idnits 2.17.1 draft-calhoun-diameter-proxy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 17 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 18 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 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 abstract seems to contain references ([2], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 754 has weird spacing: '... copied and ...' == Line 755 has weird spacing: '...s, and deriv...' == Line 757 has weird spacing: '...blished and d...' == Line 758 has weird spacing: '...hat the above...' == Line 759 has weird spacing: '... and this ...' == (5 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that unless noted, the 'P' bit can be set on any DIAMETER AVP. The Proxy-State AVP MUST not have the 'P' bit set since this AVP will be removed at each hop. Any other AVP that have similar properties (e.g. it will be removed or modified at each hop) MUST NOT have the 'P' bit enabled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 687, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 690, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 692, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 695, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 697, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 699, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 705, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') -- No information found for draft-calhoun-diameter-authen - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '8') -- 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-02 -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '11') ** Obsolete normative reference: RFC 2459 (ref. '12') (Obsoleted by RFC 3280) Summary: 16 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-proxy-04.txt William Bulley 4 Date: October 1999 Merit Network, Inc. 6 DIAMETER 7 Secure Proxying 9 Status of this Memo 11 This document is an individual contribution for consideration by the 12 AAA Working Group of the Internet Engineering Task Force. Comments 13 should be submitted to the diameter@ipass.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The DIAMETER base protocol [2] allows for secure communication 39 between two DIAMETER nodes, and introduces the concept of proxying 40 through the Proxy-State AVP. However, the base protocol only allows 41 for hop-by-hop security, and the work done in the ROAMOPS WG [8] 42 shows that support for end-to-end security through proxies. This 43 document describes the extensions necessary to provide for secure 44 communication through DIAMETER proxies. 46 Table of Contents 48 1.0 Introduction 49 1.1 Copyright Statement 50 1.2 Requirements language 51 1.3 Changes in version -02 52 1.4 Changes in version -03 53 2.0 Extended AVP Format 54 3.0 DIAMETER AVPs 55 3.1 Digital-Signature 56 3.2 X509-Certificate 57 3.3 X509-Certificate-URL 58 3.4 Next-Hop 59 4.0 Protocol Definition 60 4.1 Feature Advertisement/Discovery 61 4.2 DIAMETER Secure Proxying 62 4.3 Data Integrity 63 4.3.1 Using Digital Signatures 64 4.3.1 Using Mixed Data Integrity AVPs 65 4.4 AVP Data Encryption 66 4.4.1 AVP Encryption with Public Keys 67 4.5 Public Key Cryptography Support 68 4.5.1 X509-Certificate 69 4.5.2 X509-Certificate-URL 70 4.5.3 Static Public Key Configuration 71 5.0 IANA Considerations 72 6.0 References 73 7.0 Acknowledgements 74 8.0 Author's Address 75 9.0 Full Copyright Statement 77 1.0 Introduction 79 Many services, including ROAMOPS and MobileIP, have a requirement for 80 DIAMETER Server to proxy a request to another DIAMETER Server. The 81 concept of proxying AAA requests was introduced by RADIUS and has 82 been in use for many years. 84 The DIAMETER base protocol [2] does provide the basic capability for 85 proxying, but only defines hop-by-hop security, which has some known 86 security flaws. Specifically a fraudulent proxy server can modify 87 some portions of an AAA request in order to make the next hop 88 improperly believe that some services were rendered. For example, a 89 DIAMETER Proxy Server could modify an accounting request, such as the 90 number of bytes that a user transfered, and the end system would have 91 no way of determining that this change occured. 93 This specification contains the extensions necessary to DIAMETER to 94 allow for end-to-end AVP integrity and privacy. The document also 95 describes a method that DIAMETER can provide referal services to 96 clients. 98 The Extension number for this draft is two (2). This value is used in 99 the Extension-Id AVP as defined in [2]. 101 1.1 Copyright Statement 103 Copyright (C) The Internet Society 1999. All Rights Reserved. 105 1.2 Requirements language 107 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 108 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 109 described in [13]. 111 1.3 Changes in version -02 113 The following changes were made in version 02 of the document: 115 - New title 117 - A good cleanup of the abstract and the introduction. 119 - Fixed up text in section 3.2 that stated that all AVPs with the 120 'P' disabled were protected. This should have stated enabled. 122 - Added Section 2 which describes the extended AVP Header Format. 124 - Moved the Proxy State AVP to the base protocol. 126 - Changed the description of the Digital-Signature AVP. 128 - The Next-Hop AVP now requires a preceeding Digital-Signature AVP 129 instead of a Host-IP-Address AVP. This change was necessary since 130 the base protocol does not explicitely state that the Host-IP- 131 Address AVP may appear multiple times in a single message. Such a 132 change would be a big departure from the current RADIUS model 133 where the Host-IP-Address contains the IP address of the 134 originator of the message, not the address of intermediate hops. 136 - Fixed various references to sections that were incorrect. 138 - Added clarification about the use of ICV and Digital Signatures 139 within a single message. 141 - Updated the AVP Header flags. 143 - Re-wrote a good portion of section 4.1 ... 145 - ... well, re-wrote a good portion of all everything in section 146 4. 148 - Added a reference to RFC 2459 (x.509 certs) 150 - Added an IANA Considerations section. 152 1.3 Changes in version -03 154 The following changes were made in version 03 of the document: 156 - Removed the DDR and DDA Commands. The new base protocol defines 157 an error message that allows a broker to return a redirect 158 indication. This new method really simplifies the protocol. 160 - Changed the AVP Command Code for Next-Hop from 278 to 290. 162 2.0 Extended AVP Format 164 The DIAMETER Proxy specification introduces a new bit in the AVP 165 flags field of the AVP Header. The following AVP header is used when 166 proxy support is enabled. 168 The attribute format is shown below and MUST be sent in network byte 169 order. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | AVP Code | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | AVP Length | Cmd Flags |Reservd|P|E|T|V|H|M| 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Vendor ID (opt) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Tag (opt) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Data ... 183 +-+-+-+-+-+-+-+-+ 185 Command Flags 187 All Command Codes defined in this spec MUST set all bits in this 188 field to zero (0). 190 AVP Flags 192 The AVP Flags field informs the DIAMETER host how each attribute 193 must be handled. 195 The 'P' bit, known as the protected AVP bit, is used to indicate 196 whether the AVP is protected by a Digital Signature AVP. When set, 197 the AVP is protected and the contents cannot be changed by a 198 DIAMETER proxy server. An AVP MUST NOT have both the 'P' and the 199 'H' bits set simultaneously, since the 'H' bit implies that the 200 AVP will change on a hop-by-hop basis, and the 'P' requires that 201 the AVP NOT change along a proxy chain. 203 Note that unless noted, the 'P' bit can be set on any DIAMETER 204 AVP. The Proxy-State AVP MUST not have the 'P' bit set since this 205 AVP will be removed at each hop. Any other AVP that have similar 206 properties (e.g. it will be removed or modified at each hop) MUST 207 NOT have the 'P' bit enabled. 209 When the 'E' bit is enabled it indicates that the AVP data is 210 encrypted using end-to-end encryption. 212 Note that the User-Name AVP [2] MUST NOT have the 'E' bit set 213 since intermediate proxies require the domain information in order 214 to determine the target proxy. 216 3.0 DIAMETER AVPs 218 This section will define the mandatory AVPs which MUST be supported 219 by all DIAMETER implementations claiming support for this 220 specification. 222 The following AVPs are defined in this document: 224 Attribute Name Attribute Code Definition in Section 225 ------------------------------------------------------------ 226 Digital-Signature 260 3.1 227 X509-Certificate 264 3.2 228 X509-Certificate-URL 265 3.3 229 Next-Hop 290 3.4 231 3.1 Digital-Signature 233 Description 235 The Digital-Signature AVP is used to provide for authentication, 236 integrity and non-repudiation of DIAMETER AVPs. A DIAMETER entity 237 adding AVPs to a message that must be protected by the Digital 238 Signature MUST ensure that they apprear prior to this AVP. Two are 239 two exceptions to this rule. The Integrity-Check-Value AVP, which 240 MUST appear after the Digital-Signature AVP, since it is stripped 241 at each hop. Any AVP that has the 'H' bit set CANNOT be included 242 in the Digital-Signature. Any other AVP that is stripped at each 243 hop (e.g. Proxy-State AVP) also MUST NOT be protected by the 244 Digital-Signature AVP. AVPs are marked as being protected by 245 enabling their 'P' bit. 247 A DIAMETER node adding a Digital-Signature to a message that 248 already has such an AVP MUST sign all of the existing AVP that 249 have the 'P' bit set in addition to the new protected AVPs added. 251 It is imperative that Proxy servers NOT change the order of the 252 AVPs with the 'P' bit set, otherwise the signature verification 253 would fail. Proxy servers also MUST NOT remove, add, or change 254 any AVP that has the 'P' bit set. 256 The Digital Signature also includes the DIAMETER header. However, 257 when computing the signature, it is necessary for the header's 258 length, Ns and Nr fields to be set to zero (0). This is necessary 259 since the message size and windowing information may change from 260 one proxy server to another as AVPs are added and others are 261 deleted. 263 The Digital-Signature is generated in the method described in 264 section 4.4.1. 266 All DIAMETER implementations supporting this extension MUST 267 support this AVP. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 AVP Header (AVP Code = 260) 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Address | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Transform ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Data ... 279 +-+-+-+-+-+-+-+-+ 281 AVP Length 282 The length of this attribute MUST be at least 17. 284 AVP Flags 285 The 'M' bit MUST be set. The 'P', 'V', 'H' and 'T' bits MUST 286 NOT be set. 288 Address 289 The Address field contains the IP address of the DIAMETER host 290 which generated the Digital-Signature. 292 Transform ID 293 The Transform ID field contains a value that identifies the 294 transform that was used to compute the signature. The following 295 values are defined in this document: 297 RSA [9] 1 299 Data 300 The Data field contains the digital signature of the message up 301 to this AVP. 303 3.2 X509-Certificate 305 Description 307 The X509-Certificate [12] is used in order to send a DIAMETER peer 308 the local system's X.509 certificate chain, which is used in order 309 to validate the Digital-Signature attribute. 311 Section 4.6 contains more information about the use of 312 certificates. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 AVP Header (AVP Code = 264) 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Data ... 320 +-+-+-+-+-+-+-+-+ 322 AVP Flags 323 The 'M' bit MUST be set. The 'P' bits MAY be set if end to end 324 message integrity is required. The 'V', 'H' and 'T' bits MUST 325 NOT be set. 327 Data 328 The Data field contains the X.509 Certificate Chain. 330 3.3 X509-Certificate-URL 332 Description 334 The X509-Certificate-URL is used in order to send a DIAMETER peer 335 a URL to the local system's X.509 certificate chain [12], which is 336 used in order to validate the Digital-Signature attribute. 338 Section 4.6 contains more information about the use of 339 certificates. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 AVP Header (AVP Code = 265) 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | String ... 347 +-+-+-+-+-+-+-+-+ 349 AVP Flags 350 The 'M' bit MUST be set. The 'P' bits MAY be set if end to end 351 message integrity is required. The 'V', 'H' and 'T' bits MUST 352 NOT be set. 354 String 355 The String field contains the X.509 Certificate Chain URL. 357 3.4 Next-Hop 359 Description 360 The Next-Hop AVP MUST preceed a Digital-Signature AVP and is used 361 to validate that a message traversed the proxy chain that was 362 intended. A DIAMETER message with the Next-Hop Address being 363 different than the address found in the preceeding Digital- 364 Signature AVP is considered invalid. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 AVP Header (AVP Code = 290) 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 AVP Flags 375 The 'M' bit and 'P' bits MUST be set. The 'V', 'H' and 'T' 376 bits MUST NOT be set. 378 Address 379 This field contains the IP Address of the next DIAMETER Server. 381 4.0 Protocol Definition 383 This section will describe how the base protocol works (or is at 384 least an attempt to). 386 4.1 Feature Advertisement/Discovery 388 As defined in [2], the Reboot-Ind and Device-Feature-Query messages 389 can be used to inform a peer about locally supported DIAMETER 390 Extensions. In order to advertise support of this extension, the 391 Extension-Id AVP must be transmitted with a value of two (2). 393 4.2 DIAMETER Secure Proxying 395 The ROAMOPS specification [11] discusses how RADIUS servers can be 396 arranged in a hierarchical manner, allowing message exchanges across 397 domain boundaries. The specification also describes some security 398 flaws encountered when RADIUS is used in a proxy environment. The 399 DIAMETER extension described in this document introduces end-to-end 400 security, which solves many of the problems encountered when RADIUS 401 is used. 403 (Request) (Request) 404 +------+ -----> +------+ ------> +------+ 405 | | | | | | 406 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 407 | | | | | | 408 +------+ <----- +------+ <------ +------+ 409 (Answer) (Answer) 411 In this example NASB generates a Request that is forwarded to DIA2. 412 The Request contains a Digital-Signature AVP which "protects" all 413 preceeding AVPs bit the 'P' bit set (known as protected AVPs) within 414 the request. All AVPs which may be modified, or removed by 415 intermediate DIAMETRE Proxies MUST NOT have the 'P' bit set. Such 416 AVPs include the Integrity-Check-Value, Proxy-State, etc. Once DIA2 417 receives the request, it MAY validate the signature in the request to 418 ensure that it was originated by NASB. Verification may not be 419 necessary if the signature was added by a DIAMETER node one hop away 420 since the Integrity-Check-Value (or any whatever security mechanism 421 used for hop-by-hop security) may be sufficient. 423 The DIA2 Server SHOULD add the Proxy-State AVP [2], which contains 424 opaque data that MUST be present in the response and is used to 425 identify state information related to the request or response. If a 426 Proxy-State AVP is found in the request, it SHOULD be replaced with a 427 locally generated Proxy-State AVP. This means that the Proxy-State 428 AVP cannot have the 'P' bit set. The Server MAY also add other new 429 AVPs to the request. All new AVPs that are protected by the new 430 Digital-Signature AVP MUST have the 'P' bit set, and MUST preceed the 431 Digital-Signature AVP. The message is then forwarded towards the DIA1 432 server. 434 The use of network level encryption, such as IPSec, cannot be used 435 for end-to-end AVP integrity between NASB and DIA1, since all 436 messages are processed by DIA2. What is needed is an application 437 level security mechanism, which is what the Digital-Signature AVP 438 provides. However, Digital-Signatures may not be necessary if the 439 messages do not traverse proxies, unless non-repudiation is required. 441 This mechanism now provides a method for DIA1 to be able to identify 442 that NAS was the initiator of the request, and that no "critial" AVPs 443 were modified mid-stream by intermediate proxies. Therefore, DIA2 444 cannot modify any protected AVPs (such as duration of a call, number 445 of bytes transfered, etc). This mechanism also provides the 446 application with the integrity, and non-repudiation, information it 447 may need should it deem it necessary to log such information. 449 This extension also provides for end-to-end AVP encryption, by using 450 the peer's public key. However, given that asymetric encryption is 451 very costly, it's use should be minimal. 453 An attack has been identified in this proposal which allows a 454 malicous man in the middle attack as shown in the following diagram. 456 (Request) (Request) (Request) 457 +------+ -----> +------+ -----> +------+ -----> +------+ 458 | | | | | | | | 459 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 460 | | | | | | | | 461 +------+ <----- +------+ <----- +------+ <----- +------+ 462 (Answer) (Answer) (Answer) 464 In this example, DIA3 traps messages generated from DIA2 towards 465 DIA1, removes the AVPs added by DIA2 and inserts its own AVPs 466 (possibly by trying to convince DIA1 to pay DIA3 for the services). 467 This attack can be prevented by supporting a new Next-Hop AVP. In 468 this case when NASB prepares a request it inserts a protected Next- 469 Hop AVP which contains DIA2's identitity. DIA2 also adds a Next-Hop 470 AVP with DIA1 as the next hop. 472 This mechanism ensures that a man in the middle cannot alter the 473 message by overriding the previous hop's additions and signature. 474 DIA1 could easily validate the message's path with the use of the 475 Next-Hop AVPs. 477 4.3 Data Integrity 479 This section will describe how data integrity and non-repudiation is 480 achieved using the Digital-Signature AVP. 482 Note that the Timestamp and Nonce AVPs MUST be present in the message 483 PRIOR to the Digital-Signature AVPs discussed in this section. The 484 Timestamp AVP provides replay protection and the Nonce AVP provides 485 randomness. 487 4.3.1 Using Digital Signatures 489 In the case of a simple peer to peer relationship the use of IPSEC is 490 sufficient for data integrity and confidentiality. However there are 491 instances where a peer must communicate with another peer through the 492 use of a proxy server. IPSEC does not provide a mechanism to protect 493 traffic when two peers must use an intermediary node to communicate 494 at the application layer therefore the Digital-Signature AVP MUST be 495 used. 497 The following diagram shows an example of a router initiating a 498 DIAMETER message to DIA1. Once DIA1 has finished processing the 499 message it adds its signature and forwards the message to the non- 500 trusted DIA2 proxy server. If DIA2 needs to add any protected AVPs it 501 SHOULD add its digital signature before forwarding the message to 502 DIA3. 504 +------+ -----> +------+ -----> +------+ -----> +------+ 505 | | | | | non- | | | 506 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 507 | | | | | DIA2 | | | 508 +------+ <----- +------+ <----- +------+ <----- +------+ 510 Since intermediate DIAMETER proxies may add, or delete unprotected 511 AVPs "en route" towards the final DIAMETER destination, it is 512 necessary for the length, Ns and Nr in the header to be set to zero 513 (0) prior to the signature computation. The fields must be restored 514 once the computation is complete. 516 The following is an example of a message that include end-to-end 517 security: 519 ::= 520 521 [] 522 523 524 525 527 The AVP Header's 'P' bit is used to identify which AVPs are 528 considered protected when applying a digital signature to a DIAMETER 529 message. Protected AVPs cannot be changed "en route" since they are 530 protected by the Digital Signature AVP. All protected AVPs added by a 531 DIAMETER entity MUST appear prior to the new Digital Signature AVP. 533 The Next-Hop AVP indicates the intended recipient of the DIAMETER 534 message. When a DIAMETER message is received with a Next-Hop AVP 535 that does not correspond with the address information with the 536 preceeding Digital-Signature AVP, the message MUST be considered 537 invalid and MUST be rejected. The Next-Hop AVP MUST be protected. 539 The Data field of the Digital-Signature AVP contains the RSA/MD5 540 signature algorithm as defined in [9]. 542 4.3.2 Using Mixed Data Integrity AVPs 543 The previous sections described the Integrity-Check-Value and the 544 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 545 the digital signature offers end to end integrity, it is possible to 546 use both AVPs within a single DIAMETER message. In fact, the use of 547 the ICV and the Digital-Signature is recommended to provide both 548 types of AVP integrity, which is necessary when messages are proxied. 549 In the event that two peers use an underlying integrity mechanism 550 (e.g. IPSec) for hop-by-hop AVP integrity, the ICV AVP is not 551 necessary and should not be used. 553 The following diagram provides an example where DIAMETER Server 1 554 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 555 In this example ICVs are used between DIA1 and DIA2 as well as 556 between DIA2 and DIA3. 558 559 -----------------------------> 560 561 +------+ -----> +------+ -----> +------+ 562 | | | | | | 563 | DIA1 +----------+ DIA2 +----------+ DIA3 | 564 | | | | | | 565 +------+ +------+ +------+ 567 Using the previous diagram, the following message would be sent 568 between DIA1 and DIA2: 570 ::= 571 572 [] 573 574 575 576 DIA2)> 578 The following message would be sent between DIA2 and DIA3: 580 ::= 581 582 [] 583 584 585 586 587 588 DIA3)> 590 Note that in the above example messages the ICV AVP appear after the 591 Digital-Signature AVP. This is necessary since DIA2 above removes the 592 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 593 provide hop-by-hop security while the Digital-Signature provides 594 integrity of the message between DIA1 and DIA3. 596 597 ----------------------------> 598 599 +------+ -----> +------+ -----> +------+ -----> +------+ 600 | | | | | | | | 601 |router+----------+ DIA1 +----------+ DIA2 +----------+ DIA2 | 602 | | | | | | | | 603 +------+ <----- +------+ <----- +------+ <----- +------+ 605 There are cases, such as in remote access, where the device 606 initiating the DIAMETER request does not have the processing power to 607 generate Digital-Signatures as required by the protocol. In such an 608 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 609 which acts as a proxy to relay the request to the final 610 authenticating DIAMETER server (DIA2). It is valid for the first hop 611 server to remove the Integrity-Check-Value AVP inserted by the router 612 and replace it with a Digital-Signature AVP. 614 4.4 AVP Encryption with Public Keys 616 AVP encryption using public keys is much more complex than the 617 previously decribed method, yet it is desirable to use it in cases 618 where the DIAMETER message will be processed by an untrusted 619 intermediate node (proxy). 621 Public Key encryption SHOULD be supported, however it is permissible 622 for a low powered device initiating the DIAMETER message to use 623 shared secret encryption with the first hop (proxy) DIAMETER server, 624 which would decrypt and encrypt using the Public Key method. 626 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 627 is aware of the sender's public key. This information can be relayed 628 in three different methods as described in section 4.6. 630 The AVP is encrypted in the method described in [9]. 632 4.5 Public Key Cryptography Support 634 A DIAMETER peer's public key is required in order to validate a 635 message which includes the the Digital-Signature AVP. There are three 636 possibilities on retrieving public keys: 638 4.5.1 X509-Certificate 640 A message which includes a Digital-Signature MAY include the X509- 641 Certificate AVP. Given the size of a typical certificate, this is 642 very wasteful and in most cases DIAMETER peers would cache such 643 information in order to minimize per message processing overhead. 645 It is however valid for a DIAMETER host to provide its X509- 646 Certificate in certain cases, such as when issuing the Device- 647 Reboot-Indication, or in the Domain-Discovery messages. It is 648 envisioned that the peer would validate and cache the certificate at 649 that time. 651 4.5.2 X509-Certificate-URL 653 The X509-Certificate-URL is a method for a DIAMETER host sending a 654 message that includes the Digital-Signature to provide a pointer to 655 its certificate. 657 Upon receiving such a message a DIAMETER host MAY choose to retrieve 658 the certificate if it is not locally cached. Of course the process of 659 retrieving and validating a certificate is lengthy and will require 660 the initiator of the message to retransmit the request. However once 661 cached the certificate can be used until it expires. 663 4.5.3 Static Public Key Configuration 665 Given that using certificates requires a PKI infrastructure which is 666 very costly, it is also possible to use this technology by locally 667 configuring DIAMETER peers' public keys. 669 Note that in a network involving many DIAMETER proxies this may not 670 scale well. 672 5.0 IANA Considerations 674 The numbers for the Command Code AVPs (section 3) is taken from the 675 numbering space defined for Command Codes in [2]. The numbers for the 676 various AVPs defined in section 4 were taken from the AVP numbering 677 space defined in [2]. The numbering for the AVP and Command Codes 678 MUST NOT conflict with values specified in [2] and other DIAMETER 679 related Internet Drafts. 681 This document also introduces two new bits to the AVP Header, which 682 MUST NOT conflict with the base protocol [2] and any other DIAMETER 683 extension. 685 6.0 References 687 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 688 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 689 draft-calhoun-diameter-08.txt, August 1999. 690 [3] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 691 RFC 1321, April 1992. 692 [4] Kaufman, Perlman, Speciner, "Network Security: Private 693 Communications in a Public World", Prentice Hall, 694 March 1995, ISBN 0-13-061466-1. 695 [5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 696 Authentication", RFC 2104, January 1997. 697 [6] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 698 draft-calhoun-diameter-authen-06.txt, August 1999. 699 [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. 700 January 1999. 701 [8] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", 702 RFC 2477, January 1999. 703 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 704 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 705 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", 706 draft-calhoun-diameter-framework-02.txt, Work in Progress, 707 December 1998. 708 [11] Aboba, Vollbrecht, "Proxy Chaining and Policy Implementation in 709 Roaming", RFC 2607, June 1999. 710 [12] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 711 Infrastructure Certificate and CRL Profile", RFC 2459, 712 January 1999. 713 [13] S. Bradner, "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, March 1997. 716 7.0 Acknowledgements 718 The Authors would like to acknowledge the following people for their 719 contribution in the development of the DIAMETER protocol: 721 Bernard Aboba, Jari Arkko, Daniel C. Fox, Lol Grant, Nancy Greene, 722 Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Allan 723 Rubens, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 725 8.0 Author's Address 727 Questions about this memo can be directed to: 729 Pat R. Calhoun 730 Network and Security Research Center, Sun Labs 731 Sun Microsystems, Inc. 732 15 Network Circle 733 Menlo Park, California, 94025 734 USA 736 Phone: 1-650-786-7733 737 Fax: 1-650-786-6445 738 E-mail: pcalhoun@eng.sun.com 740 William Bulley 741 Merit Network, Inc. 742 4251 Plymouth Road, Suite C 743 Ann Arbor, Michigan, 48105-2785 744 USA 746 Phone: 1-734-764-9993 747 Fax: 1-734-647-3185 748 E-mail: web@merit.edu 750 9.0 Full Copyright Statement 752 Copyright (C) The Internet Society (1999). All Rights Reserved. 754 This document and translations of it may be copied and furnished 755 to others, and derivative works that comment on or otherwise 756 explain it or assist in its implmentation may be prepared, copied, 757 published and distributed, in whole or in part, without 758 restriction of any kind, provided that the above copyright notice 759 and this paragraph are included on all such copies and derivative 760 works. However, this docu- ment itself may not be modified in any 761 way, such as by removing the copyright notice or references to the 762 Internet Society or other Inter- net organizations, except as needed 763 for the purpose of developing Internet standards in which case 764 the procedures for copyrights defined in the Internet Standards 765 process must be followed, or as required to translate it into 766 languages other than English. The limited permis- sions granted 767 above are perpetual and will not be revoked by the Internet 768 Society or its successors or assigns. This document and the 769 information contained herein is provided on an "AS IS" basis and 770 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 771 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 772 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 773 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 774 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."