WDIFF

draft-adrangi-radius-attributes-extension-00.txt --> draft-adrangi-radius-attributes-extension-01.txt

INTERNET DRAFT Intel Corporation
Category: Informational Avi Lior
Expires: Nov Dec 10, 2004 Bridgewater Systems
Jouni Korhonen
Teliasonera
May 10,
July 16, 2004

RADIUS Attributes Extension
draft-adrangi-radius-attributes-extension-00.txt
draft-adrangi-radius-attributes-extension-01.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes additional Remote Authentication Dial In
User Service (RADIUS) [1] attributes for use of RADIUS AAA
(Authentication, Authorization, Accounting) in both Wireless and
wired networks. Some of these attributes are already implemented
as Vendor Specific Attributes (VSA) in networks today, but their
consistent use is essential to promote multi-vendor
interoperability where RADIUS NAS It contains an IPv4 address type control mechanism,
mobile IPv4 home agent discovery mechanism, and sever are from two
different vendors. a RADIUS
capabilities discovery mechanism.

Adrangi, et al. Expires April 13, Dec 16, 2004 [Page 1]

Internet Draft RADIUS Attributes Extension 10 May 16 July 2004

Table of Contents

1. Introduction....................................................2
1.1 Requirements language..........................................2
2. Operation.......................................................2
2.1 RADIUS Support for Specifying User Alias Identity..............2 Identity Alias..............3
2.2 RADIUS Support for Advertising Application-based capabilities..4 capabilities..5
2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6
2.4 RADIUS Support for Specifying IP IPv4 Address Type Options..........7 Options........7
3. IANA Considerations.............................................8 Considerations.............................................9
4. Security Considerations.........................................8 Considerations.........................................9
5. Acknowledgements................................................8 Acknowledgements................................................9
6. References......................................................8
Authors’ Addresses.................................................9 References......................................................9
AuthorsË Addresses................................................10

1. Introduction

Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the
dominant Authentication, Authorization, and Accounting (AAA)
protocol in use across broadband wireless and wired networks
globally.

This document describes a number of additional attributes that are
needed to enable use of RADIUS AAA in various types of access
network in an interoperable manner.

This document describes a number of additional attributes
for the RADIUS and Diameter AAA protocols. These attributes
are needed to provide additional AAA functions for wired and
wireless access networks. Some of these functions already
exist as vendor-specific solutions, but this draft makes these
functions interoperable among different vendors.

1.1 Requirements language

In this document, several words are used to signify the
requirements of the specification. These words are often
capitalized. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].

2. Operation

Operation is identical to

This document assumes that defined the RADIUS protocol operates as
specified in [1] [1, 2] and [2].

2.1 RADIUS Support for Specifying User Alias Identity

Rationale that the Diameter protocol operates as
specified in[RFC 3588, NASREQ].

Adrangi, et al. Expires November 13, 2004 [Page 2]

Internet Draft RADIUS Attributes Extension 10 May 16 July 2004

2.1 RADIUS Support for Specifying User Identity Alias

Rationale

In certain authentication methods such as, EAP-PEAP or EAP-
TTLS, EAP-SIM, and EAP-AKA, the true identity of the subscriber is
can be hidden from the RADIUS AAA infrastructure. servers outside the
subscriberËs home network. In these methods the User-name(1)
attribute contains an anonymous identity (e.g.,
anonymous@homerealm.com) sufficient to route the RADIUS packets
to the home network but otherwise insufficient to identify the
subscriber. While this mechanism is good practice there are
situations where this creates
problems. For example, in problems:

- In certain roaming situations intermediaries and visited
network require to be able to correlate an authentication
session with a user identity; A identity known to the userËs home
network í for example: a broker may require to implement a
policy where by only session is allowed per user entity. Third entity;
third party billing brokers may require to match accounting
records to a user identity.
- NAS may require to match the user session and accounting
records to a user identity known to the userËs home network.

The User Identity Alias provides a solution to the above
problem. When the home network assigns a value to the User
Identity Alias it asserts that this value represents a user in
the home network. The assertion should be temporary. Long
enough to be useful for the external applications and not too
long to such that it can be used to identify the user.

Attribute

This attribute indicates user’s userËs identity alias. It is assigned
by the home RADIUS server and MAY be sent in Access-Accept
message. The NAS or the access network AAA server MUST include
this attribute in the Accounting Requests (Start, Interim, and
Stop) messages if it was included in the Access Accept message.
Intermediaries MUST NOT modify the User Alias Identity
attribute.

If the RADIUS server includes this attribute in an Access-
Accept message it MAY also use this attribute as one of the
identity attributes in a Disconnect Message and Change of
Authorization message defined by RFC 3576. [4].

A summary of the RADIUS User Identity Alias Attribute is shown
below.

Adrangi, et al. Expires November 13, 2004 [Page 3]

Internet Draft RADIUS Attributes Extension 16 July 2004

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Name

User Identity Alias

Type

To be assigned by IANA

Length

>= 6

