idnits 2.17.1 draft-calhoun-enh-radius-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 31 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 51: '... MUST be supported. An accompanyi...' RFC 2119 keyword, line 61: '... MUST This word, or the adje...' RFC 2119 keyword, line 65: '... MUST NOT This phrase means that...' RFC 2119 keyword, line 68: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 74: '... MAY This word, or the adje...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Version field is used by the RADIUS Server to inform the NAS the highest version which it supports. The Server MUST not insert a version which is higher than requested by the NAS. The client MUST use the version which is reported by the Server. If the NAS does not support the version returned by the Server, it should default to RADIUS V1. -- 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 (June 1996) is 10177 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 559 looks like a reference -- Missing reference section? '3' on line 563 looks like a reference -- Missing reference section? '2' on line 561 looks like a reference -- Missing reference section? '4' on line 565 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Pat R. Calhoun 2 Category: Experimental US Robotics Access Corp. 3 expires in six months Allan Rubens 4 Merit Network Inc. 5 June 1996 7 Enhanced Remote Authentication Dial In User Service (RADIUS) 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Abstract 32 This document describes a protocol for carrying authentication, 33 authorization, and configuration information between a Network Access 34 Server which desires to authenticate its links and a shared 35 Authentication Server. This enhanced protocol is a backward 36 compatible protocol which attempts to solve many deficiencies with 37 the existing protocol. 39 1. Introduction 41 Enhanced RADIUS is an extension to the existing RADIUS 42 specification [1]. This document in itself is not complete and 43 should be used with the RADIUS Version 1 specification [1]. 45 Since RADIUS Version 1 has a very limited number of available 46 commands and attributes, the intent of the Enhanced RADIUS 47 protocol is to allow for future protocol enhancements. 49 This document will describe the packet headers for the Enhanced 50 RADIUS protocol as well as any commands and attributes which 51 MUST be supported. An accompanying document will describe the 52 documentation required in order to standardize any protocol 53 extensions. 55 1.1. Specification of Requirements 57 In this document, several words are used to signify the 58 requirements of the specification. These words are often 59 capitalized. 61 MUST This word, or the adjective "required", means that the 62 definition is an absolute requirement of the 63 specification. 65 MUST NOT This phrase means that the definition is an absolute 66 prohibition of the specification. 68 SHOULD This word, or the adjective "recommended", means that 69 there may exist valid reasons in particular circumstances 70 to ignore this item, but the full implications must be 71 understood and carefully weighed before choosing a 72 different course. 74 MAY This word, or the adjective "optional", means that this 75 item is one of an allowed set of alternatives. An 76 implementation which does not include this option MUST 77 be prepared to interoperate with another implementation 78 which does include the option. 80 1.2. Terminology 82 This document frequently uses the following terms: 84 silently discard 86 This means the implementation discards the packet without 87 further processing. The implementation SHOULD provide the 88 capability of logging the error, including the contents of 89 the silently discarded packet, and SHOULD record the event 90 in a statistics counter. 92 2. Packet Format 94 Exactly one RADIUS packet is encapsulated in the UDP Data field 95 [3], where the UDP Destination Port field indicates 1645. 97 When a reply is generated, the source and destination ports are 98 reversed. 100 A summary of the Enhanced RADIUS data format is shown below. 101 The fields are transmitted from left to right. 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Code | Flags | Ver | Command | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Identifier | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | | 111 | Authenticator | 112 | | 113 | | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | | 116 | Message Integrity Code | 117 | | 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Attributes ... 121 +-+-+-+-+-+-+-+-+-+-+-+-+- 123 Code 125 The Code field is one octet, and identifies the type of RADIUS 126 packet. When a valid code is received, the packet format to use 127 is as defined in the RADIUS V1 specification [1]. When a packet 128 is received with an invalid Code field, it is silently discarded. 129 When a code of 0xFE (254) is received, it identifies an Enhanced 130 RADIUS packet as shown above, in which case the Command field is to 131 be checked. In this case the RADIUS Codes wich follow 132 (with the exception of 254) are passed in the Command field 133 instead. 135 RADIUS Codes (decimal) are assigned as follows: 137 1 Access-Request 138 2 Access-Accept 139 3 Access-Reject 140 4 Accounting-Request 141 5 Accounting-Response 142 11 Access-Challenge 143 12 Status-Server (experimental) 144 13 Status-Client (experimental) 145 254 Enhanced RADIUS packet 147 Flags 149 The Flags field is five bits, and is used in order to identify any 150 options. This field MUST be set to zero unless any options are 151 used. The following flags are defined globally for all commands: 153 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 155 Note that additional options in the Flag field may be defined per 156 Command (see individual commands). 158 Version 160 The Version field is three bits, and indicates the version number 161 which is associated with the packet received. This field MUST be 162 set to 2. 164 Command 166 The Command field is two octet, and identifies the type of RADIUS 167 packet. When a packet is received with an invalid Code field, a 168 Command-Unrecognized message SHOULD be returned. 170 RADIUS Commands (decimal), in addition to those shown above, are 171 assigned as follows: 173 256 Command-Unrecognized 174 267 NAS-Reboot-Indication 175 268 NAS-Reboot-Ack 177 Identifier 179 The Identifier field is two octets, and aids in matching requests 180 and replies. 182 Length 184 The Length field is two octets. It indicates the length of the 185 packet including the header fields. Octets outside the range of 186 the Length field should be treated as padding and should be 187 ignored on reception. 189 Authenticator 191 The Authenticator field is a random 16 octet value. This field adds 192 randomness to the packets and makes the guessing of the shared 193 secret much more diffcult to the malicious user. 195 If the Timestamp option is supported, the first four octets 196 contains a timestamp of when the packet was sent from the peer. 197 This allows the protocol to detect replay attacks. The Timestamp 198 value is the current time relative to a base of 0:0:0 GMT 199 January 1, 1900. 201 Message Integrity Code 203 This field contains an MD5 hash of the following: 205 MD5( packet | Shared Secret ) 207 When creating a message, the MIC must be set to all zeros before 208 calculating the MD5 hash. When receiving a message, the receiver 209 must save the MIC, set the field to all zeroes and perform the 210 hash function. The resulting value MUST be identical to the 211 value which was in the message. 213 3. Command Name and Command Code 215 Command Name: Command-Unrecognized 216 Command Code: 256 217 Command Name: NAS-Reboot-Indicationr 218 Command Code: 267 220 Command Name: NAS-Reboot-Ack 221 Command Code: 268 223 4. Command Meanings 225 The Enhanced RADIUS Packet type is determined by the Command Code 226 field in the second and third octets of the Packet. This section will 227 not describe the RADIUS packets already defined in [1]. 229 4.1. Command-Unrecognized 231 Description 233 Command-Unrecognized packets are sent by the NAS or the RADIUS 234 server to inform its peer that a previous packet received is 235 unrecognized. 237 Since there certainly will exist a case where an existing device 238 does not support a new extension to the Enhanced RADIUS protocol, 239 a device which receives a packet with an unrecognized Command code 240 SHOULD return a Command-Unrecognized packet. 242 For backward compatibility with RADIUS Version 1, a device MUST 243 support the fact that its peer may silently discard the packet. 245 A summary of the Command-Unrecognized packet format is shown below. 246 The fields are transmitted from left to right. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Code | Flags | Ver | Command | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Identifier | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 | Authenticator | 257 | | 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 | Message Integrity Code | 262 | | 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Code 268 254 for Enhanced RADIUS. 270 Flags 272 The Flag field is used as described above. 274 Version 276 MUST be set to 2 278 Command 280 256 for Command-Unrecognized. 282 Identifier 284 The Identifier field is a copy of the Identifier field of the 285 packet which caused this event. 287 Length 289 The total length of the message, including the this header. 291 Authenticator 293 The Authenticator field is a random 16 octet value. If the Timestamp 294 option is supported, the first four octets contains a timestamp of 295 when the packet was sent from the peer. 297 Message Integrity Code 299 This field contains an MD5 hash of the following: 301 MD5( packet | Shared Secret ) 303 4.2. NAS-Reboot-Indication 305 Description 307 The NAS-Reboot-Indication message is sent from the NAS to the RADIUS 308 Server in order for the NAS to inform the local server that it has 309 rebooted. The server MUST respond to the message with a successful 310 acknowledge, indicating its version. 312 This message is used by both the NAS and the RADIUS Server in order 313 to exchange protocol version numbers which it supports. The NAS 314 MUST insert the highest version number which it supports. The 315 RADIUS Server must respond with the highest version which it 316 supports, but may not be higher than the version number requested 317 by the NAS. 319 In the case of a proxy server, the proxy is responsible for 320 inserting the highest version number which it supports in the 321 version field before sending the proxy request to the remote 322 RADIUS server. The proxy server may then retain the version number 323 of the remote server as received in the response, and must insert 324 its highest version number (with the limitations described above) 325 in the response to the NAS. 327 The Server may discard this information if it wishes to do so, however 328 it is envisioned that the Server would retain the NAS' and remote 329 RADIUS server's version numbers to retain backward and forward 330 protocol compatibility. 332 A NAS MUST support the fact that it may not receive an acknowledge 333 to this message if the RADIUS Server does not support this version 334 of the protocol. In this case, if no acknowledge was receive, it 335 must default to version 1 messages as described in [1]. 337 If a NAS is configured to communicate with more than one RADIUS server 338 it MUST issue NAS-Reboot-Indications to each such server. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Code | Flags | Ver | Command | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Identifier | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 | Authenticator | 349 | | 350 | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 | Message Integrity Code | 354 | | 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Code 360 254 for Enhanced RADIUS 362 Flags 364 The Flag field is used as described above. 366 Version 368 The version field is used by the NAS to indicate the highest 369 supported version of the RADIUS protocol. This will allow the NAS 370 and RADIUS Server to be able to negotiate a version of the protocol 371 to use between both peers. 373 Command 375 267 for NAS-Reboot-Indication. 377 Identifier 379 The Identifier field MUST be changed whenever the content of the 380 Attributes field changes, and whenever a valid reply has been 381 received for a previous request. For retransmissions, the 382 Identifier MAY remain unchanged. 384 Length 386 The total length of the message, including this header. 388 Authenticator 390 The Authenticator field is a random 16 octet value. If the Timestamp 391 option is supported, the first four octets contain a timestamp of 392 when the packet was sent from the peer. 394 Message Integrity Code 396 This field contains an MD5 hash of the following: 398 MD5( packet | Shared Secret ) 400 5.3. NAS-Reboot-Ack 402 Description 404 The NAS-Reboot-Ack message is sent from the RADIUS Server to the 405 NAS to acknowledge the receipt of the NAS-Reboot message. The 406 Server MUST replace the version value in the version field with the 407 highest version number which it supports, up to and including 408 the version which was included in the NAS-Reboot's version field. 410 The NAS may wish to ignore the version number contained in the Flag 411 field, however it is envisioned that the NAS would retain this 412 information to remove any backward compatibility problems with any 413 future versions of the protocol. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Code | Flags | Ver | Command | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Identifier | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 | Authenticator | 424 | | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 | Message Integrity Code | 429 | | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Code 435 254 for Enhanced RADIUS. 437 Flags 439 The Flag field is used as described above. 441 Version 443 The Version field is used by the RADIUS Server to inform the NAS 444 the highest version which it supports. The Server MUST not insert 445 a version which is higher than requested by the NAS. The client 446 MUST use the version which is reported by the Server. If the NAS 447 does not support the version returned by the Server, it should 448 default to RADIUS V1. 450 Command 452 268 for NAS-Reboot-Ack. 454 Identifier 456 The Identifier field is a copy of the Identifier field of the 457 packet which caused this event. 459 Length 461 The total length of the message, including this header. 463 Authenticator 465 The Authenticator field is a random 16 octet value. If the Timestamp 466 option is supported, the first four octets contain a timestamp of 467 when the packet was sent from the peer. 469 Message Integrity Code 471 This field contains an MD5 hash of the following: 473 MD5( packet | Shared Secret ) 475 6. Attributes 477 RADIUS Attributes carry the specific authentication, authorization, 478 information and configuration details for the request and reply. 480 Some Attributes MAY be listed more than once. The effect of this is 481 Attribute specific, and is specified by each such Attribute 482 description. 484 The end of the list of Attributes is indicated by the length of the 485 RADIUS packet. 487 A summary of the Attribute format is shown below. The fields are 488 transmitted from left to right. 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Attribute Type | Length | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Flags | Vendor ID (optional) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 |Vendor ID (opt)| Value ... | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Type 502 The Type field is two octets. RADIUS Version 1 reserves the 503 lowest 256 attribute numbers. Up-to-date values of the RADIUS Type 504 field are specified in the most recent "Assigned Numbers" RFC [2]. 506 Enhanced RADIUS Versions will use attribute numbers 257 and above. 507 Vendor Specific attributes reside within this space when the Vendor 508 Specific bit is set (see flags). This will allow up to 65535 509 trouble-free vendor specific attributes (per vendor). 511 Length 513 The Length field is two octets, and indicates the length of this 514 Attribute including the Type, Length, Flag, Vendor ID is present and 515 Value fields. If a packet is received with an Invalid length, the 516 packet SHOULD be rejected. 518 Flags 520 The Flags field indicates how the NAS or RADIUS Server MUST react 521 to the attribute. The following values are currently supported: 523 1 - The Device MUST support this attribute. If the attribute 524 is NOT supported, the device MUST reject the Command. 525 If this flag is not set, then the device MAY accept the 526 command regardless of whether or not the particular attribute 527 is recognized. 529 128 - If this bit is set, the optional Vendor ID field will be 530 present. When set, the attribute is a vendor specific 531 attribute 533 Value 535 The Value field is zero or more octets and contains information 536 specific to the Attribute. The format and length of the Value 537 field is determined by the Type and Length fields. 539 The format of the value field is one of five data types. 541 string 0-65526 octets. 543 address 32 bit value, most significant octet first. 545 extended 546 address Address Length is determined from the Length field, most 547 significant octet first. This is required in order to 548 support protocols which require an address length greater 549 than 32 bits (i.e. IPNG). Note that this type is 550 differentiated from the previous type by the value of length. 552 integer 32 bit value, most significant octet first. 554 time 32 bit value, most significant octet first -- seconds 555 since 00:00:00 GMT, January 1, 1970. 557 References 559 [1] Rigney, et alia, "RADIUS Authentication", Internet-Draft, 560 Livingston, May 1995. 561 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 562 USC/Information Sciences Institute, October 1994. 563 [3] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 564 Sciences Institute, August 1980. 565 [4] Calhoun, "Enhanced RADIUS Protocol Extension Specifications", 566 Internet-Draft, US Robotics Access Corp., May 1996.