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