idnits 2.17.1 draft-calhoun-diameter-proxy-03.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 19 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 20 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 704 has weird spacing: '...ize per packe...' == Line 814 has weird spacing: '... copied and ...' == Line 815 has weird spacing: '...s, and deriv...' == Line 817 has weird spacing: '...blished and d...' == Line 818 has weird spacing: '...hat the above...' == (6 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 748, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 756, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 760, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 766, 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-03.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 message 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. 200 Note that unless noted, the 'P' bit can be set on any DIAMETER 201 AVP. The Proxy-State AVP MUST not have the 'P' bit set since this 202 AVP will be removed at each hop. Any other AVP that have similar 203 properties (e.g. it will be removed or modified at each hop) MUST 204 NOT have the 'P' bit enabled. 206 When the 'E' bit is enabled it indicates that the AVP data is 207 encrypted using end-to-end encryption. 209 Note that the User-Name AVP [2] MUST NOT have the 'E' bit set 210 since intermediate proxies require the domain information in order 211 to determine the target proxy. 213 3.0 DIAMETER AVPs 215 This section will define the mandatory AVPs which MUST be supported 216 by all DIAMETER implementations claiming support for this 217 specification. 219 The following AVPs are defined in this document: 221 Attribute Name Attribute Code 222 ----------------------------------- 223 Digital-Signature 260 224 X509-Certificate 264 225 X509-Certificate-URL 265 226 Next-Hop 290 228 3.1 Digital-Signature 230 Description 231 The Digital-Signature AVP is used to provide for authentication, 232 integrity and non-repudiation of DIAMETER AVPs. A DIAMETER entity 233 adding AVPs to a message that must be protected by the Digital 234 Signature MUST ensure that they apprear prior to this AVP. The 235 only exception being the Integrity-Check-Vector AVP, which MUST 236 appear after the Digital-Signature AVP, since it is stripped at 237 each hop. Any other AVP that is stripped at each hop (e.g. Proxy- 238 State AVP) also MUST NOT be protected by the Digital-Signature 239 AVP. AVPs are marked as being protected by enabling their 'P' bit. 241 A DIAMETER node adding a Digital-Signature to a message that 242 already has such an AVP MUST sign all of the existing AVP that 243 have the 'P' bit set in addition to the new protected AVPs added. 245 It is imperative that Proxy servers NOT change the order of the 246 AVPs with the 'P' bit set, otherwise the signature verification 247 would fail. Proxy servers also MUST NOT remove, add, or change 248 any AVP that has the 'P' bit set. 250 The Digital Signature also includes the DIAMETER header. However, 251 when computing the signature, it is necessary for the header's 252 length field to be set to zero (0). This is necessary since the 253 message size may change from one proxy server to another as AVPs 254 are added and others are deleted. 256 The Digital-Signature is generated in the method described in 257 section 4.4.1. 259 All DIAMETER implementations supporting this extension MUST 260 support this AVP. 262 AVP Format 264 A summary of the Digital-Signature AVP format is shown below. The 265 fields are transmitted from left to right. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AVP Code | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AVP Length | Reserved |P|E|T|V|H|M| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Address | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Transform ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Data ... 279 +-+-+-+-+-+-+-+-+ 281 AVP Code 283 260 Digital-Signature 285 AVP Length 287 The length of this attribute MUST be at least 17. 289 AVP Flags 291 The 'M' bit MUST be set. The 'P', 'V', 'H' and 'T' bits MUST 292 NOT be set. 294 Address 296 The Address field contains the IP address of the DIAMETER host 297 which generated the Digital-Signature. 299 Transform ID 301 The Transform ID field contains a value that identifies the 302 transform that was used to compute the signature. The following 303 values are defined in this document: 305 RSA [9] 1 307 Data 309 The Data field contains the digital signature of the packet up 310 to this AVP. 312 3.2 X509-Certificate 313 Description 315 The X509-Certificate [12] is used in order to send a DIAMETER peer 316 the local system's X.509 certificate chain, which is used in order 317 to validate the Digital-Signature attribute. 319 Section 4.6 contains more information about the use of 320 certificates. 322 AVP Format 324 A summary of the X509-Certificate AVP format is shown below. The 325 fields are transmitted from left to right. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | AVP Code | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | AVP Length | Reserved |P|E|T|V|H|M| 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Data ... 335 +-+-+-+-+-+-+-+-+ 337 AVP Code 339 264 X509-Certificate 341 AVP Length 343 The length of this attribute MUST be at least 9. 345 AVP Flags 347 The 'M' bit MUST be set. The 'P' bits MAY be set if end to end 348 message integrity is required. The 'V', 'H' and 'T' bits MUST 349 NOT be set. 351 Data 353 The Data field contains the X.509 Certificate Chain. 355 3.3 X509-Certificate-URL 357 Description 359 The X509-Certificate-URL is used in order to send a DIAMETER peer 360 a URL to the local system's X.509 certificate chain [12], which is 361 used in order to validate the Digital-Signature attribute. 363 Section 4.6 contains more information about the use of 364 certificates. 366 AVP Format 368 A summary of the X509-Certificate-URL AVP format is shown below. 369 The fields are transmitted from left to right. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | AVP Code | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | AVP Length | Reserved |P|E|T|V|H|M| 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | String ... 379 +-+-+-+-+-+-+-+-+ 381 AVP Code 383 265 X509-Certificate-URL 385 AVP Length 387 The length of this attribute MUST be at least 9. 389 AVP Flags 391 The 'M' bit MUST be set. The 'P' bits MAY be set if end to end 392 message integrity is required. The 'V', 'H' and 'T' bits MUST 393 NOT be set. 395 String 397 The String field contains the X.509 Certificate Chain URL. 399 3.4 Next-Hop 401 Description 403 The Next-Hop AVP MUST preceed a Digital-Signature AVP and is used 404 to validate that a packet traversed the proxy chain that was 405 intended. A DIAMETER message with the Next-Hop Address being 406 different than the address found in the preceeding Digital- 407 Signature AVP is considered invalid. 409 AVP Format 411 A summary of the Next-Hop AVP format is shown below. The fields 412 are transmitted from left to right. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | AVP Code | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | AVP Length | Reserved |P|E|T|V|H|M| 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Address | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 AVP Code 426 290 Next-Hop 428 AVP Length 430 The length of this attribute MUST be 12. 432 AVP Flags 434 The 'M' bit and 'P' bits MUST be set. The 'V', 'H' and 'T' 435 bits MUST NOT be set. 437 Address 439 This field contains the IP Address of the next DIAMETER Server. 441 4.0 Protocol Definition 443 This section will describe how the base protocol works (or is at 444 least an attempt to). 446 4.1 Feature Advertisement/Discovery 448 As defined in [2], the Reboot-Ind and Device-Feature-Query messages 449 can be used to inform a peer about locally supported DIAMETER 450 Extensions. In order to advertise support of this extension, the 451 Extension-Id AVP must be transmitted with a value of two (2). 453 4.2 DIAMETER Secure Proxying 455 The ROAMOPS specification [11] discusses how RADIUS servers can be 456 arranged in a hierarchical manner, allowing message exchanges across 457 domain boundaries. The specification also describes some security 458 flaws encountered when RADIUS is used in a proxy environment. The 459 DIAMETER extension described in this document introduces end-to-end 460 security, which solves many of the problems encountered when RADIUS 461 is used. 463 (Request) (Request) 464 +------+ -----> +------+ ------> +------+ 465 | | | | | | 466 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 467 | | | | | | 468 +------+ <----- +------+ <------ +------+ 469 (Answer) (Answer) 471 In this example NASB generates a Request that is forwarded to DIA2. 472 The Request contains a Digital-Signature AVP which "protects" all 473 preceeding AVPs bit the 'P' bit set (known as protected AVPs) within 474 the request. All AVPs which may be modified, or removed by 475 intermediate DIAMETRE Proxies MUST NOT have the 'P' bit set. Such 476 AVPs include the Integrity-Check-Vector, Proxy-State, etc. Once DIA2 477 receives the request, it MAY validate the signature in the request to 478 ensure that it was originated by NASB. Verification may not be 479 necessary if the signature was added by a DIAMETER node one hop away 480 since the Integrity-Check-Vector (or any whatever security mechanism 481 used for hop-by-hop security) may be sufficient. 483 The DIA2 Server SHOULD add the Proxy-State AVP [2], which contains 484 opaque data that MUST be present in the response and is used to 485 identify state information related to the request or response. If the 486 Proxy-State AVP is already present in the request, it MUST be 487 replaced with DIA2's Proxy-State AVP. This means that the Proxy-State 488 AVP cannot have the 'P' bit set. The Server MAY also add other new 489 AVPs to the request. All new AVPs that are protected by the new 490 Digital-Signature AVP MUST have the 'P' bit set, and MUST preceed the 491 Digital-Signature AVP. The message is then forwarded towards the DIA1 492 server. 494 The use of link level encryption, such as IPSec, cannot be used for 495 end-to-end message integrity between NASB and DIA1, since all 496 messages are processed by DIA2. What is needed is an application 497 level security mechanism, which is what the Digital-Signature AVP 498 provides. However, Digital-Signatures may not be necessary if the 499 messages do not traverse proxies, unless non-repudiation is required. 501 This mechanism now provides a method for DIA1 to be able to identify 502 that NAS was the initiator of the request, and that no "critial" AVPs 503 were modified mid-stream by intermediate proxies. Therefore, DIA2 504 cannot modify any protected AVPs (such as duration of a call, number 505 of bytes transfered, etc). This mechanism also provides the 506 application with the integrity, and non-repudiation, information it 507 may need should it deem it necessary to log such information. 509 This extension also provides for end-to-end AVP encryption, by using 510 the peer's public key. However, given that asymetric encryption is 511 very costly, it's use should be minimal. 513 An attack has been identified in this proposal which allows a 514 malicous man in the middle attack as shown in the following diagram. 516 (Request) (Request) (Request) 517 +------+ -----> +------+ -----> +------+ -----> +------+ 518 | | | | | | | | 519 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 520 | | | | | | | | 521 +------+ <----- +------+ <----- +------+ <----- +------+ 522 (Answer) (Answer) (Answer) 524 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 525 removes the AVPs added by DIA2 and inserts its own AVPs (possibly by 526 trying to convince DIA1 to pay DIA3 for the services). This attack 527 can be prevented by supporting a new Next-Hop AVP. In this case when 528 NASB prepares a request it inserts a protected Next-Hop AVP which 529 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 530 as the next hop. 532 This mechanism ensures that a man in the middle cannot alter the 533 packet by overriding the previous hop's additions and signature. DIA1 534 could easily validate the packet's path with the use of the Next-Hop 535 AVPs. 537 4.3 Data Integrity 539 This section will describe how data integrity and non-repudiation is 540 achieved using the Digital-Signature AVP. 542 Note that the Timestamp and Nonce AVPs MUST be present in the message 543 PRIOR to the Digital-Signature AVPs discussed in this section. The 544 Timestamp AVP provides replay protection and the Nonce AVP provides 545 randomness. 547 4.3.1 Using Digital Signatures 549 In the case of a simple peer to peer relationship the use of IPSEC is 550 sufficient for data integrity and confidentiality. However there are 551 instances where a peer must communicate with another peer through the 552 use of a proxy server. IPSEC does not provide a mechanism to protect 553 traffic when two peers must use an intermediary node to communicate 554 at the application layer therefore the Digital-Signature AVP MUST be 555 used. 557 The following diagram shows an example of a router initiating a 558 DIAMETER message to DIA1. Once DIA1 has finished processing the 559 message it adds its signature and forwards the message to the non- 560 trusted DIA2 proxy server. If DIA2 needs to add or change any 561 protected AVPs it SHOULD add its digital signature before forwarding 562 the message to DIA3. 564 +------+ -----> +------+ -----> +------+ -----> +------+ 565 | | | | | non- | | | 566 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 567 | | | | | DIA2 | | | 568 +------+ <----- +------+ <----- +------+ <----- +------+ 570 Since intermediate DIAMETER proxies may add, or delete unprotected 571 AVPs "en route" towards the final DIAMETER destination, it is 572 necessary for the length in the header to be set to zero (0) prior to 573 the signature computation. The length field must be restored once the 574 computation is complete. 576 The following is an example of a message that include end-to-end 577 security: 579 ::= 580 581 [] 582 583 584 585 587 The AVP Header's 'P' bit is used to identify which AVPs are 588 considered protected when applying a digital signature to a DIAMETER 589 message. Protected AVPs cannot be changed "en route" since they are 590 protected by the Digital Signature AVP. All protected AVPs added by a 591 DIAMETER entity MUST appear prior to the new Digital Signature AVP. 593 The Next-Hop AVP indicates the intended recipient of the DIAMETER 594 message. When a DIAMETER message is received with a Next-Hop AVP 595 that does not correspond with the address information with the 596 preceeding Digital-Signature AVP, the message MUST be considered 597 invalid and MUST be rejected. The Next-Hop AVP MUST be protected. 599 The Data field of the Digital-Signature AVP contains the RSA/MD5 600 signature algorithm as defined in [9]. 602 4.3.2 Using Mixed Data Integrity AVPs 604 The previous sections described the Integrity-Check-Vector and the 605 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 606 the digital signature offers end to end integrity, it is possible to 607 use both AVPs within a single DIAMETER message. In fact, the use of 608 the ICV and the Digital-Signature is recommended to provide both 609 types of message integrity, which is necessary when messages are 610 proxied. In the event that two peers use an out-of-band message 611 integrity mechanism (e.g. IPSec) for hop-by-hop message integrity, 612 the ICV AVP is not necessary and should not be used. 614 The following diagram provides an example where DIAMETER Server 1 615 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 616 In this example ICVs are used between DIA1 and DIA2 as well as 617 between DIA2 and DIA3. 619 620 -----------------------------> 621 622 +------+ -----> +------+ -----> +------+ 623 | | | | | | 624 | DIA1 +----------+ DIA2 +----------+ DIA3 | 625 | | | | | | 626 +------+ +------+ +------+ 628 Using the previous diagram, the following message would be sent 629 between DIA1 and DIA2: 631 ::= 632 633 [] 634 635 636 637 DIA2)> 639 The following message would be sent between DIA2 and DIA3: 641 ::= 642 643 [] 644 645 646 647 648 649 DIA3)> 651 Note that in the above example messages the ICV AVP appear after the 652 Digital-Signature AVP. This is necessary since DIA2 above removes the 653 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 654 provide hop-by-hop security while the Digital-Signature provides 655 integrity of the message between DIA1 and DIA3. 657 658 ----------------------------> 659 660 +------+ -----> +------+ -----> +------+ -----> +------+ 661 | | | | | | | | 662 |router+----------+ DIA1 +----------+ DIA2 +----------+ DIA2 | 663 | | | | | | | | 664 +------+ <----- +------+ <----- +------+ <----- +------+ 666 There are cases, such as in remote access, where the device 667 initiating the DIAMETER request does not have the processing power to 668 generate Digital-Signatures as required by the protocol. In such an 669 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 670 which acts as a proxy to relay the request to the final 671 authenticating DIAMETER server (DIA2). It is valid for the first hop 672 server to remove the Integrity-Check-Vector AVP inserted by the 673 router and replace it with a Digital-Signature AVP. 675 4.4 AVP Encryption with Public Keys 677 AVP encryption using public keys is much more complex than the 678 previously decribed method, yet it is desirable to use it in cases 679 where the DIAMETER message will be processed by an untrusted 680 intermediate node (proxy). 682 Public Key encryption SHOULD be supported, however it is permissible 683 for a low powered device initiating the DIAMETER message to use 684 shared secret encryption with the first hop (proxy) DIAMETER server, 685 which would decrypt and encrypt using the Public Key method. 687 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 688 is aware of the sender's public key. This information can be relayed 689 in three different methods as described in section 4.6. 691 The AVP is encrypted in the method described in [9]. 693 4.5 Public Key Cryptography Support 695 A DIAMETER peer's public key is required in order to validate a 696 message which includes the the Digital-Signature AVP. There are three 697 possibilities on retrieving public keys: 699 4.5.1 X509-Certificate 701 A message which includes a Digital-Signature MAY include the X509- 702 Certificate AVP. Given the size of a typical certificate, this is 703 very wasteful and in most cases DIAMETER peers would cache such 704 information in order to minimize per packet processing overhead. 706 It is however valid for a DIAMETER host to provide its X509- 707 Certificate in certain cases, such as when issuing the Device- 708 Reboot-Indication, or in the Domain-Discovery messages. It is 709 envisioned that the peer would validate and cache the certificate at 710 that time. 712 4.5.2 X509-Certificate-URL 714 The X509-Certificate-URL is a method for a DIAMETER host sending a 715 message that includes the Digital-Signature to provide a pointer to 716 its certificate. 718 Upon receiving such a message a DIAMETER host MAY choose to retrieve 719 the certificate if it is not locally cached. Of course the process of 720 retrieving and validating a certificate is lengthy and will require 721 the initiator of the message to retransmit the request. However once 722 cached the certificate can be used until it expires. 724 4.5.3 Static Public Key Configuration 726 Given that using certificates requires a PKI infrastructure which is 727 very costly, it is also possible to use this technology by locally 728 configuring DIAMETER peers' public keys. 730 Note that in a network involving many DIAMETER proxies this may not 731 scale well. 733 5.0 IANA Considerations 735 The numbers for the Command Code AVPs (section 3) is taken from the 736 numbering space defined for Command Codes in [2]. The numbers for the 737 various AVPs defined in section 4 were taken from the AVP numbering 738 space defined in [2]. The numbering for the AVP and Command Codes 739 MUST NOT conflict with values specified in [2] and other DIAMETER 740 related Internet Drafts. 742 This document also introduces two new bits to the AVP Header, which 743 MUST NOT conflict with the base protocol [2] and any other DIAMETER 744 extension. 746 6.0 References 748 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 749 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 750 draft-calhoun-diameter-08.txt, August 1999. 751 [3] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 752 RFC 1321, April 1992. 753 [4] Kaufman, Perlman, Speciner, "Network Security: Private 754 Communications in a Public World", Prentice Hall, 755 March 1995, ISBN 0-13-061466-1. 756 [5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 757 Authentication", RFC 2104, January 1997. 758 [6] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 759 draft-calhoun-diameter-authen-06.txt, August 1999. 760 [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. 761 January 1999. 762 [8] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", 763 RFC 2477, January 1999. 764 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 765 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 766 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", 767 draft-calhoun-diameter-framework-02.txt, Work in Progress, 768 December 1998. 769 [11] Aboba, Vollbrecht, "Proxy Chaining and Policy Implementation in 770 Roaming", RFC 2607, June 1999. 771 [12] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 772 Infrastructure Certificate and CRL Profile", RFC 2459, 773 January 1999. 774 [13] S. Bradner, "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 7.0 Acknowledgements 778 The Authors would like to acknowledge the following people for their 779 contribution in the development of the DIAMETER protocol: 781 Bernard Aboba, Jari Arkko, Daniel C. Fox, Lol Grant, Nancy Greene, 782 Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Allan 783 Rubens, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 785 8.0 Author's Address 787 Questions about this memo can be directed to: 789 Pat R. Calhoun 790 Network and Security Research Center, Sun Labs 791 Sun Microsystems, Inc. 792 15 Network Circle 793 Menlo Park, California, 94025 794 USA 796 Phone: 1-650-786-7733 797 Fax: 1-650-786-6445 798 E-mail: pcalhoun@eng.sun.com 800 William Bulley 801 Merit Network, Inc. 802 4251 Plymouth Road, Suite C 803 Ann Arbor, Michigan, 48105-2785 804 USA 806 Phone: 1-734-764-9993 807 Fax: 1-734-647-3185 808 E-mail: web@merit.edu 810 9.0 Full Copyright Statement 812 Copyright (C) The Internet Society (1999). All Rights Reserved. 814 This document and translations of it may be copied and furnished 815 to others, and derivative works that comment on or otherwise 816 explain it or assist in its implmentation may be prepared, copied, 817 published and distributed, in whole or in part, without 818 restriction of any kind, provided that the above copyright notice 819 and this paragraph are included on all such copies and derivative 820 works. However, this docu- ment itself may not be modified in any 821 way, such as by removing the copyright notice or references to the 822 Internet Society or other Inter- net organizations, except as needed 823 for the purpose of developing Internet standards in which case 824 the procedures for copyrights defined in the Internet Standards 825 process must be followed, or as required to translate it into 826 languages other than English. The limited permis- sions granted 827 above are perpetual and will not be revoked by the Internet 828 Society or its successors or assigns. This document and the 829 information contained herein is provided on an "AS IS" basis and 830 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 831 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 832 LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN 833 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 834 MERCHANTABILITY OR FITNESS FOR A PARTICULAR 835 RLITYse