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

["Dan Harkins" <[e-mail]>]

  Hi Scott,

On Tue, September 7, 2010 2:57 pm, Scott Fluhrer (sfluhrer) wrote:
>
>
>> -----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?

  Yes, that would be a bad idea. But the alternative was to use a key
of all zeros for PRF and then nobody contributes anything. I think it's
better to use the identities as "salt" and if this means just using
HKDF with some HMAC of a hash function (and not a block cipher) then
so be it. But I'm just a contributor not an author :-)

>>   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?

  I guess. Honestly I'm fine with this and the resolution Yaron presented.
It's better than the -07 version.

  But my original comments were essentially, why not just use HKDF.
There's this new standard for extraction-expansion key derivation that
had alot of cryptographic analysis and it has a rigorous proof behind it
when used in the way it is specified and instead of just using that,
EAP-EKE is adding yet another negotiable option-- "prf"-- that determines
whether you build something that will look like the standard or whether it
will look like slightly different. Are we assured that the extraction and
pseudo-random properties of "prf" with a value of <RESERVED TO IANA> are
appropriate for use in this HKDF-like construct? Even if we are, is there
a problem being solved here or a reason why HKDF as defined is not enough?

  Can't you just say, use HKDF in 5.1 to distill whatever entropy is in
the password and generate an encryption key to encrypt the exponentials;
use HKDF in 5.2 to distill the entropy from g^(x_s * x_p) mod p
and generate Ke and Ki; and then, use HKDF in 5.5 to distill the entropy
from SharedSecret and derive MSK and EMSK?

  Dan.