Adrangi, et al. Expires November 13, 2004 [Page 3]

Internet Draft RADIUS Attributes Extension 10 May 2004

String

The string field is six or more octets. This non-NULL
terminated string consists of two colon separated parts. The
first part is determines the Charging Type identifier User Identity Alias type and the
second part is the Charging identifier. actual User Identity Alias value. The Charging Type
identifier
User-Identity-Alias type is a coded as two octet hexadecimal string, which defines
explicitly the interpretation of the following Charging
identity.
string,. The Charging identity part User Identity Alias value must be at least one
octet.

Following Charging Type identities

The following User-Identity Alias types have been defined:

00 – í reserved
01 – í IMSI
02 – í NAI
03 – í E.164 number
04 – í SIP URL (as defined in [13])
05 – í Opaque string

Opague string is a value that is assigned to the user by the
home network where the home network asserts that this value
represents a particular user í itËs a handle to the user.
The length of time for which this assertion is valid is
unspecified by this specification and typically would be
long enough to serve some business needs and short enough
such that it minimizes the chance of revealing the true
identity of the user (either directly or indirectly).

Below are examples of User Identity Alias Strings strings with NAI
and E.164 Charging Types:

“02:user@realm.org”
“03:+4689761234”

÷02:charging-id@realm.org÷
÷03:+4689761234÷

Adrangi, et al. Expires November 13, 2004 [Page 4]

Internet Draft RADIUS Attributes Extension 16 July 2004

Ideally, the real user identity should not be revealed
through this attribute. However, the operators will have
the final word on the used charging type and its identifier.

Additional Charging Type identifiers User Identity Alias types may be assigned in
revised versions of this RFC.

2.2 RADIUS Support for Advertising Application-based capabilities

Rationale

There is a need for a home RADIUS server to discover
capabilities of a NAS that has initiated a connection to it.
The capabilities indicate standard-based applications (e.g.,
existing dynamic authorization Extension to Remote [5], future
prepaid accounting model, etc.) that a NAS supports. This
enables the home RADIUS server to decide which application
services it can use for the connection, or whether or not it
should accept the connection. For example, if the subscriber
is a prepaid subscriber, and the NAS does not support the
prepaid capability, the RADIUS server may want to reject the
connection.

Attribute

Adrangi, et al. Expires November 13, 2004 [Page 4]

Internet Draft RADIUS Attributes Extension 10 May 2004

This attribute describes standard-based capabilities that a NAS
supports. Zero or more of these attribute are available to be
sent in Access-Request.

A summary of the capability Attribute is shown below.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Name

Generic Capability

Type

To be assigned by IANA

Length

= 6

Adrangi, et al. Expires November 13, 2004 [Page 5]

Internet Draft RADIUS Attributes Extension 16 July 2004

Integer

The format of this Integer is as follows:

0xCCCTSSSS

Where:
CCC is a 12-bit indicator that identifies the capability ID.
CCC = 0x000 and 0xFFF is reserved.

T is a 4-bit indicator used for extending the sub-capability
space. T = 0xF is reserved.

SSSS is 16-bit indicator that identifies the sub-capabilities ID.
These are determined by the application writer and may represent a
number of mutually exclusive sub-capabilities or mutually
inclusive sub-capabilities codes as bits.

Extension of sub-capabilities. sub-capabilities:

T=0x0 represents the first 16 bits of sub-capabilities
T=0x1 represents the next 16 bits of sub-capabilities
T=0xF represents the last 16 bits of sub-capabilities

The following Capability Identities are assigned by this RFC.
Additional capability ids may be assigned later. See the IANA
section.

Adrangi, et al. Expires November 13, 2004 [Page 5]

Internet Draft RADIUS Attributes Extension 10 May 2004

Editor’s

EditorËs note: we have to assign some capabilities from radius and
also sub-capabilities. Candidates would be from RFCs 2865, 2869,
2867, 3162, 3576, 3580.

2.3 RADIUS Support for Specifying a Mobile IP Home Agent

Rationale

In Mobile IP [7], a Mobile-IP enabled client registers with its
home agent when it attaches to the network for the first time,
or when it changes its network point of attachment. In typical
service provider deployments, networks are geographically
dispersed within a single large administrative domain. In such
networks, it is possible to deploy the home agents in each
geographical area. When a client authenticates to its home
network through a NAS, the home RADIUS server may want to
specify the home agent for that client based on the NAS
location information.

There is a need for an interoperable method by which the home
RADIUS server can indicate the Mobile IP home agent that MUST
used by the client to the NAS. The home agent address can

Adrangi, et al. Expires November 13, 2004 [Page 6]

Internet Draft RADIUS Attributes Extension 16 July 2004

later be indicated to the client through several means – í for
example, it can be relayed in the “home ÷home agent address” address÷ field of
a DHCP reply if the client acquires its IP address through DHCP
[8].

Attribute (IPv4 version)

This attribute indicates the home agent IPv4 Address that can
be used by a Mobile-IP enabled client. This attribute is
available to be sent in Access-Accept.

