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 15:39:43 -0500

Alan DeKok writes...
 
>   Under what circumstances can a RADIUS client put a NAS-IP-Address
> attribute inside of a packet, which is different than the IP address
> from which the packet is sent?

I suppose if the RADIUS client is a multi-homed host, it might do so.
The primary purpose of the NAS-IP-Address attribute (or the NAS-
Identifier) is so that the RADIUS server may look up the shared secret
of the NAS.  A multi-homed NAS may have it's secret registered on the
RADIUS server by only one of it's IP addresses.  A somewhat contrived
example, perhaps...

>   I'd like to see the draft updated to talk about this issue.  Even
> adding a 'SHOULD' would help, as in:
> 
> ---------------------------------
> 5.4.  NAS-IP-Address
> 
>    Description
> 
>       This Attribute indicates the identifying IP Address of the NAS
>       which is requesting authentication of the user.  It is only used
>       in Access-Request packets.  Either NAS-IP-Address or NAS-
>       Identifier SHOULD be present in an Access-Request packet.
> 
>       If the NAS is originating the packet, then the value of the
>       NAS-IP-Address attribute SHOULD match the IP address of the
>       interface from which the packet is sent.

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.

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 16:31:33 -0500

[email-masked] says:
> of the NAS.

  Really?  The RFC doesn't say that at all.  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'.

  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.

  In fact, I've just tried this with servers from different vendors.

  I sent an Access-Request packet from client X, with NAS-IP-Address
of Y.  I didn't define Y as a RADIUS client, yet the user was
authenticated.

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

  Alan DeKok.
-

---

From: "Heath Partington" <[email-masked]>
Date: Wed, 24 Feb 1999 16:46:39 -0500

I think the multi-homed case is a valid case but looking at the draft I
believe it does need to be updated to clarify this point.

>     -----Original Message-----
>     From: [email-masked]
>     [mailto:[email-masked]]On Behalf Of Alan DeKok
>     Sent: Wednesday, February 24, 1999 4:32 PM
>     To: [email-masked]
>     Subject: Re: (radius) Matching NAS-IP-Address to actual
>     real-life NAS IP
>     a ddress
>
>

-

---

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

> request and has a shared secret, and a 'NAS'.

The server should ALWAYS use the IP Address it received the request
from to verify against the secret and NOT the NAS-IP-Address or
NAS-Identifier.  Anything else would be a security hole.
 
> NAS-IP-Address attribute is treated as ONLY informational.

Correct.
 
> of Y.  I didn't define Y as a RADIUS client, yet the user was

Which is expected behavior for me.  
 
> > the identity of the NAS, and thus know it's shared secret.

Actually, the NAS-Identifier is just a "name".  The NAS-IP-Address
should be the IP Address of the ORIGINATOR of the request.

-- 

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.