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

From: Barney Wolff <[email-masked]>
Date: Wed, 4 Nov 1998 09:15 EST

> Date: Wed, 4 Nov 1998 04:17:19 -0800 (PST)
> From: Carl Rigney <[email-masked]>
> 
> I agree that it makes sense to send the Calling-Station-Id as the
> User-Name for NASes that want to send an Access-Request before prompting
> the user for their username.

Oh I suppose.  But the server MUST then check for your new service type,
as otherwise a user could enter an arbitrary digit string in response to
a prompt, and perhaps get accepted.  All this is really doing is getting
around a server check for the presence of officially-required attributes.

> A further step might be to permit User-Name in Access-Accept so that a
> NAS can find out the name of the user dialing in on a given line and
> send that along in accounting requests.

We should think seriously about what the appropriate response is, to a
call-check access-request.  One of the things I'd use that for is to
direct the NAS to do different things based on the called-station-id.
For that scenario, I'd feel safer replying with Access-Challenge, not
Accept, because further user authentication must be done.  So I would
like to define the NAS's action on all three server responses:

Kill the call on reject.
Answer the call and do further user authentication on challenge.
Answer the call and do no further user authentication on accept.

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

---

From: Aydin Edguer <[email-masked]>
Date: Wed, 4 Nov 1998 10:21:45 -0500 (EST)

> call-check access-request.

The appropriate reponse is to allow the call to be answered.  The "call-check"
takes place before the NAS goes off-hook.

> One of the things I'd use that for is to direct the NAS to do different
> things based on the called-station-id.

Yes, you can certainly authorize different services based on the called
or calling station-id.

> Accept, because further user authentication must be done.

Using an Access-Challenge might be an option, but it is not strictly
necessary.  In the Ascend implementation, you are able to either accept
the call an immediately start a framed protocol or terminal server
login without additional authentication, or you can require user
authentication in addition to called or calling station "call-check"
based on a vendor specific attribute in the Access-Accept message.

Specifically using Ascend-Require-Auth = Require-Auth forces the user to
go through "normal" framed (PAP/CHAP) or terminal server (login/password)
authentication.

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

> Answer the call and do further user authentication on challenge.

I can see that using Access-Challenge would be useful for certain purposes
but it is not strictly necessary to acheive the behavior you describe.
It requires more intelligence in the RADIUS server to implement (similar
to the Livingston RADIUS server method of implementing menus).

> Answer the call and do no further user authentication on accept.

This is an option, but it can be modified by other attributes in the
Access-Accept.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.