eap Mailing List: Re: How to design fast handoffs

[Bernard Aboba (aboba]

> 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 Key-Name is needed so that the NAS knows what to ask for.  For this
purpose the EAP Session-Id should be sufficient.  The other info that is
required is which AAA server to send the request to.  I think this needs
to be an FQDN resolvable to an IP address, or an IP address.

As you note, even in protocols that provide an authenticated EAP server
name, this might not be fulfilled.  For example, multiple AAA servers can
use the same certificate ("aaa.example.com"), so that the altSubjectName in the
server certificate might not be specific enough.

> So the problem is about routing to the right AAA node? I don't think
> the EAP server name guarantees that.

Right.  I don't think it does.

> What if the same cert and key
> pair is shared between the primary and backup servers?

That's a common practice, and I think it will break this scheme, even for
protocols that provide an authenticated EAP server name.

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

This is an example of something that needs to be discussed in the EAP
Keying document, to make sure people are aware of the "gotchas".