Subject: [eap] issue: make existing vs. handoff usage of AAA-Key clearer

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 14:18:10 +0300

Submitter name: Jari Arkko
Submitter email address: [email-masked]
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). Finally,
"some suitable pseudo-random function" does not appear
to be sufficient for interoperability :-)

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.

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

---

From: Florent Bersani <[email-masked]>
Date: Tue, 05 Oct 2004 16:59:02 +0200

Jari Arkko wrote:

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

i agree

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 05 Oct 2004 17:52:31 -0700

The current text is geared for generating keys and pushing them to other
authenticators in advance (prior to handover). I'd recommend the other
mechanism, namely pulling keys from a new authenticator in response to a
handover (reactive) is also covered in this section.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jari Arkko
> Sent: Tuesday, October 05, 2004 4:18 AM
> To: [email-masked]
> Subject: [eap] issue: make existing vs. handoff usage of AAA-Key
clearer
>     desirable for the keying material used on different authenticators
B,
> C, ... to

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Oct 2004 15:40:47 +0300

Florent Bersani wrote:

> 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). 
...
> may need the EAP side to be in place to be acceptable...)

I'm starting to think that the document should restrict
itself to saying AAA-Key = MSK(0..63) in the body of the
document, and allocate an appendix for discussing requirements
(not specifics) of fast handoff key generation... leaving
the rest for researchers & future work. Section 4 could go
there as well.

--Jari