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

[Florent Bersani (florent.bersani]

Hi Joe,

Thanks for taking the time to read and reply to my metaphysical concerns.

I agree with the solution you proposed (to allow the prf negotiation 
with the fixed prf+ construction, using IKEv2 notations)

A few more comments in-line

Florent

Joseph Salowey wrote:

> 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.
>  
I totally agree with you!

>  
>
> > 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. 
>  
Well I didn't view this as internal to the method.

*My view*: The method after successfully completing would hand over to
the rest of the world its decision (success), the keying material
available (MSK and EMSK) and possibly the KDF. Then the EMSK and the KDF
would have to be handled by a kind of server capable of producing AMSKs
upon request.

*My understanding of your view*: It seems like your view was that the
necessary AMSKs were instantly derived (within the method?) and handed
over to the relevant applications. This scenario would not need the EMSK
to be exported but only the AMSKs. I think I am misunderstanding you
since I find this scenario a bit too restrictive: a peer and a server
might not know in advance which EMSK they would need.

I guess this "AMSK server" from my view is out of the scope of EAP
(implementation details or other protocol to specify how they request
AMSKs...) but I just wanted to know if I was off the rocket.

>  
>
> > 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. 
>  
So perhaps, adding some text in section "EAP AMSK Key Derivation" after
"The EAP EMSK usage guidelines provide a means for generating multiple
application-specific master keys (AMSKs). These AMSKs are then used to
derive transient session keys (TSKs), which are used as actual ciphering
keys. This allows multiple applications to use keys independently
derived from the EAP method." like "It must be remembered that the
effective strength of the derived AMSK depend on the keys used to
generate it and therefore that it may be far less than its actual
length"  or include that in the security considerations section, which
you seem to favor.

BTW, a very stupid comment: will it be clear to everybody that we are
deriving symmetric keys or  do we need to clarify that (tentative
answer: yes, it is obvious and we don't need to do anything)

>  
>
> > 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?
>  
Yes, it should be enough :-)
In fact I had no precise idea in mind and wasn't even thinking of an
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"?
> >
> >    
>
> [Joe]I think so. Should we limit this length as well?
>  
No idea, I would they yes to avoid problems with implementations.
I've taken a look at draft-ietf-ipsec-ikev2-12.txt and I did not find
anything regarding this point since they don't talk of optional
application data.

>  
>
> > 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).
So do I ;-) Do you think this should be explicitly added?

> > 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. 
>  
I had figured that :-)

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

>  
>
> > 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. 
Well I've just went into it for "my" KDF (see reference [SOBMO] of my
draft EAP-PSK) and I'll include this analysis in the upcoming version of
EAP-PSK (02)

> Some discussion of this probably belongs in security
> considerations along with key strength discussion. 
>  
I agree and I'll try and provide some input on this

>  
>
> > 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 :-).
I agree

> 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. 
>  
I guess you are referring to draft-salowey-eap-protectedtlv-02.txt. I'll
be more than happy to share some thoughts on it with you offline.

>  
>
> > 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.  
>  
I like the way you propose to solve this and it makes sense to me to
take the little bit more you suggest of IKEv2 (allowing the prf
negotiation but not the prf+ construction, hence saving some time and
hair for implementors) :-))

I would suggest also agree to keep the situation simple the situation by
mandating that an EAP method may specify statically which prf it intends
to use - to avoid burdening the methods with mandatorily having to
negotiate the prf (which some may want to do in the future, as you say).

My only remaining concern is the way the AMSK get generated ("the AMSK
server" I referred to in the beginning of the mail) but this belongs
probably to another thread. Do you think it's worth opening one on it?

>  
>
> > Hope my mental torture helped in some way.
> >
> >    
> [Joe] I think so, but then again I tend to be tortured. 
>  
I don't think so, the solution you suggested (negotiation prf with the
fixed prf+ construction) makes a lot of sense to me

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