doc/rfc/rfc4372.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         F. Adrangi
   8 Request for Comments: 4372                                         Intel
   9 Category: Standards Track                                        A. Lior
  10                                                      Bridgewater Systems
  11                                                              J. Korhonen
  12                                                              Teliasonera
  13                                                              J. Loughney
  14                                                                    Nokia
  15                                                             January 2006
  16
  17
  18                         Chargeable User Identity
  19
  20 Status of This Memo
  21
  22    This document specifies an Internet standards track protocol for the
  23    Internet community, and requests discussion and suggestions for
  24    improvements.  Please refer to the current edition of the "Internet
  25    Official Protocol Standards" (STD 1) for the standardization state
  26    and status of this protocol.  Distribution of this memo is unlimited.
  27
  28 Copyright Notice
  29
  30    Copyright (C) The Internet Society (2006).
  31
  32 Abstract
  33
  34    This document describes a new Remote Authentication Dial-In User
  35    Service (RADIUS) attribute, Chargeable-User-Identity.  This attribute
  36    can be used by a home network to identify a user for the purpose of
  37    roaming transactions that occur outside of the home network.
  38
  39 Table of Contents
  40
  41    1. Introduction ....................................................2
  42       1.1. Motivation .................................................3
  43       1.2. Terminology ................................................4
  44    2. Operation .......................................................5
  45       2.1. Chargeable-User-Identity (CUI) Attribute ...................5
  46       2.2. CUI Attribute ..............................................6
  47    3. Attribute Table .................................................7
  48    4. Diameter Consideration ..........................................7
  49    5. IANA Considerations .............................................7
  50    6. Security Considerations .........................................7
  51    7. Acknowledgements ................................................8
  52    8. References ......................................................8
  53       8.1. Normative References .......................................8
  54       8.2. Informative References .....................................8
  55
  56
  57
  58 Adrangi, et al.             Standards Track                     [Page 1]
  59 \f
  60 RFC 4372                Chargeable User Identity            January 2006
  61
  62
  63 1.  Introduction
  64
  65    Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM
  66    and EAP-AKA, can hide the true identity of the user from RADIUS
  67    servers outside of the user's home network.  In these methods, the
  68    User-Name(1) attribute contains an anonymous identity (e.g.,
  69    @example.com) sufficient to route the RADIUS packets to the home
  70    network but otherwise insufficient to identify the user.  While this
  71    mechanism is good practice in some circumstances, there are problems
  72    if local and intermediate networks require a surrogate identity to
  73    bind the current session.
  74
  75    This document introduces an attribute that serves as an alias or
  76    handle (hereafter, it is called Chargeable-User-Identity) to the real
  77    user's identity.  Chargeable-User-Identity can be used outside the
  78    home network in scenarios that traditionally relied on User-Name(1)
  79    to correlate a session to a user.
  80
  81    For example, local or intermediate networks may limit the number of
  82    simultaneous sessions for specific users; they may require a
  83    Chargeable-User-Identity in order to demonstrate willingness to pay
  84    or otherwise limit the potential for fraud.
  85
  86    This implies that a unique identity provided by the home network
  87    should be able to be conveyed to all parties involved in the roaming
  88    transaction for correlating the authentication and accounting
  89    packets.
  90
  91    Providing a unique identity, Chargeable-User-Identity (CUI), to
  92    intermediaries, is necessary to fulfill certain business needs.  This
  93    should not undermine the anonymity of the user.  The mechanism
  94    provided by this document allows the home operator to meet these
  95    business requirements by providing a temporary identity representing
  96    the user and at the same time protecting the anonymity of the user.
  97
  98    When the home network assigns a value to the CUI, it asserts that
  99    this value represents a user in the home network.  The assertion
 100    should be temporary -- long enough to be useful for the external
 101    applications and not too long such that it can be used to identify
 102    the user.
 103
 104    Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
 105    and IRAP, have been studying mechanisms to provide roaming services,
 106    using RADIUS.  Missing elements include mechanisms for billing and
 107    fraud prevention.
 108
 109
 110
 111
 112
 113
 114 Adrangi, et al.             Standards Track                     [Page 2]
 115 \f
 116 RFC 4372                Chargeable User Identity            January 2006
 117
 118
 119    The CUI attribute is intended to close operational loopholes in
 120    RADIUS specifications that have impacted roaming solutions
 121    negatively.  Use of the CUI is geared toward EAP methods supporting
 122    privacy (such as PEAP and EAP-TTLS), which are, for the most part,
 123    recent deployments.  A chargeable identity reflecting the user
 124    profile by the home network is needed in such roaming scenarios.
 125
 126 1.1.  Motivation
 127
 128    Some other mechanisms have been proposed in place of the CUI
 129    attribute.  These mechanisms are insufficient or cause other
 130    problems.  It has been suggested that standard RADIUS Class(25) or
 131    User-Name(1) attributes could be used to indicate the CUI.  However,
 132    in a complex global roaming environment where there could be one or
 133    more intermediaries between the NAS [RFC4282] and the home RADIUS
 134    server, the use of aforementioned attributes could lead to problems
 135    as described below.
 136
 137       - On the use of RADIUS Class(25) attribute:
 138
 139       [RFC2865] states: "This Attribute is available to be sent by the
 140       server to the client in an Access-Accept packet and SHOULD be sent
 141       unmodified by the client to the accounting server as part of the
 142       Accounting-Request packet if accounting is supported.  The client
 143       MUST NOT interpret the attribute locally."  So RADIUS clients or
 144       intermediaries MUST NOT interpret the Class(25) attribute, which
 145       precludes determining whether it contains a CUI.  Additionally,
 146       there could be multiple class attributes in a RADIUS packet, and
 147       since the contents of Class(25) attribute is not to be interpreted
 148       by clients, this makes it hard for the entities outside the home
 149       network to determine which one contains the CUI.
 150
 151       - On the use of RADIUS User-Name(1) attribute:
 152
 153       The User-Name(1) attribute included in the Access-Request packet
 154       may be used for the purpose of routing the Access-Request packet,
 155       and in the process may be rewritten by intermediaries.  As a
 156       result, a RADIUS server receiving an Access-Request packet relayed
 157       by a proxy cannot assume that the User-Name(1) attribute remained
 158       unmodified.
 159
 160       On the other hand, rewriting of a User-Name(1) attribute sent
 161       within an Access-Accept packet occurs more rarely, since a
 162       Proxy-State(33) attribute can be used to route the Access-Accept
 163       packet without parsing the User-Name(1) attribute.  As a result, a
 164       RADIUS server cannot assume that a proxy stripping routing
 165       information from a User-Name(1) attribute within an Access-Request
 166       packet will add this information to a User-Name(1) attribute
 167
 168
 169
 170 Adrangi, et al.             Standards Track                     [Page 3]
 171 \f
 172 RFC 4372                Chargeable User Identity            January 2006
 173
 174
 175       included within an Access-Accept packet.  The result is that when
 176       a User-Name(1) attribute is sent in an Access-Accept packet, it is
 177       possible that the Access-Request packet and Accounting-Request
 178       packets will follow different paths.  Where this outcome is
 179       undesirable, the RADIUS client should use the original
 180       User-Name(1) in accounting packets.  Therefore, another mechanism
 181       is required to convey a CUI within an Access-Accept packet to the
 182       RADIUS client, so that the CUI can be included in the accounting
 183       packets.
 184
 185    The CUI attribute provides a solution to the above problems and
 186    avoids overloading RADIUS User-Name(1) attribute or changing the
 187    usage of existing RADIUS Class(25) attribute.  The CUI therefore
 188    provides a standard approach to billing and fraud prevention when EAP
 189    methods supporting privacy are used.  It does not solve all related
 190    problems, but does provide for billing and fraud prevention.
 191
 192 1.2.  Terminology
 193
 194    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 195    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 196    document are to be interpreted as described in [RFC2119].
 197
 198    The following acronyms are used:
 199
 200       3GPP - Third Generation Partnership Project
 201       AAA - Authentication, Authorization, and Accounting
 202       AKA - Authentication and Key Agreement
 203       CUI - Chargeable-User-Identity
 204       GSMA - GSM Association
 205       IRAP - International Roaming Access Protocols Program
 206       NAS - Network Access Server
 207       PEAP - Protected Extensible Authentication Protocol
 208       SIM - Subscriber Identity Modules
 209       TTLS - Tunneled Transport Layer Security
 210       WISPr - Wireless ISP Roaming
 211       WPA - Wi-Fi Protected Access
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Adrangi, et al.             Standards Track                     [Page 4]
 227 \f
 228 RFC 4372                Chargeable User Identity            January 2006
 229
 230
 231 2.  Operation
 232
 233    This document assumes that the RADIUS protocol operates as specified
 234    in [RFC2865] and [RFC2866], dynamic authorization as specified in
 235    [RFC3576], and the Diameter protocol as specified in [RFC3588].
 236
 237 2.1.  Chargeable-User-Identity (CUI) Attribute
 238
 239    The CUI attribute serves as an alias to the user's real identity,
 240    representing a chargeable identity as defined and provided by the
 241    home network as a supplemental or alternative information to
 242    User-Name(1).  Typically, the CUI represents the identity of the
 243    actual user, but it may also indicate other chargeable identities
 244    such as a group of users.  RADIUS clients (proxy or NAS) outside the
 245    home network MUST NOT modify the CUI attribute.
 246
 247    The RADIUS server (a RADIUS proxy, home RADIUS server) may include
 248    the CUI attribute in the Access-Accept packet destined to a roaming
 249    partner.  The CUI support by RADIUS infrastructure is driven by the
 250    business requirements between roaming entities.  Therefore, a RADIUS
 251    server supporting this specification may choose not to send the CUI
 252    in response to an Access-Request packet from a given NAS, even if the
 253    NAS has indicated that it supports CUI.
 254
 255    If an Access-Accept packet without the CUI attribute was received by
 256    a RADIUS client that requested the CUI attribute, then the
 257    Access-Accept packet MAY be treated as an Access-Reject.
 258
 259    If the CUI was included in an Access-Accept packet, RADIUS clients
 260    supporting the CUI attribute MUST ensure that the CUI attribute
 261    appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
 262    This requirement applies regardless of whether the RADIUS client
 263    requested the CUI attribute.
 264
 265    RFC 2865 includes the following statements about behaviors of RADIUS
 266    client and server with respect to unsupported attributes:
 267
 268       - "A RADIUS client MAY ignore Attributes with an unknown Type."
 269       - "A RADIUS server MAY ignore Attributes with an unknown Type."
 270
 271    Therefore, RADIUS clients or servers that do not support the CUI may
 272    ignore the attribute.
 273
 274    A RADIUS client requesting the CUI attribute in an Access-Accept
 275    packet MUST include within the Access-Request packet a CUI attribute.
 276    For the initial authentication, the CUI attribute will include a
 277    single NUL character (referred to as a nul CUI).  And, during
 278
 279
 280
 281
 282 Adrangi, et al.             Standards Track                     [Page 5]
 283 \f
 284 RFC 4372                Chargeable User Identity            January 2006
 285
 286
 287    re-authentication, the CUI attribute will include a previously
 288    received CUI value (referred to as a non-nul CUI value) in the
 289    Access-Accept.
 290
 291    Upon receiving a non-nul CUI value in an Access-Request, the home
 292    RADIUS server MAY verify that the value of CUI matches the CUI from
 293    the previous Access-Accept.  If the verification fails, then the
 294    RADIUS server SHOULD respond with an Access-Reject message.
 295
 296    If a home RADIUS server that supports the CUI attribute receives an
 297    Access-Request packet containing a CUI (set to nul or otherwise), it
 298    MUST include the CUI attribute in the Access-Accept packet.
 299    Otherwise, if the Access-Request packet does not contain a CUI, the
 300    home RADIUS server SHOULD NOT include the CUI attribute in the
 301    Access-Accept packet.  The Access-Request may be sent either in the
 302    initial authentication or during re-authentication.
 303
 304    A NAS that requested the CUI during re-authentication by including
 305    the CUI in the Access-Request will receive the CUI in the
 306    Access-Accept.  The NAS MUST include the value of that CUI in all
 307    Accounting Messages.
 308
 309 2.2.  CUI Attribute
 310
 311    A summary of the RADIUS CUI attribute is given below.
 312
 313
 314       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
 315       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 316       |     Type      |    Length     | String...
 317       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 318
 319    Type: 89 for Chargeable-User-Identity.
 320
 321    Length: >= 3
 322
 323    String:
 324
 325       The string identifies the CUI of the end-user.  This string value
 326       is a reference to a particular user.  The format and content of
 327       the string value are determined by the Home RADIUS server.  The
 328       binding lifetime of the reference to the user is determined based
 329       on business agreements.  For example, the lifetime can be set to
 330       one billing period.  RADIUS entities other than the Home RADIUS
 331       server MUST treat the CUI content as an opaque token, and SHOULD
 332       NOT perform operations on its content other than a binary equality
 333       comparison test, between two instances of CUI.  In cases where the
 334
 335
 336
 337
 338 Adrangi, et al.             Standards Track                     [Page 6]
 339 \f
 340 RFC 4372                Chargeable User Identity            January 2006
 341
 342
 343       attribute is used to indicate the NAS support for the CUI, the
 344       string value contains a nul character.
 345
 346 3.  Attribute Table
 347
 348    The following table provides a guide to which attribute(s) may be
 349    found in which kinds of packets, and in what quantity.
 350
 351    Request Accept Reject Challenge Accounting #     Attribute
 352                                     Request
 353      0-1    0-1     0        0        0-1    89 Chargeable-User-Identity
 354
 355    Note: If the Access-Accept packet contains CUI, then the NAS MUST
 356    include the CUI in Accounting Requests (Start, Interim, and Stop)
 357    packets.
 358
 359 4.  Diameter Consideration
 360
 361    Diameter needs to define an identical attribute with the same Type
 362    value.  The CUI should be available as part of the NASREQ application
 363    [RFC4005].
 364
 365 5.  IANA Considerations
 366
 367    This document uses the RADIUS [RFC2865] namespace; see
 368    http://www.iana.org/assignments/radius-types.  The IANA has assigned
 369    a new RADIUS attribute number for the CUI attribute.
 370
 371    CUI 89
 372
 373 6.  Security Considerations
 374
 375    It is strongly recommended that the CUI format used is such that the
 376    real user identity is not revealed.  Furthermore, where a reference
 377    is used to a real user identity, it is recommended that the binding
 378    lifetime of that reference to the real user be kept as short as
 379    possible.
 380
 381    The RADIUS entities (RADIUS proxies and clients) outside the home
 382    network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
 383    However, there is no way to detect or prevent this.
 384
 385    Attempting theft of service, a man-in-the-middle may try to insert,
 386    modify, or remove the CUI in the Access-Accept packets and Accounting
 387    packets.  However, RADIUS Access-Accept and Accounting packets
 388    already provide integrity protection.
 389
 390
 391
 392
 393
 394 Adrangi, et al.             Standards Track                     [Page 7]
 395 \f
 396 RFC 4372                Chargeable User Identity            January 2006
 397
 398
 399    If the NAS includes CUI in an Access-Request packet, a
 400    man-in-the-middle may remove it.  This will cause the Access-Accept
 401    packet to not include a CUI attribute, which may cause the NAS to
 402    reject the session.  To prevent such a denial of service (DoS)
 403    attack, the NAS SHOULD include a Message-Authenticator(80) attribute
 404    within Access-Request packets containing a CUI attribute.
 405
 406 7.  Acknowledgements
 407
 408    The authors would like to thank Jari Arkko, Bernard Aboba, David
 409    Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
 410    David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for
 411    their feedback and guidance.
 412
 413 8.  References
 414
 415 8.1.  Normative References
 416
 417    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 418               Requirement Levels", BCP 14, RFC 2119, March 1997.
 419
 420    [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
 421               "Remote Authentication Dial In User Service (RADIUS)",
 422               RFC 2865, June 2000.
 423
 424    [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 425
 426    [RFC4005]  Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
 427               "Diameter Network Access Server Application", RFC 4005,
 428               August 2005.
 429
 430    [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
 431               Network Access Identifier", RFC 4282, December 2005.
 432
 433 8.2.  Informative References
 434
 435    [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
 436               Aboba, "Dynamic Authorization Extensions to Remote
 437               Authentication Dial In User Service (RADIUS)", RFC 3576,
 438               July 2003.
 439
 440    [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
 441               Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 442
 443
 444
 445
 446
 447
 448
 449
 450 Adrangi, et al.             Standards Track                     [Page 8]
 451 \f
 452 RFC 4372                Chargeable User Identity            January 2006
 453
 454
 455 Authors' Addresses
 456
 457    Farid Adrangi
 458    Intel Corporation
 459    2111 N.E. 25th Avenue
 460    Hillsboro, OR  97124
 461    USA
 462
 463    Phone: +1 503-712-1791
 464    EMail: farid.adrangi@intel.com
 465
 466
 467    Avi Lior
 468    Bridgewater Systems Corporation
 469    303 Terry Fox Drive
 470    Ottawa, Ontario  K2K 3J1
 471    Canada
 472
 473    Phone: +1 613-591-9104
 474    EMail: avi@bridgewatersystems.com
 475
 476
 477    Jouni Korhonen
 478    Teliasonera Corporation
 479    P.O.Box 970
 480    FIN-00051,   Sonera
 481    Finland
 482
 483    Phone: +358405344455
 484    EMail: jouni.korhonen@teliasonera.com
 485
 486
 487    John Loughney
 488    Nokia
 489    Itamerenkatu 11-13
 490    FIN-00180,   Helsinki
 491    Finland
 492
 493    Phone: +358504836342
 494    EMail: john.loughney@nokia.com
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Adrangi, et al.             Standards Track                     [Page 9]
 507 \f
 508 RFC 4372                Chargeable User Identity            January 2006
 509
 510
 511 Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (2006).
 514
 515    This document is subject to the rights, licenses and restrictions
 516    contained in BCP 78, and except as set forth therein, the authors
 517    retain all their rights.
 518
 519    This document and the information contained herein are provided on an
 520    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 521    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 522    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 523    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 524    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 525    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 526
 527 Intellectual Property
 528
 529    The IETF takes no position regarding the validity or scope of any
 530    Intellectual Property Rights or other rights that might be claimed to
 531    pertain to the implementation or use of the technology described in
 532    this document or the extent to which any license under such rights
 533    might or might not be available; nor does it represent that it has
 534    made any independent effort to identify any such rights.  Information
 535    on the procedures with respect to rights in RFC documents can be
 536    found in BCP 78 and BCP 79.
 537
 538    Copies of IPR disclosures made to the IETF Secretariat and any
 539    assurances of licenses to be made available, or the result of an
 540    attempt made to obtain a general license or permission for the use of
 541    such proprietary rights by implementers or users of this
 542    specification can be obtained from the IETF on-line IPR repository at
 543    http://www.ietf.org/ipr.
 544
 545    The IETF invites any interested party to bring to its attention any
 546    copyrights, patents or patent applications, or other proprietary
 547    rights that may cover technology that may be required to implement
 548    this standard.  Please address the information to the IETF at
 549    ietf-ipr@ietf.org.
 550
 551 Acknowledgement
 552
 553    Funding for the RFC Editor function is provided by the IETF
 554    Administrative Support Activity (IASA).
 555
 556
 557
 558
 559
 560
 561
 562 Adrangi, et al.             Standards Track                    [Page 10]
 563 \f