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 revision | 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
|
|
| Completed | 2010-08-20 |
review-sheffer-emu-eap-eke-secdir-telechat-weis-2010-08-20-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 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