Subject: Re: (radius) Username/User-Password attributes

From: Barney Wolff <[email-masked]>
Date: Mon, 26 Oct 1998 10:08 EST

While we already have a problem with the installed base, I would support
defining specific strings that mean "not a real value" for use in the
user and pw attributes.  Every vendor has chosen a different way to
deal with this, and some vendors have chosen more than one.  Ridiculous.
We ought to at least provide a target to which all can gradually evolve.

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

---

From: David Bolen <[email-masked]>
Date: Mon, 26 Oct 98 14:46:17 EST

Barney Wolff <[email-masked]> writes:

> user and pw attributes.

The only risk with that is conflicting with something that someone
needs as a true value, so I prefer the option of the NAS permitting
the value to be used to be configurable.  Then, you just configure the
NAS and your RADIUS server with matching values (that work in the
specified system) and the server can detect their existence.

I suppose I'd still take statically defined values over no such
specification, but I think the configurable is better.

>                          Every vendor has chosen a different way to

We've been using the above approach (configurable values) with one
vendor's gear for a few years now without any problems.  The box can
be configured with how much it should do before the initial request
(from nothing to both user/password prompts) and with default values
for user/password.  By being configured with the default values, the
server can thus detect how much of the information it needs to do
extra challenges to get (e.g., how much of the login sequence it is in
control of, including prompting), and how much the NAS already
prompted for.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen              \  Internet: [email-masked]    /
  |        ANS Communications, Inc.         \   Phone: (914) 701-5327 |
 / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
\-----------------------------------------------------------------------/
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Leonard Cuff <[email-masked]>
Date: Tue, 27 Oct 1998 11:07:11 -0800 (PST)

Most of what I know about cryptography comes from browsing in Bruce Schneier's 
"Applied Cryptography" (so therefore I DON'T consider myself an expert), but
as I see it, having a fixed value in the password field (such as "Ascend-DNIS") 
makes possible the recovery
of the shared secret by hackers through a "known plaintext" attack.  Basically
they can snoop the message on the net, then pick shared secrets via any favorite
method and keeping running MD5 'till the known plaintext pops out, shazaam they
know the shared secret.  RADIUS does have a 128 byte keyspace, but given the
reality
of how people pick their key - short lengths, all printable characters,
what's the
vulnerability?

I'd like to have someone who IS a cryptography expert
comment on the security aspects here.

Leonard

At 05:53 PM 10/23/98 -0700, Dale E. Reed Jr. wrote:
>Aydin Edguer wrote:
>> 
>> 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".
>
>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
> 
>> 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.
>
>The password really isn't relevant and in most cases is ignored.  It
>COULD be definable on the NAS for added security, though.
> 
>> > 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.
>
>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
>-

-

---

From: Barney Wolff <[email-masked]>
Date: Tue, 27 Oct 1998 17:00 EST

Without claiming any real expertise, I'll jump in.  I see no added risk
here - if one assumes the attacker can sniff the packets, it's a triviality
to know your OWN password, so you can run the same attack by just dialing
in.  As the shared secret is set up by network operators, not users, the
use of a short or guessable one is self-abuse.

Barney Wolff

> Date: Tue, 27 Oct 1998 11:07:11 -0800 (PST)
> From: Leonard Cuff <[email-masked]>
> 
-

---

From: Tom Fraser <[email-masked]>
Date: Tue, 27 Oct 1998 18:06:15 -0600

The real preventative it seems is to remove the ASCII component (user id)
somehow.

The simplest method, from my perspective, would be to generate a CHAP
request.  This removes the user id from the packet and vendors can
generically generate one from whatever type of user authorization profiles
are being used (terminal login, DNIS, etc.).

This maintains the RADIUS protocol as utilized in the field but removing an
attribute that can allow hackers to fairly easily crack the secret.

Tom Fraser
[email-masked] <mailto:[email-masked]> 

	-----Original Message-----
	From:	Leonard Cuff [SMTP:[email-masked]]
	Sent:	Tuesday, October 27, 1998 1:07 PM
	To:	Dale E. Reed Jr.
	Cc:	[email-masked]
	Subject:	Re: (radius) Username/User-Password attributes

	Most of what I know about cryptography comes from browsing in Bruce
Schneier's 
	"Applied Cryptography" (so therefore I DON'T consider myself an
expert), but
	as I see it, having a fixed value in the password field (such as
"Ascend-DNIS") 
	makes possible the recovery
	of the shared secret by hackers through a "known plaintext" attack.
Basically
	they can snoop the message on the net, then pick shared secrets via
any favorite
	method and keeping running MD5 'till the known plaintext pops out,
shazaam they
	know the shared secret.  RADIUS does have a 128 byte keyspace, but
given the
	reality
	of how people pick their key - short lengths, all printable
characters,
	what's the
	vulnerability?

	Leonard

	-