idnits 2.17.00 (12 Aug 2021) /tmp/idnits36743/draft-tschofenig-hiprg-host-identities-01.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.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 549: '...Identities exchanged with SIP/SDP MUST...' 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 (October 2004) is 6427 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: '7' is defined on line 619, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: 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') == Outdated reference: draft-ietf-mmusic-sdescriptions has been published as RFC 4568 ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) == Outdated reference: draft-ietf-mmusic-kmgmt-ext has been published as RFC 4567 -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: draft-ietf-mmusic-sdp-new has been published as RFC 4566 Summary: 9 errors (**), 0 flaws (~~), 8 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: April 4, 2005 J. Ott 5 Universitaet Bremen 6 H. Schulzrinne 7 Columbia U. 8 T. Henderson 9 The Boeing Company 10 G. Camarillo 11 Ericsson 12 October 2004 14 Exchanging Host Identities in SIP 15 draft-tschofenig-hiprg-host-identities-01.txt 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 4, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 This document proposes to exchange Host Identities (or Host Identity 50 Tags) in SIP/SDP for later usage in the Host Identity Protocol 51 Protocol (HIP) between the SIP user agents. As such, it is a first 52 step in investigating the interaction between SIP and HIP and mainly 53 a discussion document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 61 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 62 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . 21 66 8.2 Informative References . . . . . . . . . . . . . . . . . . 21 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 68 Intellectual Property and Copyright Statements . . . . . . . . 24 70 1. Introduction 72 SIP [1] allows to establish and maintain sessions between two user 73 agents. The communication typically involves SIP proxies before 74 direct communication between the end points takes place. As part of 75 the initial communication exchange a number of parameters are 76 exchanged including security relevant parameters, such as keying 77 material and cryptographic information to establish a security 78 association for subsequent data traffic protection. 80 HIP (see [2] and [3]) creates an architecture with a new, 81 cryptographic namespace and a new layer between the network and the 82 transport layer to shield applications from the impact of multi- 83 homing, readdressing and mobility. A protocol, the Host Identity 84 Protocol, is used to establish state at the two end hosts. This 85 state includes the establishment of IPsec SAs. 87 In order to provide security between two HIP end hosts beyond 88 opportunistic encryption it is necessary to securely retrieve the 89 Host Identities. A number of mechanisms can be used including 90 directories (such as DNS) or more advanced concepts for example based 91 on Distributed Hash Tables typically used in peer-to-peer networks. 93 This document suggests to exchange the Host Identities (or Host 94 Identity Tags) as part of the initial SIP exchange inside the SDP 95 payload. As such, the Host Identities can also be bound to the user 96 identities - a concept not used in HIP. 98 The figure below illustrates the main idea: 100 +-----------+ +-----------+ 101 HI/HIT |SIP | HI/HIT |SIP | HI/HIT 102 +------>|Proxy |<---------->|Proxy |<------+ 103 | |Server X | TLS |Server Y | | 104 | +-----------+ +-----------+ | 105 | | 106 | TLS or TLS or | 107 | SIP Digest SIP Digest | 108 | | 109 | | 110 v v 111 +-----------+ SIP and HIP +-----------+ 112 |SIP | <---------------------------------> |SIP | 113 |User Agent | RTP |User Agent | 114 |Alice | <=================================> |Bob | 115 +-----------+ +-----------+ 117 Legend: 118 <--->: Signaling Traffic 119 <===>: Data Traffic 121 Figure 1: SIP Trapezoid 123 The initial SIP signaling messages between Alice and Bob often take 124 place via the proxy servers. This exchange may be protected with TLS 125 (between SIP proxies but also between SIP UAs and SIP proxies) or 126 with SIP digest authentication between SIP UAs and the outbound 127 proxy. Furthermore, SIP end-to-end security mechanisms are also 128 available with S/MIME. 130 This allows two hosts to securely exchange keys even if there are 131 only domain-level public and private keys, as well as secure 132 associations within a domain, thus avoiding the need for a global 133 user-level PKI. 135 This initial message exchange is used to exchange Host Identities 136 between the end points within the SDP payload. 138 Subsequently, when both user agents Alice and Bob communicate 139 directly with each other they are able to reuse the Host Identity for 140 the HIP message exchange. 142 If the SIP communication does not involve third parties (i.e., SIP 143 proxies) and is therefore executed directly between the two SIP UAs 144 then it is not useful to exchange Host Identities in the SDP payloads 145 since the HIP exchange already took place before the first SIP 146 message can be exchanged between the two peers. Still HIP might 147 provide some advantages for the end-to-end communication, such as 148 providing security at the lower layer and mobility and multi-homing 149 support. 151 The security of this approach relies on two properties: 153 The signaling messages and the data traffic traverse a different 154 path. Hence, an adversary needs to be located where it is able to 155 see both, the signaling and the the data traffic. 157 The signaling traffic is often protected. 159 2. SDP Extension 161 This document proposes to enhance the SDP [4] 'k' parameter. 163 This parameter has the following structure: k=. This document defines two new method fields: 166 k=host-identity: 168 k=host-identity-tag: 170 Both, the Host Identity and the Host Identity Tag are defined in [3]. 171 The Host Identity contains the public key and a number of 172 cryptographic parameters (such as used algorithms and Diffie-Hellmann 173 public parameters). The Host Identity is base64 encoded. 175 FOR DISCUSSION: 177 The usage of the k parameter as defined in [5] is deprecated. [4] 178 is more appropriate but like 'k=', they come with the caveat that 179 they require a secured e2e signaling path (or SDP is S/MIME 180 protected). One alternative is the usage of MIKEY for the 181 exchange as defined in [6]. 183 Furthermore, and probably more important, it is important to said 184 what the Host Identity is supposed to be used with. They may help 185 avoiding re-INVITEs when underlying IP addresses change to update 186 the 'Contact:' address as well as the addresses in the 'c=' lines 187 for the various media. 189 However, multiple devices may take part in the different media 190 sessions (your laptop doing video in parallel to your hardware IP 191 phone). To support these cases, it may be necessary to exchange 192 _several_ HI(T)s within SDP and denote what they shall be used 193 for. Such a mapping could naturally be achieved for each media 194 stream (even using 'k=' attributes); at simple 'a=' attributes (or 195 the mechanisms from [4]/ [6] would be preferred. 197 SDP only deals with media streams and does not have a notion of 198 user or main device in the background. Hence, the SIP HI(T) may 199 need to go into SIP signaling (rather than be carried in SDP). 201 Logically, this appears to belong to the 'Contact:' header which 202 may be conveyed protected in an S/MIME body (signed and 203 encrypted). 205 3. Example 207 This example contains the full details of the example session setup 208 taken from Section 4 of [1]. The message flow is shown in Figure 1 209 of [1] and resembles the architecture shown in Figure 1. Note that 210 these flows show the minimum required set of header fields; some 211 other header fields such as Allow and Supported would normally be 212 present. 214 In our example Alice uses the following Host Identity Tag 215 (7214148E0433AFE2FA2D48003D31172E) and Bob uses 216 (44A5C522D7EDEDF962E55A0677DB1346) as the HIT. These HITs correspond 217 to the following Host Identities (for convenience we reuse the XML 218 representation format used by the Boeing implementation). 220 ------ 221 Alice: 222 ------ 224 227 sip:alice@atlanta.com 229

