idnits 2.17.1 draft-calhoun-diameter-07.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-25) 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 42 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 43 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 2 characters 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 39: '...R extensions and MUST be supported by ...' RFC 2119 keyword, line 104: '...not complete and MUST be used with an ...' RFC 2119 keyword, line 116: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 120: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 123: '... SHOULD This word, or the adjecti...' (156 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 108 == Unused Reference: '3' is defined on line 1877, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1880, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1892, 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 == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-01 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-05 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '10') == Outdated reference: A later version (-01) exists of draft-calhoun-diameter-reliable-00 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-00 -- Possible downref: Normative reference to a draft: ref. '12' Summary: 16 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 Laboratories, Inc. 4 Title: draft-calhoun-diameter-07.txt Allan C. Rubens 5 Date: November 1998 Ascend Communications 7 DIAMETER Base Protocol 9 Status of this Memo 11 Comments should be submitted to the diameter@ipass.com mailing list. 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (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 intended 35 to be flexible enough to allow services to add building blocks (or 36 extensions) to DIAMETER in order to meet their requirements. 38 This draft specifies the message format and transport to be used by 39 all DIAMETER extensions and MUST be supported by all DIAMETER 40 implementations, regardless of the specific underlying service. 42 Table of Contents 44 1.0 Introduction 45 1.1 Definitions 46 1.2 Terminology 47 2.0 Protocol Overview 48 2.1 Header Format 49 2.2 AVP Format 50 2.3 Error Reporting 51 3.0 DIAMETER AVPs 52 3.1 DIAMETER-Command AVP 53 3.1.1 Message-Reject-Ind 54 3.1.2 Device-Reboot-Ind 55 3.1.3 Device-Watchdog-Ind 56 3.2 Host-IP-Address 57 3.3 Host-Name 58 3.4 State 59 3.5 Class 60 3.6 Session-Timeout 61 3.7 Extension-Id 62 3.8 Integrity-Check-Vector 63 3.9 Initialization-Vector 64 3.10 Timestamp 65 3.11 Session-Id 66 3.12 Vendor-Name 67 3.13 Firmware-Revision 68 3.14 Result-Code 69 3.15 Error-Code 70 3.16 Unrecognized-Command-Code 71 3.17 Reboot-Type 72 3.18 Reboot-Time 73 3.19 Failed-AVP-Code 74 3.20 User-Name 75 4.0 Protocol Definition 76 4.1 DIAMETER Bootstrap Message 77 4.2 Keepalive Exchange 78 4.3 Unrecognized Command Support 79 4.4 The art of AVP Tagging 80 4.5 Using the Integrity-Check-Vector 81 4.6 AVP Encryption with Shared Secrets 82 5.0 References 83 6.0 Acknowledgements 84 7.0 Author's Address 86 1.0 Introduction 88 Since the RADIUS protocol is being used today for much more than 89 simple authentication and accounting of dial-up users (i.e. 90 authentication of WWW clients, etc), a more extensible protocol was 91 necessary which could support new services being deployed in the 92 internet and corporate networks. 94 RADIUS in itself is not an extensible protocol largely due to its 95 very limited command and attribute address space. In addition, the 96 RADIUS protocol assumes that there cannot be any unsolicited messages 97 from a server to a client. In order to support new services it is 98 imperative that a server be able to send unsolicited messages to 99 clients on a network, and this is a requirement for any DIAMETER 100 implementation. 102 This document describes the base DIAMETER protocol, which is used as 103 the transport for all DIAMETER extensions. This document in itself is 104 not complete and MUST be used with an accompanying applicability 105 extension document. 107 An example of such a document would be [7] that defines extensions to 108 the base protocol to support user authentication and [XXX] which 109 defines extensions to support accounting. 111 1.1 Definitions 113 In this document, several words are used to signify the requirements 114 of the specification. These words are often capitalized. 116 MUST This word, or the adjective "required", means that the 117 definition is an absolute requirement of the 118 specification. 120 MUST NOT This phrase means that the definition is an absolute 121 prohibition of the specification. 123 SHOULD This word, or the adjective "recommended", means that 124 there may exist valid reasons in particular circumstances 125 to ignore this item, but the full implications must be 126 understood and carefully weighed before choosing a 127 different course. 129 MAY This word, or the adjective "optional", means that this 130 item is one of an allowed set of alternatives. An 131 implementation which does not include this option MUST 132 be prepared to interoperate with another implementation 133 which does include the option. 135 1.2 Terminology 137 AVP 139 The DIAMETER protocol consists of a header followed by objects. 140 Each object is encapsulated in a header known as an Attribute- 141 Value-Pair (AVP). 143 DIAMETER Device 145 A Diameter device is a client or server system that supports the 146 Diameter Base protocol and 0 or more extensions. 148 ICV 150 An Integrity Check Vector (ICV) is a hash of the packet with a 151 shared secret. 153 2.0 Protocol Overview 155 2.1 Header Format 157 The base DIAMETER protocol MAY be transmitted over TCP. The document 158 [11] defines the extensions required to transmit DIAMETER over UDP. 159 The destination port field for DIAMETER is 1812. 161 Each DIAMETER Service Extension (i.e. Mobile IP, ROAMOPS, etc) MUST 162 define the transport layer required. 164 For UDP, when a reply is generated the source and destination ports 165 are reversed. 167 A summary of the DIAMETER data format is shown below. The fields are 168 transmitted from left to right. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | RADIUS PCC | Flags |W| Ver | Packet Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Identifier | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Next Send (Ns) | Next Received (Nr) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | AVPs ... 180 +-+-+-+-+-+-+-+-+-+-+-+-+- 182 RADIUS PCC (Packet Compatibility Code) 184 The RADIUS PCC field is a one octet field which is used for 185 backward compatibility with RADIUS. In order to easily distinguish 186 DIAMETER packets from RADIUS a special value has been reserved and 187 allows an implementation to support both protocols concurrently 188 using the first octet in the header. The RADIUS PCC field MUST be 189 set as follows: 191 254 DIAMETER packet 193 PKT Flags 195 The Packet Flags field is five bits, and is used in order to 196 identify any options. This field MUST be initialized to zero. The 197 following flag may be set: 199 The 'W' bit is set when the Next Send (Ns) and Next Received 200 (Nr) fields are present in the header. This SHOULD be set 201 unless the underlying layer provides reliability (i.e. TCP). 203 Version 205 The Version field is three bits, and indicates the version number 206 which is associated with the packet received. This field MUST be 207 set to 1 to indicate DIAMETER Version 1. 209 Packet Length 211 The Packet Length field is two octets. It indicates the length of 212 the packet including the header fields. For messages received via 213 UDP, octets outside the range of the Length field should be 214 treated as padding and should be ignored upon receipt. 216 Identifier 217 The Identifier field is four octets, and aids in matching requests 218 and replies. The sender MUST ensure that the identifier in a 219 message is locally unique (to the sender) at any given time, and 220 MAY attempt to ensure that the number is unique across reboots. 221 The identifier is normally a monotonically increasing number, but 222 using a random value is also permitted. Given the size of the 223 Identifier field it is unlikely that 2^32 requests could be 224 outstanding at any given time. 226 Next Send 228 This field is defined in [11]. 230 Next Received 232 This field is defined in [11]. 234 AVPs 236 AVPs is a method of encapsulating information relevant to the 237 DIAMETER message. See section 2.2 for more information on AVPs. 239 2.2 AVP Format 241 DIAMETER Attributes carry specific authentication, accounting and 242 authorization information as well as configuration details for the 243 request and reply. 245 Some Attributes MAY be listed more than once. The effect of this is 246 Attribute specific, and is specified in each case by the attribute 247 description. 249 Each AVP MUST be padded to align on a 32 bit boundary. Although this 250 is not problematic for most attribute types, it does require that AVP 251 of string and data type be padded with zeroes accordingly. The 252 Padding size can be calculated using the following formula: 254 if( Length mod 4 != 0 ) 255 padding_size = 4 - ( Length mod 0 ) 256 else 257 padding_size = 0 259 The end of the list of attributes is defined by the length of the 260 DIAMETER packet minus the length of the header. 262 The attribute format is shown below and MUST be sent in network byte 263 order. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | AVP Code | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AVP Length | Reserved |P|T|V|E|H|M| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Vendor ID (opt) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Tag (opt) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Data ... 277 +-+-+-+-+-+-+-+-+ 279 AVP Code 281 The AVP Code field is four octets. The first 256 AVP numbers are 282 reserved for backward RADIUS compatibility. Up-to-date values of 283 the RADIUS Type field are specified in the most recent "Assigned 284 Numbers" RFC [2]. 286 AVP numbers 256 and above are used for DIAMETER. Each service MUST 287 allocate AVP numbers through the IANA. 289 If the Vendor-Specific-AVP flag is set, the AVP Code is allocated 290 from the vendor's private address space. 292 AVP Length 294 The AVP Length field is two octets, and indicates the length of 295 this Attribute including the AVP Code, AVP Length, AVP Flags, 296 Reserved, the Tag and Vendor ID fields if present and the AVP 297 data. If a packet is received with an Invalid attribute length, 298 the packet SHOULD be rejected. 300 Reserved 302 The Reserved field MUST be set to zero (0). 304 AVP Flags 306 The AVP Flags field informs the DIAMETER host how each attribute 307 must be handled. 309 The 'M' Bit, known as the Mandatory bit, indicates whether support 310 of the AVP is required. If an AVP is received with the 'M' bit 311 enabled and the receiver does not support the AVP, the request 312 MUST be rejected. 314 AVPs without the 'M' bit enabled are informational only and a 315 receiver that receives a message with such an AVP that is not 316 supported MAY simply ignore the AVP. 318 When the 'H' bit is enabled it indicates that the AVP data is 319 encrypted using hop-by-hop encryption. See section 4.5 for more 320 information. 322 When the 'E' bit is enabled it indicates that the AVP data is 323 encrypted using end-to-end encryption. See [12] for more 324 information. 326 The 'V' bit, known as the Vendor-Specific bit, indicates whether 327 the optional Vendor ID field is present in the AVP header. When 328 set the AVP Code belongs to the specific vendor code address 329 space. 331 The 'T' bit, known as the Tag bit, is used to group sets of AVPs 332 together. Grouping of AVPs is necessary when more than one AVP is 333 needed to express a condition. 335 The 'P' bit, known as the protected AVP bit, is used to indicate 336 whether the AVP is protected by a Digital Signature AVP. When set, 337 the AVP is protected and the contents cannot be changed by a 338 DIAMETER proxy server. See [12] for more information. 340 Vendor ID 342 The optional four octet Vendor ID field contains the IANA assigned 343 "SMI Network Management Private Enterprise Codes" value, encoded 344 in network byte order. Any vendor wishing to implement DIAMETER 345 extensions can use their own Vendor ID along with private 346 Attribute values, guaranteeing that they will not collide with any 347 other vendor's extensions, nor with future IETF extensions. 349 The value zero, reserved in this protocol, corresponds to IETF 350 adopted Attribute values, defined within this document; zero MUST 351 NOT be used in an AVP. 353 Tag 355 The Tag field is four octet in length and is intended to provide a 356 means of grouping attributes in the same packet which refer to the 357 same tunnel. If the Tag field is unused, the 'T' bit MUST NOT be 358 set.. 360 Data 361 The Data field is zero or more octets and contains information 362 specific to the Attribute. The format and length of the Data field 363 is determined by the AVP Code and AVP Length fields. 365 The format of the value field MAY be one of six data types. It is 366 possible for an attribute to have a structure and this MUST be 367 defined along with the attribute. 369 Data 371 0-65400 octets of arbitrary data. 373 String 375 0-65400 octets of string data using the UTF-8 character set. 377 Address 379 32 bit or 128 bit value, most significant octet first. The 380 length of the attribute is determined by the length. 382 Integer32 384 32 bit value, most significant octet first. 386 Integer64 388 64 bit value, most significant octet first. 390 Time 392 32 bit value, most significant octet first -- seconds since 393 00:00:00 GMT, January 1, 1970. 395 2.3 Error Reporting 397 There are five different types of errors within DIAMETER. The first 398 being where a DIAMETER message is poorly formatted and 399 unrecognizable, indicated below by "Bad Packet". 401 The second case involves receiving a DIAMETER-Command-AVP that is not 402 supported, which is shown below by "Unknown Command". The third case 403 is where an AVP is received, marked mandatory and is unknown by the 404 receiver, which is labeled below as "Unknown AVP". 406 This fourth case involves receiving a message with a known AVP, yet 407 the value is either unknown or illegal, which is shown below as "Bad 408 Value". The last case occurs when an error occurs while processing a 409 specific extension command, which is not related to the packet format 410 and is labeled "Extension Error" below. 412 Error Type Ignore Message Send Extension 413 Message-Reject-Ind Response /w 414 Result-Code 415 Bad Packet X 416 Unknown Command X 417 Unknown AVP X 418 Bad Value X 419 Extension Error X 421 "Ignore Message" indicates that the message is simply dropped. The 422 "Message-Reject-Ind" indicates that a Message-Reject-Ind message MUST 423 be sent to the peer as described in the appropriate section. The 424 "Extension Error w/ Result-Code" indicates that the appropriate 425 Response to the message MUST be sent with the Result-Code or Error- 426 Code AVP set to a value that enables the peer to understand the 427 nature of the problem. 429 3.0 DIAMETER AVPs 431 This section will define the mandatory AVPs that MUST be supported by 432 all DIAMETER implementations. Note the first 256 AVP numbers are 433 reserved for RADIUS compatibility. 435 The following AVPs are defined in this document: 437 Attribute Name Attribute Code 438 ----------------------------------- 439 DIAMETER-Command 256 440 Host-IP-Address 4 441 Host-Name 32 442 State 24 443 Class 25 444 Session-Timeout 27 445 Extension-Id 258 446 Integrity-Check-Vector 259 447 Initialization-Vector 261 448 Timestamp 262 449 Session-Id 263 450 Vendor-Name 266 451 Firmware-Revision 267 452 Result-Code 268 453 Error-Code 269 454 Unrecognized-Command-Code 270 455 Reboot-Type 271 456 Reboot-Time 272 457 Failed-AVP-Code 279 459 3.1 DIAMETER-Command AVP 461 Description 463 The DIAMETER-Command AVP MUST be the first AVP following the 464 DIAMETER header. This AVP is used in order to communicate the 465 command associated with the message. A DIAMETER message can have 466 at most one DIAMETER-Command AVP. The format of the AVP is as 467 follows: 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | AVP Code | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | AVP Length | Reserved |P|T|V|E|H|M| 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Command Code | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 AVP Code 481 256 DIAMETER-Command 483 AVP Length 485 The length of this attribute MUST be at least 12. The exact 486 length of the AVP is determined by the actual Command and is 487 defined with each command. 489 AVP Flags 491 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 492 upon the security model used. The 'V' MAY be set if the Command 493 Code is vendor specific. The 'T' and the 'P' bits MUST NOT be 494 set. 496 Command Code 498 The Command Code field contains the command number. The 499 following commands are defined and MUST be supported by all 500 DIAMETER implementations in order to conform to the base 501 protocol specification: 503 Command Name Command Code 504 ----------------------------------- 505 Message-Reject-Ind 256 506 Device-Reboot-Ind 257 507 Device-Watchdog-Ind 258 509 3.1.1 Message-Reject-Ind (MRI) 511 Description 513 The Message-Reject-Ind command provides a generic means of 514 completing transactions by indicating errors in the messages which 515 initiated them. The Message-Reject-Ind command is a possible 516 response to any DIAMETER command, but some DIAMETER commands MAY 517 expect more specialized error messages, depending on the error 518 type. 520 The Message-Reject-Ind message MUST contain the same 521 identification in the header and include the Session-Id if it was 522 present in the original message that it is responding to, even if 523 the identification is erroneous. The receiver of a Message- 524 Reject-Ind SHOULD examine the Result-Code AVP provided before 525 processing the identification, in order to handle the letter 526 appropriately. 528 Message Format 530 The structure of the Message-Reject message is defined as follows: 532 ::= 533 534 535 [] 536 [] 537 538 [ ] 539 { || 540 } 541 542 543 { || 544 ::= 639 640 641 [] 642 643 [] 644 645 646 647 [] 648 [] 649 650 651 { || 652 ::= 699 700 701 [] 702 703 704 { || 705 1165 It is suggested that the monotonically increasing 32 bit value NOT 1166 start at zero upon reboot, but rather start at a random value. 1167 This will minimize the possibility of overlapping Session-Ids 1168 after a reboot. The optional value is implementation specific but 1169 may include a modem's device Id, a random value, etc. 1171 The session Id is created by the DIAMETER device initiating the 1172 session, which in most cases is done by the client. Note that a 1173 Session-Id can be used by more than one extension. 1175 AVP Format 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | AVP Code | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | AVP Length | Reserved |P|T|V|E|H|M| 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Data ... 1185 +-+-+-+-+-+-+-+-+ 1187 AVP Code 1189 263 Session-Id 1191 AVP Length 1193 The length of this attribute MUST be at least 9. 1195 AVP Flags 1197 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1198 upon the security model used. The 'V', 'T' and the 'P' bits 1199 MUST NOT be set. 1201 Data 1203 The Data field contains the session identifier assigned to the 1204 session. 1206 3.12 Vendor-Name 1208 Description 1210 The Vendor-Name attribute is used in order to inform a DIAMETER 1211 peer of the Vendor Name of the DIAMETER device. This MAY be used 1212 in order to know which vendor specific attributes may be sent to 1213 the peer. 1215 It is also envisioned that the combination of the Vendor-Name and 1216 the Firmware-Revision AVPs can provide very useful debugging 1217 information. 1219 AVP Format 1221 0 1 2 3 1222 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 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | AVP Code | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | AVP Length | Reserved |P|T|V|E|H|M| 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | String ... 1229 +-+-+-+-+-+-+-+-+ 1231 AVP Code 1233 266 Vendor-Name 1235 AVP Length 1237 The length of this attribute MUST be at least 9. 1239 AVP Flags 1241 The 'H' and 'E' MAY be set depending upon the security model 1242 used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set. 1244 String 1246 The String field contains the vendor name. 1248 3.13 Firmware-Revision 1249 Description 1251 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1252 firmware revision of the issuing device. 1254 For devices which do not have a firmware revision (general purpose 1255 computers running DIAMETER software modules, for instance), the 1256 revision of the DIAMETER software module may be reported instead. 1258 AVP Format 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | AVP Code | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | AVP Length | Reserved |P|T|V|E|H|M| 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Integer32 | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 AVP Code 1272 267 Firmware-Revision 1274 AVP Length 1276 The length of this attribute MUST be at least 12. 1278 AVP Flags 1280 The 'H' and 'E' MAY be set depending upon the security model 1281 used. The 'M', 'V', 'T' and the 'P' bits MUST NOT be set. 1283 Integer32 1285 The Integer32 field contains the firmware revision number of 1286 the issuing device. 1288 3.14 Result-Code 1290 Description 1292 The Result-Code AVP is used in order to indicate whether a 1293 particular command was completed successfully or whether an error 1294 occurred. The Result-Code AVP MUST be present in all DIAMETER 1295 messages of type -Request or -Answer. 1297 AVP Format 1299 0 1 2 3 1300 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 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | AVP Code | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | AVP Length | Reserved |P|T|V|E|H|M| 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Integer32 | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 AVP Code 1311 268 Result-Code 1313 AVP Length 1315 The length of this attribute MUST be 12. 1317 AVP Flags 1319 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1320 upon the security model used. The 'V', 'T' and the 'P' bits 1321 MUST NOT be set. 1323 Integer32 1325 The Integer32 field contains the result code associated with 1326 the DIAMETER command. The following codes have been defined: 1328 DIAMETER_SUCCESS 0 1329 The Request was successfully completed. 1331 DIAMETER_FAILURE 1 1332 The Request was not successfully completed for an 1333 unspecified reason. A DIAMETER Message-Reject message 1334 returning this result SHOULD whenever possible also 1335 contain one or more Failed-AVP-Code AVPs indicating the 1336 attributes which caused the failure. 1338 DIAMETER_POOR_REQUEST 2 1339 The Request was poorly constructed. A DIAMETER Message- 1340 Reject message returning this result SHOULD whenever 1341 possible also contain one or more Failed-AVP-Code AVPs 1342 indicating the attributes which caused the failure. 1344 DIAMETER_INVALID_MAC 3 1345 The Request did not contain a valid Integrity-Check- 1346 Vector or Digital-Signature [12]. 1348 DIAMETER_UNKNOWN_SESSION_ID 4 1349 The Request contained an unknown Session-Id. 1351 DIAMETER_SEE_ERROR_CODE 5 1352 The Request failed. The message MUST also contain an 1353 Error-Code AVP which provides command-specific 1354 information on the failure. A DIAMETER Message-Reject- 1355 Ind message returning this result SHOULD whenever 1356 possible also contain one or more Failed-AVP-Code AVPs 1357 indicating the attributes which caused the failure. 1359 DIAMETER_COMMAND_UNSUPPORTED 6 1361 The Request contained a command code which the DIAMETER 1362 implementation does not recognize or does not support. 1363 The Message-Reject-Ind message MUST also contain an 1364 Unrecognized-Command-Code AVP which contains the Command 1365 Code value which was rejected. 1367 DIAMETER_ATTRIBUTE_UNSUPPORTED 8 1369 The Request contained an AVP with an AVP Code which the 1370 DIAMETER implementation does not recognize or does not 1371 support. An DIAMETER Message-Reject-Ind message returning 1372 this result MUST also contain one or more Failed-AVP-Code 1373 AVPs indicating the AVP Codes which caused the failure. 1375 3.15 Error-Code 1377 Description 1379 The Error-Code AVP contains the message specific error code, if 1380 any. This AVP only needs to be present if the Result-Code AVP is 1381 present with the DIAMETER_SEE_ERROR_CODE. 1383 Error-Code values and corresponding semantics are specific to the 1384 command to which the Error-Code is a response, and MUST therefore 1385 be documented as part of the description of that command. 1387 AVP Format 1388 0 1 2 3 1389 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 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | AVP Code | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | AVP Length | Reserved |P|T|V|E|H|M| 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Integer32 | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 AVP Code 1400 269 Error-Code 1402 AVP Length 1404 The length of this attribute MUST be 12. 1406 AVP Flags 1408 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1409 upon the security model used. The 'V', 'T' and the 'P' bits 1410 MUST NOT be set. 1412 Integer32 1414 The Integer32 field contains the error code. 1416 3.16 Unrecognized-Command-Code 1418 Description 1420 The Unrecognized-Command-Code AVP contains the offending Command 1421 Code that resulted in sending the Message-Reject-Ind message. 1423 AVP Format 1425 0 1 2 3 1426 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 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | AVP Code | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | AVP Length | Reserved |P|T|V|E|H|M| 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Integer32 | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 AVP Code 1436 270 Unrecognized-Command-Code 1438 AVP Length 1440 The length of this attribute MUST be 12. 1442 AVP Flags 1444 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1445 upon the security model used. The 'V', 'T' and the 'P' bits 1446 MUST NOT be set. 1448 Integer32 1450 The Integer32 field contains the unrecognized command code that 1451 resulted in sending an Message-Reject-Ind message. 1453 3.17 Reboot-Type 1455 Description 1457 The Reboot-Type AVP MUST be present in the Device-Reboot- 1458 Indication message and contains an indication of the type of 1459 reboot. 1461 AVP Format 1463 0 1 2 3 1464 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 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | AVP Code | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | AVP Length | Reserved |P|T|V|E|H|M| 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Integer32 | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 AVP Code 1475 271 Reboot-Type 1477 AVP Length 1479 The length of this attribute MUST be 12. 1481 AVP Flags 1483 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1484 upon the security model used. The 'V', 'T' and the 'P' bits 1485 MUST NOT be set. 1487 Integer32 1489 The Integer32 field contains the reboot type associated with 1490 the DRI command. The following value are currently defined: 1492 REBOOT_IMMINENT 1 1493 When the Reboot-Type AVP is set to this value it is an 1494 indication that the DIAMETER peer is about to reboot and 1495 should not be sent any additional DIAMETER messages 1496 besides the acknowledgement. 1498 REBOOTED 2 1499 When the Reboot-Type AVP is set to this value it is an 1500 indication that the DIAMETER peer has recently rebooted 1501 and is ready to accept new DIAMETER messages. 1503 CLEAN_REBOOT 3 1504 When the Reboot-Type AVP is set to this value the server 1505 is in the process of shutting down and MAY be available 1506 at some time in the future. 1508 3.18 Reboot-Time 1510 Description 1512 The Reboot-Time AVP MAY be present in the DRI and indicates the 1513 number of seconds before the issuer expects to be ready to receive 1514 new DIAMETER messages. This AVP MUST only be present when the 1515 Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by 1516 this AVP should be used as an estimate and is not a hard rule. 1518 AVP Format 1519 0 1 2 3 1520 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 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | AVP Code | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | AVP Length | Reserved |P|T|V|E|H|M| 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Integer32 | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 AVP Code 1531 272 Reboot-Time 1533 AVP Length 1535 The length of this attribute MUST be 12. 1537 AVP Flags 1539 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1540 upon the security model used. The 'V', 'T' and the 'P' bits 1541 MUST NOT be set. 1543 Integer32 1545 The Integer32 field contains the expected amount of seconds 1546 before the issuer of the DRI expects to be receive to receive 1547 new DIAMETER messages. 1549 3.19 Failed-AVP-Code 1551 Description 1553 The Failed-AVP-Code AVP provides debugging information in cases 1554 where a request is rejected or not fully processed due to 1555 erroneous information in a specific AVP. The documentation of the 1556 Result-Code AVP and of the Message-Reject-Ind command provide 1557 information on the use of the Failed-AVP-Code AVP. This AVP has 1558 the following format: 1560 AVP Format 1561 0 1 2 3 1562 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 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | AVP Code | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | AVP Length | Reserved |P|T|V|E|H|M| 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Data... 1569 +-+-+-+-+-+-+-+-+ 1571 AVP Code 1573 279 Failed-AVP-Code 1575 AVP Length 1577 The length of this attribute MUST be 12. 1579 AVP Flags 1581 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1582 upon the security model used. The 'V', 'T' and the 'P' bits 1583 MUST NOT be set. 1585 Data 1587 The Data field contains the complete AVP that could not be 1588 processed successfully.Possible reasons for this are an 1589 improperly-constructed AVP, an unsupported or unrecognized AVP 1590 Code, or an invalid value. 1592 3.20 User-Name 1594 Description 1596 This attribute contains the User-Name in a format consistent with 1597 the NAI specification [8]. 1599 A summary of the User-Name AVP format is shown below. The fields 1600 are transmitted from left to right. 1602 AVP Format 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | AVP Code | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | AVP Length | Reserved |P|T|V|E|H|M| 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | String ... 1612 +-+-+-+-+-+-+-+-+ 1614 Type 1616 1 for User-Name. 1618 AVP Length 1620 The length of this AVP MUST be at least 9. 1622 AVP Flags 1624 The 'M' bit MUST be set. The 'H' MAY be set, but the 'E' bit 1625 MUST NOT be set since proxy servers would have no knowledge of 1626 the user's domain. The 'V', 'T' and the 'P' bits MUST NOT be 1627 set. 1629 String 1631 The String field is one or more octets. All DIAMETER systems 1632 SHOULD support User-Name lengths of at least 63 octets. The 1633 format of the User-Name SHOULD follow the format defined in 1634 [8]. 1636 4.0 Protocol Definition 1638 This section will describe how the base protocol works (or is at 1639 least an attempt to). 1641 4.1 DIAMETER Bootstrap Message 1643 DIAMETER provides a message that is used to indicate either an 1644 imminent reboot, or that a reboot has occurred. The DRI message MUST 1645 be sent to all known DIAMETER peers both previous to a reboot when 1646 possible as well as following a reboot. 1648 The Reboot-Type AVP is used to indicate the type of reboot associated 1649 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 1650 that any new DIAMETER requests sent to the issuer will probably not 1651 be received or processed. If a request MUST be sent it would be 1652 preferable to issue the request to an alternate peer if available. 1654 The message includes an optional Reboot-Time AVP that specifies an 1655 estimate of how long before the issuer is available to receive new 1656 DIAMETER messages. 1658 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 1659 AVP set to REBOOTED. This is an indication that new DIAMETER messages 1660 may be sent to the transmitter of the DRI. 1662 Note that the Reboot-Time AVP is not required, and when present 1663 provides an estimate and should not be used as a hard value. In the 1664 case of a software implementation (server) running on a general 1665 purpose operating system, the Reboot-Time AVP will probably not be 1666 present since it is possible that the DIAMETER server has been 1667 stopped and it is not possible to know how long before (and if) it 1668 will be restarted. 1670 Upon receipt of this message the peer's Ss and Sr variables must be 1671 reset. It is possible for this message to be received outside the 1672 window (Ns and Nr set to zero) when it follows a reboot. 1674 The DIAMETER Reboot-Ind message does not require a reply. The message 1675 is acknowledged using DIAMETER's reliable transport. 1677 4.2 Keepalive Exchange 1679 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 1680 mechanism. DIAMETER entities that need to ensure that connectivity 1681 with a peer is not lost may use this mechanism. 1683 A DIAMETER Client can use this mechanism to ensure that failover to 1684 an alternate server occurs even without any AAA traffic. Redundant 1685 DIAMETER Servers use this mechanism to identify when the primary 1686 server is no longer available. 1688 The DIAMETER Device-Watchdog-Ind message does not require a reply. 1689 The message is acknowledged using DIAMETER's reliable transport. 1691 4.3 Unrecognized Command Support 1693 The DIAMETER protocol provides a message that is used to inform a 1694 peer that a DIAMETER message was received with an unrecognized 1695 command. The following provides a DIAMETER message that is sent to a 1696 peer: 1698 ::= 1699 1700 1701 [] 1702 1703 1704 { || 1705 ::= 1711 1712 1713 1714 [] 1715 1716 1717 { || 1718 ::= 1766 1767 [] 1768 1769 1770 1772 Any AVPs in a message that is not succeeded by the Integrity-Check- 1773 Vector AVP MUST be ignored. 1775 4.6 AVP Encryption with Shared Secrets 1777 This method of encrypting AVP data is the simplest to use and MUST be 1778 supported by all DIAMETER implementations. However, local policy MAY 1779 determine that the use of this mechanism is not permitted. 1781 The 'H' bit MUST only be set if a shared secret exists between both 1782 DIAMETER peers. If the 'H' bit is set in any DIAMETER AVP, the 1783 Initialization-Vector AVP MUST be present prior to the first 1784 encrypted AVP. 1786 The length of the AVP value to be encrypted is first encoded in the 1787 following Subformat, which is included in the AVP's data field. 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Length of ClearText Data | ClearText Data ... 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Padding ... 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 Length 1799 The Length field contains the length of the decrypted data. 1801 ClearText Data 1803 Data of AVP that is to be obscured. 1805 Padding 1807 Random additional octets used to obscure length of the ClearText 1808 Data. 1810 The resulting subformat MAY be padded to a multiple of 16 octets in 1811 length. For example, if the ClearText Data to be obscured is a string 1812 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1813 octets of padding would be applied. Padding does NOT alter the value 1814 placed in the Length of the ClearText Data, only the length of the 1815 AVP itself. 1817 Next, An MD5 hash is performed on the concatenation of: 1819 - the two octet Command Code of the AVP 1820 - the shared authentication secret 1821 - an arbitrary length random vector 1823 The value of the random vector used in this hash is passed in the 1824 Data field of a Initialization-Vector AVP. This Initialization- 1825 Vector AVP must appear in the message before any hidden AVPs. The 1826 same Initialization-Vector may be used for more than one hidden AVP 1827 in the same message. If a different Initialization-Vector is used 1828 for the hiding of subsequent AVPs then a new Initialization-Vector 1829 AVP must be placed before the first AVP to which it applies. 1831 The MD5 hash value is then XORed with the first 16 octet or less 1832 segment of the AVP Subformat and placed in the Data field of the AVP. 1833 If the AVP Subformat is less than 16 octets, the Subformat is 1834 transformed as if the Value field had been padded to 16 octets before 1835 the XOR, but only the actual octets present in the Subformat are 1836 modified, and the length of the AVP is not altered. 1838 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1839 is calculated over a stream of octets consisting of the shared secret 1840 followed by the result of the first XOR. That hash is XORed with the 1841 second 16 octet or less segment of the Subformat and placed in the 1842 corresponding octets of the Data field of the AVP. 1844 If necessary, this operation is repeated, with each XOR result being 1845 used along with the shared secret to generate the next hash to XOR 1846 the next segment of the value with. This technique results in the 1847 content of the AVP being obscured, although the length of the AVP is 1848 still known. 1850 On receipt, the Initialization-Vector is taken from the last 1851 Initialization-Vector AVP encountered in the message prior to the AVP 1852 to be decrypted. The above process is then reversed to yield the 1853 original value. For more details on this hiding method, consult 1854 RFC2138 [1]. 1856 Please note that in the case where the DIAMETER message needs to be 1857 processed by an intermediate non-trusted DIAMETER server (also known 1858 as a proxy server, depicted as DIA2 in the figure below) the AVP 1859 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 1860 using Shared-Secret-2. 1862 (Shared-Secret-1) (Shared-Secret-2) 1863 +------+ -----> +------+ ------> +------+ 1864 | | | | | | 1865 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1866 | | | | | | 1867 +------+ +------+ +------+ 1869 Unfortunately in this case the non-trusted server DIA2 has access to 1870 sensitive information (such as a password). 1872 5.0 References 1874 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1875 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 1876 October 1994. 1877 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1878 [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 1879 RFC 1321, April 1992. 1880 [5] Kaufman, Perlman, Speciner, "Network Security: Private 1881 Communications in a Public World", Prentice Hall, 1882 March 1995, ISBN 0-13-061466-1. 1883 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1884 Authentication", RFC 2104, January 1997. 1886 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 1887 draft-calhoun-diameter-authen-04.txt, Work in Progress, 1888 August 1998. 1889 [8] Aboba, Beadles, "Network Address Identifier", Internet-Draft, 1890 draft-ietf-roamops-nai-10.txt, Work in Progress, 1891 February 1998. 1892 [9] Calhoun, Zorn, Pan, "DIAMETER Framework", 1893 draft-calhoun-diameter-framework-01.txt, Work in Progress, 1894 August 1998 1895 [10] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for 1896 Tunnel Protocol Support", 1897 draft-ietf-radius-tunnel-auth-05.txt, Work in Progress, 1898 April 1998. 1899 [11] Calhoun, Bulley, "DIAMETER Reliable Transport Extension", 1900 draft-calhoun-diameter-reliable-00.txt, 1901 Work in Progress, August 1998. 1902 [12] Calhoun, Bulley, "DIAMETER Proxy Extension", 1903 draft-calhoun-diameter-proxy-00.txt, Work in Progress, 1904 August 1998. 1906 6.0 Acknowledgements 1908 The Authors would like to acknowledge the following people for their 1909 contribution in the development of the DIAMETER protocol: 1911 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1912 Ignacio Goyret, Nancy Greene, Erik Guttman, Peter Heitman, Fergal 1913 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Nenad Trifunovic, 1914 Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 1916 7.0 Author's Address 1918 Questions about this memo can be directed to: 1920 Pat R. Calhoun 1921 Technology Development 1922 Sun Microsystems, Inc. 1923 15 Network Circle 1924 Menlo Park, California, 94025 1925 USA 1927 Phone: 1-650-786-7733 1928 Fax: 1-650-786-6445 1929 E-mail: pcalhoun@eng.sun.com 1930 Allan C. Rubens 1931 Ascend Communications 1932 1678 Broadway 1933 Ann Arbor, MI 48105-1812 1934 USA 1936 Phone: 1-734-761-6025 1937 E-Mail: acr@del.com