idnits 2.17.1 draft-calhoun-diameter-05.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 38 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 39 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 36: '... This draft MUST be supported by all...' RFC 2119 keyword, line 100: '...not complete and MUST be used with an ...' RFC 2119 keyword, line 112: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 116: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 119: '... SHOULD This word, or the adjecti...' (145 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 104 == Missing Reference: '14' is mentioned on line 1591, but not defined == Unused Reference: '3' is defined on line 1741, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1742, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1744, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1753, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1755, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1757, 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' == 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. '11') == Outdated reference: A later version (-01) exists of draft-calhoun-diameter-reliable-00 -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-00 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 10 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-05.txt Allan C. Rubens 5 Date: July 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 months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The DIAMETER base protocol is intended to provide a framework for any 32 services which require AAA/Policy support. The protocol is inteded to 33 be flexible enough to allow services to add building blocks to 34 DIAMETER in order to meet their requirements. 36 This draft MUST be supported by all DIAMETER implementations, 37 regardless of the specific underlying service. 39 Table of Contents 41 1.0 Introduction 42 1.1 Definitions 43 1.2 Terminology 44 2.0 Protocol Overview 45 2.1 Header Format 46 2.2 AVP Format 47 3.0 DIAMETER AVPs 48 3.1 DIAMETER-Command AVP 49 3.1.1 Unrecognized-Command-Ind 50 3.1.2 Device-Reboot-Ind 51 3.1.3 Device-Watchdog-Ind 52 3.1.6 Device-Config-Req 53 3.1.7 Device-Config-Answer 54 3.2 Host-IP-Address 55 3.3 Host-Name 56 3.4 State 57 3.5 Class 58 3.6 Session-Timeout 59 3.7 Version-Number 60 3.8 Extension-Id 61 3.9 Integrity-Check-Vector 62 3.10 Initialization-Vector 63 3.11 Timestamp 64 3.12 Session-Id 65 3.13 Vendor-Name 66 3.14 Firmware-Revision 67 3.15 Result-Code 68 3.16 Error-Code 69 3.17 Unrecognized-Command-Code 70 3.18 Reboot-Type 71 3.19 Reboot-Time 72 4.0 Protocol Definition 73 4.1 DIAMETER Bootstrap Message 74 4.2 Keepalive Exchange 75 4.3 Unrecognized Command Support 76 4.4 The art of AVP Tagging 77 4.5 Using the Integrity-Check-Vector 78 4.6 AVP Encryption with Shared Secrets 79 5.0 References 80 6.0 Acknowledgements 81 7.0 Author's Address 83 1.0 Introduction 85 Since the RADIUS protocol is being used today for much more than 86 simple authentication and accounting of dial-up users (i.e. 87 authentication of WWW clients, etc), a more extensible protocol was 88 necessary which could support new services being deployed in the 89 internet and corporate networks. 91 RADIUS in itself is not an extensible protocol largely due to its 92 very limited command and attribute address space. In addition, the 93 RADIUS protocol assumes that there cannot be any unsolicited messages 94 from a server to a client. In order to support new services it is 95 imperative that a server be able to send unsolicited messages to 96 clients on a network, and this is a requirement for any DIAMETER 97 implementation. 99 This document describes the base DIAMETER protocol. This document in 100 itself is not complete and MUST be used with an accompanying 101 applicability extension document. 103 An example of such a document would be [7] which defines extensions 104 to the base protocol to support user authentication and [XXX] which 105 defines extensions to support accounting. 107 1.1 Definitions 109 In this document, several words are used to signify the requirements 110 of the specification. These words are often capitalized. 112 MUST This word, or the adjective "required", means that the 113 definition is an absolute requirement of the 114 specification. 116 MUST NOT This phrase means that the definition is an absolute 117 prohibition of the specification. 119 SHOULD This word, or the adjective "recommended", means that 120 there may exist valid reasons in particular circumstances 121 to ignore this item, but the full implications must be 122 understood and carefully weighed before choosing a 123 different course. 125 MAY This word, or the adjective "optional", means that this 126 item is one of an allowed set of alternatives. An 127 implementation which does not include this option MUST 128 be prepared to interoperate with another implementation 129 which does include the option. 131 1.2 Terminology 132 AVP 134 The DIAMETER protocol consists of a header followed by objects. 135 Each object is encapsulated in a header known as an Attribute- 136 Value-Pair (AVP). 138 DIAMETER Device 140 A Diameter device is a client or server system that supports the 141 Diameter Base protocol and 0 or more extensions. 143 ICV 145 An Integrity Check Vector (ICV) is a hash of the packet with a 146 shared secret. 148 2.0 Protocol Overview 150 2.1 Header Format 152 DIAMETER packets MAY be transmitted over UDP or TCP. Each Service 153 Extensions draft SHOULD specify the transport layer. The destination 154 port field for DIAMETER is 1812. 156 For UDP, when a reply is generated the source and destination ports 157 are reversed. 159 A summary of the DIAMETER data format is shown below. The fields are 160 transmitted from left to right. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | RADIUS PCC | Flags |W| Ver | Packet Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Identifier | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Next Send (Ns) | Next Received (Nr) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | AVPs ... 172 +-+-+-+-+-+-+-+-+-+-+-+-+- 174 RADIUS PCC (Packet Compatibility Code) 176 The RADIUS PCC field is a one octet field which is used for 177 RADIUS backward compatibility. In order to easily distinguish 178 DIAMETER packets from RADIUS a special value has been reserved and 179 allows an implementation to support both protocols concurently 180 using the first octet in the header. The RADIUS PCC field MUST be 181 set as follows: 183 254 DIAMETER packet 185 PKT Flags 187 The Packet Flags field is five bits, and is used in order to 188 identify any options. This field MUST be initialized to zero. The 189 following flag may be set: 191 The 'W' bit is set when the Next Send (Ns) and Next Received 192 (Nr) fields are present in the header. This SHOULD be set 193 unless the underlying layer provides reliability (i.e. TCP). 195 Version 197 The Version field is three bits, and indicates the version number 198 which is associated with the packet received. This field MUST be 199 set to 1 to indicate DIAMETER Version 1. 201 Packet Length 203 The Packet Length field is two octets. It indicates the length of 204 the packet including the header fields. For messages received via 205 UDP, octets outside the range of the Length field should be 206 treated as padding and should be ignored upon receipt. 208 Identifier 210 The Identifier field is four octets, and aids in matching requests 211 and replies. The sender MUST ensure that the identifier in a 212 message is locally unique (to the sender) at any given time, and 213 MAY attempt to ensure that the number is unique across reboots. 214 The identifier is normally a monotonically increasing number, but 215 using a random value is also permitted. Given the size of the 216 Identifier field it is unlikely that 2^32 requests could be 217 outstanding at any given time. 219 Next Send 221 This field is defined in [12]. 223 Next Received 225 This field is defined in [12]. 227 AVPs 229 AVPs is a method of encapsulating information relevant to the 230 DIAMETER message. See section 2.2 for more information on AVPs. 232 2.2 AVP Format 234 DIAMETER Attributes carry specific authentication, accounting and 235 authorization information as well as configuration details for the 236 request and reply. 238 Some Attributes MAY be listed more than once. The effect of this is 239 Attribute specific, and is specified in each case by the attribute 240 description. 242 Each AVP MUST be padded to align on a 32 bit boundary. Although this 243 is not problematic for most attribute types, it does require that AVP 244 of string and data type be padded with zeroes accordingly. The 245 Padding size can be calculated using the following formula: 247 if( Length mod 4 != 0 ) 248 padding_size = 4 - ( Length mod 0 ) 249 else 250 padding_size = 0 252 The end of the list of attributes is defined by the length of the 253 DIAMETER packet minus the length of the header. 255 The attribute format is shown below and MUST be sent in network byte 256 order. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | AVP Code | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | AVP Length | Reserved |P|T|V|E|H|M| 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Vendor ID (opt) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Tag (opt) | Data... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 AVP Code 272 The AVP Code field is four octets. The first 256 AVP numbers are 273 reserved for backward RADIUS compatibility. Up-to-date values of 274 the RADIUS Type field are specified in the most recent "Assigned 275 Numbers" RFC [2]. 277 AVP numbers 256 and above are used for DIAMETER. Each service MUST 278 allocate AVP numbers through the IANA. 280 If the Vendor-Specific-AVP flag is set, the AVP Code is allocated 281 from the vendor's private address space. 283 AVP Length 285 The AVP Length field is two octets, and indicates the length of 286 this Attribute including the Address Type, AVP Length, AVP Flags, 287 Reserved, Vendor ID if present and the AVP data. If a packet is 288 received with an Invalid attribute length, the packet SHOULD be 289 rejected. 291 Reserved 293 The Reserved field MUST be set to zero (0). 295 AVP Flags 297 The AVP Flags field informs the DIAMETER host how each attribute 298 must be handled. 300 The 'M' Bit, known as the Mandatory bit, indicates whether support 301 of the AVP is required. If an AVP is received with the 'M' bit 302 enabled and the receiver does not support the AVP, the request 303 MUST be rejected. 305 AVPs without the 'M' bit enabled are informational only and a 306 receiver that receives a message with such an AVP that is not 307 supported MAY simply ignore the AVP. 309 When the 'H' bit is enabled it indicates that the AVP data is 310 encrypted using hop-by-hop encryption. See section 4.5 for more 311 information. 313 When the 'E' bit is enabled it indicates that the AVP data is 314 encrypted using end-to-end encryption. See [13] for more 315 information. 317 The 'V' bit, known as the Vendor-Specific bit, indicates whether 318 the optional Vendor ID field is present in the AVP header. When 319 set the AVP Code belongs to the specific vendor code address 320 space. 322 The 'T' bit, known as the Tag bit, is used to group sets of AVPs 323 together. Grouping of AVPs is necessary when more than one AVP is 324 needed to express a condition. 326 The 'P' bit, known as the protected AVP bit, is used to indicate 327 whether the AVP is protected by a Digital Signature AVP. When set, 328 the AVP is protected and the contents cannot be changed by a 329 DIAMETER proxy server. See [13] for more information. 331 Vendor ID 333 The optional four octet Vendor ID field contains the the IANA 334 assigned "SMI Network Management Private Enterprise Codes" value, 335 encoded in network byte order. Any vendor wishing to implement 336 DIAMETER extensions can use their own Vendor ID along with private 337 Attribute values, guaranteeing that they will not collide with any 338 other vendor's extensions, nor with future IETF extensions. 340 The value zero, reserved in this protocol, corresponds to IETF 341 adopted Attribute values, defined within this document; zero MUST 342 NOT be used in an AVP. 344 Tag 346 The Tag field is two octet in length and is intended to provide a 347 means of grouping attributes in the same packet which refer to the 348 same tunnel. Valid values for this field are 0x01 through 349 0x1FFFFFFF, inclusive. If the Tag field is unused, the 'T' bit 350 MUST NOT be set.. 352 Data 354 The Data field is zero or more octets and contains information 355 specific to the Attribute. The format and length of the Data field 356 is determined by the AVP Code and AVP Length fields. 358 The format of the value field MAY be one of six data types. It is 359 possible for an attribute to have a structure and this MUST be 360 defined along with the attribute. 362 Data 364 0-65526 octets of arbitrary data. 366 String 368 0-65526 octets of string data using the UTF-8 character set. 370 Address 372 32 bit or 48 bit value, most significant octet first. The 373 length of the attribute is determined by the length. 375 Integer32 377 32 bit value, most significant octet first. 379 Integer64 381 64 bit value, most significant octet first. 383 Time 385 32 bit value, most significant octet first -- seconds since 386 00:00:00 GMT, January 1, 1970. 388 3.0 DIAMETER AVPs 390 This section will define the mandatory AVPs which MUST be supported 391 by all DIAMETER implementations. Note the first 256 AVP numbers are 392 reserved for RADIUS compatibility. 394 The following AVPs are defined in this document: 396 Attribute Name Attribute Code 397 ----------------------------------- 398 DIAMETER-Command 256 399 Host-IP-Address 4 400 Host-Name 32 401 State 24 402 Class 25 403 Session-Timeout 27 404 Version-Number 257 405 Extension-Id 258 406 Integrity-Check-Vector 259 407 Initialization-Vector 261 408 Timestamp 262 409 Session-Id 263 410 Vendor-Name 266 411 Firmware-Revision 267 412 Result-Code 268 413 Error-Code 269 414 Unknown-Command-Code 270 415 Reboot-Type 271 416 Reboot-Time 272 418 3.1 DIAMETER-Command AVP 420 Description 422 The Command AVP MUST be the first AVP following the DIAMETER 423 header. This AVP is used in order to communicate the command 424 associated with the message. There MUST only be a single Command 425 AVP within a given message. The format of the AVP is as follows: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | AVP Code | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | AVP Length | Reserved |U|T|V|E|H|M| 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Command Code | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 AVP Code 439 256 DIAMETER-Command 441 AVP Length 443 The length of this attribute MUST be at least 12. The exact length 444 of the AVP is determined by the actual Command and is defined with 445 each command. 447 AVP Flags 449 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon 450 the security model used. The 'V' MAY be set if the Command Code is 451 vendor specific. The 'T' and the 'P' bits MUST NOT be set. 453 Command Code 455 The Command Code field contains the command number. The following 456 commands are defined and MUST be supported by all DIAMETER 457 implementations in order to conform to the base protocol 458 specification: 460 Command Name Command Code 461 ----------------------------------- 462 Command-Unrecognized-Ind 256 463 Device-Reboot-Ind 257 464 Device-Watchdog-Ind 258 466 3.1.1 Command-Unrecognized-Ind (CUI) 468 Description 470 Messages with the Command-Unrecognized AVP MUST be sent by a 471 DIAMETER device to inform its peer that a message was received 472 with an unsupported Command AVP value. 474 Since there certainly will exist a case where an existing device 475 does not support a new extension to the DIAMETER protocol, a 476 device which receives a packet with an unrecognized Command code 477 MUST return a Command-Unrecognized packet. 479 This Command MUST also include the Unknown-Command-Code AVP. 481 A summary of the Command-Unrecognized packet format is shown 482 below. The fields are transmitted from left to right. 484 Message Format 486 ::= 487 488 489 490 [] 491 492 493 { || 494 ::= 582 583 584 [] 585 586 [] 587 588 589 [] 590 [] 591 592 593 { || 594 ::= 643 644 645 [] 646 647 648 { || 649 1142 It is suggested that the monotonically increasing 32 bit value NOT 1143 start at zero upon reboot, but rather start at a random value. 1144 This will minimize the possibility of overlapping Session-Ids 1145 after a reboot. The optional value is implementation specific but 1146 may include a modem's device Id, a random value, etc. 1148 The session Id is created by the DIAMETER device initiating the 1149 session. In most cases this is performed by the client. Note that 1150 a Session-Id can be used by more than one extension. 1152 AVP Format 1154 0 1 2 3 1155 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 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | AVP Code | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | AVP Length | Reserved |U|T|V|E|H|M| 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Data ... 1162 +-+-+-+-+-+-+-+-+ 1164 AVP Code 1166 263 Session-Id 1168 AVP Length 1170 The length of this attribute MUST be at least 9. 1172 AVP Flags 1174 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1175 upon the security model used. The 'V', 'T' and the 'P' bits 1176 MUST NOT be set. 1178 Data 1180 The Data field contains the session identifier assigned to the 1181 session. 1183 3.13 Vendor-Name 1185 Description 1187 The Vendor-Name attribute is used in order to inform a DIAMETER 1188 peer of the Vendor Name of the DIAMETER device. This MAY be used 1189 in order to know which vendor specific attributes may be sent to 1190 the peer. 1192 It is also envisioned that the combination of the Vendor-Name and 1193 the Firmware-Revision AVPs can provide very useful debugging 1194 information. 1196 AVP Format 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | AVP Code | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | AVP Length | Reserved |U|T|V|E|H|M| 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | String ... 1206 +-+-+-+-+-+-+-+-+ 1208 AVP Code 1210 266 Vendor-Name 1212 AVP Length 1214 The length of this attribute MUST be at least 9. 1216 AVP Flags 1218 The 'H' and 'E' MAY be set depending upon the security model 1219 used. The 1221 String 1223 The String field contains the vendor name. 1225 3.14 Firmware-Revision 1227 Description 1229 The Firmware-Revision AVP is used to inform a DIAMETER peer of the 1230 firmware revision of the issuing device. 1232 For devices which do not have a firmware revision (general purpose 1233 computers running DIAMETER software modules, for instance), the 1234 revision of the DIAMETER software module may be reported instead. 1236 AVP Format 1238 0 1 2 3 1239 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 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | AVP Code | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | AVP Length | Reserved |U|T|V|E|H|M| 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Integer32 | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 AVP Code 1250 267 Firmware-Revision 1252 AVP Length 1254 The length of this attribute MUST be at least 12. 1256 AVP Flags 1258 The 'H' and 'E' MAY be set depending upon the security model 1259 used. The 1261 Integer32 1263 The Integer32 field contains the firmware revision number of 1264 the issuing device. 1266 3.15 Result-Code 1268 Description 1270 The Result-Code AVP is used in order to indicate whether a 1271 particular command was completed successfully or whether an error 1272 occurred. All DIAMETER commands MUST specify whether the Result- 1273 Code AVP MUST be present. 1275 AVP Format 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | AVP Code | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | AVP Length | Reserved |U|T|V|E|H|M| 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Integer32 | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 AVP Code 1289 268 Result-Code 1291 AVP Length 1293 The length of this attribute MUST be at least 12. 1295 AVP Flags 1297 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1298 upon the security model used. The 'V', 'T' and the 'P' bits 1299 MUST NOT be set. 1301 Integer32 1303 The Integer32 field contains the result code associated with 1304 the DIAMETER command. The following codes have been defined: 1306 DIAMETER_SUCCESS 0 1307 The Request was successfully completed. 1309 DIAMETER_FAILURE 1 1310 The Request was not successfully completed for an 1311 unspecified reason. 1313 DIAMETER_POOR_REQUEST 2 1314 The Request was poorly constructed. 1316 DIAMETER_INVALID_MAC 3 1317 The Request did not contain a valid Integrity-Check- 1318 Vector or Digital-Signature [13]. 1320 DIAMETER_UNKNOWN_SESSION_ID 4 1321 The Request contained an unknown Session-Id. 1323 DIAMETER_SEE_ERROR_CODE 5 1324 The Request failed. See the Error-Code AVP for more info. 1326 3.16 Error-Code 1328 Description 1330 The Error-Code AVP contains the message specific error code, if 1331 any. This AVP only needs to be present if the Result-Code AVP is 1332 present with the DIAMETER_SEE_ERROR_CODE. 1334 AVP Format 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | AVP Code | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | AVP Length | Reserved |U|T|V|E|H|M| 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Integer32 | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 AVP Code 1348 269 Error-Code 1350 AVP Length 1352 The length of this attribute MUST be at least 12. 1354 AVP Flags 1356 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1357 upon the security model used. The 'V', 'T' and the 'P' bits 1358 MUST NOT be set. 1360 Integer32 1361 The Integer32 field contains the error code. 1363 3.17 Unknown-Command-Code 1365 Description 1367 The Unknown-Command-Code AVP contains the offending Command Code 1368 that resulted in sending the Unrecognized-Command-Code message. 1370 AVP Format 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | AVP Code | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | AVP Length | Reserved |U|T|V|E|H|M| 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Integer32 | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 AVP Code 1384 270 Unknown-Command-Code 1386 AVP Length 1388 The length of this attribute MUST be 12. 1390 AVP Flags 1392 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1393 upon the security model used. The 'V', 'T' and the 'P' bits 1394 MUST NOT be set. 1396 Integer32 1398 The Integer32 field contains the unrecognized command code that 1399 resulted in sending an Unrecognized-Command-Code message. 1401 3.18 Reboot-Type 1403 Description 1405 The Reboot-Type AVP MUST be present in the Device-Reboot- 1406 Indication message and contains an indication of the type of 1407 reboot. 1409 AVP Format 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | AVP Code | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | AVP Length | Reserved |U|T|V|E|H|M| 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Integer32 | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 AVP Code 1423 271 Reboot-Type 1425 AVP Length 1427 The length of this attribute MUST be 12. 1429 AVP Flags 1431 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1432 upon the security model used. The 'V', 'T' and the 'P' bits 1433 MUST NOT be set. 1435 Integer32 1437 The Integer32 field contains the reboot type associated with 1438 the DRI command. The following value are currently defined: 1440 REBOOT_IMMINENT 1 1441 When the Reboot-Type AVP is set to this value it is an 1442 indication that the DIAMETER peer is about to reboot and 1443 should not be sent any additional DIAMETER messages 1444 besides the acknowledgement. 1446 REBOOTED 2 1447 When the Reboot-Type AVP is set to this value it is an 1448 indication that the DIAMETER peer has recently rebooted 1449 and is ready to accept new DIAMETER messages. 1451 CLEAN_REBOOT 3 1452 When the Reboot-Type AVP is set to this value the server 1453 is in the process of shutting down and MAY be available 1454 at some time in the future. 1456 3.19 Reboot-Time 1458 Description 1460 The Reboot-Time AVP MAY be present in the DRI and indicates the 1461 number of seconds before the issuer expects to be ready to receive 1462 new DIAMETER messages. This AVP MUST only be present when the 1463 Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by 1464 this AVP should be used as an estimate and is not a hard rule. 1466 AVP Format 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | AVP Code | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | AVP Length | Reserved |U|T|V|E|H|M| 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Integer32 | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 AVP Code 1480 272 Reboot-Time 1482 AVP Length 1484 The length of this attribute MUST be 12. 1486 AVP Flags 1488 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending 1489 upon the security model used. The 'V', 'T' and the 'P' bits 1490 MUST NOT be set. 1492 Integer32 1494 The Integer32 field contains the expected amount of seconds 1495 before the issuer of the DRI expects to be receive to receive 1496 new DIAMETER messages. 1498 4.0 Protocol Definition 1500 This section will describe how the base protocol works (or is at 1501 least an attempt to). 1503 4.1 DIAMETER Bootstrap Message 1505 DIAMETER provides a message that is used to indicate either an 1506 imminent reboot, or that a reboot has occurred. The DRI message MUST 1507 be sent to all known DIAMETER peers both previous to a reboot when 1508 possible as well as following a reboot. 1510 The Reboot-Type AVP is used to indicate the type of reboot associated 1511 with the DRI. When set to REBOOT_IMMINENT, all peers should be warned 1512 that any new DIAMETER requests sent to the issuer will probably not 1513 be received or processed. If a request MUST be sent it would be 1514 preferable to issue the request to an alternate peer if available. 1516 The message includes an optional Reboot-Time AVP that specifies an 1517 estimate of how long before the issuer is available to receive new 1518 DIAMETER messages. 1520 Upon reboot, the host MUST issue a DRI message with the Reboot-Type 1521 AVP set to REBOOTED. This is an indication that new DIAMETER messages 1522 may be sent to the transmitter of the DRI. 1524 Note that the Reboot-Time AVP is not required, and when present 1525 provides an estimate and should not be used as a hard value. In the 1526 case of a software implementation (server) running on a general 1527 purpose operating system, the Reboot-Time AVP will probably not be 1528 present since it is possible that the DIAMETER server has been 1529 stopped and it is not possible to know how long before (and if) it 1530 will be restarted. 1532 Upon receipt of this message the peer's Ss and Sr variables must be 1533 reset. It is possible for this message to be received outside the 1534 window (Ns and Nr set to zero) when it follows a reboot. 1536 The DIAMETER Reboot-Ind message does not require a reply. The message 1537 is acknowledged using DIAMETER's reliable transport. 1539 4.2 Keepalive Exchange 1541 DIAMETER uses the Device-Watchdog-Ind message as a keepalive 1542 mechanism. DIAMETER entities that need to ensure that connectivity 1543 with a peer is not lost may use this mechanism. 1545 A DIAMETER Client can use this mechanism to ensure that failover to 1546 an alternate server occurs even without any AAA traffic. Redundant 1547 DIAMETER Servers use this mechanism to identify when the primary 1548 server is no longer available. 1550 The DIAMETER Device-Watchdog-Ind message does not require a reply. 1551 The message is acknowledged using DIAMETER's reliable transport. 1553 4.3 Unrecognized Command Support 1555 The DIAMETER protocol provides a message that is used to inform a 1556 peer that a DIAMETER message was received with an unrecognized 1557 command. The following provides a DIAMETER message that is sent to a 1558 peer: 1560 ::= 1561 1562 1563 [] 1564 1565 1566 { || 1567 ::= 1573 1574 1575 1576 [] 1577 1578 1579 { || 1580 ::= 1628 1629 [] 1630 1631 1632 1634 Any AVPs in a message that is not succeeded by the Integrity-Check- 1635 Vector AVP MUST be ignored. 1637 4.6 AVP Encryption with Shared Secrets 1639 This method of encrypting AVP data is the simplest to use and MUST be 1640 supported by all DIAMETER implementations. However, local policy MAY 1641 determine that the use of this mechanism is not permitted. 1643 The SS-Encrypted-Data bit MUST only be set if a shared secret exists 1644 between both DIAMETER peers. If the SS-Encrypted-Data bit is set in 1645 any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior 1646 to the first encrypted AVP. 1648 The length of the AVP value to be encrypted is first encoded in the 1649 following Subformat: 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Length of ClearText Data | ClearText Data ... 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Padding ... 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 Length 1661 The Length field contains the length of the decrypted data. 1663 ClearText Data 1665 Data of AVP that is to be obscured. 1667 Padding 1669 Random additional octets used to obscure length of the ClearText 1670 Data. 1672 The resulting subformat MAY be padded to a multiple of 16 octets in 1673 length. For example, if the ClearText Data to be obscured is a string 1674 containing 6 characters (e.g. password 'foobar'), then 8 + n * 16 1675 octects of padding would be applied. Padding does NOT alter the value 1676 placed in the Length of the ClearText Data, only the length of the 1677 AVP itself. 1679 Next, An MD5 hash is performed on the concatenation of: 1681 - the two octet Command Code of the AVP 1682 - the shared authentication secret 1683 - an arbitrary length random vector 1685 The value of the random vector used in this hash is passed in the 1686 Data field of a Initialization-Vector AVP. This Initialization- 1687 Vector AVP must be placed in the message by the sender before any 1688 hidden AVPs. The same Initialization-Vector may be used for more than 1689 one hidden AVP in the same message. If a different Initialization- 1690 Vector is used for the hiding of subsequent AVPs then a new 1691 Initialization-Vector AVP must be placed before the first AVP to 1692 which it applies. 1694 The MD5 hash value is then XORed with the first 16 octet or less 1695 segment of the AVP Subformat and placed in the Data field of the AVP. 1696 If the AVP Subformat is less than 16 octets, the Subformat is 1697 transformed as if the Value field had been padded to 16 octets before 1698 the XOR, but only the actual octets present in the Subformat are 1699 modified, and the length of the AVP is not altered. 1701 If the Subformat is longer than 16 octets, a second one-way MD5 hash 1702 is calculated over a stream of octets consisting of the shared secret 1703 followed by the result of the first XOR. That hash is XORed with the 1704 second 16 octet or less segment of the Subformat and placed in the 1705 corresponding octets of the Data field of the AVP. 1707 If necessary, this operation is repeated, with each XOR result being 1708 used along with the shared secret to generate the next hash to XOR 1709 the next segment of the value with. This technique results in the 1710 content of the AVP being obscured, although the length of the AVP is 1711 still known. 1713 On receipt, the Initialization-Vector is taken from the last 1714 Initialization-Vector AVP encountered in the message prior to the AVP 1715 to be decrypted. The above process is then reversed to yield the 1716 original value. For more details on this hiding method, consult 1717 RFC2138 [1]. 1719 Please note that in the case where the DIAMETER message needs to be 1720 processed by an intermediate non-trusted DIAMETER server (also known 1721 as a proxy server, depicted as DIA2 in the figure below) the AVP 1722 needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2 1723 using Shared-Secret-2. 1725 (Shared-Secret-1) (Shared-Secret-2) 1726 +------+ -----> +------+ ------> +------+ 1727 | | | | | | 1728 | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | 1729 | | | | | | 1730 +------+ +------+ +------+ 1732 Unfortunately in this case the non-trusted server DIA2 has access to 1733 sensitive information (such as a password). 1735 5.0 References 1737 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 1739 [2] Reynolds, Postel, "Assigned Numbers", RFC 1700, 1740 October 1994. 1741 [3] Postel, "User Datagram Protocol", RFC 768, August 1980. 1742 [4] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 1743 RFC 1321, April 1992. 1744 [5] Kaufman, Perlman, Speciner, "Network Security: Private 1745 Communications in a Public World", Prentice Hall, 1746 March 1995, ISBN 0-13-061466-1. 1747 [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 1748 Authentication", RFC 2104, January 1997. 1749 [7] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 1750 draft-calhoun-diameter-authen-03.txt, May 1998. 1751 [8] Aboba, Beadles, "Network Address Identifier", Internet-Draft, 1752 draft-ietf-roamops-nai-10.txt, February 1998. 1753 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 1754 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 1755 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 1756 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 1757 [11] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for 1758 Tunnel Protocol Support", Internet-Draft, 1759 draft-ietf-radius-tunnel-auth-05.txt, April 1998. 1760 [12] Calhoun, Bulley, "DIAMETER Reliable Transport Extension", 1761 Internet-Draft, draft-calhoun-diameter-reliable-00.txt, 1762 August 1998. 1763 [13] Calhoun, Bulley, "DIAMETER Proxy Extension". Internet- 1764 Draft, draft-calhoun-diameter-proxy-00.txt, August 1998. 1766 6.0 Acknowledgements 1768 The Authors would like to acknowledge the following people for their 1769 contribution in the development of the DIAMETER protocol: 1771 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1772 Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth 1773 Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 1775 7.0 Author's Address 1777 Questions about this memo can be directed to: 1779 Pat R. Calhoun 1780 Technology Development 1781 Sun Microsystems, Inc. 1782 15 Network Circle 1783 Menlo Park, California, 94025 1784 USA 1785 Phone: 1-650-786-7733 1786 Fax: 1-650-786-6445 1787 E-mail: pcalhoun@eng.sun.com 1789 Allan C. Rubens 1790 Ascend Communications 1791 1678 Broadway 1792 Ann Arbor, MI 48105-1812 1793 USA 1795 Phone: 1-734-761-6025 1796 E-Mail: acr@del.com