D757262C4584C44C211F18BD96E5F061C4F0A423F7FE6B6B85B34CEF72CE14 230 A0D3A222FE08CECE65BE6C265854889DC1EDBD13EC8B274DA9F75BA26CCB98772 231 3602787E92BA84421F22C3C89CB9B06FD60FE01941DDD77FE6B12893DA76EEBC1 232 D128D97F0678D772B5341C8506F358214B16A2FAC4B368950387811C7DA33

234 C773218C737EC8EE993B4F2DED30F48EDACE915F 236 82269009E14EC474BAF2932E69D3B1F18517AD9594184CCDFCEAE96EC4D5EF 237 9313384B47093C52B20CD35D02492B3959EC6499625BC4FA5082E22C5B374E16D 238 D00132CE71020217091AC717B612391C76C1FB2E88317C1BD8171D41ECB83E210 239 C03CC9B32E81056C21621C73D6DAAC028F4B1585DA7F42519718CC9B09EEF 241 A4666AED5F5E753773DC961EDD0412A03F1F8D7CEC70A057076062804B86 242 619D3DA4E7610EBBDB05F44C5784622D1B86600DFCC1431BC4451D4FD31329354 243 07A9B24718CB82BAE93A4CDD9CC4C8B9A41C000AB53D52A65E8383F54F5BF92A8 244 21EA776A207C6991EF23808C00DB820977D97CAC01CB96307274E2386001327 245 247 7214148E0433AFE2FA2D48003D31172E 248 249 ---- 250 Bob: 251 ---- 253 256 sip:bob@biloxi.com 258

