Telechat Review of draft-sheffer-emu-eap-eke-
review-sheffer-emu-eap-eke-secdir-telechat-weis-2010-08-20-00

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

Review
review-sheffer-emu-eap-eke-secdir-telechat-weis-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  


changed.




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




Brian