idnits 2.17.00 (12 Aug 2021) /tmp/idnits41407/draft-tschofenig-hiprg-host-identities-00.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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 693. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 709), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 45. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 543: '...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 18, 2004) is 6424 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 603, 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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HIPRG H. Tschofenig 2 Internet-Draft Siemens 3 Expires: April 18, 2005 V. Torvinen 4 Ericsson 5 J. Ott 6 Universitaet Bremen 7 H. Schulzrinne 8 Columbia U. 9 T. Henderson 10 The Boeing Company 11 G. Camarillo 12 Ericsson 13 October 18, 2004 15 Exchanging Host Identities in SIP 16 draft-tschofenig-hiprg-host-identities-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 18, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). All Rights Reserved. 47 Abstract 48 This document proposes to exchange Host Identities (or Host Identity 49 Tags) in SIP/SDP for later usage in the Host Identity Protocol 50 Protocol (HIP) between the SIP user agents. As such, it is a first 51 step in investigating the interaction between SIP and HIP and mainly 52 a discussion document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 60 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 64 7.2 Informative References . . . . . . . . . . . . . . . . . . . 19 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 66 Intellectual Property and Copyright Statements . . . . . . . . 22 68 1. Introduction 70 SIP [1] allows to establish and maintain sessions between two user 71 agents. The communication typically involves SIP proxies before 72 direct communication between the end points takes place. As part of 73 the initial communication exchange a number of parameters are 74 exchanged including security relevant parameters, such as keying 75 material and cryptographic information to establish a security 76 association for subsequent data traffic protection. 78 HIP (see [2] and [3]) creates an architecture with a new, 79 cryptographic namespace and a new layer between the network and the 80 transport layer to shield applications from the impact of 81 multi-homing, readdressing and mobility. A protocol, the Host 82 Identity Protocol, is used to establish state at the two end hosts. 83 This state includes the establishment of IPsec SAs. 85 In order to provide security between two HIP end hosts beyond 86 opportunistic encryption it is necessary to securely retrieve the 87 Host Identities. A number of mechanisms can be used including 88 directories (such as DNS) or more advanced concepts for example based 89 on Distributed Hash Tables typically used in peer-to-peer networks. 91 This document suggests to exchange the Host Identities (or Host 92 Identity Tags) as part of the initial SIP exchange inside the SDP 93 payload. As such, the Host Identities can also be bound to the user 94 identities - a concept not used in HIP. 96 The figure below illustrates the main idea: 98 +-----------+ +-----------+ 99 HI/HIT |SIP | HI/HIT |SIP | HI/HIT 100 +------>|Proxy |<---------->|Proxy |<------+ 101 | |Server X | TLS |Server Y | | 102 | +-----------+ +-----------+ | 103 | | 104 | TLS or TLS or | 105 | SIP Digest SIP Digest | 106 | | 107 | | 108 v v 109 +-----------+ SIP and HIP +-----------+ 110 |SIP | <---------------------------------> |SIP | 111 |User Agent | RTP |User Agent | 112 |Alice | <=================================> |Bob | 113 +-----------+ +-----------+ 115 Legend: 116 <--->: Signaling Traffic 117 <===>: Data Traffic 119 Figure 1: SIP Trapezoid 121 The initial SIP signaling messages between Alice and Bob often take 122 place via the proxy servers. This exchange may be protected with TLS 123 (between SIP proxies but also between SIP UAs and SIP proxies) or 124 with SIP digest authentication between SIP UAs and the outbound 125 proxy. Furthermore, SIP end-to-end security mechanisms are also 126 available with S/MIME. 128 This allows two hosts to securely exchange keys even if there are 129 only domain-level public and private keys, as well as secure 130 associations within a domain, thus avoiding the need for a global 131 user-level PKI. 133 This initial message exchange is used to exchange Host Identities 134 between the end points within the SDP payload. 136 Subsequently, when both user agents Alice and Bob communicate 137 directly with each other they are able to reuse the Host Identity for 138 the HIP message exchange. 140 If the SIP communication does not involve third parties (i.e., SIP 141 proxies) and is therefore executed directly between the two SIP UAs 142 then it is not useful to exchange Host Identities in the SDP payloads 143 since the HIP exchange already took place before the first SIP 144 message can be exchanged between the two peers. Still HIP might 145 provide some advantages for the end-to-end communication, such as 146 providing security at the lower layer and mobility and multi-homing 147 support. 149 The security of this approach relies on two properties: 150 The signaling messages and the data traffic traverse a different 151 path. Hence, an adversary needs to be located where it is able to 152 see both, the signaling and the the data traffic. 153 The signaling traffic is often protected. 155 2. SDP Extension 157 This document proposes to enhance the SDP [4] 'k' parameter. 159 This parameter has the following structure: k=. This document defines two new method fields: 161 k=host-identity: 162 k=host-identity-tag: 164 Both, the Host Identity and the Host Identity Tag are defined in [3]. 165 The Host Identity contains the public key and a number of 166 cryptographic parameters (such as used algorithms and Diffie-Hellmann 167 public parameters). The Host Identity is base64 encoded. 169 FOR DISCUSSION: 171 The usage of the k parameter as defined in [5] is deprecated. [4] 172 is more appropriate but like 'k=', they come with the caveat that 173 they require a secured e2e signaling path (or SDP is S/MIME 174 protected). One alternative is the usage of MIKEY for the 175 exchange as defined in [6]. 177 Furthermore, and probably more important, it is important to said 178 what the Host Identity is supposed to be used with. They may help 179 avoiding re-INVITEs when underlying IP addresses change to update 180 the 'Contact:' address as well as the addresses in the 'c=' lines 181 for the various media. 183 However, multiple devices may take part in the different media 184 sessions (your laptop doing video in parallel to your hardware IP 185 phone). To support these cases, it may be necessary to exchange 186 _several_ HI(T)s within SDP and denote what they shall be used 187 for. Such a mapping could naturally be achieved for each media 188 stream (even using 'k=' attributes); at simple 'a=' attributes (or 189 the mechanisms from [4]/ [6] would be preferred. 191 SDP only deals with media streams and does not have a notion of 192 user or main device in the background. Hence, the SIP HI(T) may 193 need to go into SIP signaling (rather than be carried in SDP). 195 Logically, this appears to belong to the 'Contact:' header which 196 may be conveyed protected in an S/MIME body (signed and 197 encrypted). 199 3. Example 201 This example contains the full details of the example session setup 202 taken from Section 4 of [1]. The message flow is shown in Figure 1 203 of [1] and resembles the architecture shown in Figure 1. Note that 204 these flows show the minimum required set of header fields; some 205 other header fields such as Allow and Supported would normally be 206 present. 208 In our example Alice uses the following Host Identity Tag 209 (7214148E0433AFE2FA2D48003D31172E) and Bob uses 210 (44A5C522D7EDEDF962E55A0677DB1346) as the HIT. These HITs correspond 211 to the following Host Identities (for convenience we reuse the XML 212 representation format used by the Boeing implementation). 214 ------ 215 Alice: 216 ------ 218 221 sip:alice@atlanta.com 223

