Subject: [paws] comments on draft-das-paws-protocol-02.txt

From: <[email-masked]>
Date: Sat, 21 Jul 2012 23:30:35 +0000

It would be beneficial if there were discussions on the drafts to submitted ahead of the F2F presentations.
Thus, I've taken the initiative to read the draft and provide some initial comments:

1. I do not understand the purpose of the initialization process and why messages INT-REQ and INT-RESP are necessary. The capability exchange can be done during the registration process.
We may even consider merging the registration process with the DB query process, there doesn't seem to be any reason to have them as separate messages.

2. you may need a section where you map your newly defined messages to existing http protocol messages. I saw that you have an example section, but a normative section would be more desirable.

3. the data model part needs some more work. The structure is not very clear to me, and some of the attributes reference obsolete RFC. 
Eg, RFC3825 is referenced for the longitude/latitude attributes. I think you should be better of using an element for geo-location, with the structure as defined in RFC5491, a separate element for the civic location, with the structure as defined in RFC5139, etc.
Instead of the DeviceOwner object, I would use a vCard element, with the structure as defined in RFC2426.
You may also need an iCalendar element (RFC5545) to specify the channel availability time (eg, when the channel is not available for the full 24H).
Etc.

More comments are welcome.
- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Subir
Sent: Saturday, July 14, 2012 7:36 AM
To: [email-masked]
Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02.txt

Dear Chairs,
We have updated our draft and would like to request a slot in IETF-84 to present it.

Regards, 
_Subir 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 14, 2012 10:30 AM
To: Das, Subir
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-das-paws-protocol-02.txt

A new version of I-D, draft-das-paws-protocol-02.txt has been successfully submitted by Subir Das and posted to the IETF repository.

Filename:	 draft-das-paws-protocol
Revision:	 02
Title:		 Device to Database Protocol for White Space
Creation date:	 2012-07-14
WG ID:		 Individual Submission
Number of pages: 32
URL:             http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt
Status:          http://datatracker.ietf.org/doc/draft-das-paws-protocol
Htmlized:        http://tools.ietf.org/html/draft-das-paws-protocol-02
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-das-paws-protocol-02

