Telechat 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 Telechat Review
Team Security Area Directorate (secdir)
Deadline 2010-08-24
Requested 2010-08-16
Authors Scott Fluhrer, Glen Zorn, Yaron Sheffer, Hannes Tschofenig
Draft last updated 2010-08-20
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-telechat-weis-2010-08-20
Review completed: 2010-08-20


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 review comments.

I previously reviewed -06 of this I-D and made a number of  

suggestions. The current version has addressed those as well as other  

last call comments. I have just one concern and one comment regarding  

the changes regarding encrypting DHComponent_S and DHComponent_P in on- 

the-wire payloads. This is described in Sections 5.1, 5.2, and 6.1.  

I'm going to discuss DHComponent_S, but DHComponent_P is similarly  


1. In -06, DHComponent_S was protected with an IKEv2-style prf+():
    DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s),
In -07, DHComponent_S is now protected with a "keyed MAC":
     DHComponent_S = Encr(kmac+(password), y_s)
where kmac+() is defined as:
    kmac+(P) = T1 | T2 | ...
 where each Ti is an application of the keyed MAC with a fixed key:
     T1 = kmac("S"+, P | 0x01)
     T2 = kmac("S"+, T1 | P | 0x02)
     T3 = kmac("S"+, T2 | P | 0x03)

Dan Harkins suggested an "extractor and expander" KDF, which I believe  

motivated this change. I think the use of a constant "salt" value used  

as a key in kmac+ approximates only the "extractor" function described  

in RFC 5869, and the output of an "extractor" is not intended to be  

the final KDF output. An "expander" function is necessary to follow  

the "extractor" function, and prf+ fits that description. So unless  

I'm mistaken, these section should define two calls: one to kmac() to  

to create an intermediate value of the appropriate size, and the  

another that uses the intermediate value as the key to a prf+ call.

I think it might be convenient to require the kmac+ and prf+  

algorithms be the same.

2. As far as I can tell, the definition of "kmac" is new to this I-D,  

which I found a bit confusing. It's really just a MAC, so I think it  

would be clearer to just call it a mac().