D757262C4584C44C211F18BD96E5F061C4F0A423F7FE6B6B85B34CEF72CE14 224 A0D3A222FE08CECE65BE6C265854889DC1EDBD13EC8B274DA9F75BA26CCB98772 225 3602787E92BA84421F22C3C89CB9B06FD60FE01941DDD77FE6B12893DA76EEBC1 226 D128D97F0678D772B5341C8506F358214B16A2FAC4B368950387811C7DA33

228 C773218C737EC8EE993B4F2DED30F48EDACE915F 230 82269009E14EC474BAF2932E69D3B1F18517AD9594184CCDFCEAE96EC4D5EF 231 9313384B47093C52B20CD35D02492B3959EC6499625BC4FA5082E22C5B374E16D 232 D00132CE71020217091AC717B612391C76C1FB2E88317C1BD8171D41ECB83E210 233 C03CC9B32E81056C21621C73D6DAAC028F4B1585DA7F42519718CC9B09EEF 235 A4666AED5F5E753773DC961EDD0412A03F1F8D7CEC70A057076062804B86 236 619D3DA4E7610EBBDB05F44C5784622D1B86600DFCC1431BC4451D4FD31329354 237 07A9B24718CB82BAE93A4CDD9CC4C8B9A41C000AB53D52A65E8383F54F5BF92A8 238 21EA776A207C6991EF23808C00DB820977D97CAC01CB96307274E2386001327 239 241 7214148E0433AFE2FA2D48003D31172E 242 243 ---- 244 Bob: 245 ---- 247 250 sip:bob@biloxi.com 252

F13ACC1693AFD04B9E1E8D2A9DEA6DE8DE4C276BE2BF15B6CFF6E269B0169 253 378CB0DDDE23D187827015DC67E6768193914B823BDF215D0DAD7A151E434F9E 254 128DAFB9DEFAE07874621E70D7ED2D34B80A95FA8312B9564E4D118FB525664C 255 77D

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