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

[Peter McCann <[e-mail]>]

Hi, Subir,

Das, Subir wrote:
> Answers inline.
> 
> -----Original Message-----
> From: Peter McCann [mailto:[e-mail]]
> Sent: Wednesday, July 25, 2012 3:04 PM
> To: Cuiyang; Das, Subir; [e-mail]; [e-mail]
> 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

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.

> Is it so that you can upgrade the hash function from MD5 to SHA-1?
> 
> 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.

> 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.

Why not use an HTTP Response message?

> 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.

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.

> 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.

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

-Pete

> -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). 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
>>  [e-mail]
>>  
>>> -----邮件原件-----
>>> 发件人: Das, Subir [mailto:[e-mail]]
>>> 发送时间: 2012年7月24日 7:46
>>> 收件人: Cuiyang; [e-mail]; [e-mail]
>>> 主题: RE: comments on draft-das-paws-protocol-02.txt
>>> 
>>> Thanks for your comments. Some answers inline.
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Cuiyang
>>> Sent: Monday, July 23, 2012 8:45 AM
>>> To: [e-mail]; [e-mail]
>>> Subject: Re: [paws] comments on draft-das-paws-protocol-02.txt
>>> 
>>> 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.
>>> 
>>> 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
>>> SD> 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?
>>> 
>>> - 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?
>>> 
>>> SD> During normal TLS negotiation.
>>> 
>>> - 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.
>>> 
>>> SD>  I do not understand this. HTTP/TLS is used in our scheme.
>>> 
>>> - "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.
>>> 
>>> SD> Yes it should be HMAC-SHA1.
>>> 
>>> 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
>>>  [e-mail]
>>>  
>>>> -----邮件原件-----
>>>> 发件人: [e-mail] [mailto:[e-mail]] 代表
>>>> [e-mail]
>>>> 发送时间: 2012年7月22日 7:31
>>>> 收件人: [e-mail]
>>>> 主题: [paws] comments on draft-das-paws-protocol-02.txt
>>>> 
>>>> 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: [e-mail]
>>>> [mailto:[e-mail]] On Behalf Of ext Das, Subir Sent:
>>>> Saturday, July 14, 2012 7:36 AM To: [e-mail] 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: [e-mail]
>>>> [mailto:[e-mail]] Sent: Saturday, July 14, 2012
>>>> 10:30 AM To: Das, Subir Cc: [e-mail];
>>>> [e-mail] 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.
>>>>