rfc4372.txt

使用最广泛的radius的linux的源码

Network Working Group                                         F. Adrangi
Request for Comments: 4372                                         Intel
Category: Standards Track                                        A. Lior
                                                     Bridgewater Systems
                                                             J. Korhonen
                                                             Teliasonera
                                                             J. Loughney
                                                                   Nokia
                                                            January 2006


                        Chargeable User Identity

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a new Remote Authentication Dial-In User
   Service (RADIUS) attribute, Chargeable-User-Identity.  This attribute
   can be used by a home network to identify a user for the purpose of
   roaming transactions that occur outside of the home network.

Table of Contents

   1. Introduction ....................................................2
      1.1. Motivation .................................................3
      1.2. Terminology ................................................4
   2. Operation .......................................................5
      2.1. Chargeable-User-Identity (CUI) Attribute ...................5
      2.2. CUI Attribute ..............................................6
   3. Attribute Table .................................................7
   4. Diameter Consideration ..........................................7
   5. IANA Considerations .............................................7
   6. Security Considerations .........................................7
   7. Acknowledgements ................................................8
   8. References ......................................................8
      8.1. Normative References .......................................8
      8.2. Informative References .....................................8



Adrangi, et al.             Standards Track                     [Page 1]

RFC 4372                Chargeable User Identity            January 2006


1.  Introduction

   Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM
   and EAP-AKA, can hide the true identity of the user from RADIUS
   servers outside of the user's home network.  In these methods, the
   User-Name(1) attribute contains an anonymous identity (e.g.,
   @example.com) sufficient to route the RADIUS packets to the home
   network but otherwise insufficient to identify the user.  While this
   mechanism is good practice in some circumstances, there are problems
   if local and intermediate networks require a surrogate identity to
   bind the current session.

   This document introduces an attribute that serves as an alias or
   handle (hereafter, it is called Chargeable-User-Identity) to the real
   user's identity.  Chargeable-User-Identity can be used outside the
   home network in scenarios that traditionally relied on User-Name(1)
   to correlate a session to a user.

   For example, local or intermediate networks may limit the number of
   simultaneous sessions for specific users; they may require a
   Chargeable-User-Identity in order to demonstrate willingness to pay
   or otherwise limit the potential for fraud.

   This implies that a unique identity provided by the home network
   should be able to be conveyed to all parties involved in the roaming
   transaction for correlating the authentication and accounting
   packets.

   Providing a unique identity, Chargeable-User-Identity (CUI), to
   intermediaries, is necessary to fulfill certain business needs.  This
   should not undermine the anonymity of the user.  The mechanism
   provided by this document allows the home operator to meet these
   business requirements by providing a temporary identity representing
   the user and at the same time protecting the anonymity of the user.

   When the home network assigns a value to the CUI, it asserts that
   this value represents a user in the home network.  The assertion
   should be temporary -- long enough to be useful for the external
   applications and not too long such that it can be used to identify
   the user.

   Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
   and IRAP, have been studying mechanisms to provide roaming services,
   using RADIUS.  Missing elements include mechanisms for billing and
   fraud prevention.






Adrangi, et al.             Standards Track                     [Page 2]

RFC 4372                Chargeable User Identity            January 2006


   The CUI attribute is intended to close operational loopholes in
   RADIUS specifications that have impacted roaming solutions
   negatively.  Use of the CUI is geared toward EAP methods supporting
   privacy (such as PEAP and EAP-TTLS), which are, for the most part,
   recent deployments.  A chargeable identity reflecting the user
   profile by the home network is needed in such roaming scenarios.

1.1.  Motivation

   Some other mechanisms have been proposed in place of the CUI
   attribute.  These mechanisms are insufficient or cause other
   problems.  It has been suggested that standard RADIUS Class(25) or
   User-Name(1) attributes could be used to indicate the CUI.  However,
   in a complex global roaming environment where there could be one or
   more intermediaries between the NAS [RFC4282] and the home RADIUS
   server, the use of aforementioned attributes could lead to problems
   as described below.

      - On the use of RADIUS Class(25) attribute:

      [RFC2865] states: "This Attribute is available to be sent by the
      server to the client in an Access-Accept packet and SHOULD be sent
      unmodified by the client to the accounting server as part of the
      Accounting-Request packet if accounting is supported.  The client
      MUST NOT interpret the attribute locally."  So RADIUS clients or
      intermediaries MUST NOT interpret the Class(25) attribute, which
      precludes determining whether it contains a CUI.  Additionally,
      there could be multiple class attributes in a RADIUS packet, and
      since the contents of Class(25) attribute is not to be interpreted
      by clients, this makes it hard for the entities outside the home
      network to determine which one contains the CUI.

      - On the use of RADIUS User-Name(1) attribute:

      The User-Name(1) attribute included in the Access-Request packet
      may be used for the purpose of routing the Access-Request packet,
      and in the process may be rewritten by intermediaries.  As a
      result, a RADIUS server receiving an Access-Request packet relayed
      by a proxy cannot assume that the User-Name(1) attribute remained
      unmodified.

      On the other hand, rewriting of a User-Name(1) attribute sent
      within an Access-Accept packet occurs more rarely, since a
      Proxy-State(33) attribute can be used to route the Access-Accept
      packet without parsing the User-Name(1) attribute.  As a result, a
      RADIUS server cannot assume that a proxy stripping routing
      information from a User-Name(1) attribute within an Access-Request
      packet will add this information to a User-Name(1) attribute



