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

[Joseph Salowey (jsalowey]

Hi Florent,

Thanks for you comments, responses inline below:

Florent Bersani wrote:
> 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-eapkeyfra
> mework.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
> 

[Joe] EAP generates key material, but leaves it open as to how you use it.
This is good, but it can leave to problems if the usage of keys is not
coordinated, the same key can be used for two different purposes which can
lead to problems.  A good key derivation framework provides computation
independence between the keys to reduce this problem.


> 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 ;-)
> 

[Joe] OK I understand this, perhaps there is a way to work around this
problem. 

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

[Joe] If we choose to have a variable KDF I agree that it should have a
consistent interface.

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

[Joe] The EMSK seems to be reasonable, but if you are making this internal
to the method, then it doesn't matter as long as both sides agree. 

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

[Joe] This is definitely a security consideration. Yes, deriving the "real"
strength is a bit complicated and probably controversial as well. 

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

[Joe] OK, what do you think would be a good upper limit, 50 chars?
 
> 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"?
> 

[Joe]I think so. Should we limit this length as well?

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

[Joe] I believe it should be bytes.

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

[Joe] there is a one byte counter in the KDF that will wrap. 

> Should this limit be imposed to any other KDF?

[Joe] I don't see any reason why not.  5100 bytes is lots of key material. 

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

[Joe] In general I think the problem is small, but it has not been
quantified.  Some discussion of this probably belongs in security
considerations along with key strength discussion. 

> 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)
>
 
[Joe] One could define such an application, but I think the subsequent AMSKs
you derive in a new way fall under some other specification and I would not
classify them as AMSKs (perhaps EAMSKS :-). At one point I had a draft on
using TLVs protected with AMSK to extend the EAP conversation and add
features, but it has expired, if you want I can send you a copy. 


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

[Joe] I think that it is important to have a coordinated way to derive keys.
To this you need a KDF with a standard interface like the one defined in the
draft. While EAP methods that derive keys have internal KDFs they typically
do not have an interface like the one defined so they would have to be
modified in any case.  

Perhaps a better solution is to take the KDF construction defined in the
document and allow for the PRF to be specified independently (IKEv2 does
this).  This way you can use AES as the PRF instead of HMAC-SHA1. 

The difficulty is how to decide which PRF to use.  Perhaps this should be
attached to the method, AES methods use the AES PRF defined for IKEv2,
methods that use SHA1 use HMAC-SHA1 other make a choice.  Some methods in
the future may allow you to negotiate this.  The rule could be use SHA1
unless a method specification specifies otherwise.  

The consistency in the construction would allow implementations with EAP
frameworks to do the derivation in the framework without having to keep the
method state around and it would allow methods that are trying to provide
compact implementations to reduce the number of cryptographic primitives
involved.  

> Hope my mental torture helped in some way.
> 
[Joe] I think so, but then again I tend to be tortured. 


> 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