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

From: [email-masked] (Patrice Calhoun)
Date: Wed, 4 Nov 1998 08:21:53 -0800

My personal preference is to have an Access-Request message that includes
Calling-Station-Id and Called-Station-Id and the Service-Type set to 
Authorize-Only.

I really don't see the need for another service type. Of course, this could
cause backward compatibility problems, but I think that you'll have problems
regardless of the approach unless you require the User-Name attribute to be
present.

PatC

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

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 4 Nov 1998 15:21:42 -0500

> > If we are trying to define the standard (or at least recommended)
> way to
> > handle this issue, I strongly oppose using an Access-Accept as
> anything
> > other than meaning "accept this user" because of the risk of
> allowing a
> > caller inappropriately.
> 
> Access-Accept in this case means accept this call, since what you are
> "authenticating" is the phone number, not a user.
> 
Ah, but the "U" in RADIUS stands for USER.  I think the basic paradigm
of RADIUS is the authentication of, and service provision to, USERS.
While this distinction may seem pedantic, I think we could easily go
astray if we start authenticating other entities.  In the Caller-ID
case, one typically thinks of the calling phone number as the alias of a
user (or group of users). 

> The decision on whether to authenticate the user separately can be a
> distinct issue from accepting the call.
> 
There can be a distinct decision, but it should not be up the NAS to
decide.  The RADIUS server is uniquely positioned to make such security
policy decisions, IMHO.

> Please note, that I was not saying that we should not look into using
> the
> Access-Challenge.  I was pointing out that it is not strictly
> necessary
> to implement the desired functionality.
> 
> The fact that Ascend-Require-Auth is a vendor specific attribute, does
> not
> mean that a standard attribute with similar functionality could not be
> provided.
> 
Adding a another standard attribute whose functionality overlaps and
confuses that of existing standard attributes is only slightly better
than adding a vendor-specific attribute with the same properties.

> > > > So I would like to define the NAS's action on all three server
> responses:
> > > > 
> > > > Kill the call on reject.
> > > 
> > > This is controlled by the NAS.  The Access-Reject can cause the
> call to
> > > be rejected (not-answered) or the NAS can accept the call but
> require the
> > > normal authentication.
> > 
> > The server has no method of physically forcing the NAS to terminate
> the
> > call, I agree.  But I believe, strongly, that we have three
> responses
> > that have perfectly intuitive meanings, and should not blur the
> > meanings without some really good reason.  You're advocating an
> Accept
> > that can say "do more authentication" and a reject that says "no
> good
> > this try, but feel free to try again".  Whatever is wrong with
> Access
> > Challenge?  Are we really going to say that because some old
> > demo-level code (for which we should all be grateful!) might not
> issue
> > one that we can't now use it?
> 
I have to support this view.

> I think you are reading too much into an Access-Reject.
> 
How so?  To use the cliché:  "What part of 'no' don't you understand?"
What's to read into the meaning of Access-Reject?

> I do not see that the current RADIUS standard uses sending an
> Access-Reject
> to mean "drop the call".  There are many NAS vendors who will permit
> the
> user to attempt more than one authentication.  Thus the NAS may
> receive
> an Access-Reject because of a typo and then an Access-Accept on the
> next
> attempt, without ever disconnecting the user.
> 
Well, here I concur.  The NAS may decide to drop the call or it may
allow authentication retries.  That is an implementation decision.
Access-Reject certainly means "don't start the service", however.

> I don't agree that Accept and Reject have unequivocal meanings beyond
> the RADIUS server accepting the information in the Request as valid or
> invalid.
> 
Yes and no.  Access-Reject means "do not start the service".  If the NAS
is not prepared to implement an authentication retry method, then it
certainly implies "drop the call".  Access- Accept dictates what service
will be delivered -- it need not the service requested or expected by
the user.  Any service type information in an Access-Request packet is
just a hint to the RADIUS server.

Regards,

Dave

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

-

---

From: [email-masked] (Patrice Calhoun)
Date: Wed, 4 Nov 1998 12:53:15 -0800

What if there is no further user authentication? An example is a tunneled user
and the LNS information is determined based on DNIS. In this case the NAS
should an Access-Accept (with service type=Authorize-Only) and the LNS
information.

PatC
>> > > Answer the call and do further user authentication on challenge.
>
>Just as you feel that the option I presented changes the meaning of
>the Access-Accept and Access-Reject, I think the option you presented
>changes to meaning of Access-Challenge. 
>
>Normally an Access-Challenge does not give the user any greater access
>to the NAS.  It allows the authentication to continue at the same level.
>
>When using called or calling station-id for pre-authentication of the
>call, the Access-Challenge would actually be giving access to the NAS,
>which the caller did not previously have.
>
>The use of an Access-Challenge also raises the question of how the
>Reply-Message in the Access-Challenge is supposed to be "displayed"
>to a user who is dialing in with a frame connection (rather than a
>terminal server).
>
>But I still think your idea is of interest and should be investigated.
>-

-

---

From: "Beadles, Mark A." <[email-masked]>
Date: Mon, 9 Nov 1998 16:27:53 -0500

There are really a number of scenarios, some of which have wider
application than others, for Phone-Number-only authorization.
For example:

1) Compulsory tunneling of a connection based solely on number dialed.
2) Compulsory tunneling of a connection based solely on calling number.
3) Application of a preset filter to a connection based solely on number
dialed.
4) Selection of a secondary authentication server based solely on number
dialed.

