Subject: RE: [eap] Re: keying issue 221: EMSK usage guidelines

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 18 Mar 2004 16:38:39 -0800

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
>> [email-masked] http://mail.frascone.com/mailman/listinfo/eap

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Fri, 19 Mar 2004 03:28:35 +0100

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

>independence between the keys to reduce this problem.
I totally agree with you!

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

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

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

>>bytes I assume).
So do I ;-) Do you think this should be explicitly added?

>> Also, where does the limit of 255 iterations (hence
I had figured that :-)

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

>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
I agree and I'll try and provide some input on this

>classify them as AMSKs (perhaps EAMSKS :-).
>
I agree

> At one point I had a draft on
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.

>compact implementations to reduce the number of cryptographic primitives
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 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

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 18 Mar 2004 21:24:36 -0800

Hi Florent, 

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

Joe

> A few more comments in-line

<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
>> [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. 
>> 
>> 
> *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

[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

[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] yes.

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

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