idnits 2.17.00 (12 Aug 2021) /tmp/idnits39057/draft-tschofenig-hiprg-host-identities-05.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 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 980. 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 (June 17, 2007) is 5452 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: '25' is defined on line 892, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == 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. '8') (Obsoleted by RFC 4566) == Outdated reference: draft-shacham-sipping-session-mobility has been published as RFC 5631 == Outdated reference: draft-ietf-hip-rvs has been published as RFC 5204 == 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-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: draft-ietf-hip-nat-traversal has been published as RFC 5770 == Outdated reference: A later version (-06) exists of draft-tschofenig-hiprg-hip-natfw-traversal-05 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-hip-esp has been published as RFC 5202 == Outdated reference: draft-ietf-mmusic-sdp-new has been published as RFC 4566 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '23') (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-sip-certs has been published as RFC 6072 Summary: 4 errors (**), 0 flaws (~~), 19 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: December 19, 2007 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 June 17, 2007 14 Interaction between SIP and HIP 15 draft-tschofenig-hiprg-host-identities-05.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 December 19, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Exchanging Host Identities with SIP . . . . . . . . . . . . . 7 61 3.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 65 4.1. UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 4.2. SIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 4.3. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 20 68 4.4. Single-sided Verification . . . . . . . . . . . . . . . . 20 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 70 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 77 Intellectual Property and Copyright Statements . . . . . . . . . . 31 79 1. Introduction 81 SIP [1] enables a pair of user agents to establish and maintain 82 sessions. The communication typically involves SIP proxies before 83 prior to communication between the end points taking place. As part 84 of the initial exchange, a number of parameters are exchanged. 85 Certain of these parameters are relevant to security. Examples of 86 such parameters are keying material and other cryptographic 87 information that is used in order to establish a security association 88 for the protection of subsequent data traffic. 90 HIP (see [2] and [3]) propose an architecture with a cryptographic 91 namespace and a layer between the network and the transport layer. 92 This layer is used in order to shield applications from the impact of 93 multi-homing, readdressing and mobility. A protocol, called the Host 94 Identity Protocol, is used in order to establish state at the two end 95 hosts. This state includes the establishment of IPsec SAs. 97 Several areas may benefit from the aformentioned interworking. These 98 include the following. 100 Mobility: 102 Mobility support can be provided at different layers in the 103 protocol stack. SIP can offer terminal mobility, as described in 104 [4]. Prior to a call, mobility is handled by re-registration with 105 the home registrar. For mid-call mobility, the moving node sends 106 a re-INVITE directly to the correspondent host, or via the SIP 107 proxies if, during the initial call setup, the proxy had inserted 108 a Record-Route header. Session mobility in SIP is implemented 109 through the usage of the SIP REFER method [9]. A discussion of 110 session mobility with SIP is, for example, provided in [10]. The 111 basic SIP security mechanisms are used in order to protect the 112 signalling exchanges that refer to the above-mentioned terminal 113 and session mobility. 115 The basic SIP mobility has two main limitations. Firstly, it is 116 unable to move TCP sessions to new IP addresses. This could be 117 accomplished by TCP extensions, such as TCP-Migrate or M-TCP or by 118 the usage of SCTP (where possible). The second limitation is the 119 low speed of handoffs. 121 One can shield the movement of the end hosts against each other 122 though the usage of HIP. HIP itself, however, does not offer 123 micromobility solutions or mechanisms to deal with the double- 124 movement problem. Extensions have been defined, such as the HIP 125 rendezvous concept [11] or Hi3 [12] that, among other things, deal 126 with initial reachability and provide additional mobility 127 mechanisms. A later version of this document will also 128 investigate the interworking of SIP with these HIP extensions. In 129 summary, current HIP mobility mechanisms do not offer substantial 130 additional features or security over what SIP provides. This 131 applies especially to the typical scenario where reliable 132 transport protocols are not used in SIP user data flows. 134 Middlebox Traversal: 136 The work on traversing Network Address Translators with SIP and 137 media traffic has focused on MIDCOM and the Interactive 138 Connectivity Establishment (ICE) methodology. ICE relies on other 139 protocols, such as STUN [13] and TURN [14] in order to create a 140 NAT binding. 142 HIP may provide an alternative way to traverse HIP-aware NATs, 143 since, in this setting, the NATs can inspect the HIP signaling 144 exchange and create the necessary bindings. This approach is 145 similar to the one proposed by the NSIS working group where a 146 path-coupled signaling protocol is used to interact with these 147 middleboxes to create NAT bindings (and firewall pin-holes). The 148 NATFW-NSLP [15] is a protocol proposal that utilizes the NSIS 149 protocol suite. The travesal of HIP unaware NATs is detailed in 150 [16] and a discussion about NAT and firewall traversal of HIP- 151 aware devices is given in [17]. 153 Denial of Service Prevention: 155 SIP follows the offer/answer model. The offerer generates an 156 offer that contains, among other things, the IP address the 157 answerer is expected to send its media to. The offer/answer model 158 can be used in order to perform denial of service attacks against 159 third parties. The offerer generates an offer with the IP address 160 of the victim and the answerer, on reception of such offer, starts 161 sending media to the victim. If the session consists of media 162 sent over a connection-oriented transport protocol such as TCP, 163 the victim is unlikely to respond to the connection establishment 164 request (e.g. the initial SYN in TCP) and the connection is not 165 established. However, if the session consists of media sent over 166 RTP and UDP, the sender just floods the victim with RTP packets. 167 The ICMP "not reachable" messages generated by the victim may or 168 may not stop the attack. Firewalls in the path may discard these 169 packets or the RTP library of the sender may ignore them. The use 170 of HIP would prevent this type of attack because the victim would 171 not accept the incoming HIP message. Of course, in order to 172 further address this type of attack no user agent in the network 173 should accept session descriptions that only provide IP addresses 174 in order to send RTP data. Sessions that did not use HIP would 175 need to use a different method to deal with this attack. An 176 example of such a method consists of using ICE (Interactive 177 Connectivity Establishment) [18] as a return routability test 178 before starting to send media. Other approaches as part of the 179 HIP overlay infrastructure in combination with HIP Registration 180 servers might also provide the same effect or even a higher degree 181 of security. 183 SRTP and HIP: 185 The Host Identity Protocol is able to establish IPsec security 186 associations, as described in [19]. In the case of SIP for voice 187 communication, end-to-end media protection using SRTP may be 188 applied. HIP supports a variety of cryptographic protection 189 mechanisms for the data traffic, including IPsec, SRTP. The 190 establishment of the necessary parameters and the keying material 191 for enabling SRTP communication is outlined in a separate document 192 [20]. 194 Exchanging Host Identities with SIP: 196 HIP can benefit from existing SIP infrastructure because it 197 enables the distribution of Host Identities or Host Identity Tags, 198 as described in Section 3. 200 2. Terminology 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC 2119 [5]. 206 3. Exchanging Host Identities with SIP 208 3.1. Concept 210 In order to provide security between two HIP end hosts beyond 211 opportunistic encryption it is necessary to securely retrieve the 212 Host Identities. A number of mechanisms can be used including 213 directories (such as DNS) or more advanced concepts for example based 214 on Distributed Hash Tables typically used in peer-to-peer networks. 216 This document suggests to exchange the Host Identities (or Host 217 Identity Tags) as part of the initial SIP exchange inside the SDP 218 payload. As such, the Host Identities can also be bound to the user 219 identities - a concept not used in HIP. 221 Figure 1 illustrates the main idea: 223 +-----------+ +-----------+ 224 HI/HIT |SIP | HI/HIT |SIP | HI/HIT 225 +------>|Proxy |<---------->|Proxy |<------+ 226 | |Server X | TLS |Server Y | | 227 | +-----------+ (+auth.id.)+-----------+ | 228 | | 229 | TLS or TLS or | 230 | SIP Digest SIP Digest | 231 | (+auth.id.) | 232 | | 233 v v 234 +-----------+ SIP and HIP +-----------+ 235 |SIP | <---------------------------------> |SIP | 236 |User Agent | RTP |User Agent | 237 |Alice | <=================================> |Bob | 238 +-----------+ +-----------+ 240 Legend: 241 <--->: Signaling Traffic 242 <===>: Data Traffic 244 Figure 1: SIP Trapezoid 246 The initial SIP signaling messages between Alice and Bob often take 247 place via the proxy servers. This exchange may be protected with TLS 248 (between SIP proxies but also between SIP UAs and SIP proxies) or 249 with SIP digest authentication between SIP UAs and the outbound 250 proxy. Further SIP security mechanisms should be used in combination 251 with this proposal. The security consideration section, see 252 Section 4, provides a discussion about the possible approaches to 253 secure the Host Identity Tag and to relate it ongoing session. 255 This allows two hosts to securely exchange keys even if there are 256 only domain-level public and private keys, as well as secure 257 associations within a domain, thus avoiding the need for a global 258 user-level PKI. 260 This initial message exchange is used to exchange Host Identities 261 between the end points within the SDP payload. 263 Subsequently, when both user agents Alice and Bob communicate 264 directly with each other they are able to reuse the Host Identity for 265 the HIP message exchange. 267 If the SIP communication does not involve third parties (i.e., SIP 268 proxies) and is therefore executed directly between the two SIP UAs 269 then it is not useful to exchange Host Identities in the SDP payloads 270 since the HIP exchange already took place before the first SIP 271 message can be exchanged between the two peers. Still HIP might 272 provide some advantages for the end-to-end communication, such as 273 providing security at the lower layer and mobility and multi-homing 274 support. 276 The security of this approach relies on two properties: 278 The signaling messages and the data traffic traverse a different 279 path. Hence, an adversary needs to be located where it is able to 280 see both, the signaling and the the data traffic. 282 The signaling traffic is often protected. 284 3.2. SDP Extension 286 This document proposes to enhance the SDP [6] 'k' or 'a' parameter. 288 The 'k' parameter has the following structure: 290 k=: 292 This document defines two new method fields: 294 k=host-identity: 296 k=host-identity-tag: 298 Alternatively, the 'a' parameter could be used like [7] proposes. An 299 example for MIKEY [21] is given in the reference, which could be 300 reused for HIP. As defined in [22], the 'a' parameter has the 301 following structure: 303 a=: 305 Similar to the MIKEY example in [7], this document defines two new 306 method fields: 308 a=key-mgmt:host-identity 310 a=key-mgmt:host-identity-tag 312 Both, the Host Identity and the Host Identity Tag are defined in [3]. 313 The Host Identity contains the public key and a number of 314 cryptographic parameters (such as used algorithms and Diffie-Hellmann 315 public parameters). The Host Identity is base64 encoded. 317 FOR DISCUSSION: 319 The usage of the k parameter as defined in [8] is deprecated. [6] 320 is more appropriate but like 'k=', they come with the caveat that 321 they require a secured e2e signaling path (or SDP is S/MIME 322 protected). One alternative is the usage of MIKEY for the 323 exchange as defined in [7]. 325 Furthermore, and probably more important, it is important to said 326 what the Host Identity is supposed to be used with. They may help 327 avoiding re-INVITEs when underlying IP addresses change to update 328 the 'Contact:' address as well as the addresses in the 'c=' lines 329 for the various media. 331 However, multiple devices may take part in the different media 332 sessions (your laptop doing video in parallel to your hardware IP 333 phone). To support these cases, it may be necessary to exchange 334 _several_ HI(T)s within SDP and denote what they shall be used 335 for. Such a mapping could naturally be achieved for each media 336 stream (even using 'k=' attributes); at simple 'a=' attributes (or 337 the mechanisms from [6]/ [7] would be preferred. 339 SDP only deals with media streams and does not have a notion of 340 user or main device in the background. Hence, the SIP HI(T) may 341 need to go into SIP signaling (rather than be carried in SDP). 343 Logically, this appears to belong to the 'Contact:' header which 344 may be conveyed protected in an S/MIME body (signed and 345 encrypted). 347 3.3. Example 349 This example contains the full details of the example session setup 350 taken from Section 4 of [1]. The message flow is shown in Figure 1 351 of [1] and resembles the architecture shown in Figure 1. Note that 352 these flows show the minimum required set of header fields; some 353 other header fields such as Allow and Supported would normally be 354 present. 356 In our example Alice uses the following Host Identity Tag 357 (7214148E0433AFE2FA2D48003D31172E) and Bob uses 358 (44A5C522D7EDEDF962E55A0677DB1346) as the HIT. These HITs correspond 359 to the following Host Identities (for convenience we reuse the XML 360 representation format used by the Boeing implementation). 362 ------ 363 Alice: 364 ------ 366 369 sip:alice@atlanta.com 371

D757262C4584C44C211F18BD96E5F061C4F0A423F7FE6B6B85B34CEF72CE14 372 A0D3A222FE08CECE65BE6C265854889DC1EDBD13EC8B274DA9F75BA26CCB98772 373 3602787E92BA84421F22C3C89CB9B06FD60FE01941DDD77FE6B12893DA76EEBC1 374 D128D97F0678D772B5341C8506F358214B16A2FAC4B368950387811C7DA33

376 C773218C737EC8EE993B4F2DED30F48EDACE915F 378 82269009E14EC474BAF2932E69D3B1F18517AD9594184CCDFCEAE96EC4D5EF 379 9313384B47093C52B20CD35D02492B3959EC6499625BC4FA5082E22C5B374E16D 380 D00132CE71020217091AC717B612391C76C1FB2E88317C1BD8171D41ECB83E210 381 C03CC9B32E81056C21621C73D6DAAC028F4B1585DA7F42519718CC9B09EEF 383 A4666AED5F5E753773DC961EDD0412A03F1F8D7CEC70A057076062804B86 384 619D3DA4E7610EBBDB05F44C5784622D1B86600DFCC1431BC4451D4FD31329354 385 07A9B24718CB82BAE93A4CDD9CC4C8B9A41C000AB53D52A65E8383F54F5BF92A8 386 21EA776A207C6991EF23808C00DB820977D97CAC01CB96307274E2386001327 387 389 7214148E0433AFE2FA2D48003D31172E 390 391 ---- 392 Bob: 393 ---- 395 398 sip:bob@biloxi.com 400

F13ACC1693AFD04B9E1E8D2A9DEA6DE8DE4C276BE2BF15B6CFF6E269B0169 401 378CB0DDDE23D187827015DC67E6768193914B823BDF215D0DAD7A151E434F9E 402 128DAFB9DEFAE07874621E70D7ED2D34B80A95FA8312B9564E4D118FB525664C 403 77D

405 C773218C737EC8EE993B4F2DED30F48EDACE915F 407 241F32CF48F424B1A75D33B7AE6088E745D9E24E653AE2CAEBE67E4AA1C11 408 15BA0CC25055A63C139235A95B36EFBC2064AF304C0F8A431D151B2B5854DE61 409 5168B45B9EAEBF9A88354CA7876E52D169E14E502BEA0CBB98B55AD2AB61620F 410 498 412 E481C20D8FBAA84F9C7ED8B5598F60F5A7D03951CA4783841EB8ADDC63D 413 DE11A2F3555C5641F465160AB1E016756D826B0F8CE4FDE33BA17F6FFFA751DA 414 1389A10E5599802AB1EBE4FD943405819A74FD6F1C9EA2815EE6B651610DF107 415 5D19F 417 44A5C522D7EDEDF962E55A0677DB1346 419 420 F1 INVITE Alice -> atlanta.com proxy 422 INVITE sip:bob@biloxi.com SIP/2.0 423 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 424 Max-Forwards: 70 425 To: Bob 426 From: Alice ;tag=1928301774 427 Call-ID: a84b4c76e66710 428 CSeq: 314159 INVITE 429 Contact: 430 Content-Type: application/sdp 431 Content-Length: ... 433 v=0 434 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 435 s=Session SDP 436 t=0 0 437 c=IN IP4 pc33.atlanta.com 438 m=audio 3456 RTP/AVP 0 1 3 99 439 a=rtpmap:0 PCMU/8000 440 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 442 F2 100 Trying atlanta.com proxy -> Alice 444 SIP/2.0 100 Trying 445 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 446 ;received=192.0.2.1 447 To: Bob 448 From: Alice ;tag=1928301774 449 Call-ID: a84b4c76e66710 450 CSeq: 314159 INVITE 451 Content-Length: 0 452 F3 INVITE atlanta.com proxy -> biloxi.com proxy 454 INVITE sip:bob@biloxi.com SIP/2.0 455 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 456 ;branch=z9hG4bK77ef4c2312983.1 457 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 458 ;received=192.0.2.1 459 Max-Forwards: 69 460 To: Bob 461 From: Alice ;tag=1928301774 462 Call-ID: a84b4c76e66710 463 CSeq: 314159 INVITE 464 Contact: 465 Content-Type: application/sdp 466 Content-Length: ... 468 v=0 469 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 470 s=Session SDP 471 t=0 0 472 c=IN IP4 pc33.atlanta.com 473 m=audio 3456 RTP/AVP 0 1 3 99 474 a=rtpmap:0 PCMU/8000 475 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 477 F4 100 Trying biloxi.com proxy -> atlanta.com proxy 479 SIP/2.0 100 Trying 480 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 481 ;branch=z9hG4bK77ef4c2312983.1 482 ;received=192.0.2.2 483 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 484 ;received=192.0.2.1 485 To: Bob 486 From: Alice ;tag=1928301774 487 Call-ID: a84b4c76e66710 488 CSeq: 314159 INVITE 489 Content-Length: 0 490 F5 INVITE biloxi.com proxy -> Bob 492 INVITE sip:bob@192.0.2.4 SIP/2.0 493 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 494 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 495 ;branch=z9hG4bK77ef4c2312983.1 496 ;received=192.0.2.2 497 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 498 ;received=192.0.2.1 499 Max-Forwards: 68 500 To: Bob 501 From: Alice ;tag=1928301774 502 Call-ID: a84b4c76e66710 503 CSeq: 314159 INVITE 504 Contact: 505 Content-Type: application/sdp 506 Content-Length: ... 508 v=0 509 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 510 s=Session SDP 511 t=0 0 512 c=IN IP4 pc33.atlanta.com 513 m=audio 3456 RTP/AVP 0 1 3 99 514 a=rtpmap:0 PCMU/8000 515 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 517 F6 180 Ringing Bob -> biloxi.com proxy 519 SIP/2.0 180 Ringing 520 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 521 ;received=192.0.2.3 522 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 523 ;branch=z9hG4bK77ef4c2312983.1 524 ;received=192.0.2.2 525 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 526 ;received=192.0.2.1 527 To: Bob ;tag=a6c85cf 528 From: Alice ;tag=1928301774 529 Call-ID: a84b4c76e66710 530 Contact: 531 CSeq: 314159 INVITE 532 Content-Length: 0 533 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy 535 SIP/2.0 180 Ringing 536 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 537 ;branch=z9hG4bK77ef4c2312983.1 538 ;received=192.0.2.2 539 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 540 ;received=192.0.2.1 541 To: Bob ;tag=a6c85cf 542 From: Alice ;tag=1928301774 543 Call-ID: a84b4c76e66710 544 Contact: 545 CSeq: 314159 INVITE 546 Content-Length: 0 548 F8 180 Ringing atlanta.com proxy -> Alice 550 SIP/2.0 180 Ringing 551 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 552 ;received=192.0.2.1 553 To: Bob ;tag=a6c85cf 554 From: Alice ;tag=1928301774 555 Call-ID: a84b4c76e66710 556 Contact: 557 CSeq: 314159 INVITE 558 Content-Length: 0 559 F9 200 OK Bob -> biloxi.com proxy 561 SIP/2.0 200 OK 562 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 563 ;received=192.0.2.3 564 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 565 ;branch=z9hG4bK77ef4c2312983.1 566 ;received=192.0.2.2 567 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 568 ;received=192.0.2.1 569 To: Bob ;tag=a6c85cf 570 From: Alice ;tag=1928301774 571 Call-ID: a84b4c76e66710 572 CSeq: 314159 INVITE 573 Contact: 574 Content-Type: application/sdp 575 Content-Length: ... 577 v=0 578 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 579 s=Session SDP 580 c=IN IP4 192.0.2.4 581 t=3034423619 0 582 m=audio 3456 RTP/AVP 0 583 a=rtpmap:0 PCMU/8000 584 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 585 F10 200 OK biloxi.com proxy -> atlanta.com proxy 587 SIP/2.0 200 OK 588 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 589 ;branch=z9hG4bK77ef4c2312983.1 590 ;received=192.0.2.2 591 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 592 ;received=192.0.2.1 593 To: Bob ;tag=a6c85cf 594 From: Alice ;tag=1928301774 595 Call-ID: a84b4c76e66710 596 CSeq: 314159 INVITE 597 Contact: 598 Content-Type: application/sdp 599 Content-Length: ... 601 v=0 602 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 603 s=Session SDP 604 c=IN IP4 192.0.2.4 605 t=3034423619 0 606 m=audio 3456 RTP/AVP 0 607 a=rtpmap:0 PCMU/8000 608 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 610 F11 200 OK atlanta.com proxy -> Alice 612 SIP/2.0 200 OK 613 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 614 ;received=192.0.2.1 615 To: Bob ;tag=a6c85cf 616 From: Alice ;tag=1928301774 617 Call-ID: a84b4c76e66710 618 CSeq: 314159 INVITE 619 Contact: 620 Content-Type: application/sdp 621 Content-Length: ... 623 v=0 624 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 625 s=Session SDP 626 c=IN IP4 192.0.2.4 627 t=3034423619 0 628 m=audio 3456 RTP/AVP 0 629 a=rtpmap:0 PCMU/8000 630 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 631 F12 ACK Alice -> Bob 633 ACK sip:bob@192.0.2.4 SIP/2.0 634 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 635 Max-Forwards: 70 636 To: Bob ;tag=a6c85cf 637 From: Alice ;tag=1928301774 638 Call-ID: a84b4c76e66710 639 CSeq: 314159 ACK 640 Content-Length: 0 642 The media session between Alice and Bob is now established. 644 The exchanged HITs are now placed in the pool of known HITs at both 645 end hosts. As such there is also a binding established between URI 646 and HIT at this point. 648 Next a regular HIP base exchange between Alice and Bob is started. 649 As part of the exchange the two end hosts inspect their known-HITs 650 pool and find the previously exchanged parameters. 652 Alice -> Bob: I1: Trigger exchange 654 Alice <- Bob: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 655 HIP Transform }SIG 657 Alice -> Bob: I2: {Solution, LSI(I), SPI(I), D-H(I), 658 ESP Transform, HIP Transform, {H(I)}SK }SIG 660 Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG 662 As a result of this exchange, two IPsec SAs (one for each direction) 663 is established. RTP media traffic can be exchanged between the two 664 end hosts, Alice and Bob, protected by IPsec. If end host mobility 665 takes place then a HIP readdressing exchange takes place which is not 666 detected at the upper layer by UDP/RTP or SIP. 668 4. Security Considerations 670 The standard HIP strategy for authenticating the communicating 671 parties is to give the Initiator and the Responder a Host Identity 672 and to assure the authenticity of the Host Identity via external 673 mechanisms, such as DNSSEC (if the Host Identities are stored in the 674 DNS). The Initiator then verifies the Host Identity and checks its 675 validity. The complexity of ensuring that the Host Identity has not 676 been tampered with is pushed to DNS (and DNSSEC), as the only 677 mechanism specified for ensuring that the public key is genuine. The 678 infrastructure provided for SIP can provide a similar, but more 679 deployment friendly, functionality when combined with already 680 available SIP security mechanisms. 682 The design described in this document is intended to leverage the 683 authenticity of the signaling channel (while not requiring 684 confidentiality). As long as each side of the connection can verify 685 the integrity of the SDP INVITE then the HIP base exchange handshake 686 cannot be hijacked via a man-in-the-middle attack. This integrity 687 protection is easily provided by the caller to the callee via the SIP 688 Identity [23] mechanism. However, it is less straightforward for the 689 responder. 691 Ideally Alice would want to know that Bob's SDP had not been tampered 692 with and who it was from so that Alice's User Agent could indicate to 693 Alice that there was a secure phone call to Bob. This is known as the 694 SIP Response Identity problem and is still a topic of ongoing work in 695 the SIP community. When a solution to the SIP Response Identity 696 problem is finalized, it SHOULD be used here. In the meantime there 697 are several approaches that can be used to mitigate this problem: Use 698 UPDATE, Use SIPS, Use S/MIME, and do nothing. Each one is discussed 699 here followed by the security implications of that approach. 701 4.1. UPDATE 703 In this approach, Bob sends an answer, then immediately follows up 704 with an UPDATE that includes the Host Identity Tag and uses the SIP 705 Identity mechanism to assert that the message is from Bob's. The 706 downside of this approach is that it requires the extra round trip of 707 the UPDATE. However, it is simple and secure even when the proxies 708 are not trusted. 710 4.2. SIPS 712 In this approach, the signaling is protected by TLS from hop to hop. 713 As long as all proxies are trusted, this provides integrity for the 714 Host Identity Tag. It does not provide a strong assertion of who 715 Alice is communicating with. However, as much as the target domain 716 can be trusted to correctly populate the From header field value, 717 Alice can use that. The security issue with this approach is that if 718 one of the Proxies wished to mount a man-in-the-middle attack, it 719 could convince Alice that she was talking to Bob when really the 720 media was flowing through a man in the middle media relay. However, 721 this attack could not convince Bob that he was taking to Alice. 723 4.3. S/MIME 725 RFC 3261 [1] defines a S/MIME security mechanism for SIP that could 726 be used to sign that the fingerprint was from Bob. This would be 727 secure. However, so far there have been no deployments of S/MIME for 728 SIP. 730 4.4. Single-sided Verification 732 In this approach, no integrity is provided for the fingerprint from 733 Bob to Alice. In this approach, an attacker that was on the 734 signaling path could tamper with the fingerprint and insert 735 themselves as a man-in-the-middle on the media. Alice would know 736 that she had a secure call with someone but would not know if it was 737 with Bob or a man-in-the-middle. Bob would know that an attack was 738 happening. The fact that one side can detect this attack means that 739 in most cases where Alice and Bob both wish the communications to be 740 encrypted there is not a problem. Keep in mind that in any of the 741 possible approaches Bob could always reveal the media that was 742 received to anyone. We are making the assumption that Bob also wants 743 secure communications. In this do nothing case, Bob knows the media 744 has not been tampered with or intercepted by a third party and that 745 it is from Alice. Alice knows that she is talking to someone and 746 that whoever that is has probably checked that the media is not being 747 intercepted or tampered with. This approach is certainly less than 748 ideal but very usable for many situations. An alternative available 749 to Alice and Bob is to use human speech to verified each others' 750 identity then verify each others' Host Identity Tags also using human 751 speech. Assuming that it is difficult to impersonate another's 752 speech and seamlessly modify the audio contents of a call, this 753 approach is relatively safe. On the other hand, SIP is not only used 754 for voice communication. 756 Note that this proposal is closely aligned towards the usage of the 757 'k' parameter in SDP [8]. As a difference, an asymmetric key is 758 exchanged unlike the proposals illustrated in Section 6 of [8]. 759 Section 5.12 of [22] is relevant for this discussion. 761 Please note that this approach is in a certain sense a re- 762 instantiation of the Purpose-Built-Key (PBK) idea (see [24]). With 763 PBK a hash of a public key is sent from node A to node B. If there 764 was no adversary between A and B at that time to modify the 765 transmitted hash value then subsequent communication interactions 766 which use the public key are secure. This proposal reuses the same 767 idea but focuses on the interworking between different protocols. In 768 fact it would be possible to use the same approach to exchange the 769 hash of an S/MIME certificate which can later be used in subsequent 770 SIP signaling message exchanges. 772 5. IANA Considerations 774 [Editor's Note: A future version of this document will provide a 775 discussion about IANA considerations.] 777 6. Open Issues 779 A list of open issues can be found at: 780 http://www.tschofenig.com:8080/sip-hip/ 782 7. Contributors 784 We would like to thank Vesa Torvinen for his contributions to the 785 initial version of this document. 787 8. Acknowledgments 789 The authors would like to thank Steffen Fries, Aarthi Nagarajan, 790 Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross 791 for their feedback. 793 The content of the security consideration section is based on DTLS- 794 SIP. 796 9. References 798 9.1. Normative References 800 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 801 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 802 Session Initiation Protocol", RFC 3261, June 2002. 804 [2] Moskowitz, R. and P. Nikander, "Host Identity Protocol 805 Architecture", draft-ietf-hip-arch-03 (work in progress), 806 August 2005. 808 [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-08 809 (work in progress), June 2007. 811 [4] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility 812 using SIP, ACM MC2R", , July 2000. 814 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 815 Levels", March 1997. 817 [6] Andreasen, F., "Session Description Protocol Security 818 Descriptions for Media Streams", 819 draft-ietf-mmusic-sdescriptions-12 (work in progress), 820 September 2005. 822 [7] Arkko, J., "Key Management Extensions for Session Description 823 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 824 draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. 826 [8] Handley, M. and V. Jacobson, "SDP: Session Description 827 Protocol", RFC 2327, April 1998. 829 9.2. Informative References 831 [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer 832 Method", RFC 3515, April 2003. 834 [10] Shacham, R., "Session Initiation Protocol (SIP) Session 835 Mobility", draft-shacham-sipping-session-mobility-03 (work in 836 progress), November 2006. 838 [11] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 839 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 840 progress), June 2006. 842 [12] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)", 843 draft-nikander-hiprg-hi3-00 (work in progress), June 2004. 845 [13] Rosenberg, J., "Session Traversal Utilities for (NAT) (STUN)", 846 draft-ietf-behave-rfc3489bis-06 (work in progress), March 2007. 848 [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 849 Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in 850 progress), March 2007. 852 [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 853 (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in progress), 854 March 2007. 856 [16] Schmitt, V., "HIP Extensions for the Traversal of Network 857 Address Translators", draft-ietf-hip-nat-traversal-01 (work in 858 progress), March 2007. 860 [17] Tschofenig, H. and M. Shanmugam, "Traversing HIP-aware NATs and 861 Firewalls: Problem Statement and Requirements", 862 draft-tschofenig-hiprg-hip-natfw-traversal-05 (work in 863 progress), October 2006. 865 [18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 866 Protocol for Network Address Translator (NAT) Traversal for 867 Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in 868 progress), June 2007. 870 [19] Jokela, P., "Using ESP transport format with HIP", 871 draft-ietf-hip-esp-06 (work in progress), June 2007. 873 [20] Tschofenig, H., "Using SRTP transport format with HIP", 874 draft-tschofenig-hiprg-hip-srtp-02 (work in progress), 875 October 2006. 877 [21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 878 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 879 August 2004. 881 [22] Handley, M., "SDP: Session Description Protocol", 882 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 884 [23] Peterson, J. and C. Jennings, "Enhancements for Authenticated 885 Identity Management in the Session Initiation Protocol (SIP)", 886 RFC 4474, August 2006. 888 [24] Bradner, S., Mankin, A., and J. Schiller, "A Framework for 889 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in 890 progress), June 2003. 892 [25] Jennings, C., "Certificate Management Service for The Session 893 Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in 894 progress), March 2007. 896 Authors' Addresses 898 Hannes Tschofenig 899 Nokia Siemens Networks 900 Otto-Hahn-Ring 6 901 Munich, Bavaria 81739 902 Germany 904 Phone: +49 89 636 40390 905 Email: Hannes.Tschofenig@nsn.com 906 URI: http://www.tschofenig.com 908 Joerg Ott 909 Helsinki University of Technology 910 Otakaari 5A 911 Espoo FI-02150 912 Finland 914 Email: jo@netlab.hut.fi 916 Henning Schulzrinne 917 Columbia University 918 Department of Computer Science 919 450 Computer Science Building 920 New York, NY 10027 921 USA 923 Phone: +1 212 939 7042 924 Email: schulzrinne@cs.columbia.edu 925 URI: http://www.cs.columbia.edu/~hgs 927 Thomas R. Henderson 928 The Boeing Company 929 P.O. Box 3707 930 Seattle, WA 931 USA 933 Email: thomas.r.henderson@boeing.com 934 Gonzalo Camarillo 935 Ericsson 936 Hirsalantie 11 937 Jorvas 02420 938 Finland 940 Email: Gonzalo.Camarillo@ericsson.com 942 Full Copyright Statement 944 Copyright (C) The IETF Trust (2007). 946 This document is subject to the rights, licenses and restrictions 947 contained in BCP 78, and except as set forth therein, the authors 948 retain all their rights. 950 This document and the information contained herein are provided on an 951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 953 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 954 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 955 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Intellectual Property 960 The IETF takes no position regarding the validity or scope of any 961 Intellectual Property Rights or other rights that might be claimed to 962 pertain to the implementation or use of the technology described in 963 this document or the extent to which any license under such rights 964 might or might not be available; nor does it represent that it has 965 made any independent effort to identify any such rights. Information 966 on the procedures with respect to rights in RFC documents can be 967 found in BCP 78 and BCP 79. 969 Copies of IPR disclosures made to the IETF Secretariat and any 970 assurances of licenses to be made available, or the result of an 971 attempt made to obtain a general license or permission for the use of 972 such proprietary rights by implementers or users of this 973 specification can be obtained from the IETF on-line IPR repository at 974 http://www.ietf.org/ipr. 976 The IETF invites any interested party to bring to its attention any 977 copyrights, patents or patent applications, or other proprietary 978 rights that may cover technology that may be required to implement 979 this standard. Please address the information to the IETF at 980 ietf-ipr@ietf.org. 982 Acknowledgment 984 Funding for the RFC Editor function is provided by the IETF 985 Administrative Support Activity (IASA).