One document matched: draft-adrangi-radius-attributes-extension-00.txt
Network Working Group Farid Adrangi
INTERNET DRAFT Intel Corporation
Category: Informational Avi Lior
Expires: Nov 10, 2004 Bridgewater Systems
Jouni Korhonen
Teliasonera
May 10, 2004
RADIUS Attributes Extension
draft-adrangi-radius-attributes-extension-00.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 and sever are from two
different vendors.
Adrangi, et al. Expires April 13, 2004 [Page 1]
Internet Draft RADIUS Attributes Extension 10 May 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
2.2 RADIUS Support for Advertising Application-based capabilities..4
2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6
2.4 RADIUS Support for Specifying IP Address Type Options..........7
3. IANA Considerations.............................................8
4. Security Considerations.........................................8
5. Acknowledgements................................................8
6. References......................................................8
Authors’ Addresses.................................................9
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.
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 that defined in [1] and [2].
2.1 RADIUS Support for Specifying User Alias Identity
Rationale
Adrangi, et al. Expires November 13, 2004 [Page 2]
Internet Draft RADIUS Attributes Extension 10 May 2004
In certain authentication methods such as, EAP-PEAP or EAP-
TTLS, the true identity of the subscriber is hidden from the
RADIUS AAA infrastructure. In these methods the User-name(1)
attribute contains an anonymous identity 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 certain roaming situations
intermediaries and visited network require to be able to
correlate an authentication session with a user identity; A
broker may require to implement a policy where by only session
is allowed per user entity. Third party billing brokers may
require to match accounting records to a user identity.
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 identity alias. It is assigned
by the home RADIUS server and MAY be sent in Access-Accept
message. The NAS MUST include this attribute in the Accounting
Requests (Start, Interim, and Stop) messages if it was included
in the Access Accept message.
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.
A summary of the User Identity Alias Attribute is shown 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
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 the Charging Type identifier and the
second part is the Charging identifier. The Charging Type
identifier is a two octet hexadecimal string, which defines
explicitly the interpretation of the following Charging
identity. The Charging identity part must be at least one
octet.
Following Charging Type identities have been defined:
00 – reserved
01 – IMSI
02 – NAI
03 – E.164 number
04 – SIP URL (as defined in [13])
05 – Opaque string
Below are examples of User Identity Alias Strings with NAI
and E.164 Charging Types:
“02:user@realm.org”
“03:+4689761234”
Additional Charging Type identifiers 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
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.
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 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
later be indicated to the client through several means – for
example, it can be relayed in the “home agent 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 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
6
Address
The Address filed is four octets. It contains a Mobile IP
home agent address.
2.4 RADIUS Support for Specifying IP 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
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 subscription profile.
There is a need for an interoperable method by which a NAS can
indicate its currently available IP address type options to a
home network for a given client. And then, the home network can
specify the desired IP address type option to be used for
assigning an IP address to the client.
Attribute
This attribute indicates IPv4 address type options. It can be
present in Access-Request, Access-Accept, and Accounting-
Request records where the Acc-Status-Type is set to Start or
Stop. When it is used in an Access-Accept and Accounting-
Request packets, the Address Type value MUST be 1 or 2.
A NAS includes this attribute in the AR to advertise its
supported IP address type options. A RADIUS server includes
this attribute in the Access-Accept to specify an IP address
type option for the PWLAN client.
A RADIUS server MUST NOT include this attribute in the Access-
Accept if the IP Address Type options were not advertised in
the Access-Request. If an invalid IP Address Type option is
received in the Access-Accept, then the AN MUST use its default
IP Address Type option for the client. Otherwise, the AN MUST
Adrangi, et al. Expires November 13, 2004 [Page 7]
Internet Draft RADIUS Attributes Extension 10 May 2004
assign an IP address according to the specified type option.
In either case it MUST include this attribute in Accounting-
Request packets to indicate the used IP address type option.
If an IP address type option is not specified in the Access-
Accept, the NAS MUST NOT include this attribute in Accounting-
Request packets.
A summary of the home-agent Attribute is shown 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 |IP Address Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Name
IP Address Type Options
Type
To be assigned by IANA
Length
1
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.
4. Security Considerations
The attributes in this document have no additional security
considerations beyond those already identified in [?].
5. Acknowledgements
TBD
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’ 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
Copyright (C) The Internet Society (2002). All Rights
Reserved.
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]
| PAFTECH AB 2003-2026 | 2026-04-22 13:22:48 |