idnits 2.17.1 draft-calhoun-diameter-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-03-29) 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 45 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], [5], [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 59: '... commands and attributes which MUST be...' RFC 2119 keyword, line 61: '... MUST be used with the RADIUS RFC[1] which describes the...' RFC 2119 keyword, line 71: '... MUST This word, or the adje...' RFC 2119 keyword, line 75: '... MUST NOT This phrase means that...' RFC 2119 keyword, line 78: '... SHOULD This word, or the adje...' (42 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 DIAMETER 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 using the RADIUS protocol. -- 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 (March 1997) is 9876 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 680 looks like a reference -- Missing reference section? '3' on line 683 looks like a reference -- Missing reference section? '4' on line 685 looks like a reference -- Missing reference section? '5' on line 688 looks like a reference -- Missing reference section? '2' on line 681 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 7 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 March 1997 7 DIAMETER 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 original document was named Enhanced RADIUS and was changed at 33 the request of the WG since this protocol is different from the 34 former. 36 This document describes a management protocol used between Network 37 Access Servers and DIAMETER Servers for authentication, authorization, 38 accounting of dial-up users. A considerable amount of effort was put 39 into the design of this protocol to ensure that an implementation could 40 support both DIAMETER and RADIUS at the same time. 42 1. Introduction 44 Since the RADIUS protocol is being used today for much more than 45 simple authentication and accounting of dial-up users (i.e. 46 authentication of WEB clients, etc), a more extensible protocol was 47 necessary which could support new services being deployed in the 48 internet and corporate networks. 50 RADIUS in itself is not an extensible protocol largely due to its 51 very limited command and attribute address space. In addition, the 52 RADIUS protocol assumes that there cannot be any unsolicited 53 messages from a server to a client. In order to support new services 54 it is imperative that a server be able to send unsolicited messages 55 to clients on a network, and this is a requirement for any DIAMETER 56 implementation. 58 This document will describe the packet headers for the DIAMETER 59 protocol as well as any commands and attributes which MUST be 60 supported. Note that this document in itself is not complete and 61 MUST be used with the RADIUS RFC[1] which describes the 62 authentication and accounting messages as well as the necessary 63 attributes. 65 1.1. Specification of Requirements 67 In this document, several words are used to signify the 68 requirements of the specification. These words are often 69 capitalized. 71 MUST This word, or the adjective "required", means that the 72 definition is an absolute requirement of the 73 specification. 75 MUST NOT This phrase means that the definition is an absolute 76 prohibition of the specification. 78 SHOULD This word, or the adjective "recommended", means that 79 there may exist valid reasons in particular circumstances 80 to ignore this item, but the full implications must be 81 understood and carefully weighed before choosing a 82 different course. 84 MAY This word, or the adjective "optional", means that this 85 item is one of an allowed set of alternatives. An 86 implementation which does not include this option MUST 87 be prepared to interoperate with another implementation 88 which does include the option. 90 2. Packet Format 92 Exactly one DIAMETER packet is encapsulated in the Data field of 93 a UDP Packet[3], where the UDP Destination Port field indicates 1645. 95 When a reply is generated, the source and destination ports are 96 reversed. 98 A summary of the DIAMETER data format is shown below. The fields 99 are transmitted from left to right. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Code | Flags | Ver | Command | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Identifier | Length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 | Authenticator | 110 | | 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 | Message Integrity Code | 115 | | 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Attributes ... 119 +-+-+-+-+-+-+-+-+-+-+-+-+- 121 Code 123 The Code field is a one octet field which is used in the RADIUS 124 protocol to identify the command type. In order to easily 125 distinguish DIAMETER packets from RADIUS a special value has been 126 reserved. 128 A Server implementation can now support both RADIUS and DIAMETER 129 and identify the packet type by looking at the first octet in the 130 header. The Code field MUST be set as follow: 132 254 DIAMETER packet 134 Flags 136 The Flags field is five bits, and is used in order to identify any 137 options. This field MUST be set to zero unless any options are 138 used. The following flags are defined globally for all commands: 140 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 141 0x2 - (Bit 11) All attributes in packets are encrypted. 143 When the encryption feature is set, all data following the DIAMETER 144 header is XORed using MD5 with the shared secret (see section 3). 146 Version 148 The Version field is three bits, and indicates the version number 149 which is associated with the packet received. This field MUST be 150 set to 2. 152 Command 154 The Command field is two octet, and identifies the type of DIAMETER 155 packet. When a packet is received with an invalid Code field, a 156 Command-Unrecognized message SHOULD be returned. See section 4 for 157 a list of supported commands. 159 Identifier 161 The Identifier field is two octets, and aids in matching requests 162 and replies. 164 Length 166 The Length field is two octets. It indicates the length of the 167 packet including the header fields. Octets outside the range of 168 the Length field should be treated as padding and should be 169 ignored on reception. 171 Authenticator 173 The Authenticator field is a random 16 octet value. This field adds 174 randomness to the packets and makes the guessing of the shared 175 secret much more diffcult to the malicious user. 177 If the Timestamp option is supported, the first four octets 178 contains a timestamp of when the packet was sent from the peer. 179 This allows the protocol to detect replay attacks. The Timestamp 180 value is the current time relative to a base of 0:0:0 GMT 181 January 1, 1900. 183 Message Integrity Code (MIC) 185 This field contains an MD5 hash of the following: 187 MD5( packet | Shared Secret ) 189 When creating a message, the MIC must be set to all zeros before 190 calculating the MD5 hash. When receiving a message, the receiver 191 must save the MIC, set the field to all zeroes and perform the 192 hash function. The resulting value MUST be identical to the 193 value which was in the message. 195 Attributes 197 See section 6 for more information of attribute formats. 199 3. Data Encryption 201 When the encryption flag is enabled (either for a specific 202 attribute or for all attributes following the header) the MD5[4] 203 algorithm is used. However, since the MD5 algorithm works 204 specifically with strings of up to 16 octets and most attributes 205 will have a length of greater than 16 octets, the following method 206 is used: 208 e(1) = MD5( SS | IV ) 209 v(1) = d(1) XOR e(1) 210 e(2) = MD5( SS | v(1) ) 211 v(2) = d(2) XOR e(2) 212 . 213 . 214 . 215 e(x) = MD5( SS | v(x) ) 216 v(x) = d(x) XOR e(x) 218 Where: 220 | - Concatenate 221 SS - Shared Secret 222 IV - Initialization Vector, this value is derived from the 223 Authenticator field in the Diameter header. 224 d(n) - data partitioned into 16 octets chunks. This value 225 MUST be padded with NULLs to 16 characters if the 226 length is less than 16 octets. 227 e(n) - 16 octet hash resulting from the MD5 algorithm 228 v(n) - 16 octet encrypted data 230 The above formula MUST be executed in order to encrypt the data. 231 The number of times which the formula must be executed is length/16. 233 In the case of attribute encryption, only the data following the 234 attribute header is encrypted. In the case of the encryption bit 235 set in the header, all data following the header is passed through 236 the above formula. Which ever the case, it is imperative that the 237 data be padded with NULLs to a 16 octet boundary. 239 The encrypted data MUST then be concatenated as v(1)|v(2)|...v(x). 240 Since this process is reverseable, the receiver MUST inverse the 241 process in order to extract the data from the encrypted hash. 243 Read [5] for more information on the use of this algorithm, 245 4. Command Name and Command Code 247 Command Name: Command-Unrecognized 248 Command Code: 256 250 Command Name: NAS-Reboot-Indicationr 251 Command Code: 267 253 Command Name: NAS-Reboot-Ack 254 Command Code: 268 256 Command Name: Vendor-Specific 257 Command Code: 269 259 5. Command Meanings 261 The DIAMETER Packet type is determined by the Command Code field in 262 the second and third octets of the Packet. This section will not 263 describe the existing RADIUS codes as defined in [1]. 265 5.1. Command-Unrecognized 267 Description 269 Command-Unrecognized packets are sent by the NAS or the DIAMETER 270 server to inform its peer that a previous packet received is 271 unrecognized. 273 Since there certainly will exist a case where an existing device 274 does not support a new extension to the DIAMETER protocol, a device 275 which receives a packet with an unrecognized Command code MUST 276 return a Command-Unrecognized packet. 278 For backward compatibility with RADIUS, a device SHOULD support the 279 fact that its peer may silently discard the packet. 281 A summary of the Command-Unrecognized packet format is shown below. 282 The fields are transmitted from left to right. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Code | Flags | Ver | Command | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Identifier | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 | Authenticator | 293 | | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 | Message Integrity Code | 298 | | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Code 304 254 for DIAMETER. 306 Flags 308 The Flag field is used as described above. 310 Version 312 MUST be set to 2 314 Command 316 256 for Command-Unrecognized. 318 Identifier 320 The Identifier field is a copy of the Identifier field of the 321 packet which caused this event. 323 Length 325 The total length of the message, including this header. 327 Authenticator 329 The Authenticator field is a random 16 octet value. If the Timestamp 330 option is supported, the first four octets contains a timestamp of 331 when the packet was sent from the peer. 333 Message Integrity Code 335 This field contains an MD5 hash of the following: 337 MD5( packet | Shared Secret ) 339 5.2. NAS-Reboot-Indication 341 Description 343 The NAS-Reboot-Indication message is sent from the NAS to the 344 DIAMETER Server in order for the NAS to inform the local server 345 that it has rebooted. The server MUST respond to the message with 346 a successful acknowledge, indicating its version. 348 This message is used by both the NAS and the DIAMETER Server in 349 order to exchange protocol version numbers which it supports. The 350 NAS MUST insert the highest version number which it supports. The 351 DIAMETER Server must respond with the highest version which it 352 supports, but may not be higher than the version number requested 353 by the NAS. 355 In the case of a proxy server, the proxy is responsible for 356 inserting the highest version number which it supports in the 357 version field before sending the proxy request to the remote 358 DIAMETER server. The proxy server may then retain the version 359 number of the remote server as received in the response, and must 360 insert its highest version number (with the limitations described 361 above) in the response to the NAS. 363 The Server may discard this information if it wishes to do so, 364 however it is envisioned that the Server would retain the NAS' 365 and remote DIAMETER server's version numbers to retain backward and 366 forward protocol compatibility. 368 A NAS MUST support the fact that it may not receive an acknowledge 369 to this message if the DIAMETER Server does not support this version 370 of the protocol. In this case, if no acknowledgment was received 371 within the maximum retransmission period, it MAY default to using 372 messages as described in [1]. 374 If a NAS is configured to communicate with more than one DIAMETER 375 server it MUST issue NAS-Reboot-Indications to each such server. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Code | Flags | Ver | Command | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Identifier | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | Authenticator | 386 | | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | Message Integrity Code | 391 | | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Code 397 254 for DIAMETER 399 Flags 401 The Flag field is used as described above. 403 Version 405 The version field is used by the NAS to indicate the highest 406 supported version of the DIAMETER protocol. This will allow the NAS 407 and DIAMETER Server to be able to negotiate a version of the 408 protocol to use between both peers. 410 Command 412 267 for NAS-Reboot-Indication. 414 Identifier 416 The Identifier field MUST be changed whenever the content of the 417 Attributes field changes, and whenever a valid reply has been 418 received for a previous request. For retransmissions, the 419 Identifier MAY remain unchanged. 421 Length 423 The total length of the message, including this header. 425 Authenticator 427 The Authenticator field is a random 16 octet value. If the Timestamp 428 option is supported, the first four octets contain a timestamp of 429 when the packet was sent from the peer. 431 Message Integrity Code 433 This field contains an MD5 hash of the following: 435 MD5( packet | Shared Secret ) 437 5.3. NAS-Reboot-Ack 439 Description 441 The NAS-Reboot-Ack message is sent from the DIAMETER Server to the 442 NAS to acknowledge the receipt of the NAS-Reboot message. The 443 Server MUST replace the version value in the version field with the 444 highest version number which it supports, up to and including 445 the version which was included in the NAS-Reboot's version field. 447 The NAS may wish to ignore the version number contained in the Flag 448 field, however it is envisioned that the NAS would retain this 449 information to remove any backward compatibility problems with any 450 future versions of the protocol. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Code | Flags | Ver | Command | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Identifier | Length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 | Authenticator | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 | Message Integrity Code | 466 | | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Code 472 254 for DIAMETER. 474 Flags 476 The Flag field is used as described above. 478 Version 480 The Version field is used by the DIAMETER Server to inform the NAS 481 the highest version which it supports. The Server MUST not insert 482 a version which is higher than requested by the NAS. The client 483 MUST use the version which is reported by the Server. If the NAS 484 does not support the version returned by the Server, it should 485 default to using the RADIUS protocol. 487 Command 489 268 for NAS-Reboot-Ack. 491 Identifier 493 The Identifier field is a copy of the Identifier field of the 494 packet which caused this event. 496 Length 498 The total length of the message, including this header. 500 Authenticator 502 The Authenticator field is a random 16 octet value. If the Timestamp 503 option is supported, the first four octets contain a timestamp of 504 when the packet was sent from the peer. 506 Message Integrity Code 508 This field contains an MD5 hash of the following: 510 MD5( packet | Shared Secret ) 512 6. Attributes Formats 514 DIAMETER Attributes carry the specific authentication and 515 authorization information as well as configuration details for the 516 request and reply. 518 Some Attributes MAY be listed more than once. The effect of this is 519 Attribute specific, and is specified by each such attribute 520 description. 522 The end of the list of attributes is indicated by the length of the 523 DIAMETER packet. 525 A summary of the attribute format is shown below. The fields are 526 transmitted from left to right. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Attribute Type | Length | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Flags | Vendor ID (optional) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |Vendor ID (opt)| Value ... | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Type 540 The Type field is two octets. RADIUS reserves the lowest 256 541 attribute numbers. Up-to-date values of the RADIUS Type field are 542 specified in the most recent "Assigned Numbers" RFC [2]. 544 DIAMETER will use attribute numbers 257 and above. Vendor Specific 545 attributes reside within this space when the Vendor Specific bit is 546 set (see flags). This will allow up to 65535 trouble-free vendor 547 specific attributes (per vendor). 549 Length 551 The Length field is two octets, and indicates the length of this 552 Attribute including the Type, Length, Flag, Vendor ID is present and 553 Value fields. If a packet is received with an Invalid length, the 554 packet SHOULD be rejected. 556 Flags 558 The Flags field indicates how the NAS or DIAMETER Server MUST react 559 to the attribute. The following values are currently supported: 561 1 - The Device MUST support this attribute. If the attribute 562 is NOT supported, the device MUST reject the Command. 563 If this flag is not set, then the device MAY accept the 564 command regardless of whether or not the particular attribute 565 is recognized. 567 2 - If this bit is set, the contents of the attributes are 568 encrypted. Note that the attribute header is NOT encrypted in 569 this case. See section 3 for more information. 571 NOTE That this bit MUST NOT be turned on if the encryption bit 572 is set in the DIAMETER header which means that all attributes 573 are encrypted. 575 128 - If this bit is set, the optional Vendor ID field will be 576 present. When set, the attribute is a vendor specific 577 attribute 579 Value 581 The Value field is zero or more octets and contains information 582 specific to the Attribute. The format and length of the Value 583 field is determined by the Type and Length fields. 585 The format of the value field is one of five data types. 587 string 0-65526 octets. 589 address 32 bit value, most significant octet first. 591 extended 592 address Address Length is determined from the Length field, most 593 significant octet first. This is required in order to 594 support protocols which require an address length greater 595 than 32 bits (i.e. IPNG). Note that this type is 596 differentiated from the previous type by the value of length. 598 integer 32 bit value, most significant octet first. 600 time 32 bit value, most significant octet first -- seconds 601 since 00:00:00 GMT, January 1, 1970. 603 7. Attribute Name and Attribute Code 605 Attribute Name: Command-Code 606 Attribute Code: 263 608 8. Command Meanings 610 The DIAMETER Packet type is determined by the Command Code field in 611 the second and third octets of the Packet. This section will not 612 describe the existing RADIUS codes as defined in [1]. 614 8.1. Command-Code 616 Description 618 The Command-Code attribute MAY be used in conjunction with the 619 Vendor-Specific command code set in the header. This attribute 620 MUST include a Vendor-ID in the attribute header. A vendor-ID 621 set to zero (0) indicates a standard (non-proprietary) command. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Attribute Type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Flags | Vendor ID (optional) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 |Vendor ID (opt)| Value ... | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Type 635 263 for EAP-Packet 637 Length 639 >= 13 641 Flags 643 The Flags field indicates how the NAS or DIAMETER Server MUST react 644 to the attribute. The following values are currently supported: 646 1 - The Device MUST support this attribute. If the attribute 647 is NOT supported, the device MUST reject the Command. 648 If this flag is not set, then the device MAY accept the 649 command regardless of whether or not the particular attribute 650 is recognized. This bit MUST be set. 652 2 - If this bit is set, the contents of the attributes are 653 encrypted. Note that the attribute header is NOT encrypted in 654 this case. See section 3 for more information. 656 128 - This bit (Vendor ID present) MUST be set in the attribute. 658 Vendor ID 660 The Vendor ID field MUST contain a value. A value of zero (0) 661 indicates that the command contains a standard command code. 663 Identifier 665 The identifier field is used in order to build a "history" of the 666 transaction. The EAP-Packet attribute with the highest identifier 667 represents the current packet to process. The history is passed along 668 in each request/responses in order for an EAP authentication to 669 span multiple DIAMETER servers (in order to support the concept of 670 backup servers). 672 Value 674 The Value attribute MUST contain the Command Code associated with 675 this message. It MAY be set the a standard Command Code as defined 676 in this draft if the Vendor ID is set to zero (0). 678 9. References 680 [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997 681 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 682 USC/Information Sciences Institute, October 1994. 683 [3] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 684 Sciences Institute, August 1980. 685 [4] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 686 MIT Laboratory for Computer Science and RSA Data Security, 687 Inc., RFC 1321, April 1992. 688 [5] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 689 Private Communications in a Public World", Prentice Hall, 690 March 1995, ISBN 0-13-061466-1. 692 10. Authors' Addresses 694 Pat R. Calhoun 695 US Robotics Access Corp. 696 8100 N. McCormick Blvd. 697 Skokie, IL 60076-2999 699 Phone: 847-342-6898 700 EMail: pcalhoun@usr.com 702 Allan C. Rubens 703 Merit Network, Inc. 704 4251 Plymouth Rd. 705 Ann Arbor, MI 48105-2785 707 Phone: 313-647-0417 708 EMail: acr@merit.edu