Re: Question about NAI Realm based routing of RADIUS

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Daval --

RADIUS clients do not modify the EAP-Response/Identity, but rather they just 
insert it as is into the User-Name attribute.  RADIUS clients typically are 
only configured with primary/secondary RADIUS servers and so they do not 
handle routing; this is the responsibility of RADIUS proxies.  The situation 
is akin to hosts which only point to default gatways;  it is the gateways 
that typically run routing protocols, rather than hosts.

So in your example, the RADIUS client would send the Access-Request to the 
local RADIUS proxy. if a RADIUS proxy received an Access-Request containing 
a User-Name of other2.example.net!home.example.net!user@other1.example.net 
then it would look in its routing table for the RADIUS server handling the 
other1.example.net realm, and route the Access-Request to that server.  
RADIUS servers can only be included in the realm routing table if there is a 
shared secret configured for communication with that server.

Since RADIUS does not support DNS-based server discovery (this is a Diameter 
feature), there is no notion of "resolving" a realm name to an IP address 
other than via the realm routing table.  If the RADIUS proxy did not have a 
realm routing table entry for "other1.example.net" then it would either drop 
the packet or perhaps send back an Access-Challenge containing an 
EAP-Message/EAP-Request/Identity message containing realm hints as specified 
in RFC 4284.

In Diameter, DNS-based discovery is possible.  This could allow a Diameter 
proxy to discover the IP address of a server within a destination realm, 
without that address being configured in the realm routing table.  However, 
a successful Diameter session would only be set up if appropriate 
credentials were available to enable authentication.  For example, if 
Diameter over TLS were used, then the Diameter proxy would need to be able 
to verify the Diameter Server certificate based on its configured trust 
anchors.

--------------------------------------------------------------------------------------------------------------------------
Date: Wed, 14 Jun 2006 12:29:13 -0700
From: Dhaval Shah <dshah@wichorus.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Question about NAI Realm based routing of RADIUS
Parts/Attachments:

Hi
    I have a question about NAI Realm based routing of AAA RADIUS messages 
from say a 802.1x
authenticator to the Home AAA server.

Consider the following example: (I am using the notations from RFC 4282 
(Network Access Identifier), section 2.7)

Lets say autheticator received user identity in EAP-Response packet as NAI 
formed like

other2.example.net!home.example.net!user@other1.example.net

This NAI will be converted by the RADIUS client of the 802.1x authenticator 
as

home.example.net!user@other2.example.net

and forwarded to the IP address of other2.example.net as a RADIUS 
Access-Request.

My question is, RADIUS client usually needs to share a "secret" with AAA 
server, in the above
case where the client needs to send the message through multiple routing 
realms as coded
in the NAI, is it required that the client MUST have a shared "secret" with 
the first hop AAA
server/proxy towards the Home AAA server? In the above case, does 802.1x 
authenticator
of other1.example.net needs to share a "secret" with AAA server of 
other2.example.net and
it MUST use that to prepare the Message Authenticator? And similarly, AAA 
server of
other2.example.net MUST share a "secret" with home.example.net's AAA server?

Also, what (if any) extensions must be added to the RADIUS message 
originating at the authenticator to allow such realm based forwarding of the 
packet to the Home AAA server?

thanks
Dhaval



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