Subject: FW: [HOKEY] a transparent proposal

From: "gwz" <[email-masked]>
Date: Mon, 7 Jan 2008 11:11:34 -0800

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]

.

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey