RE: [HOKEY] a transparent proposal

["Narayanan, Vidya" <vidyan@qualcomm.com>]

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Wednesday, January 09, 2008 12:18 AM
> To: Alan DeKok
> Cc: Hannes Tschofenig; barney@databus.com; hokey@ietf.org; 
> radiusext@ops.ietf.org
> Subject: RE: [HOKEY] a transparent proposal
> 
> 
> >   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.
> 
> Doesn't this imply a significant degree of complexity?  For 
> example, one argument for the RFC 4507 PAC is that avoiding 
> server-side state enables better scaling and authentication 
> performance, because RADIUS servers don't replicate TLS key 
> state.  It's hard to reconcile that argument with the idea of 
> having the domain keeping track of server side state. 
> 
> If there is a way to push that state on the peer, things 
> would be much simpler.  For example, if the ERX exchange were 
> to leave the peer with an NAI identifying the "local server" 
> and corresponding key state, then the peer could use that 
> "re-auth" NAI in subsequent requests. 
> 

That is what is done.  The peer performs the ERP exchange with
"rIKName@localdomain", where the "rIKName" is the name of the
reauthentication integrity key that is used to authenticate the ERP
exchange and "localdomain" identifies the domain name of the local ER
server.  For local domains that replicate key material, this domain name
may actually route to one of the multiple local ER servers; for local
domains that strictly have one server, they have the burden of providing
local domain names that are server-specific.   

The peer learns the local domain name at the time of ERX bootstrapping
and uses that, along with the corresponding rIKName as the username part
of its NAI at the time of reauthentication.  

Vidya

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