idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4566]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2011) is 4697 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: 'RFC6135' is defined on line 510, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft S. Blau 4 Intended status: Standards Track Ericsson 5 Expires: December 11, 2011 June 9, 2011 7 Alternative Connection Establishment (ACE) for the Message Session Relay 8 Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-12.txt 11 Abstract 13 This document defines an MSRP extension, Alternative Connection 14 Establishment (ACE). Support of the extension is optional. MSRP 15 endpoints can implement the extension in order to allow MSRP 16 communication in networks where SIP Application Layer Gateways (ALGs) 17 anchor the MSRP connection, without the need for the ALGs to enable 18 MSRP B2BUA functionality. The document also defines a Session 19 Description Protocol (SDP) [RFC4566] attribute, a=msrp-ace, that can 20 be used by MSRP endpoints to indicate support of the ACE extension. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 11, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability statement . . . . . . . . . . . . . . . . . . . 4 59 4. Alternative Connection Establishment Mechanism . . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. MSRP Offerer Procedures . . . . . . . . . . . . . . . . . 5 62 4.3. MSRP Answerer Procedures . . . . . . . . . . . . . . . . . 6 63 4.4. Usage With The Alternative Connection Model . . . . . . . 7 64 5. ALG assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2. MSRP awareness . . . . . . . . . . . . . . . . . . . . . . 7 67 5.3. TCP connection reuse . . . . . . . . . . . . . . . . . . . 8 68 5.4. SDP integrity . . . . . . . . . . . . . . . . . . . . . . 8 69 5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6.1. Man in the middle . . . . . . . . . . . . . . . . . . . . 9 72 6.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. IANA Registration of the SDP a=msrp-ace attribute . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 85 use MSRP relays [RFC4976] as a means for Network Address Translation 86 (NAT) traversal and policy enforcement. 88 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 89 in which MSRP usage is emerging, also contain SIP Application Layer 90 Gateways (ALGs), that anchor and controls media, perform tasks such 91 as NAT traversal, performance monitoring, lawful intercept, address 92 domain bridging, interconnect Service Layer Agreement (SLA) policy 93 enforcement, etc. An example is the Interconnection Border Control 94 Function (IBCF) [3GPP.23.228], defined by the 3rd Generation 95 Partnership Project (3GPP). The IBCF controls a media relay that 96 handles all types of SIP session media (voice, video, MSRP, etc). 98 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does 99 not work when an MSRP endpoints communicate with such ALGs, unless 100 the ALGs implement MSRP Back-To-Back User Agent (B2BUA) 101 functionality. The reason is that ALGs modify the address:port 102 information in SDP c/m-line in order to anchor media, and since the 103 active MSRP UA establishes the MSRP TCP connection based on the MSRP 104 URI of the SDP a=path attribute, this means that the MSRP connection 105 will not, unless the ALG also modifies the MSRP URI of the topmost 106 SDP a=path attribute be routed through the ALG, which in many 107 scenarios will prevent the MSRP connection from being established. 108 However, if the ALG modifies the MSRP URI of the SDP a=path 109 attribute, then the MSRP URI comparison procedure [RFC4975], which 110 requires consistency between the address information in the MSRP 111 messages and the address information carried in the MSRP URI of the 112 SDP a=path attribute, will fail. The matching will fail if ALGs 113 modify the address information in the MSRP URI of the SDP a=path 114 attribute, but do not enable MSRP B2BUA functionality and perform the 115 corresponding modification in the associated MSRP messages. However, 116 the enabling of MSRP B2BUA functionality requires substantially more 117 resource usage in the ALG, that normally result in negative 118 performance impact. 120 This specification defines an MSRP extension, Alternative Connection 121 Establishment (ACE), that in certain cases allows MSRP endpoints to 122 communicate with ALGs without a need for the ALGs to enable MSRP 123 B2BUA functionality. In such cases, ALGs that anchor the MSRP 124 connection simply modify the SDP c/m-line address information 125 (similar to what it does for non-MSRP media types), and MSRP 126 endpoints that support the ACE extension can use the SDP c/m-line 127 address information for establishing the TCP (or TLS) connection to 128 be used for sending and receiving of MSRP messages. 130 The ACE extension is fully backward compatible. In scenarios where 131 MSRP endpoints that do not support the ACE extension are able to 132 establish MSRP connectivity, an MSRP endpoint that supports the ACE 133 extension behaves in the same way as an MSRP endpoint that does not 134 support it. The ACE extension only provides an alternative mechanism 135 for negotiating and providing the address information for the MSRP 136 TCP connection. Once the MSRP TCP connection has been created, an 137 MSRP endpoint that supports the ACE extension MUST act according to 138 the procedures (e.g. for creating MSRP messages, performing checks 139 when receiving MSRP messages etc) defined in RFC 4975 (and RFC 4976, 140 when it is using a relay for MSRP communication). 142 2. Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in BCP 14, RFC 2119 147 [RFC2119]. 149 In this specification the terminology "fingerprint based TLS 150 authentication" and "name based TLS authentication" are used to refer 151 to the two cases where: 153 1. An MSRP endpoint uses a self-signed TLS certificate and sends a 154 certificate fingerprint in SDP (fingerprint based TLS 155 authentication). 157 2. An MSRP endpoint uses a certificate from a well known certificate 158 authority and the other endpoint matches the hostname in the received 159 TLS communication SubjectAltName parameter towards the hostname 160 received in the MSRP URI in SDP (name based TLS authentication). 162 3. Applicability statement 164 This document defines an MSRP extension, Alternative Connection 165 Establishment (ACE). Support of the extension is optional. MSRP 166 endpoints can implement the extension in order to allow MSRP 167 communication in networks where SIP Application Layer Gateways (ALGs) 168 anchor the MSRP connection, without the need for the ALGs to enable 169 MSRP B2BUA functionality. 171 4. Alternative Connection Establishment Mechanism 172 4.1. General 174 This section defines how an MSRP endpoint that supports the ACE 175 extension generates SDP offers and answers for MSRP, and what SDP 176 information elements the MSRP endpoint uses when creating the TCP 177 connection for the MSRP messages. 179 4.2. MSRP Offerer Procedures 181 When an MSRP endpoint sends an SDP offer for MSRP, it generates the 182 SDP offer according to the procedures in RFC 4975 (and RFC 4976, if 183 it is using a relay for MSRP communication), with the following 184 additions and modifications: 186 1) The MSRP endpoint MUST include an SDP a=msrp-ace attribute in the 187 MSRP media description of the SDP offer. 189 2) If the MSRP endpoint is not using a relay for MSRP communication, 190 it MUST include an SDP a=setup attribute in the MSRP media 191 description of the SDP offer, according to the procedures in RFC 192 6135. 194 3) If the MSRP endpoint is using a relay for MSRP communication, it 195 MUST include the address information on the relay (the MSRP URI of 196 the topmost SDP a=path attribute), rather than the address 197 information of itself, in the SDP c/m-line associated with the MSRP 198 media description. In addition, it MUST include an SDP a=setup: 199 passive attribute in the MSRP media description of the SDP offer. 201 When the MSRP endpoint receives the first SDP answer to the SDP offer 202 above, and the SDP answer indicates that the offered MSRP media has 203 been accepted by the remote MSRP endpoint (i.e. the port number of 204 the MSRP media description is not set to zero), if the MSRP media 205 description of the SDP answer does not contain an SDP a=msrp-ace 206 attribute, the MSRP endpoint MUST check whether any of the following 207 criteria is fulfilled: 209 1) The SDP c/m-line address information associated with the MSRP 210 media description does not match the information in the MSRP URI of 211 the topmost SDP a=path attribute, and the MSRP media description 212 contains an SDP a=setup:active attribute (indicating that the remote 213 MSRP endpoint is "active"). 215 2) The MSRP media description contains multiple SDP a=path attributes 216 (indicating that MSRP relays are used). 218 If any, or both, of the criteria above is fulfilled, the MSRP 219 endpoint MUST fallback to RFC 4975 behavior, by sending a new SDP 220 offer according to the procedures in RFC 4975 and RFC 4976. The new 221 offer MUST NOT contain an SDP a=msrp-ace attribute. 223 NOTE: In the absence of the SDP a=msrp-ace attribute in the new 224 offer, the ALG will in all cases have to, in order to be able to 225 anchor MSRP media, enable MSRP B2BUA functionality. 227 NOTE: The MSRP endpoint can send the new offer within the existing 228 early dialog [RFC3261], or it can terminate the early dialog and 229 establish a new dialog by sending the new offer in a new initial 230 INVITE request. 232 In all other cases, where the MSRP endpoint becomes "active", it MUST 233 use the SDP c/m-line for establishing the MSRP TCP connection. If 234 the MSRP endpoint becomes "passive", it will wait for the remote MSRP 235 endpoint to establish the TCP connection, according to the procedures 236 in RFC 4975. 238 4.3. MSRP Answerer Procedures 240 When an MSRP endpoint receives an SDP offer for MSRP, if the MSRP 241 media description does not contain an SDP a=msrp-ace attribute, the 242 MSRP endpoint MUST check whether any of the following criteria is 243 fulfilled: 245 1) The SDP c/m-line address information associated with the MSRP 246 media description does not match the information in the MSRP URI of 247 the topmost SDP a=path attribute, and the remote MSRP endpoint will 248 become "active" (either by default, or by negotiation using the 249 procedures in RFC 6135). 251 2) The MSRP media description contains multiple SDP a=path attributes 252 (indicating that MSRP relays are used). 254 3) The MSRP endpoint uses a relay for MSRP communication, and is not 255 able to become "passive" (the MSRP media description of the offer 256 contains an SDP a=setup:passive attribute). 258 If any, or all, of the criteria above is fulfilled, the MSRP endpoint 259 MUST fallback to RFC 4975 behavior, and generate the associated SDP 260 answer according to the procedures in RFC 4975 and RFC 4976. The 261 MSRP endpoint MUST NOT insert an SDP a=msrp-ace attribute in the MSRP 262 media description of the SDP answer. 264 In all other cases, the MSRP endpoint generates the associated SDP 265 answer according to the procedures in RFC 4975 and RFC 4976, with the 266 following additions and modifications: 268 1) The MSRP endpoint MUST include an SDP a=msrp-ace attribute in the 269 MSRP media description of the SDP answer. 271 2) If the MSRP endpoint is not using a relay for MSRP communication, 272 it MUST include an SDP a=setup attribute in the MSRP media 273 description of the answer, according to the procedures in RFC 6135. 275 3) If the MSRP endpoint is using a relay for MSRP communication, it 276 MUST include the address information on the relay (the MSRP URI of 277 the topmost SDP a=path attribute), rather than the address 278 information of itself, in the SDP c/m-line associated with the MSRP 279 media description. In addition, it MUST include an SDP a=setup: 280 passive attribute in the MSRP media description of the SDP offer. 282 If the MSRP endpoint included an SDP a=msrp-ace attribute in the MSRP 283 media description of the SDP answer, and if the MSRP endpoint becomes 284 "active", it MUST use the received SDP c/m-line for establishing the 285 MSRP TCP connection. If the MSRP endpoint becomes "passive", it will 286 wait for the remote MSRP endpoint to establish the TCP connection, 287 according to the procedures in RFC 4975. 289 4.4. Usage With The Alternative Connection Model 291 An MSRP endpoint that supports the ACE extension MUST in addition 292 also support the mechanism defined in RFC 6135, as it extends the 293 number of scenarios where the ACE extension can be used, and ALGs do 294 not need to enable MSRP B2BUA functionality. An example is where a 295 MSRP endpoint is using a relay for MSRP communication, and it needs 296 to be "passive" in order to use the ACE extension (instead of doing a 297 fallback to RFC 4975 behavior. 299 5. ALG assumptions 301 5.1. General 303 This document does not specify explicit ALG behavior, eventhough some 304 of the procedures will be enabled by ALGs. However, as the main 305 reason behind the ACE extension is to allow MSRP endpoints to 306 communicate in networks where ALGs are present, this document makes 307 certain assumptions regarding to how such ALGs behave. 309 5.2. MSRP awareness 311 This document assumes that an ALG, in order to support 312 interoperability between UAs that support the ACE extension and UAs 313 that do not support the extension, is MSRP aware, meaning that it 314 implements MSRP B2BUA functionality, and that it enables that 315 functionality in cases where support of the ACE extension is not 316 indicated. In cases where support of the ACE extension is indicated 317 by at least one MSRP endpoint, the ALG can simply modifies the SDP 318 c/m-line address information for the MSRP connection. However, MSRP 319 communication will work if the ALG enables MSRP B2BUA functionality 320 also in such cases. 322 5.3. TCP connection reuse 324 When the ACE extension is used, in cases where ALGs do not need to 325 enable MSRP B2BUA functionality, the ALGs are not required to parse 326 and modify the MSRP payload. An ALG that does not parse the MSRP 327 payload might not enable re-usage of TCP connections for multiple 328 MSRP sessions. Instead, in order to associate an MSRP message with a 329 specific session, the ALG often assigns a unique local address:port 330 combination for each MSRP session. 332 5.4. SDP integrity 334 This document assumes that ALGs are able to modify the SDP address 335 information associated with the MSRP media, and therefore can not be 336 deployed in environments that require SIP identity [RFC4916] based 337 peer-to-peer SDP protection. 339 5.5. TLS 341 This document considers two approaches how an ALG handles TLS 342 protected MSRP connections. 344 In the first approach, the ALG relays the MSRP media packets at the 345 transport layer. The TLS handshake and resulting security 346 association (SA) are established peer-to-peer between the MSRP 347 endpoints. The ALG will see encrypted MSRP media packets, but is 348 unable to inspect the cleartext content. 350 In the second approach, the ALG acts as a TLS B2BUA, meaning that 351 separate SAs are established between the ALG and each MSRP endpoint. 352 The ALG decrypts MSRP media packets received from one MSRP endpoint, 353 and then re-encrypts them before sending them toward the other MSRP 354 endpoint. With this approach, the ALG can inspect and modify the 355 MSRP message content. 357 6. Security Considerations 358 6.1. Man in the middle 360 In some cases, where MSRP B2BUA functionality does not need to be 361 enabled, the ACE extension makes it easier for a man in the middle 362 (MiTM) to transparently insert itself in the communication between 363 MSRP endpoints in order to monitor or record unprotected MSRP 364 communication. It does not however make it easier for a MiTM to 365 monitor TLS protected MSRP, or in any significant way modify TLS 366 protected MSRP content or even find out that the packets contain MSRP 367 messages, since that would require the MiTM to implement MSRP B2BUA 368 functionality, no matter if UAs support the ACE extension or not. It 369 would thus require the MiTM to terminate the TCP/TLS/MSRP connection 370 in both directions. 372 6.2. TLS 374 The ACE extension supports the usage of name based authentication for 375 TLS, also in the presence of ALGs. 377 NOTE: If an ALG acts as a TLS B2BUA, MSRP endpoints will also be able 378 to use fingerprint based authentication for TLS, no matter if they 379 support the ACE extension or not. In such cases, as the ALG acts as 380 a TLS endpoints, MSRP endpoints might be given an incorrect 381 impression that there is an end-to-end SA between the MSRP endpoints. 383 If an ALG does not act as a TLS B2BUA, fingerprint based 384 authentication will not work, as the "SIP Identity" based integrity 385 protection of SDP will break. Therefore, in addition to the 386 authentication mechanisms defined in RFC 4975, an MSRP endpoint 387 supporting the ACE extension SHOULD also support an authentication 388 mechanism that does not rely on peer-to-peer SDP integrity. 390 It is RECOMMENDED that an MSRP endpoint supports one of the following 391 authentication mechanisms: 393 1) TLS certificates together with support of interacting with a 394 Certificate Management Service [ref to draft-ietf-sip-certs], to 395 which it publishes the public version of its own self-signed 396 certificate and from which it fetches on need the public certificates 397 of other endpoints. 399 2) TLS-PSK managed e.g by MIKEY-TICKET based Key Management and Key 400 Management Service [RFC6043]. 402 NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key 403 Management and Key Management Service authentication mechanism for 404 the IP Multimedia Subsystem (IMS). 406 When an MSRP endpoint generates an SDP offer for MSRPS it MUST, in 407 addition to the SDP attributes associated with the TLS authentication 408 mechanisms described in RFC 4975, it MUST include any information 409 elements associated with the other authentication mechanisms that it 410 supports. 412 Unless the MSRP endpoints are able to use name based authentication, 413 and they support a common authentication mechanism, they MUST use 414 that mechanism. If the MSRP endpoints do not support such common 415 authentication mechanism, they MUST try fingerprint based 416 authentication, which will succeed if there are no ALGs present. If 417 that also fails, the MSRP endpoints MUST either: 419 1) Consider the TLS authentication as failed, in accordance with RFC 420 4975; or 422 2) If the SIP signalling between the MSRP endpoints is protected 423 through e.g. SIPS, use fingerprint based authentication without 424 requiring peer-to-peer SDP integrity, and thus trust the network 425 endpoints in the signaling path for SDP integrity. 427 NOTE: As defined in RFC 4975, if TLS authentication fails, the user 428 need to be able to decide whether to try to anyway establish an MSRP 429 connection. 431 7. IANA Considerations 433 7.1. IANA Registration of the SDP a=msrp-ace attribute 435 This section registers a new SDP attribute, a=msrp-ace. The required 436 information for this registration, as specified in RFC 4566, is: 438 Contact name: Christer Holmberg 440 Contact e-mail: christer.holmberg@ericsson.com 442 Attribute name: a=msrp-ace 444 Type of attribute: media level 446 Purpose: This attribute is used to indicate support of the MSRP 447 Alternative Connection Establishment (ACE) extension 448 defined in RFC XXXX. When present in an MSRP media 449 description of an SDP body, it indicates that 450 the sending UA supports the ACE the mechanism. 452 Values: The attribute does not carry a value 454 Charset dependency: no 456 8. Acknowledgements 458 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 459 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 460 Ted Hardie, Richard L Barnes, Inaki Baz Castillo and Saul Ibarra 461 Corretge for their guidance and input in order to produce this 462 document. 464 9. Change Log 466 [RFC EDITOR NOTE: Please remove this section when publishing] 468 Changes from draft-ietf-simple-msrp-sessmatch-11 469 o Modification of the sessmatch mechanism. 470 o - Extension name changed to Alternative Connection Establishment 471 (ACE) 472 o - Session matching procedure no longer updated. 473 o - SDP c/m-line used for MSRP TCP connection. 474 o - sessmatch option-tag removed. 475 o - a=msrp-ace attribute defined. 476 o - Support of RFC 6135 mandatory. 478 Changes from draft-ietf-simple-msrp-sessmatch-10 479 o Sessmatch option-tag added, based on WG discussions and concensus. 481 Changes from draft-ietf-simple-msrp-sessmatch-08 482 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 484 Changes from draft-ietf-simple-msrp-sessmatch-07 485 o Sessmatch defined as an MSRP extension, rather than MSRP update 486 o Additional security considerations text added 488 10. References 490 10.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 496 A., Peterson, J., Sparks, R., Handley, M., and E. 497 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 498 June 2002. 500 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 501 Description Protocol", RFC 4566, July 2006. 503 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 504 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 506 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 507 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 508 September 2007. 510 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 511 for the Message Session Relay Protocol (MSRP)", RFC 6135, 512 February 2011. 514 10.2. Informative References 516 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 517 Protocol (SIP)", RFC 4916, June 2007. 519 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 520 Modes of Key Distribution in Multimedia Internet KEYing 521 (MIKEY)", RFC 6043, March 2011. 523 [3GPP.23.228] 524 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 525 TS 23.228 5.15.0, June 2006. 527 Authors' Addresses 529 Christer Holmberg 530 Ericsson 531 Hirsalantie 11 532 Jorvas 02420 533 Finland 535 Email: christer.holmberg@ericsson.com 537 Staffan Blau 538 Ericsson 539 Stockholm 12637 540 Sweden 542 Email: staffan.blau@ericsson.com