Subject: (radius) Username/User-Password attributes

From: "Glen Zorn" <[email-masked]>
Date: Fri, 23 Oct 1998 15:33:48 -0700

Trying to figure out how to support DNIS/CLNI authentication, as well as
"guest" accounts, it appears that the Username and *-Password attributes are
pretty much superfluous in these cases.  Does anyone else support these?
How many servers will break if they get an Access-Request w/o them?  Is
there any interest in making Username a "0-1" attribute instead of "1"?

--
A society, most of whose members spend a great deal of their time not on the
spot,
not here and now in the calculable future, but somwhere else,
in the irrelevant other worlds of sport and soap opera, of mythology and
metaphysical fantasy,
will find it hard to resist the encroachments of those who would manipulate
and control it.
  -- Aldous Huxley, Foreword to "Brave New World", 1946

---

From: Aydin Edguer <[email-masked]>
Date: Fri, 23 Oct 1998 19:02:38 -0400 (EDT)

> "guest" accounts, it appears that the Username and *-Password attributes
> are pretty much superfluous in these cases.
> Does anyone else support these?

Yes.  Ascend supports DNIS and CLID authentication (and has for at least
three years).

Ascend sends the DNIS or CLID information in the Access-Request as the
User-Name attribute along with a standard User-Password.

For example, if the NAS is configured to use DNIS to pre-authenticate
a call, the number that was dialed would be placed in the User-Name.

If the number was 5551212, then the User-Name would be "5551212" and
the Password would be "Ascend-DNIS".

The use of User-Name could be fairly generic between all NAS vendors and
is very easy to implement.  The use of "Ascend-*" as a User-Password is
not generic and most vendors would probably not agree to such a value.
The option on the RADIUS server side would be to ignore the password if
other NAS vendors use a different password.

> How many servers will break if they get an Access-Request w/o them?

Most.  The typical index into the RADIUS user database is the User-Name
attribute.  It is a requirement for Livingston 1.x and Merit 2/3/4.x
RADIUS servers at least.

> Is there any interest in making Username a "0-1" attribute instead of "1"?

I do not have any interest at this stage of the RADIUS standards game.
I could understand relaxing the requirement to include a User-Password or
CHAP-Password, but there are other ways around the problem.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: William Bulley <[email-masked]>
Date: Fri, 23 Oct 1998 19:12:30 -0400 (EDT)

> there any interest in making Username a "0-1" attribute instead of "1"?

I am pretty sure that we should keep User-Name and *-Password present:

  1) for if we abandon *-Password we lose the security of MD-5 and RADIUS

  2) lots of stuff depends upon User-Name being present (at a minimum)

I would not object to setting User-Name to "MaBell" when using DNIS/CLNI
authentication, but I would think eliminating it altogether would be a
radical change.  Maybe we could discuss this elsewhere?  (e.g., ietf-aaa)?

Regards,

web...

-- 
William Bulley                     Senior Systems Research Programmer
Merit Network, Inc.                Email: [email-masked]
4251 Plymouth Road, Suite C        Phone: (734) 764-9993
Ann Arbor, Michigan  48105-2785    Fax:   (734) 647-3185

[ Reuters, London, February 29, 1998: Scientists have announced discovering ]
[ a meteorite which will strike the earth in March, 2028.  Millions of UNIX ]
[ coders expressed relief for being spared the UNIX epoch "crisis" of 2038. ]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Fri, 23 Oct 1998 17:53:35 -0700

> the Password would be "Ascend-DNIS".

This is what I prefer to see.  It makes life REALLY easy to diagnose
and interpret this.  Just set the username to the same as the
 
> other NAS vendors use a different password.

The password really isn't relevant and in most cases is ignored.  It
COULD be definable on the NAS for added security, though.
 
> attribute.  It is a requirement for Livingston 1.x and Merit 2/3/4.x

RadiusNT does require it unless Caller-ID Authentication is enabled.
 
-- 
Dale E. Reed Jr.  ([email-masked])
_________________________________________________________________
       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs
 Internet Solutions for Today  |   http://www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 25 Oct 1998 10:38:05 -0500

>   2) lots of stuff depends upon User-Name being present (at a minimum)

  I agree with most of this.  However, I'm all for making the
*-Password attributes '0-1', instead of '1' in Access-Request packets.

  We're a token card vendor, and the current radius spec forces customers
to type in a password *prior* to performing challenge-response
authentication.  This is annoying.

  I'd like to see a NAS configured so that it can query a RADIUS
server as to which prompt to use when asking for a password.  This
will can each NAS multi-lingual support, and will allow us to send an
X9.9 challenge as part of the password prompt.

  Right now we can hack around this problem, but it's a continual
source of frustration.

  It would also be useful to not require a User-Name, and define new
explicit authentication conversations between the NAS and the server,
instead of the current implicit password-only authentication.  The
utility of a robust conversation mechanism can be seen from the
efforts currently being put into working around the strict
username/password only authentication.

  However, this is probably beyond the scope of the current
discussion.

  Alan DeKok.
-

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 26 Oct 1998 06:40:44 -0800 (PST)

>   However, this is probably beyond the scope of the current

This is exactly what EAP was meant for. I would propose the use of EAP as
opposed to hacking RADIUS more than we have to.

PatC

-