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

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

> From: Aydin Edguer <[email-masked]>
> Date: Wed, 4 Nov 1998 10:21:45 -0500 (EST)
> 
> > For that scenario, I'd feel safer replying with Access-Challenge, not
> > 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.

Need I point out that Ascend-Require-Auth is NOT a generally-accepted
RADIUS attribute, but a vendor-specific attribute in drag?  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.

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

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

Strictly speaking, packet type is not necessary at all, if packet
attributes completely define the meaning of the packet.  But that's
some other protocol, not RADIUS.

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

See above for why I believe Accept and Reject should have unequivocal
meanings.

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 14:32:50 -0500 (EST)

> RADIUS attribute, but a vendor-specific attribute in drag?

No, you do not need to point it out, since I stated explicitly that it
was a vendor specific attribute.

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

The decision on whether to authenticate the user separately can be a
distinct issue from accepting the call.

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.

> one that we can't now use it?

No, I am not advocating anything.  I am pointing out *an* alternative that
should be discussed and which is currently in use at some sites.  Since
much of RADIUS was supposed to be based on current practice, examining
current practice seems reasonable.

No where did I say that using an Access-Challenge was wrong, just that
it was not strictly necessary and to point out that it requires greater
intelligence in the RADIUS server.  Access-Challenge is certainly a viable
option.

I am trying to make the point that the Access-Accept is accepting the call,
and does not have to accept the user.  I am saying that when sending an
Access-Accept to a called or calling station-id request the RADIUS server
can be used to authorize the call to proceed to user authentication.

I think you are reading too much into an 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.

> See above for why I believe Accept and Reject should have unequivocal

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.
-
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 15:04:20 -0500 (EST)

> > > 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.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.