eap Mailing List: Re: Re: keying issue 221: EMSK usage guidelines

[Florent Bersani (florent.bersani]

[Sending the mail Joe replied to and that did not reach the list]

Sorry to catch up late on this one :-( and many thanks to Joe and Pasi
for their very nice draft (draft-salowey-eap-key-deriv-02.txt)

Indeed, it is a follow-up of a question raised during Pasi's
presentation at IETF 59 in Seoul: should we not mandate the PRF used to
derive the AMSKs from the EMSK or not? (EAP issue 221 and slides
available at:
http://www.arkko.com/publications/eap/ietf-59/ietf59-eapkeyframework.ppt)

Though I understand that specifying a KDF from a well-now one (IKEv2's)
makes life a lot easier (just one option generally leads to
interoperability and choosing a good mandatory KDF prevents designers
from choosing a poor one), I feel a little bit concerned, probably for
two reasons:

1) First, EAP cautiously avoided specifying any cryptographic part so
far (I guess to preserve its extensibility since it is a framework) and
now we are just including such a part

2) Second, as the author of an EAP method that takes great pride in
using a single cryptographic primitive (AES-128), I am little bit biased
again people mandating that we use something depending on SHA1 ;-)

So, my first reaction would be: we should leave it up to EAP methods to
export such a KDF. And modify the text of section "The EAP AMSK Key
Derivation Function" to say something like:

"EAP methods MAY export a KDF to derive AMSKs from the EMSK.

In case, an EAP method does not export a KDF to derive MSKs from the
EMSK, the following KDF MUST (or SHOULD?) be used"

This tends to get me to my second reaction (I am bit slow, I know ;-)),
which is to try and investigate the benefits of suggesting such a
change, since it obviously complexifies things a little (possible
euphemism here). And a bunch of additional questions arises from this
second reaction:

1)  What behavior should we specify in case an EAP method does not
export a KDF, i.e. MUST or SHOULD in my proposed text? And if SHOULD is
the answer, then, what would be the behavior when an AMSK is requested
when there is no KDF? Possibly, an error I assume... TBD?

2) What is the interface to the KDF? I guess it would have to mimic the
K,L,D,O format specified in section "The EAP AMSK Key Derivation
Function". Thus, would it be possible to specify things a little bit
more, namely:

2.1) *On the key to the KDF*: The EMSK neatly fits into HMAC-SHA1 since
its length is precisely the one of the compression function of SHA1. In
case, you use a different KDF (e.g. the one specified in EAP-PSK), you
could have to add an intermediate processing step. So, should we say
that the exported KDF MUST take as input for K exactly 64 bytes - that
is the whole EMSK (I guess the answer is yes). By the way, wouldn't it
be nice to add a security warning on the AMSK, to say that although one
may derive say a 128 byte AMSK, one must not forget that it may come
from a 128 bit key (for instance the KDK portion of EAP-PSK's PSK)...
Should we provide a way to track down the "real" strength of an AMSK? (I
guess the answer to this one is no, because it would be too complicated)

2.2) *On the key label*: I would recommend specifying the length of this
item. I understand it may be a variable length non-empty string of ASCII
printable characters with no upper limit

2.3) *On the application data*: I did not find any precision on this
item. Would it be possible to clarify this, by saying something like
"the application data is a variable length possibly empty sequence of bits"?

2.4) *On the output length*: how is the output length encoded? does the
two byte output length encode the output length in bytes or in bits? (in
bytes I assume). Also, where does the limit of 255 iterations (hence
5100 bytes of key material) come from (IKEv2 must explain that somewhere
I think)? Should this limit be imposed to any other KDF? Another issue
close to that one: should we limit in any way the number of AMSK
(probably the sum of their length) that are derived from an EMSK (I
guess the answer is no since it would be too complicated but on the
other hand, it would be nice not to be able to burn down an EMSK
although this is highly improbable)

3) How would a peer and a server use an AMSK? This should probably not
be specified in any place. So I assume, we could have the following
scenario: a peer and a server derive an AMSK called the "AMSK transport
key" which would be used to transport any subsequent AMSK to the peer
without having the peer to derive them by himself. I just wanted to make
sure it is possible (I of course know some issued this scenario
obviously raises - the first one being that it makes the AMSK process
somehow useless - the new AMSKs could perfectly be chosen at random by
the server). I guess I wanted to suggest that we could add a word to say
that the AMSK derivation may not always involve the peer (To be honest,
I do not like my proposition very much ;-) - perhaps reformulate it to
say precisely that the whole point of the AMSKs is to allow the network
and the peer to derive them without having to have them sent between them)

Bottom line: I am not sure that it would be a good idea to allow EAP
methods to export their KDF but neither am I of the contrary. Anybody
has more inputs to help me make up my mind?

Hope my mental torture helped in some way.

Florent

Jari Arkko wrote:

> Joseph Salowey wrote:
>
> > [Joe] I don't think so, I think that the basic requirement is that both
> > parties in the EAP exchange can derive the same key name and that the
> > name is unique.  I'm suggesting the methods derive the key name in their
> > own way.  This could make use of nonces, it could send the key name as
> > authenticated data in the exchange, and there are probably other
>
>
> This would work for me. Others?
>
> > possibilities as well.  It might be OK to derive the key from the EMSK,
> > but a few people I mentioned this to disliked it.  In theory I suppose
> > it increases the chance that an attacker can precompute a partial
> > dictionary that will allow them to compromise some sessions on a network
> > (its difficult to attack a particular session, but it may increase the
> > possibility of compromising one arbitrary session out of many).  Perhaps
> > it is not a big deal, perhaps it is worse than I think it is.  
>
>
> Ok.
>
> --Jari
>
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap