idnits 2.17.00 (12 Aug 2021) /tmp/idnits27442/draft-tschofenig-hiprg-host-identities-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 850. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 28 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (February 25, 2008) is 5192 days in the past. Is this intentional? 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: '8' is defined on line 718, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 738, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 745, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 763, but no explicit reference was found in the text == Outdated reference: draft-ietf-hip-arch has been published as RFC 4423 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '2') == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: draft-ietf-mmusic-sdescriptions has been published as RFC 4568 == Outdated reference: draft-ietf-mmusic-kmgmt-ext has been published as RFC 4567 ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: draft-ietf-mmusic-sdp-new has been published as RFC 4566 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '11') (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-sip-certs has been published as RFC 6072 == Outdated reference: draft-ietf-hip-rvs has been published as RFC 5204 == Outdated reference: draft-ietf-hip-nat-traversal has been published as RFC 5770 == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 Summary: 4 errors (**), 0 flaws (~~), 22 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Expires: August 28, 2008 J. Ott 5 Helsinki University of Technology 6 H. Schulzrinne 7 Columbia U. 8 T. Henderson 9 The Boeing Company 10 G. Camarillo 11 Ericsson 12 February 25, 2008 14 Interaction between SIP and HIP 15 draft-tschofenig-hiprg-host-identities-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 28, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document investigates the interworking between the Session 49 Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and 50 the benefits that may arise from their combined operation. 52 The aspect of exchanging Host Identities (or Host Identity Tags) in 53 SIP/SDP for later usage with the Host Identity Protocol Protocol 54 (HIP) is described in more detail as an example of this interworking. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Exchanging Host Identities with SIP . . . . . . . . . . . . . 5 61 3.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 4.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 4.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 4.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 4.4. Single-sided Verification . . . . . . . . . . . . . . . . 18 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 76 Intellectual Property and Copyright Statements . . . . . . . . . . 27 78 1. Introduction 80 SIP [1] enables a pair of user agents to establish and maintain 81 sessions. The communication typically involves SIP proxies before 82 prior to communication between the end points taking place. As part 83 of the initial exchange, a number of parameters are exchanged. 84 Certain of these parameters are relevant to security. Examples of 85 such parameters are keying material and other cryptographic 86 information that is used in order to establish a security association 87 for the protection of subsequent data traffic. 89 HIP (see [2] and [3]) propose an architecture with a cryptographic 90 namespace and a layer between the network and the transport layer. 91 This layer is used in order to shield applications from the impact of 92 multi-homing, readdressing and mobility. A protocol, called the Host 93 Identity Protocol, is used in order to establish state at the two end 94 hosts. This state includes the establishment of IPsec SAs. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [4]. 102 3. Exchanging Host Identities with SIP 104 3.1. Concept 106 In order to provide security between two HIP end hosts beyond 107 opportunistic encryption it is necessary to securely retrieve the 108 Host Identities. A number of mechanisms can be used including 109 directories (such as DNS) or more advanced concepts for example based 110 on Distributed Hash Tables typically used in peer-to-peer networks. 112 This document suggests to exchange the Host Identities (or Host 113 Identity Tags) as part of the initial SIP exchange inside the SDP 114 payload. As such, the Host Identities can also be bound to the user 115 identities - a concept not used in HIP. 117 Figure 1 illustrates the main idea: 119 +-----------+ +-----------+ 120 HI/HIT |SIP | HI/HIT |SIP | HI/HIT 121 +------>|Proxy |<---------->|Proxy |<------+ 122 | |Server X | TLS |Server Y | | 123 | +-----------+ (+auth.id.)+-----------+ | 124 | | 125 | TLS or TLS or | 126 | SIP Digest SIP Digest | 127 | (+auth.id.) | 128 | | 129 v v 130 +-----------+ SIP and HIP +-----------+ 131 |SIP | <---------------------------------> |SIP | 132 |User Agent | RTP |User Agent | 133 |Alice | <=================================> |Bob | 134 +-----------+ +-----------+ 136 Legend: 137 <--->: Signaling Traffic 138 <===>: Data Traffic 140 Figure 1: SIP Trapezoid 142 The initial SIP signaling messages between Alice and Bob often take 143 place via the proxy servers. This exchange may be protected with TLS 144 (between SIP proxies but also between SIP UAs and SIP proxies) or 145 with SIP digest authentication between SIP UAs and the outbound 146 proxy. Further SIP security mechanisms should be used in combination 147 with this proposal. The security consideration section, see 148 Section 4, provides a discussion about the possible approaches to 149 secure the Host Identity Tag and to relate it ongoing session. 151 This allows two hosts to securely exchange keys even if there are 152 only domain-level public and private keys, as well as secure 153 associations within a domain, thus avoiding the need for a global 154 user-level PKI. 156 This initial message exchange is used to exchange Host Identities 157 between the end points within the SDP payload. 159 Subsequently, when both user agents Alice and Bob communicate 160 directly with each other they are able to reuse the Host Identity for 161 the HIP message exchange. 163 If the SIP communication does not involve third parties (i.e., SIP 164 proxies) and is therefore executed directly between the two SIP UAs 165 then it is not useful to exchange Host Identities in the SDP payloads 166 since the HIP exchange already took place before the first SIP 167 message can be exchanged between the two peers. Still HIP might 168 provide some advantages for the end-to-end communication, such as 169 providing security at the lower layer and mobility and multi-homing 170 support. 172 The security of this approach relies on two properties: 174 The signaling messages and the data traffic traverse a different 175 path. Hence, an adversary needs to be located where it is able to 176 see both, the signaling and the the data traffic. 178 The signaling traffic is often protected. 180 3.2. SDP Extension 182 This document proposes to enhance the SDP [5] 'k' or 'a' parameter. 184 The 'k' parameter has the following structure: 186 k=: 188 This document defines two new method fields: 190 k=host-identity: 192 k=host-identity-tag: 194 Alternatively, the 'a' parameter could be used like [6] proposes. An 195 example for MIKEY [9] is given in the reference, which could be 196 reused for HIP. As defined in [10], the 'a' parameter has the 197 following structure: 199 a=: 201 Similar to the MIKEY example in [6], this document defines two new 202 method fields: 204 a=key-mgmt:host-identity 206 a=key-mgmt:host-identity-tag 208 Both, the Host Identity and the Host Identity Tag are defined in [3]. 209 The Host Identity contains the public key and a number of 210 cryptographic parameters (such as used algorithms and Diffie-Hellmann 211 public parameters). The Host Identity is base64 encoded. 213 FOR DISCUSSION: 215 The usage of the k parameter as defined in [7] is deprecated. [5] 216 is more appropriate but like 'k=', they come with the caveat that 217 they require a secured e2e signaling path (or SDP is S/MIME 218 protected). One alternative is the usage of MIKEY for the 219 exchange as defined in [6]. 221 Furthermore, and probably more important, it is important to said 222 what the Host Identity is supposed to be used with. They may help 223 avoiding re-INVITEs when underlying IP addresses change to update 224 the 'Contact:' address as well as the addresses in the 'c=' lines 225 for the various media. 227 However, multiple devices may take part in the different media 228 sessions (your laptop doing video in parallel to your hardware IP 229 phone). To support these cases, it may be necessary to exchange 230 _several_ HI(T)s within SDP and denote what they shall be used 231 for. Such a mapping could naturally be achieved for each media 232 stream (even using 'k=' attributes); at simple 'a=' attributes (or 233 the mechanisms from [5]/ [6] would be preferred. 235 SDP only deals with media streams and does not have a notion of 236 user or main device in the background. Hence, the SIP HI(T) may 237 need to go into SIP signaling (rather than be carried in SDP). 239 Logically, this appears to belong to the 'Contact:' header which 240 may be conveyed protected in an S/MIME body (signed and 241 encrypted). 243 3.3. Example 245 This example contains the full details of the example session setup 246 taken from Section 4 of [1]. The message flow is shown in Figure 1 247 of [1] and resembles the architecture shown in Figure 1. Note that 248 these flows show the minimum required set of header fields; some 249 other header fields such as Allow and Supported would normally be 250 present. 252 In our example Alice uses the following Host Identity Tag 253 (7214148E0433AFE2FA2D48003D31172E) and Bob uses 254 (44A5C522D7EDEDF962E55A0677DB1346) as the HIT. These HITs correspond 255 to the following Host Identities (for convenience we reuse the XML 256 representation format used by the Boeing implementation). 258 ------ 259 Alice: 260 ------ 262 265 sip:alice@atlanta.com 267

D757262C4584C44C211F18BD96E5F061C4F0A423F7FE6B6B85B34CEF72CE14 268 A0D3A222FE08CECE65BE6C265854889DC1EDBD13EC8B274DA9F75BA26CCB98772 269 3602787E92BA84421F22C3C89CB9B06FD60FE01941DDD77FE6B12893DA76EEBC1 270 D128D97F0678D772B5341C8506F358214B16A2FAC4B368950387811C7DA33

272 C773218C737EC8EE993B4F2DED30F48EDACE915F 274 82269009E14EC474BAF2932E69D3B1F18517AD9594184CCDFCEAE96EC4D5EF 275 9313384B47093C52B20CD35D02492B3959EC6499625BC4FA5082E22C5B374E16D 276 D00132CE71020217091AC717B612391C76C1FB2E88317C1BD8171D41ECB83E210 277 C03CC9B32E81056C21621C73D6DAAC028F4B1585DA7F42519718CC9B09EEF 279 A4666AED5F5E753773DC961EDD0412A03F1F8D7CEC70A057076062804B86 280 619D3DA4E7610EBBDB05F44C5784622D1B86600DFCC1431BC4451D4FD31329354 281 07A9B24718CB82BAE93A4CDD9CC4C8B9A41C000AB53D52A65E8383F54F5BF92A8 282 21EA776A207C6991EF23808C00DB820977D97CAC01CB96307274E2386001327 283 285 7214148E0433AFE2FA2D48003D31172E 286
287 ---- 288 Bob: 289 ---- 291 294 sip:bob@biloxi.com 296

F13ACC1693AFD04B9E1E8D2A9DEA6DE8DE4C276BE2BF15B6CFF6E269B0169 297 378CB0DDDE23D187827015DC67E6768193914B823BDF215D0DAD7A151E434F9E 298 128DAFB9DEFAE07874621E70D7ED2D34B80A95FA8312B9564E4D118FB525664C 299 77D

301 C773218C737EC8EE993B4F2DED30F48EDACE915F 303 241F32CF48F424B1A75D33B7AE6088E745D9E24E653AE2CAEBE67E4AA1C11 304 15BA0CC25055A63C139235A95B36EFBC2064AF304C0F8A431D151B2B5854DE61 305 5168B45B9EAEBF9A88354CA7876E52D169E14E502BEA0CBB98B55AD2AB61620F 306 498 308 E481C20D8FBAA84F9C7ED8B5598F60F5A7D03951CA4783841EB8ADDC63D 309 DE11A2F3555C5641F465160AB1E016756D826B0F8CE4FDE33BA17F6FFFA751DA 310 1389A10E5599802AB1EBE4FD943405819A74FD6F1C9EA2815EE6B651610DF107 311 5D19F 313 44A5C522D7EDEDF962E55A0677DB1346 315
316 F1 INVITE Alice -> atlanta.com proxy 318 INVITE sip:bob@biloxi.com SIP/2.0 319 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 320 Max-Forwards: 70 321 To: Bob 322 From: Alice ;tag=1928301774 323 Call-ID: a84b4c76e66710 324 CSeq: 314159 INVITE 325 Contact: 326 Content-Type: application/sdp 327 Content-Length: ... 329 v=0 330 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 331 s=Session SDP 332 t=0 0 333 c=IN IP4 pc33.atlanta.com 334 m=audio 3456 RTP/AVP 0 1 3 99 335 a=rtpmap:0 PCMU/8000 336 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 338 F2 100 Trying atlanta.com proxy -> Alice 340 SIP/2.0 100 Trying 341 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 342 ;received=192.0.2.1 343 To: Bob 344 From: Alice ;tag=1928301774 345 Call-ID: a84b4c76e66710 346 CSeq: 314159 INVITE 347 Content-Length: 0 348 F3 INVITE atlanta.com proxy -> biloxi.com proxy 350 INVITE sip:bob@biloxi.com SIP/2.0 351 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 352 ;branch=z9hG4bK77ef4c2312983.1 353 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 354 ;received=192.0.2.1 355 Max-Forwards: 69 356 To: Bob 357 From: Alice ;tag=1928301774 358 Call-ID: a84b4c76e66710 359 CSeq: 314159 INVITE 360 Contact: 361 Content-Type: application/sdp 362 Content-Length: ... 364 v=0 365 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 366 s=Session SDP 367 t=0 0 368 c=IN IP4 pc33.atlanta.com 369 m=audio 3456 RTP/AVP 0 1 3 99 370 a=rtpmap:0 PCMU/8000 371 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 373 F4 100 Trying biloxi.com proxy -> atlanta.com proxy 375 SIP/2.0 100 Trying 376 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 377 ;branch=z9hG4bK77ef4c2312983.1 378 ;received=192.0.2.2 379 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 380 ;received=192.0.2.1 381 To: Bob 382 From: Alice ;tag=1928301774 383 Call-ID: a84b4c76e66710 384 CSeq: 314159 INVITE 385 Content-Length: 0 386 F5 INVITE biloxi.com proxy -> Bob 388 INVITE sip:bob@192.0.2.4 SIP/2.0 389 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 390 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 391 ;branch=z9hG4bK77ef4c2312983.1 392 ;received=192.0.2.2 393 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 394 ;received=192.0.2.1 395 Max-Forwards: 68 396 To: Bob 397 From: Alice ;tag=1928301774 398 Call-ID: a84b4c76e66710 399 CSeq: 314159 INVITE 400 Contact: 401 Content-Type: application/sdp 402 Content-Length: ... 404 v=0 405 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 406 s=Session SDP 407 t=0 0 408 c=IN IP4 pc33.atlanta.com 409 m=audio 3456 RTP/AVP 0 1 3 99 410 a=rtpmap:0 PCMU/8000 411 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 413 F6 180 Ringing Bob -> biloxi.com proxy 415 SIP/2.0 180 Ringing 416 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 417 ;received=192.0.2.3 418 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 419 ;branch=z9hG4bK77ef4c2312983.1 420 ;received=192.0.2.2 421 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 422 ;received=192.0.2.1 423 To: Bob ;tag=a6c85cf 424 From: Alice ;tag=1928301774 425 Call-ID: a84b4c76e66710 426 Contact: 427 CSeq: 314159 INVITE 428 Content-Length: 0 429 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy 431 SIP/2.0 180 Ringing 432 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 433 ;branch=z9hG4bK77ef4c2312983.1 434 ;received=192.0.2.2 435 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 436 ;received=192.0.2.1 437 To: Bob ;tag=a6c85cf 438 From: Alice ;tag=1928301774 439 Call-ID: a84b4c76e66710 440 Contact: 441 CSeq: 314159 INVITE 442 Content-Length: 0 444 F8 180 Ringing atlanta.com proxy -> Alice 446 SIP/2.0 180 Ringing 447 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 448 ;received=192.0.2.1 449 To: Bob ;tag=a6c85cf 450 From: Alice ;tag=1928301774 451 Call-ID: a84b4c76e66710 452 Contact: 453 CSeq: 314159 INVITE 454 Content-Length: 0 455 F9 200 OK Bob -> biloxi.com proxy 457 SIP/2.0 200 OK 458 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 459 ;received=192.0.2.3 460 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 461 ;branch=z9hG4bK77ef4c2312983.1 462 ;received=192.0.2.2 463 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 464 ;received=192.0.2.1 465 To: Bob ;tag=a6c85cf 466 From: Alice ;tag=1928301774 467 Call-ID: a84b4c76e66710 468 CSeq: 314159 INVITE 469 Contact: 470 Content-Type: application/sdp 471 Content-Length: ... 473 v=0 474 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 475 s=Session SDP 476 c=IN IP4 192.0.2.4 477 t=3034423619 0 478 m=audio 3456 RTP/AVP 0 479 a=rtpmap:0 PCMU/8000 480 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 481 F10 200 OK biloxi.com proxy -> atlanta.com proxy 483 SIP/2.0 200 OK 484 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 485 ;branch=z9hG4bK77ef4c2312983.1 486 ;received=192.0.2.2 487 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 488 ;received=192.0.2.1 489 To: Bob ;tag=a6c85cf 490 From: Alice ;tag=1928301774 491 Call-ID: a84b4c76e66710 492 CSeq: 314159 INVITE 493 Contact: 494 Content-Type: application/sdp 495 Content-Length: ... 497 v=0 498 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 499 s=Session SDP 500 c=IN IP4 192.0.2.4 501 t=3034423619 0 502 m=audio 3456 RTP/AVP 0 503 a=rtpmap:0 PCMU/8000 504 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 506 F11 200 OK atlanta.com proxy -> Alice 508 SIP/2.0 200 OK 509 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 510 ;received=192.0.2.1 511 To: Bob ;tag=a6c85cf 512 From: Alice ;tag=1928301774 513 Call-ID: a84b4c76e66710 514 CSeq: 314159 INVITE 515 Contact: 516 Content-Type: application/sdp 517 Content-Length: ... 519 v=0 520 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 521 s=Session SDP 522 c=IN IP4 192.0.2.4 523 t=3034423619 0 524 m=audio 3456 RTP/AVP 0 525 a=rtpmap:0 PCMU/8000 526 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 527 F12 ACK Alice -> Bob 529 ACK sip:bob@192.0.2.4 SIP/2.0 530 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 531 Max-Forwards: 70 532 To: Bob ;tag=a6c85cf 533 From: Alice ;tag=1928301774 534 Call-ID: a84b4c76e66710 535 CSeq: 314159 ACK 536 Content-Length: 0 538 The media session between Alice and Bob is now established. 540 The exchanged HITs are now placed in the pool of known HITs at both 541 end hosts. As such there is also a binding established between URI 542 and HIT at this point. 544 Next a regular HIP base exchange between Alice and Bob is started. 545 As part of the exchange the two end hosts inspect their known-HITs 546 pool and find the previously exchanged parameters. 548 Alice -> Bob: I1: Trigger exchange 550 Alice <- Bob: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 551 HIP Transform }SIG 553 Alice -> Bob: I2: {Solution, LSI(I), SPI(I), D-H(I), 554 ESP Transform, HIP Transform, {H(I)}SK }SIG 556 Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG 558 As a result of this exchange, two IPsec SAs (one for each direction) 559 is established. RTP media traffic can be exchanged between the two 560 end hosts, Alice and Bob, protected by IPsec. If end host mobility 561 takes place then a HIP readdressing exchange takes place which is not 562 detected at the upper layer by UDP/RTP or SIP. 564 4. Security Considerations 566 The standard HIP strategy for authenticating the communicating 567 parties is to give the Initiator and the Responder a Host Identity 568 and to assure the authenticity of the Host Identity via external 569 mechanisms, such as DNSSEC (if the Host Identities are stored in the 570 DNS). The Initiator then verifies the Host Identity and checks its 571 validity. The complexity of ensuring that the Host Identity has not 572 been tampered with is pushed to DNS (and DNSSEC), as the only 573 mechanism specified for ensuring that the public key is genuine. The 574 infrastructure provided for SIP can provide a similar, but more 575 deployment friendly, functionality when combined with already 576 available SIP security mechanisms. 578 The design described in this document is intended to leverage the 579 authenticity of the signaling channel (while not requiring 580 confidentiality). As long as each side of the connection can verify 581 the integrity of the SDP INVITE then the HIP base exchange handshake 582 cannot be hijacked via a man-in-the-middle attack. This integrity 583 protection is easily provided by the caller to the callee via the SIP 584 Identity [11] mechanism. However, it is less straightforward for the 585 responder. 587 Ideally Alice would want to know that Bob's SDP had not been tampered 588 with and who it was from so that Alice's User Agent could indicate to 589 Alice that there was a secure phone call to Bob. This is known as the 590 SIP Response Identity problem and is still a topic of ongoing work in 591 the SIP community. When a solution to the SIP Response Identity 592 problem is finalized, it SHOULD be used here. In the meantime there 593 are several approaches that can be used to mitigate this problem: Use 594 UPDATE, Use SIPS, Use S/MIME, and do nothing. Each one is discussed 595 here followed by the security implications of that approach. 597 4.1. UPDATE 599 In this approach, Bob sends an answer, then immediately follows up 600 with an UPDATE that includes the Host Identity Tag and uses the SIP 601 Identity mechanism to assert that the message is from Bob's. The 602 downside of this approach is that it requires the extra round trip of 603 the UPDATE. However, it is simple and secure even when the proxies 604 are not trusted. 606 4.2. SIPS 608 In this approach, the signaling is protected by TLS from hop to hop. 609 As long as all proxies are trusted, this provides integrity for the 610 Host Identity Tag. It does not provide a strong assertion of who 611 Alice is communicating with. However, as much as the target domain 612 can be trusted to correctly populate the From header field value, 613 Alice can use that. The security issue with this approach is that if 614 one of the Proxies wished to mount a man-in-the-middle attack, it 615 could convince Alice that she was talking to Bob when really the 616 media was flowing through a man in the middle media relay. However, 617 this attack could not convince Bob that he was taking to Alice. 619 4.3. S/MIME 621 RFC 3261 [1] defines a S/MIME security mechanism for SIP that could 622 be used to sign that the fingerprint was from Bob. This would be 623 secure. However, so far there have been no deployments of S/MIME for 624 SIP. 626 4.4. Single-sided Verification 628 In this approach, no integrity is provided for the fingerprint from 629 Bob to Alice. In this approach, an attacker that was on the 630 signaling path could tamper with the fingerprint and insert 631 themselves as a man-in-the-middle on the media. Alice would know 632 that she had a secure call with someone but would not know if it was 633 with Bob or a man-in-the-middle. Bob would know that an attack was 634 happening. The fact that one side can detect this attack means that 635 in most cases where Alice and Bob both wish the communications to be 636 encrypted there is not a problem. Keep in mind that in any of the 637 possible approaches Bob could always reveal the media that was 638 received to anyone. We are making the assumption that Bob also wants 639 secure communications. In this do nothing case, Bob knows the media 640 has not been tampered with or intercepted by a third party and that 641 it is from Alice. Alice knows that she is talking to someone and 642 that whoever that is has probably checked that the media is not being 643 intercepted or tampered with. This approach is certainly less than 644 ideal but very usable for many situations. An alternative available 645 to Alice and Bob is to use human speech to verified each others' 646 identity then verify each others' Host Identity Tags also using human 647 speech. Assuming that it is difficult to impersonate another's 648 speech and seamlessly modify the audio contents of a call, this 649 approach is relatively safe. On the other hand, SIP is not only used 650 for voice communication. 652 Note that this proposal is closely aligned towards the usage of the 653 'k' parameter in SDP [7]. As a difference, an asymmetric key is 654 exchanged unlike the proposals illustrated in Section 6 of [7]. 655 Section 5.12 of [10] is relevant for this discussion. 657 Please note that this approach is in a certain sense a re- 658 instantiation of the Purpose-Built-Key (PBK) idea (see [12]). With 659 PBK a hash of a public key is sent from node A to node B. If there 660 was no adversary between A and B at that time to modify the 661 transmitted hash value then subsequent communication interactions 662 which use the public key are secure. This proposal reuses the same 663 idea but focuses on the interworking between different protocols. In 664 fact it would be possible to use the same approach to exchange the 665 hash of an S/MIME certificate which can later be used in subsequent 666 SIP signaling message exchanges. 668 5. IANA Considerations 670 [Editor's Note: A future version of this document will provide a 671 discussion about IANA considerations.] 673 6. Contributors 675 We would like to thank Vesa Torvinen for his contributions to the 676 initial version of this document. 678 7. Acknowledgments 680 The authors would like to thank Steffen Fries, Aarthi Nagarajan, 681 Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross 682 for their feedback. 684 The content of the security consideration section is based on DTLS- 685 SIP. 687 8. References 689 8.1. Normative References 691 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 692 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 693 Session Initiation Protocol", RFC 3261, June 2002. 695 [2] Moskowitz, R. and P. Nikander, "Host Identity Protocol 696 Architecture", draft-ietf-hip-arch-03 (work in progress), 697 August 2005. 699 [3] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 700 "Host Identity Protocol", draft-ietf-hip-base-10 (work in 701 progress), October 2007. 703 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 704 Levels", March 1997. 706 [5] Andreasen, F., "Session Description Protocol Security 707 Descriptions for Media Streams", 708 draft-ietf-mmusic-sdescriptions-12 (work in progress), 709 September 2005. 711 [6] Arkko, J., "Key Management Extensions for Session Description 712 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 713 draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. 715 [7] Handley, M. and V. Jacobson, "SDP: Session Description 716 Protocol", RFC 2327, April 1998. 718 [8] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility 719 using SIP, ACM MC2R", , July 2000. 721 8.2. Informative References 723 [9] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 724 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 725 August 2004. 727 [10] Handley, M., "SDP: Session Description Protocol", 728 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 730 [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated 731 Identity Management in the Session Initiation Protocol (SIP)", 732 RFC 4474, August 2006. 734 [12] Bradner, S., Mankin, A., and J. Schiller, "A Framework for 735 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in 736 progress), June 2003. 738 [13] Jennings, C., Peterson, J., and J. Fischl, "Certificate 739 Management Service for The Session Initiation Protocol (SIP)", 740 draft-ietf-sip-certs-05 (work in progress), February 2008. 742 [14] Sparks, R., "The Session Initiation Protocol (SIP) Refer 743 Method", RFC 3515, April 2003. 745 [15] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 746 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 747 progress), June 2006. 749 [16] Schmitt, V., "HIP Extensions for the Traversal of Network 750 Address Translators", draft-ietf-hip-nat-traversal-02 (work in 751 progress), July 2007. 753 [17] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session 754 Traversal Utilities for (NAT) (STUN)", 755 draft-ietf-behave-rfc3489bis-15 (work in progress), 756 February 2008. 758 [18] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 759 Relays around NAT (TURN): Relay Extensions to Session 760 Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-06 761 (work in progress), January 2008. 763 [19] Jokela, P., "Using ESP transport format with HIP", 764 draft-ietf-hip-esp-06 (work in progress), June 2007. 766 Authors' Addresses 768 Hannes Tschofenig 769 Nokia Siemens Networks 770 Linnoitustie 6 771 Espoo 02600 772 Finland 774 Phone: +358 (50) 4871445 775 Email: Hannes.Tschofenig@nsn.com 776 URI: http://www.tschofenig.com 778 Joerg Ott 779 Helsinki University of Technology 780 Otakaari 5A 781 Espoo FI-02150 782 Finland 784 Email: jo@netlab.hut.fi 786 Henning Schulzrinne 787 Columbia University 788 Department of Computer Science 789 450 Computer Science Building 790 New York, NY 10027 791 USA 793 Phone: +1 212 939 7042 794 Email: schulzrinne@cs.columbia.edu 795 URI: http://www.cs.columbia.edu/~hgs 797 Thomas R. Henderson 798 The Boeing Company 799 P.O. Box 3707 800 Seattle, WA 801 USA 803 Email: thomas.r.henderson@boeing.com 804 Gonzalo Camarillo 805 Ericsson 806 Hirsalantie 11 807 Jorvas 02420 808 Finland 810 Email: Gonzalo.Camarillo@ericsson.com 812 Full Copyright Statement 814 Copyright (C) The IETF Trust (2008). 816 This document is subject to the rights, licenses and restrictions 817 contained in BCP 78, and except as set forth therein, the authors 818 retain all their rights. 820 This document and the information contained herein are provided on an 821 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 822 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 823 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 824 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 825 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 826 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 828 Intellectual Property 830 The IETF takes no position regarding the validity or scope of any 831 Intellectual Property Rights or other rights that might be claimed to 832 pertain to the implementation or use of the technology described in 833 this document or the extent to which any license under such rights 834 might or might not be available; nor does it represent that it has 835 made any independent effort to identify any such rights. Information 836 on the procedures with respect to rights in RFC documents can be 837 found in BCP 78 and BCP 79. 839 Copies of IPR disclosures made to the IETF Secretariat and any 840 assurances of licenses to be made available, or the result of an 841 attempt made to obtain a general license or permission for the use of 842 such proprietary rights by implementers or users of this 843 specification can be obtained from the IETF on-line IPR repository at 844 http://www.ietf.org/ipr. 846 The IETF invites any interested party to bring to its attention any 847 copyrights, patents or patent applications, or other proprietary 848 rights that may cover technology that may be required to implement 849 this standard. Please address the information to the IETF at 850 ietf-ipr@ietf.org. 852 Acknowledgment 854 Funding for the RFC Editor function is provided by the IETF 855 Administrative Support Activity (IASA).