Abstract:
   This document describes the `Protocol to Access White Space database
   (PAWS)' that uses HTTP/TLS as transport.  The protocol is used for
   retrieving the necessary TV white space information (e.g., channel,
   frequency, transmitted power) at a given location and time from a
   database that is operating under a regulatory domain.  The document
   includes the protocol functionalities, its elements, corresponding
   data model and recommends its encoding scheme.

The IETF Secretariat
_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Sat, 21 Jul 2012 21:07:02 -0400

Gabor.
This draft represents the merger of two submitted proposals, one from
Das/Gabor from Telcordia and one from Peter/Don from SBI prior to the last
meeting.
These individuals have worked to create a single proposal for this
upcoming meeting. This attempt at a merger was a request from the last
meeting and was acted upon so I do not understand why you think there has
been no discussion.
I do not agree with your assertion that the data model needs more work.
For example your assumption that an iCalander element is needed. You
assume that a 24 hour channel map is provided. There is no reason to
require this. In fact there is ongoing discussion in the US to migrating
to much shorter channel allocations and it is reasonable to have a channel
map that is valid for a duration until such time as something changes. In
other words the DB provides a channel map that is valid from now until
some time in the future, which may be much less than 24 hours.
Peter S.

On SatJul/21/12 Sat Jul 21, 7:30 PM, "[email-masked]"
<[email-masked]> wrote:

>It would be beneficial if there were discussions on the drafts to
>submitted ahead of the F2F presentations.
>1. I do not understand the purpose of the initialization process and why
>messages INT-REQ and INT-RESP are necessary. The capability exchange can
>be done during the registration process.
>We may even consider merging the registration process with the DB query
>process, there doesn't seem to be any reason to have them as separate
>messages.
>
>2. you may need a section where you map your newly defined messages to
>existing http protocol messages. I saw that you have an example section,
>but a normative section would be more desirable.
>
>3. the data model part needs some more work. The structure is not very
>clear to me, and some of the attributes reference obsolete RFC.
>Eg, RFC3825 is referenced for the longitude/latitude attributes. I think
>you should be better of using an element for geo-location, with the
>structure as defined in RFC5491, a separate element for the civic
>location, with the structure as defined in RFC5139, etc.
>You may also need an iCalendar element (RFC5545) to specify the channel
>availability time (eg, when the channel is not available for the full
>24H).
>Etc.
>
>A new version of I-D, draft-das-paws-protocol-02.txt has been
>successfully submitted by Subir Das and posted to the IETF repository.
>
>URL:             
>http://www.ietf.org/internet-drafts/draft-das-paws-protocol-02.txt
>Diff:            
>http://tools.ietf.org/rfcdiff?url2=draft-das-paws-protocol-02
>
>Abstract:

---

From: Peter Stanforth <[email-masked]>
Date: Sun, 22 Jul 2012 07:22:16 -0400

Sorry I got my naming/timing wrong. John Malyar and Don Joslyn submitted drafts to the last F2F.  Subir Das and Don Joslyn combined them for this F2F
Peter S.

---

From: "Malyar, John P" <[email-masked]>
Date: Sun, 22 Jul 2012 15:45:15 +0000

Gabor,

Thanks for your comments. We separated the two sets of functions to allow for (as described in the document) the general ability for the Master Device to establish communications with the Database in the INT-REQ and used the REG-REQ for the specific purpose of supporting the requirement for a Fixed Device to register its location and owner information as per the FCC rules. They could be combined; however, it seemed clearer to separate out the optional requirement of the Fixed Device registration into a separate well defined function.

Regarding the data model using vCard and iCalendar are reasonable implementations however including these packages may be cumbersome and overkill for the one or two elements that need to be communicated. One of the design principles we were considering in the draft proposal was to keep the interface light weight. Looking forward to the discussion in Vancouver.

Regards,

John Malyar      

________________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Saturday, July 21, 2012 7:30 PM
To: [email-masked]
Subject: [paws] comments on  draft-das-paws-protocol-02.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Subir
Sent: Saturday, July 14, 2012 7:36 AM
To: [email-masked]
Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02.txt

Dear Chairs,

Regards,
_Subir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, July 14, 2012 10:30 AM
To: Das, Subir
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-das-paws-protocol-02.txt

Abstract:

The IETF Secretariat

---

From: Cuiyang <[email-masked]>
Date: Mon, 23 Jul 2012 12:45:16 +0000

Hi All,

I would like to provide some comments to this draft, from a security point of view.
Hope that it will be helpful.

The TLS and "HTTP Digest Auth" have been used, but seem unclear for me. Besides, it is not recommended to use the latter for some reasons listed below.
- It is said that the HTTP/TLS protocol is deployed for mutual authentication. However, "HTTP digest authentication" is actually used for authenticating the device, which is typically weaker than normal TLS. Only the server side authentication is performed by TLS certificate-based crypto method.
- It appears that authentication is done in different layers, i.e., device is done in PAWS layer by "HTTP digest auth" and server is achieved in TLS layer by certificate. I do not understand why security is done in mixed layers?
- It is said that confidentiality is protected in HTTPS layer, but if authenticating device is achieved in different layer (i.e. in PAWS layer), how can the device and server negotiate the session key?
- Or, if my above understanding is wrong and mutual authentication is indeed done in TLS layer, why does it need to have additional "HTTP digest auth" in PAWS layer?
- "HTTP digest auth" only provides a hash-based protection for secrets like password and ID, and is known to be vulnerable to MitM (Man-in-the-Middle) attacks. Since according to the PAWS WG document, draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7, MitM attack should be thwarted. This draft using "HTTP digest auth" obviously does not satisfy the security requirement.
- "HTTP digest auth" differs from HTTP over TLS, where the former provides no encryption for content, but the latter can encrypt the content by Public Key crypto. Thus TLS is preferred.
- "HTTP digest auth" does not support HMAC algorithm (so-called Keyed Hash), thus it is yet a little risky to use SHA-1 to replace current MD5 algorithm, because NIST has not recommended to use the collision resistance of SHA-1 (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does not have such a problem.

From the above analysis, it is clear to see that the security and privacy of PAWS is not straightforward and needs to be carefully investigated, for design and implementation.
It is also the reason why we have submitted an independent draft for PAWS security, to provide a base for discussion.

BR,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> [email-masked]
> 发送时间: 2012年7月22日 7:31
> 收件人: [email-masked]
> 主题: [paws] comments on draft-das-paws-protocol-02.txt
> 
> existing http protocol messages. I saw that you have an example section, but a
> normative section would be more desirable.
> 
> 3. the data model part needs some more work. The structure is not very clear
> to me, and some of the attributes reference obsolete RFC.
> Eg, RFC3825 is referenced for the longitude/latitude attributes. I think you
> should be better of using an element for geo-location, with the structure as
> defined in RFC5491, a separate element for the civic location, with the
> structure as defined in RFC5139, etc.
> availability time (eg, when the channel is not available for the full 24H).
> Etc.
> 
> A new version of I-D, draft-das-paws-protocol-02.txt has been successfully
> submitted by Subir Das and posted to the IETF repository.
>

---

From: "Das, Subir" <[email-masked]>
Date: Mon, 23 Jul 2012 23:19:11 +0000

Thanks for your comments. I will answer your following point that was not covered by John and Peter: 

SD>  Yes, we would be happy do that in next version. 

-Subir 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Subir
Sent: Saturday, July 14, 2012 7:36 AM
To: [email-masked]
Subject: [paws] FW: New Version Notification for draft-das-paws-protocol-02.txt

Dear Chairs,

Regards, 
_Subir 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, July 14, 2012 10:30 AM
To: Das, Subir
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-das-paws-protocol-02.txt

Abstract:

The IETF Secretariat

---

From: "Das, Subir" <[email-masked]>
Date: Mon, 23 Jul 2012 23:45:57 +0000

Thanks for your comments. Some answers inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cuiyang
Sent: Monday, July 23, 2012 8:45 AM
To: [email-masked]; [email-masked]
Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt

Hi All,

The TLS and "HTTP Digest Auth" have been used, but seem unclear for me. Besides, it is not recommended to use the latter for some reasons listed below.
- It is said that the HTTP/TLS protocol is deployed for mutual authentication. 

SD> This is not correct. 

However, "HTTP digest authentication" is actually used for authenticating the device, 

SD>  Digest Authentication is used to authenticate the client at the PAWS layer. 

which is typically weaker than normal TLS. 

SD> Why is it weaker? 

Only the server side authentication is performed by TLS certificate-based crypto method.
- It appears that authentication is done in different layers, i.e., device is done in PAWS layer by "HTTP digest auth" and server is achieved in TLS layer by certificate. 

SD> Yes, authentication is done at the PAWS layer by using digest authentication. 

I do not understand why security is done in mixed layers?

SD> During normal TLS negotiation. 

SD> Only client authentication is done at the PAWS layer. Of course client auth can be done at the TLS layer. Then one needs to have channel binding and that's another approach.   

SD>  I do not understand this. HTTP/TLS is used in our scheme. 

SD> Yes it should be HMAC-SHA1.  

BR,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> Thus, I've taken the initiative to read the draft and provide some 
> initial
> comments:
> 
> 1. I do not understand the purpose of the initialization process and 
> why messages INT-REQ and INT-RESP are necessary. The capability 
> exchange can be done during the registration process.
> We may even consider merging the registration process with the DB 
> query process, there doesn't seem to be any reason to have them as 
> separate messages.
> 
> existing http protocol messages. I saw that you have an example 
> section, but a normative section would be more desirable.
> 
> Eg, RFC3825 is referenced for the longitude/latitude attributes. I 
> think you should be better of using an element for geo-location, with 
> the structure as defined in RFC5491, a separate element for the civic 
> You may also need an iCalendar element (RFC5545) to specify the 
> channel availability time (eg, when the channel is not available for the full 24H).
> Etc.
>

---

From: Cuiyang <[email-masked]>
Date: Tue, 24 Jul 2012 12:41:03 +0000

Thanks for your answers.

But then I realized that the proposal is using a kind of two-layer authentication protocols, s.t. an outer layer protocol of TLS authentication of server (database), and an inner layer protocol authentication of client (Master device).
Unfortunately, it is known that such a mixed mode of authentication is vulnerable to MitM.
I am seriously concerned that this draft is also in the case.

In particular, such a combination of TLS of server authentication and HTTP digest authentication of client, is raised as an insecure example in several places, including:
- RFC 4169
- Asokan-Niemi-Nyberg attack 2002, http://eprint.iacr.org/2002/163.pdf

Quoted from RFC 4169, Sec 4.3, Man-in-the-Middle Attack,
	" For example, the use of TLS with HTTP Digest authentication (i.e.,
   TLS for server authentication, and subsequent use of HTTP Digest for
   client authentication) is an instance of such scenario.  HTTP
   challenges and responses can be fetched from and to different TLS
   tunnels without noticing their origin."

Although the above attack needs some conditions, such a use of TLS and HTTP digest does lead the proposed protocol to a dangerous situation.
It is mainly because, (details could be found in Asokan et al's paper)
- HTTP digest authentication protocol is too weak. It only has a cryptographic hash function to run a one-way computation of the password, lack of secret key based or public key based protection, unlike TLS.
- The session key is negotiated in outer TLS protocol solely.
- The inner protocol HTTP digest auth does not realize the existence of outer TLS protocol.

A possible solution to this problem might be to cryptographically bind the inner and outer protocol, for example, to generate a session key for inner protocol.
However, HTTP digest does not use nor generate session key...
Again, IMHO, it seems not a good idea to use HTTP digest auth protocol for client authentication. Some other candidates need to be considered.

And again, I feel that it is necessary to set up an independent draft taking care of PAWS security, which may help design and implement the PAWS protocol.
Hope that our draft, draft-wu-paws-secutity-00, could be a starting point. Any comment is welcome.

BR,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: Das, Subir [mailto:[email-masked]]
> 发送时间: 2012年7月24日 7:46
> 收件人: Cuiyang; [email-masked]; [email-masked]
> 主题: RE: comments on draft-das-paws-protocol-02.txt
> 
> The TLS and "HTTP Digest Auth" have been used, but seem unclear for me.
> Besides, it is not recommended to use the latter for some reasons listed
> below.
> - It appears that authentication is done in different layers, i.e., device is done
> in PAWS layer by "HTTP digest auth" and server is achieved in TLS layer by
> certificate.
> 
> - It is said that confidentiality is protected in HTTPS layer, but if
> authenticating device is achieved in different layer (i.e. in PAWS layer), how
> can the device and server negotiate the session key?
> 
> - Or, if my above understanding is wrong and mutual authentication is indeed
> done in TLS layer, why does it need to have additional "HTTP digest auth" in
> PAWS layer?
> 
> SD> Only client authentication is done at the PAWS layer. Of course client
> auth can be done at the TLS layer. Then one needs to have channel binding
> and that's another approach.
> 
> - "HTTP digest auth" only provides a hash-based protection for secrets like
> password and ID, and is known to be vulnerable to MitM (Man-in-the-Middle)
> attacks. Since according to the PAWS WG document,
> draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7, MitM
> attack should be thwarted. This draft using "HTTP digest auth" obviously
> does not satisfy the security requirement.
> 
> - "HTTP digest auth" differs from HTTP over TLS, where the former provides
> no encryption for content, but the latter can encrypt the content by Public
> Key crypto. Thus TLS is preferred.
> - "HTTP digest auth" does not support HMAC algorithm (so-called Keyed
> Hash), thus it is yet a little risky to use SHA-1 to replace current MD5
> algorithm, because NIST has not recommended to use the collision resistance
> of SHA-1 (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does
> not have such a problem.
> 
> From the above analysis, it is clear to see that the security and privacy of
> PAWS is not straightforward and needs to be carefully investigated, for
> design and implementation.
> It is also the reason why we have submitted an independent draft for PAWS
> security, to provide a base for discussion.
> 
> BR,
> Yang
> ==================
>  Yang Cui,  Ph.D.
>  Huawei Technologies
>  [email-masked]
> 
> 
> > -----邮件原件-----

---

From: Peter McCann <[email-masked]>
Date: Wed, 25 Jul 2012 19:03:50 +0000

It also appears that draft-das re-implements HTTP Digest at the
application layer, rather than attempting to use standard HTTP
Digest.  I am curious as to why you made this choice.  Is it so
that you can upgrade the hash function from MD5 to SHA-1?

Also, you don't show the messages that relay the nonce value from
the server to the client.  I think you will need to specify that
message as well.  HTTP does this with a 401 Unauthorized response.

It also looks like you are not sending any responses at all in your
examples, just using POST in both directions.  This seems strange.

It might be better to rely on client certificates at the TLS layer
to authenticate the master device.

For authenticating the slave devices, we might need something at the
application layer.  That is a separate discussion that still needs to
happen (neither draft right now deals with authenticating the slave
device identifiers).

-Pete

Cuiyang wrote:
> Thanks for your answers.
> 
> But then I realized that the proposal is using a kind of two-layer
> authentication protocols, s.t. an outer layer protocol of TLS
> authentication of server (database), and an inner layer protocol
> authentication of client (Master device).
> In particular, such a combination of TLS of server authentication and
> HTTP digest authentication of client, is raised as an insecure example
> in several places, including:
> - RFC 4169
> Although the above attack needs some conditions, such a use of TLS and
> HTTP digest does lead the proposed protocol to a dangerous situation.
> - HTTP digest authentication protocol is too weak. It only has a
> cryptographic hash function to run a one-way computation of the
> password, lack of secret key based or public key based protection,
> unlike TLS.
> A possible solution to this problem might be to cryptographically bind
> the inner and outer protocol, for example, to generate a session key
> for inner protocol.
> Again, IMHO, it seems not a good idea to use HTTP digest auth protocol
> for client authentication. Some other candidates need to be considered.
> 
> And again, I feel that it is necessary to set up an independent draft
> taking care of PAWS security, which may help design and implement the
> PAWS protocol.
>> Besides, it is not recommended to use the latter for some reasons
>> listed below. - It is said that the HTTP/TLS protocol is deployed for
>> mutual authentication.
>> 
>> SD> This is not correct.
>> 
>> SD>  Digest Authentication is used to authenticate the client at the
>> SD> PAWS
>> layer.
>> 
>> - It appears that authentication is done in different layers, i.e.,
>> device is done in PAWS layer by "HTTP digest auth" and server is
>> achieved in TLS layer by certificate.
>> 
>> - It is said that confidentiality is protected in HTTPS layer, but
>> if authenticating device is achieved in different layer (i.e. in
>> PAWS layer), how can the device and server negotiate the session key?
>> 
>> - Or, if my above understanding is wrong and mutual authentication
>> is indeed done in TLS layer, why does it need to have additional
>> "HTTP digest auth" in PAWS layer?
>> 
>> SD> Only client authentication is done at the PAWS layer. Of course
>> SD> client
>> auth can be done at the TLS layer. Then one needs to have channel
>> binding and that's another approach.
>> 
>> - "HTTP digest auth" only provides a hash-based protection for secrets
>> like password and ID, and is known to be vulnerable to MitM
>> (Man-in-the-Middle) attacks. Since according to the PAWS WG document,
>> draft-ietf-paws-problem-stmt-usecases-rqmts-06, Chapter 8, threat 7,
>> MitM attack should be thwarted. This draft using "HTTP digest auth"
>> obviously does not satisfy the security requirement.
>> 
>> - "HTTP digest auth" differs from HTTP over TLS, where the former
>> provides no encryption for content, but the latter can encrypt the
>> content by Public Key crypto. Thus TLS is preferred. - "HTTP digest
>> auth" does not support HMAC algorithm (so-called Keyed Hash), thus it
>> is yet a little risky to use SHA-1 to replace current MD5 algorithm,
>> because NIST has not recommended to use the collision resistance of
>> SHA-1 (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and does
>> not have such a problem.
>> 
>> From the above analysis, it is clear to see that the security and
>> privacy of PAWS is not straightforward and needs to be carefully
>> investigated, for design and implementation.
>> It is also the reason why we have submitted an independent draft for
>> PAWS security, to provide a base for discussion.
>> 
>> BR,
>> Yang
>> ==================
>>  Yang Cui,  Ph.D.
>>  Huawei Technologies
>>  [email-masked]
>> 
>>> -----邮件原件-----
>>> exchange can be done during the registration process. We may even
>>> consider merging the registration process with the DB query process,
>>> there doesn't seem to be any reason to have them as separate messages.
>>> 
>>> 2. you may need a section where you map your newly defined
>>> messages to existing http protocol messages. I saw that you have
>>> an example section, but a normative section would be more desirable.
>>> 
>>> clear to me, and some of the attributes reference obsolete RFC. Eg,
>>> RFC3825 is referenced for the longitude/latitude attributes. I think
>>> location, with the structure as defined in RFC5139, etc. Instead of
>>> the DeviceOwner object, I would use a vCard element, with the
>>> structure as defined in RFC2426. You may also need an iCalendar
>>> element (RFC5545) to specify the channel availability time (eg, when
>>> the channel is not available for the full 24H). Etc.
>>> 
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of ext Das, Subir Sent:
>>> Saturday, July 14, 2012 7:36 AM To: [email-masked] Subject: [paws] FW:
>>> New Version Notification for draft-das-paws-protocol-02.txt
>>> 
>>> Dear Chairs,
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] Sent: Saturday, July 14, 2012 10:30
>>> AM To: Das, Subir Cc: [email-masked];
>>> [email-masked] Subject: New Version Notification for
>>> draft-das-paws-protocol- 02.txt
>>> 
>>> 
>>> Filename:	 draft-das-paws-protocol Revision:	 02 Title:		 Device to
>>> Database Protocol for White Space Creation date:	 2012-07-14 WG ID:		
>>> Individual Submission Number of pages: 32 URL:
>>> Status:          http://datatracker.ietf.org/doc/draft-das-paws-
>>> protocol Htmlized:        http://tools.ietf.org/html/draft-das-paws-
>>> protocol-02 Diff:
>>>    This document describes the `Protocol to Access White Space
>>>    database (PAWS)' that uses HTTP/TLS as transport.  The protocol is
>>>    used for retrieving the necessary TV white space information (e.g.,
>>>    channel, frequency, transmitted power) at a given location and time
>>>    from a database that is operating under a regulatory domain.  The
>>>    document includes the protocol functionalities, its elements,
>>>    corresponding data model and recommends its encoding scheme.
>>> 
>>> 
>>> 
>>> The IETF Secretariat

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 26 Jul 2012 05:25:59 +0000

