Skip to main content

Last Call Review of draft-sheffer-emu-eap-eke-
review-sheffer-emu-eap-eke-secdir-lc-weis-2010-05-27-00

Request Review of draft-sheffer-emu-eap-eke
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-05-19
Requested 2010-04-25
Authors Scott Fluhrer , Glen Zorn , Yaron Sheffer , Hannes Tschofenig
I-D last updated 2010-05-27
Completed reviews Secdir Last Call review of -?? by Brian Weis
Secdir Telechat review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-sheffer-emu-eap-eke by Security Area Directorate Assigned
Completed 2010-05-27
review-sheffer-emu-eap-eke-secdir-lc-weis-2010-05-27-00
I have reviewed this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the  


IESG. These comments were written primarily for the benefit of the  


security area directors. Document editors and WG chairs should treat  


these comments just like any other last call comments.






This document describes a new EAP method based on the Encrypted Key  


Exchange (EKE) protocol. The well-defined EKE exchange is preceded by  


a new crypto policy negotiation exchange, several of the payloads are  


protected by authenticated encryption, and a cryptographic  


confirmation that both the server and peer have seen identical  


messages has been added.






The document and Security Considerations are comprehensive, and I see  


no issues that need to be addressed. I do have the following  


suggestions for improvement.






Section 3.1. The schematic of the EAP-EKE messages (bottom of page 6)  


defines a number of terms for the first time, without explanation. The  


single sentence following it (top of page 7) seems intended to point  


the reader to Section 5 to find those terms. It ought to be a little  


more descriptive. At a minimum, I suggest something like "Section 5  


explains the various cryptographic values and how they are derived."






Section 5.1. The strength of x_s is significantly determined by the  


choice of randomness method deriving x_s. It seems that a weak source  


of randomness would be a significant implementation flaw for EAP-EKE.  


This section does refer to RFC 4086 for randomness recommendations,  


which should certainly be helpful to implementors. But perhaps also  


referencing some well-known methods (e.g., NIST SP 800-90) would be  


even better.






Section 7.3. The sentence following the table seems to be trying to  


define a PRF as something with a "K" and an "S", but doesn't define  


what those values mean. This should either be clarified, or have the  


section point to a better external definition of a PRF.






Section 7.6. Defining a registry without any standardized values  


(other than a "reserved" value of 0x0) isn't very useful for  


interoperability. If the expectation is that private use values will  


be mainly used, perhaps the channel binding value should be treated as  


a vendor-id payload rather than a registry.




Brian