Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)
draft-dekok-radext-datatypes-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Alan DeKok | ||
| Last updated | 2013-02-01 | ||
| Replaced by | draft-ietf-radext-datatypes, RFC 8044 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dekok-radext-datatypes-01
Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS
Updates: 2865,3162,6158
Category: Standards Track
<draft-dekok-radext-datatypes-01.txt>
1 February 2013
Data Types in the Remote Authentication
Dial-In User Service Protocol (RADIUS)
draft-dekok-radext-datatypes-01.txt
Abstract
RADIUS specifications have used data types for two decades, without
rigorously defining them as managed entities. During this time,
RADIUS implementations have named the data types, and have used them
to as managed entities in attribute definitions. This document
updates the specifications to match established prctice. We do this
by naming data types defined in [RFC6158], which have been used since
at least [RFC2865]. We provide an IANA registry for the data types,
and update the RADIUS Attribute Type registry to include a "data
type" field for each attribute. Finally, we recommend that authors
of RADIUS specifications use these types in preference to existing
practice.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
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 July 31, 2013.
DeKok, Alan Standards Track [Page 1]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
DeKok, Alan Standards Track [Page 2]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Table of Contents
1. Introduction ............................................. 4
1.1. Specification use of Data Types ..................... 4
1.2. Implementation use of Data Types .................... 4
1.3. Requirements Language ............................... 5
2. Data Type Definitions .................................... 6
2.1. Integer ............................................. 7
2.2. Enum ................................................ 8
2.3. IPv4addr ............................................ 8
2.4. Time ................................................ 9
2.5. Text ................................................ 9
2.6. String .............................................. 10
2.7. Ifid ................................................ 10
2.8. IPv6addr ............................................ 11
2.9. IPv6prefix .......................................... 12
2.10. Integer64 .......................................... 13
2.11. TLV ................................................ 13
2.12. VSA ................................................ 15
2.13. Extended ........................................... 16
2.14. Long-Extended ...................................... 17
2.15. EVS ................................................ 19
3. Updated Registries ....................................... 20
3.1. Create a Data Type Registry ......................... 21
3.2. Updates to the Attribute Type Registry .............. 21
4. Suggestions for Authors .................................. 25
5. Security Considerations .................................. 26
6. IANA Considerations ...................................... 26
7. References ............................................... 26
7.1. Normative References ................................ 26
7.2. Informative References .............................. 27
DeKok, Alan Standards Track [Page 3]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
1. Introduction
RADIUS specifications have historically defined attributes in terms
of name, type value, and data type. Of these three pieces of
information, only the type value is managed by IANA. There is no
management of, or restriction on the attribute name, as discussed in
[EXTEN] Section 2.7.1. There is no management of data type name or
definition. This document defines an IANA registry for data types,
and updates the RADIUS Attribute Type registry to use those newly
defined data types.
In this section, we review the use of data types in specifications
and implementations. Whe highlight ambiguities and inconsistencies.
The rest of this document is devoted to resolving those issues.
1.1. Specification use of Data Types
A number of data type names and definitions are given in [RFC2865]
Section 5, at the bottom of page 25. These data types are named and
clearly defined. However, this practice was not continued in later
specifications.
Specifically, [RFC2865] defines attributes of data type "address" to
carry IPv4 addresses. Despite this definition, [RFC3162] defines
attributes of data type "Address" to carry IPv6 addresses. We
suggest that the use of the word "address" to refer to disparate data
types is problematic.
Other failures are that [RFC3162] does not give a data type name and
definition for the data types IPv6 address, Interface-Id, or IPv6
prefix. Also, [RFC2869] defines Event-Timestamp to carry a time.
Instead of re-using the "time" data type defined in [RFC2865], it
repeats the "time" definition.
These ambiguities and inconsistencies need to be resolved.
1.2. Implementation use of Data Types
RADIUS implementations often use "dictionaries" to map attribute
names to type values, and to define data types for each attribute.
The data types in the dictionaries are defined by each
implementation, but correspond to the "ad hoc" data types used in the
specifications.
In effect, implementations have seen the need for well-defined data
types, and have created them. RADIUS specifications need to follow
this practice.
DeKok, Alan Standards Track [Page 4]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
This document requires no changes to any RADIUS implementation, past,
present, or future. It instead documents existing practice, in order
to simplify the process of writing RADIUS specifications, to clarify
the interpretation of RADIUS standards, and to improve the
communication between specification authors and IANA.
1.3. Requirements Language
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].
DeKok, Alan Standards Track [Page 5]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
2. Data Type Definitions
This section defines the new data types. For each data type, it
gives a definition, a name, a number, a length, and an encoding
format. Where relevant, it describes subfields contained within the
data type. We reiterate that these definitions have no impact on
existing RADIUS implementations. There is no requirement that
implementations use these names.
Where possible, the name of each data type has been taken from
previous specifications. In some cases, a different name has been
chosen. The change of name is required to avoid ambiguity (i.e.
"address" versus "Address"). Otherwise, the new name has been chosen
to be compatible with [RFC2865], or with use in common
implementations. In some cases, new names are chosen to clarify the
interpretation of the data type.
The numbers assigned here for the data types have no meaning other
than to permit them to be tracked by IANA.
The encoding of each data type is taken from previous specifications.
The fields are transmitted from left to right.
The data types are given below in mostly arbitrary order. Where the
data types have inter-dependencies, the simplest data type is given
first, and dependent ones are given later.
We do not create specific data types for the "tagged" attributes, as
discussed in [RFC2868]. That specification defines the "tagged"
attributes as being backwards compatible with pre-existing data
types. In addition, [RFC6158] Section 2.1 says that "tagged"
attributes should not be used. There is therefore no benefit to
defining additional data types for these attributes.
Implementations not supporting a particular data type MUST treat
attributes of that data type as being of data type "string". See
Section 2.6 for a definition of the "string" data type.
The definitions below will use specialized names for various fields
of attributes and data types. These names serve to address ambiguity
of the field names in previous specifications. For example, the term
"Value" is used in [RFC2865] Section 5 as the contents of an
attribute. It is then used in later sections as the sub-field of an
attribute definition. The result is that "Value" is defined
recursively to contain itself. Similarly, "String" is used both as a
data type, and as a sub-field of other data types.
We therefore use the slightly different terminology than previous
DeKok, Alan Standards Track [Page 6]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
specifications. The main addition is the following term:
Attr-Data
The "Value" field of an Attribute as defined in [RFC2865] Section
5. The contents of this field MUST be a valid data type as
defined in the RADIUS Data Type registry.
In this document, we use the term "Value" only to refer to the
contents of a data type, where that data type cannot carry other data
types.
Other terms are defined below in the sections specific to each data
type. These terms are different than the terms used in previous
specifications, though they refer to the same logical fields. We
suggest that future RADIUS specifications use thes updated terms in
order to maintain consisten definitions, and to avoid ambiguities.
2.1. Integer
The "integer" data type encodes a 32-bit unsigned integer in network
byte order. Where the range of values for a particular attribute is
limited to a sub-set of the values, specifications MUST define the
valid range.
Name
integer
Number
1
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DeKok, Alan Standards Track [Page 7]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
2.2. Enum
The "enum" data type encodes a 32-bit unsigned integer in network
byte order. It differs from the "integer" data type only in that it
is used to define enumerated types, such as Service-Type.
Name
enum
Number
2
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. IPv4addr
The "ipv4addr" data type encodes an IPv4 address in network byte
order. Where the range of address for a particular attribute is
limited to a sub-set of possible addresses, specifications MUST
define the valid range.
Name
ipv4addr
Number
3
Length
Four octets
Format
DeKok, Alan Standards Track [Page 8]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4. Time
The "time" data type encodes time as a 32-bit unsigned value in
network byte order and in seconds since 00:00:00 UTC, January 1,
1970.
Name
time
Number
4
Length
Four octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.5. Text
The "text" data type encodes UTF-8 text [RFC3629]. The maximum
length of the text is given by the encapsulating attribute. Where
the range of lengths for a particular attribute is limited to a sub-
set of possible longths, specifications MUST define the valid range.
Name
text
Number
5
DeKok, Alan Standards Track [Page 9]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Length
One or more octets.
Format
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Value ...
+-+-+-+-+-+-+-+-
2.6. String
The "string" data type encodes binary data, as a sequence of
undistinguished octets. This includes opaque encapsulation of data
structures defined outside of RADIUS. Where the length for a
particular attribute is limited, specifications MUST define a maximum
length.
Name
string
Number
6
Length
One or more octets.
Format
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-
| Octets ...
+-+-+-+-+-+-+-+-
2.7. Ifid
The "ifid" data type encodes an Interface-Id as an 8-octet string in
network byte order.
Name
DeKok, Alan Standards Track [Page 10]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
ifid
Number
7
Length
Eight octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface-ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Interface-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.8. IPv6addr
The "ipv6addr" data type encodes an IPv6 address in network byte
order. Where the range of address for a particular attribute is
limited to a sub-set of possible addresses, specifications MUST
define the valid range.
Name
ipv6addr
Number
8
Length
Sixteen octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
DeKok, Alan Standards Track [Page 11]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.9. IPv6prefix
The "ipv6addr" data type encodes an IPv6 prefix, using both a prefix
and an IPv6 address in network byte order.
Name
ipv6prefix
Number
9
Length
At least two, and no more than eighteen octets.
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Reserved
This field, which is reserved and MUST be present, is always
set to zero.
Prefix-Length
The length of the prefix, in bits. At least 0 and no larger
DeKok, Alan Standards Track [Page 12]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
than 128.
Prefix
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.
2.10. Integer64
The "integer64" data type encodes a 64-bit unsigned integer in
network byte order. Where the range of values for a particular
attribute is limited to a sub-set of the values, specifications MUST
define the valid range.
Name
integer64
Number
10
Length
Eight octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.11. TLV
The "tlv" data type encodes a type-length-value, as defined in
[EXTEN] Section 2.3.
Name
tlv
Number
DeKok, Alan Standards Track [Page 13]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
11
Length
Three or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV-Type | TLV-Length | TLV-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
TLV-Type
This field is one octet. Up-to-date values of this field are
specified according to the policies and rules described in
[EXTEN] Section 10. Values 254-255 are "Reserved" for use by
future extensions to RADIUS. The value 26 has no special
meaning, and MUST NOT be treated as a Vendor Specific
attribute.
The TLV-Type is meaningful only within the context defined by
"Type" fields of the encapsulating Attributes, using the
dotted-number notation introduced in [EXTEN].
A RADIUS server MAY ignore Attributes with an unknown "TLV-
Type".
A RADIUS client MAY ignore Attributes with an unknown "TLV-
Type".
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-
Type" verbatim.
TLV-Length
The TLV-Length field is one octet, and indicates the length of
this TLV including the TLV-Type, TLV-Length and TLV-Value
fields. It MUST have a value between 3 and 255. If a client
or server receives a TLV with an invalid TLV-Length, then the
attribute which encapsulates that TLV MUST be considered to be
an "invalid attribute", and handled as per [EXTEN] Section 2.8.
TLV-Data
DeKok, Alan Standards Track [Page 14]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
The TLV-Data field is one or more octets and contains
information specific to the Attribute. The format and length
of the TLV-Data field is determined by the TLV-Type and TLV-
Length fields.
The TLV-Data field MUST contain only known RADIUS data types.
The TLV-Data field MUST NOT contain any of the following data
types: vsa, extended, long-extended, or evs.
2.12. VSA
The "vsa" data type encodes Vendor-Specific data, as given in
[RFC2865] Section 5.26. It is used only in the Attr-Data field of a
Vendor-Specific Attribute. It MUST NOT appear in the contents of any
other data type.
Name
vsa
Number
12
Length
Five or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSA-String ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Vendor-Id
The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order.
VSA-String
DeKok, Alan Standards Track [Page 15]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
The VSA-String field is one or more octets. The actual format
of the information is site or application specific, and a
robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
It SHOULD be encoded as a sequence of "tlv" fields. The
interpretation of the TLV-Type and TLV-Data fields are
dependent on the vendor's definition of that attribute.
2.13. Extended
The "extended" data type encodes the "Extended Type" format, as given
in [EXTEN] Section 2.1. It is used only in the Attr-Data field of an
Attribute. It MUST NOT appear in the contents of any other data
type.
Name
extended
Number
13
Length
Two or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Extended-Type
The Extended-Type field is one octet. Up-to-date values of
this field are specified according to the policies and rules
described in [EXTEN] Section 10. Unlike the Type field defined
in [RFC2865] Section 5, no values are allocated for
DeKok, Alan Standards Track [Page 16]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
experimental or implementation-specific use. Values 241-255
are reserved and MUST NOT be used.
The Extended-Type is meaningful only within a context defined
by the Type field. That is, this field may be thought of as
defining a new type space of the form "Type.Extended-Type".
See [EXTEN] Section 2.5 for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type".
Ext-Data
The contents of this field MUST be a valid data type as defined
in the RADIUS Data Type registry.. The Ext-Data field MUST NOT
contain any of the following data types: vsa, extended, long-
extended, or evs.
The Ext-Data field is one or more octets.
Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field.
2.14. Long-Extended
The "long-extended" data type encodes the "Long Extended Type"
format, as given in [EXTEN] Section 2.2. It is used only in the
Attr-Data field of an Attribute. It MUST NOT appear in the contents
of any other data type.
Name
long-extended
Number
14
Length
Three or more octets
Format
DeKok, Alan Standards Track [Page 17]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-Type |M| Reserved | Ext-Data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Extended-Type
This field is identical to the Extended-Type field defined
above in Section 2.13.
M (More)
The More field is one (1) bit in length, and indicates whether
or not the current attribute contains "more" than 251 octets of
data. The More field MUST be clear (0) if the Length field has
value less than 255. The More field MAY be set (1) if the
Length field has value of 255.
If the More field is set (1), it indicates that the Ext-Data
field has been fragmented across multiple RADIUS attributes.
When the More field is set (1), the attribute MUST have a
Length field of value 255; there MUST be an attribute following
this one; and the next attribute MUST have both the same Type
and Extended Type. That is, multiple fragments of the same
value MUST be in order and MUST be consecutive attributes in
the packet, and the last attribute in a packet MUST NOT have
the More field set (1).
That is, a packet containing a fragmented attribute needs to
contain all fragments of the attribute, and those fragments
need to be contiguous in the packet. RADIUS does not support
inter-packet fragmentation, which means that fragmenting an
attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can
be found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per [EXTEN] Section 2.8.
Reserved
This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an
attribute for sending in a packet. The contents SHOULD be
ignored on reception.
DeKok, Alan Standards Track [Page 18]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as
invalid if it is non-zero.
Ext-Data
The contents of this field MUST be a valid data type as defined
in the RADIUS Data Type registry.. The Ext-Data field MUST NOT
contain any of the following data types: vsa, extended, long-
extended, or evs.
The Ext-Data field is one or more octets.
Implementations supporting this specification MUST use the
Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field.
Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST
be taken as the sum of the lengths of the fragments (i.e. Ext-
Data fields) from which it is constructed. The format of the
data SHOULD be a valid RADIUS data type. If the reassembled
data does not match the expected format, all fragments MUST be
treated as "invalid attributes", and the reassembled data MUST
be discarded.
We note that the maximum size of a fragmented attribute is
limited only by the RADIUS packet length limitation (i.e. 4096
octets, not counting various headers and overhead).
Implementations MUST be able to handle the case where one
fragmented attribute completely fill the packet.
2.15. EVS
The "evs" data type encodes an "extended vendor-specific" attribute,
as given in [EXTEN] Section 2.4. The "evs" data type is used solely
to extend the Vendor Specific space. It can occur inside of an
"extended" or "long-extended" data type, and MUST NOT appear in the
contents of any other data type.
Name
evs
Number
15
DeKok, Alan Standards Track [Page 19]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Length
Six or more octets
Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | EVS-String ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields
Vendor-Id
The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order.
Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor.
EVS-String
The EVS-String field is one or more octets. It SHOULD
encapsulate a previously defined RADIUS data type. Non-
standard data types SHOULD NOT be used. We note that the EVS-
String field may be of data type "tlv".
The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field
as undistinguished octets. We recognise that Vendors have
complete control over the contents and format of the Ext-String
field, while at the same time recommending that good practices
be followed.
Further codification of the range of allowed usage of this
field is outside the scope of this specification.
3. Updated Registries
This section defines a new IANA registry for RADIUS data types, and
updates the existing RADIUS Attribute Type registry.m
DeKok, Alan Standards Track [Page 20]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
3.1. Create a Data Type Registry
This section defines a new RADIUS registry, called "Data Type".
Allocation in this registry requires IETF Review. The "Registration
Procedures" for this registry are "Standards Action".
The registry contains three columns of data, as follows.
Value
The number of the data type.
Description
The name of the data type.
Reference
The specification where the data type was defined.
The initial contents of the registry are as follows.
Value Description Reference
----- ----------- ----------------
1 integer [RFC2865], TBD
2 enum [RFC2865], TBD
3 ipv4addr [RFC2865], TBD
4 time [RFC2865], TBD
5 text [RFC2865], TBD
6 string [RFC2865], TBD
7 ifid [RFC3162], TBD
8 ipv6addr [RFC3162], TBD
9 ipv6prefix [RFC3162], TBD
10 integer64 [EXTEN], TBD
11 tlv [EXTEN], TBD
12 evs [EXTEN], TBD
3.2. Updates to the Attribute Type Registry
This section updates the RADIUS Attribute Type Registry to have a new
column, which is inserted in between the existing "Description" and
"Reference" columns. The new column is named "Data Type". The
contents of that column are the name of a data type, corresponding to
the attribute in that row, or blank if the attribute type is
unassigned. The name of the data type is taken from the RADIUS Data
Type registry, defined above.
Value Description Data Type
DeKok, Alan Standards Track [Page 21]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
----- ---------------------------------------- ---------
1 User-Name text
2 User-Password text
3 CHAP-Password string
4 NAS-IP-Address ipaddr
5 NAS-Port integer
6 Service-Type enum
7 Framed-Protocol enum
8 Framed-IP-Address ipaddr
9 Framed-IP-Netmask ipaddr
10 Framed-Routing enum
11 Filter-Id text
12 Framed-MTU integer
13 Framed-Compression enum
14 Login-IP-Host ipaddr
15 Login-Service enum
16 Login-TCP-Port enum
18 Reply-Message text
19 Callback-Number text
20 Callback-Id text
22 Framed-Route text
23 Framed-IPX-Network ipaddr
24 State string
25 Class string
26 Vendor-Specific vsa
27 Session-Timeout integer
28 Idle-Timeout integer
29 Termination-Action enum
30 Called-Station-Id text
31 Calling-Station-Id text
32 NAS-Identifier text
33 Proxy-State string
34 Login-LAT-Service text
35 Login-LAT-Node text
36 Login-LAT-Group string
37 Framed-AppleTalk-Link integer
38 Framed-AppleTalk-Network integer
39 Framed-AppleTalk-Zone text
40 Acct-Status-Type enum
41 Acct-Delay-Time integer
42 Acct-Input-Octets integer
43 Acct-Output-Octets integer
44 Acct-Session-Id text
45 Acct-Authentic enum
46 Acct-Session-Time integer
47 Acct-Input-Packets integer
48 Acct-Output-Packets integer
49 Acct-Terminate-Cause enum
DeKok, Alan Standards Track [Page 22]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
50 Acct-Multi-Session-Id text
51 Acct-Link-Count integer
52 Acct-Input-Gigawords integer
53 Acct-Output-Gigawords integer
55 Event-Timestamp time
56 Egress-VLANID integer
57 Ingress-Filters enum
58 Egress-VLAN-Name text
59 User-Priority-Table string
60 CHAP-Challenge string
61 NAS-Port-Type enum
62 Port-Limit integer
63 Login-LAT-Port text
64 Tunnel-Type enum
65 Tunnel-Medium-Type enum
66 Tunnel-Client-Endpoint text
67 Tunnel-Server-Endpoint text
68 Acct-Tunnel-Connection text
69 Tunnel-Password text
70 ARAP-Password string
71 ARAP-Features string
72 ARAP-Zone-Access enum
73 ARAP-Security integer
74 ARAP-Security-Data text
75 Password-Retry integer
76 Prompt enum
77 Connect-Info text
78 Configuration-Token text
79 EAP-Message string
80 Message-Authenticator string
81 Tunnel-Private-Group-Id text
82 Tunnel-Assignment-Id text
83 Tunnel-Preference integer
84 ARAP-Challenge-Response string
85 Acct-Interim-Interval integer
86 Acct-Tunnel-Packets-Lost integer
87 NAS-Port-Id text
88 Framed-Pool text
89 Chargeable-User-Identity text
90 Tunnel-Client-Auth-Id text
91 Tunnel-Server-Auth-Id text
92 NAS-Filter-Rule text
95 NAS-IPv6-Address ipv6addr
96 Framed-Interface-Id ifid
97 Framed-IPv6-Prefix ipv6prefix
98 Login-IPv6-Host ipv6addr
99 Framed-IPv6-Route text
100 Framed-IPv6-Pool text
DeKok, Alan Standards Track [Page 23]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
101 Error-Cause enum
102 EAP-Key-Name text
103 Digest-Response text
104 Digest-Realm text
105 Digest-Nonce text
106 Digest-Response-Auth text
107 Digest-Nextnonce text
108 Digest-Method text
109 Digest-URI text
110 Digest-Qop text
111 Digest-Algorithm text
112 Digest-Entity-Body-Hash text
113 Digest-CNonce text
114 Digest-Nonce-Count text
115 Digest-Username text
116 Digest-Opaque text
117 Digest-Auth-Param text
118 Digest-AKA-Auts text
119 Digest-Domain text
120 Digest-Stale text
121 Digest-HA1 text
122 SIP-AOR text
123 Delegated-IPv6-Prefix ipv6prefix
124 MIP6-Feature-Vector string
125 MIP6-Home-Link-Prefix ipv6prefix
126 Operator-Name text
127 Location-Information string
128 Location-Data string
129 Basic-Location-Policy-Rules string
130 Extended-Location-Policy-Rules string
131 Location-Capable enum
132 Requested-Location-Info enum
133 Framed-Management enum
134 Management-Transport-Protection enum
135 Management-Policy-Id text
136 Management-Privilege-Level integer
137 PKM-SS-Cert string
138 PKM-CA-Cert string
139 PKM-Config-Settings string
140 PKM-Cryptosuite-List string
141 PKM-SAID string
142 PKM-SA-Descriptor string
143 PKM-Auth-Key string
144 DS-Lite-Tunnel-Name text
145 Mobile-Node-Identifier string
146 Service-Selection text
147 PMIP6-Home-LMA-IPv6-Address ipv6addr
148 PMIP6-Visited-LMA-IPv6-Address ipv6addr
DeKok, Alan Standards Track [Page 24]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
149 PMIP6-Home-LMA-IPv4-Address ipaddr
150 PMIP6-Visited-LMA-IPv4-Address ipaddr
151 PMIP6-Home-HN-Prefix ipv6prefix
152 PMIP6-Visited-HN-Prefix ipv6prefix
153 PMIP6-Home-Interface-ID ifid
154 PMIP6-Visited-Interface-ID ifid
155 PMIP6-Home-IPv4-HoA ipv4prefix
156 PMIP6-Visited-IPv4-HoA ipv4prefix
157 PMIP6-Home-DHCP4-Server-Address ipaddr
158 PMIP6-Visited-DHCP4-Server-Address ipaddr
159 PMIP6-Home-DHCP6-Server-Address ipv6addr
160 PMIP6-Visited-DHCP6-Server-Address ipv6addr
161 PMIP6-Home-IPv4-Gateway ipaddr
162 PMIP6-Visited-IPv4-Gateway ipaddr
4. Suggestions for Authors
We suggest that these data types be used in new RADIUS
specifications. Attributes can usually be completely described
through their Attribute Type code, name, and data type. The use of
"ASCII art" to describe attributes is becomes less required.
Use of the new extended attributes [EXTEN] makes ASCII art even more
problematic. An attribute can be allocated from the standard space,
or from one of the extended spaces. This allocation decision is made
after the specification has been accepted for publication, which
makes it difficult to create the correct ASCII art. Allocation from
the different spaces also changes the value of the Length field,
making it difficult to define it clearly prior to final publication
of the document.
The following fields SHOULD be given when defining new attributes:
Description
A description of the meaning and interpretation of the attribute.
Type
The Attribute Type code, given in the "dotted number" notation
from [EXTEN]. Most specifications can leave this as "TBD", and
rely on IANA to fill in the correct values.
Length
A description of the length of the attribute. For attributes of
data type "text" or "string", a maximum length SHOULD be given.
DeKok, Alan Standards Track [Page 25]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
Data Type
One of the named Data Types from Section X.Y, above.
Value
A description of any attribute-specific limitations on the values
carried by the specified data type. If there are no attribute-
specific limitations, then the description of this field can be
omitted.
For attributes of type "integer" or "integer64", where the values
are limited to a subset of the possible range, minimum and maximum
values MUST be defined.
For attributes of data type "enum", a list of enumerated values
and names is given, as with [RFC2865] Section 5.6.
5. Security Considerations
This specification is concerned solely with updates to IANA
registries. As such, there are no security considerations.
6. IANA Considerations
IANA is instructed to create one new registry as described above in
Section X.Y. The "TBD" text in that section should be replaced with
the RFC number of this document when it is published.
IANA is instructed to update the RADIUS Attribute Type registry, as
described above in Section X.Y.
IANA is instructed to require that all future allocations in the
RADIUS Attribute Type Registry contain a "data type" field, using one
of the names defined in the RADIUS Data Type registrty.
7. References
7.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
[RFC2865]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
DeKok, Alan Standards Track [Page 26]
INTERNET-DRAFT Data Types in RADIUS 1 February 2013
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003.
[RFC6158]
DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158,
March 2011.
7.2. Informative References
[RFC2868]
Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.
Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,
June 2000.
[RFC2869]
Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000.
[RFC3162]
Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162,
August 2001.
[EXTEN]
DeKok, A., and Lior, A., "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", draft-ietf-radext-radius-
extensions-04.txt (work in progress), January 2013.
[PEN]
http://www.iana.org/assignments/enterprise-numbers
Acknowledgments
Stuff
Authors' Addresses
Alan DeKok
The FreeRADIUS Server Project
Email: aland@freeradius.org
DeKok, Alan Standards Track [Page 27]