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

Re: Question about NAI Realm based routing of RADIUS



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