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

[Tschofenig, Hannes (hannes.tschofenig]

hi all, 

here is a review of <draft-badra-eap-double-tls-03.txt>:

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


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. 

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.

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. 


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. 

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?

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. 


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. 
- the relationship of appendix a to the rest of the document is not clear.
- kerberos is mentioned at several places throughout the document. it is not 
described how kerberos should be used in the context of this method. 
- although the advantages of the eap method are advertised in the context of 
tunneling an eap method (or other authentication methods) over eap-tls 
eap-double-tls allows to skip the inner method. the relationship to other 
methods, such as peap, eap-ttls and eap-fast, is not clear. if the goal is user 
identity confidentiality for the eap peer and pfs then more efficient methods 
are available.

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> Im Auftrag von Jari Arkko
> Gesendet: Dienstag, 7. Juni 2005 11:37
> An: eap [at] frascone.com
> Betreff: [eap] methods and expert reviews
> 
> 
> Hello folks,
> 
> Just to keep you updated on what's going on with expert reviews
> of methods: We have gotten a number of requests for expert reviews
> and iana assignments. Expert reviews are focusing on making sure
> RFC 3748 is followed. The template for such reviews is at
> http://www.drizzle.com/~aboba/EAP/template.txt
> We have gotten a number of volunteers to do such reviews,
> see below. Thanks for the volunteers!
> 
> We hope to receive the reviews in two weeks, which should
> give some time for discussion & revision before the next
> I-D deadline, if necessary.
> 
> Other comments and opinions on methods are also welcome both
> by these reviewers or other members of the WG on, e.g.,
> the usefulness of the methods for a particular purpose, security
> properties, what people feel like is something that they would
> implement, etc.
> 
> EAP-PSK
> <http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-07.txt>
> Reviewer: Jesse Walker
> 
> EAP-IKEv2
> <http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev
2-06.txt>
Reviewer: Pasi Eronen

EAP Double TLS
<http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-03.txt>
Reviewer: Hannes Tschofenig

EAP Smartcard Type
<http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-01.txt>
Reviewer: Glen Zorn

_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap