Subject: [HOKEY] FW: [Cfrg] Question on key size reduction for Cipher-based PRFs and MACs

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Jul 2007 15:17:36 -0700

Folks,
Here is some feedback from CFRG on key size reduction.  The rIK in
draft-ietf-hokey-erx is currently derived to be the same length as its
parent key and can hence be 64bytes or longer.  For use with hash-based
integrity algorithms, we recommend that the key be first hashed to
reduce the size of the key before generating the MAC (pretty standard
operation). For cipher-based integrity algorithms, in order to allow
cases where the device does not have a hash-based algorithm, the draft
currently has an approach using the cipher-based algorithm itself, based
on RFC4615.  

But, based on David's recommendations below, I think we should stick to
recommending reduction of the key size by hashing the key in all cases.
I don't think this is restrictive - our default PRFs are all
HMAC-SHA-256 anyway; so, requiring a hash algorithm support doesn't seem
to be a big deal to me.  

Any other thoughts? 

Vidya

> -----Original Message-----
> From: David Wagner [mailto:[email-masked]] 
> Sent: Thursday, July 12, 2007 1:44 PM
> To: Narayanan, Vidya
> Cc: David Wagner; [email-masked]
> Subject: Re: [Cfrg] Question on key size reduction for 
> Cipher-based PRFs and MACs
> 
> > In accordance with RFC4615, if the original key (VK) is longer or 
> > shorter than 128 bits, then the key, K, is derived by "applying the 
> > AES-CMAC algorithm using the 128-bit all-zero string as the 
> key and VK 
> > as the input message".
> 
> Oh.  Well, I don't know of any theoretical basis for thinking 
> that this will work.  One standard way for expanding a key or 
> deriving session keys from a master key MK is that you use a 
> PRF with MK as the key and some constant string (e.g., all 
> zeros) as the input, and then you take as many bits from the 
> output of the PRF as you need.  This way you can derive many 
> subkeys from the master key MK as you want just by changing 
> that constant string.  Note that this is the reverse of what 
> you quote from RFC4615.
> 
> If you really want to derive only one key from MK, then 
> another strategy is to hash MK using a secure hash function 
> (e.g., SHA256).
> If the key is too short, that's what I'd recommend.
> 
> Perhaps RFC4615 is trying to do something clever for the case where
> (a) the key VK is too short, and (b) they already have a 
> block cipher implemented in hardware and they don't want to 
> take up the extra die space to implement a hash function, 
> too.  In that case, well, all I can say is that what they are 
> recommending seems likely to work but it is not guaranteed or 
> justified by any theory or by any standard assumptions on 
> AES, so it is mildly dubious.  In practice it is highly 
> unlikely that this crypto scheme will be the weakest link in 
> your system overall, so I may be arguing about the number of 
> angels that can fit on the head of a pin -- but at the same 
> time this is not the best possible practice and so I would 
> probably not use this scheme except where necessary (e.g., 
> applications where I really cannot use a hash function and I 
> cannot get a longer key).  For instance, I don't think this 
> trick is likely to be justified in most software 
> applications, because it's easy enough to just use some 
> standard library implementation of SHA256 and there's usually 
> little cost in doing so.
> 
> -- David
> 

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 12 Jul 2007 17:50:26 -0700 (PDT)

Hi Vidya,

  We already require support for HMAC-SHA-256 so the ability to use the
prf from the EAP method provides a complication for dubious benefit. If
we just say that the prf is based on HMAC-SHA-256 and be done with it
then the need to reduce the key goes away.

  Or we could say:

  rIK || rRK = prf+(EMSK, "EAP re-auth blah blah blah")

where len(rIK) = length of integrity algorithm being used, len(rRK) =
len(EMSK) and lop off any remainder. And no change to rMSK derivation.
That makes the key hierarchy slightly different but so what:

      EMSK
       |
    |------|
   rIK    rRK
           |
        |---------|
      rMSK1 ... rMSKn

  While we're on the subject of keys, what is the point of having
an rRK_name and rMSK_name? They aren't being used.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 12 Jul 2007 22:07:40 -0700

