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

[Cuiyang <[e-mail]>]

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 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 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.
> >
> >
> >
> >
> > The IETF Secretariat
> > _______________________________________________
> > paws mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/paws
> > _______________________________________________
> > paws mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/paws
> _______________________________________________
> paws mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/paws