idnits 2.17.1 draft-ietf-radext-datatypes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 August 2016) is 2792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7499' is defined on line 1677, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 2865,3162,6158,6572 5 Category: Standards Track 6 7 24 August 2016 9 Data Types in the Remote Authentication 10 Dial-In User Service Protocol (RADIUS) 12 Abstract 14 RADIUS specifications have used data types for two decades without 15 defining them as managed entities. During this time, RADIUS 16 implementations have named the data types, and have used them in 17 attribute definitions. This document updates the specifications to 18 better follow established practice. We do this by naming the data 19 types defined in RFC 6158, which have been used since at least the 20 publication of RFC 2865. We provide an IANA registry for the data 21 types, and update the RADIUS Attribute Type registry to include a 22 "Data Type" field for each attribute. Finally, we recommend that 23 authors of RADIUS specifications use these types in preference to 24 existing practice. This document updates RFC 2865, 3162, 6158, and 25 6572. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 24, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info/) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction ............................................. 4 68 1.1. Specification Problems with Data Types .............. 4 69 1.2. Implementation Problems with Data Types ............. 5 70 1.3. No Mandated Changes ................................. 5 71 1.4. Requirements Language ............................... 5 72 2. Use of Data Types ........................................ 6 73 2.1. Specification Use of Data Types ..................... 6 74 2.1.1. Field Names for Attribute Values ............... 6 75 2.1.2. Attribute Definitions using Data Types ......... 7 76 2.1.3. Format of Attribute Definitions ................ 7 77 2.1.4. Defining a New Data Type ....................... 8 78 2.2. Implementation Use of Data Types .................... 9 79 3. Data Type Definitions .................................... 11 80 3.1. integer ............................................. 12 81 3.2. enum ................................................ 12 82 3.3. time ................................................ 13 83 3.4. text ................................................ 13 84 3.5. string .............................................. 14 85 3.6. concat .............................................. 16 86 3.7. ifid ................................................ 16 87 3.8. ipv4addr ............................................ 17 88 3.9. ipv6addr ............................................ 18 89 3.10. ipv6prefix ......................................... 18 90 3.11. ipv4prefix ......................................... 20 91 3.12. integer64 .......................................... 21 92 3.13. tlv ................................................ 22 93 3.14. vsa ................................................ 23 94 3.15. extended ........................................... 24 95 3.16. long-extended ...................................... 26 96 3.17. evs ................................................ 28 97 4. Updated Registries ....................................... 29 98 4.1. Create a Data Type Registry ......................... 29 99 4.2. Updates to the Attribute Type Registry .............. 30 100 5. Security Considerations .................................. 35 101 6. IANA Considerations ...................................... 36 102 7. References ............................................... 36 103 7.1. Normative References ................................ 36 104 7.2. Informative References .............................. 37 106 1. Introduction 108 RADIUS specifications have historically defined attributes in terms 109 of name, value, and data type. Of these three pieces of information, 110 the name is recorded by IANA in the RADIUS Attribute Type registry, 111 but not otherwise managed or restricted, as discussed in [RFC6929] 112 Section 2.7.1. The value is managed by IANA, and recorded in that 113 registry. The data type is not managed or recorded in the RADIUS 114 Attribute Type registry. Experience has shown that there is a need 115 to create well known data types, and have them managed by IANA. 117 This document defines an IANA RADIUS Data Type registry, and updates 118 the RADIUS Attribute Type registry to use those newly defined data 119 types. It recommends how both specifications and implementations 120 should use the data types. It extends the RADIUS Attribute Type 121 registry to have a data type for each assigned attribute. 123 In this section, we review the use of data types in specifications 124 and implementations. Whe highlight ambiguities and inconsistencies. 125 The rest of this document is devoted to resolving those problems. 127 1.1. Specification Problems with Data Types 129 When attributes are defined in the specifications, the terms "Value" 130 and "String" are used to refer to the contents of an attribute. 131 However, these names are used recursively and inconsistently. We 132 suggest that defining a field to recursively contain itself is 133 problematic. 135 A number of data type names and definitions are given in [RFC2865] 136 Section 5, at the bottom of page 25. These data types are named and 137 clearly defined. However, this practice was not continued in later 138 specifications. 140 Specifically, [RFC2865] defines attributes of data type "address" to 141 carry IPv4 addresses. Despite this definition, [RFC3162] defines 142 attributes of data type "Address" to carry IPv6 addresses. We 143 suggest that the use of the word "address" to refer to disparate data 144 types is problematic. 146 Other failures are that [RFC3162] does not give a data type name and 147 definition for the data types IPv6 address, Interface-Id, or IPv6 148 prefix. [RFC2869] defines Event-Timestamp to carry a time, but does 149 not re-use the "time" data type defined in [RFC2865]. Instead, it 150 just repeats the "time" definition. [RFC6572] defines multiple 151 attributes which carry IPv4 prefixes. However, an "IPv4 prefix" data 152 type is not named, defined as a data type, or called out as an 153 addition to RADIUS. Further, [RFC6572] does not follow the 154 recommendations of [RFC6158], and does not explain why it fails to 155 follow those recommendations. 157 These ambiguities and inconsistencies need to be resolved. 159 1.2. Implementation Problems with Data Types 161 RADIUS implementations often use "dictionaries" to map attribute 162 names to type values, and to define data types for each attribute. 163 The data types in the dictionaries are defined by each 164 implementation, but correspond to the "ad hoc" data types used in the 165 specifications. 167 In effect, implementations have seen the need for well-defined data 168 types, and have created them. It is time for RADIUS specifications 169 to follow this practice. 171 1.3. No Mandated Changes 173 This document mandates no changes to any RADIUS implementation, past, 174 present, or future. It instead documents existing practice, in order 175 to simplify the process of writing RADIUS specifications, to clarify 176 the interpretation of RADIUS standards, and to improve the 177 communication between specification authors and IANA. 179 This document suggests that implementations SHOULD use the data types 180 defined here, in preference to any "ad hoc" data types currently in 181 use. This suggestion should have minimal effect on implementations, 182 as most "ad hoc" data types are compatible with the ones defined 183 here. Any difference will typically be limited to the name of the 184 data type. 186 This document updates [RFC6158] to permit the data types defined in 187 the "Data Type registry" as "basic data types", as per Section 2.1 of 188 that document. The recommendations of [RFC6158] are otherwise 189 unchanged. 191 1.4. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 2. Use of Data Types 199 The Data Types can be used in two places: specifications, and 200 implementations. This section discusses both uses, and gives 201 guidance on using the data types. 203 2.1. Specification Use of Data Types 205 In this section, we give recommendations for how specifications 206 should be written using data types. We first describe how attribute 207 field names can be consistently named. We then describe how 208 attribute definitions should use the data types, and deprecate the 209 use of "ASCII art" for attribute definitions. We suggest a format 210 for new attribute definitions. This format includes recommended 211 fields, and suggestions for how those fields should be described. 213 Finally, we make recommendations for how new data types should be 214 defined. 216 2.1.1. Field Names for Attribute Values 218 Previous specifications used inconsistent and conflicting names for 219 the contents of RADIUS attributes. For example, the term "Value" is 220 used in [RFC2865] Section 5 to define a field which carries the 221 contents of attribute. It is then used in later sections as the sub- 222 field of attribute contents. The result is that the field is defined 223 as recursively containing itself. Similarly, "String" is used both 224 as a data type, and as a sub-field of other data types. 226 We correct this ambiguity by using context-specific names for various 227 fields of attributes and data types. It then becomes clear that, for 228 example, that a field called "VSA-Data" must contain different data 229 than a field called "EVS-Data". Each new name is defined where it is 230 used. 232 We also define the following term: 234 Attr-Data 236 The "Value" field of an Attribute as defined in [RFC2865] 237 Section 5. The contents of this field MUST be of a valid data 238 type as defined in the RADIUS Data Type registry. 240 We consistently use "Attr-Data" to refer to the contents of an 241 attribute, instead of the more ambiguous name "Value". It is 242 RECOMMENDED that new specifications follow this practice. 244 We consistently use "Value" to refer to the contents of a data type, 245 where that data type is simple. For example, an "integer" can have a 246 "Value". In contrast, a Vendor-Specific attribute carries complex 247 information, and thus cannot have a "Value". 249 For data types which carry complex information, we name the fields 250 based on the data type. For example, a Vendor-Specific attribute is 251 defined to carry a "vsa" data type, and the contents of that data 252 type are described herein as "VSA-Data". 254 These terms are used in preference to the term "String", which was 255 previously used in ambiguous ways. It is RECOMMENDED that future 256 specifications use type-specific names, and the same naming scheme 257 for new types. This use will maintain consistent definitions, and 258 help to avoid ambiguities. 260 2.1.2. Attribute Definitions using Data Types 262 New RADIUS specifications MUST define attributes using data types 263 from the RADIUS Data Type registry. The specification may, of 264 course, define a new data type and use it in the same document. The 265 guidelines given in [RFC6929] MUST be followed when defining a new 266 data type. 268 Attributes can usually be completely described via the Attribute Type 269 value, name, and data type. The use of "ASCII art" is then limited 270 only to the definition of new data types, and for complex data types. 272 Use of the new extended attributes [RFC6929] makes ASCII art even 273 more problematic. An attribute can be allocated from any of the 274 extended spaces, with more than one option for attribute header 275 format. This allocation decision is made after the specification has 276 been accepted for publication. As the allocation affects the format 277 of the attribute header, it is essentially impossible to create the 278 correct ASCII art prior to final publication. Allocation from the 279 different spaces also changes the value of the Length field, also 280 making it difficult to define it correctly prior to final publication 281 of the document. 283 It is therefore RECOMMENDED that "ASCII art" diagrams not be used for 284 new RADIUS attribute specifications. 286 2.1.3. Format of Attribute Definitions 288 When defining a new attribute, the following fields SHOULD be given: 290 Description 291 A description of the meaning and interpretation of the 292 attribute. 294 Type 296 The Attribute Type value, given in the "dotted number" notation 297 from [RFC6929]. Specifications can often leave this as "TBD", 298 and request that IANA fill in the allocated values. 300 Length 302 A description of the length of the attribute. For attributes 303 of variable length, a maximum length SHOULD be given. Since 304 the Length may depend on the Type, the definition of Length may 305 be affected by IANA allocations. 307 Data Type 309 One of the named data types from the RADIUS Data Type registry. 311 Value 313 A description of any attribute-specific limitations on the 314 values carried by the specified data type. If there are no 315 attribute-specific limitations, then the description of this 316 field can be omitted, so long as the Description field is 317 sufficiently explanatory. 319 Where the values are limited to a subset of the possible range, 320 valid range(s) MUST be defined. 322 For attributes of data type "enum", a list of enumerated values 323 and names MUST be given, as with [RFC2865] Section 5.6. 325 Using a consistent format for attribute definitions helps to make the 326 definitions clearer. 328 2.1.4. Defining a New Data Type 330 When a specification needs to define a new data type, it SHOULD 331 follow the format used by the definitions in Section 3 of this 332 document. The text at the start of the data type definition MUST 333 describe the data type, including the expected use, and why a new 334 data type is required. That text SHOULD include limits on expected 335 values, and why those limits exist. The field's "Name", "Value", 336 "Length", and "Format", MUST be given, along with values. 338 The "Name" field SHOULD be a single name, all lower-case. 340 Contractions such as "ipv4addr" are RECOMMENDED where they add 341 clarity. 343 We note that the use of "Value" in the RADIUS Data Type registry can 344 be confusing. That name is also used in attribute definitions, but 345 with a different meaning. We trust that the meaning here is clear 346 from the context. 348 The "Value" field SHOULD be given as to be determined or "TBD" in 349 specifications. That number is assigned by IANA. 351 The "Format" field SHOULD be defined with "ASCII art" in order to 352 have a precise definition. Machine-readable formats are also 353 RECOMMENDED. 355 The definition of a new data type should be done only when absolutely 356 necessary. We do not expect a need for a large number of new data 357 types. When defining a new data type, the guideliness of [RFC6929] 358 with respect to data types MUST be followed. 360 It is RECOMMENDED that vendors not define "vendor specific" data 361 types. As discussed in [RFC6929], those data types are rarely 362 necessary, and can cause interoperability problems. 364 Any new data type MUST have unique name in the RADIUS Data Type 365 registry. The number of the data type will be assigned by IANA. 367 2.2. Implementation Use of Data Types 369 Implementations not supporting a particular data type MUST treat 370 attributes of that data type as being of data type "string", as 371 defined in Section 3.6. It is RECOMMENDED that such attributes be 372 treated as "invalid attributes", as defined in [RFC6929] Section 2.8. 374 Where the contents of a data type do not match the definition, 375 implementations MUST treat the the enclosing attribute as being an 376 "invalid attribute". This requirement includes, but is not limited 377 to, the following situations: 379 * Attributes with values outside of the allowed range(s) for the 380 data type, e.g. as given in the data types "integer", "ipv4addr", 381 "ipv6addr", "ipv4prefix", "ipv6prefix", or "enum". 383 * "text" attributes where the contents do not match the required 384 format, 386 * Attributes where the length is shorter or longer than the allowed 387 length(s) for the given data type, 389 The requirements for "reserved" fields are more difficult to 390 quantify. Implementations SHOULD be able to receive and process 391 attributes where "reserved" fields are non-zero. We do not, however, 392 define any "correct" processing of such attributes. Instead, 393 specifications which define new meaning for "reserved" fields SHOULD 394 describe how the new meaning is compatible with older 395 implementations. We expect that such descriptions are derived from 396 practice. Implementations MUST set "reserved" fields to zero when 397 creating attributes. 399 3. Data Type Definitions 401 This section defines the new data types. For each data type, it 402 gives a definition, a name, a number, a length, and an encoding 403 format. Where relevant, it describes subfields contained within the 404 data type. These definitions have no impact on existing RADIUS 405 implementations. There is no requirement that implementations use 406 these names. 408 Where possible, the name of each data type has been taken from 409 previous specifications. In some cases, a different name has been 410 chosen. The change of name is sometimes required to avoid ambiguity 411 (i.e. "address" versus "Address"). Otherwise, the new name has been 412 chosen to be compatible with [RFC2865], or with use in common 413 implementations. In some cases, new names are chosen to clarify the 414 interpretation of the data type. 416 The numbers assigned herein for the data types have no meaning other 417 than to permit them to be tracked by IANA. As RADIUS does not encode 418 information about data types in a packet, the numbers assigned to a 419 data type will never occur in a packet. It is RECOMMENDED that new 420 implementations use the names defined in this document, in order to 421 avoid confusion. Existing implementations may choose to use the 422 names defined here, but that is not required. 424 The encoding of each data type is taken from previous specifications. 425 The fields are transmitted from left to right. 427 Where the data types have inter-dependencies, the simplest data type 428 is given first, and dependent ones are given later. 430 We do not create specific data types for the "tagged" attributes 431 defined in [RFC2868]. That specification defines the "tagged" 432 attributes as being backwards compatible with pre-existing data 433 types. In addition, [RFC6158] Section 2.1 says that "tagged" 434 attributes should not be used. There is therefore no benefit to 435 defining additional data types for these attributes. We trust that 436 implementors will be aware that tagged attributes must be treated 437 differently from non-tagged attributes of the same data type. 439 Similarly, we do not create data types for some attributes having 440 complex structure, such as CHAP-Password, ARAP-Features, or Location- 441 Information. We need to strike a balance between correcting earlier 442 mistakes, and making this document more complex. In some cases, it 443 is better to treat complex attributes as being of type "string", even 444 though they need to be interpreted by RADIUS implementations. The 445 guidelines given in Section 6.3 of [RFC6929] were used to make this 446 determination. 448 3.1. integer 450 The "integer" data type encodes a 32-bit unsigned integer in network 451 byte order. Where the range of values for a particular attribute is 452 limited to a sub-set of the values, specifications MUST define the 453 valid range. Attributes with Values outside of the allowed ranges 454 SHOULD be treated as "invalid attributes". 456 Name 458 integer 460 Value 462 1 464 Length 466 Four octets 468 Format 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Value | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 3.2. enum 478 The "enum" data type encodes a 32-bit unsigned integer in network 479 byte order. It differs from the "integer" data type only in that it 480 is used to define enumerated types, such as Service-Type (Section 5.6 481 of [RFC2865]). Specifications MUST define a valid set of enumerated 482 values, along with a unique name for each value. Attributes with 483 Values outside of the allowed enumerations SHOULD be treated as 484 "invalid attributes". 486 Name 488 enum 490 Value 492 2 494 Length 495 Four octets 497 Format 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Value | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 3.3. time 507 The "time" data type encodes time as a 32-bit unsigned value in 508 network byte order and in seconds since 00:00:00 UTC, January 1, 509 1970. We note that dates before the year 2016 are likely to indicate 510 configuration errors, or lack of access to the correct time. 512 Note that the "time" attribute is defined to be unsigned, which means 513 it is not subject to a signed integer overflow in the year 2038. 515 Name 517 time 519 Value 521 3 523 Length 525 Four octets 527 Format 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Time | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 3.4. text 537 The "text" data type encodes UTF-8 text [RFC3629]. The maximum 538 length of the text is given by the encapsulating attribute. Where 539 the range of lengths for a particular attribute is limited to a sub- 540 set of possible lengths, specifications MUST define the valid 541 range(s). Attributes with length outside of the allowed values 542 SHOULD be treated as "invalid attributes". 544 Attributes of type "text" which are allocated in the standard space 545 (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of 546 data. Attributes of type "text" which are allocated in the extended 547 space can be longer. In both cases, these limits are reduced when 548 the data is encapsulated inside of an another attribute. 550 Where the text is intended to carry data in a particular format, 551 (e.g. Framed-Route), the format MUST be given. The specification 552 SHOULD describe the format in a machine-readable way, such as via 553 Augmented Backus-Naur Form (ABNF) [RFC5234]. Attributes with values 554 not matching the defined format SHOULD be treated as "invalid 555 attributes". 557 Note that the "text" data type does not terminate with a NUL octet 558 (hex 00). The Attribute has a Length field and does not use a 559 terminator. Texts of length zero (0) MUST NOT be sent; omit the 560 entire attribute instead. 562 Name 564 text 566 Value 568 4 570 Length 572 One or more octets. 574 Format 576 0 577 0 1 2 3 4 5 6 7 578 +-+-+-+-+-+-+-+- 579 | Value ... 580 +-+-+-+-+-+-+-+- 582 3.5. string 584 The "string" data type encodes binary data, as a sequence of 585 undistinguished octets. Where the range of lengths for a particular 586 attribute is limited to a sub-set of possible lengths, specifications 587 MUST define the valid range(s). Attributes with length outside of 588 the allowed values SHOULD be treated as "invalid attributes". 590 Attributes of type "string" which are allocated in the standard space 591 (Section 1.2 of [RFC6929]) are limited to no more than 253 octets of 592 data. Attributes of type "string" which are allocated in the 593 extended space can be longer. In both cases, these limits are 594 reduced when the data is encapsulated inside of an another attribute. 596 Note that the "string" data type does not terminate with a NUL octet 597 (hex 00). The Attribute has a Length field and does not use a 598 terminator. Strings of length zero (0) MUST NOT be sent; omit the 599 entire attribute instead. a Where there is a need to encapsulate 600 complex data structures, and TLVs cannot be used, the "string" data 601 type MUST be used. This requirement includes encapsulation of data 602 structures defined outside of RADIUS, which are opaque to the RADIUS 603 infrastucture. It also includes encapsulation of some data 604 structures which are not opaque to RADIUS, such as the contents of 605 CHAP-Password. 607 There is little reason to define a new RADIUS data type for only one 608 attribute. However, where the complex data type cannot be 609 represented as TLVs, and is expected to be used in many attributes, a 610 new data type SHOULD be defined. 612 These requirements are stronger than [RFC6158], which makes the above 613 encapsulation a "SHOULD". This document defines data types for use 614 in RADIUS, so there are few reasons to avoid using them. 616 Name 618 string 620 Value 622 5 624 Length 626 One or more octets. 628 Format 630 0 631 0 1 2 3 4 5 6 7 632 +-+-+-+-+-+-+-+- 633 | Octets ... 634 +-+-+-+-+-+-+-+- 636 3.6. concat 638 The "concat" data type permits the transport of more than 253 octets 639 of data in a "standard space" [RFC6929] attribute. It is otherwise 640 identical to the "string" data type. 642 If multiple attributes of this data type are contained in a packet, 643 all attributes of the same type code MUST be in order and they MUST 644 be consecutive attributes in the packet. 646 The amount of data transported in a "concat" data type can be no more 647 than the RADIUS packet size. In practice, the requirement to 648 transport multiple attributes means that the limit may be 649 substantially smaller than one RADIUS packet. As a rough guide, is 650 RECOMMENDED that this data type transport no more than 2048 octets of 651 data. 653 The "concat" data type MAY be used for "standard space" attributes. 654 It MUST NOT be used for attributes in the "short extended space" or 655 the "long extended space". It MUST NOT be used in any field or 656 subfields of the following data types: "tlv", "vsa", "extended", 657 "long-extended", or "evs". 659 Name 661 concat 663 Value 665 6 667 Length 669 One or more octets. 671 Format 673 0 674 0 1 2 3 4 5 6 7 675 +-+-+-+-+-+-+-+- 676 | Octets ... 677 +-+-+-+-+-+-+-+- 679 3.7. ifid 681 The "ifid" data type encodes an Interface-Id as an 8 octet IPv6 682 Interface Identifier network byte order. 684 Name 686 ifid 688 Value 690 7 692 Length 694 Eight octets 696 Format 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Interface-ID ... 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 ... Interface-ID | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 3.8. ipv4addr 708 The "ipv4addr" data type encodes an IPv4 address in network byte 709 order. Where the range of address for a particular attribute is 710 limited to a sub-set of possible addresses, specifications MUST 711 define the valid range(s). Attributes with Addresses outside of the 712 allowed range(s) SHOULD be treated as "invalid attributes". 714 Name 716 ipv4addr 718 Value 720 8 722 Length 724 Four octets 726 Format 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Address | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 3.9. ipv6addr 736 The "ipv6addr" data type encodes an IPv6 address in network byte 737 order. Where the range of address for a particular attribute is 738 limited to a sub-set of possible addresses, specifications MUST 739 define the valid range(s). Attributes with Addresses outside of the 740 allowed range(s) SHOULD be treated as "invalid attributes". 742 Name 744 ipv6addr 746 Value 748 9 750 Length 752 Sixteen octets 754 Format 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Address ... 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 ... Address ... 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 ... Address ... 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 ... Address | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 3.10. ipv6prefix 770 The "ipv6prefix" data type encodes an IPv6 prefix, using both a 771 prefix length and an IPv6 address in network byte order. Where the 772 range of prefixes for a particular attribute is limited to a sub-set 773 of possible prefixes, specifications MUST define the valid range(s). 774 Attributes with Addresses outside of the allowed range(s) SHOULD be 775 treated as "invalid attributes". 777 Attributes with a Prefix-Length field having value greater than 128 778 MUST be treated as "invalid attributes". 780 Name 782 ipv6prefix 784 Value 786 10 788 Length 790 At least two, and no more than eighteen octets. 792 Format 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Reserved | Prefix-Length | Prefix ... 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 ... Prefix ... 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 ... Prefix ... 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 ... Prefix | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Subfields 808 Reserved 810 This field, which is reserved and MUST be present, is always 811 set to zero. 813 Prefix-Length 815 The length of the prefix, in bits. At least 0 and no larger 816 than 128. 818 Prefix 820 The Prefix field is up to 16 octets in length. Bits outside of 821 the Prefix-Length, if included, MUST be zero. 823 The Prefix field SHOULD NOT contain more octets than necessary 824 to encode the Prefix. 826 3.11. ipv4prefix 828 The "ipv4prefix" data type encodes an IPv4 prefix, using both a 829 prefix length and an IPv4 address in network byte order. Where the 830 range of prefixes for a particular attribute is limited to a sub-set 831 of possible prefixes, specifications MUST define the valid range(s). 832 Attributes with Addresses outside of the allowed range(s) SHOULD be 833 treated as "invalid attributes". 835 Attributes with a Prefix-Length field having value greater than 32 836 MUST be treated as "invalid attributes". 838 Name 840 ipv4prefix 842 Value 844 11 846 Length 848 six octets 850 Format 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Reserved | Prefix-Length | Prefix ... 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 ... Prefix | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Subfields 862 Reserved 864 This field, which is reserved and MUST be present, is always 865 set to zero. This field is one octet in length. 867 Note that this definition differs from that given in [RFC6572]. 868 See Prefix-Length, below, for an explanation. 870 Prefix-Length 872 The length of the prefix, in bits. The values MUST be no 873 larger than 32. This field is one octet in length. 875 Note that this definition differs from that given in [RFC6572]. 877 As compared to [RFC6572], the Prefix-Length field has increased 878 in size by two bits, both of which must be zero. The Reserved 879 field has decreased in size by two bits. The result is that 880 both fields are aligned on octet boundaries, which removes the 881 need for bit masking of the fields. 883 Since [RFC6572] required the Reserved field to be zero, the 884 definition here is compatible with the definition in the 885 original specification. 887 Prefix 889 The Prefix field is 4 octets in length. Bits outside of the 890 Prefix-Length MUST be zero. Unlike the "ipv6prefix" data type, 891 this field is fixed length. If the address is all zeros (i.e. 892 "0.0.0.0", then the Prefix-Length MUST be set to 32. 894 3.12. integer64 896 The "integer64" data type encodes a 64-bit unsigned integer in 897 network byte order. Where the range of values for a particular 898 attribute is limited to a sub-set of the values, specifications MUST 899 define the valid range(s). Attributes with Values outside of the 900 allowed range(s) SHOULD be treated as "invalid attributes". 902 Name 904 integer64 906 Value 908 12 910 Length 912 Eight octets 914 Format 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Value ... 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 ... Value | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 3.13. tlv 927 The "tlv" data type encodes a type-length-value, as defined in 928 [RFC6929] Section 2.3. 930 Name 932 tlv 934 Value 936 13 938 Length 940 Three or more octets 942 Format 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | TLV-Type | TLV-Length | TLV-Data ... 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Subfields 952 TLV-Type 954 This field is one octet. Up-to-date values of this field are 955 specified according to the policies and rules described in 956 [RFC6929] Section 10. Values of 254-255 are "Reserved" for use 957 by future extensions to RADIUS. The value 26 has no special 958 meaning, and MUST NOT be treated as a Vendor Specific 959 attribute. 961 The TLV-Type is meaningful only within the context defined by 962 "Type" fields of the encapsulating Attributes, using the 963 dotted-number notation introduced in [RFC6929]. 965 A RADIUS server MAY ignore Attributes with an unknown "TLV- 966 Type". 968 A RADIUS client MAY ignore Attributes with an unknown "TLV- 969 Type". 971 A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- 972 Type" verbatim. 974 TLV-Length 976 The TLV-Length field is one octet, and indicates the length of 977 this TLV including the TLV-Type, TLV-Length and TLV-Value 978 fields. It MUST have a value between 3 and 255. If a client 979 or server receives a TLV with an invalid TLV-Length, then the 980 attribute which encapsulates that TLV MUST be considered to be 981 an "invalid attribute", and handled as per [RFC6929] Section 982 2.8. 984 TLVs having TLV-Length of two (2) MUST NOT be sent; omit the 985 entire TLV instead. 987 TLV-Data 989 The TLV-Data field is one or more octets and contains 990 information specific to the Attribute. The format and length 991 of the TLV-Data field is determined by the TLV-Type and TLV- 992 Length fields. 994 The TLV-Data field MUST contain only known RADIUS data types. 995 The TLV-Data field MUST NOT contain any of the following data 996 types: "concat", "vsa", "extended", "long-extended", or "evs". 998 3.14. vsa 1000 The "vsa" data type encodes Vendor-Specific data, as given in 1001 [RFC2865] Section 5.26. It is used only in the Attr-Data field of a 1002 Vendor-Specific Attribute. It MUST NOT appear in the contents of any 1003 other data type. 1005 Where an implementation determines that an attribute of data type 1006 "vsa" contains data which does not match the expected format, it 1007 SHOULD treat that attribute as being an "invalid attribute". 1009 Name 1011 vsa 1013 Value 1015 14 1017 Length 1018 Five or more octets 1020 Format 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Vendor-Id | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | VSA-Data .... 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Subfields 1032 Vendor-Id 1034 The 4 octets are the Network Management Private Enterprise Code 1035 [PEN] of the Vendor in network byte order. 1037 VSA-Data 1039 The VSA-Data field is one or more octets. The actual format of 1040 the information is site or application specific, and a robust 1041 implementation SHOULD support the field as undistinguished 1042 octets. 1044 The codification of the range of allowed usage of this field is 1045 outside the scope of this specification. 1047 The "vsa" data type SHOULD contain as a sequence of "tlv" data 1048 types. The interpretation of the TLV-Type and TLV-Data fields 1049 are dependent on the vendor's definition of that attribute. 1051 The "vsa" data type MUST be used as contents of the Attr-Data 1052 field of the Vendor-Specific attribute. The "vsa" data type 1053 MUST NOT appear in the contents of any other data type. 1055 3.15. extended 1057 The "extended" data type encodes the "Extended Type" format, as given 1058 in [RFC6929] Section 2.1. It is used only in the Attr-Data field of 1059 an Attribute allocated from the "standard space". It MUST NOT appear 1060 in the contents of any other data type. 1062 Name 1064 extended 1066 Value 1068 15 1070 Length 1072 Two or more octets 1074 Format 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Extended-Type | Ext-Data ... 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 Subfields 1084 Extended-Type 1086 The Extended-Type field is one octet. Up-to-date values of 1087 this field are specified according to the policies and rules 1088 described in [RFC6929] Section 10. Unlike the Type field 1089 defined in [RFC2865] Section 5, no values are allocated for 1090 experimental or implementation-specific use. Values 241-255 1091 are reserved and MUST NOT be used. 1093 The Extended-Type is meaningful only within a context defined 1094 by the Type field. That is, this field may be thought of as 1095 defining a new type space of the form "Type.Extended-Type". 1096 See [RFC6929] Section 2.5 for additional discussion. 1098 A RADIUS server MAY ignore Attributes with an unknown 1099 "Type.Extended-Type". 1101 A RADIUS client MAY ignore Attributes with an unknown 1102 "Type.Extended-Type". 1104 Ext-Data 1106 The contents of this field MUST be a valid data type as defined 1107 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1108 contain any of the following data types: "concat", "vsa", 1109 "extended", "long-extended", or "evs". 1111 The Ext-Data field is one or more octets. 1113 Implementations supporting this specification MUST use the 1114 Identifier of "Type.Extended-Type" to determine the 1115 interpretation of the Ext-Data field. 1117 3.16. long-extended 1119 The "long-extended" data type encodes the "Long Extended Type" 1120 format, as given in [RFC6929] Section 2.2. It is used only in the 1121 Attr-Data field of an Attribute. It MUST NOT appear in the contents 1122 of any other data type. 1124 Name 1126 long-extended 1128 Value 1130 16 1132 Length 1134 Three or more octets 1136 Format 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Extended-Type |M| Reserved | Ext-Data ... 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Subfields 1146 Extended-Type 1148 This field is identical to the Extended-Type field defined 1149 above in Section 3.15. 1151 M (More) 1153 The More field is one (1) bit in length, and indicates whether 1154 or not the current attribute contains "more" than 251 octets of 1155 data. The More field MUST be clear (0) if the Length field has 1156 value less than 255. The More field MAY be set (1) if the 1157 Length field has value of 255. 1159 If the More field is set (1), it indicates that the Ext-Data 1160 field has been fragmented across multiple RADIUS attributes. 1162 When the More field is set (1), the attribute MUST have a 1163 Length field of value 255; there MUST be an attribute following 1164 this one; and the next attribute MUST have both the same Type 1165 and Extended Type. That is, multiple fragments of the same 1166 value MUST be in order and MUST be consecutive attributes in 1167 the packet, and the last attribute in a packet MUST NOT have 1168 the More field set (1). 1170 That is, a packet containing a fragmented attribute needs to 1171 contain all fragments of the attribute, and those fragments 1172 need to be contiguous in the packet. RADIUS does not support 1173 inter-packet fragmentation, which means that fragmenting an 1174 attribute across multiple packets is impossible. 1176 If a client or server receives an attribute fragment with the 1177 "More" field set (1), but for which no subsequent fragment can 1178 be found, then the fragmented attribute is considered to be an 1179 "invalid attribute", and handled as per [RFC6929] Section 2.8. 1181 Reserved 1183 This field is 7 bits long, and is reserved for future use. 1184 Implementations MUST set it to zero (0) when encoding an 1185 attribute for sending in a packet. The contents SHOULD be 1186 ignored on reception. 1188 Future specifications may define additional meaning for this 1189 field. Implementations therefore MUST NOT treat this field as 1190 invalid if it is non-zero. 1192 Ext-Data 1194 The contents of this field MUST be a valid data type as defined 1195 in the RADIUS Data Type registry. The Ext-Data field MUST NOT 1196 contain any of the following data types: "concat", "vsa", 1197 "extended", "long-extended", or "evs". 1199 The Ext-Data field is one or more octets. 1201 Implementations supporting this specification MUST use the 1202 Identifier of "Type.Extended-Type" to determine the 1203 interpretation of the Ext-Data field. 1205 The length of the data MUST be taken as the sum of the lengths 1206 of the fragments (i.e. Ext-Data fields) from which it is 1207 constructed. Any interpretation of the resulting data MUST 1208 occur after the fragments have been reassembled. If the 1209 reassembled data does not match the expected format, each 1210 fragment MUST be treated as an "invalid attribute", and the 1211 reassembled data MUST be discarded. 1213 We note that the maximum size of a fragmented attribute is 1214 limited only by the RADIUS packet length limitation. 1215 Implementations MUST be able to handle the case where one 1216 fragmented attribute completely fills the packet. 1218 3.17. evs 1220 The "evs" data type encodes an "Extended Vendor-Specific" attribute, 1221 as given in [RFC6929] Section 2.4. The "evs" data type is used 1222 solely to extend the Vendor Specific space. It MAY appear inside of 1223 an "extended" or a "long-extended" data type. It MUST NOT appear in 1224 the contents of any other data type. 1226 Where an implementation determines that an attribute of data type 1227 "evs" contains data which does not match the expected format, it 1228 SHOULD treat that attribute as being an "invalid attribute". 1230 Name 1232 evs 1234 Value 1236 17 1238 Length 1240 Six or more octets 1242 Format 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Vendor-Id | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Vendor-Type | EVS-Data .... 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 Subfields 1254 Vendor-Id 1256 The 4 octets are the Network Management Private Enterprise Code 1258 [PEN] of the Vendor in network byte order. 1260 Vendor-Type 1262 The Vendor-Type field is one octet. Values are assigned at the 1263 sole discretion of the Vendor. 1265 EVS-Data 1267 The EVS-Data field is one or more octets. It SHOULD 1268 encapsulate a previously defined RADIUS data type. Non- 1269 standard data types SHOULD NOT be used. We note that the EVS- 1270 Data field may be of data type "tlv". 1272 The actual format of the information is site or application 1273 specific, and a robust implementation SHOULD support the field 1274 as undistinguished octets. We recognise that Vendors have 1275 complete control over the contents and format of the Ext-Data 1276 field, while at the same time recommending that good practices 1277 be followed. 1279 Further codification of the range of allowed usage of this 1280 field is outside the scope of this specification. 1282 4. Updated Registries 1284 This section defines a new IANA registry for RADIUS data types, and 1285 then updates the existing RADIUS Attribute Type registry to use the 1286 data types from the new registry. 1288 4.1. Create a Data Type Registry 1290 This section defines a new registry located under "RADIUS Types", 1291 called "Data Type". Allocation in this registry requires IETF 1292 Review. The "Registration Procedures" for the Data Type registry are 1293 "Standards Action". 1295 The Data Type registry contains three columns of data, as follows. 1297 Value 1299 The number of the data type. The value field is an artifact of 1300 the registry, and has no on-the-wire meaning. 1302 Description 1304 The name of the data type. The name field is used only for the 1305 registry, and has no on-the-wire meaning. 1307 Reference 1309 The specification where the data type was defined. 1311 The initial contents of the registry are as follows. 1313 Value Description Reference 1314 ----- ----------- ---------------- 1315 1 integer [RFC2865], TBD 1316 2 enum [RFC2865], TBD 1317 3 time [RFC2865], TBD 1318 4 text [RFC2865], TBD 1319 5 string [RFC2865], TBD 1320 6 concat TBD 1321 7 ifid [RFC3162], TBD 1322 8 ipv4addr [RFC2865], TBD 1323 9 ipv6addr [RFC3162], TBD 1324 10 ipv6prefix [RFC3162], TBD 1325 11 ipv4prefix [RFC6572], TBD 1326 12 integer64 [RFC6929], TBD 1327 13 tlv [RFC6929], TBD 1328 14 evs [RFC6929], TBD 1329 15 extended [RFC6929], TBD 1330 16 long-extended [RFC6929], TBD 1332 4.2. Updates to the Attribute Type Registry 1334 This section updates the RADIUS Attribute Type registry to have a new 1335 column, which is inserted in between the existing "Description" and 1336 "Reference" columns. The new column is named "Data Type". The 1337 contents of that column are the name of a data type, corresponding to 1338 the attribute in that row, or blank if the attribute type is 1339 unassigned. The name of the data type is taken from the RADIUS Data 1340 Type registry, as defined above. 1342 The existing registration requirements for the RADIUS Attribute Type 1343 registry are otherwise unchanged. 1345 NOTE TO RFC EDITOR: Before the document is published, please remove this 1346 note, and the following text in this section. 1348 The updated registry follows in CSV format. 1350 Value,Description,Data Type,Reference 1351 1,User-Name,text,[RFC2865] 1352 2,User-Password,string,[RFC2865] 1353 3,CHAP-Password,string,[RFC2865] 1354 4,NAS-IP-Address,ipv4addr,[RFC2865] 1355 5,NAS-Port,integer,[RFC2865] 1356 6,Service-Type,enum,[RFC2865] 1357 7,Framed-Protocol,enum,[RFC2865] 1358 8,Framed-IP-Address,ipv4addr,[RFC2865] 1359 9,Framed-IP-Netmask,ipv4addr,[RFC2865] 1360 10,Framed-Routing,enum,[RFC2865] 1361 11,Filter-Id,text,[RFC2865] 1362 12,Framed-MTU,integer,[RFC2865] 1363 13,Framed-Compression,enum,[RFC2865] 1364 14,Login-IP-Host,ipv4addr,[RFC2865] 1365 15,Login-Service,enum,[RFC2865] 1366 16,Login-TCP-Port,integer,[RFC2865] 1367 17,Unassigned,, 1368 18,Reply-Message,text,[RFC2865] 1369 19,Callback-Number,text,[RFC2865] 1370 20,Callback-Id,text,[RFC2865] 1371 21,Unassigned,, 1372 22,Framed-Route,text,[RFC2865] 1373 23,Framed-IPX-Network,ipv4addr,[RFC2865] 1374 24,State,string,[RFC2865] 1375 25,Class,string,[RFC2865] 1376 26,Vendor-Specific,vsa,[RFC2865] 1377 27,Session-Timeout,integer,[RFC2865] 1378 28,Idle-Timeout,integer,[RFC2865] 1379 29,Termination-Action,enum,[RFC2865] 1380 30,Called-Station-Id,text,[RFC2865] 1381 31,Calling-Station-Id,text,[RFC2865] 1382 32,NAS-Identifier,text,[RFC2865] 1383 33,Proxy-State,string,[RFC2865] 1384 34,Login-LAT-Service,text,[RFC2865] 1385 35,Login-LAT-Node,text,[RFC2865] 1386 36,Login-LAT-Group,string,[RFC2865] 1387 37,Framed-AppleTalk-Link,integer,[RFC2865] 1388 38,Framed-AppleTalk-Network,integer,[RFC2865] 1389 39,Framed-AppleTalk-Zone,text,[RFC2865] 1390 40,Acct-Status-Type,enum,[RFC2866] 1391 41,Acct-Delay-Time,integer,[RFC2866] 1392 42,Acct-Input-Octets,integer,[RFC2866] 1393 43,Acct-Output-Octets,integer,[RFC2866] 1394 44,Acct-Session-Id,text,[RFC2866] 1395 45,Acct-Authentic,enum,[RFC2866] 1396 46,Acct-Session-Time,integer,[RFC2866] 1397 47,Acct-Input-Packets,integer,[RFC2866] 1398 48,Acct-Output-Packets,integer,[RFC2866] 1399 49,Acct-Terminate-Cause,enum,[RFC2866] 1400 50,Acct-Multi-Session-Id,text,[RFC2866] 1401 51,Acct-Link-Count,integer,[RFC2866] 1402 52,Acct-Input-Gigawords,integer,[RFC2869] 1403 53,Acct-Output-Gigawords,integer,[RFC2869] 1404 54,Unassigned,, 1405 55,Event-Timestamp,time,[RFC2869] 1406 56,Egress-VLANID,integer,[RFC4675] 1407 57,Ingress-Filters,enum,[RFC4675] 1408 58,Egress-VLAN-Name,text,[RFC4675] 1409 59,User-Priority-Table,string,[RFC4675] 1410 60,CHAP-Challenge,string,[RFC2865] 1411 61,NAS-Port-Type,enum,[RFC2865] 1412 62,Port-Limit,integer,[RFC2865] 1413 63,Login-LAT-Port,text,[RFC2865] 1414 64,Tunnel-Type,enum,[RFC2868] 1415 65,Tunnel-Medium-Type,enum,[RFC2868] 1416 66,Tunnel-Client-Endpoint,text,[RFC2868] 1417 67,Tunnel-Server-Endpoint,text,[RFC2868] 1418 68,Acct-Tunnel-Connection,text,[RFC2867] 1419 69,Tunnel-Password,string,[RFC2868] 1420 70,ARAP-Password,string,[RFC2869] 1421 71,ARAP-Features,string,[RFC2869] 1422 72,ARAP-Zone-Access,enum,[RFC2869] 1423 73,ARAP-Security,integer,[RFC2869] 1424 74,ARAP-Security-Data,text,[RFC2869] 1425 75,Password-Retry,integer,[RFC2869] 1426 76,Prompt,enum,[RFC2869] 1427 77,Connect-Info,text,[RFC2869] 1428 78,Configuration-Token,text,[RFC2869] 1429 79,EAP-Message,concat,[RFC2869] 1430 80,Message-Authenticator,string,[RFC2869] 1431 81,Tunnel-Private-Group-ID,text,[RFC2868] 1432 82,Tunnel-Assignment-ID,text,[RFC2868] 1433 83,Tunnel-Preference,integer,[RFC2868] 1434 84,ARAP-Challenge-Response,string,[RFC2869] 1435 85,Acct-Interim-Interval,integer,[RFC2869] 1436 86,Acct-Tunnel-Packets-Lost,integer,[RFC2867] 1437 87,NAS-Port-Id,text,[RFC2869] 1438 88,Framed-Pool,text,[RFC2869] 1439 89,CUI,string,[RFC4372] 1440 90,Tunnel-Client-Auth-ID,text,[RFC2868] 1441 91,Tunnel-Server-Auth-ID,text,[RFC2868] 1442 92,NAS-Filter-Rule,text,[RFC4849] 1443 93,Unassigned,, 1444 94,Originating-Line-Info,string,[RFC7155] 1445 95,NAS-IPv6-Address,ipv6addr,[RFC3162] 1446 96,Framed-Interface-Id,ifid,[RFC3162] 1447 97,Framed-IPv6-Prefix,ipv6prefix,[RFC3162] 1448 98,Login-IPv6-Host,ipv6addr,[RFC3162] 1449 99,Framed-IPv6-Route,text,[RFC3162] 1450 100,Framed-IPv6-Pool,text,[RFC3162] 1451 101,Error-Cause Attribute,enum,[RFC3576] 1452 102,EAP-Key-Name,string,[RFC4072][RFC7268] 1453 103,Digest-Response,text,[RFC5090] 1454 104,Digest-Realm,text,[RFC5090] 1455 105,Digest-Nonce,text,[RFC5090] 1456 106,Digest-Response-Auth,text,[RFC5090] 1457 107,Digest-Nextnonce,text,[RFC5090] 1458 108,Digest-Method,text,[RFC5090] 1459 109,Digest-URI,text,[RFC5090] 1460 110,Digest-Qop,text,[RFC5090] 1461 111,Digest-Algorithm,text,[RFC5090] 1462 112,Digest-Entity-Body-Hash,text,[RFC5090] 1463 113,Digest-CNonce,text,[RFC5090] 1464 114,Digest-Nonce-Count,text,[RFC5090] 1465 115,Digest-Username,text,[RFC5090] 1466 116,Digest-Opaque,text,[RFC5090] 1467 117,Digest-Auth-Param,text,[RFC5090] 1468 118,Digest-AKA-Auts,text,[RFC5090] 1469 119,Digest-Domain,text,[RFC5090] 1470 120,Digest-Stale,text,[RFC5090] 1471 121,Digest-HA1,text,[RFC5090] 1472 122,SIP-AOR,text,[RFC5090] 1473 123,Delegated-IPv6-Prefix,ipv6prefix,[RFC4818] 1474 124,MIP6-Feature-Vector,string,[RFC5447] 1475 125,MIP6-Home-Link-Prefix,ipv6prefix,[RFC5447] 1476 126,Operator-Name,text,[RFC5580] 1477 127,Location-Information,string,[RFC5580] 1478 128,Location-Data,string,[RFC5580] 1479 129,Basic-Location-Policy-Rules,string,[RFC5580] 1480 130,Extended-Location-Policy-Rules,string,[RFC5580] 1481 131,Location-Capable,enum,[RFC5580] 1482 132,Requested-Location-Info,enum,[RFC5580] 1483 133,Framed-Management-Protocol,enum,[RFC5607] 1484 134,Management-Transport-Protection,enum,[RFC5607] 1485 135,Management-Policy-Id,text,[RFC5607] 1486 136,Management-Privilege-Level,integer,[RFC5607] 1487 137,PKM-SS-Cert,concat,[RFC5904] 1488 138,PKM-CA-Cert,concat,[RFC5904] 1489 139,PKM-Config-Settings,string,[RFC5904] 1490 140,PKM-Cryptosuite-List,string,[RFC5904] 1491 141,PKM-SAID,text,[RFC5904] 1492 142,PKM-SA-Descriptor,string,[RFC5904] 1493 143,PKM-Auth-Key,string,[RFC5904] 1494 144,DS-Lite-Tunnel-Name,text,[RFC6519] 1495 145,Mobile-Node-Identifier,string,[RFC6572] 1496 146,Service-Selection,text,[RFC6572] 1497 147,PMIP6-Home-LMA-IPv6-Address,ipv6addr,[RFC6572] 1498 148,PMIP6-Visited-LMA-IPv6-Address,ipv6addr,[RFC6572] 1499 149,PMIP6-Home-LMA-IPv4-Address,ipv4addr,[RFC6572] 1500 150,PMIP6-Visited-LMA-IPv4-Address,ipv4addr,[RFC6572] 1501 151,PMIP6-Home-HN-Prefix,ipv6prefix,[RFC6572] 1502 152,PMIP6-Visited-HN-Prefix,ipv6prefix,[RFC6572] 1503 153,PMIP6-Home-Interface-ID,ifid,[RFC6572] 1504 154,PMIP6-Visited-Interface-ID,ifid,[RFC6572] 1505 155,PMIP6-Home-IPv4-HoA,ipv4prefix,[RFC6572] 1506 156,PMIP6-Visited-IPv4-HoA,ipv4prefix,[RFC6572] 1507 157,PMIP6-Home-DHCP4-Server-Address,ipv4addr,[RFC6572] 1508 158,PMIP6-Visited-DHCP4-Server-Address,ipv4addr,[RFC6572] 1509 159,PMIP6-Home-DHCP6-Server-Address,ipv6addr,[RFC6572] 1510 160,PMIP6-Visited-DHCP6-Server-Address,ipv6addr,[RFC6572] 1511 161,PMIP6-Home-IPv4-Gateway,ipv4addr,[RFC6572] 1512 162,PMIP6-Visited-IPv4-Gateway,ipv4addr,[RFC6572] 1513 163,EAP-Lower-Layer,enum,[RFC6677] 1514 164,GSS-Acceptor-Service-Name,text,[RFC7055] 1515 165,GSS-Acceptor-Host-Name,text,[RFC7055] 1516 166,GSS-Acceptor-Service-Specifics,text,[RFC7055] 1517 167,GSS-Acceptor-Realm-Name,text,[RFC7055] 1518 168,Framed-IPv6-Address,ipv6addr,[RFC6911] 1519 169,DNS-Server-IPv6-Address,ipv6addr,[RFC6911] 1520 170,Route-IPv6-Information,ipv6prefix,[RFC6911] 1521 171,Delegated-IPv6-Prefix-Pool,text,[RFC6911] 1522 172,Stateful-IPv6-Address-Pool,text,[RFC6911] 1523 173,IPv6-6rd-Configuration,tlv,[RFC6930] 1524 174,Allowed-Called-Station-Id,text,[RFC7268] 1525 175,EAP-Peer-Id,string,[RFC7268] 1526 176,EAP-Server-Id,string,[RFC7268] 1527 177,Mobility-Domain-Id,integer,[RFC7268] 1528 178,Preauth-Timeout,integer,[RFC7268] 1529 179,Network-Id-Name,string,[RFC7268] 1530 180,EAPoL-Announcement,concat,[RFC7268] 1531 181,WLAN-HESSID,text,[RFC7268] 1532 182,WLAN-Venue-Info,integer,[RFC7268] 1533 183,WLAN-Venue-Language,string,[RFC7268] 1534 184,WLAN-Venue-Name,text,[RFC7268] 1535 185,WLAN-Reason-Code,integer,[RFC7268] 1536 186,WLAN-Pairwise-Cipher,integer,[RFC7268] 1537 187,WLAN-Group-Cipher,integer,[RFC7268] 1538 188,WLAN-AKM-Suite,integer,[RFC7268] 1539 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 1540 190,WLAN-RF-Band,integer,[RFC7268] 1541 191,Unassigned,, 1542 192-223,Experimental Use,,[RFC3575] 1543 224-240,Implementation Specific,,[RFC3575] 1544 241,Extended-Attribute-1,extended,[RFC6929] 1545 241.1,Frag-Status,integer,[RFC7499] 1546 241.2,Proxy-State-Length,integer,[RFC7499] 1547 241.{3-25},Unassigned,, 1548 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 1549 241.{27-240},Unassigned,, 1550 241.{241-255},Reserved,,[RFC6929] 1551 242,Extended-Attribute-2,extended,[RFC6929] 1552 242.{1-25},Unassigned,, 1553 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 1554 242.{27-240},Unassigned,, 1555 242.{241-255},Reserved,,[RFC6929] 1556 243,Extended-Attribute-3,extended,[RFC6929] 1557 243.{1-25},Unassigned,, 1558 243.26,Extended-Vendor-Specific-3,evs,[RFC6929] 1559 243.{27-240},Unassigned,, 1560 243.{241-255},Reserved,,[RFC6929] 1561 244,Extended-Attribute-4,extended,[RFC6929] 1562 244.{1-25},Unassigned,, 1563 244.26,Extended-Vendor-Specific-4,evs,[RFC6929] 1564 244.{27-240},Unassigned,, 1565 244.{241-255},Reserved,,[RFC6929] 1566 245,Extended-Attribute-5,long-extended,[RFC6929] 1567 245.{1-25},Unassigned,, 1568 245.26,Extended-Vendor-Specific-5,evs,[RFC6929] 1569 245.{27-240},Unassigned,, 1570 245.{241-255},Reserved,,[RFC6929] 1571 246,Extended-Attribute-6,long-extended,[RFC6929] 1572 246.{1-25},Unassigned,, 1573 246.26,Extended-Vendor-Specific-6,evs,[RFC6929] 1574 246.{27-240},Unassigned,, 1575 246.{241-255},Reserved,,[RFC6929] 1576 247-255,Reserved,,[RFC3575] 1578 5. Security Considerations 1580 This specification is concerned solely with updates to IANA 1581 registries. As such, there are no security considerations with the 1582 document itself. 1584 However, the use of inconsistent names and poorly-defined entities in 1585 a protocol is problematic. Inconsistencies in specifications can 1586 lead to security and interoperability problems in implementations. 1587 Further, having one canonical source for the definition of data types 1588 means an implementor has fewer specifications to read. The 1589 implementation work is therefore simpler, and is more likely to be 1590 correct. 1592 The goal of this specification is to reduce ambiguities in the RADIUS 1593 protocol, which we believe will lead to more robust and more secure 1594 implementations. 1596 6. IANA Considerations 1598 IANA is instructed to create one new registry as described above in 1599 Section 4.1. The "TBD" text in that section should be replaced with 1600 the RFC number of this document when it is published. 1602 IANA is instructed to update the RADIUS Attribute Type registry, as 1603 described above in Section 4.2. 1605 IANA is instructed to require that all allocation requests in the 1606 RADIUS Attribute Type registry contain a "Data Type" field. That 1607 field is required to contain one of the "Data Type" names contained 1608 in the RADIUS Data Type registry. 1610 IANA is instructed to require that updates to the RADIUS Data Type 1611 registry contain the following fields, with the associated 1612 instructions: 1614 * Value. IANA is instructed to assign the next unused integer in 1615 sequence to new data type definitions. 1617 * Name. IANA is instructed to require that this name be unique 1618 in the registry. 1620 * Reference. IANA is instructed to update this field with a 1621 reference to the document which defines the data type. 1623 7. References 1625 7.1. Normative References 1627 [RFC2119] 1628 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1629 Levels", RFC 2119, March, 1997. 1631 [RFC2865] 1632 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1633 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1635 [RFC3162] 1636 Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, 1637 August 2001. 1639 [RFC3629] 1640 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1641 3629, November 2003. 1643 [RFC4072] 1644 Eronen, P., et al, "Diameter Extensible Authentication Protocol 1645 (EAP) Application", RFC 4072, February 2013. 1647 [RFC6158] 1648 DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, 1649 March 2011. 1651 [RFC6572] 1652 Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, 1653 June 2012. 1655 7.2. Informative References 1657 [RFC2868] 1658 Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. 1659 Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 1660 June 2000. 1662 [RFC2869] 1663 Rigney, C., et al, "RADIUS Extensions", RFC 2869, June 2000. 1665 [RFC5234] 1666 Crocker, D. and P. Overell, "Augmented BNF for Syntax 1667 Specifications: ABNF", RFC 5234, January 2008. 1669 [RFC6929] 1670 DeKok, A., and Lior, A., "Remote Authentication Dial In User 1671 Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 1673 [RFC7268] 1674 Aboba, B, et al, "RADIUS Attributes for IEEE 802 Networks", RFC 1675 7268, July 2015. 1677 [RFC7499] 1678 Perez-Mendez A., et al, "Support of Fragmentation of RADIUS 1679 Packets", RFC 7499, April 2015. 1681 [PEN] 1682 http://www.iana.org/assignments/enterprise-numbers 1684 Acknowledgments 1686 Thanks to the RADEXT WG for patience and reviews of this document. 1688 Authors' Addresses 1690 Alan DeKok 1691 The FreeRADIUS Server Project 1693 Email: aland@freeradius.org