ISSUE: Use of RADIUS in non-layer-2 sessions.

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

Description: Use of RADIUS on non-layer-2 sessions
Submitter name: Alan DeKok
Submitter email address: aland@ox.org
Date first submitted: March 6, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00228.html
Document: "issues and fixes" draft
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue:

  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.  However, these
deployments are outside of the scope of the RADIUS standard, and any
interpretation of RADIUS within those contexts is
implementation-defined.  In order to guide implementors in the design
and use of RADIUS in novel deployments, we offer the text below.

Requested change: use suggested 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.

    The definition of the "service" being offered is a complex
    one, and should be interpreted as narrowly as possible within the
    context of the intended deployment.

    For example, when an authentication failure occurs in the context
    of an FTP session, the normal semantics for rejecting FTP services
    apply.  The rejection does not necessarily cause the FTP server to
    terminate the underlying TCP connection, but the FTP server MUST
    NOT offer any services protected by user authentication.

    We note also that users may use RADIUS to request multiple
    services from the NAS.  Where those services are independent, the
    deployment MUST treat the RADIUS sessions as being independent.

    For example, a NAS may offer multi-link services, where a user may
    have multiple simultaneous layer 2 connections.  In that case, an
    Access-Reject for a later multi-link connection request does not
    necessarily mean that earlier multi-link connections are torn
    down.  Similarly, if a NAS offers both dialup and VOIP services,
    the rejection of a VOIP attempt does not mean that the dialup
    session is torn down.

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