--- 1/draft-ietf-radext-datatypes-01.txt 2015-11-02 11:15:10.996435116 -0800 +++ 2/draft-ietf-radext-datatypes-02.txt 2015-11-02 11:15:11.068436863 -0800 @@ -1,21 +1,21 @@ Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 2865,3162,6158,6572 Category: Standards Track - -4 September 2015 + +2 November 2015 Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) - draft-ietf-radext-datatypes-01.txt + draft-ietf-radext-datatypes-02.txt Abstract RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the 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 @@ -37,87 +37,105 @@ 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 March 4, 2016. + This Internet-Draft will expire on May 2, 2016. Copyright Notice Copyright (c) 2015 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. 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 ............................................ 9 - 2.4. time ................................................ 9 - 2.5. text ................................................ 10 - 2.6. string .............................................. 11 - 2.7. concat .............................................. 12 - 2.8. ifid ................................................ 13 - 2.9. ipv6addr ............................................ 13 - 2.10. ipv6prefix ......................................... 14 - 2.11. ipv4prefix ......................................... 15 - 2.12. integer64 .......................................... 16 - 2.13. tlv ................................................ 17 - 2.14. vsa ................................................ 18 - 2.15. extended ........................................... 20 - 2.16. long-extended ...................................... 21 - 2.17. evs ................................................ 23 -3. Updated Registries ....................................... 24 - 3.1. Create a Data Type Registry ......................... 24 - 3.2. Updates to the Attribute Type Registry .............. 25 -4. Suggestions for Specifications ........................... 30 -5. Security Considerations .................................. 31 -6. IANA Considerations ...................................... 32 -7. References ............................................... 32 - 7.1. Normative References ................................ 32 - 7.2. Informative References .............................. 33 + 1.1. Specification Problems with Data Types .............. 4 + 1.2. Implementation Problems with Data Types ............. 5 + 1.3. No Mandated Changes ................................. 5 + 1.4. Requirements Language ............................... 5 +2. Use of Data Types ........................................ 6 + 2.1. Specification Use of Data Types ..................... 6 + 2.1.1. Field Names for Attribute Values ............... 6 + 2.1.2. Attribute Definitions using Data Types ......... 7 + 2.1.3. Format of Attribute Definitions ................ 7 + 2.1.4. Defining a New Data Type ....................... 8 + 2.2. Implementation Use of Data Types .................... 9 +3. Data Type Definitions .................................... 11 + 3.1. integer ............................................. 12 + 3.2. enum ................................................ 12 + 3.3. ipv4addr ............................................ 13 + 3.4. time ................................................ 13 + 3.5. text ................................................ 14 + 3.6. string .............................................. 15 + 3.7. concat .............................................. 16 + 3.8. ifid ................................................ 17 + 3.9. ipv6addr ............................................ 17 + 3.10. ipv6prefix ......................................... 18 + 3.11. ipv4prefix ......................................... 19 + 3.12. integer64 .......................................... 20 + 3.13. tlv ................................................ 21 + 3.14. vsa ................................................ 23 + 3.15. extended ........................................... 24 + 3.16. long-extended ...................................... 25 + 3.17. evs ................................................ 27 +4. Updated Registries ....................................... 29 + 4.1. Create a Data Type Registry ......................... 29 + 4.2. Updates to the Attribute Type Registry .............. 30 +5. Security Considerations .................................. 35 +6. IANA Considerations ...................................... 35 +7. References ............................................... 36 + 7.1. Normative References ................................ 36 + 7.2. Informative References .............................. 36 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 + definition. Experience has shown that there is a need for well defined data types. + This document defines an IANA registry for data types, and updates + the RADIUS Attribute Type registry to use those newly defined data + types. It recommends how both specifications and implementations + should use the data types. It extends the RADIUS Attribute Type + registry to have a data type for each assigned attribute. + 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 problems. -1.1. Specification use of Data Types +1.1. Specification Problems with Data Types + + When attributes are defined in the specifications, the terms "Value" + and "String" are used to refer to the contents of an attribute. + However, these names are used recursively and inconsistently. We + suggest that defining a field to recursively contain itself is + problematic. 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 @@ -129,182 +147,345 @@ 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 +1.2. Implementation Problems with 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. It is time for RADIUS specifications to follow this practice. +1.3. No Mandated Changes + This document mandates 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. This document suggests that implementations SHOULD use the data types defined here, in preference to any "ad hoc" data types currently in use. This suggestion should have minimal effect on implementations, as most "ad hoc" data types are compatible with the ones defined here. Any difference will typically be limited to the name of the data type. -1.3. Requirements Language +1.4. 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]. -2. Data Type Definitions +2. Use of Data Types + + The Data Types can be used in two places: specifications, and + implementations. This section discusses both uses, and gives + guidance on using the data types. + +2.1. Specification Use of Data Types + + In this section, we give recommendations for how specifications + should be written using data types. We first describe how attribute + field names can be consistently named. We then describe how + attribute definitions should use the data types, and deprecate the + use of "Ascii art" for attribute definitions. We suggest a format + for new attribute definitions. This format includes recommended + fields, and suggestions for how those fields should be described. + + Finally, we make recommendations for how new data types should be + defined. + +2.1.1. Field Names for Attribute Values + + Previous specifications used inconsistent and conflicting names for + the contents of RADIUS attributes. 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 correct this ambiguity by using context-specific names for various + fields of attributes and data types. It then becomes clear that, for + example, that a field called "VSA-Data" must contain different data + than a field called "EVS-Data". Each new name is defined where it is + used. + + We also define 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. + + We consistently use "Attr-Data" to refer to the contents of an + attribute, instead of the more ambiguous name "Value". It is + RECOMMENDED that new specifications follow this practice. + + In this document, we use the term "Value" to refer to the contents of + a data type, where that data type cannot carry other data types. In + other cases, we refer to the contents of a data type with a type- + specific name, in order to distinguish it from data of other types. + For example, the data type "vsa" will contain a data field called + "VSA-Data". + + These terms are used in preference to the term "String", which was + used in multiple incompatible ways. It is RECOMMENDED that future + specifications use type-specific names, and the same naming scheme + for new types. This use will maintain consistent definitions, and + avoid ambiguities. + +2.1.2. Attribute Definitions using Data Types + + New RADIUS specifications MUST define attributes using data types + from the RADIUS Data Type registry. The specification may, of + course, define a new data type and use it in the same document. The + guidelines given in [RFC6929] MUST be followed when defining a new + data type. + + Attributes can usually be completely described via the Attribute Type + code, 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. + + 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. + + It is therefore RECOMMENDED that "ASCII art" diagrams not be used for + new RADIUS attribute specifications. + +2.1.3. Format of Attribute Definitions + + When defining a new attribute, the following fields SHOULD be given: + + 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. Since + the Length may depend on the Type, the definition of Length may + be affected by IANA allocations. + + 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, so long as the Description field is + sufficiently explanatory. + + Where the values are limited to a subset of the possible range, + valid range(s) MUST be defined. + + For attributes of data type "enum", a list of enumerated values + and names MUST be given, as with [RFC2865] Section 5.6. + + Using a consistent format for attribute definitions helps to make the + definitions clearer. + +2.1.4. Defining a New Data Type + + When a specification needs to define a new data type, it should + follow the format used by the definitions in Section 3 of this + document. The text at the start of the data type definition MUST + describe the data type, including the expected use, and why a new + data type is required. That text SHOULD include limits on expected + values, and why those limits exist. The fields "Name", "Value", + "Length", and "Format", MUST be given, along with values. + + The "Name" field SHOULD be a single name, all lower-case. + Contractions such as "ipv4addr" are RECOMMENDED where they add + clarity. + + We note that the use of "Value" in the RADIUS Data Type registry can + be confusing. That name is also used in attribute definitions, but + with a different meaning. We trust that the meaning here is clear + from the context. + + The "Value" field should be given as to be determined or "TBD" in + specifications. That number is assigned by IANA. + + The "Format" field SHOULD be defined with "Ascii art" in order to + have a precise definition. Machine-readable formats are also + RECOMMENDED. + + The definition of a new data type should be done only when absolutely + necessary. We do not expect a need for a large number of new data + types. When defining a new data type, the guideliness of [RFC6929] + with respect to data types MUST be followed. + + It is RECOMMENDED that vendors not define "vendor specific" data + types. As discussed in [RFC6929], those data types are rarely + necessary, and can cause interoperability problems. + + Any new data type MUST have unique name in the RADIUS Data Type + registry. The number of the data type will be assigned by IANA. + +2.2. Implementation Use of Data Types + + Implementations not supporting a particular data type MUST treat + attributes of that data type as being of data type "string", as + defined in Section 2.6. It is RECOMMENDED that such attributes be + treated as "invalid attributes", as defined in [RFC6929] Section 2.8. + + Where the contents of a data type do not match the definition, + implementations MUST treat the the enclosing attribute as being an + "invalid attribute". This requirement includes, but is not limited + to, the following situations: + + * Attributes with values outside of the allowed range(s) for the + data type, e.g. as given in the data types "integer", "ipv4addr", + "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". + + * "text" attributes where the contents do not match the required + format, + + * Attributes where the length is shorter or longer than the allowed + length(s) for the given data type, + + The requirements for "reserved" fields are more difficult to + quantify. Implementations SHOULD be able to receive and process + attributes where "reserved" fields are non-zero. We do not, however, + define any "correct" processing of such attributes. Instead, + specifications which define new meaning for "reserved" fields SHOULD + describe how older implementations process those fields. We expect + that such descriptions are derived from practice. Implementations + MUST set "reserved" fields to zero when creating attributes. + +3. 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. 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 sometimes 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 herein for the data types have no meaning other than to permit them to be tracked by IANA. As RADIUS does not encode information about data types in a packet, the numbers assigned to a data type will never occur in a packet. It is RECOMMENDED that new - implementations use the names defined herein, in order to avoid - confusion. Existing implementations may choose to use the names - defined herein, but that is not required. + implementations use the names defined in this document, in order to + avoid confusion. Existing implementations may choose to use the + names defined here, but that is not required. The encoding of each data type is taken from previous specifications. The fields are transmitted from left to right. 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" + We do not create specific data types for the "tagged" attributes + defines 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. We trust that implementors will be aware that tagged attributes must be treated differently from non-tagged attributes of the same data type. Similarly, we do not create data types for some attributes having complex structure, such as CHAP-Password, ARAP-Features, or Location- Capable. We need to strike a balance between correcting earlier mistakes, and making this document more complex. In some cases, it is better to treat complex attributes as being of type "string", even - though they need to be interpreted by RADIUS implementations. - - Implementations not supporting a particular data type MUST treat - attributes of that data type as being of data type "string", as - defined in Section 2.6. It is RECOMMENDED that such attributes be - treated as "invalid attributes", as defined in [RFC6929] Section 2.8. - - The definitions below 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. - - This document uses slightly different terminology than previous - specifications, in order to be avoid ambiguity. The first 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. In other cases, we refer to the contents of a data type with - a type-specific name, in order to distinguish it from data of other - types. For example, the data type "vsa" will contain a data field - called "VSA-Data". - - These terms are used in preference to the term "String", which was - used in multiple incompatible ways. It is RECOMMENDED that future - specifications use these names, and the same naming scheme for new - types, in order to maintain consistent definitions, and to avoid - ambiguities. + though they need to be interpreted by RADIUS implementations. The + guidelines given in Section 6.3 of [RFC6969] were used to make this + determination. -2.1. integer +3.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. Attributes with Values outside of the allowed ranges SHOULD be treated as "invalid attributes". Name integer - Number + Value 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2.2. enum +3.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. Attributes with Values outside of - the allowed enumerations SHOULD be treated as "invalid attributes". + is used to define enumerated types, such as Service-Type (Section 5.6 + of [RFC 2865]). Specifications MUST define a valid set of enumerated + values, along with a unique name for each value. Attributes with + Values outside of the allowed enumerations SHOULD be treated as + "invalid attributes". Name enum - Number + Value 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -301,67 +482,68 @@ 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 +3.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). Attributes with Values outside of the + define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name ipv4addr - Number + Value 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2.4. time +3.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 2015 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 + Value 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -358,21 +540,21 @@ 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 +3.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 range(s). Attributes with length outside of the allowed values SHOULD be treated as "invalid attributes". Where the text is intended to carry data in a particular format, (e.g. Framed-Route), the format MUST be given. The specification @@ -383,21 +565,21 @@ Note that the "text" data type does not terminate with a NUL octet (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 + Value 5 Length One or more octets. Format 0 @@ -395,26 +577,25 @@ 5 Length One or more octets. Format 0 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+- | Value ... +-+-+-+-+-+-+-+- -2.6. string +3.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). Attributes with length outside of the allowed values SHOULD be treated as "invalid attributes". Note that the "string" data type does not terminate with a NUL octet (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 @@ -430,39 +611,39 @@ 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 are few reasons to avoid using them. Name - string - Number + Value 6 Length One or more octets. Format + 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Octets ... +-+-+-+-+-+-+-+- -2.7. concat +3.7. concat The "concat" data type permits the transport of more than 253 octets of data in a "standard space" [RFC6929] attribute. It is otherwise identical to the "string" data type. If multiple attributes of this data type are contained in a packet, all attributes of the same type code MUST be in order and they MUST be consecutive attributes in the packet. The amount of data transported in a "concat" data type can be no more @@ -475,22 +656,21 @@ The "concat" data type MAY be used for "standard space" attributes. It MUST NOT be used for attributes in the "short extended space" or the "long extended space". It MUST NOT be used in any field or subfields of the following data types: "tlv", "vsa", "extended", "long-extended", or "evs". Name concat - Number - + Value 7 Length One or more octets. Format 0 0 1 2 3 4 5 6 7 @@ -489,67 +669,67 @@ Length One or more octets. Format 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+- | Octets ... - +-+-+-+-+-+-+-+- -2.8. ifid +3.8. ifid The "ifid" data type encodes an Interface-Id as an 8-octet string in network byte order. Name ifid - Number + Value 8 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.9. ipv6addr +3.9. 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). Attributes with Values outside of the + define the valid range(s). Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name ipv6addr - Number + Value 9 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 ... @@ -552,38 +732,37 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -2.10. ipv6prefix +3.10. ipv6prefix The "ipv6prefix" data type encodes an IPv6 prefix, using both a prefix length and an IPv6 address in network byte order. Where the range of prefixes for a particular attribute is limited to a sub-set of possible prefixes, specifications MUST define the valid range(s). - Attributes with Values outside of the allowed range(s) SHOULD be + Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Attributes with a Prefix-Length field having value greater than 128 SHOULD be treated as "invalid attributes". Name ipv6prefix - Number - + Value 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 @@ -607,37 +786,37 @@ 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.11. ipv4prefix +3.11. ipv4prefix The "ipv4prefix" data type encodes an IPv4 prefix, using both a prefix length and an IPv4 address in network byte order. Where the range of prefixes for a particular attribute is limited to a sub-set of possible prefixes, specifications MUST define the valid range(s). - Attributes with Values outside of the allowed range(s) SHOULD be + Attributes with Addresses outside of the allowed range(s) SHOULD be treated as "invalid attributes". Attributes with a Prefix-Length field having value greater than 32 SHOULD be treated as "invalid attributes". Name ipv4prefix - Number + Value 11 Length At least two, and no more than eighteen octets. Format 0 1 2 3 @@ -660,37 +839,38 @@ 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.12. integer64 +3.12. 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). Attributes with Values outside of the allowed range(s) SHOULD be treated as "invalid attributes". Name integer64 - Number + Value 12 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 | @@ -689,30 +869,30 @@ 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.13. tlv +3.13. tlv The "tlv" data type encodes a type-length-value, as defined in [RFC6929] Section 2.3. Name tlv - Number + Value 13 Length Three or more octets Format 0 1 2 3 @@ -720,22 +901,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 - [RFC6929] Section 10. Values 254-255 are "Reserved" for use by - future extensions to RADIUS. The value 26 has no special + [RFC6929] Section 10. Values of 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". @@ -762,36 +943,36 @@ 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: "concat", "vsa", "extended", "long-extended", or "evs". -2.14. vsa +3.14. 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. Where an implementation determines that an attribute of data type "vsa" contains data which does not match the expected format, it SHOULD treat that attribute as being an "invalid attribute". Name vsa - Number + Value 14 Length Five or more octets Format 0 1 2 3 @@ -820,32 +1001,32 @@ outside the scope of this specification. The "vsa" data type SHOULD contain as a sequence of "tlv" data types. The interpretation of the TLV-Type and TLV-Data fields are 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.15. extended +3.15. 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 allocated from the "standard space". It MUST NOT appear in the contents of any other data type. Name extended - Number + Value 15 Length Two or more octets Format 0 1 2 3 @@ -882,37 +1063,36 @@ in the RADIUS Data Type registry. The Ext-Data field MUST NOT contain any of the following data types: "concat", "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.16. long-extended +3.16. 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 + Value 16 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -982,37 +1161,37 @@ 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.17. evs +3.17. 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. Where an implementation determines that an attribute of data type "evs" contains data which does not match the expected format, it SHOULD treat that attribute as being an "invalid attribute". Name evs - Number + Value 17 Length Six or more octets Format 0 1 2 3 @@ -1045,34 +1224,35 @@ 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. Updated Registries +4. Updated Registries This section defines a new IANA registry for RADIUS data types, and updates the existing RADIUS Attribute Type registry. -3.1. Create a Data 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 used only for the registry, and has no on-the-wire meaning. Reference @@ -1092,21 +1272,21 @@ 8 ifid [RFC3162], TBD 9 ipv6addr [RFC3162], TBD 10 ipv6prefix [RFC3162], TBD 11 ipv4prefix [RFC6572], TBD 12 integer64 [RFC6929], TBD 13 tlv [RFC6929], TBD 14 evs [RFC6929], TBD 15 extended [RFC6929], TBD 16 long-extended [RFC6929], TBD -3.2. Updates to the Attribute Type Registry +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. The updated registry follows in CSV format. @@ -1332,74 +1512,20 @@ 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 245.{27-240},Unassigned,, 245.{241-255},Reserved,,[RFC6929] 246,Extended-Attribute-6,long-extended,[RFC6929] 246.{1-25},Unassigned,, 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 246.{27-240},Unassigned,, 246.{241-255},Reserved,,[RFC6929] 247-255,Reserved,,[RFC3575] -4. 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 - - attributes of variable length, a maximum length SHOULD be given. - Since the Length may depend on the Type, the definition of Length - may be affected by IANA allocations. - - 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, so long as the Description field is sufficiently - explanatory. - - Where the values are limited to a subset of the possible range, - valid range(s) MUST be defined. - - For attributes of data type "enum", a list of enumerated values - and names MUST be 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 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 @@ -1418,20 +1544,34 @@ 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. + IANA is instructed to require that updates to the RADIUS Data Type + registry contain the following fields, with the associated + instructions: + + * Value. IANA is instructed to assign the next unused integer in + sequence to new data type definitions. + + * Name. IANA is instructed to require that this name be unique + in the registry. + + * Reference. IANA is instructed to update this field with a + reference + to the document which defines the data type. + 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