Re: Access-Reject (was RE: Comments on draft-carroll-dynmobileip- cdma -04.txt)

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

Avi Lior <avi@bridgewatersystems.com> wrote:
> No.  That is the problem we are now facing. Authorize-Only messages maybe
> sent by the NAS without receiving a CoA.
> This makes perfect sense.

  ... outside of the scope of RFC 3576, where meaning is
implementation-defined.

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

  I can see that.  But the more I think about it, the more I believe
that "Authorize-Only" is inappropriate in this context.  I'll continue
that discussion elsewhere, though.


  RADIUS is being deployed in situations where it is performing
authentication and authorization for access *other* than layer 2
connections.  e.g. web/ftp servers, user login authentication, etc.
All of these "sessions" have clear start, stop, and authorization
semantics.  These semantics can often be represented within the
existing RADIUS packet and attribute encapsulations.

  My suggestion for the "issues and fixes" document is the following
text:


    The RADIUS specification [rfc's] is defined in reference to dialin
    authentication, layer 2 connections, and user "sessions" are
    discussed within that context.  RADIUS has been deployed, however,
    in the context of other layers and sessions where user
    authentication, authorization, and accounting is desired.  For
    example, existing deployments use RADIUS as a "back-end" for
    authenticating VOIP connections [digest], HTTP sessions [apache],
    FTP sessions [proftpd, and machine logins for multiple operating
    systems [bsdi, pam, gina].  In those contexts, the implementation
    MUST interpret the RADIUS specification as narrowly as possible,
    within the scope of the client-server model as described in
    RADIUS [RFC 2865] Section 1:

  <quote>
   Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers.
   </quote>

    Any deployment of RADIUS outside of the scope of dialin
    authentication MUST therefore interpret RADIUS within the context
    of the service that the RADIUS client is delivering to the user
    who is requesting authentication, authorization, and accounting.
    For example, an Access-Reject sent to the client MUST be
    interpreted by the client as a rejection of the users request for
    service, and the client MUST no longer offer that service to the
    user.  In the deployments listed above, this rejection will mean
    termination of a VOIP call, TCP connection, or user login session.


  I'll resubmit this using the ISSUES format.

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