Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress

From: "Nelson, David" <[email-masked]>
Date: Wed, 24 Feb 1999 16:55:29 -0500

Alan DeKok writes...
 
>   Really?  The RFC doesn't say that at all.

That's the way it has always worked, at least before the 
introduction of RADIUS Proxy servers.

>  I won't quote it, but it
> does seem to differentiate between a 'client', which originates a
> request and has a shared secret, and a 'NAS'.

Both a NAS and a RADIUS Proxy Server may act as RADIUS Client.  All
RADIUS clients must have a shared secret, that the RADIUS servers
used by these RADIUS clients have access to.

>   The implementations I'm familiar with key on the IP address (and
> possibly port) of the client for the shared secret.  The
> NAS-IP-Address attribute is treated as ONLY informational.

Hmmm.   This is one way, probably the only way, to implement RADIUS
Proxy service.  Since the "second-hop" RADIUS server cannot be
required to share a secret with the NAS, the "first-hop" RADIUS
server must share a secret with the "second-hop" RADIUS server for
the purpose of decrypting the end user's password.  Another way of
stating this is that the encryption of the end user's password is per
"hop", each RADIUS Proxy server must decrypt it to clear text and then
re-encrypt it using the shared secret of the next RADIUS server up the
food chain.  On RADIUS responses, it works just the other way around.

> > I don't know that this is important to require or desire.  The
> > NAS-IP-Address is just a "name" by which the RADIUS server may know
> > the identity of the NAS, and thus know it's shared secret.
> 
>   I'd have to disagree.

Well, I reiterate my statement for the non-proxy case, however I fully
recognize that for RADIUS Proxy service to work, RADIUS servers are
going to have to do as you suggest and look at the source IP address of
the RADIUS client to be able to look up the appropriate shared secret.
 
Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Feb 1999 17:18:59 -0500

> introduction of RADIUS Proxy servers.

  My copy of the Livingston 1.16 source looks up the client using the
IP address of the receiving socket.  The NAS-IP-Address attribute
isn't even *referenced* in the source.

  That is, it's information, not identifying.

  Alan DeKok.
-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Wed, 24 Feb 1999 22:05:54 -0800

> food chain.  On RADIUS responses, it works just the other way around.

Except that there are other Password attributes besides PAP which may
not be clear text.  It is good to state that each RADIUS server must
unpackage the request and if it needs to proxy/forward it, must 
re-package the request specifically for the server it is forwarding
it to.
 
> the RADIUS client to be able to look up the appropriate shared secret.

A RADIUS server should NEVER look at anything but the IP Address the
request came in from to determine the secret and validitiy of the
request.  As an implementaion issue, you shouldn't even look at
the contents of the request until you have verified the request came
from
an allowed IP (therefore, if someone is playing a DOS attack, you don't 
waste time looking at the packet).  There are many RADIUS
implementations
that do look at the full request before checking the source and are 
suspectible to DOS and malformed packet attacks.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.