idnits 2.17.00 (12 Aug 2021) /tmp/idnits33199/draft-tschofenig-hiprg-host-identities-02.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 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 RFC 3978 Section 5.4 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 (July 18, 2005) is 6151 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) == 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: A later version (-08) exists of draft-rosenberg-midcom-turn-07 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: A later version (-06) exists of draft-tschofenig-hiprg-hip-natfw-traversal-01 == 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: A later version (-02) exists of draft-tschofenig-hiprg-hip-srtp-00 == Outdated reference: draft-ietf-mmusic-sdp-new has been published as RFC 4566 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-certs-01 Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIPRG H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 19, 2006 J. Ott 5 Universitaet Bremen 6 H. Schulzrinne 7 Columbia U. 8 T. Henderson 9 The Boeing Company 10 G. Camarillo 11 Ericsson 12 July 18, 2005 14 Interaction between SIP and HIP 15 draft-tschofenig-hiprg-host-identities-02.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 January 19, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 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 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23 70 8.2 Informative References . . . . . . . . . . . . . . . . . . 23 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 72 Intellectual Property and Copyright Statements . . . . . . . . 27 74 1. Introduction 76 SIP [1] enables a pair of user agents to establish and maintain 77 sessions. The communication typically involves SIP proxies before 78 prior to communication between the end points taking place. As part 79 of the initial exchange, a number of parameters are exchanged. 80 Certain of these parameters are relevant to security. Examples of 81 such parameters are keying material and other cryptographic 82 information that is used in order to establish a security association 83 for the protection of subsequent data traffic. 85 HIP (see [2] and [3]) propose an architecture with a cryptographic 86 namespace and a layer between the network and the transport layer. 87 This layer is used in order to shield applications from the impact of 88 multi-homing, readdressing and mobility. A protocol, called the Host 89 Identity Protocol, is used in order to establish state at the two end 90 hosts. This state includes the establishment of IPsec SAs. 92 Several areas may benefit from the aformentioned interworking. These 93 include the following. 95 Mobility: 97 Mobility support can be provided at different layers in the 98 protocol stack. SIP can offer terminal mobility, as described in 99 [4]. Prior to a call, mobility is handled by re-registration with 100 the home registrar. For mid-call mobility, the moving node sends 101 a re-INVITE directly to the correspondent host, or via the SIP 102 proxies if, during the initial call setup, the proxy had inserted 103 a Record-Route header. Session mobility in SIP is implemented 104 through the usage of the SIP REFER method [9]. A discussion of 105 session mobility with SIP is, for example, provided in [10]. The 106 basic SIP security mechanisms are used in order to protect the 107 signalling exchanges that refer to the above-mentioned terminal 108 and session mobility. 110 The basic SIP mobility has two main limitations. Firstly, it is 111 unable to move TCP sessions to new IP addresses. This could be 112 accomplished by TCP extensions, such as TCP-Migrate or M-TCP or by 113 the usage of SCTP (where possible). The second limitation is the 114 low speed of handoffs. 116 One can shield the movement of the end hosts against each other 117 though the usage of HIP. HIP itself, however, does not offer 118 micromobility solutions or mechanisms to deal with the double- 119 movement problem. Extensions have been defined, such as the HIP 120 rendezvous concept [11] or Hi3 [12] that, among other things, deal 121 with initial reachability and provide additional mobility 122 mechanisms. A later version of this document will also 123 investigate the interworking of SIP with these HIP extensions. In 124 summary, current HIP mobility mechanisms do not offer substantial 125 additional features or security over what SIP provides. This 126 applies especially to the typical scenario where reliable 127 transport protocols are not used in SIP user data flows. 129 Middlebox Traversal: 131 The work on traversing Network Address Translators with SIP and 132 media traffic has focused on MIDCOM and the Interactive 133 Connectivity Establishment (ICE) methodology. ICE relies on other 134 protocols, such as STUN [13] and TURN [14] in order to create a 135 NAT binding. 137 HIP might be better suited for the traversal of HIP-aware NATs, 138 since, in this setting, the NATs can inspect the HIP signaling 139 exchange and create the necessary bindings. This approach is 140 similar to the one proposed by the NSIS working group where a 141 path-coupled signaling protocol is used to interact with these 142 middleboxes to create NAT bindings (and firewall pin-holes). The 143 NATFW-NSLP [15] is a protocol proposal that utilizes the NSIS 144 protocol suite. The travesal of HIP unaware NATs is detailed in 145 [16] and a discussion about NAT and firewall traversal of HIP- 146 aware devices is given in [17]. 148 Denial of Service Prevention: 150 SIP follows the offer/answer model. The offerer generates an 151 offer that contains, among other things, the IP address the 152 answerer is expected to send its media to. The offer/answer model 153 can be used in order to perform denial of service attacks against 154 third parties. The offerer generates an offer with the IP address 155 of the victim and the answerer, on reception of such offer, starts 156 sending media to the victim. If the session consists of media 157 sent over a connection-oriented transport protocol such as TCP, 158 the victim is unlikely to respond to the connection establishment 159 request (e.g. the initial SYN in TCP) and the connection is not 160 established. However, if the session consists of media sent over 161 RTP and UDP, the sender just floods the victim with RTP packets. 162 The ICMP "not reachable" messages generated by the victim may or 163 may not stop the attack. Firewalls in the path may discard these 164 packets or the RTP library of the sender may ignore them. The use 165 of HIP would prevent this type of attack because the victim would 166 not accept the incoming HIP message. Of course, in order to 167 further address this type of attack no user agent in the network 168 should accept session descriptions that only provide IP addresses 169 in order to send RTP data. Sessions that did not use HIP would 170 need to use a different method to deal with this attack. An 171 example of such a method consists of using ICE (Interactive 172 Connectivity Establishment) [18] as a return routability test 173 before starting to send media. Other approaches as part of the 174 HIP overlay infrastructure in combination with HIP Registration 175 servers might also provide the same effect or even a higher degree 176 of security. 178 SRTP and HIP: 180 The Host Identity Protocol is able to establish IPsec security 181 associations, as described in [19]. In the case of SIP for voice 182 communication, end-to-end media protection using SRTP may be 183 applied. HIP supports a variety of cryptographic protection 184 mechanisms for the data traffic, including IPsec, SRTP. The 185 establishment of the necessary parameters and the keying material 186 for enabling SRTP communication is outlined in a separate document 187 [20]. 189 Exchanging Host Identities with SIP: 191 HIP can benefit from existing SIP infrastructure because it 192 enables the distribution of Host Identities or Host Identity Tags, 193 as described in Section 3. 195 2. Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC 2119 [5]. 201 3. Exchanging Host Identities with SIP 203 3.1 Concept 205 In order to provide security between two HIP end hosts beyond 206 opportunistic encryption it is necessary to securely retrieve the 207 Host Identities. A number of mechanisms can be used including 208 directories (such as DNS) or more advanced concepts for example based 209 on Distributed Hash Tables typically used in peer-to-peer networks. 211 This document suggests to exchange the Host Identities (or Host 212 Identity Tags) as part of the initial SIP exchange inside the SDP 213 payload. As such, the Host Identities can also be bound to the user 214 identities - a concept not used in HIP. 216 The figure below illustrates the main idea: 218 +-----------+ +-----------+ 219 HI/HIT |SIP | HI/HIT |SIP | HI/HIT 220 +------>|Proxy |<---------->|Proxy |<------+ 221 | |Server X | TLS |Server Y | | 222 | +-----------+ +-----------+ | 223 | | 224 | TLS or TLS or | 225 | SIP Digest SIP Digest | 226 | | 227 | | 228 v v 229 +-----------+ SIP and HIP +-----------+ 230 |SIP | <---------------------------------> |SIP | 231 |User Agent | RTP |User Agent | 232 |Alice | <=================================> |Bob | 233 +-----------+ +-----------+ 235 Legend: 236 <--->: Signaling Traffic 237 <===>: Data Traffic 239 Figure 1: SIP Trapezoid 241 The initial SIP signaling messages between Alice and Bob often take 242 place via the proxy servers. This exchange may be protected with TLS 243 (between SIP proxies but also between SIP UAs and SIP proxies) or 244 with SIP digest authentication between SIP UAs and the outbound 245 proxy. Furthermore, SIP end-to-end security mechanisms are also 246 available with S/MIME. 248 This allows two hosts to securely exchange keys even if there are 249 only domain-level public and private keys, as well as secure 250 associations within a domain, thus avoiding the need for a global 251 user-level PKI. 253 This initial message exchange is used to exchange Host Identities 254 between the end points within the SDP payload. 256 Subsequently, when both user agents Alice and Bob communicate 257 directly with each other they are able to reuse the Host Identity for 258 the HIP message exchange. 260 If the SIP communication does not involve third parties (i.e., SIP 261 proxies) and is therefore executed directly between the two SIP UAs 262 then it is not useful to exchange Host Identities in the SDP payloads 263 since the HIP exchange already took place before the first SIP 264 message can be exchanged between the two peers. Still HIP might 265 provide some advantages for the end-to-end communication, such as 266 providing security at the lower layer and mobility and multi-homing 267 support. 269 The security of this approach relies on two properties: 271 The signaling messages and the data traffic traverse a different 272 path. Hence, an adversary needs to be located where it is able to 273 see both, the signaling and the the data traffic. 275 The signaling traffic is often protected. 277 3.2 SDP Extension 279 This document proposes to enhance the SDP [6] 'k' or 'a' parameter. 281 The 'k' parameter has the following structure: 283 k=: 285 This document defines two new method fields: 287 k=host-identity: 289 k=host-identity-tag: 291 Alternatively, the 'a' parameter could be used like [7] proposes. An 292 example for MIKEY [21] is given in the reference, which could be 293 reused for HIP. As defined in [22], the 'a' parameter has the 294 following structure: 296 a=: 298 Similar to the MIKEY example in [7], this document defines two new 299 method fields: 301 a=key-mgmt:host-identity 303 a=key-mgmt:host-identity-tag 305 Both, the Host Identity and the Host Identity Tag are defined in [3]. 306 The Host Identity contains the public key and a number of 307 cryptographic parameters (such as used algorithms and Diffie-Hellmann 308 public parameters). The Host Identity is base64 encoded. 310 FOR DISCUSSION: 312 The usage of the k parameter as defined in [8] is deprecated. [6] 313 is more appropriate but like 'k=', they come with the caveat that 314 they require a secured e2e signaling path (or SDP is S/MIME 315 protected). One alternative is the usage of MIKEY for the 316 exchange as defined in [7]. 318 Furthermore, and probably more important, it is important to said 319 what the Host Identity is supposed to be used with. They may help 320 avoiding re-INVITEs when underlying IP addresses change to update 321 the 'Contact:' address as well as the addresses in the 'c=' lines 322 for the various media. 324 However, multiple devices may take part in the different media 325 sessions (your laptop doing video in parallel to your hardware IP 326 phone). To support these cases, it may be necessary to exchange 327 _several_ HI(T)s within SDP and denote what they shall be used 328 for. Such a mapping could naturally be achieved for each media 329 stream (even using 'k=' attributes); at simple 'a=' attributes (or 330 the mechanisms from [6]/ [7] would be preferred. 332 SDP only deals with media streams and does not have a notion of 333 user or main device in the background. Hence, the SIP HI(T) may 334 need to go into SIP signaling (rather than be carried in SDP). 336 Logically, this appears to belong to the 'Contact:' header which 337 may be conveyed protected in an S/MIME body (signed and 338 encrypted). 340 3.3 Example 342 This example contains the full details of the example session setup 343 taken from Section 4 of [1]. The message flow is shown in Figure 1 344 of [1] and resembles the architecture shown in Figure 1. Note that 345 these flows show the minimum required set of header fields; some 346 other header fields such as Allow and Supported would normally be 347 present. 349 In our example Alice uses the following Host Identity Tag 350 (7214148E0433AFE2FA2D48003D31172E) and Bob uses 351 (44A5C522D7EDEDF962E55A0677DB1346) as the HIT. These HITs correspond 352 to the following Host Identities (for convenience we reuse the XML 353 representation format used by the Boeing implementation). 355 ------ 356 Alice: 357 ------ 359 362 sip:alice@atlanta.com 364

D757262C4584C44C211F18BD96E5F061C4F0A423F7FE6B6B85B34CEF72CE14 365 A0D3A222FE08CECE65BE6C265854889DC1EDBD13EC8B274DA9F75BA26CCB98772 366 3602787E92BA84421F22C3C89CB9B06FD60FE01941DDD77FE6B12893DA76EEBC1 367 D128D97F0678D772B5341C8506F358214B16A2FAC4B368950387811C7DA33

369 C773218C737EC8EE993B4F2DED30F48EDACE915F 371 82269009E14EC474BAF2932E69D3B1F18517AD9594184CCDFCEAE96EC4D5EF 372 9313384B47093C52B20CD35D02492B3959EC6499625BC4FA5082E22C5B374E16D 373 D00132CE71020217091AC717B612391C76C1FB2E88317C1BD8171D41ECB83E210 374 C03CC9B32E81056C21621C73D6DAAC028F4B1585DA7F42519718CC9B09EEF 376 A4666AED5F5E753773DC961EDD0412A03F1F8D7CEC70A057076062804B86 377 619D3DA4E7610EBBDB05F44C5784622D1B86600DFCC1431BC4451D4FD31329354 378 07A9B24718CB82BAE93A4CDD9CC4C8B9A41C000AB53D52A65E8383F54F5BF92A8 379 21EA776A207C6991EF23808C00DB820977D97CAC01CB96307274E2386001327 380 382 7214148E0433AFE2FA2D48003D31172E 383 384 ---- 385 Bob: 386 ---- 388 391 sip:bob@biloxi.com 393

F13ACC1693AFD04B9E1E8D2A9DEA6DE8DE4C276BE2BF15B6CFF6E269B0169 394 378CB0DDDE23D187827015DC67E6768193914B823BDF215D0DAD7A151E434F9E 395 128DAFB9DEFAE07874621E70D7ED2D34B80A95FA8312B9564E4D118FB525664C 396 77D

398 C773218C737EC8EE993B4F2DED30F48EDACE915F 400 241F32CF48F424B1A75D33B7AE6088E745D9E24E653AE2CAEBE67E4AA1C11 401 15BA0CC25055A63C139235A95B36EFBC2064AF304C0F8A431D151B2B5854DE61 402 5168B45B9EAEBF9A88354CA7876E52D169E14E502BEA0CBB98B55AD2AB61620F 403 498 405 E481C20D8FBAA84F9C7ED8B5598F60F5A7D03951CA4783841EB8ADDC63D 406 DE11A2F3555C5641F465160AB1E016756D826B0F8CE4FDE33BA17F6FFFA751DA 407 1389A10E5599802AB1EBE4FD943405819A74FD6F1C9EA2815EE6B651610DF107 408 5D19F 410 44A5C522D7EDEDF962E55A0677DB1346 412 413 F1 INVITE Alice -> atlanta.com proxy 415 INVITE sip:bob@biloxi.com SIP/2.0 416 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 417 Max-Forwards: 70 418 To: Bob 419 From: Alice ;tag=1928301774 420 Call-ID: a84b4c76e66710 421 CSeq: 314159 INVITE 422 Contact: 423 Content-Type: application/sdp 424 Content-Length: ... 426 v=0 427 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 428 s=Session SDP 429 t=0 0 430 c=IN IP4 pc33.atlanta.com 431 m=audio 3456 RTP/AVP 0 1 3 99 432 a=rtpmap:0 PCMU/8000 433 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 435 F2 100 Trying atlanta.com proxy -> Alice 437 SIP/2.0 100 Trying 438 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 439 ;received=192.0.2.1 440 To: Bob 441 From: Alice ;tag=1928301774 442 Call-ID: a84b4c76e66710 443 CSeq: 314159 INVITE 444 Content-Length: 0 445 F3 INVITE atlanta.com proxy -> biloxi.com proxy 447 INVITE sip:bob@biloxi.com SIP/2.0 448 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 449 ;branch=z9hG4bK77ef4c2312983.1 450 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 451 ;received=192.0.2.1 452 Max-Forwards: 69 453 To: Bob 454 From: Alice ;tag=1928301774 455 Call-ID: a84b4c76e66710 456 CSeq: 314159 INVITE 457 Contact: 458 Content-Type: application/sdp 459 Content-Length: ... 461 v=0 462 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 463 s=Session SDP 464 t=0 0 465 c=IN IP4 pc33.atlanta.com 466 m=audio 3456 RTP/AVP 0 1 3 99 467 a=rtpmap:0 PCMU/8000 468 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 470 F4 100 Trying biloxi.com proxy -> atlanta.com proxy 472 SIP/2.0 100 Trying 473 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 474 ;branch=z9hG4bK77ef4c2312983.1 475 ;received=192.0.2.2 476 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 477 ;received=192.0.2.1 478 To: Bob 479 From: Alice ;tag=1928301774 480 Call-ID: a84b4c76e66710 481 CSeq: 314159 INVITE 482 Content-Length: 0 483 F5 INVITE biloxi.com proxy -> Bob 485 INVITE sip:bob@192.0.2.4 SIP/2.0 486 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 487 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 488 ;branch=z9hG4bK77ef4c2312983.1 489 ;received=192.0.2.2 490 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 491 ;received=192.0.2.1 492 Max-Forwards: 68 493 To: Bob 494 From: Alice ;tag=1928301774 495 Call-ID: a84b4c76e66710 496 CSeq: 314159 INVITE 497 Contact: 498 Content-Type: application/sdp 499 Content-Length: ... 501 v=0 502 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 503 s=Session SDP 504 t=0 0 505 c=IN IP4 pc33.atlanta.com 506 m=audio 3456 RTP/AVP 0 1 3 99 507 a=rtpmap:0 PCMU/8000 508 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 510 F6 180 Ringing Bob -> biloxi.com proxy 512 SIP/2.0 180 Ringing 513 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 514 ;received=192.0.2.3 515 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 516 ;branch=z9hG4bK77ef4c2312983.1 517 ;received=192.0.2.2 518 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 519 ;received=192.0.2.1 520 To: Bob ;tag=a6c85cf 521 From: Alice ;tag=1928301774 522 Call-ID: a84b4c76e66710 523 Contact: 524 CSeq: 314159 INVITE 525 Content-Length: 0 526 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy 528 SIP/2.0 180 Ringing 529 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 530 ;branch=z9hG4bK77ef4c2312983.1 531 ;received=192.0.2.2 532 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 533 ;received=192.0.2.1 534 To: Bob ;tag=a6c85cf 535 From: Alice ;tag=1928301774 536 Call-ID: a84b4c76e66710 537 Contact: 538 CSeq: 314159 INVITE 539 Content-Length: 0 541 F8 180 Ringing atlanta.com proxy -> Alice 543 SIP/2.0 180 Ringing 544 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 545 ;received=192.0.2.1 546 To: Bob ;tag=a6c85cf 547 From: Alice ;tag=1928301774 548 Call-ID: a84b4c76e66710 549 Contact: 550 CSeq: 314159 INVITE 551 Content-Length: 0 552 F9 200 OK Bob -> biloxi.com proxy 554 SIP/2.0 200 OK 555 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 556 ;received=192.0.2.3 557 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 558 ;branch=z9hG4bK77ef4c2312983.1 559 ;received=192.0.2.2 560 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 561 ;received=192.0.2.1 562 To: Bob ;tag=a6c85cf 563 From: Alice ;tag=1928301774 564 Call-ID: a84b4c76e66710 565 CSeq: 314159 INVITE 566 Contact: 567 Content-Type: application/sdp 568 Content-Length: ... 570 v=0 571 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 572 s=Session SDP 573 c=IN IP4 192.0.2.4 574 t=3034423619 0 575 m=audio 3456 RTP/AVP 0 576 a=rtpmap:0 PCMU/8000 577 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 578 F10 200 OK biloxi.com proxy -> atlanta.com proxy 580 SIP/2.0 200 OK 581 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 582 ;branch=z9hG4bK77ef4c2312983.1 583 ;received=192.0.2.2 584 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 585 ;received=192.0.2.1 586 To: Bob ;tag=a6c85cf 587 From: Alice ;tag=1928301774 588 Call-ID: a84b4c76e66710 589 CSeq: 314159 INVITE 590 Contact: 591 Content-Type: application/sdp 592 Content-Length: ... 594 v=0 595 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 596 s=Session SDP 597 c=IN IP4 192.0.2.4 598 t=3034423619 0 599 m=audio 3456 RTP/AVP 0 600 a=rtpmap:0 PCMU/8000 601 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 603 F11 200 OK atlanta.com proxy -> Alice 605 SIP/2.0 200 OK 606 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 607 ;received=192.0.2.1 608 To: Bob ;tag=a6c85cf 609 From: Alice ;tag=1928301774 610 Call-ID: a84b4c76e66710 611 CSeq: 314159 INVITE 612 Contact: 613 Content-Type: application/sdp 614 Content-Length: ... 616 v=0 617 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 618 s=Session SDP 619 c=IN IP4 192.0.2.4 620 t=3034423619 0 621 m=audio 3456 RTP/AVP 0 622 a=rtpmap:0 PCMU/8000 623 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 624 F12 ACK Alice -> Bob 626 ACK sip:bob@192.0.2.4 SIP/2.0 627 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 628 Max-Forwards: 70 629 To: Bob ;tag=a6c85cf 630 From: Alice ;tag=1928301774 631 Call-ID: a84b4c76e66710 632 CSeq: 314159 ACK 633 Content-Length: 0 635 The media session between Alice and Bob is now established. 637 The exchanged HITs are now placed in the pool of known HITs at both 638 end hosts. As such there is also a binding established between URI 639 and HIT at this point. 641 Next a regular HIP base exchange between Alice and Bob is started. 642 As part of the exchange the two end hosts inspect their known-HITs 643 pool and find the previously exchanged parameters. 645 Alice -> Bob: I1: Trigger exchange 647 Alice <- Bob: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 648 HIP Transform }SIG 650 Alice -> Bob: I2: {Solution, LSI(I), SPI(I), D-H(I), 651 ESP Transform, HIP Transform, {H(I)}SK }SIG 653 Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG 655 As a result of this exchange, two IPsec SAs (one for each direction) 656 is established. RTP media traffic can be exchanged between the two 657 end hosts, Alice and Bob, protected by IPsec. If end host mobility 658 takes place then a HIP readdressing exchange takes place which is not 659 detected at the upper layer by UDP/RTP or SIP. 661 4. Security Considerations 663 The security considerations currently deal with the proposal of 664 exchanging Host Identities within SIP. A future version of this 665 document will investigate security considerations that address other 666 parts of the interworking as well. 668 This proposal is closely aligned towards the usage of the 'k' 669 parameter in SDP [8]. As a difference, an asymmetric key is 670 exchanged unlike the proposals illustrated in Section 6 of [8]. 671 Section 5.12 of [22] is relevant for this discussion. 673 If an adversary aims to impersonate one of the SIP UAs in the 674 subsequent HIP exchange then it is necessary to replace the Host 675 Identity/Host Identity Tag exchanged in the SIP/SDP messages. 677 Please note that this approach is in a certain sense a re- 678 instantiation of the Purpose-Built-Key (PBK) idea (see [23]). With 679 PBK a hash of a public key is sent from node A to node B. If there 680 was no adversary between A and B at that time to modify the 681 transmitted hash value then subsequent communication interactions 682 which use the public key are secure. This proposal reuses the same 683 idea but focuses on the interworking between different protocols. In 684 fact it would be possible to use the same approach to exchange the 685 hash of an S/MIME certificate which can later be used in subsequent 686 SIP signaling message exchanges. 688 If Host Identities for HIP can be retrieved using a different, more 689 secure method then the Host Identities exchanged with SIP/SDP MUST 690 NOT be used. 692 5. Open Issues 694 The authors came accross a number of open issues while thinking about 695 this topic: 697 o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute 698 Host Identities. This approach is particularly interesting, if 699 Host Identities are subject to frequent change. As such, it would 700 resemble the proposal provided with SIPPING-CERT [24]. Thereby 701 the user agent would be allowed to upload its own Host Identity to 702 the Credential Server. Other user agents would use the SUBSCRIBE 703 method to retrieve Host Identities of a particular user. With the 704 help of the NOTIFY message it is possible to learn about a changed 705 Host Identity (e.g., a revoked HI). It is for further study 706 whether this is more useful than the already described proposal. 708 o Is an IANA registration for the method field required? 710 o Is it possible to carry more than one Host Identity/Host Identity 711 Tag in the SDP payload by listing more than one 'k' parameter? 713 o Further investigations are required with regard to the mobility 714 functionality provided by HIP and the potential benefits for end- 715 to-end signaling using SIP, RTP etc. between the SIP UAs. 717 o Middlebox traversal functionality discussed in the context of HIP 718 (such as STUN, TURN, ICE) could potentially be replaced by the HIP 719 middlebox traversal functionality. 721 6. Contributors 723 We would like to thank Vesa Torvinen for his contributions to the 724 initial version of this document. 726 7. Acknowledgments 728 The authors would like to thank Steffen Fries, Aarthi Nagarajan, 729 Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross 730 for their feedback. 732 8. References 734 8.1 Normative References 736 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 737 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 738 Session Initiation Protocol", RFC 3261, June 2002. 740 [2] Moskowitz, R., "Host Identity Protocol Architecture", 741 draft-ietf-hip-arch-02 (work in progress), January 2005. 743 [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 744 (work in progress), June 2005. 746 [4] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility 747 using SIP, ACM MC2R", , July 2000. 749 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 750 Levels", March 1997. 752 [6] Andreasen, F., "Session Description Protocol Security 753 Descriptions for Media Streams", 754 draft-ietf-mmusic-sdescriptions-11 (work in progress), 755 June 2005. 757 [7] Arkko, J., "Key Management Extensions for Session Description 758 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 759 draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005. 761 [8] Handley, M. and V. Jacobson, "SDP: Session Description 762 Protocol", RFC 2327, April 1998. 764 8.2 Informative References 766 [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer 767 Method", RFC 3515, April 2003. 769 [10] Shacham, R., "Session Initiation Protocol (SIP) Session 770 Mobility", draft-shacham-sipping-session-mobility-01 (work in 771 progress), July 2005. 773 [11] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 774 Rendezvous Extension", draft-ietf-hip-rvs-03 (work in 775 progress), July 2005. 777 [12] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)", 778 draft-nikander-hiprg-hi3-00 (work in progress), June 2004. 780 [13] Rosenberg, J., "Simple Traversal of UDP Through Network Address 781 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-01 782 (work in progress), February 2005. 784 [14] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 785 draft-rosenberg-midcom-turn-07 (work in progress), 786 February 2005. 788 [15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 789 (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), 790 May 2005. 792 [16] Stiemerling, M., "Middlebox Traversal Issues of Host Identity 793 Protocol (HIP) Communication", draft-stiemerling-hip-nat-05 794 (work in progress), July 2005. 796 [17] Tschofenig, H., "NAT and Firewall Traversal for HIP", 797 draft-tschofenig-hiprg-hip-natfw-traversal-01 (work in 798 progress), February 2005. 800 [18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 801 Methodology for Network Address Translator (NAT) Traversal for 802 Multimedia Session Establishment Protocols", 803 draft-ietf-mmusic-ice-04 (work in progress), February 2005. 805 [19] Jokela, P., "Using ESP transport format with HIP", 806 draft-ietf-hip-esp-00 (work in progress), July 2005. 808 [20] Tschofenig, H., "Using SRTP transport format with HIP", 809 draft-tschofenig-hiprg-hip-srtp-00 (work in progress), 810 July 2005. 812 [21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 813 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 814 August 2004. 816 [22] Handley, M., "SDP: Session Description Protocol", 817 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 819 [23] Bradner, S., Mankin, A., and J. Schiller, "A Framework for 820 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in 821 progress), June 2003. 823 [24] Jennings, C. and J. Peterson, "Certificate Management Service 824 for The Session Initiation Protocol (SIP)", 825 draft-ietf-sipping-certs-01 (work in progress), February 2005. 827 Authors' Addresses 829 Hannes Tschofenig 830 Siemens 831 Otto-Hahn-Ring 6 832 Munich, Bavaria 81739 833 Germany 835 Email: Hannes.Tschofenig@siemens.com 837 Joerg Ott 838 Universitaet Bremen 839 Bibliothekstr. 1 840 Bremen 28359 841 Germany 843 Email: jo@tzi.org 845 Henning Schulzrinne 846 Columbia University 847 Department of Computer Science 848 450 Computer Science Building 849 New York, NY 10027 850 USA 852 Phone: +1 212 939 7042 853 Email: schulzrinne@cs.columbia.edu 854 URI: http://www.cs.columbia.edu/~hgs 856 Thomas R. Henderson 857 The Boeing Company 858 P.O. Box 3707 859 Seattle, WA 860 USA 862 Email: thomas.r.henderson@boeing.com 863 Gonzalo Camarillo 864 Ericsson 865 Hirsalantie 11 866 Jorvas 02420 867 Finland 869 Email: Gonzalo.Camarillo@ericsson.com 871 Intellectual Property Statement 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Disclaimer of Validity 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 900 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 901 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 902 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Copyright Statement 907 Copyright (C) The Internet Society (2005). This document is subject 908 to the rights, licenses and restrictions contained in BCP 78, and 909 except as set forth therein, the authors retain all their rights. 911 Acknowledgment 913 Funding for the RFC Editor function is currently provided by the 914 Internet Society.