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

[Joseph Salowey (jsalowey]

Hi Florent, 

This has been a good discussion, more comments in line.  

Joe

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

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

[Joe] So for the most part we share the same view.  My thinking was that in
an EAP framework and EAP method would hand over the MSK and EMSK to the
framework.  The framework would then be responsible for generating and
controlling AMSKs.  I do think that it would be good for a framework to
restrict which callers can request which AMSKs and that the EMSK should not
be kept around longer than it needs to be.  This may not be possible in some
cases, but may be required in others.  How the AMSKs are distributed and
controlled is out of scope of EAP, but some suggestions may be nice. 

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

[Joe] Yes, this is good, I think it is worthwhile to perhaps mention in more
than one place.

<snip>

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

[Joe] yes.


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

[Joe] I would appreciate this. 

<snip>

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

[Joe] I think we are thinking the same, but if you think there are still
differences the we should start a separate thread. I'd like to make sure
that the EMSK (and the MSK) is not handled lightly.  I realize that it may
be difficult for implementations to enforce who can obtain which AMSKs and
how long EMSK is maintained, but I think it is desirable. How the
enforcement is done and how keys are distributed is beyond the scope of
this, but it may be important to consider such things as they are part of
the system.