eap Mailing List: Re: EAP key binding discussion

[Bernard Aboba (aboba]

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