[secdir] Secdir review of draft-sheffer-emu-eap-eke-06

[Brian Weis <[e-mail]>]

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