Internet DRAFT - draft-adrangi-radius-attributes-extension

draft-adrangi-radius-attributes-extension



   Network Working Group                            Farid Adrangi  
   INTERNET DRAFT                                   Intel Corporation 
   Category: Informational                          Avi Lior 
   Expires: Dec 10, 2004                            Bridgewater Systems      
                                                    Jouni Korhonen  
                                                    Teliasonera 
                                                    July 16, 2004 
                 
                          RADIUS Attributes Extension 
                draft-adrangi-radius-attributes-extension-01.txt 
                                            
    
   Status of this Memo 
    
        This document is an Internet-Draft and is in full conformance 
        with all provisions of Section 10 of RFC2026. 
         
        Internet-Drafts  are  working  documents  of  the  Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups. Note that other groups may also distribute working 
        documents as Internet-Drafts. 
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress." 
         
        The  list  of  current  Internet-Drafts  can  be  accessed  at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
         
         
   Abstract 
 
   This document describes additional Remote Authentication Dial In 
   User Service (RADIUS) [1] attributes for use of RADIUS AAA 
   (Authentication, Authorization, Accounting) in both Wireless and 
   wired networks. It contains an IPv4 address type control mechanism, 
   mobile IPv4 home agent discovery mechanism, and a RADIUS 
   capabilities discovery mechanism. 











     
   Adrangi, et al.          Expires Dec 16, 2004             [Page 1] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
   Table of Contents 
    
   1. Introduction....................................................2 
   1.1 Requirements language..........................................2 
   2. Operation.......................................................2 
   2.1 RADIUS Support for Specifying User Identity Alias..............3 
   2.2 RADIUS Support for Advertising Application-based capabilities..5 
   2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 
   2.4 RADIUS Support for Specifying IPv4 Address Type Options........7 
   3. IANA Considerations.............................................9 
   4. Security Considerations.........................................9 
   5. Acknowledgements................................................9 
   6. References......................................................9 
   AuthorsĖ Addresses................................................10 
 
 
    
   1. Introduction  
    
     
    Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the 
    dominant Authentication, Authorization, and Accounting (AAA) 
    protocol in use across broadband wireless and wired networks 
    globally.  
     
    This document describes a number of additional attributes that are 
    needed to enable use of RADIUS AAA in various types of access 
    network in an interoperable manner.   
    
    This document describes a number of additional attributes 
    for the RADIUS and Diameter AAA protocols. These attributes 
    are needed to provide additional AAA functions for wired and 
    wireless access networks. Some of these functions already 
    exist as vendor-specific solutions, but this draft makes these 
    functions interoperable among different vendors. 
 
   1.1 Requirements language 
 
      In this document, several words are used to signify the 
      requirements of the specification.  These words are often 
      capitalized.  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]. 
    
 
   2. Operation 
 
     This document assumes that the RADIUS protocol operates as 
     specified in [1, 2] and that the Diameter protocol operates as 
     specified in[RFC 3588, NASREQ]. 
 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 2] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
 
 
   2.1 RADIUS Support for Specifying User Identity Alias  
    
    
      Rationale 
         
        In certain authentication methods such as, EAP-PEAP or EAP-
        TTLS, EAP-SIM, and EAP-AKA, the true identity of the subscriber 
        can be hidden from the RADIUS AAA servers outside the 
        subscriberĖs home network.  In these methods the User-name(1) 
        attribute contains an anonymous identity (e.g., 
        anonymous@homerealm.com) sufficient to route the RADIUS packets 
        to the home network but otherwise insufficient to identify the 
        subscriber.  While this mechanism is good practice there are 
        situations where this creates problems:  
         
        - In certain roaming situations intermediaries and visited 
           network require to be able to correlate an authentication 
           session with a user identity known to the userĖs home 
           network ķ for example: a broker may require to implement a 
           policy where by only session is allowed per user entity; 
           third party billing brokers may require to match accounting 
           records to a user identity. 
        - NAS may require to match the user session and accounting 
           records to a user identity known to the userĖs home network. 
         
        The User Identity Alias provides a solution to the above 
        problem.  When the home network assigns a value to the User 
        Identity Alias 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 to such that it can be used to identify the user. 
         
       
      Attribute 
       
        This attribute indicates userĖs identity alias. It is assigned 
        by the home RADIUS server and MAY be sent in Access-Accept 
        message.  The NAS or the access network AAA server MUST include 
        this attribute in the Accounting Requests (Start, Interim, and 
        Stop) messages if it was included in the Access Accept message.  
        Intermediaries  MUST  NOT  modify  the  User  Alias  Identity 
        attribute. 
         
        If the RADIUS server includes this attribute in an Access-
        Accept message it MAY also use this attribute as one of the 
        identity attributes in a Disconnect Message and Change of 
        Authorization message defined by [4]. 
         
        A summary of the RADIUS User Identity Alias Attribute is shown 
        below. 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 3] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
       
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |    Length     | String...          
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
        Name 
           
           User Identity Alias 
         
        Type 
         
           To be assigned by IANA 
         
        Length 
         
           >= 6 
         
        String 
 
           The string field is six or more octets. This non-NULL 
           terminated string consists of two colon separated parts. The 
           first part determines the User Identity Alias type and the 
           second part is the actual User Identity Alias value. The 
           User-Identity-Alias type  is coded as  two octet hexadecimal 
           string,. The User Identity Alias value must be at least one 
           octet. 
            
           The following User-Identity Alias types have been defined: 
            
           00 ķ reserved 
           01 ķ IMSI 
           02 ķ NAI 
           03 ķ E.164 number 
           04 ķ SIP URL (as defined in [13]) 
           05 ķ Opaque string 
            
           Opague string is a value that is assigned to the user by the 
           home network where the home network asserts that this value 
           represents a particular user ķ itĖs a handle to the user.  
           The length of time for which this assertion is valid is 
           unspecified by this specification and typically would be 
           long enough to serve some business needs and short enough 
           such that it minimizes the chance of revealing the true 
           identity of the user (either directly or indirectly).  
            
           Below are examples of User Identity Alias strings with NAI 
           and E.164 Charging Types: 
            
             ÷02:charging-id@realm.org÷ 
             ÷03:+4689761234÷ 
            
  
   Adrangi, et al.        Expires November 13, 2004           [Page 4] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
           Ideally, the real user identity should not be revealed 
           through this attribute.  However, the operators will have 
           the final word on the used charging type and its identifier.  
            
           Additional User Identity Alias types may be assigned in 
           revised versions of this RFC. 
       
 
   2.2 RADIUS Support for Advertising Application-based capabilities  
    
      Rationale 
    
        There  is  a  need  for  a  home  RADIUS  server  to  discover 
        capabilities of a NAS that has initiated a connection to it.  
        The capabilities indicate standard-based applications (e.g., 
        existing dynamic authorization Extension to Remote [5], future 
        prepaid accounting model, etc.) that a NAS supports.  This 
        enables the home RADIUS server to decide which application 
        services it can use for the connection, or whether or not it 
        should accept the connection.  For example, if the subscriber 
        is a prepaid subscriber, and the NAS does not support the 
        prepaid capability, the RADIUS server may want to reject the 
        connection.   
         
 
      Attribute 
 
        This attribute describes standard-based capabilities that a NAS 
        supports.  Zero or more of these attribute are available to be 
        sent in Access-Request. 
 
        A summary of the capability Attribute is shown below. 
    
   0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |    Length     |  Integer                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Name  
      
     Generic Capability 
    
   Type 
    
     To be assigned by IANA 
    
   Length 
    
     = 6 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 5] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
    
   Integer 
    
   The format of this Integer is as follows: 
    
   0xCCCTSSSS 
    
   Where: 
     CCC is a 12-bit indicator that identifies the capability ID.  
     CCC = 0x000 and 0xFFF is reserved.   
    
     T is a 4-bit indicator used for extending the sub-capability   
     space. T = 0xF is reserved. 
      
     SSSS is 16-bit indicator that identifies the sub-capabilities ID.  
     These are determined by the application writer and may represent a 
     number of mutually exclusive sub-capabilities or mutually 
     inclusive sub-capabilities codes as bits. 
    
   Extension of sub-capabilities: 
    
      T=0x0 represents the first 16 bits of sub-capabilities 
      T=0x1 represents the next  16 bits of sub-capabilities 
      T=0xF represents the last  16 bits of sub-capabilities 
    
   The following Capability Identities are assigned by this RFC. 
   Additional capability ids may be assigned later.  See the IANA 
   section. 
    
   EditorĖs note: we have to assign some capabilities from radius and 
   also sub-capabilities. Candidates would be from RFCs 2865, 2869, 
   2867, 3162, 3576, 3580.   
      
    
   2.3 RADIUS Support for Specifying a Mobile IP Home Agent  
 
      Rationale 
    
        In Mobile IP [7], a Mobile-IP enabled client registers with its 
        home agent when it attaches to the network for the first time, 
        or when it changes its network point of attachment.  In typical 
        service  provider  deployments,  networks  are  geographically 
        dispersed within a single large administrative domain.  In such 
        networks, it is possible to deploy the home agents in each 
        geographical area.  When a client authenticates to its home 
        network through a NAS, the home RADIUS server may want to 
        specify the home agent for that client based on the NAS 
        location information.   
 
        There is a need for an interoperable method by which the home 
        RADIUS server can indicate the Mobile IP home agent that MUST 
        used by the client to the NAS.  The home agent address can 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 6] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
        later be indicated to the client through several means ķ for 
        example, it can be relayed in the ÷home agent address÷ field of 
        a DHCP reply if the client acquires its IP address through DHCP 
        [8]. 
    
      Attribute (IPv4 version) 
    
        This attribute indicates the home agent IPv4 Address that can 
        be used by a Mobile-IP enabled client.  This attribute is 
        available to be sent in Access-Accept. 
         
         
        A summary of the RADIUS Mobile IPv4 home agent Attribute is 
        shown below. 
    
       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |    Length     |            Address 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
               Address (cont)         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
    
    
    
         Name 
    
           Mobile IPv4 Home Agent 
    
        Type 
         
          To be assigned by IANA 
         
        Length 
         
          6 
         
        Address 
         
           The Address filed is four octets.  It contains a Mobile IP 
           home agent address. 
 
 
   2.4 RADIUS Support for Specifying IPv4 Address Type Options 
    
      Rationale 
    
        An access network may have an option of assigning a layer 3 
        public (i.e., routable) or private (i.e., non-routable) address 
        to the authorized clients.  If the option is available, the 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 7] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
        home network may also want to influence which address type 
        (i.e., public or private) should be assigned to the client 
        depending on the clientĖs subscription profile.  
         
        There is a need for an interoperable method by which a NAS can 
        indicate its currently available IPv4 address type options to a 
        home network for a given client. And then, the home network can 
        specify the desired IPv4 address type option to be used for 
        assigning an IPv4 address to the client. 
    
      Attribute 
         
        This attribute indicates IPv4 address type options. In RADIUS, 
        it can be present in Access-Request, and Access-Accept 
        messages.  In Diameter, it can be present in AAR, AAA, and RAR 
        commands. In both protocols, it can be present in 
        Accounting-Request messages where the Acc-Status-Type is set to 
        Start or Stop.  When it is used in an Access-Accept and 
        Accounting-Request packets, the Address Type value MUST be 1 or 
        2. 
         
        A NAS includes this attribute in the RADIUS Access-Accept or 
        Diameter AAR to advertise its supported IPv4 address type 
        options.  An AAA server includes this attribute in the RADIUS 
        Access-Accept packet or Diameter AAA and RAR commands to 
        specify an IPv4 address type option for the access network 
        client. 
 
        An AAA server MUST NOT include this attribute in the RADIUS 
        Access-Accept or Diameter AAA and PAR if the IPv4 Address Type 
        options were not advertised by the NAS.  If an invalid IPv4 
        Address Type option is received, then the NAS MUST treat it as 
        an RADIUS Access-Reject or Diameter AA-Answer with Result-Code 
        AVP set to ???.  Otherwise, the access network MUST assign an 
        IPv4 address according to the specified type option, and the 
        NAS MUST include this attribute in Accounting-Request packets 
        to indicate the used IPv4 address type option.  If an IPv4 
        address type option is not specified in the RADIUS Access-
        Accept or Diameter RAR and AAA commands, the NAS MUST NOT 
        include this attribute in Accounting-Request packets. 
          
        A summary of the RADIUS IPv4 Address Type Option Attribute is 
        shown below. 
    
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |    Length     |IPv4 Addr. Type| 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
        Name  
         
  
   Adrangi, et al.        Expires November 13, 2004           [Page 8] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
          IPv4 Address Type Options 
         
        Type 
         
          To be assigned by IANA 
         
        Length 
         
          1 
         
        Address Type 
         
          1 : Public Address Type 
          2 : Private Address Type 
          3 : Public and Private Type 
 
 
   3. IANA Considerations 
 
     This draft introduces new RADIUS Attributes.  Therefore, there is 
     a need for obtaining new attribute TYPE numbers from IANA.  
 
     New enumerated values within the attributes defined here can be 
     allocated using the policies defined in RFC 3575, i.e., Designated 
     Expert. 
 
   4. Security Considerations 
    
     The attributes in this document have no additional security 
     considerations beyond those already identified in [?]. 
 
    
   5. Acknowledgements 
 
     The authors would like to thank Jari Arkko for his extensive 
     contribution and comments in improving the draft. 
    
    
   6. References 
 
     [1]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote    
          Authentication Dial In User Server (RADIUS)", RFC 2865, June  
          2000.  
                        
     [2]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.  
                        
     [3]  Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions",  
          RFC 2869, June 2000.  
    
     [4] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B.,  
         ÷Dynamic Authorization Extensions to Remote Authentication 
         Dial In User Service (RADIUS)÷, RFC 3576, July 2003. 
  
   Adrangi, et al.        Expires November 13, 2004           [Page 9] 
    
   Internet Draft     RADIUS Attributes Extension        16 July 2004 
               
 
    
 
                           
   AuthorsĖ Addresses 
    
   Farid  Adrangi     
   Email: farid.adrangi@intel.com       Phone:+1 503-712-1791 
    
   Avi Lior 
   Email: avi@bridgewatersystems.com 
    
   Jouni Korhonen 
   Email: jouni.korhonen@teliasonera.com 
    
   Full Copyright Statement 
    
        Copyright  (C)  The  Internet  Society  (2002).    All  Rights 
        Reserved. 
         
        This  document  and  translations  of  it  may  be  copied  and 
        furnished to others, and derivative works that comment on or 
        otherwise explain it or assist in its implementation may be 
        prepared, copied, published and distributed, in whole or in 
        part, without restriction of any kind, provided that the above 
        copyright notice and this paragraph are included on all such 
        copies and derivative works.  However, this document itself may 
        not be modified in any way, such as by removing the copyright 
        notice or references to the Internet Society or other Internet 
        organizations, except as needed for the purpose of developing 
        Internet standards in which case the procedures for copyrights 
        defined in the Internet Standards process must be followed, or 
        as required to translate it into languages other than English. 
         
        The limited permissions granted above are perpetual and will 
        not be revoked by the Internet Society or its successors or 
        assigns. 
         
        This document and the information contained herein is provided 
        on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
        ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
        IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 
        OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 
        IMPLIED  WARRANTIES  OF  MERCHANTABILITY  OR  FITNESS  FOR  A 
        PARTICULAR PURPOSE.                             
                 
         
   Acknowledgement 
         
        Funding for the RFC Editor function is currently provided by 
        the Internet Society. 
         
         
  
   Adrangi, et al.        Expires November 13, 2004          [Page 10]