AAA Routing in ERX (was RE: [HOKEY] a transparent proposal)

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

Hi Bernard,
AAA routing in ERX is still done based on the realm.  It is up to the
local domain how the key state replication is handled.  If there are
multiple local ER servers in the same domain for redundancy sake, key
state may be replicated across those servers.  While ERX provides no
provisions for such AAA replication, this is not restricted by ERX. 

So, there are no changes to AAA routing between regular EAP and ERX.  In
fact, this was one of the debated points earlier on in the design when
the choice was made to keep the AAA routing the same to minimize impact
to AAA entities. 

Thanks,
Vidya

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, January 07, 2008 7:56 AM
> To: Hannes Tschofenig; barney@databus.com
> Cc: hokey@ietf.org; radiusext@ops.ietf.org
> Subject: 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.  
> 
> 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. 
> 
> 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.  
> 
> 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".  
> 
> 
> > Date: Mon, 7 Jan 2008 10:54:02 +0200
> > From: Hannes.Tschofenig@gmx.net
> > To: barney@databus.com
> > CC: hokey@ietf.org; radiusext@ops.ietf.org
> > Subject: Re: [HOKEY] a transparent proposal
> > 
> > I don't think that this works since the Authenticator needs 
> to route 
> > the messages to a local proxy that later acts as the local 
> ER server. 
> > Hence, the Authenticator needs to perform special routing 
> > functionality. In my recent mail to the list I was 
> wondering whether 
> > in Diameter one would have to define a new Diameter application for 
> > EAP-ER to accomplish this routing since otherwise you might 
> encounter other interesting effects.
> > 
> > Ciao
> > Hannes
> > 
> > 
> > 
> > 
> > 
> > Barney Wolff wrote:
> > > I've been reading the HOKEY drafts, and am somewhat taken 
> aback by 
> > > the extent of the required changes. I know it's late in 
> the process, 
> > > but I wonder if the HOKEY group has considered and 
> rejected an idea 
> > > like the following. If so, why? If not, and there is some 
> expression 
> > > of support, I could write it up as a draft.
> > >
> > > Make HOKEY transparent to the authenticator - peer and 
> server have 
> > > to know, but the authenticator does not.
> > >
> > > As part of the initial EAP conversation, peer & server agree that 
> > > HOKEY may be done. The MSK that the server sends to the 
> > > authenticator is not the real MSK, but a 
> > > domain-authenticator-specific key derived from it that 
> the peer can also derive.
> > >
> > > When the peer connects to another authenticator, the identity it 
> > > supplies is a reauth-NAI given to it by the original 
> server rather 
> > > than the id it supplied at initial auth. Based on the id, the new 
> > > authenticator naturally routes its access-requests to a reauth 
> > > server, without needing any code updates. The reauth server goes 
> > > through an abbreviated conversation with the peer, and 
> upon success 
> > > sends the newly-derived domain-authenticator-specific key to the 
> > > authenticator. Class can be used to tie together all the pieces.
> > >
> > > Advantages:
> > >
> > > Authenticator is completely unchanged.
> > >
> > > AAA proxies are completely unchanged.
> > >
> > > Peer behavior remains that of an EAP responder, rather than being 
> > > both requester (for reauth) and responder (for initial 
> auth) in the 
> > > current HOKEY drafts. The HOKEY drafts seem to do considerable 
> > > philosophical violence to EAP in this regard.
> > >
> > > No new EAP codes. HOKEY can be done as a new EAP method.
> > >
> > > Disadvantages:
> > >
> > > There is an extra round-trip, but it is to a (presumably local) 
> > > reauth server. Even that could be avoided if the 
> authenticator were 
> > > to be upgraded to recognize a reauth-identity and generate a 
> > > reauth-eap request itself. But I suspect that's not 
> really necessary.
> > >
> > > 
> > 
> > 
> > --
> > 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/>
> 
> 

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