In many cases when authorization is based solely on the number dialed, this
authorization takes place prior to the going off-hook.  For example, in case
4,
you can think of this as a "RADIUS referral" mechanism, where the selection
of
which RADIUS server the NAS should authenticate against is determined by
which 
number is dialed.  The mechanism for making this determination?  RADIUS, of
course.
This allows the sharing of NAS's across multiple service providers without
the use
of RADIUS proxy.

Another interesting application is a help-desk scenario.  User's password
expires, 
or user is new and has no password - then just dial this toll-free number
which
connects you (either via a tunnel or via application of filters) to a preset
site
which has help-desk or sign-up information.  

Or consider where a corporation provides its sales force with a bunch of
cellular
modems from a predetermined pool of phone numbers.  Perhaps when these folks
dial in, they automatically get tunneled to a corporate intranet site.

I have noted some objections to going down this road, paraphrased here:

Objection 1) RADIUS stands for ...USER SERVICE, how can we even think about
authenti-
             cating things that aren't user-based?

Response 1)  It's really just a matter of degree.  RADIUS is just a tool for
service
             providers and enterprises to implement policy.  Policy may be
very strict
             or very loose, and this is a business decision, not a technical
one.
             Phone number based authorization is really just authentication
based on a
             very loose set of credentials - specifically, just knowing a
phone number.
             But these credentials may be good enough to authorize a very
limited set of 
             services, such as a help desk, a sign-up service, or the
granting of a try
             at a round of REAL authentication.

Objection 2) Couldn't this lead to the use of predictable passwords in a
DNIS-based
             Access-Request, which could aid an attacker in recovering a
shared secret
             if they could snoop the wire?

Response 2)  I agree with those who point out that service providers should
be policing
             their shared secrets anyway, and that if you posit the ability
to snoop
             the wire, guessing shared secrets via a known
plaintext/dictionary attack
             is not a high risk.

Objection 3) But doesn't this subvert the RADIUS model?  What is the proper
action when a 
             NAS gets an Access-Accept or -Reject on a DNIS-authorized call?

Response 3)  Really quite straightforward.  The NAS just does what the
RADIUS server says.
             If the RADIUS server says, Access-Reject, then the NAS doesn't
pick up the phone.
             If the RADIUS server says, Access-Accept, Tunnel-*, then the
NAS connects the
             user and builds a tunnel.  If the RADIUS server says,
Access-Accept, Filter 17, then
             the NAS connects the user and applies filter 17.  If the RADIUS
server says,
             Access-Accept, RADIUS-Referral-Address 10.10.10.1[note], then
the NAS picks up the phone
             and begins a normal PPP negotiation, using RADIUS server
10.10.10.1.

Note 1:  OK, so this attribute doesn't exist in the standard, but you get
the idea.

Besides, the ability to provide the services described above is required,
IMHO, and since
RADIUS is all we have today, then it is RADIUS that will be used to provide
them.

+ Mark Anthony Beadles + MCI WorldCom Advanced Networks +
+  [email-masked]   +        http://www.wcom.net     +
+  Voice 614.723.1941  +          Fax 614.723.8407      +

-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Wednesday, 04 November 1998 15:59 
To: [email-masked]; Aydin Edguer
Subject: Re: (radius) Username/User-Password attributes

Sender: [email-masked]
Received: from bast (bast.livingston.com [149.198.247.2])
	by arl-img-12.compuserve.com (8.8.6/8.8.6/2.16) with ESMTP id
PAA03926
	for <[email-masked]>; Wed, 4 Nov 1998 15:59:07 -0500
(EST)
Received: from server.livingston.com (server.livingston.com [149.198.1.70])
by bast (8.8.5/8.6.9) with ESMTP id MAA02469; Wed, 4 Nov 1998 12:56:35 -0800
(PST)
Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9)
id MAA27978 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:56:28 -0800 (PST)
Date: Wed, 4 Nov 1998 12:53:15 -0800
From: [email-masked] (Patrice Calhoun)
Message-Id: <[email-masked]>
To: "Aydin Edguer" <[email-masked]>, [email-masked]
X-Mailer: Sun NetMail 2.1.6
Subject: Re: (radius) Username/User-Password attributes
Sender: [email-masked]
Precedence: bulk
Reply-To: [email-masked] (Patrice Calhoun)

What if there is no further user authentication? An example is a tunneled
user
and the LNS information is determined based on DNIS. In this case the NAS
should an Access-Accept (with service type=Authorize-Only) and the LNS
information.

PatC

-

---

From: "Darran Potter" <[email-masked]>
Date: Tue, 10 Nov 1998 11:11:29 -0000

We have clients wanting user access via premium rate nos' they dont care who so
long
as they come in via the correct number... So I'd like CLID/DNIS authentication..

So long as the standard defines how to recognise it... I think there may already
by
several proprietry implementations with CLID in the User-Name etc.. etc..

IMHO you should have a Calling/Called-Station-Id but NO User-Name or
User-Password.
That way it would be clear what type of authentication was needed. Otherwise you
have to add per-vendor cludges.

Wouldnt it be nice if there was an Authentication-Type attribute... so you didnt
have
to work out what you're supposed to do....Diameter maybe?

Darran

-----Original Message-----
From: Beadles, Mark A. <[email-masked]>
To: 'Patrice Calhoun' <[email-masked]>; [email-masked]
<[email-masked]>; Aydin Edguer <[email-masked]>
Date: 09 November 1998 21:40
Subject: RE: (radius) Username/User-Password attributes

-