Answers inline. 

-----Original Message-----
From: Peter McCann [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 3:04 PM
To: Cuiyang; Das, Subir; [email-masked]; [email-masked]
Subject: RE: comments on draft-das-paws-protocol-02.txt

It also appears that draft-das re-implements HTTP Digest at the application layer, rather than attempting to use standard HTTP Digest. I am curious as to why you made this choice.  

SD>  This is not new. Other IETF protocols have used this, for example, RFC 3261

Is it so that you can upgrade the hash function from MD5 to SHA-1?

SD> IETF does not recommend  using MD5 anymore. 

Also, you don't show the messages that relay the nonce value from the server to the client.  I think you will need to specify that message as well.  HTTP does this with a 401 Unauthorized response.

SD> This is done via initialization response message, INIT_RESP.  Remember client authentication is performed during initialization stage. We should have included the details of INIT_REQ and INIT_RESP messages in example section. Will include this in next version.

It also looks like you are not sending any responses at all in your examples, just using POST in both directions.  This seems strange.

SD>  The database responds to all requests. In our example,  we currently show PAWS protocol message  details that are included in the body of the HTTP POST.

It might be better to rely on client certificates at the TLS layer to authenticate the master device.

SD> We do not assume that the client has cert. Our experience with WSD manufactures is that they prefer the model of a shared secret for Master WSD authentication to manage costs.

For authenticating the slave devices, we might need something at the application layer.  That is a separate discussion that still needs to happen (neither draft right now deals with authenticating the slave device identifiers).

SD> Our understanding is that authenticating the slave devices is outside the scope of PAWS. There is no direct communication between slave devices and the database. However, we do support the capability of validating the slave devices via MSD. 

-Pete

Cuiyang wrote: 
>> authenticating device is achieved in different layer (i.e. in PAWS 
>> layer), how can the device and server negotiate the session key?
>> 
>> - Or, if my above understanding is wrong and mutual authentication is 
>> indeed done in TLS layer, why does it need to have additional "HTTP 
>> digest auth" in PAWS layer?
>> 
>> - "HTTP digest auth" only provides a hash-based protection for 
>> secrets like password and ID, and is known to be vulnerable to MitM
>> SHA-1 (but HMAC-SHA1 is fine). In contrast, TLS supports HMAC and 
>> does not have such a problem.
>> 
>>> 2. you may need a section where you map your newly defined messages 
>>> to existing http protocol messages. I saw that you have an example 
>>> 3. the data model part needs some more work. The structure is not 
>>> very clear to me, and some of the attributes reference obsolete RFC. 
>>> Eg,
>>> [mailto:[email-masked]] Sent: Saturday, July 14, 2012 
>>> 10:30 AM To: Das, Subir Cc: [email-masked];

---

From: Zhulei <[email-masked]>
Date: Thu, 26 Jul 2012 10:13:12 +0000

Disagree that the paws is to compare Session Initiation Protocol which is quite similar to HTTP. It is going to TLS security, but a paws digest authentication. It even does not authentication in HTTP layer. 

The digest authentication is not sufficient either in paws data model or http message body, and, I doubt this use that might mix layered functions.

I disagreed the usage of POST method for bidirectional between paws master device and DB and duplicate information in INIT_RESP message to registration. The second one is quite relevant to the security model of paws which is assumed to be discussed in meeting and is a separated arrangement according to my understanding.

Best regards,
Zhu Lei

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Das, Subir
发送时间: 2012年7月26日 13:26
收件人: Peter McCann; Cuiyang; [email-masked]; [email-masked]
主题: Re: [paws] comments on draft-das-paws-protocol-02.txt

Answers inline. 

-----Original Message-----
From: Peter McCann [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 3:04 PM
To: Cuiyang; Das, Subir; [email-masked]; [email-masked]
Subject: RE: comments on draft-das-paws-protocol-02.txt

-Pete

---

From: Peter McCann <[email-masked]>
Date: Thu, 26 Jul 2012 15:16:42 +0000

Hi, Subir,

Das, Subir wrote:
> application layer, rather than attempting to use standard HTTP Digest.
> I am curious as to why you made this choice.
> 

But 3261 does it with header fields and response codes.  What you
are proposing is like putting the challenge/response into the SDP
body, which is not the design choice made there.  If we decide to
use Digest (which is a big if) I think it should use the HTTP headers.

> SD> IETF does not recommend  using MD5 anymore.

Sure, but that's not necessarily a reason to re-implement digest
authentication in the payload.  We could define a new "algorithm"
value for the HTTP-digest scheme.

> Also, you don't show the messages that relay the nonce value from the
> server to the client.  I think you will need to specify that message as
> well.  HTTP does this with a 401 Unauthorized response.
> 
> SD> This is done via initialization response message, INIT_RESP.
> Remember client authentication is performed during initialization
> stage. We should have included the details of INIT_REQ and INIT_RESP
> messages in example section. Will include this in next version.

Ok.  Note that this will introduce an extra round-trip during the
query process.

> SD>  The database responds to all requests. In our example,  we
> currently show PAWS protocol message  details that are included in the
> body of the HTTP POST.

Why not use an HTTP Response message?

> SD> We do not assume that the client has cert. Our experience with WSD
> manufactures is that they prefer the model of a shared secret for
> Master WSD authentication to manage costs.

The use of a shared secret has additional costs because key distribution
is harder.  What if the user wants to change database providers?  This is
much easier to accomplish with a public key mechanism.

> SD> Our understanding is that authenticating the slave devices is
> outside the scope of PAWS. There is no direct communication between
> slave devices and the database. However, we do support the capability
> of validating the slave devices via MSD.

I think authentication of slave devices is required by FCC rules, as
previous discussion on the mailing list has shown.

-Pete

>> authentication of client (Master device). Unfortunately, it is known
>> that such a mixed mode of authentication is vulnerable to MitM. I am
>> seriously concerned that this draft is also in the case.
>> 
>> in several places, including: - RFC 4169 - Asokan-Niemi-Nyberg attack
>> 2002, http://eprint.iacr.org/2002/163.pdf
>> 
>> unlike TLS. - The session key is negotiated in outer TLS protocol
>> solely. - The inner protocol HTTP digest auth does not realize the
>> existence of outer TLS protocol.
>> 
>> for inner protocol. However, HTTP digest does not use nor generate
>> session key... Again, IMHO, it seems not a good idea to use HTTP digest
>> auth protocol for client authentication. Some other candidates need to
>> be considered.
>> 
>>> The TLS and "HTTP Digest Auth" have been used, but seem unclear for
>>> me. Besides, it is not recommended to use the latter for some reasons
>>>> protocol Htmlized:        http://tools.ietf.org/html/draft-das- paws-
>>>> protocol-02 Diff:
>>>>    used for retrieving the necessary TV white space information
>>>>    (e.g., channel, frequency, transmitted power) at a given location
>>>>    and time from a database that is operating under a regulatory
>>>>    domain. The document includes the protocol functionalities, its
>>>>    elements, corresponding data model and recommends its encoding
>>>>    scheme.
>>>>

---

From: Weixinpeng <[email-masked]>
Date: Fri, 27 Jul 2012 02:16:31 +0000

Hi,
I think in the request message from master device to the database POST method may be ok, but for the 
message that the database responses to the master device SHOULD be a HTTP response message, NOT a POST message.

-wei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Thursday, July 26, 2012 1:26 PM
To: Peter McCann; Cuiyang; [email-masked]; [email-masked]
Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt

Answers inline. 

-----Original Message-----
From: Peter McCann [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 3:04 PM
To: Cuiyang; Das, Subir; [email-masked]; [email-masked]
Subject: RE: comments on draft-das-paws-protocol-02.txt

-Pete

---

From: "Das, Subir" <[email-masked]>
Date: Fri, 27 Jul 2012 12:33:17 +0000

Yes, that is the case in our draft.

-----Original Message-----
From: Weixinpeng [mailto:[email-masked]] 
Sent: Thursday, July 26, 2012 10:17 PM
To: Das, Subir; Peter McCann; Cuiyang; [email-masked]; [email-masked]
Subject: RE: comments on draft-das-paws-protocol-02.txt

Hi,
I think in the request message from master device to the database POST method may be ok, but for the message that the database responses to the master device SHOULD be a HTTP response message, NOT a POST message.

-wei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Thursday, July 26, 2012 1:26 PM
To: Peter McCann; Cuiyang; [email-masked]; [email-masked]
Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt

Answers inline. 

-----Original Message-----
From: Peter McCann [mailto:[email-masked]]
Sent: Wednesday, July 25, 2012 3:04 PM
To: Cuiyang; Das, Subir; [email-masked]; [email-masked]
Subject: RE: comments on draft-das-paws-protocol-02.txt

SD>  This is not new. Other IETF protocols have used this, for example, 
SD> RFC 3261

-Pete