RE: [RADIUS FIXES] Authorize Only

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

Hi Alan,

Thanx for the quick response -- see inline.

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Monday, July 25, 2005 5:59 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:
> > First, I don't think that 3576 prohibited the use of 
> Authorize-Only -- 
> > some implementation and specification already use Authorize-Only.
> 
>   Outside the scope of it's definited usage scenario.

I wont argue on this point since it may generate more heat then light if
you know what I mean ;-)


> > Second, I think that having "Authorize-Only" has utility.
> 
>   I agree.  *What* utility is a qualification that needs to 
> be defined.

Sure.  But again we may never be able to describe all utilities.  I
think perhaps we should explore the danger of having such a facility and
perhaps describe how it is to be used.

> >  In fact one case is prepaid where the NAS and Server maintain a 
> > conversation regarding the replenshiment of prepaid quota.  The 
> > replenishing of the quota is triggered by the NAS (usually) 
> using an 
> > Access-Request (Note the NAS is the only entity that knows when the 
> > quota is used up).  Without the having the ability to use the 
> > semantics provided by "Authorize-Only" we would have no 
> option but to 
> > reauthenticate.
> 
>   Are the semantics information returned from Authorize-Only:
> 
>   a) additional to existing authorization
>   b) replacement of existing authorization
>   c) some combination of (a) and (b)

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.


>   In your scenario, the use is well defined.  The danger in 
> allowing Authorize-Only is that other use-cases may not be 
> well defined.

Sure. But we should not limit something because some use-cases are going
to be problematic.  In prepaid I would have a real problem if I don't
have this capability.

> > Support for Authorize-Only is key in supporting many new 
> functionality 
> > that allow the NAS to authorize new resources without 
> authenticating 
> > the user.  For example, we may want to authorize a Voip call for an 
> > already existing session.  I feel strongly that we need to support 
> > this capability in RADIUS.
> 
>   I agree.
> 
>   Before I offer suggestions, I have a question.  How do you 
> tie the VOIP call into the existing session?  How do you deal 
> with security issues such as spoofing, etc?  How does the 
> RADIUS server associate the two requests?

Forgetting existing VoIP protocols like SIP etc.

When a terminal wants to make a VoIP call the NAS may send an
Access-Request with Service-Type = "Authorize-Only"
It will need to establish a context for what purpose it is sending this
request and for whom.

The for "whom" part would require NAI, Calling Station ID, CUI, IP
address, or even Accounting Session Id, VSA - this is similar to the
requirements in 3576.

The context can be established by the presence of an attribute. In 3576
the context is in essence base RADIUS.  In prepaid, there is an
attribute that is included that tells the RADIUS server the context of
the authorize only and what action is being requested.  In VoIP it could
be the an Attribute that describes the number the device wants to
contact.

Regarding security.  
The Authorize-Only MUST be protected using Message-Authenticator since
there is no password.  This is as defined by 3576.

Other then that, RADIUS is hop-by-hop protocol and hops are implicitly
trusted. No different then any other RADIUS interaction.
 
>   The answers to those questions will influence any 
> suggestion I might have for a solution.

Does this answer your questions?
 
>   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/>