idnits 2.17.1 draft-calhoun-diameter-03.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-24) 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. == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages 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 4 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 38: '... This draft MUST be supported by all...' RFC 2119 keyword, line 102: '...not complete and MUST be used with an ...' RFC 2119 keyword, line 114: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 118: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 121: '... SHOULD This word, or the adjecti...' (121 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Looks like a reference, but probably isn't: 'XXX' on line 106 == Unused Reference: '3' is defined on line 1635, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1637, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1639, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** 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') -- No information found for draft-calhoun-diameter-authen - is the name correct? -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 -- Unexpected draft version: The latest known version of draft-hoffman-pkcs-rsa-encrypt is -02, but you're referring to -03. (However, the state information for draft-calhoun-diameter-authen is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-hoffman-pkcs-rsa-encrypt (ref. '9') == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 8 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-03.txt Allan C. Rubens 5 Date: May 1998 Ascend Communications 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 19 months. Internet-Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 33 The DIAMETER base protocol is intended to provide a framework for any 34 services which require AAA/Policy support. The protocol is inteded to 35 be flexible enough to allow services to add building blocks to 36 DIAMETER in order to meet their requirements. 38 This draft MUST be supported by all DIAMETER implementations, 39 regardless of the specific underlying service. 41 Table of Contents 43 1.0 Introduction 44 1.1 Definitions 45 1.2 Terminology 46 2.0 Packet Format 47 3.0 DIAMETER AVP Format 48 4.0 DIAMETER AVPs 49 4.1 DIAMETER-Command AVP 50 4.1.1 Command-Unrecognized 51 4.1.2 Device-Reboot-Indication 52 4.1.3 Device-Reboot-Ack 53 4.1.4 Device-Feature-Request 54 4.1.5 Device-Feature-Response 55 4.2 Host-IP-Address 56 4.3 Host-Name 57 4.4 Version-Number 58 4.5 Extension-Id 59 4.6 Integrity-Check-Vector 60 4.7 Digital-Signature 61 4.8 Initialization-Vector 62 4.9 Timestamp 63 4.10 Session-Id 64 4.11 X509-Certificate 65 4.12 X509-Certificate-URL 66 4.13 Vendor-Name 67 4.14 Firmware-Revision 68 4.15 Result-Code 69 5.0 Protocol Definition 70 5.1 DIAMETER Bootstrap Message 71 5.2 Data Integrity 72 5.2.1 Using the Integrity-Check-Vector 73 5.2.2 Using Digital Signatures 74 5.2.3 Using Mixed Data Integrity AVPs 75 5.3 AVP Data Encryption 76 5.3.1 AVP Encryption with Shared Secrets 77 5.3.2 AVP Encryption with Public Keys 78 5.4 Public Key Cryptography Support 79 5.4.1 X509-Certificate 80 5.4.2 X509-Certificate-URL 81 5.4.3 Static Public Key Configuration 82 6.0 References 83 7.0 Acknowledgements 84 8.0 Author's Address 86 1.0 Introduction 87 Since the RADIUS protocol is being used today for much more than 88 simple authentication and accounting of dial-up users (i.e. 89 authentication of WWW clients, etc), a more extensible protocol was 90 necessary which could support new services being deployed in the 91 internet and corporate networks. 93 RADIUS in itself is not an extensible protocol largely due to its 94 very limited command and attribute address space. In addition, the 95 RADIUS protocol assumes that there cannot be any unsolicited messages 96 from a server to a client. In order to support new services it is 97 imperative that a server be able to send unsolicited messages to 98 clients on a network, and this is a requirement for any DIAMETER 99 implementation. 101 This document describes the base DIAMETER protocol. This document in 102 itself is not complete and MUST be used with an accompanying 103 applicability extension document. 105 An example of such a document would be [7] which defines extensions 106 to the base protocol to support user authentication and [XXX] which 107 defines extensions to support accounting. 109 1.1 Definitions 111 In this document, several words are used to signify the requirements 112 of the specification. These words are often capitalized. 114 MUST This word, or the adjective "required", means that the 115 definition is an absolute requirement of the 116 specification. 118 MUST NOT This phrase means that the definition is an absolute 119 prohibition of the specification. 121 SHOULD This word, or the adjective "recommended", means that 122 there may exist valid reasons in particular circumstances 123 to ignore this item, but the full implications must be 124 understood and carefully weighed before choosing a 125 different course. 127 MAY This word, or the adjective "optional", means that this 128 item is one of an allowed set of alternatives. An 129 implementation which does not include this option MUST 130 be prepared to interoperate with another implementation 131 which does include the option. 133 1.2 Terminology 135 AVP 137 The DIAMETER protocol consists of a header followed by objects. 138 Each object is encapsulated in a header known as an Attribute- 139 Value-Pair. 141 DIAMETER Device 143 A Diameter device is a client or server system that supports the 144 Diameter Base protocol and 0 or more extensions. 146 Integrity Check Vector 148 An Integrity Check Vector is a hash of the packet with a shared 149 secret. 151 2.0 DIAMETER Header Format 153 DIAMETER packets MAY be transmitted over UDP or TCP. Each Service 154 Extensions draft SHOULD specify the transport layer. The destination 155 port field for DIAMETER is 1645. 157 For UDP, when a reply is generated the source and destination ports 158 are reversed. 160 A summary of the DIAMETER data format is shown below. The fields are 161 transmitted from left to right. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | RADIUS PCC |PKT Flags| Ver | Packet Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Identifier | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Attributes ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+- 173 RADIUS PCC (Packet Compatibility Code) 175 The RADIUS PCC field is a one octet field which is used for 176 RADIUS backward compatibility. In order to easily distinguish 177 DIAMETER packets from RADIUS a special value has been reserved and 178 allows an implementation to support both protocols concurently 179 using the first octet in the header. The RADIUS PCC field MUST be 180 set as follows: 182 254 DIAMETER packet 184 PKT Flags 186 The Packet Flags field is five bits, and is used in order to 187 identify any options. This field MUST be initialized to zero. No 188 flags are defined at this time. 190 Version 192 The Version field is three bits, and indicates the version number 193 which is associated with the packet received. This field MUST be 194 set to 1 to indicate DIAMETER Version 1. 196 Packet Length 198 The Packet Length field is two octets. It indicates the length of 199 the packet including the header fields. For messages received via 200 UDP, octets outside the range of the Length field should be 201 treated as padding and should be ignored upon receipt. 203 Identifier 205 The Identifier field is four octets, and aids in matching requests 206 and replies. The identifier MUST be unique at any given time and 207 one mechanism to ensure this is to use a monotonically increasing 208 number. Given the size of the Identifier field it is unlikely that 209 2^32 requests could be outstanding at any given time. 211 Attributes 213 See section 3.0 for more information of attribute formats. 215 3.0 DIAMETER AVP Format 217 DIAMETER Attributes carry the specific authentication, accounting and 218 authorization information as well as configuration details for the 219 request and reply. 221 Some Attributes MAY be listed more than once. The effect of this is 222 Attribute specific, and is specified by each such attribute 223 description. 225 Each AVP MUST be padded to align on a 32 bit boundary. Although this 226 is not problematic for most attribute types, it does require that AVP 227 of string and data type be padded accordingly. The Padding size can 228 be deduced using the following formula: 230 padding_size = Length modulus 4 232 The end of the list of attributes is defined by the length of the 233 DIAMETER packet minus the length of the header. 235 A summary of the attribute format is shown below. The fields are 236 transmitted from left to right. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | AVP Code | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | AVP Length | AVP Flags | Reserved | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Vendor ID (opt) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Data... 248 +-+-+-+-+-+-+-+-+ 250 AVP Code 252 The AVP Code field is four octets. The first 256 AVP numbers are 253 reserved for backward RADIUS compatibility. Up-to-date values of 254 the RADIUS Type field are specified in the most recent "Assigned 255 Numbers" RFC [2]. 257 AVP numbers 257 and above are used for DIAMETER. Each service MUST 258 allocate AVP numbers through the IANA. 260 If the Vendor-Specific-AVP flag is set, the AVP Code is allocated 261 from the vendor's private address space. 263 AVP Length 265 The AVP Length field is two octets, and indicates the length of 266 this Attribute including the Address Type, AVP Length, AVP Flags, 267 Reserved, Vendor ID if present and the AVP data. If a packet is 268 received with an Invalid attribute length, the packet SHOULD be 269 rejected. 271 AVP Flags 273 The AVP Flags field informs the DIAMETER host how each attribute 274 must be handled. The following values are currently defined: 276 Mandatory-Support 1 277 The receiver MUST support this attribute. If the attribute 278 is NOT supported, the device MUST reject the Command. If 279 this flag is not set, then the receiver MAY accept the 280 command regardless of whether or not the particular 281 attribute is recognized. 283 SS-Encrypted-Data 2 284 If this bit is set, the contents of the attribute is 285 encrypted. Note that the attribute header is NOT encrypted 286 in this case. See section 5.2 for more information. 288 PK-Encrypted-Data 4 289 If this bit is set, the contents of the attribute is 290 encrypted. Note that the attribute header is NOT encrypted 291 in this case. See section 5.2 for more information. 293 Vendor-Specific-AVP 8 294 If this bit is set, the optional Vendor ID field will be 295 present in the AVP header and the AVP Code MUST be treated 296 accordingly. 298 Reserved 300 The Reserved field MUST be set to zero (0). 302 Vendor ID 304 The optional four octet Vendor ID field contains the the IANA 305 assigned "SMI Network Management Private Enterprise Codes" value, 306 encoded in network byte order. Any vendor wishing to implement 307 DIAMETER extensions can use their own Vendor ID along with private 308 Attribute values, guaranteeing that they will not collide with any 309 other vendor's extensions, nor with future IETF extensions. 311 The value zero, reserved in this protocol, corresponds to IETF 312 adopted Attribute values, defined within this document and MUST 313 NOT be used in an AVP since it is implied with the absence of the 314 Vendor-Specific-AVP bit. 316 Data 318 The Data field is zero or more octets and contains information 319 specific to the Attribute. The format and length of the Data field 320 is determined by the AVP Code and AVP Length fields. 322 The format of the value field MAY be one of six data types. It is 323 possible for an attribute to have a structure and this MUST be 324 defined along with the attribute. 326 Data 328 0-65526 octets of arbitrary data. 330 String 332 0-65526 octets of string data in some agreed upon character 333 set. 335 Address 337 32 bit or 48 bit value, most significant octet first. The 338 length of the attribute is determined by the length. 340 Integer32 342 32 bit value, most significant octet first. 344 Integer64 346 64 bit value, most significant octet first. 348 Time 350 32 bit value, most significant octet first -- seconds since 351 00:00:00 GMT, January 1, 1970. 353 4.0 DIAMETER AVPs 355 This section will define the mandatory AVPs which MUST be supported 356 by all DIAMETER implementations. Note the first 256 AVP numbers are 357 reserved for RADIUS compatibility. 359 The following AVPs are defined in this document: 361 Attribute Name Attribute Code 362 ----------------------------------- 363 DIAMETER-Command 256 364 Host-IP-Address 4 365 Host-Name 32 366 Version-Number 257 367 Extension-Id 258 368 Integrity-Check-Vector 259 369 Digital-Signature 260 370 Initialization-Vector 261 371 Timestamp 262 372 Session-Id 263 373 X509-Certificate 264 374 X509-Certificate-URL 265 375 Vendor-Name 266 376 Firmware-Revision 267 377 Result-Code 268 378 Error-Code 269 379 Next-Hop 270 381 4.1 DIAMETER-Command AVP 383 Description 385 The Command AVP MUST be the first AVP following the DIAMETER 386 header. This AVP is used in order to communicate the command 387 associated with the message. There MUST only be a single Command 388 AVP within a given message. The format of the AVP is as follows: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | AVP Code | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | AVP Length | AVP Flags | Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Command Code | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 AVP Code 402 256 DIAMETER-Command 404 AVP Length 406 The length of this attribute MUST be at least 12. The exact length 407 of the AVP is determined by the actual Command and is defined with 408 each command. 410 AVP Flags 412 The flag field MUST have bit one (Mandatory Support) set. Bit two 413 (SS-Encrypted-Data) and Bit four (PK-Encrypted-Data) SHOULD NOT be 414 set. The optional Vendor-Specific-AVP bit MAY be set if the 415 command is vendor-specific. 417 Reserved 418 The Reserved field MUST be set to zero (0). 420 Command Code 422 The Command Code field contains the command number. The following 423 commands are defined and MUST be supported by all DIAMETER 424 implementations in order to conform to the base protocol 425 specification: 427 Command Name Command Code 428 ----------------------------------- 429 Command-Unrecognized 256 430 Device-Reboot-Indication 257 431 Device-Reboot-Ack 258 432 Device-Feature-Query 259 433 Device-Feature-Response 260 435 4.1.1 Command-Unrecognized 437 Description 439 Messages with the Command-Unrecognized AVP MUST be sent by a 440 DIAMETER device to inform its peer that a message was received 441 with an unsupported Command AVP value. 443 Since there certainly will exist a case where an existing device 444 does not support a new extension to the DIAMETER protocol, a 445 device which receives a packet with an unrecognized Command code 446 MUST return a Command-Unrecognized packet. 448 A summary of the Command-Unrecognized packet format is shown 449 below. The fields are transmitted from left to right. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | AVP Code | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | AVP Length | AVP Flags | Reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Command Code | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Unrecognized Command Code | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 AVP Code 464 256 DIAMETER Command 466 AVP Length 468 The length of this attribute MUST be 16. 470 AVP Flags 472 The flag field MUST have bit one (Mandatory Support) set. 474 Command Code 476 The Command Code field MUST be set to 256 (Command-Unrecognized). 478 Unrecognized Command Code 480 The Unrecognized Command Code field MUST contain the Command Code 481 that resulted in this message. 483 4.1.2 Device-Reboot-Indication 485 Description 487 The Device-Reboot-Indication message is sent by a DIAMETER device 488 to inform all of its peers that it has rebooted. The peer MUST 489 respond to the message with a successful acknowledgement. Note 490 that a device MUST only send this message once it is ready to 491 receive packets. 493 This message is also used by a DIAMETER device in order to 494 exchange the supported protocol version number as well as all 495 supported extensions. The originator of this message MUST insert 496 it's highest supported version number within the DIAMETER header. 497 The response message MUST include the highest supported version up 498 to and including the version number within the request. 500 Similarly the originator of this message MUST include all 501 supported extensions within the message. The responder MUST 502 include all supported extensions as long as they were present 503 within the request message. 505 In the case where the receiver of this message is a proxy device, 506 it is responsible for inserting the highest version number which 507 it supports in the version field before sending the proxy request 508 to the remote DIAMETER peer. The proxy device may then retain the 509 version number of the remote peers as received in the message, and 510 must insert its highest version number (with the limitations 511 described above) in the response to the initiator. 513 It is desireable for a DIAMETER device to retain the supported 514 extensions as well as the version number in order to ensure that 515 any requests issued to a peer will be processed. 517 This message MAY contain the Version-Number, Vendor-Name and 518 Extension-Id AVPs. 520 In the case where a DIAMETER device is configured to communicate 521 with many peers, this message MUST be issued to each peer. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | AVP Code | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | AVP Length | AVP Flags | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Command Code | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 AVP Code 535 256 DIAMETER Command 537 AVP Length 539 The length of this attribute MUST be 12. 541 AVP Flags 543 The flag field MUST have bit one (Mandatory Support) set. 545 Command Code 547 The Command Code field MUST be set to 257 (Device-Reboot- 548 Indication). 550 4.1.3 Device-Reboot-Ack 552 Description 554 The Device-Reboot-Ack message is sent by a DIAMETER device to 555 acknowledge the receipt of the Device-Reboot-Indication message. 556 The originator of this message MUST include the highest support 557 version number (up to and including the value in the request) in 558 the DIAMETER header as well as all supported extensions (as long 559 as they were present in the requesting message). 561 This message MAY contain the Version-Number, Vendor-Name and 562 Extension-Id AVPs. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | AVP Code | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | AVP Length | AVP Flags | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Command Code | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 AVP Code 576 256 DIAMETER Command 578 AVP Length 580 The length of this attribute MUST be 12. 582 AVP Flags 584 The flag field MUST have bit one (Mandatory Support) set. 586 Command Code 588 The Command Code field MUST be set to 258 (Device-Reboot-Ack). 590 4.1.4 Device-Feature-Query 592 Description 594 The Device-Feature-Query message is used in order to query a peer 595 about it's supported extensions. This message MAY contain the 596 Version-Number, Vendor-Name and Extension-Id AVPs. 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | AVP Code | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | AVP Length | AVP Flags | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Command Code | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 AVP Code 610 256 DIAMETER Command 612 AVP Length 614 The length of this attribute MUST be 12. 616 AVP Flags 618 The flag field MUST have bit one (Mandatory Support) set. 620 Command Code 622 The Command Code field MUST be set to 259 (Device-Feature- 623 Request). 625 4.1.5 Device-Feature-Response 627 Description 629 The Device-Feature-Response message is sent in response to the 630 Device-Feature-Query message. This message includes all supported 631 extensions by the responder and MAY contain the Version-Number, 632 Vendor-Name and Extension-Id AVPs. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | AVP Code | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | AVP Length | AVP Flags | Reserved | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Command Code | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 AVP Code 646 256 DIAMETER Command 648 AVP Length 650 The length of this attribute MUST be 12. 652 AVP Flags 654 The flag field MUST have bit one (Mandatory Support) set. 656 Command Code 658 The Command Code field MUST be set to 260 (Device-Feature- 659 Response). 661 4.2 Host-IP-Address 663 Description 665 The Host-IP-Address attribute is used to inform a DIAMETER peer of 666 the sender's identity. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | AVP Code | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | AVP Length | AVP Flags | Reserved | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Address | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 AVP Code 680 4 Host-IP-Address 682 AVP Length 684 The length of this attribute MUST be at least 12. 686 AVP Flags 688 The flag field MUST have bit one (Mandatory Support) set. 690 Address 692 The Address field contains the sender's IP address. 694 4.3 Host-Name 696 Description 697 The Host-Name attribute is used to inform a DIAMETER peer of the 698 sender's identity. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | AVP Code | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | AVP Length | AVP Flags | Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | String ... 708 +-+-+-+-+-+-+-+-+ 710 AVP Code 712 32 Host-Name 714 AVP Length 716 The length of this attribute MUST be at least 9. 718 AVP Flags 720 The flag field MUST have bit one (Mandatory Support) set. 722 String 724 The String field is one or more octets, and should be unique to 725 the DIAMETER host. The Host Name MUST follow the NAI [8] naming 726 conventions. 728 4.4 Version-Number 730 Description 732 The Version-Number AVP is used in order to indicate the current 733 DIAMETER system version number to a peer. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | AVP Code | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | AVP Length | AVP Flags | Reserved | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Integer32 | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 AVP Code 747 257 Version-Number 749 AVP Length 751 The length of this attribute MUST be 12. 753 AVP Flags 755 The flag field MUST have bit one (Mandatory Support) set. 757 Integer32 759 The Integer32 field contains the system's DIAMETER version number. 761 4.5 Extension-Id 763 Description 765 The Extension-Id AVP is used in order to identify a specific 766 DIAMETER extension. This AVP MAY be used in the Device-Reboot-Ind 767 and the Device-Feature-Response command in order to inform the 768 peer what externsions are locally supported. 770 Each DIAMETER extensions draft MUST have a Extension-Id assigned 771 to it by the IANA. The base protocol does not require a 772 Extension-Id since its support is mandatory. 774 There MAY be more than one Extension-Id AVP within a DIAMETER 775 message. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | AVP Code | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | AVP Length | AVP Flags | Reserved | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Integer32 | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 AVP Code 789 258 Extension-Id 791 AVP Length 792 The length of this attribute MUST be 12. 794 AVP Flags 796 The flag field MUST have bit one (Mandatory Support) set. 798 Integer32 800 The Integer32 field contains the extension identifier as defined 801 in the extension's document. 803 4.6 Integrity-Check-Vector 805 Description 807 The Integrity-Check-Vector AVP is used for hop-by-hop 808 authentication and integrity, and is not recommended for use with 809 untrusted proxy servers. 811 The DIAMETER header as well as all AVPs up to and including the 812 AVP Code field of this AVP is protected by the Integrity-Check- 813 Vector. 815 The Integrity-Check-Vector is generated in the method described in 816 section 5.1.1. 818 All DIAMETER implementations MUST support this AVP. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | AVP Code | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | AVP Length | AVP Flags | Reserved | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Data ... 828 +-+-+-+-+-+-+-+-+ 830 AVP Code 832 259 Integrity-Check-Vector 834 AVP Length 836 The length of this attribute MUST be at least 9. 838 AVP Flags 839 The flag field MUST have bit one (Mandatory Support) set. 841 Data 843 The Data field contains an HMAC-MD5-96[6] of the message up to 844 this AVP. 846 4.7 Digital-Signature 848 Description 850 The Digital-Signature AVP is used for authentication, integrity as 851 well as non-repudiation. The DIAMETER header as well as all AVPs 852 up to and including the AVP Code field of this AVP is protected by 853 the Digital-Signature. 855 Note that for services which use the concept of a proxy server 856 which forwards the request to a next hop server, the proxy server 857 MUST NOT modify any attributes found prior to the Digital- 858 Signature AVP. This ensures that end-to-end security is maintained 859 even through proxy arrangements. 861 The Digital-Signature is generated in the method described in 862 section 5.1.2. 864 All DIAMETER implementations SHOULD support this AVP. 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | AVP Code | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | AVP Length | AVP Flags | Reserved | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Address | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Data ... 876 +-+-+-+-+-+-+-+-+ 878 AVP Code 880 260 Digital-Signature 882 AVP Length 884 The length of this attribute MUST be at least 9. 886 AVP Flags 887 The flag field MUST have bit one (Mandatory Support) set. 889 Address 891 The Address field contains the IP address of the DIAMETER host 892 which generated the Digital-Signature. 894 Data 896 The Data field contains the digital signature of the packet up to 897 this AVP. 899 4.8 Initialization-Vector 901 Description 903 The Initialization-Vector AVP MUST be present prior to the 904 Digital- Signature and Integrity-Check-Vector AVPs within a 905 message and is used to ensure randomness within a message. The 906 content of this AVP MUST be a random 128 bit value. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | AVP Code | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | AVP Length | AVP Flags | Reserved | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Data ... 916 +-+-+-+-+-+-+-+-+ 918 AVP Code 920 261 Initialization-Vector 922 AVP Length 924 The length of this attribute MUST be 24. 926 AVP Flags 928 The flag field MUST have bit one (Mandatory Support) set. 930 Data 932 The Data field contains a random 128 bit value. 934 4.9 Timestamp 936 Description 938 The Timestamp field is used in order to enable replay protection 939 of previous messages. The value of time is the most significant 940 four octets returned from an NTP server which indicates the number 941 of seconds expired since Jan. 1, 1970. 943 This document does not specify the window which an implementation 944 will accept packets, however it is strongly encouraged to make 945 this value user configurable with a reasonable default value (i.e. 946 4 seconds). 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | AVP Code | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | AVP Length | AVP Flags | Reserved | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Time | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 AVP Code 960 262 Timestamp 962 AVP Length 964 The length of this attribute MUST be 12. 966 AVP Flags 968 The flag field MUST have bit one (Mandatory Support) set. 970 Time 972 The Time field contains the number of seconds since Jan. 1, 1970 973 when the message was created. 975 4.10 Session-Id 977 Description 979 The Session-Id field is used in order to identify a specific 980 session. All messages pertaining to a specific session MUST 981 include this AVP and the same value MUST be used throughout the 982 life of a session. When present, the Session-Id SHOULD appear 983 immediately following the Command- AVP. 985 Note that in some applications there is no concept of a session 986 (i.e. data flow) and this field MAY be used to identify objects 987 other than a session. 989 The Session-Id MUST be globally unique at any given time since it 990 is used by the server to identify the session (or flow). It is 991 recommended that the format of the AVP be as follow: 993 996 It is suggested that the monotonically increasing 32 bit value NOT 997 start at zero upon reboot, but rather start at a random value. 998 This will minimize the possibility of overlapping Session-Ids 999 after a reboot. The optional value is implementation specific but 1000 may include a modem's device Id, a random value, etc. 1002 The session Id is created by the DIAMETER device initiating the 1003 session. In most cases this is performed by the client. 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | AVP Code | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | AVP Length | AVP Flags | Reserved | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Data ... 1013 +-+-+-+-+-+-+-+-+ 1015 AVP Code 1017 263 Session-Id 1019 AVP Length 1021 The length of this attribute MUST be 12. 1023 AVP Flags 1025 The flag field MUST have bit one (Mandatory Support) set. 1027 Data 1028 The Data field contains the session identifier assigned to the 1029 session. 1031 4.11 X509-Certificate 1033 Description 1035 The X509-Certificate is used in order to send a DIAMETER peer the 1036 local system's X.509 certificate chain, which is used in order to 1037 validate the Digital-Signature attribute. 1039 Section 5.3 contains more information about the use of 1040 certificates. 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | AVP Code | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | AVP Length | AVP Flags | Reserved | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Data ... 1050 +-+-+-+-+-+-+-+-+ 1052 AVP Code 1054 264 X509-Certificate 1056 AVP Length 1058 The length of this attribute MUST be at least 9. 1060 AVP Flags 1062 The flag field MUST have bit one (Mandatory Support) set. 1064 Data 1066 The Data field contains the X.509 Certificate Chain. 1068 4.12 X509-Certificate-URL 1070 Description 1072 The X509-Certificate-URL is used in order to send a DIAMETER peer 1073 a URL to the local system's X.509 certificate chain, which is used 1074 in order to validate the Digital-Signature attribute. 1076 Section 5.3 contains more information about the use of 1077 certificates. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | AVP Code | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | AVP Length | AVP Flags | Reserved | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | String ... 1087 +-+-+-+-+-+-+-+-+ 1089 AVP Code 1091 265 X509-Certificate-URL 1093 AVP Length 1095 The length of this attribute MUST be at least 9. 1097 AVP Flags 1099 The flag field MUST have bit one (Mandatory Support) set. 1101 String 1103 The String field contains the X.509 Certificate Chain URL. 1105 4.13 Vendor-Name 1107 Description 1109 The Vendor-Name attribute is used in order to inform a DIAMETER 1110 peer of the Vendor Name of the DIAMETER device. This MAY be used 1111 in order to know which vendor specific attributes may be sent to 1112 the peer. 1114 It is also envisioned that the combination of the Vendor-Name and 1115 the Firmware-Revision AVPs can provide very useful debugging 1116 information. 1118 0 1 2 3 1119 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 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | AVP Code | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | AVP Length | AVP Flags | Reserved | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | String ... 1126 +-+-+-+-+-+-+-+-+ 1128 AVP Code 1130 266 Vendor-Name 1132 AVP Length 1134 The length of this attribute MUST be at least 9. 1136 AVP Flags 1138 The flag field MUST have bit one (Mandatory Support) set. 1140 String 1142 The String field contains the vendor name. 1144 4.14 Firmware-Revision 1146 Description 1148 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1149 firmware revision of the issuing device. 1151 For devices which do not have a firmware revision (general purpose 1152 computers running DIAMETER software modules, for instance), the 1153 revision of the DIAMETER software module may be reported instead. 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | AVP Code | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | AVP Length | AVP Flags | Reserved | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Integer32 | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 AVP Code 1167 267 Firmware-Revision 1169 AVP Length 1171 The length of this attribute MUST be at least 12. 1173 AVP Flags 1175 The flag field MUST have bit one (Mandatory Support) set. 1177 Integer32 1179 The Integer32 field contains the firmware revision number of the 1180 issuing device. 1182 4.15 Result-Code 1184 Description 1186 The Result-Code AVP is used in order to indicate whether a 1187 particular command was completed successfully or whether an error 1188 occurred. All DIAMETER commands MUST specify whether the Result- 1189 Code AVP MUST be present. 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | AVP Code | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | AVP Length | AVP Flags | Reserved | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Integer32 | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 AVP Code 1203 268 Result-Code 1205 AVP Length 1207 The length of this attribute MUST be at least 12. 1209 AVP Flags 1211 The flag field MUST have bit one (Mandatory Support) set. 1213 Integer32 1215 The Integer32 field contains the result code associated with the 1216 DIAMETER command. The following codes have been defined: 1218 DIAMETER_SUCCESS 0 1219 The Request was successfully completed. 1221 DIAMETER_FAILURE 1 1222 The Request was not successfully completed for an 1223 unspecified reason. 1225 DIAMETER_POOR_REQUEST 2 1226 The Request was poorly constructed. 1228 DIAMETER_INVALID_MAC 3 1229 The Request did not contain a valid Integrity-Check-Vector 1230 or Digital- Signature. 1232 DIAMETER_UNKNOWN_SESSION_ID 4 1233 The Request contained an unknown Session-Id. 1235 DIAMETER_SEE_ERROR_CODE 5 1236 The Request failed. See the Error-Code AVP for more info. 1238 4.15 Error-Code 1240 Description 1242 The Error-Code AVP contains the message specific error code, if 1243 any. This AVP only needs to be present if the Result-Code AVP is 1244 present with the DIAMETER_SEE_ERROR_CODE. 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | AVP Code | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | AVP Length | AVP Flags | Reserved | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Integer32 | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 AVP Code 1258 268 Error-Code 1260 AVP Length 1262 The length of this attribute MUST be at least 12. 1264 AVP Flags 1266 The flag field MUST have bit one (Mandatory Support) set. 1268 Integer32 1270 The Integer32 field contains the error code. 1272 5.0 Protocol Definition 1274 This section will describe how the base protocol works (or is at 1275 least an attempt to). 1277 5.1 DIAMETER Bootstrap Message 1279 DIAMETER provides a message that is used to indicate that a reboot 1280 has occurred. The Device-Reboot-Ind message MUST be sent to all known 1281 DIAMETER Peers following a reboot. The message format is as follow: 1283 ::= 1284 1285 1286 [] 1287 1288 1289 [] 1290 [] 1291 1292 1293 { || 1294 ::= 1300 1301 1302 [] 1303 1304 1305 [] 1306 [] 1307 1308 1309 { || 1310 ::= 1346 1347 [] 1348 1349 1350 1352 5.2.2 Using Digital Signatures 1354 In the case of a simple peer to peer relationship the use of IPSEC is 1355 sufficient for data integrity and non-repudiation. However there are 1356 instances where a peer must communicate with another peer through the 1357 use of a proxy server. IPSEC does not provide a mechanism to protect 1358 traffic when two peers must use an intermediary node to communicate 1359 at the application layer therefore the Digital-Signature AVP MUST be 1360 used. 1362 The following diagram shows an example of a router initiating a 1363 DIAMETER message to DIA1. Once DIA1 has finished processing the 1364 message it adds its signature and forwards the message to the non- 1365 trusted DIA2 proxy server. If DIA2 needs to add or change any 1366 muteable AVPs it SHOULD add its digital signature before forwarding 1367 the message to DIA3. 1369 +------+ -----> +------+ -----> +------+ -----> +------+ 1370 | | | | | non- | | | 1371 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 1372 | | | | | DIA2 | | | 1373 +------+ <----- +------+ <----- +------+ <----- +------+ 1375 Since some fields within the DIAMETER header will change "en route" 1376 towards the final DIAMETER destination, it is necessary to set the 1377 mutable fields to zero (0) prior to calculating the signature. The 1378 two mutable fields are the identifier and the length in the DIAMETER 1379 header. 1381 The following is an example of a message that include end-to-end 1382 security: 1384 ::= 1385 1386 [] 1387 1388 1389 1391 Note that Digital Signatures only protect the DIAMETER header as well 1392 as all AVPs found prior to the digital signature. It is therefore 1393 possible to have AVPs following the digital signature and these are 1394 considered unprotected. 1396 The Data field of the Digital-Signature AVP contains the RSA/MD5 1397 signature algorithm as defined in [9]. 1399 5.2.3 Using Mixed Data Integrity AVPs 1401 The previous sections described the Integrity-Check-Vector and the 1402 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 1403 the digital signature offers end to end integrity, it is possible to 1404 use both AVPs within a single DIAMETER message. 1406 The following diagram provides an example where DIAMETER Server 1 1407 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 1408 In this example ICVs are used between DIA1 and DIA2 as well as 1409 between DIA2 and DIA3. 1411 1412 -----------------------------> 1413 1414 +------+ -----> +------+ -----> +------+ 1415 | | | | | | 1416 | DIA1 +----------+ DIA2 +----------+ DIA3 | 1417 | | | | | | 1418 +------+ +------+ +------+ 1420 Using the previous diagram, the following message would be sent 1421 between DIA1 and DIA2: 1423 ::= 1424 1425 [] 1426 1427 1428 1429 DIA2)> 1431 The following message would be sent between DIA2 and DIA3: 1433 ::= 1434 1435 [] 1436 1437 1438 1439 1440 1441 DIA3)> 1443 Note that in the above example messages the ICV AVP appear after the 1444 Digital-Signature AVP. This is necessary since DIA2 above removes the 1445 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 1446 provide hop-by-hop security while the Digital-Signature provides 1447 integrity of the message between DIA1 and DIA3. 1449 1451 +------+ -----> +------+ -----> +------+ 1452 | | | | | | 1453 |router+----------+ DIA1 +----------+ DIA2 | 1454 | | | | | | 1455 +------+ <----- +------+ <----- +------+ 1457 There are cases, such as in remote access, where the device 1458 initiating the DIAMETER request does not have the processing power to 1459 generate Digital-Signatures as required by the protocol. In such an 1460 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 1461 which acts as a proxy to relay the request to the final 1462 authenticating DIAMETER server (DIA2). It is valid for the first hop 1463 server to remove the Integrity-Check-Vector AVP inserted by the 1464 router and replace it with a Digital-Signature AVP. 1466 5.3 AVP Data Encryption 1468 DIAMETER supports two methods of encrypting AVP data. One is using a 1469 shared secret and the other is used with public keys. 1471 This feature can be used to encrypt sensitive data such as user ID's 1472 and passwords. The Encryption bits MUST NOT be set in the Command 1473 Type or Initialization-Vector AVPs. 1475 5.3.1 AVP Encryption with Shared Secrets 1477 This method of encrypting AVP data is the simplest to use and MUST be 1478 supported by all DIAMETER implementations. However, local policy MAY 1479 determine that the use of this mechanism is not permitted. 1481 The SS-Encrypted-Data bit MUST only be set if a shared secret exists 1482 between both DIAMETER peers. If the SS-Encrypted-Data bit is set in 1483 any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior 1484 to the first encrypted AVP. 1486 The length of the AVP value to be encrypted is first encoded in the 1487 following Subformat: 1489 0 1 2 3 1490 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 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Length of ClearText Data | ClearText Data ... 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Padding ... 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 Length 1499 The Length field contains the length of the decrypted data. 1501 ClearText Data 1503 Data of AVP that is to be obscured. 1505 Padding 1507 Random additional octets used to obscure length of the ClearText 1508 Data. 1510 The resulting subformat MAY be padded to a multiple of 16 octets in 1511 length. For example, if the ClearText Data to be obscured is a string 1512 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1513 octects of padding would be applied. Padding does NOT alter the value 1514 placed in the Length of the ClearText Data, only the length of the 1515 AVP itself. 1517 Next, An MD5 hash is performed on the concatenation of: 1519 - the two octet Command Code of the AVP 1520 - the shared authentication secret 1521 - an arbitrary length random vector 1523 The value of the random vector used in this hash is passed in the 1524 Data field of a Initialization-Vector AVP. This Initialization- 1525 Vector AVP must be placed in the message by the sender before any 1526 hidden AVPs. The same Initialization-Vector may be used for more than 1527 one hidden AVP in the same message. If a different Initialization- 1528 Vector is used for the hiding of subsequent AVPs then a new 1529 Initialization-Vector AVP must be placed before the first AVP to 1530 which it applies. 1532 The MD5 hash value is then XORed with the first 16 octet or less 1533 segment of the AVP Subformat and placed in the Data field of the AVP. 1534 If the AVP Subformat is less than 16 octets, the Subformat is 1535 transformed as if the Value field had been padded to 16 octets before 1536 the XOR, but only the actual octets present in the Subformat are 1537 modified, and the length of the AVP is not altered. 1539 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1540 is calculated over a stream of octets consisting of the shared secret 1541 followed by the result of the first XOR. That hash is XORed with the 1542 second 16 octet or less segment of the Subformat and placed in the 1543 corresponding octets of the Data field of the AVP. 1545 If necessary, this operation is repeated, with each XOR result being 1546 used along with the shared secret to generate the next hash to XOR 1547 the next segment of the value with. This technique results in the 1548 content of the AVP being obscured, although the length of the AVP is 1549 still known. 1551 On receipt, the Initialization-Vector is taken from the last 1552 Initialization-Vector AVP encountered in the message prior to the AVP 1553 to be decrypted. The above process is then reversed to yield the 1554 original value. For more details on this hiding method, consult 1555 RFC2138 [1]. 1557 Please note that in the case where the DIAMETER message needs to be 1558 processed by an intermediate non-trusted DIAMETER server (also known 1559 as a proxy server, depicted as DIA2 in the figure below) the AVP 1560 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 1561 using Shared-Secret-2. 1563 (Shared-Secret-1) (Shared-Secret-2) 1564 +------+ -----> +------+ ------> +------+ 1565 | | | | | | 1566 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1567 | | | | | | 1568 +------+ +------+ +------+ 1570 Unfortunately in this case the non-trusted server DIA2 has access to 1571 sensitive information (such as a password). 1573 5.3.2 AVP Encryption with Public Keys 1575 AVP encryption using public keys is much more complex than the 1576 previously decribed method, yet it is desirable to use it in cases 1577 where the DIAMETER message will be processed by an untrusted 1578 intermediate node (proxy). 1580 Public Key encryption SHOULD be supported, however it is permissible 1581 for a low powered device initiating the DIAMETER message to use 1582 shared secret encryption with the first hop (proxy) DIAMETER server, 1583 which would decrypt and encrypt using the Public Key method. 1585 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 1586 is aware of the sender's public key. This information can be relayed 1587 in three different methods as described in section 5.3. 1589 The AVP is encrypted in the method described in [9]. 1591 5.4 Public Key Cryptography Support 1593 A DIAMETER peer's public key is required in order to validate a 1594 message which includes the the Digital-Signature AVP. There are three 1595 possibilities on retrieving public keys: 1597 5.4.1 X509-Certificate 1599 A message which includes a Digital-Signature MAY include the X509- 1600 Certificate AVP. Given the size of a typical certificate, this is 1601 very wasteful and in most cases DIAMETER peers would cache such 1602 information in order to minimize per packet processing overhead. 1604 It is however valid for a DIAMETER host to provide its X509- 1605 Certificate in certain cases, such as when issuing the Device- 1606 Reboot-Indication. It is envisioned that the peer would validate and 1607 cache the certificate at that time. 1609 5.4.2 X509-Certificate-URL 1611 The X509-Certificate-URL is a method for a DIAMETER host sending a 1612 message that includes the Digital-Signature to provide a pointer to 1613 its certificate. 1615 Upon receiving such a message a DIAMETER host MAY choose to retrieve 1616 the certificate if it is not locally cached. Of course the process of 1617 retrieving and validating a certificate is lengthy and will require 1618 the initiator of the message to retransmit the request. However once 1619 cached the certificate can be used until it expires. 1621 5.4.3 Static Public Key Configuration 1623 Given that using certificates requires a PKI infrastructure which is 1624 very costly, it is also possible to use this technology by locally 1625 configuring DIAMETER peers' public keys. 1627 Note that in a network involving many DIAMETER proxies this may not 1628 scale well. 1630 6.0 References 1632 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1633 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 1634 October 1994. 1635 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1637 [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 1638 RFC 1321, April 1992. 1639 [5] Kaufman, Perlman, Speciner, "Network Security: Private 1640 Communications in a Public World", Prentice Hall, 1641 March 1995, ISBN 0-13-061466-1. 1642 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1643 Authentication", RFC 2104, January 1997. 1644 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 1645 draft-calhoun-diameter-authen-03.txt, May 1998. 1646 [8] Aboba, Beadles, "Network Address Identifier", Internet-Draft, 1647 draft-ietf-roamops-nai-10.txt, February 1998. 1648 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 1649 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 1650 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 1651 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 1653 7.0 Acknowledgements 1655 The Authors would like to acknowledge the following people for their 1656 contribution in the development of the DIAMETER protocol: 1658 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1659 Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth 1660 Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 1662 8.0 Author's Address 1664 Questions about this memo can be directed to: 1666 Pat R. Calhoun 1667 Technology Development 1668 Sun Microsystems, Inc. 1669 15 Network Circle 1670 Menlo Park, California, 94025 1671 USA 1673 Phone: 1-650-786-7733 1674 Fax: 1-650-786-6445 1675 E-mail: pcalhoun@eng.sun.com 1677 Allan C. Rubens 1678 Ascend Communications 1679 1678 Broadway 1680 Ann Arbor, MI 48105-1812 1681 USA 1682 Phone: 1-734-647-0417 1683 E-Mail: acr@del.com