eap Mailing List: Re: issue: make existing vs. handoff usage of AAA-Key clearer

[Florent Bersani (florent.bersani]

Jari Arkko wrote:

> Submitter name: Jari Arkko
> Submitter email address: jarkko [at] piuha.net
> Date first submitted: 10/5/2004
> Reference:
> Document: Keying Framework
> Comment type: 'T'echnical
> Priority: 'S' Must fix
> Section: 2.1, Appendix E
> Rationale/Explanation of issue:
>
> Section 2.1 says:
>
>    AAA-Key derivation is discussed in Appendix E; in
>    existing implementations the MSK is used as the AAA-Key.
>
> Then Appendix E says:
>
>    Where a AAA-Key is generated as the result of a successful EAP
>    authentication, the AAA-Key is set to MSK(0,63).
>
>    ... Where the backend
>    authentication server provides keying material to multiple
>    authenticators in order to facilitate fast handoff, it is highly
>    desirable for the keying material used on different authenticators to
>    be cryptographically separate, so that if one authenticator is
>    compromised, it does not lead to the compromise of other
>    authenticators. ... a key hierarchy derived from the EMSK, can be
>    used to provide cryptographically separate keying material for use in
>    fast handoff:
>
>    AAA-Key-A = MSK(0,63)
>    AAA-Key-B = PRF(... AAA-Key-A,B-Called-Station-Id,
>                Calling-Station-Id,length)
>
>    AAA-Key-E = PRF(... AAA-Key-A,E-Called-Station-Id,
>                Calling-Station-Id, length)
>
>    Where:
>    Calling-Station-Id  = STA MAC address
>    B-Called-Station-Id = AP B MAC address
>    E-Called-Station-Id = AP E MAC address
>    PRF = Some suitable pseudo-random function
>    length = length of derived key material
>
> What I worry about is an apparent set of two methods -- yet
> AAA-Key-A and AAA-Key are equivalent. The text could be
> also clearer about existing implementations that use fast
> handoffs -- would they be using MSK or AAA-Key-X? And is the
> AAA-Key-X method the recommended IETF method, or one
> proposal among many competing ones (people who work with
> fast handoff in IEEE could perhaps comment here). 

I have been participating to the IEEE 802.11r (previously known as FRFH 
study group) for a while.
Here is my view of the matter but please not that this is a *personal 
view*. I am not speaking in the name if IEEE 802.11r!
Please also note that I may have got things the wrong way :-( and that 
I'll try to be objective.

So, a Call for proposal has been issued by IEEE 802.11r and there are 
currently various competing proposals. Very preliminary material on some 
proposals is available as IEEE documents (from year 2004: doc 1127, 
1089, 1117 and 1114) and more detailed documentation from all proposals 
should be made available 10/15

It is not cleat at all that all (any?) proposals will use the AMSK 
scheme (for instance, they could very well create a whole new key 
hierarchy based on the PMK).
And anyway, I guess IEEE 802 will get in trouble here since as soon as 
they need communication with the AS, the "IP" world steps in, which some 
may object to at IEEE 802.
I am wondering how things will get working since it does not suffice to 
enhance the frame exchanges between STA  and AP but you also have to get 
the right key to the AP.
Of course AMSK may be a nice way to do so.

> Finally,
> "some suitable pseudo-random function" does not appear
> to be sufficient for interoperability :-)

i agree

> In any case, my suggestion would be to merge the two
> approaches and just say that this is the way AAA keys
> need to be generated; given that the first key is the
> same in any case, the remaining keys will be different
> whenever fast handoffs are used. And we could use hmac-sha1
> as is already done for AMSK generation.
>
> Note: if people think that keying for handoff isn't
> clear and stable at this time, we should avoid recommending
> any specific key hierarchy for that. If that's the case
> then I withdraw my issue, and suggest that we simply keep
> the textual parts of appendix E and remove the rest.

I think that restricting AAA-key to the fast handoff scheme is too 
narrow, all the more that keying for handoff is IMHO not stable (but 
there might be a cjicken and egg problem here as some handoff schemes 
may need the EAP side to be in place to be acceptable...)

We have already discussed the possible problems with the name AAA-key.
My view is that our definition is still pretty much closed (reference is 
made in the definition of AAA-key to an authenticator).
Why couldn't some application that is not authenticator based use EAP 
derived keys (i.e. specific AMSKs) that would be transported by some AAA 
protocol (so in a way wrapped in an AAA token)?
My answer is that e should stick to AAA-key derivation from the MSK and 
say that AMSKs may also be exported and transported in AAA tokens
Does that make sense?

> But assuming we can specify this now, here's the suggested
> text for Section 2.1:
>
>      AAA-Key derivation is discussed in Appendix E.
>
> and for Appendix E:
>
>    Where a AAA-Key is generated as the result of a successful EAP
>    authentication with the authenticator A, the AAA-Key is based on
>    the MSK:
>
>    AAA-Key   = MSK(0,63)
>
>    ... Where the backend
>    authentication server provides keying material to additional
>    authenticators in order to facilitate fast handoff, it is highly
>    desirable for the keying material used on different authenticators 
> B, C, ... to
>    be cryptographically separate, so that if one authenticator is
>    compromised, it does not lead to the compromise of other
>    authenticators. ... a key hierarchy derived from ... can be
>    used to provide cryptographically separate keying material for use in
>    fast handoff:
>
>    AAA-Key-B = prf(... AAA-Key,B-Called-Station-Id,
>                Calling-Station-Id,length)
>
>    AAA-Key-C = prf(... AAA-Key,C-Called-Station-Id,
>                Calling-Station-Id, length)
>
>    Where:
>    Calling-Station-Id  = STA MAC address
>    B-Called-Station-Id = AP B MAC address
>    C-Called-Station-Id = AP C MAC address
>    prf = hmac-sha1
>    length = length of derived key material
>
>    Here AAA-Key is derived during the initial EAP
>    authentication between the peer and authenticator A. Based on this
>    initial EAP authentication, the EMSK is also derived, which can be
>    used to derive AAA-Keys for fast authentication between the EAP peer
>    and authenticators B and C.  Since the EMSK is cryptographically
>    separate from the MSK, each of these AAA-Keys is cryptographically
>    separate from each other, and are guaranteed to be unique between the
>    EAP peer (also known as the STA) and the authenticator (also known as
>    the AP).
>
> --Jari
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap