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

[<john.loughney@nokia.com>]

Hi Alan,

I just gave your text a quick read, and I am basically supportive of
this.  I know it goes against some existing deployments of RADIUS,
but interoperability can be helped, based upon this text.

John

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Alan DeKok
> Sent: 06 March, 2005 19:25
> To: radiusext@ops.ietf.org
> Subject: ISSUE: Use of RADIUS in non-layer-2 sessions.
> 
> 
> 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/>
> 

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