eap Mailing List: How to design fast handoffs (Was: Re: [eap] RFC 3748 Review of EAP SIM)

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> > > I believe that it does.  One issue that may arise is the lack of an EAP
> > > Server identity.  This could have implications for handoff mechanisms that
> > > require a NAS to fetch a key from the server, since the server identity is
> > > not authenticated.
> >
> > Hmm... we may not have explored the handoff design far enough to
> > say for sure, but its not immediately obvious to me that the
> > server identity helps here. There's certainly a key which is
> > shared between the server and the client. And key identifiers,
> > if the eap keying framework defines them. Plus even if the
> > server was identified, how would that identification be
> > communicated to the (new) NAS?
>
> I mention this because of the importance of authenticated peer and server
> names in several of the 802.11r proposals.  The authenticated peer name is
> utilized as the identity in some of the proposals, so that EAP methods
> which don't include this might not function.  Luckily, I think most
> methods have this (it's a SHOULD in RFC 3748).
>
> What was somewhat surprising to me is that there was also talk about a
> message sent from the peer to the new NAS, requesting that a key be
> provisioned, by name.

Would this be a "key name" (as defined in eap-keying), the identity
of the AAA server in some AAA level representation (e.g.
Destination-Host AVP), or the identity that the peer saw for the
server when it initially authenticated with it? Note that all these
name spaces may be separate, and might not be possible for the
client to discover the Destination-Host AVP or for the NAS to
use either the key name or the method-internal server name for
any purpose.

> The new NAS might have more than one RADIUS server, which might
> include the RADIUS server used by the old NAS, on which key state (EMSK)
> still resides.  But that might not be the primary RADIUS server.  So in
> that message, the peer may need to include the server name, so that the
> new NAS can fetch the key from it.

So the problem is about routing to the right AAA node? I don't think
the EAP server name guarantees that. What if the same cert and key
pair is shared between the primary and backup servers?
One working solution would be for the EAP server to pass its
"AAA address" via EAP to the client, but this feels like a hack
at least on initial look. Alternatively, the old NAS could
hand the AAA route or destination it used to the client, and
the client could hand it to the new NAS.

> For that reason, I'm
> not sure this kind of "key fetching" is a good idea, and it's not
> supported in Diameter EAP.

Agreed.

--Jari