F13ACC1693AFD04B9E1E8D2A9DEA6DE8DE4C276BE2BF15B6CFF6E269B0169 259 378CB0DDDE23D187827015DC67E6768193914B823BDF215D0DAD7A151E434F9E 260 128DAFB9DEFAE07874621E70D7ED2D34B80A95FA8312B9564E4D118FB525664C 261 77D

263 C773218C737EC8EE993B4F2DED30F48EDACE915F 265 241F32CF48F424B1A75D33B7AE6088E745D9E24E653AE2CAEBE67E4AA1C11 266 15BA0CC25055A63C139235A95B36EFBC2064AF304C0F8A431D151B2B5854DE61 267 5168B45B9EAEBF9A88354CA7876E52D169E14E502BEA0CBB98B55AD2AB61620F 268 498 270 E481C20D8FBAA84F9C7ED8B5598F60F5A7D03951CA4783841EB8ADDC63D 271 DE11A2F3555C5641F465160AB1E016756D826B0F8CE4FDE33BA17F6FFFA751DA 272 1389A10E5599802AB1EBE4FD943405819A74FD6F1C9EA2815EE6B651610DF107 273 5D19F 275 44A5C522D7EDEDF962E55A0677DB1346 277 278 F1 INVITE Alice -> atlanta.com proxy 280 INVITE sip:bob@biloxi.com SIP/2.0 281 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 282 Max-Forwards: 70 283 To: Bob 284 From: Alice ;tag=1928301774 285 Call-ID: a84b4c76e66710 286 CSeq: 314159 INVITE 287 Contact: 288 Content-Type: application/sdp 289 Content-Length: ... 291 v=0 292 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 293 s=Session SDP 294 t=0 0 295 c=IN IP4 pc33.atlanta.com 296 m=audio 3456 RTP/AVP 0 1 3 99 297 a=rtpmap:0 PCMU/8000 298 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 300 F2 100 Trying atlanta.com proxy -> Alice 302 SIP/2.0 100 Trying 303 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 304 ;received=192.0.2.1 305 To: Bob 306 From: Alice ;tag=1928301774 307 Call-ID: a84b4c76e66710 308 CSeq: 314159 INVITE 309 Content-Length: 0 310 F3 INVITE atlanta.com proxy -> biloxi.com proxy 312 INVITE sip:bob@biloxi.com SIP/2.0 313 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 314 ;branch=z9hG4bK77ef4c2312983.1 315 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 316 ;received=192.0.2.1 317 Max-Forwards: 69 318 To: Bob 319 From: Alice ;tag=1928301774 320 Call-ID: a84b4c76e66710 321 CSeq: 314159 INVITE 322 Contact: 323 Content-Type: application/sdp 324 Content-Length: ... 326 v=0 327 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 328 s=Session SDP 329 t=0 0 330 c=IN IP4 pc33.atlanta.com 331 m=audio 3456 RTP/AVP 0 1 3 99 332 a=rtpmap:0 PCMU/8000 333 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 335 F4 100 Trying biloxi.com proxy -> atlanta.com proxy 337 SIP/2.0 100 Trying 338 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 339 ;branch=z9hG4bK77ef4c2312983.1 340 ;received=192.0.2.2 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 F5 INVITE biloxi.com proxy -> Bob 350 INVITE sip:bob@192.0.2.4 SIP/2.0 351 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 352 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 353 ;branch=z9hG4bK77ef4c2312983.1 354 ;received=192.0.2.2 355 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 356 ;received=192.0.2.1 357 Max-Forwards: 68 358 To: Bob 359 From: Alice ;tag=1928301774 360 Call-ID: a84b4c76e66710 361 CSeq: 314159 INVITE 362 Contact: 363 Content-Type: application/sdp 364 Content-Length: ... 366 v=0 367 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com 368 s=Session SDP 369 t=0 0 370 c=IN IP4 pc33.atlanta.com 371 m=audio 3456 RTP/AVP 0 1 3 99 372 a=rtpmap:0 PCMU/8000 373 k=host-identity-tag:7214148E0433AFE2FA2D48003D31172E 375 F6 180 Ringing Bob -> biloxi.com proxy 377 SIP/2.0 180 Ringing 378 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 379 ;received=192.0.2.3 380 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 381 ;branch=z9hG4bK77ef4c2312983.1 382 ;received=192.0.2.2 383 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 384 ;received=192.0.2.1 385 To: Bob ;tag=a6c85cf 386 From: Alice ;tag=1928301774 387 Call-ID: a84b4c76e66710 388 Contact: 389 CSeq: 314159 INVITE 390 Content-Length: 0 391 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy 393 SIP/2.0 180 Ringing 394 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 395 ;branch=z9hG4bK77ef4c2312983.1 396 ;received=192.0.2.2 397 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 398 ;received=192.0.2.1 399 To: Bob ;tag=a6c85cf 400 From: Alice ;tag=1928301774 401 Call-ID: a84b4c76e66710 402 Contact: 403 CSeq: 314159 INVITE 404 Content-Length: 0 406 F8 180 Ringing atlanta.com proxy -> Alice 408 SIP/2.0 180 Ringing 409 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 410 ;received=192.0.2.1 411 To: Bob ;tag=a6c85cf 412 From: Alice ;tag=1928301774 413 Call-ID: a84b4c76e66710 414 Contact: 415 CSeq: 314159 INVITE 416 Content-Length: 0 417 F9 200 OK Bob -> biloxi.com proxy 419 SIP/2.0 200 OK 420 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 421 ;received=192.0.2.3 422 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 423 ;branch=z9hG4bK77ef4c2312983.1 424 ;received=192.0.2.2 425 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 426 ;received=192.0.2.1 427 To: Bob ;tag=a6c85cf 428 From: Alice ;tag=1928301774 429 Call-ID: a84b4c76e66710 430 CSeq: 314159 INVITE 431 Contact: 432 Content-Type: application/sdp 433 Content-Length: ... 435 v=0 436 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 437 s=Session SDP 438 c=IN IP4 192.0.2.4 439 t=3034423619 0 440 m=audio 3456 RTP/AVP 0 441 a=rtpmap:0 PCMU/8000 442 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 443 F10 200 OK biloxi.com proxy -> atlanta.com proxy 445 SIP/2.0 200 OK 446 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com 447 ;branch=z9hG4bK77ef4c2312983.1 448 ;received=192.0.2.2 449 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 450 ;received=192.0.2.1 451 To: Bob ;tag=a6c85cf 452 From: Alice ;tag=1928301774 453 Call-ID: a84b4c76e66710 454 CSeq: 314159 INVITE 455 Contact: 456 Content-Type: application/sdp 457 Content-Length: ... 459 v=0 460 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 461 s=Session SDP 462 c=IN IP4 192.0.2.4 463 t=3034423619 0 464 m=audio 3456 RTP/AVP 0 465 a=rtpmap:0 PCMU/8000 466 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 468 F11 200 OK atlanta.com proxy -> Alice 470 SIP/2.0 200 OK 471 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 472 ;received=192.0.2.1 473 To: Bob ;tag=a6c85cf 474 From: Alice ;tag=1928301774 475 Call-ID: a84b4c76e66710 476 CSeq: 314159 INVITE 477 Contact: 478 Content-Type: application/sdp 479 Content-Length: ... 481 v=0 482 o=bob 2890844527 2890844527 IN IP4 192.0.2.4 483 s=Session SDP 484 c=IN IP4 192.0.2.4 485 t=3034423619 0 486 m=audio 3456 RTP/AVP 0 487 a=rtpmap:0 PCMU/8000 488 k=host-identity-tag:44A5C522D7EDEDF962E55A0677DB1346 489 F12 ACK Alice -> Bob 491 ACK sip:bob@192.0.2.4 SIP/2.0 492 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 493 Max-Forwards: 70 494 To: Bob ;tag=a6c85cf 495 From: Alice ;tag=1928301774 496 Call-ID: a84b4c76e66710 497 CSeq: 314159 ACK 498 Content-Length: 0 500 The media session between Alice and Bob is now established. 502 The exchanged HITs are now placed in the pool of known HITs at both 503 end hosts. As such there is also a binding established between URI 504 and HIT at this point. 506 Next a regular HIP base exchange between Alice and Bob is started. 507 As part of the exchange the two end hosts inspect their known-HITs 508 pool and find the previously exchanged parameters. 510 Alice -> Bob: I1: Trigger exchange 512 Alice <- Bob: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 513 HIP Transform }SIG 515 Alice -> Bob: I2: {Solution, LSI(I), SPI(I), D-H(I), 516 ESP Transform, HIP Transform, {H(I)}SK }SIG 518 Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG 520 As a result of this exchange, two IPsec SAs (one for each direction) 521 is established. RTP media traffic can be exchanged between the two 522 end hosts, Alice and Bob, protected by IPsec. If end host mobility 523 takes place then a HIP readdressing exchange takes place which is not 524 detected at the upper layer by UDP/RTP or SIP. 526 4. Security Considerations 528 This proposal is closely aligned towards the usage of the 'k' 529 parameter in SDP [5]. As a difference, an asymmetric key is 530 exchanged unlike the proposals illustrated in Section 6 of [5]. 531 Section 5.12 of [8] is relevant for this discussion. 533 If an adversary aims to impersonate one of the SIP UAs in the 534 subsequent HIP exchange then it is necessary to replace the Host 535 Identity/Host Identity Tag exchanged in the SIP/SDP messages. 537 Please note that this approach is in a certain sense a re- 538 instantiation of the Purpose-Built-Key (PBK) idea (see [9]). With 539 PBK a hash of a public key is sent from node A to node B. If there 540 was no adversary between A and B at that time to modify the 541 transmitted hash value then subsequent communication interactions 542 which use the public key are secure. This proposal reuses the same 543 idea but focuses on the interworking between different protocols. In 544 fact it would be possible to use the same approach to exchange the 545 hash of an S/MIME certificate which can later be used in subsequent 546 SIP signaling message exchanges. 548 If Host Identities for HIP can be retrieved using a different, more 549 secure method then the Host Identities exchanged with SIP/SDP MUST 550 NOT be used. 552 5. Open Issues 554 The authors came accross a number of open issues while thinking about 555 this topic: 557 o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute 558 Host Identities. This approach is particularly interesting, if 559 Host Identities are subject to frequent change. As such, it would 560 resemble the proposal provided with SIPPING-CERT [10]. Thereby 561 the user agent would be allowed to upload its own Host Identity to 562 the Credential Server. Other user agents would use the SUBSCRIBE 563 method to retrieve Host Identities of a particular user. With the 564 help of the NOTIFY message it is possible to learn about a changed 565 Host Identity (e.g., a revoked HI). It is for further study 566 whether this is more useful than the already described proposal. 568 o Is an IANA registration for the method field required? 570 o Is it possible to carry more than one Host Identity/Host Identity 571 Tag in the SDP payload by listing more than one 'k' parameter? 573 o Further investigations are required with regard to the mobility 574 functionality provided by HIP and the potential benefits for end- 575 to-end signaling using SIP, RTP etc. between the SIP UAs. 577 o Middlebox traversal functionality discussed in the context of HIP 578 (such as STUN, TURN, ICE) could potentially be replaced by the HIP 579 middlebox traversal functionality. 581 6. Contributors 583 We would like to thank Vesa Torvinen for his contributions to the 584 initial version of this document. 586 7. Acknowledgments 588 The authors would like to thank Steffen Fries, Aarthi Nagarajan, 589 Murugaraj Shanmugam, Franz Muenz, Jochen Grimminger and Joachim Kross 590 for their feedback. 592 8. References 594 8.1 Normative References 596 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 597 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 598 Session Initiation Protocol", RFC 3261, June 2002. 600 [2] Moskowitz, R., "Host Identity Protocol Architecture", 601 draft-moskowitz-hip-arch-06 (work in progress), June 2004. 603 [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 604 (work in progress), June 2004. 606 [4] Andreasen, F., Baugher, M., and D. Wing, "Session Description 607 Protocol Security Descriptions for Media Streams", 608 draft-ietf-mmusic-sdescriptions-07 (work in progress), 609 July 2004. 611 [5] Handley, M. and V. Jacobson, "SDP: Session Description 612 Protocol", RFC 2327, April 1998. 614 [6] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 615 Norrman, "Key Management Extensions for Session Description 616 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 617 draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. 619 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 620 Levels", March 1997. 622 8.2 Informative References 624 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 625 Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in 626 progress), September 2004. 628 [9] Bradner, S., Mankin, A., and J. Schiller, "A Framework for 629 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in 630 progress), June 2003. 632 [10] Jennings, C., "Certificate Management Service for SIP", 633 draft-jennings-sipping-certs-04 (work in progress), July 2004. 635 Authors' Addresses 637 Hannes Tschofenig 638 Siemens 639 Otto-Hahn-Ring 6 640 Munich, Bavaria 81739 641 Germany 643 Email: Hannes.Tschofenig@siemens.com 645 Joerg Ott 646 Universitaet Bremen 647 Bibliothekstr. 1 648 Bremen 28359 649 Germany 651 Email: jo@tzi.org 653 Henning Schulzrinne 654 Columbia University 655 Department of Computer Science 656 450 Computer Science Building 657 New York, NY 10027 658 USA 660 Phone: +1 212 939 7042 661 Email: schulzrinne@cs.columbia.edu 662 URI: http://www.cs.columbia.edu/~hgs 664 Thomas R. Henderson 665 The Boeing Company 666 P.O. Box 3707 667 Seattle, WA 668 USA 670 Email: thomas.r.henderson@boeing.com 671 Gonzalo Camarillo 672 Ericsson 673 Hirsalantie 11 674 Jorvas 02420 675 Finland 677 Email: Gonzalo.Camarillo@ericsson.com 679 Intellectual Property Statement 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Disclaimer of Validity 705 This document and the information contained herein are provided on an 706 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 707 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 708 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 709 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 710 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 711 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 713 Copyright Statement 715 Copyright (C) The Internet Society (2004). This document is subject 716 to the rights, licenses and restrictions contained in BCP 78, and 717 except as set forth therein, the authors retain all their rights. 719 Acknowledgment 721 Funding for the RFC Editor function is currently provided by the 722 Internet Society.