A summary of the RADIUS Mobile IPv4 home agent Attribute is
shown below.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Name

Adrangi, et al. Expires November 13, 2004 [Page 6]

Internet Draft RADIUS Attributes Extension 10 May 2004

Mobile IPv4 Home Agent

Type

To be assigned by IANA

Length

Address

The Address filed is four octets. It contains a Mobile IP
home agent address.

2.4 RADIUS Support for Specifying IP IPv4 Address Type Options

Rationale

An access network may have an option of assigning a layer 3
public (i.e., routable) or private (i.e., non-routable) address
to the authorized clients. If the option is available, the

Adrangi, et al. Expires November 13, 2004 [Page 7]

Internet Draft RADIUS Attributes Extension 16 July 2004

home network may also want to influence which address type
(i.e., public or private) should be assigned to the client
depending on the client’s clientËs subscription profile.

There is a need for an interoperable method by which a NAS can
indicate its currently available IP IPv4 address type options to a
home network for a given client. And then, the home network can
specify the desired IP IPv4 address type option to be used for
assigning an IP IPv4 address to the client.

Attribute

This attribute indicates IPv4 address type options. It In RADIUS,
it can be present in Access-Request, Access-Accept, and Accounting-
Request records Access-Accept
messages. In Diameter, it can be present in AAR, AAA, and RAR
commands. In both protocols, it can be present in
Accounting-Request messages where the Acc-Status-Type is set to
Start or Stop. When it is used in an Access-Accept and Accounting-
Request
Accounting-Request packets, the Address Type value MUST be 1 or
2.

A NAS includes this attribute in the AR RADIUS Access-Accept or
Diameter AAR to advertise its supported IP IPv4 address type
options. A RADIUS An AAA server includes this attribute in the RADIUS
Access-Accept packet or Diameter AAA and RAR commands to
specify an IP IPv4 address type option for the PWLAN access network
client.

A RADIUS

An AAA server MUST NOT include this attribute in the Access-
Accept RADIUS
Access-Accept or Diameter AAA and PAR if the IP IPv4 Address Type
options were not advertised in by the Access-Request. NAS. If an invalid IP IPv4
Address Type option is
received in the Access-Accept, received, then the AN NAS MUST use its default
IP Address Type option for the client. treat it as
an RADIUS Access-Reject or Diameter AA-Answer with Result-Code
AVP set to ???. Otherwise, the AN access network MUST

Adrangi, et al. Expires November 13, 2004 [Page 7]

Internet Draft RADIUS Attributes Extension 10 May 2004 assign an IP
IPv4 address according to the specified type option.
In either case it option, and the
NAS MUST include this attribute in Accounting-
Request Accounting-Request packets
to indicate the used IP IPv4 address type option. If an IP IPv4
address type option is not specified in the RADIUS Access-
Accept,
Accept or Diameter RAR and AAA commands, the NAS MUST NOT
include this attribute in Accounting-
Request Accounting-Request packets.

A summary of the home-agent RADIUS IPv4 Address Type Option Attribute is
shown below.

Name

Adrangi, et al. Expires November 13, 2004 [Page 8]

Internet Draft RADIUS Attributes Extension 16 July 2004

IPv4 Address Type Options

Type

To be assigned by IANA

Length

Address Type

1 : Public Address Type
2 : Private Address Type
3 : Public and Private Type

3. IANA Considerations

This draft introduces new RADIUS Attributes. Therefore, there is
a need for obtaining new attribute TYPE numbers from IANA.

New enumerated values within the attributes defined here can be
allocated using the policies defined in RFC 3575, i.e., Designated
Expert.

4. Security Considerations

The attributes in this document have no additional security
considerations beyond those already identified in [?].

5. Acknowledgements

TBD

The authors would like to thank Jari Arkko for his extensive
contribution and comments in improving the draft.

6. References

Adrangi, et al. Expires November 13, 2004 [Page 8]

Internet Draft RADIUS Attributes Extension 10 May 2004

[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Server (RADIUS)", RFC 2865, June
2000.

[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[3] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions",
RFC 2869, June 2000.

Authors’

[4] Chiba, M., Dommety, G., Eklud, M., Mitton, D., Aboba, B.,
÷Dynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)÷, RFC 3576, July 2003.

Adrangi, et al. Expires November 13, 2004 [Page 9]

Internet Draft RADIUS Attributes Extension 16 July 2004

AuthorsË Addresses

Farid Adrangi
Email: farid.adrangi@intel.com Phone:+1 503-712-1791

Avi Lior
Email: avi@bridgewatersystems.com

Jouni Korhonen
Email: jouni.korhonen@teliasonera.com

Full Copyright Statement

This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.

This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

Adrangi, et al. Expires November 13, 2004 [Page 9]

Internet Draft RADIUS Attributes Extension 10 May 2004

Acknowledgement

Funding for the RFC Editor function is currently provided by
the Internet Society.

Adrangi, et al. Expires November 13, 2004 [Page 10]
----