Hi Dan,

> 
>   Hi Vidya,
> 
>   We already require support for HMAC-SHA-256 so the ability 
> to use the prf from the EAP method provides a complication 
> for dubious benefit. If we just say that the prf is based on 
> HMAC-SHA-256 and be done with it then the need to reduce the 
> key goes away.
> 

Using the prf from the EAP method basically provides for algorithm
agility, which otherwise won't be available.  I'm not sure how hard that
is to use, since it requires passing of the algorithm used from the
method to the EAP layer.  We could probably also introduce algorithm
agility using the ERP bootstrapping exchange - I need to think about
that further. 

> len(EMSK) and lop off any remainder. 

If the integrity algorithm that is going to be used is known to the
server ahead of time, we can certainly do that (and we can do that even
coming from the rRK).  But, the issue here is that the peer will
indicate the algorithm used, in the EAP Initiate Re-auth message.  But,
the rIK and rIKName should be available at the server before the EAP
Initiate Re-auth message can be processed.  That is why the rIK is
currently set to be a longer key that can later be reduced to the
required size.  But, as long as we say the key is hashed to the
appropriate size before use, it looks like that would be fine. Do you
agree? 

>And no change to rMSK derivation.
>   While we're on the subject of keys, what is the point of 
> having an rRK_name and rMSK_name? They aren't being used.
> 

Yes, that is true :)  But, the AAA key management document and even the
EMSK hierarchy document is recommending that any key derived must have a
key name and so, these were introduced.  I do agree that these are
pointless, especially the rRKName.  I have no problem getting rid of it.

Vidya

> > parent key and can hence be 64bytes or longer.  For use with 
> > hash-based integrity algorithms, we recommend that the key be first 
> > hashed to reduce the size of the key before generating the 
> MAC (pretty 
> > standard operation). For cipher-based integrity algorithms, 
> in order 
> > to allow cases where the device does not have a hash-based 
> algorithm, 
> > the draft currently has an approach using the cipher-based 
> algorithm 
> > itself, based on RFC4615.
> >
> > But, based on David's recommendations below, I think we 
> should stick 
> > to recommending reduction of the key size by hashing the 
> key in all cases.
> > HMAC-SHA-256 anyway; so, requiring a hash algorithm support doesn't 
> > seem to be a big deal to me.
> >
> > Any other thoughts?
> >
> > Vidya
> >
> >> Oh.  Well, I don't know of any theoretical basis for thinking that 
> >> this will work.  One standard way for expanding a key or deriving 
> >> session keys from a master key MK is that you use a PRF with MK as 
> >> the key and some constant string (e.g., all
> >> zeros) as the input, and then you take as many bits from 
> the output 
> >> of the PRF as you need.  This way you can derive many subkeys from 
> >> the master key MK as you want just by changing that 
> constant string.  
> >> Note that this is the reverse of what you quote from RFC4615.
> >>
> >> If you really want to derive only one key from MK, then another 
> >> strategy is to hash MK using a secure hash function (e.g., SHA256).
> block cipher 
> >> implemented in hardware and they don't want to take up the 
> extra die 
> >> space to implement a hash function, too.  In that case, 
> well, all I 
> >> can say is that what they are recommending seems likely to 
> work but 
> >> it is not guaranteed or justified by any theory or by any standard 
> >> assumptions on AES, so it is mildly dubious.  In practice it is 
> >> highly unlikely that this crypto scheme will be the 
> weakest link in 
> >> your system overall, so I may be arguing about the number 
> of angels 
> >> that can fit on the head of a pin -- but at the same time 
> this is not 
> >> the best possible practice and so I would probably not use this 
> >> scheme except where necessary (e.g., applications where I really 
> >> cannot use a hash function and I cannot get a longer key).  For 
> >> instance, I don't think this trick is likely to be 
> justified in most 
> >> software applications, because it's easy enough to just use some 
> >> standard library implementation of SHA256 and there's 
> usually little 
> >> cost in doing so.
> >>
> >> -- David
> >>
> >