RE: [RADIUS FIXES] Authorize Only

["Avi Lior" <avi@bridgewatersystems.com>]

Hi Alan,

Please see inline.

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Monday, July 25, 2005 8:01 PM
> To: Avi Lior
> Cc: Bernard Aboba; Nelson, David; radiusext@ops.ietf.org
> Subject: Re: [RADIUS FIXES] Authorize Only
> 
> 
> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> > I think perhaps we should explore the danger of having such 
> a facility 
> > and perhaps describe how it is to be used.
> 
>   Your application seems to be well-scoped, at least.
> 
> > This is a good question.  I think the "application" should 
> define the 
> > semantics.  So if the Application is Base RADIUS (2865 etc) then we 
> > follow the rules specified by 3576 that new attribute replace 
> > previously received attributes.  In the case of Prepaid the 
> > application deals with this explicitly so that there is no 
> confusion.
> 
>   It is then a "vendor-specific" value for Service-Type.

I don't understand why you would say it's a vendor-specific value of
Service-Type.

> 
> > Does this answer your questions?
> 
>   Yes.  My suggestion is to call your scenario 
> "pre-paid-re-authorization".

I don't agree.  There are other uses of authorize only.
 
>   I would prefer to define a new application-specific value 
> for Service-Type.  That value can then take on whatever 
> meaning is required for your needs.  The re-use of 
> Authorize-Only is awkward, and could be deprecated.  (Barring 
> re-deployment costs.)

I do have a wish .... See below.
 
>   That being said, I have no serious objections to permitting 
> this use of Authorize-Only.  I would still prefer to have the 
> "issues and fixes" strongly discourage further use of the 
> value, though.

Thanx for the support.  I don't agree that the use of Authorize-Only
should be discouraged though.  It has tremendous use for allowing the
NAS and Server to manage an already established session without the need
for re-authentication.

This is important since AAA (Diameter and RADIUS) are being used to
manage sessions that are much more complex today.

I would perfer that RADIUS issues and fixes provide guidelines on how to
use Authorize-Only.

Finally here is my wish:

I would have rather had the following Service-Type:

Re-Authorize:  this is what 3576 should be using.  It completely
re-triggers the re-authorization of the session.

Authorize-Only: is used the way I describe.  We do not completely
reauthorize the session but rather the context of what is being
reauthorized is determined from the contents of the packet.  It still
must be bound to an Authenticated Session or entity.
The binding being the same or similar to 3576.

Note:  if someone can propose a new Service-Type value to achieve the
same then I would be for that.  Although I belive there is already an
specification for Authorize-Only outside the IETF.

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