draft-ietf-radext-chargeable-user-id-06.txt   rfc4372.txt 
Network Working Group F. Adrangi Network Working Group F. Adrangi
Internet-Draft Intel Request for Comments: 4372 Intel
Expires: April 15, 2006 A. Lior Category: Standards Track A. Lior
Bridgewater Systems Bridgewater Systems
J. Korhonen J. Korhonen
Teliasonera Teliasonera
J. Loughney J. Loughney
Nokia Nokia
October 12, 2005 January 2006
Chargeable User Identity Chargeable User Identity
draft-ietf-radext-chargeable-user-id-06
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Status of This Memo
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.
This Internet-Draft will expire on April 15, 2006. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a new RADIUS attribute, Chargeable-User- This document describes a new Remote Authentication Dial-In User
Identity. This attribute can be used by a home network to identify a Service (RADIUS) attribute, Chargeable-User-Identity. This attribute
user for the purpose of roaming transactions that occur outside of can be used by a home network to identify a user for the purpose of
the home network. roaming transactions that occur outside of the home network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation .................................................3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology ................................................4
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Operation .......................................................5
2.1. Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5 2.1. Chargeable-User-Identity (CUI) Attribute ...................5
2.2. CUI Attribute . . . . . . . . . . . . . . . . . . . . . . 7 2.2. CUI Attribute ..............................................6
3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 3. Attribute Table .................................................7
4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 8 4. Diameter Consideration ..........................................7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations .............................................7
6. Security considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations .........................................7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements ................................................8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References ......................................................8
8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References .......................................8
8.2. Informative references . . . . . . . . . . . . . . . . . . 9 8.2. Informative References .....................................8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM
and EAP-AKA, can hide the true identity of the user from RADIUS 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 servers outside of the user's home network. In these methods, the
User-Name(1) attribute contains an anonymous identity (e.g., User-Name(1) attribute contains an anonymous identity (e.g.,
@example.com) sufficient to route the RADIUS packets to the home @example.com) sufficient to route the RADIUS packets to the home
network but otherwise insufficient to identify the user. While this network but otherwise insufficient to identify the user. While this
mechanism is good practice in some circumstances, there are problems mechanism is good practice in some circumstances, there are problems
if local and intermediate networks require a surrogate identity to if local and intermediate networks require a surrogate identity to
bind the current session. bind the current session.
This document introduces an attribute that serves as an alias or This document introduces an attribute that serves as an alias or
handle (hereafter, it is called Chargeable-User-Identity) to the real handle (hereafter, it is called Chargeable-User-Identity) to the real
user's identity. Chargeable-User-Identity can be used outside the user's identity. Chargeable-User-Identity can be used outside the
home network in scenarios that traditionaly relied on User-Name(1) to home network in scenarios that traditionally relied on User-Name(1)
correlate a session to a user. to correlate a session to a user.
For example, local or intermediate networks may limit the number of For example, local or intermediate networks may limit the number of
simultaneous sessions for specific users; they may require a simultaneous sessions for specific users; they may require a
Chargeable-User-Identity in order to demonstrate willingness to pay Chargeable-User-Identity in order to demonstrate willingness to pay
or otherwise limit the potential for fraud. or otherwise limit the potential for fraud.
This implies that a unique identity provided by the home network This implies that a unique identity provided by the home network
should be able to be conveyed to all parties involved in the roaming should be able to be conveyed to all parties involved in the roaming
transaction for correlating the authentication and accounting transaction for correlating the authentication and accounting
packets. packets.
Providing a unique identity, Chargeable-User-Identity (CUI), to Providing a unique identity, Chargeable-User-Identity (CUI), to
intermediaries, is necessary to fulfill certain business needs. This intermediaries, is necessary to fulfill certain business needs. This
should not undermine the anonymity of the user. The mechanism should not undermine the anonymity of the user. The mechanism
provided by this draft allows the home operator to meet these provided by this document allows the home operator to meet these
business requirements by providing a temporary identity representing business requirements by providing a temporary identity representing
the user and at the same time protecting the anonymity of the user. 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 When the home network assigns a value to the CUI, it asserts that
this value represents a user in the home network. The assertion this value represents a user in the home network. The assertion
should be temporary. Long enough to be useful for the external should be temporary -- long enough to be useful for the external
applications and not too long such that it can be used to identify applications and not too long such that it can be used to identify
the user. the user.
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
IRAP, have been studying mechanisms to provide roaming services, and IRAP, have been studying mechanisms to provide roaming services,
using RADIUS. Missing elements include mechanisms for billing and using RADIUS. Missing elements include mechanisms for billing and
fraud prevention. fraud prevention.
The CUI attribute is intended to close operational loopholes in The CUI attribute is intended to close operational loopholes in
RADIUS specifications that have impacted roaming solutions RADIUS specifications that have impacted roaming solutions
negatively. Use of the CUI is geared toward EAP methods supporting negatively. Use of the CUI is geared toward EAP methods supporting
privacy (such as PEAP and EAP-TTLS), which are, for the most part, privacy (such as PEAP and EAP-TTLS), which are, for the most part,
recent deployments. A chargeable identity reflecting the user recent deployments. A chargeable identity reflecting the user
profile by the home network is needed in such roaming scenarios. profile by the home network is needed in such roaming scenarios.
1.1. Motivation 1.1. Motivation
Some other mechanisms have been proposed in place of the CUI Some other mechanisms have been proposed in place of the CUI
attribute. These mechanisms are insufficient or cause other attribute. These mechanisms are insufficient or cause other
problems. It has been suggested that standard RADIUS Class(25) or problems. It has been suggested that standard RADIUS Class(25) or
User-Name(1) attributes could be used to indicate the CUI. However, User-Name(1) attributes could be used to indicate the CUI. However,
in a complex global roaming environment where there could be one or in a complex global roaming environment where there could be one or
more intermediaries between the NAS and the home RADIUS server, the more intermediaries between the NAS [RFC4282] and the home RADIUS
use of aforementioned attributes could lead to problems as described server, the use of aforementioned attributes could lead to problems
below. as described below.
- On the use of RADIUS Class(25) attribute: - On the use of RADIUS Class(25) attribute:
[RFC2865] states: "This Attribute is available to be sent by the [RFC2865] states: "This Attribute is available to be sent by the
server to the client in an Access-Accept packet and SHOULD be sent 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 unmodified by the client to the accounting server as part of the
Accounting-Request packet if accounting is supported. The client Accounting-Request packet if accounting is supported. The client
MUST NOT interpret the attribute locally." So RADIUS clients or MUST NOT interpret the attribute locally." So RADIUS clients or
intermediaries MUST NOT interpret the Class(25) attribute, which intermediaries MUST NOT interpret the Class(25) attribute, which
precludes determining whether it contains a CUI. Additionally, precludes determining whether it contains a CUI. Additionally,
there could be multiple class attributes in a RADIUS packet, and there could be multiple class attributes in a RADIUS packet, and
since the contents of Class(25) attribute is not to be interpreted since the contents of Class(25) attribute is not to be interpreted
by clients, this makes it hard to the entities outside home by clients, this makes it hard for the entities outside the home
network to determine which one contains the CUI. network to determine which one contains the CUI.
- On the use of RADIUS User-Name(1) attribute: - On the use of RADIUS User-Name(1) attribute:
The User-Name(1) attribute included in the Access-Request packet The User-Name(1) attribute included in the Access-Request packet
may be used for the purpose of routing 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 and in the process may be rewritten by intermediaries. As a
result, a RADIUS server receiving an Access-Request packet relayed result, a RADIUS server receiving an Access-Request packet relayed
by a proxy cannot assume that the User-Name(1) attribute remained by a proxy cannot assume that the User-Name(1) attribute remained
unmodified. unmodified.
skipping to change at page 4, line 42 skipping to change at page 3, line 45
network to determine which one contains the CUI. network to determine which one contains the CUI.
- On the use of RADIUS User-Name(1) attribute: - On the use of RADIUS User-Name(1) attribute:
The User-Name(1) attribute included in the Access-Request packet The User-Name(1) attribute included in the Access-Request packet
may be used for the purpose of routing 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 and in the process may be rewritten by intermediaries. As a
result, a RADIUS server receiving an Access-Request packet relayed result, a RADIUS server receiving an Access-Request packet relayed
by a proxy cannot assume that the User-Name(1) attribute remained by a proxy cannot assume that the User-Name(1) attribute remained
unmodified. unmodified.
On the other hand, rewriting of a User-Name(1) attribute sent On the other hand, rewriting of a User-Name(1) attribute sent
within an Access-Accept packet occurs more rarely, since a Proxy- within an Access-Accept packet occurs more rarely, since a
State(33) attribute can be used to route the Access-Accept packet Proxy-State(33) attribute can be used to route the Access-Accept
without parsing the User-Name(1) attribute. As a result, a RADIUS packet without parsing the User-Name(1) attribute. As a result, a
server cannot assume that a proxy stripping routing information RADIUS server cannot assume that a proxy stripping routing
from a User-Name(1) attribute within an Access-Request packet will information from a User-Name(1) attribute within an Access-Request
add this information to a User-Name(1) attribute included within packet will add this information to a User-Name(1) attribute
an Access-Accept packet. The result is that when a User-Name(1) included within an Access-Accept packet. The result is that when
attribute is sent in an Access-Accept packet it is possible that a User-Name(1) attribute is sent in an Access-Accept packet, it is
the Access-Request packet and Accounting-Request packets will possible that the Access-Request packet and Accounting-Request
follow different paths. Where this outcome is undesirable, the packets will follow different paths. Where this outcome is
RADIUS client should use the original User-Name(1) in accounting undesirable, the RADIUS client should use the original
packets. Therefore, another mechanism is required to convey a CUI User-Name(1) in accounting packets. Therefore, another mechanism
within an Access-Accept packet to the RADIUS client, so that the is required to convey a CUI within an Access-Accept packet to the
CUI can be included in the accounting packets. RADIUS client, so that the CUI can be included in the accounting
packets.
The CUI attribute provides a solution to the above problems and The CUI attribute provides a solution to the above problems and
avoids overloading RADIUS User-Name(1) attribute or changing the avoids overloading RADIUS User-Name(1) attribute or changing the
usage of existing RADIUS Class(25) attribute. The CUI therefore usage of existing RADIUS Class(25) attribute. The CUI therefore
provides a standard approach to billing and fraud prevention when EAP provides a standard approach to billing and fraud prevention when EAP
methods supporting privacy are used. It does not solve all related methods supporting privacy are used. It does not solve all related
problems, but does provide for billing and fraud prevention. problems, but does provide for billing and fraud prevention.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3GPP - Third Generation Partnership Program The following acronyms are used:
AAA - Authentication, Authorization and Accounting
3GPP - Third Generation Partnership Project
AAA - Authentication, Authorization, and Accounting
AKA - Authentication and Key Agreement
CUI - Chargeable-User-Identity CUI - Chargeable-User-Identity
GSMA - GSM Association GSMA - GSM Association
IRAP - International Roaming Access Protocols Program IRAP - International Roaming Access Protocols Program
NAS - Network Access Server NAS - Network Access Server
PEAP - Protected Extensible Authentication Protocol PEAP - Protected Extensible Authentication Protocol
SIM - Subscriber Identity Modules
TTLS - Tunneled Transport Layer Security TTLS - Tunneled Transport Layer Security
WISPr - Wireless ISP Roaming WISPr - Wireless ISP Roaming
WPA - Wi-Fi Protected Access WPA - Wi-Fi Protected Access
2. Operation 2. Operation
This document assumes that the RADIUS protocol operates as specified This document assumes that the RADIUS protocol operates as specified
in [RFC2865], [RFC2866], dynamic authorization as specified in in [RFC2865] and [RFC2866], dynamic authorization as specified in
[RFC3576], and the Diameter protocol as specified in [RFC3588]. [RFC3576], and the Diameter protocol as specified in [RFC3588].
2.1. Chargeable-User-Identity (CUI) Attribute 2.1. Chargeable-User-Identity (CUI) Attribute
The CUI attribute serves as an alias to the user's real identity, The CUI attribute serves as an alias to the user's real identity,
representing a chargeable identity as defined and provided by the representing a chargeable identity as defined and provided by the
home network as a supplemental or alternative information to User- home network as a supplemental or alternative information to
Name(1). Typically the CUI represents the identity of the actual User-Name(1). Typically, the CUI represents the identity of the
user but it may also indicate other chargeable identities such as a actual user, but it may also indicate other chargeable identities
group of users. RADIUS clients (proxy or NAS) outside the home such as a group of users. RADIUS clients (proxy or NAS) outside the
network MUST NOT modify the CUI attribute. home network MUST NOT modify the CUI attribute.
The RADIUS server (a RADIUS proxy, home RADIUS server) may include The RADIUS server (a RADIUS proxy, home RADIUS server) may include
the CUI attribute in the Access-Accept packet destined to a roaming the CUI attribute in the Access-Accept packet destined to a roaming
partner. The CUI support by RADIUS infrastructure is driven by the partner. The CUI support by RADIUS infrastructure is driven by the
business requirements between roaming entities. Therefore a RADIUS business requirements between roaming entities. Therefore, a RADIUS
server supporting this specification may choose not to send the CUI 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 in response to an Access-Request packet from a given NAS, even if the
NAS has indicated that it supports CUI. NAS has indicated that it supports CUI.
If an Access-Accept packet without the CUI attribute was received by If an Access-Accept packet without the CUI attribute was received by
a RADIUS client that requested the CUI attribute, then the Access- a RADIUS client that requested the CUI attribute, then the
Accept packet MAY be treated as an Access-Reject. Access-Accept packet MAY be treated as an Access-Reject.
If the CUI was included in an Access-Accept packet, RADIUS clients If the CUI was included in an Access-Accept packet, RADIUS clients
supporting the CUI attribute MUST ensure that the CUI attribute supporting the CUI attribute MUST ensure that the CUI attribute
appears in the RADIUS Accounting-Request (Start, Interim, and Stop). appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
This requirement applies regardless of whether the RADIUS client This requirement applies regardless of whether the RADIUS client
requested the CUI attribute. requested the CUI attribute.
RFC 2865 includes the following statements about behaviors of RADIUS RFC 2865 includes the following statements about behaviors of RADIUS
client and server with respect to unsupported attributes: client and server with respect to unsupported attributes:
- "A RADIUS client MAY ignore Attributes with an unknown Type." - "A RADIUS client MAY ignore Attributes with an unknown Type."
- "A RADIUS server 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 Therefore, RADIUS clients or servers that do not support the CUI may
ignore the attribute. ignore the attribute.
A RADIUS client requesting the CUI attribute in an Access-Accept A RADIUS client requesting the CUI attribute in an Access-Accept
packet MUST include within the Access-Request packet a CUI attribute. packet MUST include within the Access-Request packet a CUI attribute.
For the initial authentication, the CUI attribute will include a For the initial authentication, the CUI attribute will include a
single NUL character (referred to as a nul CUI). And, during re- single NUL character (referred to as a nul CUI). And, during
authentication, the CUI attribute will include a previously received re-authentication, the CUI attribute will include a previously
CUI value (referred as a non-nul CUI value) in the Access-Accept. received CUI value (referred to as a non-nul CUI value) in the
Access-Accept.
Upon receiving a non-nul CUI value in an Access-Request the home Upon receiving a non-nul CUI value in an Access-Request, the home
RADIUS server MAY verify that the value of CUI matches the CUI from RADIUS server MAY verify that the value of CUI matches the CUI from
the previous Access-Accept. If the verification fails, then the the previous Access-Accept. If the verification fails, then the
RADIUS server SHOULD respond with an Access-Reject message. RADIUS server SHOULD respond with an Access-Reject message.
If a home RADIUS server that supports the CUI attribute receives an If a home RADIUS server that supports the CUI attribute receives an
Access-Request packet containing a CUI (set to nul or otherwise), it Access-Request packet containing a CUI (set to nul or otherwise), it
MUST include the CUI attribute in the Access-Accept packet. MUST include the CUI attribute in the Access-Accept packet.
Otherwise, if the Access-Request packet does not contain a CUI, the Otherwise, if the Access-Request packet does not contain a CUI, the
home RADIUS server SHOULD NOT include the CUI attribute in the home RADIUS server SHOULD NOT include the CUI attribute in the
Access-Accept packet. The Access-Request may be sent either in the Access-Accept packet. The Access-Request may be sent either in the
initial authentication or during re-authentication. initial authentication or during re-authentication.
A NAS that requested the CUI during re-authentication by including A NAS that requested the CUI during re-authentication by including
the CUI in the Access-Request, will receive the CUI in the Access- the CUI in the Access-Request will receive the CUI in the
Accept. The NAS MUST include the value of that CUI in all Accounting Access-Accept. The NAS MUST include the value of that CUI in all
Messages. Accounting Messages.
2.2. CUI Attribute 2.2. CUI Attribute
A summary of the RADIUS CUI Attribute is given below. A summary of the RADIUS CUI 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 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... | Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for Chargeable-User-Identity. Type: 89 for Chargeable-User-Identity.
Length: >= 3 Length: >= 3
String: String:
The string identifies the CUI of the end-user and is of type The string identifies the CUI of the end-user. This string value
UTF8String. This string value is a reference to a particular is a reference to a particular user. The format and content of
user. The format and content of the string value is determined by the string value are determined by the Home RADIUS server. The
the Home RADIUS server. The binding lifetime of the reference to binding lifetime of the reference to the user is determined based
the user is determined based on business agreements. For example, on business agreements. For example, the lifetime can be set to
the lifetime can be set to one billing period. RADIUS entities one billing period. RADIUS entities other than the Home RADIUS
other than the Home RADIUS server MUST treat the CUI content as an server MUST treat the CUI content as an opaque token, and SHOULD
opaque token, and SHOULD NOT perform operations on its content NOT perform operations on its content other than a binary equality
other than a binary equality comparison test, between two comparison test, between two instances of CUI. In cases where the
instances of CUI. In cases where the attribute is used to attribute is used to indicate the NAS support for the CUI, the
indicate the NAS support for the CUI, the string value contains a string value contains a nul character.
nul character.
3. Attribute Table 3. Attribute Table
The following table provides a guide to which attribute(s) may be The following table provides a guide to which attribute(s) may be
found in which kinds of packets, and in what quantity. found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute Request Accept Reject Challenge Accounting # Attribute
Request Request
0-1 0-1 0 0 0-1 TBD Chargeable-User-identity 0-1 0-1 0 0 0-1 89 Chargeable-User-Identity
[Note 1] If the Access-Accept packet contains CUI then the NAS MUST Note: If the Access-Accept packet contains CUI, then the NAS MUST
include the CUI in Accounting Requests (Start, Interim and Stop) include the CUI in Accounting Requests (Start, Interim, and Stop)
packets. packets.
4. Diameter Consideration 4. Diameter Consideration
Diameter needs to define an identical attribute with the same Type Diameter needs to define an identical attribute with the same Type
value. The CUI should be available as part of the NASREQ value. The CUI should be available as part of the NASREQ application
application. [RFC4005].
5. IANA Considerations 5. IANA Considerations
This document uses the RADIUS [RFC2865] namespace, see This document uses the RADIUS [RFC2865] namespace; see
"http://www.iana.org/assignments/radius-types". This document http://www.iana.org/assignments/radius-types. The IANA has assigned
instructs IANA to assign a new RADIUS attribute number for the CUI a new RADIUS attribute number for the CUI attribute.
attribute.
CUI TBA CUI 89
6. Security considerations 6. Security Considerations
It is strongly recommended that the CUI format used is such that the It is strongly recommended that the CUI format used is such that the
real user identity is not revealed. Furthermore, where a reference real user identity is not revealed. Furthermore, where a reference
is used to a real user identity, the binding lifetime of that is used to a real user identity, it is recommended that the binding
reference to the real user be kept as short as possible. lifetime of that reference to the real user be kept as short as
possible.
The RADIUS entities (RADIUS proxies and clients) outside the home The RADIUS entities (RADIUS proxies and clients) outside the home
network MUST NOT modify the CUI or insert a CUI in an Access-Accept. network MUST NOT modify the CUI or insert a CUI in an Access-Accept.
However, there is no way to detect or prevent this. However, there is no way to detect or prevent this.
Attempting theft of service, A man-in-the-middle may try to insert, Attempting theft of service, a man-in-the-middle may try to insert,
modify or remove the CUI in the Access-Accept packets and Accounting modify, or remove the CUI in the Access-Accept packets and Accounting
packets. However, RADIUS Access-Accept and Accounting packets packets. However, RADIUS Access-Accept and Accounting packets
already provide integrity protection. already provide integrity protection.
If the NAS includes CUI in an Access-Request packet, a man-in-the- If the NAS includes CUI in an Access-Request packet, a
middle may remove it. This will cause the Access-Accept packet to man-in-the-middle may remove it. This will cause the Access-Accept
not include a CUI attribute, which may cause the NAS to reject the packet to not include a CUI attribute, which may cause the NAS to
session. To prevent such a DoS attack, the NAS SHOULD include a reject the session. To prevent such a denial of service (DoS)
Message-Authenticator(80) attribute within Access-Request packets attack, the NAS SHOULD include a Message-Authenticator(80) attribute
containing a CUI attribute. within Access-Request packets containing a CUI attribute.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Jari Arkko, Bernard Aboba, David The authors would like to thank Jari Arkko, Bernard Aboba, David
Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith, Nelson, Barney Wolff, Blair Bullock, Sami Ala-Luukko, Lothar Reith,
David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson, for David Mariblanca, Eugene Chang, Greg Weber, and Mark Grayson for
their feedback and guidance. their feedback and guidance.
8. References 8. References
8.1. Normative references 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Diameter Network Access Server Application", RFC 4005,
August 2005.
[rfc2486bis] [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
Network Access Identifier",
draft-arkko-roamops-rfc2486bis-02 (work in progress),
July 2004.
8.2. Informative references 8.2. Informative References
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 3576, Authentication Dial In User Service (RADIUS)", RFC 3576,
July 2003. July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Authors' Addresses Authors' Addresses
Farid Adrangi Farid Adrangi
Intel Corporation Intel Corporation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
USA USA
Phone: +1 503-712-1791 Phone: +1 503-712-1791
Email: farid.adrangi@intel.com EMail: farid.adrangi@intel.com
Avi Lior Avi Lior
Bridgewater Systems Corporation Bridgewater Systems Corporation
303 Terry Fox Drive 303 Terry Fox Drive
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
Canada Canada
Phone: +1 613-591-9104 Phone: +1 613-591-9104
Email: avi@bridgewatersystems.com EMail: avi@bridgewatersystems.com
Jouni Korhonen Jouni Korhonen
Teliasonera Corporation Teliasonera Corporation
P.O.Box 970 P.O.Box 970
FIN-00051, Sonera FIN-00051, Sonera
Finland Finland
Phone: +358405344455 Phone: +358405344455
Email: jouni.korhonen@teliasonera.com EMail: jouni.korhonen@teliasonera.com
John Loughney John Loughney
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
FIN-00180, Helsinki FIN-00180, Helsinki
Finland Finland
Phone: +358504836342 Phone: +358504836342
Email: john.loughney@nokia.com EMail: john.loughney@nokia.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 11, line 29 skipping to change at page 10, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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
Copyright (C) The Internet Society (2005). 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 Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 49 change blocks. 
156 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/