Subject: [eap] EAP Key Binding Discussion

From: "Walker, Jesse" <[email-masked]>
Date: Sat, 16 Apr 2005 04:40:37 -0700

On Friday we had a conference call to discuss 802.11r keying that
included Tony Braskich, Nancy Cam-Winget, Steve Emmeot, Paul Funk, Russ
Housley, Henry Ptasinski, Kapil Sood, and myself. An issue came up on
the call regarding the EAP keying draft which should be discussed here.
I don't know if everyone from the 802.11r group is on the EAP mailing
list, so please reply to all.

The core problem has been discussed many times before. Let us begin by
setting the context. One of the goals of the EAP keying draft is to
deliver a session key that an EAP Peer and a NAS can use to secure a
session between them. The EAP keying draft defines a key hierarchy
expressly for this purpose. The details of the hierarchy are method
specific, but for EAP-TLS it appears thusly:

            TMS

             |

        +----+----+

        |         |

       MSK       EMSK

        |

        |

     AAA-Key

The TMS is an EAP method specific "session key" constructed between the
EAP Peer and the EAP Server. From this the MSK and EMSK are derived,
again in an EAP method specific manner. The AAA-Key is derived from the
MSK and delivered to the NAS. The AAA-Key is then used as the session
key between the EAP Peer and the NAS.

The issue has always been how to bind the AAA-Key to this NAS and this
EAP Peer for this session. The NAS needs to know that this AAA-Key is
for this <NAS, EAP Peer> pair for this session, and the EAP Peer
likewise needs to know the same thing. The only party that is in a
position to inform both parties of this binding is the EAP Server. The
EAP Peer can trust the EAP Server to make this assertion, because it has
authenticated the EAP Server (at least in the case where the EAP method
provides mutual authentication), and the NAS can trust the EAP server to
make this assertion, because it has some channel with the EAP server
presumed to be secure.

I think everyone agrees this issue is solved for the NAS, as mechanisms
exist to allow the EAP Server to attest to the binding. It could, for
instance, deliver the EAP Peer's authenticated identity Peer-ID to the
NAS with the AAA-Key along with the EAP Success message; abstractly:

      EAP Server --> NAS:  EAP-Success || AAA-Key || Peer-ID

The NAS can then check whether it is talking with the right EAP Peer
using a 

protocol that would require the EAP Peer to assert its identity:

      NAS --> EAP Peer:  Challenge

      EAP Peer --> NAS:  f(AAA-Key, Challenge || Peer-ID)

      etc.

The function f used in this protocol would be selected so that it would
be 

computationally infeasible for the EAP Peer to produce the right
response without knowing the AAA-Key, the Challenge value, and the
Peer-ID value. And if exposure of the Peer-ID to the NAS is deemed
onerous, then we can certainly replace it in the above with another
session specific function of Peer-ID, e.g.,

     g(TMS, Peer-ID)

for some suitable function g. The EAP keying draft could specify that
delivery of (a function of) the Peer-ID with the session key is a
requirement, and we would be done with the key binding for the NAS.

The issue we have never been able to resolve successfully has been how
to provide the same attestation by the EAP Server of the correct NAS to
the EAP Peer, i.e., how does the EAP Server assert to the EAP Peer the
correct NAS to which the session key AAA-Key is bound? There is no
obvious channel within EAP itself for delivering this assertion.

The question from our conference call is whether that the assertion
could come from the key derivation. In 802.11r, for instance, we could
require the NAS to advertise its NAS-ID to the EAP Peer as part of the
802.11 discovery protocol:

     NAS --> *:  NAS-ID

Then the EAP Peer would know the NAS-ID being asserted by the NAS. The
EAP Server also knows the NAS-ID associated with an EAP transaction
through the normal instantiations of the EAP transport between the NAS
and the EAP Server. The EAP Server could then make the assertion of NAS
identity through the AAA-Key derivation:

     AAA-Key := kdf(MSK, NAS-ID)

where kdf is a suitable key derivation function. The EAP Peer would
perform the same key derivation. If the EAP Server delivered the AAA-Key
to some other NAS other than the one that advertised NAS-ID, then the
EAP Peer could detect this, because its session would fail, as the EAP
Server would have used the identifier NAS-ID' for that NAS instead.

