RE: [HOKEY] a transparent proposal

To avoid changes to existing RADIUS routing procedures, the messages would need to be routed to based on the realm in the NAI.
[gwz] Yes. [/gwz]
However, the routing requirements for the ERX application are different from those in normal AAA exchanges, because here key state (unlike the AAA credentials database) is not replicated.

[gwz]

I'm not sure where you get that idea; replication has not been called out as a specific hokey requirement but I don't recall anyone saying that it can't exist.

[/gwz]

That means that messages can't just be routed based on a "Domain Identifier" -- they actually have to be addressed to specific servers, since only those servers will hold the required key state.

For example, a "session resume NAI" could identify the specific EAP Session-Id that is being resumed, as well as the realm in which that key resides. However, an NAI including only the realm will not necessarily be routed to the server or proxy that holds the key state, because AAA deployments often point the authenticators at different AAA servers or proxies for load balancing purposes. To ensure that the request goes to the right place, the specific server name needs to be provided within the NAI.

[gwz]

Although it would be best if the sets of hokey and AAA servers in a given domain were to intersect, it is not mandatory; in particvlar, the sets need not be not be equal. This suggests that AAA routing is essentially irrelevant to hokey: it is the AAA routing method we're talking abour using, not necessarily the AAA routes or infrastructure. Even assuming that the sets are equal, I'm not sure why the reauth state wouldn't be replicated the with the rest of session state that is held by virtually all AAA (even RADIUS) servers.

[/gwz]

This may not be that easy to produce. Not all EAP methods produce the Server-Id, so the peer may not be able to include the specific server name in a "session resume NAI" sent to the home AAA server. For the peer to compose a "session resume NAI" for the local realm, it would have to learn the local server name, not just a "Domain Identifier".

[gwz]

OK, I also don't know why the peer would be composing this NAI; I thought that the idea was that the reauth identity would be passed back to the peer from the local reauth server as part of the original EAP conversation (maybe in a Notification-Request, since we can't make hokey depend upon a "special" initial EAP method).

[/gwz]

…