RE: kickstart and SSPP

["Nelson, David" <dnelson@enterasys.com>]

Madjid writes...

> Thank you for your response. Let me try to understand your reponse:
> please see inserts.

<snip>

> > General question first, why did RADIUS madated the use
> > of source IP address from the UDP packet as a way of shared
> > secret look up in the first place.
> 
> Because shared secrets in RADIUS are hop-by-hop, and the only reliable
> way to look up the shared secret for a proxy server is via the source
IP
> address.
> 
> Madjid>>if the shared secret is hop by hop and there are proxies on
the
> way, does that mean the NAS will not have a shared secret with the
home 
> RADIUS server?

Yes.  The NAS will share a RADIUS secret with any first-hop RADIUS
server it contacts, but will generally not share a secret with the
ultimate home RADIUS server, in proxy deployments.

> This means the home server will not have any trust relationship
> with the NAS that accepting users on behalf of that server?

The NAS has a transitive trust relationship with the home server, via
the proxy server chain, but no direct trust relationship.  Each proxy
server will generally validate the NAS identity before forwarding a
request.  If you have a "rogue" proxy in the chain, security problems
will obviously exist.

> > The NAS ID is the of originating client, not the proxy.
> 
> Madjid>>So are you saying the packet carries both an IP address (for
the
> proxy or NAS) and a NAS ID for originating NAS?

Yes.  The packet's source IP address is in the IP header and the NAS ID
(or NAS IP Address) is in the packet payload.  It is the Source IP
address from the IP header that is used to look up the shared secret.



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