draft-ietf-radext-chargeable-user-id-01.txt   draft-ietf-radext-chargeable-user-id-02.txt 
Network Working Group F. Adrangi Network Working Group F. Adrangi
Internet-Draft Intel Internet-Draft Intel
Expires: June 29, 2005 A. Lior Expires: July 5, 2005 A. Lior
Bridgewater Systems Bridgewater Systems
J. Korhonen J. Korhonen
Teliasonera Teliasonera
J. Loughney J. Loughney
Nokia Nokia
December 29, 2004 January 2005
Chargeable User Identity Chargeable User Identity
draft-ietf-radext-chargeable-user-id-01 draft-ietf-radext-chargeable-user-id-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 29, 2005. This Internet-Draft will expire on July 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a new RADIUS attribute, This document describes a new RADIUS attribute,
Chargeable-User-Identity. This attribute can be used by a home Chargeable-User-Identity. This attribute can be used by a home
network to identify a user for the purpose of roaming transactions network to identify a user for the purpose of roaming transactions
that occur outside of the home network. that occur outside of the home network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5 2.1 Chargeable-User-Identity (CUI) Attribute . . . . . . . . . 5
3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7 3. Attribute Table . . . . . . . . . . . . . . . . . . . . . . . 7
4. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 7 4. Diameter Consideration . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1 CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . . 7 5.1 CUI RADIUS Attribute . . . . . . . . . . . . . . . . . . . 7
5.2 Error-Cause Attribute . . . . . . . . . . . . . . . . . . 7 5.2 Error-Cause Attribute . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative references . . . . . . . . . . . . . . . . . . . 8 8.1 Normative references . . . . . . . . . . . . . . . . . . . 8
8.2 Informative references . . . . . . . . . . . . . . . . . . 9 8.2 Informative references . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11 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 user identity in order if local and intermediate networks require a user identity.
to enforce usage policies.
This document introduces an attribute that serves as an alias or
handle (hereafter, it is called Chargeable-User-Identity) to the real
user's identity. Chargeable-User-Identity can be used outside the
home network in scenarios that traditionaly relied on User-Name(1) 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 an authenticated and unique identity provided by This implies that an authenticated and unique identity provided by
the home network should be able to be conveyed to all parties the home network should be able to be conveyed to all parties
involved in the roaming transaction for correlating the involved in the roaming transaction for correlating the
authentication and accounting packets. authentication and accounting packets.
Providing a unique identity, called the Chargeable-User-Identity Providing a unique identity, Chargeable-User-Identity (CUI), to
(CUI) to intermediaries, is necessary to fulfill certain business intermediaries, is necessary to fulfill certain business needs. This
needs. This should not undermine the anonymity of the user. The should not undermine the anonymity of the user. The mechanism
mechanism provided by this draft allows the home operator to meet provided by this draft allows the home operator to meet these
these business requirements by providing a temporary identity business requirements by providing a temporary identity representing
representing the subscriber and at the same time protecting the the subscriber and at the same time protecting the anonymity of the
anonymity of the subscriber. subscriber.
1.1 Motivation When the home network assigns a value to the CUI, it asserts that
this value represents a user in the home network. The assertion
should be temporary. Long enough to be useful for the external
applications and not too long such that it can be used to identify
the user.
Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance,
IRAP, have been studying mechanisms to provide roaming services, IRAP, have been studying mechanisms to provide roaming services,
using RADIUS. A mechanism for providing the current deployments with using RADIUS. One missing element is a mechanism for providing the
the capacity to deploy, bill and oversee WPA networks against fraud. current deployments with the capacity to deploy, bill and oversee WPA
networks against fraud.
The CUI attribute has been designed 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, especially when tunneled protocols with multiple negatively, especially when tunneled protocols with multiple
identities, such as PEAP or TTLS, are used. Use of the CUI is geared identities, such as PEAP or TTLS, are used. Use of the CUI is geared
to multi-identity EAP authentications which are, for the most part, to multi-identity EAP authentications which are, for the most part,
recent deployments. A chargeable identity reflecting the user recent deployments. A chargeable identity reflecting the user
profile authenticated by the home network is needed in such roaming profile authenticated by the home network is needed in such roaming
scenarios. scenarios.
The CUI support by RADIUS infrastructure is driven by the business 1.1 Motivation
requirements between roaming entities. Therefore whether a RADIUS
server/proxy or client accepts or rejects the presence or lack of
presence of the CUI attribute is a matter of business policy.
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 User-Name(1) attributes could be used to indicate the CUI. However,
Chargeable-User-Identity. However, in a complex global roaming in a complex global roaming environment where there could be one or
environment where there could be one or more intermediaries between more intermediaries between the NAS and the home RADIUS server, the
the NAS and the home RADIUS server, the use of aforementioned use of aforementioned attributes could lead to problems as described
attributes could lead to problems as described below. below.
- On 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 and SHOULD be sent server to the client in an Access-Accept 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 with there could be multiple class attributes in a RADIUS packet, and
unspecified ordering, which makes it hard to the entities outside since the contents of Class(25) attribute is not to be interpreted
home network to determine which one contains the CUI. by clients, this makes it hard to the entities outside home
network to determine which one contains the CUI.
- On use of RADIUS User-Name(1) attribute: - On the use of RADIUS User-Name(1) attribute:
The home network could use User-Name(1) in the Access-Accept The User-Name(1) attribute included in the Access-Request may be
message to convey the CUI to intermediaries and the NAS. However, used for the purpose of routing the Access-Request packet, and in
as the Access-Accept packet is routed to the NAS, the User-Name(1) the process may be rewritten by intermediaries. As a result, a
attribute could be (completely) rewritten by an intermediary and RADIUS server receiving an Access-Request packet relayed by a
therefore the NAS or other intermediaries along the way will not proxy cannot assume that the User-Name(1) attribute remained
have access to the CUI. Furthermore, the NAS may use the original unmodified.
value of the User-Name(1) attribute (the one sent in the On the other hand, rewriting of a User-Name(1) attribute sent
Access-Request packet) in the Accounting-Request packets to ensure within an Access-Accept packet occurs more rarely, since a
the billing follows the same path as authentication packets. Proxy-State(33) attribute can be used to route the Access-Accept
packet without parsing the User-Name(1) attribute. As a result, a
RADIUS server cannot assume that a proxy stripping routing
information from a User-Name(1) attribute within an Access-Request
will add this information to a User-Name(1) attribute included
within an Access-Accept. The result is that when a User-Name(1)
attribute is sent in an Access-Accept it is possible that the
Access-Request and Accounting-Request packets will follow
different paths. Where this outcome is undesirable, the RADIUS
client should use the original User-Name(1) in accounting packets.
Therfore, another mechanism is required to convey a CUI within an
Access-Accept packet to the RADIUS client, so that the CUI can be
included in the accounting packets.
The CUI attribute provides a solution to the above problem and avoids The CUI attribute provides a solution to the above problem and avoids
overloading the use of current RADIUS attributes (e.g., User-Name(1) overloading the use of current RADIUS attributes (e.g., User-Name(1)
re-write). The CUI is the correct standards-based approach to fixing re-write). The CUI is the correct standards-based approach to fixing
the problems which have arisen with multiple-identity RADIUS the problems which have arisen with multiple-identity RADIUS
authorization and accounting methods. It does not solve all related authorization and accounting methods. It does not solve all related
problems, but does provide networks the ability to bill and oversee problems, but does provide networks the ability to bill and oversee
WPA networks against fraud. When the home network assigns a value to WPA networks against fraud.
the CUI, it asserts that this value represents a user in the home
network. The assertion should be temporary. Long enough to be
useful for the external applications and not too long such that it
can be used to identify the user.
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 3GPP - Third Generation Partnership Program
AAA - Authentication, Authorization and Accounting AAA - Authentication, Authorization and Accounting
CUI - Chargeable-User-Identity CUI - Chargeable-User-Identity
skipping to change at page 5, line 30 skipping to change at page 5, line 46
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], [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
This attribute serves as an alias to the user's real identity. It is The CUI attribute serves as an alias to the user's real identity,
provided by the home network as a suplemental or alternative representing a chargeable identity as defined and provided by the
information to User-Name(1). RADIUS clients (proxy or NAS) outside home network as a supplemental or alternative information to
the home network MUST NOT modify the CUI attribute. User-Name(1). Typically the CUI represents the identity of the
actual user but it may also indicate other chargeable identities such
as a group of users. RADIUS clients (proxy or NAS) outside the home
network MUST NOT modify the CUI attribute.
In accordance to business policies, the RADIUS server (a RADIUS The RADIUS server (a RADIUS proxy, home RADIUS server) may include
proxy, home RADIUS server) may include the CUI attribute in the the CUI attribute in the Access-Accept packet destined to a roaming
Access-Accept message destined to a roaming partner. partner. The CUI support by RADIUS infrastructure is driven by the
business requirements between roaming entities. Therefore whether a
RADIUS server/proxy or client accepts or rejects the presence or lack
of presence of the CUI attribute is a matter of business policy.
If an Access-Accept message without the CUI attribute was received by If an Access-Accept packet without the CUI attribute was received by
a RADIUS client (NAS or Proxy) that requires the presence of the CUI a RADIUS client (NAS or Proxy) that requires the presence of the CUI
attribute, then the Access-Accept message MAY be treated as an attribute, then the Access-Accept packet MAY be treated as an
Access-Reject message based on local policies. Access-Reject packet based on local policies.
If the CUI was included in the Access-Accept message, RADIUS client If the CUI was included in the Access-Accept packet, RADIUS client
(Proxy or NAS) that supports the CUI attribute MUST ensure that the (Proxy or NAS) that supports the CUI attribute MUST ensure that the
CUI attribute appears in the RADIUS Accounting-Request (Start, CUI attribute appears in the RADIUS Accounting-Request (Start,
Interim, and Stop). Interim, and Stop).
RADIUS client (Proxy or NAS) that does not support the CUI attribute RFC 2865 includes the following statements about behaviors of RADIUS
MAY ignore this attribute or MAY treat the Access-Accept as client and server with respect to unsupported attributes:
Access-Reject.
- "A RADIUS client MAY ignore Attributes with an unknown Type."
- "A RADIUS server MAY ignore Attributes with an unknown Type."
Therefore, RADIUS client or server that does not support the CUI
attribute MAY ignore this attribute.
If RADIUS client (Proxy or NAS) requires the presence of the CUI If RADIUS client (Proxy or NAS) requires the presence of the CUI
attribute in the Access-Accept, it MUST indicate its requirement by attribute in the Access-Accept, it MUST indicate its requirement by
including this attribute with a nul character for its data field including the CUI attribute in the Access-Request packet with a value
(hereafter, it is also referred to as a nul CUI) in the set to the nul character (hereafter, it is also referred to as a nul
Access-Request message. CUI).
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 containing a nul CUI, it MUST include the CUI Access-Request containing a CUI (set to nul or otherwise), it MUST
attribute in the Access-Accept. Otherwise, if the Access-Request include the CUI attribute in the Access-Accept. Otherwise, if the
does not contain a null CUI, the home RADIUS server MUST NOT include Access-Request does not contain a CUI, the home RADIUS server MUST
the CUI attribute in the Access-Accept. NOT include the CUI attribute in the Access-Accept.
A RADIUS server (a RADIUS proxy or the home RADIUS server) that A RADIUS server (a RADIUS proxy or the home RADIUS server) that
requires the presence of the CUI in the Accounting-Response messages requires the presence of the CUI in the Accounting-Request packets
(Start, Stop, Interims) MAY respond with an Access-Reject message if (Start, Stop, Interims) MAY respond with an Access-Reject packet if
it receives an Access-Request messsage from a RADIUS client, or proxy it receives an Access-Request messsage from a RADIUS client, that
chain that does not support the CUI attribute. The Access-Reject does not support the CUI attribute. The Access-Reject packet MUST
message MUST include Error-Cause attribute [RFC3576] with value include Error-Cause attribute [RFC3576] with value (to-be-defined)
(to-be-defined) (decimal), "CUI-Support-Required". (decimal), "CUI-Support-Required".
If the NAS supports CUI attribute then the CUI attribute MAY also be
used as one of the identity attribute in Disconnect Message and
Change of Authorization messages defined by [RFC3576]. Determination
of NAS support for the CUI is outside the scope of this document.
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: TBD for Chargeable-User-Identity.
skipping to change at page 7, line 13 skipping to change at page 7, line 35
a nul character. a 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 TBD Chargeable-User-identity
0 0 0-1 0 0 101 Error-Cause
[Note 1] If the Access-Accept contains CUI then the NAS MUST include [Note 1] If the Access-Accept contains CUI then the NAS MUST include
the CUI in Accounting Requests (Start, Interim and Stop) packets. the CUI in Accounting Requests (Start, Interim and Stop) packets.
[Note 2] The Error-Cause attribute is defined in [RFC3576]. 4. Diameter Consideration
Change of Authorization and Disconnect-Request
Request ACK NAK # Attribute
0-1 0 0 TBD Chargeable-User-Identity
[Note 3] Where CUI 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).
4. Diameter RADIUS Interoperability
In deployments with both RADIUS and Diameter interworking, a Diameter needs to define an identical attribute with the same Type
translation agent will be deployed and operate in accordance to the value. The CUI should be available as part of the NASREQ
NASREQ specification. application.
5. IANA Considerations 5. IANA Considerations
5.1 CUI RADIUS Attribute 5.1 CUI RADIUS Attribute
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". This document
instructs IANA to assign a new RADIUS attribute number for the CUI instructs IANA to assign a new RADIUS attribute number for the CUI
attribute. attribute.
CUI TBA CUI TBA
5.2 Error-Cause Attribute 5.2 Error-Cause Attribute
This document instructs IANA to assign a new Error-Cause attribute This document instructs IANA to assign a new value for Error-Cause
[RFC3576], attribute [RFC3576],
"CUI-Support-Required" TBA "CUI-Support-Required" TBA
6. Security considerations 6. Security considerations
The CUI attribute must be protected against Man-in-the-Middle It is strongly recommended that the CUI format used is such that the
attacks. The CUI appears in Access-Accept and Accounting-Requests
packets and is protected by the mechanisms that are defined for
RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional
security considerations beyond those already identified in [RFC2865]
and [RFC2866].
Message-Authenticator(80) and Event-Timestamp(55) can be used to
further protect against Man-in-the-middle attacks.
It is strongly recommended that the CUI form 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, the binding lifetime of that
reference to the real user be kept as short as possible. reference to the real user be kept as short as possible.
The RADIUS entities (RADIUS proxies and clients)outside the home
netowrk MUST NOT modify the CUI. However, there is no way to detect
or prevent this.
If the NAS includes CUI in an Access-Request. A man in the middle
may remove the CUI attribute from the Access-Request. The result is
that the Access-Accept will not have a CUI which will cause the NAS
to reject the session resulting in a DOS attack. To prevent this
attack, the NAS SHOULD include Message-Authenticator(80) in the
Access-Request packets that contain a CUI.
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
[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)", RFC "Remote Authentication Dial In User Service (RADIUS)",
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc2486bis] [rfc2486bis]
Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier", Network Access Identifier",
draft-arkko-roamops-rfc2486bis-02 (work in progress), July Internet-Draft draft-arkko-roamops-rfc2486bis-02, July
2004. 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.
skipping to change at page 9, line 24 skipping to change at page 9, line 33
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 Intellectual Property Statement
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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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