One document matched: draft-adrangi-radius-chargeable-user-identity-01.txt
Differences from draft-adrangi-radius-chargeable-user-identity-00.txt
Network Working Group Farid Adrangi
INTERNET DRAFT Intel Corporation
Category: Informational (or standards?) Avi Lior
Expires: Feb 27, 2005 Bridgewater Systems
Jouni Korhonen
Teliasonera
Sept 27, 2004
Chargeable User Identity
draft-adrangi-radius-chargeable-user-identity-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667. By submitting this Internet-
Draft, each author represents that any applicable patent or other
IPR claims of which he or she is aware have been or will be
disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
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.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a new RADIUS attribute used by a home RADIUS
to indicate Chargeable User Identity to all parties involved in the
roaming transaction outside the home network.
Table of Contents
1. Introduction...................................................2
Adrangi, et al. Expires Feb 27, 2005 [Page 1]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
1.1 Requirements language..........................................3
2. Operation.......................................................3
2.1 Chargeable User Identity Attribute.............................3
3. Diameter RADIUS Interoperability................................6
4. IANA Considerations.............................................6
5. Security Considerations.........................................6
6. Acknowledgements................................................6
7. References......................................................6
AuthorsÆ Addresses.................................................7
1. Introduction
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., @example.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 could be problems. Because Local and intermediate networks
may require a user identity in order to enforce usage policies.
For example, local or intermediate networks may wish to implement
a limit on simultaneous sessions, and/or may require a billable
user identity in order to demonstrate willingness to pay and limit
the potential for fraud.
This basically implies that a unique identity known by the home
network needs to be conveyed to all parties involved in the
roaming transaction for correlating the authentication and
accounting packets.
Providing a unique identity to intermediaries is therefore a
requirement to fulfill certain business needs. This fulfillment
need not undermine the need to protect the anonymity of the user.
The mechanism provided by this draft allows the home operator to
meet these business requirements by providing a temporal identity
representing the subscriber and at the same time protecting the
anonymity of the subscriber.
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 intermediary between
the NAS and the home RADIUS server, the use of aforementioned
attributes could lead to problems as described below.
O On use of RADIUS Class (25) attribute, [1] states ôThis
Attribute is available to be sent by the server to the client
in an Access-Accept and SHOULD be sent unmodified by the client
to the accounting server as part of the Accounting-Request
Adrangi, et al. Expires February 27, 2005 [Page 2]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
packet if accounting is supported. The client MUST NOT
interpret the attribute locally.ö So RADIUS clients MUST NOT
interpret the Class attribute, which precludes determining
whether it contains a chargeable identity.
O On use of RADIUS UserName(1), the home network could use
UserName(1) in the Access Accept message to convey the
chargeable user identity to intermediaries and the NAS.
However, as the Access-Accept packet is routed to the NAS, the
UserName(1) attribute could be (completely) rewritten by an
intermediary and therefore the NAS or other intermediaries
along the way will not have access to the CUI. Furthermore,
the NAS may use the original value of the UserName attribute (
the one sent in the Access-Request packet) in the Accounting-
Request packets. In this case, intermediaries will not have
access to the CUI.
The Chargeable User Identity (CUI) attribute provides a solution
to the above problem and avoids overloading the use of current
RADIUS attributes (e.g., UserName(1) re-write). 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 to such that it can be used to identify the user.
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 the Diameter protocol as specified in[RFC
3588, NASREQ].
2.1 Chargeable User Identity Attribute
This attribute serves as an alias to the userÆs identity. 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. Entities (e.g., NASes, proxies) outside the home
network MUST NOT modify the Chargeable User Identity attribute.
Adrangi, et al. Expires February 27, 2005 [Page 3]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
In cases where the home RADIUS server cannot determine the NAS
support for CUI attribute, it MUST send both the UserName (1)
attribute and CUI attribute, with the understanding that if the
NAS supports the CUI attribute the CUI attribute will override
the identity portion the UserName (1) attribute. That is, the
UserName(1) attribute will be used for routing and the CUI
attribute will be used for identity purposes.
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 Chargeable User Identity Attribute is
given 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
Chargeable User Identity
Type
To be assigned by IANA
Length
>= 6
String
The string identifies the CUI of the end-user and is of type
UTF8String. It consists of two colon separated parts. The
first part determines the Chargeable-User-Identity type and
the second part is the actual Chargeable-User-Identity
value. The Chargeable-User-Identity type is coded as two
octet string. The Chargeable-User-Identity value must be at
least one octet.
The following User-Identity types have been defined:
00 û E.164 number
The identifier is in international E.164 format
(e.g. MSISDN, according to the ITU-T E.164
numbering plan as defined in [6] and [7]).
01 û IMSI
Adrangi, et al. Expires February 27, 2005 [Page 4]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
The is in international IMSI format according to the
ITU-T E.212 numbering plan as defined in [8] and
[9]).
02 û SIP URL
The identifier is in the form of a SIP URI as defined
(as defined in [10]).
03 û NAI
The identifier is in the form of a Network Access
Identifier as defined in [5].
04 û Opaque string
Opaque string is a value that is assigned to the user
by the home network in an unspecified format. where
the home network asserts that this value represents a
particular user û itÆs a handle to the user.
05 û reserved
The length of time for which the Chargeable User Identity 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 Chargeable User Identity strings with
NAI and E.164 Charging Types:
ö02:charging-id@realm.orgö
ö03:+4689761234ö
ö05:charging-idö
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.
The following table provides a guide to which attribute(s) may be
found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute
Request
0 0-1 0 0 0-1 TBD Chargeable User ID
[Note 1] If the Access Accept contains Chargeable-User-Identity then
the NAS MUST include the Chargeable-User-Identity in Accounting
Requests (Start, Interim and Stop) packets.
Change of Authorization and Disconnect-Request
Request ACK NAK # Attribute
0-1 0 0 TBD Chargeable User
Adrangi, et al. Expires February 27, 2005 [Page 5]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
[Note 2] Where Chargeable-User-Identity attribute is included in
Disconnect-Request or CoA-Request messages, it is used for session
identification purposes only. This attribute MUST NOT be used for
purposes other than identification (e.g. within CoA-Request messages
to request authorization changes).
3. Diameter RADIUS Interoperability
In deployments where both RADIUS clients talking with Diameter
Servers or Diameter Client talking with RADIUS server then a
translation agent will be deployed and operate in accordance to
the NASREQ specification. A counterpart Diameter AVP with a
similar content to Chargeable-User-Identity is Diameter Credit-
Control ApplicationÆs Subscription-ID AVP [11].
4. IANA Considerations
This document requires the assignment of a new RADIUS attribute
number for the Chargeable User Identity attribute.
5. Security Considerations
The Chargeable-User-Identity attribute must be protected against
Man-in-the-Middle attacks. The Chargeable-User-Identity appears
in Access-Accept and Accounting Requests packets and is protected
by the mechanisms that are defined for RADIUS [1] and [2].
Therefore there are no additional security considerations beyond
those already identified in [1] and [2].
Message-Authenticator (80) and Event-Timestamp can be used to
further protect against Man-in-the-middle attacks.
In this document we require that entities outside the home network
not modify the value of this attribute yet there are no provisions
for protecting against or detecting that a RADIUS Proxy has
modified the attribute.
6. Acknowledgements
The authors would like to thank Jari Arkko (of Ericsson), Bernard
Aboba (of Microsoft), Blair Bullock (of iPass), Sami Ala-luukko
(of Teliasonera), Eugene Chang (of Funk), Mark Grayson (of
Cisco), David Mariblanca for their feedback and guidance.
7. References
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Server (RADIUS)", RFC 2865, June
2000.
Adrangi, et al. Expires February 27, 2005 [Page 6]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
[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.
[5] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", draft-arkko-roamops-rfc2486bis-02 (work in
progress), July 2004.
[6] Recommendation E.164/I.331 (05/97): The International Public
Telecommunication Numbering Plan. 1997.
[7] Complement to ITU-T Recommendation E.164 (05/1997):"List of
ITU-T Recommendation E.164 assigned country codes", June 2000.
[8] Recommendation E.212 (11/98): The international
identification plan for mobile terminals and mobile users.
1998.
[9] Complement to ITU-T Recommendation E.212 (11/1997):" List of
mobile country or geographical area codes ", February 1999.
[10] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
G. Camarillo, A. Johnston, J. Peterson, R. Sparks
"SIP: Session Initiation Protocol", RFC 3261. June 2002.
[11] Hakala, H., Mattila, L., Koskinen, J.-P., Stura M., and
Loughney J., "Diameter Credit-Control Application", draft-
ietf-aaa-diameter-cc-06.txt (work in progress), September
2004.
AuthorsÆ Addresses
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro OR
USA
Phone: 503-712-1791
Email: farid.adrangi@intel.com
Avi Lior
Bridgewater Systems Corporation
Adrangi, et al. Expires February 27, 2005 [Page 7]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: 613-591-9104 ;x 6417
Email: avi@bridgewatersystems.com
Jouni Korhonen
Teliasonera Corporation
Phone: +358405344455
Email: jouni.korhonen@teliasonera.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository athttp://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Adrangi, et al. Expires February 27, 2005 [Page 8]
Internet Draft RADIUS Chargeable User Identity 27 Sept 2004
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Adrangi, et al. Expires February 27, 2005 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 13:10:05 |