Adrangi, et al.             Standards Track                     [Page 3]

RFC 4372                Chargeable User Identity            January 2006


      included within an Access-Accept packet.  The result is that when
      a User-Name(1) attribute is sent in an Access-Accept packet, it is
      possible that the Access-Request packet and Accounting-Request
      packets will follow different paths.  Where this outcome is
      undesirable, the RADIUS client should use the original
      User-Name(1) in accounting packets.  Therefore, another mechanism
      is required to convey a CUI within an Access-Accept packet to the
      RADIUS client, so that the CUI can be included in the accounting
      packets.

   The CUI attribute provides a solution to the above problems and
   avoids overloading RADIUS User-Name(1) attribute or changing the
   usage of existing RADIUS Class(25) attribute.  The CUI therefore
   provides a standard approach to billing and fraud prevention when EAP
   methods supporting privacy are used.  It does not solve all related
   problems, but does provide for billing and fraud prevention.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following acronyms are used:

      3GPP - Third Generation Partnership Project
      AAA - Authentication, Authorization, and Accounting
      AKA - Authentication and Key Agreement
      CUI - Chargeable-User-Identity
      GSMA - GSM Association
      IRAP - International Roaming Access Protocols Program
      NAS - Network Access Server
      PEAP - Protected Extensible Authentication Protocol
      SIM - Subscriber Identity Modules
      TTLS - Tunneled Transport Layer Security
      WISPr - Wireless ISP Roaming
      WPA - Wi-Fi Protected Access














Adrangi, et al.             Standards Track                     [Page 4]

RFC 4372                Chargeable User Identity            January 2006


2.  Operation

   This document assumes that the RADIUS protocol operates as specified
   in [RFC2865] and [RFC2866], dynamic authorization as specified in
   [RFC3576], and the Diameter protocol as specified in [RFC3588].

2.1.  Chargeable-User-Identity (CUI) Attribute

   The CUI attribute serves as an alias to the user's real identity,
   representing a chargeable identity as defined and provided by the
   home network as a supplemental or alternative information to
   User-Name(1).  Typically, the CUI represents the identity of the
   actual user, but it may also indicate other chargeable identities
   such as a group of users.  RADIUS clients (proxy or NAS) outside the
   home network MUST NOT modify the CUI attribute.

   The RADIUS server (a RADIUS proxy, home RADIUS server) may include
   the CUI attribute in the Access-Accept packet destined to a roaming
   partner.  The CUI support by RADIUS infrastructure is driven by the
   business requirements between roaming entities.  Therefore, a RADIUS
   server supporting this specification may choose not to send the CUI
   in response to an Access-Request packet from a given NAS, even if the
   NAS has indicated that it supports CUI.

   If an Access-Accept packet without the CUI attribute was received by
   a RADIUS client that requested the CUI attribute, then the
   Access-Accept packet MAY be treated as an Access-Reject.

   If the CUI was included in an Access-Accept packet, RADIUS clients
   supporting the CUI attribute MUST ensure that the CUI attribute
   appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
   This requirement applies regardless of whether the RADIUS client
   requested the CUI attribute.

   RFC 2865 includes the following statements about behaviors of RADIUS
   client and server with respect to unsupported attributes:

      - "A RADIUS client MAY ignore Attributes with an unknown Type."
      - "A RADIUS server MAY ignore Attributes with an unknown Type."

   Therefore, RADIUS clients or servers that do not support the CUI may
   ignore the attribute.

   A RADIUS client requesting the CUI attribute in an Access-Accept
   packet MUST include within the Access-Request packet a CUI attribute.
   For the initial authentication, the CUI attribute will include a
   single NUL character (referred to as a nul CUI).  And, during




Adrangi, et al.             Standards Track                     [Page 5]