draft-ietf-radext-datatypes-07.txt   draft-ietf-radext-datatypes-08.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Updates: 2865,3162,6158,6572 Updates: 2865,3162,6158,6572
Category: Standards Track Category: Standards Track
<draft-ietf-radext-datatypes-07.txt> <draft-ietf-radext-datatypes-08.txt>
24 August 2016 18 October 2016
Data Types in the Remote Authentication Data Types in the Remote Authentication
Dial-In User Service Protocol (RADIUS) Dial-In User Service Protocol (RADIUS)
Abstract Abstract
RADIUS specifications have used data types for two decades without RADIUS specifications have used data types for two decades without
defining them as managed entities. During this time, RADIUS defining them as managed entities. During this time, RADIUS
implementations have named the data types, and have used them in implementations have named the data types, and have used them in
attribute definitions. This document updates the specifications to attribute definitions. This document updates the specifications to
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 April 24, 2017. This Internet-Draft will expire on May 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
3.7. ifid ................................................ 16 3.7. ifid ................................................ 16
3.8. ipv4addr ............................................ 17 3.8. ipv4addr ............................................ 17
3.9. ipv6addr ............................................ 18 3.9. ipv6addr ............................................ 18
3.10. ipv6prefix ......................................... 18 3.10. ipv6prefix ......................................... 18
3.11. ipv4prefix ......................................... 20 3.11. ipv4prefix ......................................... 20
3.12. integer64 .......................................... 21 3.12. integer64 .......................................... 21
3.13. tlv ................................................ 22 3.13. tlv ................................................ 22
3.14. vsa ................................................ 23 3.14. vsa ................................................ 23
3.15. extended ........................................... 24 3.15. extended ........................................... 24
3.16. long-extended ...................................... 26 3.16. long-extended ...................................... 26
3.17. evs ................................................ 28 3.17. evs ................................................ 29
4. Updated Registries ....................................... 29 4. Updated Registries ....................................... 30
4.1. Create a Data Type Registry ......................... 29 4.1. Create a Data Type Registry ......................... 30
4.2. Updates to the Attribute Type Registry .............. 30 4.2. Updates to the Attribute Type Registry .............. 31
5. Security Considerations .................................. 35 5. Security Considerations .................................. 36
6. IANA Considerations ...................................... 36 6. IANA Considerations ...................................... 37
7. References ............................................... 36 7. References ............................................... 37
7.1. Normative References ................................ 36 7.1. Normative References ................................ 37
7.2. Informative References .............................. 37 7.2. Informative References .............................. 38
1. Introduction 1. Introduction
RADIUS specifications have historically defined attributes in terms RADIUS specifications have historically defined attributes in terms
of name, value, and data type. Of these three pieces of information, of name, value, and data type. Of these three pieces of information,
the name is recorded by IANA in the RADIUS Attribute Type registry, the name is recorded by IANA in the RADIUS Attribute Type registry,
but not otherwise managed or restricted, as discussed in [RFC6929] but not otherwise managed or restricted, as discussed in [RFC6929]
Section 2.7.1. The value is managed by IANA, and recorded in that Section 2.7.1. The value is managed by IANA, and recorded in that
registry. The data type is not managed or recorded in the RADIUS registry. The data type is not managed or recorded in the RADIUS
Attribute Type registry. Experience has shown that there is a need Attribute Type registry. Experience has shown that there is a need
skipping to change at page 7, line 23 skipping to change at page 7, line 23
These terms are used in preference to the term "String", which was These terms are used in preference to the term "String", which was
previously used in ambiguous ways. It is RECOMMENDED that future previously used in ambiguous ways. It is RECOMMENDED that future
specifications use type-specific names, and the same naming scheme specifications use type-specific names, and the same naming scheme
for new types. This use will maintain consistent definitions, and for new types. This use will maintain consistent definitions, and
help to avoid ambiguities. help to avoid ambiguities.
2.1.2. Attribute Definitions using Data Types 2.1.2. Attribute Definitions using Data Types
New RADIUS specifications MUST define attributes using data types New RADIUS specifications MUST define attributes using data types
from the RADIUS Data Type registry. The specification may, of from the RADIUS Data Type registry. The specification may, of
course, define a new data type and use it in the same document. The course, define a new data type update the "Data Types" registry, and
guidelines given in [RFC6929] MUST be followed when defining a new use the new data type, all in the same document. The guidelines
data type. given in [RFC6929] MUST be followed when defining a new data type.
Attributes can usually be completely described via the Attribute Type Attributes can usually be completely described via the Attribute Type
value, name, and data type. The use of "ASCII art" is then limited value, name, and data type. The use of "ASCII art" is then limited
only to the definition of new data types, and for complex data types. only to the definition of new data types, and for complex data types.
Use of the new extended attributes [RFC6929] makes ASCII art even Use of the new extended attributes [RFC6929] makes ASCII art even
more problematic. An attribute can be allocated from any of the more problematic. An attribute can be allocated from any of the
extended spaces, with more than one option for attribute header extended spaces, with more than one option for attribute header
format. This allocation decision is made after the specification has format. This allocation decision is made after the specification has
been accepted for publication. As the allocation affects the format been accepted for publication. As the allocation affects the format
skipping to change at page 9, line 49 skipping to change at page 9, line 49
Where the contents of a data type do not match the definition, Where the contents of a data type do not match the definition,
implementations MUST treat the the enclosing attribute as being an implementations MUST treat the the enclosing attribute as being an
"invalid attribute". This requirement includes, but is not limited "invalid attribute". This requirement includes, but is not limited
to, the following situations: to, the following situations:
* Attributes with values outside of the allowed range(s) for the * Attributes with values outside of the allowed range(s) for the
data type, e.g. as given in the data types "integer", "ipv4addr", data type, e.g. as given in the data types "integer", "ipv4addr",
"ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum".
* "text" attributes where the contents do not match the required * "text" attributes where the contents do not match the required
format, format,
* Attributes where the length is shorter or longer than the allowed * Attributes where the length is shorter or longer than the allowed
length(s) for the given data type, length(s) for the given data type,
The requirements for "reserved" fields are more difficult to The requirements for "reserved" fields are more difficult to
quantify. Implementations SHOULD be able to receive and process quantify. Implementations SHOULD be able to receive and process
attributes where "reserved" fields are non-zero. We do not, however, attributes where "reserved" fields are non-zero. We do not, however,
define any "correct" processing of such attributes. Instead, define any "correct" processing of such attributes. Instead,
specifications which define new meaning for "reserved" fields SHOULD specifications which define new meaning for "reserved" fields SHOULD
describe how the new meaning is compatible with older describe how the new meaning is compatible with older
skipping to change at page 19, line 25 skipping to change at page 19, line 25
Length Length
At least two, and no more than eighteen octets. At least two, and no more than eighteen octets.
Format Format
0 1 2 3 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 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 ... | Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ... ... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix ... ... Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix | ... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Reserved Reserved
This field, which is reserved and MUST be present, is always This field, which is reserved and MUST be present, is always
set to zero. set to zero. This field is one octet in length.
Prefix-Length Prefix-Length
The length of the prefix, in bits. At least 0 and no larger The length of the prefix, in bits. At least 0 and no larger
than 128. than 128. This field is one octet in length.
Prefix Prefix
The Prefix field is up to 16 octets in length. Bits outside of The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, MUST be zero. the Prefix-Length, if included, MUST be zero.
The Prefix field SHOULD NOT contain more octets than necessary The Prefix field SHOULD NOT contain more octets than necessary
to encode the Prefix. to encode the Prefix.
3.11. ipv4prefix 3.11. ipv4prefix
skipping to change at page 20, line 34 skipping to change at page 20, line 34
Length Length
six octets six octets
Format Format
0 1 2 3 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 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 ... | Reserved | Prefix-Length | Prefix ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Prefix | ... Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Reserved Reserved
This field, which is reserved and MUST be present, is always This field, which is reserved and MUST be present, is always
set to zero. This field is one octet in length. set to zero. This field is one octet in length.
skipping to change at page 26, line 31 skipping to change at page 26, line 31
Length Length
Three or more octets Three or more octets
Format Format
0 1 2 3 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 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 ... | Extended-Type |M|T| Reserved | Ext-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subfields Subfields
Extended-Type Extended-Type
This field is identical to the Extended-Type field defined This field is identical to the Extended-Type field defined
above in Section 3.15. above in Section 3.15.
M (More) M (More)
skipping to change at page 27, line 24 skipping to change at page 27, line 24
contain all fragments of the attribute, and those fragments contain all fragments of the attribute, and those fragments
need to be contiguous in the packet. RADIUS does not support need to be contiguous in the packet. RADIUS does not support
inter-packet fragmentation, which means that fragmenting an inter-packet fragmentation, which means that fragmenting an
attribute across multiple packets is impossible. attribute across multiple packets is impossible.
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can "More" field set (1), but for which no subsequent fragment can
be found, then the fragmented attribute is considered to be an be found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per [RFC6929] Section 2.8. "invalid attribute", and handled as per [RFC6929] Section 2.8.
Reserved T (Truncation)
This field is 7 bits long, and is reserved for future use. This field is one bit in size and is
Implementations MUST set it to zero (0) when encoding an called "T" for Truncation. It
attribute for sending in a packet. The contents SHOULD be indicates that the attribute is
ignored on reception. intentionally truncated in this
chunk and is to be continued in the
next chunk of the sequence. The
combination of the M flag and the T
flag indicates that the attribute is
fragmented (M flag) but that all the
fragments are not available in this
chunk (T flag). Proxies
implementing [RFC6929] will see
these attributes as invalid (they
will not be able to reconstruct
them), but they will still forward
them, as Section 5.2 of [RFC6929]
indicates that they SHOULD forward
unknown attributes anyway.
Future specifications may define additional meaning for this Please see [RFC7499] for further
field. Implementations therefore MUST NOT treat this field as discussion of the uses of this flag.
invalid if it is non-zero.
Ext-Data Reserved
The contents of this field MUST be a valid data type as defined This field is 6 bits long, and is
in the RADIUS Data Type registry. The Ext-Data field MUST NOT reserved for future use.
contain any of the following data types: "concat", "vsa", Implementations MUST set it to zero
"extended", "long-extended", or "evs". (0) when encoding an attribute for
sending in a packet. The contents
SHOULD be ignored on reception.
The Ext-Data field is one or more octets. Future specifications may define
additional meaning for this field.
Implementations therefore MUST NOT
treat this field as invalid if it is
non-zero.
Implementations supporting this specification MUST use the Ext-Data
Identifier of "Type.Extended-Type" to determine the
interpretation of the Ext-Data field.
The length of the data MUST be taken as the sum of the lengths The contents of this field MUST be a
of the fragments (i.e. Ext-Data fields) from which it is valid data type as defined in the
constructed. Any interpretation of the resulting data MUST RADIUS Data Type registry. The Ext-
occur after the fragments have been reassembled. If the Data field MUST NOT contain any of
reassembled data does not match the expected format, each the following data types: "concat",
fragment MUST be treated as an "invalid attribute", and the "vsa", "extended", "long-extended",
reassembled data MUST be discarded. or "evs".
We note that the maximum size of a fragmented attribute is The Ext-Data field is one or more
limited only by the RADIUS packet length limitation. octets.
Implementations MUST be able to handle the case where one
fragmented attribute completely fills the packet. Implementations supporting this
specification MUST use the
Identifier of "Type.Extended-Type"
to determine the interpretation of
the Ext-Data field.
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. Any
interpretation of the resulting data
MUST occur after the fragments have
been reassembled. If the
reassembled data does not match the
expected format, each fragment MUST
be treated as an "invalid
attribute", 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. Implementations MUST be
able to handle the case where one
fragmented attribute completely
fills the packet.
3.17. evs 3.17. evs
The "evs" data type encodes an "Extended Vendor-Specific" attribute, The "evs" data type encodes an "Extended Vendor-Specific" attribute,
as given in [RFC6929] Section 2.4. The "evs" data type is used as given in [RFC6929] Section 2.4. The "evs" data type is used
solely to extend the Vendor Specific space. It MAY appear inside of solely to extend the Vendor Specific space. It MAY appear inside of
an "extended" or a "long-extended" data type. It MUST NOT appear in an "extended" or a "long-extended" data type. It MUST NOT appear in
the contents of any other data type. the contents of any other data type.
Where an implementation determines that an attribute of data type Where an implementation determines that an attribute of data type
skipping to change at page 29, line 38 skipping to change at page 30, line 31
4. Updated Registries 4. Updated Registries
This section defines a new IANA registry for RADIUS data types, and This section defines a new IANA registry for RADIUS data types, and
then updates the existing RADIUS Attribute Type registry to use the then updates the existing RADIUS Attribute Type registry to use the
data types from the new registry. data types from the new registry.
4.1. Create a Data Type Registry 4.1. Create a Data Type Registry
This section defines a new registry located under "RADIUS Types", This section defines a new registry located under "RADIUS Types",
called "Data Type". Allocation in this registry requires IETF called "Data Type". The "Registration Procedures" for the Data Type
Review. The "Registration Procedures" for the Data Type registry are registry are "Standards Action".
"Standards Action".
The Data Type registry contains three columns of data, as follows. The Data Type registry contains three columns of data, as follows.
Value Value
The number of the data type. The value field is an artifact of The number of the data type. The value field is an artifact of
the registry, and has no on-the-wire meaning. the registry, and has no on-the-wire meaning.
Description Name
The name of the data type. The name field is used only for the The name of the data type. The name field is used only for the
registry, and has no on-the-wire meaning. registry, and has no on-the-wire meaning.
Reference Reference
The specification where the data type was defined. The specification where the data type was defined.
The initial contents of the registry are as follows. The initial contents of the registry are as follows.
skipping to change at page 35, line 6 skipping to change at page 35, line 46
187,WLAN-Group-Cipher,integer,[RFC7268] 187,WLAN-Group-Cipher,integer,[RFC7268]
188,WLAN-AKM-Suite,integer,[RFC7268] 188,WLAN-AKM-Suite,integer,[RFC7268]
189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268]
190,WLAN-RF-Band,integer,[RFC7268] 190,WLAN-RF-Band,integer,[RFC7268]
191,Unassigned,, 191,Unassigned,,
192-223,Experimental Use,,[RFC3575] 192-223,Experimental Use,,[RFC3575]
224-240,Implementation Specific,,[RFC3575] 224-240,Implementation Specific,,[RFC3575]
241,Extended-Attribute-1,extended,[RFC6929] 241,Extended-Attribute-1,extended,[RFC6929]
241.1,Frag-Status,integer,[RFC7499] 241.1,Frag-Status,integer,[RFC7499]
241.2,Proxy-State-Length,integer,[RFC7499] 241.2,Proxy-State-Length,integer,[RFC7499]
241.{3-25},Unassigned,, 241.3,Response-Length,integer,[RFC7930]
241.4,Original-Packet-Code,integer,[RFC7930]
241.{5-25},Unassigned,,
241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 241.26,Extended-Vendor-Specific-1,evs,[RFC6929]
241.{27-240},Unassigned,, 241.{27-240},Unassigned,,
241.{241-255},Reserved,,[RFC6929] 241.{241-255},Reserved,,[RFC6929]
242,Extended-Attribute-2,extended,[RFC6929] 242,Extended-Attribute-2,extended,[RFC6929]
242.{1-25},Unassigned,, 242.{1-25},Unassigned,,
242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 242.26,Extended-Vendor-Specific-2,evs,[RFC6929]
242.{27-240},Unassigned,, 242.{27-240},Unassigned,,
242.{241-255},Reserved,,[RFC6929] 242.{241-255},Reserved,,[RFC6929]
243,Extended-Attribute-3,extended,[RFC6929] 243,Extended-Attribute-3,extended,[RFC6929]
243.{1-25},Unassigned,, 243.{1-25},Unassigned,,
skipping to change at page 37, line 21 skipping to change at page 38, line 17
(EAP) Application", RFC 4072, February 2013. (EAP) Application", RFC 4072, February 2013.
[RFC6158] [RFC6158]
DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158,
March 2011. March 2011.
[RFC6572] [RFC6572]
Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572,
June 2012. June 2012.
[RFC7499]
Perez-Mendez, A. Ed., et al, "Support of Fragmentation of RADIUS
Packets", RFC 7499, April 2015.
7.2. Informative References 7.2. Informative References
[RFC2868] [RFC2868]
Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I.
Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868,
June 2000. June 2000.
[RFC2869] [RFC2869]
Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000.
 End of changes. 23 change blocks. 
54 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/