RE: Issue 69 (was Re: Access-Reject)

[Avi Lior <avi@bridgewatersystems.com>]

Hi Alan,

See comments inline:

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Monday, March 07, 2005 1:55 PM
> To: radiusext@ops.ietf.org
> Subject: Issue 69 (was Re: Access-Reject)
> 
> 
> Avi Lior <avi@bridgewatersystems.com> wrote:
> > Here is an simple example.  If an already authenticated 
> user wants to 
> > establish a new call VoIP call etc... The NAS can then 
> Authorize that 
> > call by issueing an Access-Request Authorize-Only.  No need to 
> > autenticate again right?
> 
>   Some comments, which are conceptual and not RADIUS-specific.
> 
>   1) The authorization request MUST be tied to a previous 
> authentication request.  If it is not, then we have the 
> problem of un-authenticated users being authorized to do 
> something.  Users may authenticate multiple sessions, so each 
> authorization request MUST be tied to a particular session, 
> and not to a user.

I agree.

Where is the binding done.  Clearly the entity making the Authorization
request can associate the Authorization request with the session.  So  the
problem you are pointing to is at the Server.

Therefore we could use Accounting-Session-Id. Failing that, AAA application
that use this need to worry about this.  Prepaid I belive does this.

>   2) The authorization request itself MUST be authenticated.  
> This is Bernard's comment in the issues page about using 
> Message-Authenticator.

Yes.

>   3) The context of the authorization request MUST be 
> interpreted as what is being requested, and not any previous 
> authentication or authorization request.  e.g. User X 
> authenticates, is authorized to do X, Y, and Z.  He later 
> requests authorization to do Q.  Any "yes/no" response MUST 
> be interpreted as meaning "yes/no" to do Q.  It MUST NOT 
> apply to the previously granted authorization.

Yes 
> 
>   My reading of the above requirements in the light of RADIUS 
> means that implementing Authorize-Only semantics in 
> Access-Requests may be problematic.

Well, not if it meets the above requirements.

>   RADIUS does not have the concept of "authenticated 
> sessions", so we may use (for example) the "Class" attribute, 
> as it's already used to tie Accounting-Requests to previous 
> Access-Requests.  Using Class to tie Access-Requests together 
> may have deployment issues.

Not sure about that. For example if a session is represented by
Acct-Session-Id then I know that that has been authenticated and authorized
no?
 
>   The Message-Authenticator attribute can address requirement (2).
Sure.
 
>   Requirement (3) means that the RADIUS server MAY have to 
> keep track of not only all user sessions, but all 
> authorization data for all user sessions.  

> Otherwise, if (in 
> the above example) the user did not originally request 
> authorization to do "Q", he could later request it, and 
> possibly gain unintended authorization.  That is, the context 
> of authorization which permits/denies "Q" is the 
> authorization to do "X, Y, and Z", which itself may be time, 
> resource, and location-dependent.

That needs to be managed by the AAA Applications themselves. Nobody said it
was going to be easy.


> 
>   So to answer Bernard's question: Yes, using Authorize-Only 
> in an Access-Request outside of the context of CoA-Request 
> and DisconnectRequest can be valid.  But we should highlight 
> the issues, so that any deployment is designed correctly.

I agree.  We need to make sure that your requirements are met.

>   The Cisco TACACS+ command authorization example I discussed 
> previously is a narrowly scoped problem which can fit within 
> the above requirements.  As for others, I'm not sure.

Thanx Alan, lets work together to make this fly.
 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>