[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HOKEY] a transparent proposal



Bernard Aboba wrote:
> 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.   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.

  Yes and no.  The NAI could be decorated with a re-auth request, e.q.
"user@example.com@REAUTH".  Existing servers not implementing re-auth
could be configured to strip/ignore "@REAUTH", and forward the request
as normal.

  Servers implementing re-auth could forward the request to a
re-authentication server.  The key data obtained on initial login could
also be forwarded to that same re-authentication server.  Nobody else
needs to know or care where those servers are located.

  Of course, this only works for re-authentication within one domain.
If the user tries to re-authenticate to a different domain, then the
request has to be forwarded back up the proxy chain to another server
which has cached those credentials, or which can authenticate the user
from scratch.

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

  It is up to that domain to ensure all of it's AAA servers have the
same policy.  This includes managing state for multiple login detection,
and potentially re-auth keys.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>