Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Tuesday, September 07, 2010 5:25 PM
> To: Yaron Sheffer
> Cc: Brian Weis (bew); Dan Harkins; [e-mail]; draft-sheffer-emu-
> [e-mail]; Russ Housley; Tim Polk
> Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07
> 
> 
>   Hi Yaron,
> 
>   Actually what I was suggesting was to use the identities as the
> "salt" to the extraction part of HKDF. So it would look like this:
> 
>        PRF := mac(ID_s | ID_p, P)
>        KEY := mac+(PRF, "some application-specific string")
>        DHComponent_S := Encr(KEY, y_s)
> 
> This may impact your desire to use a block cipher as "mac" but you can
> do the same "truncation or zero-padding" trick you suggest below.

Truncation would be a bad idea; that means part (or all) of ID_p does
not contribute to the value of PRF.  Now, I don't know if this is a
weakness; on the other hand, if we were assured it wasn't a weakness,
why are we including ID_p at all?

> 
>   Also, I'm not sure what value there is to storing the the mac'd
> password since that value takes the place of the password to become
> the authentication credential (EKE is not an asymmetric protocol
> that can protect against server compromise by storing a transform
> of the password) but whatever value you find in that practice can
> only be enhanced by salting the value with the identities thereby
> ensuring that users with identical passwords will not have identical
> stored credentials.

However, if they were to store the KEY values, then identical passwords
will already not have identical credentials.  Would it work out better
if we suggested that more strongly?

> 
>   Dan.
> 
> On Mon, September 6, 2010 10:48 am, Yaron Sheffer wrote:
> > Hi Brian, Dan,
> >
> > thanks for both of your reviews.
> >
> > While we do not see additional value in including the identities in
> the
> > password derivation (given that they are later bound into the shared
> > secret), we don't have any problem with it either.
> >
> > We are fine with making the key derivation function more standard.
We
> > propose the following change to
> > http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit-
> request.
> > We define a KDF which is modeled on RFC 5869, and in fact becomes
> HKDF
> > when the MAC is an HMAC (note that the draft does *not* constrain
MAC
> > functions to be an HMAC construction):
> >
> >       PRF := mac("\0"+, P)
> >       KEY := mac+(PRF, ID_s | ID_p)
> >       DHComponent_S := Encr(KEY, y_s)
> >
> > PRF is truncated or zero-padded if necessary when used to derive
KEY.
> > Neither is needed when using an HMAC function for the MAC.
> >
> > The protocol peers should store the MAC'ed password, instead of a
> > plaintext password. The peers have a choice of storing the output of
> the
> > first application of MAC, or that of the second application (i.e.
> salted
> > by the identities). The security benefits of the latter should be
> > weighed against the operational difficulty associated with changing
> > either of the identities.
> >
> > BTW, we have changed the "kmac" terminology into "mac", per your
> comments.
> >
> > The operator mac+ will be redefined as:
> >
> > mac+(key, string) = T1 | T2 ...
> >
> > where each Ti is an application of the keyed MAC with a fixed key:
> >
> > T1 = mac(key, string | 0x01)
> > T2 = mac(key, T1 | string | 0x02)
> > T3 = mac(key, T2 | string | 0x03)
> >
> > Please let us know if this change resolves your concerns.
> >
> > Thanks,
> > 	Yaron
> >
> > On 08/17/2010 06:52 AM, Brian Weis wrote:
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> secdir mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/secdir
> >
>