Last Call Review of draft-sheffer-emu-eap-eke-

Request Review of draft-sheffer-emu-eap-eke
Requested rev. 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
Draft 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
Review review-sheffer-emu-eap-eke-secdir-lc-weis-2010-05-27
Review completed: 2010-05-27


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.