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

From: Yaron Sheffer <[email-masked]>
Date: Mon, 06 Sep 2010 20:48:13 +0300

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 7 Sep 2010 14:24:51 -0700 (PDT)

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.

  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.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 7 Sep 2010 16:52:29 -0700 (PDT)

Hi Scott,

On Tue, September 7, 2010 2:57 pm, Scott Fluhrer (sfluhrer) wrote:
>
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:[email-masked]]
>> Sent: Tuesday, September 07, 2010 5:25 PM
>> To: Yaron Sheffer
>> Cc: Brian Weis (bew); Dan Harkins; [email-masked]; draft-sheffer-emu-
>> [email-masked]; Russ Housley; Tim Polk
>> Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07
>>
>>
>>   Hi Yaron,
>>
> 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 :-)

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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 7 Sep 2010 14:57:07 -0700

> >> payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm
going
> to

---

From: Brian Weis <[email-masked]>
Date: Fri, 10 Sep 2010 11:17:09 -0700

Hi Yaron,

That approach below looks good to me.

Regarding including the identities in the salt: I do note that the  
HKDF paper referenced by RFC 5869 states several times that the salt  
should be either a constant value (e.g., "\0"), or a value chosen at  
random, which I presume means that different values will be uniformly  
distributed over the size of the salt. I don't see a clear explanation  
in the paper why this is so (other than a hint in Section 9 that a  
random salt "prevents building universal dictionaries"). Since the  
identities aren't going to be random so it may be better to simply use  
the static value.

Thanks,
Brian

On Sep 6, 2010, at 10:48 AM, Yaron Sheffer wrote:

> 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)
> PRF is truncated or zero-padded if necessary when used to derive  
> KEY. Neither is needed when using an HMAC function for the MAC.
>
> 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.
>
>> going to

-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]