Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 2865,3162,6158,6572 Category: Standards Track 24 June 2014 Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) draft-dekok-radext-datatypes-04.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 as managed entities in attribute definitions. This document updates the specifications to match established practice. We do this by naming data types defined in RFC 6158, which have been used since at least RFC 2865. 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 December 24, 2014. DeKok, Alan Standards Track [Page 1] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 Copyright Notice Copyright (c) 2014 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 24 June 2014 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 ................................................ 11 2.8. ipv6addr ............................................ 12 2.9. ipv6prefix .......................................... 12 2.10. ipv4prefix ......................................... 13 2.11. integer64 .......................................... 14 2.12. tlv ................................................ 15 2.13. vsa ................................................ 17 2.14. extended ........................................... 18 2.15. long-extended ...................................... 19 2.16. evs ................................................ 21 3. Pending and Future work. ................................. 22 4. Updated Registries ....................................... 23 4.1. Create a Data Type Registry ......................... 23 4.2. Updates to the Attribute Type Registry .............. 24 5. Suggestions for Specifications ........................... 25 6. Security Considerations .................................. 26 7. IANA Considerations ...................................... 26 8. References ............................................... 26 8.1. Normative References ................................ 26 8.2. Informative References .............................. 27 DeKok, Alan Standards Track [Page 3] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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 [RFC6929] 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. [RFC2869] defines Event-Timestamp to carry a time, but does not re-use the "time" data type defined in [RFC2865]. Instead, it just repeats the "time" definition. [RFC6572] defines multiple attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data type is not named, defined as a data type, or called out as an addition to RADIUS. Further, [RFC6572] does not follow the recommendations of [RFC6158], and does not explain why it fails to follow those recommendations. 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. DeKok, Alan Standards Track [Page 4] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 In effect, implementations have seen the need for well-defined data types, and have created them. RADIUS specifications need to follow this practice. 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 24 June 2014 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 to define a field which carries the contents of attribute. It is then used in later sections as the sub-field of attribute contents. The result is that the field is defined as recursively containing 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 24 June 2014 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 the updated terms in order to maintain consistent 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. Values outside of the allowed ranges SHOULD be treated as invalid. 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 24 June 2014 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. Specifications MUST define a valid set of enumerated values, along with a unique name for each value. Values outside of the enumerated list SHOULD be treated as invalid. 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(s). Values outside of the allowed range SHOULD be treated as invalid. Name ipv4addr Number 3 Length DeKok, Alan Standards Track [Page 8] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. We note that dates before the year 2013 are likely to be erroneous. Note that the "time" attribute is defined to be unsigned, which means it is not subject to a signed integer overflow in the year 2038. 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 lengths, specifications MUST define the valid DeKok, Alan Standards Track [Page 9] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 range(s). Note that the "text" type does not terminate with a NUL (hex 00). The Attribute has a Length field and does not use a terminator. Texts of length zero (0) MUST NOT be sent; omit the entire attribute instead. Name text Number 5 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. Where the range of lengths for a particular attribute is limited to a sub-set of possible lengths, specifications MUST define the valid range(s). Note that the "string" data type does not terminate with a NUL (hex 00). The Attribute has a Length field and does not use a terminator. Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. Where there is a need to encapsulate complex data structures, and TLVs cannot be used, the "string" data type MUST be used. This requirement include encapsulation of data structures defined outside of RADIUS, which are opaque to the RADIUS infrastucture. It also includes encapsulation of some data structures which are not opaque to RADIUS, such as the contents of CHAP-Password. DeKok, Alan Standards Track [Page 10] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 There is little reason to define a new RADIUS data type for only one attribute. However, where the complex data type cannot be represented as TLVs, and is expected to be used in many attributes, a new data type SHOULD be defined. These requirements are stronger than [RFC6158], which makes the above encapsulation a "SHOULD". This document defines data types for use in RADIUS, so there is little reason to avoid using them. 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 ifid Number 7 Length Eight octets Format DeKok, Alan Standards Track [Page 11] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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(s). 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.9. ipv6prefix The "ipv6addr" data type encodes an IPv6 prefix, using both a prefix length and an IPv6 address in network byte order. DeKok, Alan Standards Track [Page 12] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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 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. ipv4prefix The "ipv4addr" data type encodes an IPv4 prefix, using both a prefix length and an IPv4 address in network byte order. DeKok, Alan Standards Track [Page 13] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 Name ipv4prefix Number 10 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-Len| Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Reserved This field, which is reserved and MUST be present, is always set to zero. Prefix-Length A 6-bit unsigned integer containing the length of the prefix, in bits. The values MUST be no larger than 32. Prefix The Prefix field is 4 octets in length. Bits outside of the Prefix-Length, must be zero. Unlike the "ipv6prefix" data type, this field is fixed length. If the address is all zeros (i.e. "0.0.0.0", then the Prefix-Length MUST be set to 32. 2.11. 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(s). DeKok, Alan Standards Track [Page 14] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 Name integer64 Number 11 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.12. tlv The "tlv" data type encodes a type-length-value, as defined in [RFC6929] Section 2.3. Name tlv Number 12 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DeKok, Alan Standards Track [Page 15] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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 [RFC6929] 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 [RFC6929]. 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 [RFC6929] Section 2.8. TLVs having TLV-Length of zero (0) MUST NOT be sent; omit the entire TLV instead. TLV-Data 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". DeKok, Alan Standards Track [Page 16] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 2.13. 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 13 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-Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Vendor-Id The 4 octets are the Network Management Private Enterprise Code [PEN] of the Vendor in network byte order. VSA-Data The VSA-Data 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 DeKok, Alan Standards Track [Page 17] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 dependent on the vendor's definition of that attribute. The "vsa" data type MUST be used as contents of the Attr-Data field of the Vendor-Specific attribute. The "vsa" data type MUST NOT appear in the contents of any other data type. 2.14. extended The "extended" data type encodes the "Extended Type" format, as given in [RFC6929] 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 14 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 [RFC6929] Section 10. Unlike the Type field defined in [RFC2865] Section 5, no values are allocated for 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". DeKok, Alan Standards Track [Page 18] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 See [RFC6929] 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.15. long-extended The "long-extended" data type encodes the "Long Extended Type" format, as given in [RFC6929] 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 15 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended-Type |M| Reserved | Ext-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DeKok, Alan Standards Track [Page 19] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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 [RFC6929] 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. 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 DeKok, Alan Standards Track [Page 20] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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. 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. 2.16. evs The "evs" data type encodes an "Extended Vendor-Specific" attribute, 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 an "extended" or a "long-extended" data type. It MUST NOT appear in the contents of any other data type. Name evs Number 16 Length Six or more octets Format 0 1 2 3 DeKok, Alan Standards Track [Page 21] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 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-Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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-Data The EVS-Data 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- Data 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-Data 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. Pending and Future work. The fragmentation draft defines a new bit for the "long-extended" type. This bit could be defined in this document. It may be useful to have sub-second resolution in RADIUS. A "nanosecond" data type may therefore be useful. DeKok, Alan Standards Track [Page 22] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 4. Updated Registries This section defines a new IANA registry for RADIUS data types, and updates the existing RADIUS Attribute Type registry. 4.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. The value field is an artifact of the registry, and has no on-the-wire meaning. Description The name of the data type. The name field is an artifact of the registry, and has no on-the-wire meaning. 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 [RFC6929], TBD 11 tlv [RFC6929], TBD 12 evs [RFC6929], TBD 13 extended [RFC6929], TBD 14 long-extended [RFC6929], TBD DeKok, Alan Standards Track [Page 23] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 4.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 24] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 5. Suggestions for Specifications 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" is then limited only to the definition of new data types, and complex data types. Use of the new extended attributes [RFC6929] 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. That allocation strongly affects the format of the attribute header, making it nearly impossible to create the correct ASCII art prior to final publication. Allocation from the different spaces also changes the value of the Length field, also making it difficult to define it correctly 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 [RFC6929]. Specifications can often leave this as "TBD", and request that IANA fill in the allocated values. Length A description of the length of the attribute. For attributes of variable length, a maximum length SHOULD be given. Data Type One of the named data types from the RADIUS Data Type registry. 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. Where the values are limited to a subset of the possible range, valid range(s) MUST be defined. DeKok, Alan Standards Track [Page 25] INTERNET-DRAFT Data Types in RADIUS 24 June 2014 For attributes of data type "enum", a list of enumerated values and names MUST be given, as with [RFC2865] Section 5.6. 6. Security Considerations This specification is concerned solely with updates to IANA registries. As such, there are no security considerations with the document itself. However, the use of inconsistent names and poorly-defined entities in a protocol is problematic. Inconsistencies in specifications can lead to security and interoperability problems in implementations. Further, having one canonical source for the definition of data types means an implementor has fewer specifications to read. The implementation work is therefore simpler, and is more likely to be correct. The goal of this specification is to reduce ambiguities in the RADIUS protocol, which we believe will lead to more robust and more secure implementations. 7. IANA Considerations IANA is instructed to create one new registry as described above in Section 3.1. 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 3.2. IANA is instructed to require that all allocation requests in the RADIUS Attribute Type Registry contain a "data type" field. That field is required to contain one of the "data type" names contained in the RADIUS Data Type registry. 8. References 8.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 24 June 2014 [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. [RFC6572] Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, June 2012. 8.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. [RFC6929] DeKok, A., and Lior, A., "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 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]