On first blush it appears that this kind of mechanism would finally
close the binding issues with EAP keying.

Of course life is never that simple, because the key hierarchy above is
already in place, and doesn't include the derivation AAA-Key := kdf(MSK,
NAS-ID). Therefore, we would have to do something else, in order to
avoid breaking already deployed equipment. A candidate might be the
EMSK, which is currently unused. We could define something like

     Bound-AAA-Key := kdf(EMSK, "bound EAP session key || SID || NAS-ID)

where SID is the EAP session identifier, and deliver the Bound-AAA-Key
to the NAS along with the AAA-Key. We could deliver this with a session
specific EAP Peer identity

     Peer-Session-ID := hash(SID || Peer-ID)

And we could fix kdf and hash for all EAP methods, e.g., take hash to be
the first 96 bits of SHA-256, and kdf as TLS-PRF. The Bound-AAA-Key id
would then be NAS-ID || Peer-Session-ID. We don't, of course, have to
use the EMSK for this function, but I have used it for concreteness.

This mechanism requires that a NAS find some way to advertise its NAS-ID
to EAP peers, and it requires a few new attributes exchanged between the
NAS and EAP Server. It leaves the existing key hierarchies intact, but
provides a bound key for new applications that desire a bound key. It
seems to put to rest the security issues with the existing key
hierarchy, by giving the EAP Server some way to attest to the EAP Peer
the NAS which should possess the key.

What do people thing? Would this be a productive addition to the EAP
keying draft?

-- Jesse

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 18 Apr 2005 09:01:58 -0700

> -----Original Message-----
> 	From: Walker, Jesse [mailto:[email-masked]] 
> 	Sent: Saturday, April 16, 2005 4:41 AM
> 	To: [email-masked]
> 	Cc: Paul Funk; Henry Ptasinski; Steve Emeott; Russ 
> Housley; Nancy Winget
> 	Subject: [eap] EAP Key Binding Discussion
> 	

<snip>

> 
> 	            TMS
> 
> 	             |
> 
> 	        +----+----+
> 
> 	        |         |
> 
> 	       MSK       EMSK
> 
> 	        |
> 
> 	        |
> 
> 	     AAA-Key
> 
> 	 
> 
> 	The TMS is an EAP method specific "session key" 
> constructed between the EAP Peer and the EAP Server. From 
> this the MSK and EMSK are derived, again in an EAP method 
> specific manner. The AAA-Key is derived from the MSK and 
> delivered to the NAS. The AAA-Key is then used as the session 
> 	The issue has always been how to bind the AAA-Key to 
> this NAS and this EAP Peer for this session. The NAS needs to 
> know that this AAA-Key is for this <NAS, EAP Peer> pair for 
> this session, and the EAP Peer likewise needs to know the 
> same thing. The only party that is in a position to inform 
> both parties of this binding is the EAP Server. The EAP Peer 
> can trust the EAP Server to make this assertion, because it 
> has authenticated the EAP Server (at least in the case where 
> the EAP method provides mutual authentication), and the NAS 
> can trust the EAP server to make this assertion, because it 
> has some channel with the EAP server presumed to be secure.
> 
>

[Joe] We need to be a little careful here so we don't load too much
application specific knowledge into EAP methods.  In this description
there should be an application independent portion of the EAP server and
an application aware portion of the EAP server (may be the AAA logic).  
 	 
> 
> 	I think everyone agrees this issue is solved for the 
> NAS, as mechanisms exist to allow the EAP Server to attest to 
> the binding. It could, for instance, deliver the EAP Peer's 
> authenticated identity Peer-ID to the NAS with the AAA-Key 
> along with the EAP Success message; abstractly:
> 
> 	 
> 

[Joe] In this scheme what is the Peer-ID?  I'm not sure that the Peer-ID
in this protocol is the same as the Peer-ID that is the authenticated
name.  If it is not then this mechanisms may run into problems.   Also
is it the identity that is important?  Perhaps it would be possible to
use a scoping or an authorization attribute instead.
 	 
> 
> 	The NAS can then check whether it is talking with the 
> right EAP Peer using a protocol that would require the EAP Peer to
assert its identity:
> 	The function f used in this protocol would be selected 
> so that it would becomputationally infeasible for the EAP Peer to
produce 
> the right response without knowing the AAA-Key, the Challenge 
> value, and the Peer-ID value. And if exposure of the Peer-ID 
> to the NAS is deemed onerous, then we can certainly replace 
> it in the above with another session specific function of 
> Peer-ID, e.g.,
> 
> 	 
> 
> 	     g(TMS, Peer-ID)
>
> 	 
> 
> 	for some suitable function g. The EAP keying draft 
> could specify that delivery of (a function of) the Peer-ID 
> with the session key is a requirement, and we would be done 
> with the key binding for the NAS.
> 

[Joe] This type of value is not exported by EAP right now and I'm not
sure it should be.  If the Peer-ID is the identity authenticated by EAP
then it may be possible.  IF not then I don't think this is a good
construct since it requires application specific knowledge in the EAP
method better to use a key derived from the EMSK hierarchy.  

<snip>

> 	 
> 
> 	Of course life is never that simple, because the key 
> hierarchy above is already in place, and doesn't include the 
> derivation AAA-Key := kdf(MSK, NAS-ID). Therefore, we would 
> have to do something else, in order to avoid breaking already 
> deployed equipment. A candidate might be the EMSK, which is 
> currently unused. We could define something like
> 
> 	 
> 
> 	where SID is the EAP session identifier, and deliver 
> the Bound-AAA-Key to the NAS along with the AAA-Key. 

[Joe] Its not currently clear to me that you need to include the binding
in the key derivation. Why can't the server just send the NAS-ID to the
peer? I need to think about it more.  

> We could 
> deliver this with a session specific EAP Peer identity
> 
> 	 
> 
> 	And we could fix kdf and hash for all EAP methods, 
> e.g., take hash to be the first 96 bits of SHA-256, and kdf 
> as TLS-PRF. The Bound-AAA-Key id would then be NAS-ID || 
> Peer-Session-ID. We don't, of course, have to use the EMSK 
> for this function, but I have used it for concreteness.
> 

[Joe] I had a proposal for a KDF for EAP EMSK derivation that was merged
into the EAP keying framework and then removed.  I expect we could issue
a new companion draft (EAP-keying extensions) soon if that would help
add clarity to this issue.  I think the the peer-session-ID is an
application specific thing (802.11).  
	 
> 
> 	This mechanism requires that a NAS find some way to 
> advertise its NAS-ID to EAP peers, and it requires a few new 
> attributes exchanged between the NAS and EAP Server. It 
> leaves the existing key hierarchies intact, but provides a 
> bound key for new applications that desire a bound key. It 
> seems to put to rest the security issues with the existing 
> key hierarchy, by giving the EAP Server some way to attest to 
> the EAP Peer the NAS which should possess the key.
> 	 
> 
> 	What do people thing? Would this be a productive 
> addition to the EAP keying draft?
> 
[Joe] I expect that some of this would go into the EAP-Keying extensions
draft. 

> 	-- Jesse

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 18 Apr 2005 16:26:57 -0500

Hi Jesse,

Very timely email!

 I am running into similar issues with 802.16e. The problem of assertion of the NAS ID by the EAP server has a partly practical resolution through the fact that the AAA key has to be sent in a secure manner to the NAS and not over EAP but over a AAA protocol between the EAP/AAA server and NAS. I am hoping that nobody sends the AAA key to the NAS unencrypted, which means you are either using the RADIUS shared secret (bound to NAS IP address) or Diameter over an IPsec/ TLS with the NAS.

However, I have another problem with sending an unbound AAA key to the NAS and that is "handover". Say you are dealing with multiple Base stations/ AP/ what have you. You would want to do the EAP authentication only once, derive the EAP master key and then not have to do the full EAP-XXX (e.g. EAP-TLS) every time you move. If you push your "golden chip" (AAA key) to the first NAS (AP), then you are out of luck, especially if you did not mean to have each AP know about the session keys the peer shares with other APs. Since practically all it takes is for the previous AP to listen to the nonce exchanges that the peer is doing with the new AP and based the AAA-key that it still has, find the session keys between peer and new AP.

I came up with same resolution as you did. You called it bound-AAA key, I called it AAA-BS key (I think I saw this under a handover section in one the EAP key managment drafts). So the point is the AAA-key is not pushed to the NAS. Instead both the peer and EAP/ AAA server calculate a AAA-BS key that is bound to that base station. The EAP server only pushes the AAA-BS key to that BS (NAS). The AAA key to AAA-BS key is straightforward if you know the BS ID, peer ID and other things, as long as you know AAA key, of course, so the peer and AAA server both can do it. The handshakes happen based AAA-BS rather than AAA-key. But now, the BSs cannot derive the session keys for other BSs.

BR,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Walker, Jesse
Sent: Saturday, April 16, 2005 6:41 AM
To: [email-masked]
Cc: Paul Funk; Henry Ptasinski; EMEOTT STEVE-CSE005; Russ Housley; Nancy Winget
Subject: [eap] EAP Key Binding Discussion

On Friday we had a conference call to discuss 802.11r keying that included Tony Braskich, Nancy Cam-Winget, Steve Emmeot, Paul Funk, Russ Housley, Henry Ptasinski, Kapil Sood, and myself. An issue came up on the call regarding the EAP keying draft which should be discussed here. I don't know if everyone from the 802.11r group is on the EAP mailing list, so please reply to all.

The core problem has been discussed many times before. Let us begin by setting the context. One of the goals of the EAP keying draft is to deliver a session key that an EAP Peer and a NAS can use to secure a session between them. The EAP keying draft defines a key hierarchy expressly for this purpose. The details of the hierarchy are method specific, but for EAP-TLS it appears thusly:

            TMS

             |

        +----+----+

        |         |

       MSK       EMSK

        |

        |

     AAA-Key

The TMS is an EAP method specific "session key" constructed between the EAP Peer and the EAP Server. From this the MSK and EMSK are derived, again in an EAP method specific manner. The AAA-Key is derived from the MSK and delivered to the NAS. The AAA-Key is then used as the session key between the EAP Peer and the NAS.

The issue has always been how to bind the AAA-Key to this NAS and this EAP Peer for this session. The NAS needs to know that this AAA-Key is for this <NAS, EAP Peer> pair for this session, and the EAP Peer likewise needs to know the same thing. The only party that is in a position to inform both parties of this binding is the EAP Server. The EAP Peer can trust the EAP Server to make this assertion, because it has authenticated the EAP Server (at least in the case where the EAP method provides mutual authentication), and the NAS can trust the EAP server to make this assertion, because it has some channel with the EAP server presumed to be secure.

I think everyone agrees this issue is solved for the NAS, as mechanisms exist to allow the EAP Server to attest to the binding. It could, for instance, deliver the EAP Peer's authenticated identity Peer-ID to the NAS with the AAA-Key along with the EAP Success message; abstractly:

The NAS can then check whether it is talking with the right EAP Peer using a 

      etc.

The function f used in this protocol would be selected so that it would be 

computationally infeasible for the EAP Peer to produce the right response without knowing the AAA-Key, the Challenge value, and the Peer-ID value. And if exposure of the Peer-ID to the NAS is deemed onerous, then we can certainly replace it in the above with another session specific function of Peer-ID, e.g.,

     g(TMS, Peer-ID)

for some suitable function g. The EAP keying draft could specify that delivery of (a function of) the Peer-ID with the session key is a requirement, and we would be done with the key binding for the NAS.

The issue we have never been able to resolve successfully has been how to provide the same attestation by the EAP Server of the correct NAS to the EAP Peer, i.e., how does the EAP Server assert to the EAP Peer the correct NAS to which the session key AAA-Key is bound? There is no obvious channel within EAP itself for delivering this assertion.

The question from our conference call is whether that the assertion could come from the key derivation. In 802.11r, for instance, we could require the NAS to advertise its NAS-ID to the EAP Peer as part of the 802.11 discovery protocol:

     NAS --> *:  NAS-ID

Then the EAP Peer would know the NAS-ID being asserted by the NAS. The EAP Server also knows the NAS-ID associated with an EAP transaction through the normal instantiations of the EAP transport between the NAS and the EAP Server. The EAP Server could then make the assertion of NAS identity through the AAA-Key derivation:

where kdf is a suitable key derivation function. The EAP Peer would perform the same key derivation. If the EAP Server delivered the AAA-Key to some other NAS other than the one that advertised NAS-ID, then the EAP Peer could detect this, because its session would fail, as the EAP Server would have used the identifier NAS-ID' for that NAS instead.

On first blush it appears that this kind of mechanism would finally close the binding issues with EAP keying.

Of course life is never that simple, because the key hierarchy above is already in place, and doesn't include the derivation AAA-Key := kdf(MSK, NAS-ID). Therefore, we would have to do something else, in order to avoid breaking already deployed equipment. A candidate might be the EMSK, which is currently unused. We could define something like

where SID is the EAP session identifier, and deliver the Bound-AAA-Key to the NAS along with the AAA-Key. We could deliver this with a session specific EAP Peer identity

And we could fix kdf and hash for all EAP methods, e.g., take hash to be the first 96 bits of SHA-256, and kdf as TLS-PRF. The Bound-AAA-Key id would then be NAS-ID || Peer-Session-ID. We don't, of course, have to use the EMSK for this function, but I have used it for concreteness.

This mechanism requires that a NAS find some way to advertise its NAS-ID to EAP peers, and it requires a few new attributes exchanged between the NAS and EAP Server. It leaves the existing key hierarchies intact, but provides a bound key for new applications that desire a bound key. It seems to put to rest the security issues with the existing key hierarchy, by giving the EAP Server some way to attest to the EAP Peer the NAS which should possess the key.

What do people thing? Would this be a productive addition to the EAP keying draft?

-- Jesse

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Apr 2005 14:55:52 -0700 (PDT)

>  I am running into similar issues with 802.16e. The problem of assertion of the NAS ID by the EAP server has a partly
> practical resolution through the fact that the AAA key has to be sent in
> a secure manner to the NAS and not over EAP but over a AAA protocol
> between the EAP/AAA server and NAS. I am hoping that nobody sends the
> AAA key to the NAS unencrypted, which means you are either using the
> RADIUS shared secret (bound to NAS IP address) or Diameter over an
> IPsec/ TLS with the NAS.

The RADIUS shared secret is not bound to the NAS IP address.  It is bound
to the RADIUS client IP address.  That means that there is no
cryptographic binding between the key and the NAS-ID in the case where a
proxy is present.

The problem is fixed in Diameter w/redirect since the NAS and AAA server
can communicate directly.

> However, I have another problem with sending an unbound AAA key to the NAS
> and that is "handover". Say you are dealing with multiple Base stations/
> AP/ what have you. You would want to do the EAP authentication only
> once,  derive the EAP master key and then not have to do the full
> EAP-XXX (e.g. EAP-TLS) every time you move. If you push your "golden
> chip" (AAA key) to the first NAS (AP), then you are out of luck,

Remember that a NAS may have multiple "ports" so that a NAS and an AP are
not the same thing.  The AAA-Key is provided to the NAS, and the EAP peer
authenticates with the NAS, not with a particular AP (port of the NAS).
As a result, assuming that the peer, NAS and AAA server are all in sync
about the definition of the NAS boundary, then it is possible to avoid
EAP re-authentication when moving between ports on a single NAS.

> especially if you did not mean to have each AP know about the session
> keys the peer shares with other APs.

Where the NAS has multiple ports, the APs (ports) of that NAS share a key
cache.  As a result, a AAA-Key sent to the NAS can be used by the peer to
attach to any port on that NAS.

As a result, re-authentication is only required when moving between NASes.
There are multiple ways this can be accomplished without excessive handoff
latency.  Some of the mechanisms that have been proposed include:

   1. EAP pre-authentication (already supported in 802.11i)
   2. Pre-emptive handoff
   3. Key Request

>Since practically all it takes is for the previous AP to listen to the
>nonce exchanges that the peer is doing with the new AP and based the
>AAA-key that it still has, find the session keys between peer and new AP.

If the old and new APs are both attached to the same NAS, why would it
need to do this?  If they are not attached to the same NAS, then they
can't be sharing a AAA-Key.

> I came up with same resolution as you did. You called it bound-AAA key,
> I called it AAA-BS key (I think I saw this under a handover section in
> one the EAP key managment drafts). So the point is the AAA-key is not
> pushed to the NAS.

In existing implementations, as well as in the pre-emptive handoff
proposal, the AAA-Key is pushed to the NAS.  In the Key-Request
proposal, my understanding is that it is pulled by the NAS from the AAA
server.

>Instead both the peer and EAP/ AAA server calculate a
>AAA-BS key that is bound to that base station. The EAP server only pushes
>the AAA-BS key to that BS (NAS). The AAA key to AAA-BS key is
>straightforward if you know the BS ID, peer ID and other things, as long
>as you know AAA key, of course, so the peer and AAA server both can do
>it. The handshakes happen based AAA-BS rather than AAA-key. But now, the
>BSs cannot derive the session keys for other BSs.

You are describing something which I don't believe is included in any of
the existing proposals.  If this is something that you're interested in
pursuing, the best way to go about it is to write a complete proposal for
how it would work, and then analyze it to see if conforms to the security
criteria in RFC 4017.  This would make it possible for the proposal to be
included in the EAP Key Management Extensions draft.

However, please understand that this is not something that is likely to be
completed in the 802.16e timeframe.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 28 Apr 2005 11:38:25 -0500

Hi Jari,

Thank you for taking the time and responding. I agree with most of the things you said, but reading your last comments, I think I need to clarify myself. The NAS does not tell the AAA server that it is the LKDC. It simply informs the AAA server which LKDC it wants the key materials to be sent.
We need a midlevel in the hierarchy between AAA server and NAS to keep the AAA-key at, generate AAABS keys for each NAS, but keep the AAA-key from the NAS to prevent the domino effect.

			AAA server
			/	|   \
		  LKDC1   LKDC2  LKDC3
		  / |  \	/|\  /|\
	    NAS1 NAS2 NAS3
 
Please note that in the suggested approach the KDCs are out of the EAP auth-path, which means the AAA server does not know where the KDC for a NAS and its neighbors are. That is why the NAS1 needs to send an AVP to AAA server including KDC1 ID (so AAA server does not have to keep NAS-KDC state and the network architecture can be flexible with load balancing).
The AAA server will send the AAA-key to a KDC only if it has a AAAserver-KDC SA to protect the AAA key.
For RADIUS we need a request/ response signaling started from KDC to get the AAA-key, which in turn means the NAS must send a trigger to the KDC (after EAP success possibly).
This way the round trip to AAA server is reduced to roundtrip to LKDC which can be collocated with local mobility manager.

All we are changing here is that we are saying "send the AAA key" to the KDC rather than to NAS. It is unconventional but is it less secure? I am not sure? It is more secure than just sending the AAA key to the first NAS.
But I appreciate all the help we can get with the threat analysis.

Madjid
-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, April 28, 2005 7:23 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Bernard Aboba'; [email-masked]
Subject: Re: [eap] Re: EAP key binding discussion

Thanks Madjid for describing the scenarios and possibilities!
Some comments below.

There appears to be multiple issues that we want to worry about
in the fast handoff case. We've discussed the domino effect; the
same key should not be usable more than in a single place.

Efficiency concerns might dictate that at least some lengthy authentication
procedure should not be repeated. Not sure if this fully applies
today, many EAP methods have support for fast reauthentication.

On the other, roundtrip concerns may still apply, particularly if
it is expected that the home AAA server is on the other side of
world.

Another issue is compatibility and deployment. The mechanisms
may require modifications at the access network, intermediate
AAA proxies or KDCs, or the home network. Changes to the home
network are in particular troublesome because you might need
to upgrade your AAA server just because someone is using a new
a roaming partner's new link layer with fast handoff support.

Protocol modifications are also an issue. Some things are easier
to add to RADIUS and Diameter than others. New AVPs are easy;
delivery to a new KDC might be harder. And how would we prevent
a NAS lying about being a KDC -- if we don't prevent this then we
are back to the domino effect. Or maybe not, but at the
moment I at least don't see all the impacts at the system level well
enough.

Some of these requirements may also be contradictory, so we
may need to select which ones we care most for...

--Jari

Nakhjiri Madjid-MNAKHJI1 wrote:

>Ok, I did sent an email about this, but it was too long and got clogged for approval. Here is a short version.
>
>Basically the problem is how to use EAP key management framework to support handovers. In the current spec, after EAP is done, a AAA key is established between the peer and the AAA server and is pushed from the AAA server to the authenticator, so that the peer and authenticator can do a secure association protocol (say a 4-way exchange) to establish short term session keys.
>Now if you want to support handovers, this would mean the peer now has to establish session keys with a new authenticator. If you want to make handover fast, you should not require a full EAP authentication, but should be able to use the same AAA key to derive session keys between the peer and new authenticator. To prevent domino effects and other attacks, it would make sense to not send the same AAA key to each and every authenticator. 
>
>EAP keying draft 05 had a section describing derivation of per-authenticator AAA keys (lets call them AAABS key, BS for wireless base station). Say for simplicity this is how you derive the key for BS A and BS B.
>
>AAABS-Key-A = prf(AAA key,"Per BS key derivation", BS-A-Id, Peer-Id,length)
>AAABS-Key-B = prf(AAA key,"Per BS key derivation", BS-B-Id, Peer-Id,length)
>
>This would allow hiding of AAA key from the BS, but would mean now we are sending AAABS-key to each authenticator. This seems to violate the EAP key management assumption of sending the AAA key to authenticator. Furthermore, the problem is that each base station would still have to get its key from the AAA server (too slow for handover).
>
>Several alternatives to solve this problem have been suggested, including an EAP proxy by Sanjay:  So that the authenticator is placed between the BS and the AAA server and receives the AAA key, generates the AAABS key for each BS. Given that folks think there may be a bunch of binding problems with the EAP proxy approach and you need to find a protocol to run EAP over between BS and Authenticator, I am wondering if the following is acceptable:
>
>What if we keep the 3-party model with each BS still acting as NAS, but when the EAP authentication is done, the AAA server sends the AAA key to another entity (such as local key distribution center, LKDC) instead.
> EAP peer                   BS/Authen        AAA server       	     LKDC
>   --------                -------------   ------------               ------ 
>    |                           |                  |                       |
>    |<------------------------->|<---------------->|                       |
>    |   EAP auth (phase 1a)     | AAA pass-thru    | --------------------->|                      
>    |                           |                  | AAA-Key transport     |
>    |                           | ---------------------------------------->|
>    |                           |                  | AAABS-Key A request   |
>    |                           | <----------------------------------------|
>    |<------------------------->|         AAABS-key-A trans                |
>    |  Secure assoc. protocol   |                  |                       |
>    | (including a nonce exch.) |                  |                       |
>    |                           |                  |                       |
>
>To deal with RADIUS problems: The NAS can send the address for the LKDC to the AAA server during the initial EAP signaling and once the EAP success is received sends a message to the LKDC. The LKDC sends a access request to AAA server to receive the AAA key. 
>LKDC would then be responsible to distribute AAABS key during handover or proactively to all BSs with a neighbor set.
>
>Does this sound crazy?
>
>Thanks in advance for comments.
>
>Madjid
>
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Nakhjiri Madjid-MNAKHJI1
>Sent: Wednesday, April 27, 2005 3:00 PM
>To: 'Bernard Aboba'; [email-masked]
>Subject: FW: [eap] Re: EAP key binding discussion
>
>Sorry for the late response to this. I have written something up. It is more a problem statement than a solution proposal. Basically because I was not sure whether sending the AAA key to some place other than an authenticator is against EAP key management principals.
>I am sending this in the following email.
>
>Regards,
>
>Madjid
>
>
>  
>