eap Mailing List: Re: AW: [eap] methods and expert reviews

[badra [at] enst.fr (badra]

Hello Hannes,
Thank you for your review. Some comments are in-line..

> 1. Does the method document its security properties
> in sufficient manner, as required by Section 7.2
> of RFC 3748?
>
> 1a. Mechanism. Is the mechanism explained?
>
> the mechanism used eap-tls, draft-ietf-tls-sharedkeys and some additional
"inner" mechanisms similar to peap or ttls (but seems to go beyond them).
> the security properties of the "inner" mechanisms are not well described
(e.g., the usage of draft-urien-eap-smartcard or other authentication
mechanisms such as kerberos).

There is some inner mechanisms used within eap-double-tls. All of them are
optional and are used if the client and the server want more security
services. For example, if they want to establish a secure session with PFS
and identity protection, so they establish an anonymous TLS as inner
mechanism. If they don't care about these services, they may be satisfied
by the first session (based on Pre-Shared-Key). Concerning the
draft-urien-eap-smartcard, we suggest to introduce the use of EAP smart
cards as an optional method in order to securely store secret and private
keys. For that an appendix is added at the end of the draft.

I think that there is an Internet Draft that explains the use of the
Kerberos over EAP. Kerberos also remains an optional mechanism. The draft
suggests the use of any key exchange protocol during the second phase in
order to generate new secret keys and to remplace the old ones.

> 1b. Security claims. Are the claimed and not claimed
> properties listed?
>
> since the method introduces many optional parts it is difficult to
illustrate the security properties in a single list (e.g., the draft name
says "double-tls" but one option is the protocol is it to use it without
the "double" part). as a consequence the security properties are entirely
different.

Ok. But I think that the draft shows the differents services offered by
eap-double-tls in the case of an anonymous TLS that is used as an inner
mechanism by default.

> the aspect of cryptographic binding is not described.
> 1c. Justifications for the claims? Is an explanation or
> reference provided to each of the claims?
>
> most of the security properties are described but this should be done in
the context of the different protocol options. for example, what happens if
you do not use pfs, identity protection and tunnel eap-md5 over eap-tls? 
explanations are given but they are applicable only to certain modes of
operation.
> 1d. Key strength. Is the key strength documented?
>
> only a pointer to the tls-prf function is given. this is insufficient.
>  
>

A section shall be added to clarify this point.

> 1e. Description of key hierarchy. Is the key hierarchy
> documented?
>
> section 3.4 mentions the key derivation. however, more information is
required to see how the crypto-binding works, how the MSK is derived. the
current text seems to focus on the tls key derivation.
> [Optional, at least for now: does it conform to EAP
> keying framework?]
>
> no.
> 1f. Indication of vulnerabilities. Are the known vulnerabilities
> documented?
>
> [Note: it seems unreasonable to require the documentation
> of unknown vulnerabilities :-) The "known" may of course be
> "known to reviewer" or "known to author" or "known to the
> community", but that appears to be best we can do.]
>
> no vulnerabilities are mentioned. the need for the crypto-binding must be
mentioned in order to prevent man-in-the-middle attacks.

The first phase is based the TLS resumed Handshake and the client and the
server are mutually authenticated through the finished messages. A
man-in-the-middle will so be detected when the client and the server will
check, among other, the messages integrity. Concerning the second phase
messages, they will be protected and symmetrically signed by keys derived
from the shared key and the random values.

> 2. Compliance with EAP packet formats
>
> 2a. Does the method comply with the packet formats
> defined in Section 4 of RFC 3748?
>
> yes.
> 3. Compliance with EAP behaviour
>
> 3a. Does the method comply with Success/Failure usage
> as defined in Sections 2, 2.2, and 4.2?
>
> yes, implicitly follows the same procedure as eap-tls
> 3b. Does the method comply with sequence usage as defined
> in Section 2.1 of RFC 3748?
>
> yes.
> 3c. Does the method comply with request/response processing
> rules as defined in Section 4.1 of RFC 3748?
>
> yes.
> 3d. Does the method comply with retransmission rules
> as defined in Section 4.3 of RFC 3748?
>
> not mentioned although there might be some issues with regard to the
inner authentication methods that require user input.
>  
>
> 3e. Does the method comply with the usage defined for
> Identity, as defined in Section 5.1 of RFC 3748?
>
> yes;
> the concept of temporal identities is used to provide user identity
confidentiality. synchronization issues need to be addressed (i.e., what
happens if the state is out-of-sync) but this does not seem to impact rfc
3748.
> 3f. Does the method comply with the usage defined for
> Notification, as defined in Section 5.2 of RFC 3748?
>
> yes, implicitly mentioned with a reference to eap-tls
>
> 3g. Does the method comply with the usage defined for
> Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?
>
> not mentioned. 


Will be added

> 3h. Does the method comply with the MIC usage requirements
> from Sections 3.1, 7.5, and 7.8 of RFC 3748?
>
> yes, implicitly since it follows eap-tls.
>
> 4. Compliance with IANA requirements
>
> 4a. Does the method comply with EAP-based IANA requirements
> defined in Section 6 of RFC 3748? That is, if it requests
> the allocation of new numbers in the EAP namespace [not
> applicable if the numbers have already been allocated],
> is the type of the document and process appropriate for the
> desired action?
>
> a request to iana to allocate a new eap type is indicated. inner methods
might also require the creation of a registry
> or is the eap-ttls namespace inherited?

Yes for eap-ttls avp, but not for inner methods (The draft does not use new
EAP methods during its second phase).

> 4b. Does the method comply with other IANA requirements in
> the IETF standards track RFCs? For instance, does the
> method attempt to allocate TLS extensions (which would
> only be possible for standards track RFCs)?
>
> i am not sure whether the authors want this document become a standards
track rfc.

The draft does not define new extension type. It is based on TLS resumed
Handshake.

> a few minor comments:
> - the reference section needs to be split into normative and informative
references. having (expired) drafts in the normative part of the reference
section will be problematic. 

Will be fixed

> - the relationship of appendix a to the rest of the document is not clear.

For key storage, and it is an optional method.

> - kerberos is mentioned at several places throughout the document. it is
not described how kerberos should be used in the context of this method. 



In fact, the draft uses the eap-ttls avp to encapsulate other eap methods,
including eap-kerberos.

Best regards,
Badra

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .