Re: [RADIUS FIXES] Authorize Only

["Alan DeKok" <aland@ox.org>]

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

> Second, I think that having "Authorize-Only" has utility.

  I agree.  *What* utility is a qualification that needs to be defined.

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

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

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

  The answers to those questions will influence any suggestion I might
have for a solution.

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