idnits 2.17.1 draft-calhoun-diameter-01.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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 138 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 195 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 85: '... complete and MUST be used with ...' RFC 2119 keyword, line 96: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 100: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 103: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 109: '... MAY This word, or the adjecti...' (85 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... This docum...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '... groups may ...' == Line 20 has weird spacing: '...iate to use ...' == Line 21 has weird spacing: '... as referen...' == (133 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 958, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 961, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 963, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 966, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2058 (ref. '1') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-01.txt Allan Rubens 5 Date: March 1998 Merit Networks Inc. 7 DIAMETER 8 Base Protocol 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 Internet-Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet-Drafts 21 as reference material or to cite them other than as a ``working 22 draft'' or ``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, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au. 29 Abstract 31 This original document was named Enhanced RADIUS and was changed at 32 the request of the WG since this protocol is different from the 33 former. 35 This document describes a management protocol used between Network 36 Access Servers and DIAMETER Servers for authentication, authorization, 37 and accounting of dial-up users. A considerable amount of effort was 38 put into the design of this protocol to ensure that an implementation 39 could support both DIAMETER and RADIUS at the same time. 41 Table of Contents 43 1.0 Introduction 44 1.1 Definitions 45 2.0 Packet Format 46 3.0 DIAMETER Attributes Format 47 4.0 Command Meanings 48 4.1 Command AVP 49 4.1.1 Command Name and Command Code 50 4.1.2 Command-Unrecognized 51 4.1.3 Device-Reboot-Indication 52 4.1.4 Device-Reboot-Ack 53 4.1.5 Device-Feature-Request 54 4.1.6 Device-Feature-Response 55 4.2 DIAMETER AVPs 56 4.2.1 Version-Number 57 4.2.2 Supported-Extension 58 4.2.3 Signature 59 4.2.4 Digital-Signature 60 4.2.5 Initialization-Vector 61 4.2.6 Timestamp 62 4.2.7 Session-Id 63 5.0 Protocol Definition 64 5.1 DIAMETER Proxy 65 5.2 Digital Signatures 66 6.0 References 67 7.0 Contacts 69 1.0 Introduction 71 Since the RADIUS protocol is being used today for much more than 72 simple authentication and accounting of dial-up users (i.e. 73 authentication of WEB clients, etc), a more extensible protocol was 74 necessary which could support new services being deployed in the 75 internet and corporate networks. 77 RADIUS in itself is not an extensible protocol largely due to its very 78 limited command and attribute address space. In addition, the RADIUS 79 protocol assumes that there cannot be any unsolicited messages from a 80 server to a client. In order to support new services it is imperative 81 that a server be able to send unsolicited messages to clients on a 82 network, and this is a requirement for any DIAMETER implementation. 84 This document describes the base DIAMETER protocol. This document in 85 itself is not complete and MUST be used with an accompanying 86 applicability extension document. 88 An example of such a document would be [x] which defines extensions to 89 the base protocol to support user authentication and [x] which defines 90 extensions to support accounting. 92 1.1 Definitions 93 In this document, several words are used to signify the requirements 94 of the specification. These words are often capitalized. 96 MUST This word, or the adjective "required", means that the 97 definition is an absolute requirement of the 98 specification. 100 MUST NOT This phrase means that the definition is an absolute 101 prohibition of the specification. 103 SHOULD This word, or the adjective "recommended", means that 104 there may exist valid reasons in particular circumstances 105 to ignore this item, but the full implications must be 106 understood and carefully weighed before choosing a 107 different course. 109 MAY This word, or the adjective "optional", means that this 110 item is one of an allowed set of alternatives. An 111 implementation which does not include this option MUST 112 be prepared to interoperate with another implementation 113 which does include the option. 115 2.0 DIAMETER Header Format 117 DIAMETER packets MAY be transmitted over UDP or TCP. Each Service 118 Extensions draft SHOULD specify the transport layer. The destination 119 port field for DIAMETER is 1645. 121 When a reply is generated, the source and destination ports are 122 reversed. 124 A summary of the DIAMETER data format is shown below. The fields are 125 transmitted from left to right. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Code | Flags | Ver | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Identifier | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Attributes ... 135 +-+-+-+-+-+-+-+-+-+-+-+-+- 137 Code 139 The Code field is a one octet field which is used in the RADIUS 140 protocol to identify the command type. In order to easily 141 distinguish DIAMETER packets from RADIUS a special value has been 142 reserved. 144 This field allows an implementation to support both RADIUS as well 145 as DIAMETER simply by identifying the first octet in the header. 146 The Code field MUST be set as follows: 148 254 DIAMETER packet 150 Flags 152 The Flags field is five bits, and is used in order to identify any 153 options. This field MUST be set initialized to zero. No flags are 154 defined at this time. 156 Version 158 The Version field is three bits, and indicates the version number 159 which is associated with the packet received. This field MUST be 160 set to 1 to indicate DIAMETER Version 1. 162 Length 164 The Length field is two octets. It indicates the length of the 165 packet including the header fields. Octets outside the range of the 166 Length field should be treated as padding and should be ignored on 167 receipt. 169 Identifier 171 The Identifier field is four octets, and aids in matching requests 172 and replies. The identifier MUST be unique at any given time and 173 one mechanism to ensure this is to use a monotonically increasing 174 number. Given the size of the Identifier field it is unlikely that 175 2^32 requests could be outstanding at any given time. 177 Attributes 179 See section 6 for more information of attribute formats. 181 3.0 DIAMETER Attributes Format 183 DIAMETER Attributes carry the specific authentication and 184 authorization information as well as configuration details for the 185 request and reply. 187 Some Attributes MAY be listed more than once. The effect of this is 188 Attribute specific, and is specified by each such attribute 189 description. 191 The end of the list of attributes is defined by the length of the 192 DIAMETER packet minus the length of the header. 194 A summary of the attribute format is shown below. The fields are 195 transmitted from left to right. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Attribute Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Flags | Vendor ID (opt) | Value... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Attribute Type 207 The Type field is two octets. RADIUS reserves the lowest 256 208 attribute numbers. Up-to-date values of the RADIUS Type field are 209 specified in the most recent "Assigned Numbers" RFC [2]. 211 DIAMETER will use attribute numbers 257 and above. Vendor Specific 212 attributes reside within this space when the Vendor Specific bit is 213 set (see flags). This will allow up to 65535 vendor-specific 214 attributes (per vendor ID). 216 Length 218 The Length field is two octets, and indicates the length of this 219 Attribute including the Type, Length, Flag, Vendor ID is present 220 and Value fields. If a packet is received with an Invalid attribute 221 length, the packet SHOULD be rejected. 223 Flags 225 The Flags field indicates how DIAMETER devices MUST react to the 226 attribute received. The following values are currently supported: 228 1 - The Device MUST support this attribute. If the attribute 229 is NOT supported, the device MUST reject the Command. 230 If this flag is not set, then the device MAY accept the 231 command regardless of whether or not the particular attribute 232 is recognized. 234 2 - If this bit is set, the contents of the attributes are 235 encrypted. Note that the attribute header is NOT encrypted in 236 this case. See section 3 for more information. 238 NOTE That this bit MUST NOT be turned on if the encryption 239 bit is set in the DIAMETER header which means that all 240 attributes are encrypted. 242 128 - If this bit is set, the optional Vendor ID field will be 243 present. When set, the attribute is a vendor specific 244 attribute 246 Vendor ID 248 Vendor ID is the IANA assigned "SMI Network Management Private 249 Enterprise Codes" value, encoded in network byte order. The value 250 0, reserved in this table, corresponds to IETF adopted Attribute 251 values, defined within this document. Any vendor wishing to 252 implement DIAMETER extensions can use their own Vendor ID along 253 with private Attribute values, guaranteeing that they will not 254 collide with any other vendor's extensions, nor with future IETF 255 extensions. 257 Value 259 The Value field is zero or more octets and contains information 260 specific to the Attribute. The format and length of the Value 261 field is determined by the Type and Length fields. 263 The format of the value field MAY be one of five data types. It is 264 possible for an attribute to have a structure and this MUST be 265 defined along with the attribute. 267 string 0-65526 octets. 269 address 32 bit value, most significant octet first. 271 extended 272 address Address Length is determined from the Length field, most 273 significant octet first. This is required in order to 274 support protocols which require an address length greater 275 than 32 bits (i.e. IPNG). Note that this type is 276 differentiated from the previous type by the value of 277 length. 279 integer 32 bit value, most significant octet first. 281 time 32 bit value, most significant octet first -- seconds 282 since 00:00:00 GMT, January 1, 1970. 284 4.0 Command Meanings 286 4.1 Command AVP 288 Description 290 The Command AVP MUST be the first AVP following the DIAMETER 291 header. This AVP is used in order to communicate the command 292 associated with the message. There MUST only be a single Command 293 AVP within a given message. The format of the AVP is as follows: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Attribute Type | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Flags | Vendor ID (opt) | Value | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Value | 303 +-+-+-+-+-+-+-+-+ 305 Attribute Type 307 256 DIAMETER Command 309 Length 311 The length of this attribute MUST be at least 7. The exact length 312 of the AVP is determined by the actual Command and is defined with 313 each command. 315 Flags 317 The flag field MUST have bit 1 (Mandatory Support) set. Bit 2 318 (Encrypted AVP) SHOULD NOT be set. The optional Vendor ID bit MAY 319 be set if the command is vendor-specific. 321 Value 323 The value field is set to the actual Command (defined later). Note 324 that each extensions draft MAY define a new set of Commands. 326 4.1.1 Command Name and Command Code 328 The following Command types MUST be supported by all DIAMETER 329 implementations in order to conform to the base protocol 330 specification. 332 Command Name: Command-Unrecognized 333 Command Code: 1 335 Command Name: Device-Reboot-Indication 336 Command Code: 2 338 Command Name: Device-Reboot-Ack 339 Command Code: 3 341 Command Name: Device-Feature-Request 342 Command Code: 4 344 Command Name: Device-Feature-Response 345 Command Code: 5 347 4.1.2 Command-Unrecognized 349 Messages with the Command-Unrecognized AVP MUST be sent by a DIAMETER 350 device to inform its peer that a message was received with an 351 unsupported Command AVP value. 353 Since there certainly will exist a case where an existing device does 354 not support a new extension to the DIAMETER protocol, a device which 355 receives a packet with an unrecognized Command code MUST return a 356 Command-Unrecognized packet. 358 A summary of the Command-Unrecognized packet format is shown below. 359 The fields are transmitted from left to right. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Attribute Type | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Flags | Command Type | Value | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Value | 369 +-+-+-+-+-+-+-+-+ 371 Attribute Type 373 256 DIAMETER Command 375 Length 377 The length of this attribute MUST be 9. 379 Flags 381 The flag field MUST have bit 1 (Mandatory Support) set. 383 Command Type 385 The Command Type field MUST be set to 1 (Command-Unrecognized). 387 4.1.3 Device-Reboot-Indication 389 Description 391 The Device-Reboot-Indication message is sent by a DIAMETER device 392 to inform all of its peers that it has rebooted. The peer MUST 393 respond to the message with a successful acknowledgement. Note that 394 a device MUST only send this message once it is ready to receive 395 packets. 397 This message is also used by a DIAMETER device in order to exchange 398 the supported protocol version number as well as all supported 399 extensions. The originator of this message MUST insert it's highest 400 supported version number within the DIAMETER header. The response 401 message MUST include the highest supported version up to and 402 including the version number within the request. 404 Similarly the originator of this message MUST include all supported 405 extensions within the message. The responder MUST include all 406 supported extensions as long as they were present within the 407 request message. 409 In the case where the receiver of this message is a proxy device, 410 it is responsible for inserting the highest version number which it 411 supports in the version field before sending the proxy request to 412 the remote DIAMETER peer. The proxy device may then retain the 413 version number of the remote peers as received in the message, and 414 must insert its highest version number (with the limitations 415 described above) in the response to the initiator. 417 It is desireable for a DIAMETER device to retain the supported 418 extensions as well as the version number in order to ensure that 419 any requests issued to a peer will be processed. 421 This message MAY contain the Version-Number and Vendor-Name AVPs. 423 In the case where a DIAMETER device is configured to communicate 424 with many peers, this message MUST be issued to each peer. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Attribute Type | Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Flags | Command Type | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Attribute Type 436 256 DIAMETER Command 438 Length 440 The length of this attribute MUST be 7. 442 Flags 444 The flag field MUST have bit 1 (Mandatory Support) set. 446 Command Type 448 The Command Type field MUST be set to 2 (Device-Reboot-Indication). 450 4.1.4 Device-Reboot-Ack 452 Description 454 The Device-Reboot-Ack message is sent by a DIAMETER device to 455 acknowledge the receipt of the Device-Reboot-Indication message. 456 The originator of this message MUST include the highest support 457 version number (up to and including the value in the request) in 458 the DIAMETER header as well as all supported extensions (as long as 459 they were present in the requesting message). 461 This message MAY contain the Version-Number and Vendor-Name AVPs. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Attribute Type | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Flags | Command Type | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Attribute Type 473 256 DIAMETER Command 475 Length 477 The length of this attribute MUST be 7. 479 Flags 481 The flag field MUST have bit 1 (Mandatory Support) set. 483 Command Type 485 The Command Type field MUST be set to 3 (Device-Reboot-Ack). 487 4.1.5 Device-Feature-Request 489 Description 491 The Device-Feature-Request message is used in order to request a 492 peer about it's supported extensions. This message MAY contain the 493 Version-Number and Vendor-Name AVPs. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Attribute Type | Length | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Flags | Command Type | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Attribute Type 505 256 DIAMETER Command 507 Length 509 The length of this attribute MUST be 7. 511 Flags 513 The flag field MUST have bit 1 (Mandatory Support) set. 515 Command Type 517 The Command Type field MUST be set to 4 (Device-Feature-Request). 519 4.1.6 Device-Feature-Response 521 Description 523 The Device-Feature-Response message is sent in response to the 524 Device-Feature-Request message. This message includes all supported 525 extensions by the responder and MAY contain the Version-Number and 526 Vendor-Name AVPs. 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 | Command Type | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Attribute Type 538 256 DIAMETER Command 540 Length 542 The length of this attribute MUST be 7. 544 Flags 546 The flag field MUST have bit 1 (Mandatory Support) set. 548 Command Type 550 The Command Type field MUST be set to 5 (Device-Feature-Response). 552 4.2 DIAMETER AVPs 553 This section will define the mandatory AVPs which MUST be supported 554 by all DIAMETER implementations. The following AVPs are defined in 555 this document: 557 Attribute Name: Version-Number 558 Attribute Code: 257 560 Attribute Name: Supported-Extension 561 Attribute Code: 258 563 Attribute Name: Signature 564 Attribute Code: 259 566 Attribute Name: Digital-Signature 567 Attribute Code: 260 569 Attribute Name: Initialization-Vector 570 Attribute Code: 261 572 Attribute Name: Timestamp 573 Attribute Code: 262 575 Attribute Name: Session-Id 576 Attribute Code: 263 578 Attribute Name: X509-Certificate 579 Attribute Code: 264 581 Attribute Name: X509-Certificate-URL 582 Attribute Code: 265 584 Attribute Name: Vendor-Name 585 Attribute Code: 266 587 4.2.1 Version-Number 589 The Version-Number AVP is used in order to indicate the current 590 DIAMETER system version number to a peer. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Attribute Type | Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Flags | Value | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Attribute Type 601 257 Version-Number 603 Length 605 The length of this attribute MUST be 7. 607 Flags 609 The flag field MUST have bit 1 (Mandatory Support) set. 611 Value 613 The value field contains the system version number. 615 4.2.2 Supported-Extension 617 The Supported-Extension AVP is used to inform a peer of the supported 618 extensions. Note that each supported extensions draft MUST have an 619 identifier assigned. The base protocol is not considered an extension 620 since its support is mandatory. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Attribute Type | Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Flags | Value | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Attribute Type 632 258 Supported-Extension 634 Length 636 The length of this attribute MUST be 7. 638 Flags 640 The flag field MUST have bit 1 (Mandatory Support) set. 642 Value 643 The value field contains the extension number. 645 4.2.3 Signature 647 The Signature AVP is used for authentication and integrity. The 648 DIAMETER header as well as all AVPs prior to this AVP is protected by 649 the Signature. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Attribute Type | Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Flags | Value... | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Attribute Type 661 259 Signature 663 Length 665 The length of this attribute MUST be at least 7. 667 Flags 669 The flag field MUST have bit 1 (Mandatory Support) set. 671 Value 673 The value field contains an HMAC-MD5-96[6] of the message up to and 674 including the attribute type field of this AVP. 676 4.2.4 Digital-Signature 678 The Digital-Signature AVP is used for authentication, integrity as 679 well as non-repudiation. The DIAMETER header as well as all AVPs 680 prior to this AVP is protected by the Digital-Signature. 682 Note that for services which use the concept of a proxy server which 683 forwards the request to a next hop server, the proxy server MUST NOT 684 modify any attributes found prior to the Digital-Signature AVP. This 685 ensures that end-to-end security is maintained even through proxy 686 arrangements. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Attribute Type | Length | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Flags | Value... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Attribute Type 698 260 Digital-Signature 700 Length 702 The length of this attribute MUST be 7. 704 Flags 706 The flag field MUST have bit 1 (Mandatory Support) set. 708 Value 710 The value field contains the digital signature of the packet up to 711 and including the attribute type field within this AVP. 713 4.2.5 Initialization-Vector 715 The Initialization-Vector AVP MUST be present prior to the Digital- 716 Signature AVP within a message and is used to ensure randomness 717 within a message. The content of this AVP MUST be a random 128 bit 718 value. 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Attribute Type | Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Flags | Value... | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Attribute Type 729 261 Initialization-Vector 731 Length 733 The length of this attribute MUST be 21. 735 Flags 737 The flag field MUST have bit 1 (Mandatory Support) set. 739 Value 741 The value field contains a random 128 bit value. 743 4.2.6 Timestamp 745 The Timestamp field is used in order to enable replay protection of 746 previous messages. The value of time is the most significant four 747 octets returned from an NTP server which indicates the number of 748 seconds expired since Jan. 1, 1970. 750 This document does not specify the window which an implementation 751 will accept packets, however it is strongly encouraged to make this 752 value user configurable with a reasonable default value (i.e. 4 753 seconds). 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Attribute Type | Length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Flags | Value | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Value | 763 +-+-+-+-+-+-+-+-+ 765 Attribute Type 767 262 Timestamp 769 Length 771 The length of this attribute MUST be 9. 773 Flags 775 The flag field MUST have bit 1 (Mandatory Support) set. 777 Value 779 The value field contains the number of seconds since Jan. 1, 1970 780 when the message was created. 782 4.2.7 Session-Id 784 The Session-Id field is used in order to identify a specific session. 785 All messages pertaining to a specific session MUST include this AVP 786 and the same value MUST be used throughout the life of a session. 788 Note that in some applications there is no concept of a session (i.e. 789 data flow) and this field MAY be used to identify objects other than 790 a session. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Attribute Type | Length | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Flags | Value | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Value | 800 +-+-+-+-+-+-+-+-+ 802 Attribute Type 804 263 Session-Id 806 Length 808 The length of this attribute MUST be 9. 810 Flags 812 The flag field MUST have bit 1 (Mandatory Support) set. 814 Value 815 The value field contains the session identifier assigned to the 816 session. 818 4.2.8 X509-Certificate 820 The X509-Certificate is used in order to send a DIAMETER peer the 821 local system's X.509 certificate chain, which is used in order to 822 validate the Digital-Signature attribute. 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Attribute Type | Length | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Flags | Value... | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Attribute Type 834 264 X509-Certificate 836 Length 838 The length of this attribute MUST be greater than 7. 840 Flags 842 The flag field MUST have bit 1 (Mandatory Support) set. 844 Value 846 The value field contains the X.509 Certificate Chain. 848 4.2.9 X509-Certificate-URL 850 The X509-Certificate-URL is used in order to send a DIAMETER peer a 851 URL to the local system's X.509 certificate chain, which is used in 852 order to validate the Digital-Signature attribute. 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Attribute Type | Length | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Flags | Value... | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Attribute Type 864 265 X509-Certificate-URL 866 Length 868 The length of this attribute MUST be greater than 7. 870 Flags 872 The flag field MUST have bit 1 (Mandatory Support) set. 874 Value 876 The value field contains the X.509 Certificate Chain URL. 878 4.2.10 Vendor-Name 880 The Vendor-Name attribute is used in order to inform a DIAMETER peer 881 of the Vendor of the DIAMETER protocol stack. This MAY be used in 882 order to know which vendor specific attributes may be sent to the 883 peer. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Attribute Type | Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Flags | Value... | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Attribute Type 895 266 Vendor-Name 897 Length 898 The length of this attribute MUST be greater than 7. 900 Flags 902 The flag field MUST have bit 1 (Mandatory Support) set. 904 Value 906 The value field contains the vendor name. 908 5.0 Protocol Definition 910 This section will describe how the base protocol works (or is at 911 least an attempt to). 913 5.1 Digital Signatures 915 In the case of a simple peer to peer relationship the use of IPSEC is 916 sufficient for data integrity and non-repudiation. However there are 917 instances where a peer must communicate with another peer through the 918 use of a proxy server. IPSEC does not provide a mechanism to protect 919 traffic when two peers must use an intermediary node to communicate 920 at the application layer. 922 In these cases the Digital Signature AVP may be used. 924 Note that Digital Signatures only protect the DIAMETER header as well 925 as all AVPs found prior to the digital signature. It is thefore 926 possible to have AVPs following the digital signature and these are 927 considered unprotected. 929 Since some fields within the DIAMETER header will change "en route" 930 towards the final DIAMETER destination, it is necessary to set the 931 mutable fields to zero (0) prior to calculating the signature. The 932 two mutable fields are the identifier and the length. 934 The Timestamp attribute provides replay protection and this AVP MUST 935 be present prior to the Digital Signature AVP. In addition the 936 Initialization Vector AVP MUST also be present prior to the Digital 937 Signature AVP in order to provide some randomness. 939 5.2 Signatures 941 The use of the Signature AVP requires a pre-configured shared secret. 942 Although this mechanism does not scale as well as the Digital 943 Signature, it may be desireable to use this mechanism in the case 944 where asymetric technology is not required. 946 Note that in the case where two DIAMETER nodes need to communicate 947 through an intermediate node (i.e. Proxy) it does not offer any end- 948 to-end data integrity or encryption as each node must re-compute the 949 signature AVP. 951 The Timestamp attribute provides replay protection and this AVP MUST 952 be present prior to the Signature AVP. In addition the Initialization 953 Vector AVP MUST also be present prior to the Signature AVP in order 954 to provide some randomness. 956 6.0 References 958 [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997 959 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 960 USC/Information Sciences Institute, October 1994. 961 [3] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 962 Sciences Institute, August 1980. 963 [4] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 964 MIT Laboratory for Computer Science and RSA Data Security, 965 Inc., RFC 1321, April 1992. 966 [5] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: 967 Private Communications in a Public World", Prentice Hall, 968 March 1995, ISBN 0-13-061466-1. 969 [6] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 970 for Message Authentication", RFC 2104, January 1997. 972 7.0 Author's Address 974 Questions about this memo can be directed to: 976 Pat R. Calhoun 977 Technology Development 978 Sun Microsystems, Inc. 979 15 Network Circle 980 Menlo Park, California, 94025 981 USA 983 Phone: 1-847-548-9587 984 Fax: 1-650-786-6445 985 E-mail: pcalhoun@toast.net 987 Allan C. Rubens 988 Merit Network, Inc. 989 4251 Plymouth Rd. 990 Ann Arbor, MI 48105-2785 991 Phone: 1-734-647-0417 992 E-Mail: acr@merit.edu