idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-07.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 draft header indicates that this document updates RFC4975, but the abstract doesn't seem to directly say this. It does mention RFC4975 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- 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 (September 22, 2010) is 4965 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) -- Looks like a reference, but probably isn't: '10' on line 238 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: 4975 (if approved) S. Blau 5 Intended status: Standards Track Ericsson AB 6 Expires: March 26, 2011 September 22, 2010 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-07.txt 11 Abstract 13 This document updates the Message Session Relay Protocol (MSRP) 14 session matching procedure of MSRP endpoints. The update extends the 15 applicability of MSRP peer-to-peer communication to network scenarios 16 where Application Layer Gateway (ALG) functions modify the Session 17 Description Protcoll (SDP) MSRP address information. 19 The update is backwards compatible. In the absence of ALGs RFC 4975 20 compliant MSRP User Agents (UAs) can interwork with MSRP UAs 21 compliant with this specification. In the presence of ALGs RFC 4975 22 compliant MSRP UAs can normally not establish MSRP sessions. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 26, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4 61 4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4 62 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4 64 4.2.1. 5th paragraph . . . . . . . . . . . . . . . . . . . . . 4 65 4.2.2. 10th paragraph . . . . . . . . . . . . . . . . . . . . 5 66 4.3. RFC4975: 6. MSRP URIs . . . . . . . . . . . . . . . . . . . 5 67 4.3.1. 6th paragraph . . . . . . . . . . . . . . . . . . . . . 5 68 4.4. RFC4975: 6.1 MSRP URI Comparison . . . . . . . . . . . . . 5 69 4.4.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 5 70 4.5. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 6 71 4.5.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 6 74 5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 7 75 5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 7 76 5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 87 use MSRP relays [RFC4976] as a means for Network Address Translation 88 (NAT) traversal and policy enforcement. 90 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 91 in which MSRP usage is emerging, also contain generic Application 92 Layer Gateways (ALGs), which might control media relays and perform 93 tasks such as NAT traversal, performance monitoring, lawful 94 intercept, address domain bridging, interconnect Service Layer 95 Agreement (SLA) policy enforcement, etc. An example is the 96 Interconnect Border Control Function (IBCF) [3GPP.23.228] defined by 97 the 3rd Generation Partnership Project (3GPP), which controls a media 98 relay that handles all types of SIP session media (voice, video, 99 MSRP, etc). 101 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does 102 not work when such ALGs are present between the SIP/MSRP endpoints, 103 unless the ALGs act as MSRP Back-To-Back User Agents (B2BUAs). The 104 reason is that MSRP UAs, when they receive an MSRP message, use MSRP 105 URI comparision [RFC4975] in order to match the MSRP message to an 106 MSRP session. That requires consistency between the address 107 information the the MSRP messages and the MSRP URI carried in the SDP 108 a=path attribute. The matching will fail if an ALG modifies the 109 address information of the SDP a=path attribute, but does not perform 110 the corresponding modification in the MSRP message (which requires 111 MSRP B2BUA functionaltiy). However, few ALGs implement MSRP B2BUA 112 functionality, due to complexity and poor scalability. 114 In order to allow usage of MSRP use in SIP networks where ALGs are 115 present, this document updates the session matching procedures 116 defined in RFC 4975. Instead of using the MSRP URI comparision 117 procedure for matching an incoming MSRP message to an MSRP session, 118 only the MSRP URI session-id part is used. 120 The updated procedures defined in this specification allow the usage 121 of non-MSRP B2BUA ALGs in MSRP peer-to-peer connections, with the 122 restriction that TLS with name based authentication can not be used 123 with such ALGs. TLS with fingerprint based authentication can be 124 used with such ALGs, however. In case TLS name based authentication 125 is used for peer-to-peer MSRP, or MSRP relays with or without TLS are 126 used, ALGs still need to implement MSRP B2BUA functionality in order 127 to prevent MSRP communication from failing. 129 NOTE: Peer-to-peer MSRP, unprotected or TLS protected with 130 fingerprint based TLS authentication, are considered to be the most 131 common choises for MSRP communication in network environments where 132 ALGs are deployed. 134 2. Conventions 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in BCP 14, RFC 2119 139 [RFC2119]. 141 In this specification the terminology "fingerprint based TLS 142 authentication" and "name based TLS authentication" are used to refer 143 to the two cases where: 145 1 An endpoint use a self-signed TLS certificate and sends a 146 certificate fingerprint in SDP (fingerprint based TLS 147 authentication). 149 2. An endpoint use a certificate from a well known certificate 150 authority and the other endpoint matches the hostname in the received 151 TLS communication SubjectAltName parameter towards the hostname 152 received in the MSRP URI in SDP (name based TLS authentication). 154 3. Applicability statement 156 This document updates sections 5.4 (MSRP Connection Model) and 7.3 157 (Receiving Requests) of [RFC4975]. An MSRP UA MUST implement the 158 procedures defined in this document in order to interoperate with 159 remote MSRP UAs in a network where intermediaries might modify the 160 address information in the MSRP URI of the SDP a=path attribute. 162 4. Normative update of RFC 4975 164 4.1. General 166 This section replaces the text for the 5th and 10th paragraph of 167 section 5.4 (MSRP Connection Model), the 6th paragraph of section 6 168 (MSRP URIs), the 1st section of section 6.1 (MSRP URI Comparison) and 169 the first paragraph of section 7.3 (Receiving Requests), of RFC 4975. 171 4.2. RFC4975: 5.4 MSRP Connection Model 173 4.2.1. 5th paragraph 175 The rules on certificate name matching and CA signing MAY be relaxed 176 when using TLS peer-to-peer. In this case, a mechanism to ensure 177 that the peer used a correct certificate MUST be used. See Section 178 14.4 for details. It is strongly RECOMMENDED that MSRP endpoints, 179 when using peer-to-peer MSRP with TLS, use the mechanism described in 180 section 14.4, in order to be able to establish MSRP sessions in 181 networks where Application Layer Gateways (ALGs) are deployed. 183 4.2.2. 10th paragraph 185 When the first request arrives, its To-Path header field should 186 contain a URI with a session-id part that the listening element 187 provided in the SDP for a session. The element that accepted the 188 connection looks up the session-id part of the URI in the received 189 request, and determines which session it matches. If a match exists, 190 the node MUST assume that the host that formed the connection is the 191 host to which this URI was given. If no match exists, the node MUST 192 reject the request with a 481 response. The node MUST also check to 193 make sure the session is not already in use on another connection. 194 If the session is already in use, it MUST reject the request with a 195 506 response. 197 4.3. RFC4975: 6. MSRP URIs 199 4.3.1. 6th paragraph 201 The MSRP URI authority field identifies a particular MSRP host 202 device. If the authority field contains a numeric IP address, it 203 MUST also contain a port. The MSRP URI session-id field identifies a 204 particular session at the host device, and a particular value of 205 session-id is only meaningful in the context of the particular MSRP 206 host device that created it. An MSRP URI that does not include a 207 session-id is a reference to an MSRP host device, not to any 208 particular session at that device. 210 4.4. RFC4975: 6.1 MSRP URI Comparison 212 4.4.1. 1st paragraph 214 In the context of the MSRP protocol, MSRP URI comparisons MUST be 215 performed according to the following rules: 217 1. The scheme MUST match. Scheme comparison is case insensitive. 219 2. If the authority component contains an explicit IP address and/or 220 port, these are compared for address and port equivalence. Percent- 221 encoding normalization [10] applies; that is, if any percent-encoded 222 non-reserved characters exist in the authority component, they must 223 be decoded prior to comparison. Userinfo parts are not considered 224 for URI comparison. Otherwise, the authority component is compared 225 as a case-insensitive character string. 227 3. If the port exists explicitly in either URI, then it MUST match 228 exactly. A URI with an explicit port is never equivalent to another 229 with no port specified. 231 4. The session-id part is compared as case sensitive. A URI without 232 a session-id part is never equivalent to one that includes one. 234 5. URIs with different "transport" parameters never match. Two URIs 235 that are identical except for transport are not equivalent. The 236 transport parameter is case insensitive. 238 Path normalization [10] is not relevant for MSRP URIs. 240 This specification does not define any usage for the MSRP URI 241 comparison rules. However, if an extension mechanism requires MSRP 242 URI comparison, it MUST use the rules defined in this section. 244 NOTE: The MSRP URI comparison rules are not used to match MSRP 245 messages with MSRP sessions. As defined in Section 4.5, only the 246 MSRP URI session-id part is used for the session matching. 248 4.5. RFC4975: 7.3 Receiving Requests 250 4.5.1. 1st paragraph 252 The receiving endpoint MUST first check the URI in the To-Path to 253 make sure the request belongs to an existing session. When the 254 request is received, the To-Path will have exactly one URI, of which 255 the session-id part MUST map to an existing session that is 256 associated with the connection on which the request arrived. The 257 session-id part is compared as case sensitive. If this is not true, 258 then the receiver MUST generate a 481 error and ignore the request. 259 Note that if the Failure-Report header field had a value of "no", 260 then no error report would be sent. 262 5. Security Considerations 264 5.1. MSRP URI as shared secret 266 An MSRP UA compliant to RFC 4975 uses the complete MSRP URI (scheme, 267 authority, transport, session-id) as a shared secret in order to 268 determine that an incoming transport connection originates from the 269 intended peer device. The shared secret needs to be hard to guess, 270 but in reality only the session-id part with it's minimum 80 bit of 271 randomness that is hard to guess. Using only the MSRP URI session-id 272 part as shared secret is therfore roughly as good as using the 273 complete URI. 275 5.2. Uniqueness of the session-id 277 An MSRP URI session-id value only needs to be unique within the scope 278 of the MSRP device that created it, so in order to make the 279 session-id unique there is no need to scope its namespace by the MSRP 280 URI authority part. 282 5.3. Man in the middle 284 In order for a device to insert itself as a man in the middle in the 285 MSRP communication path, it needs to be in the SIP/SDP signalling 286 path and modify the SDP MSRP URI information associated with the MSRP 287 session. When communicating with RFC 4975 compliant MSRP UAs, such 288 device also needs to implement MSRP B2BUA functionality, since it 289 needs to modify the MSRP To-Path and From-Path header fields, in 290 order to match the SDP modification. This insertion of a man in the 291 middle might not be detected by MSRP end devices. 293 Due to the update in this specification a man in the middle no longer 294 need to implement an MSRP B2BUA in order to be transparently in the 295 MSRP communication path. However, a man in the middle that does not 296 implement MSRP B2BUA functionality, and does not locally terminate 297 the TCP/MSRP connection, has very limited impact on the MSRP 298 connection. It could potentially monitor unprotected MSRP 299 communication, but any kind of flexible fraudulent endpoint 300 transparent modification of the MSRP communication is likely much 301 easier done by using MSRP B2BUA functionality. 303 5.4. TLS 305 This specification does not in any way modify the TLS security 306 procedures for MSRP. 308 TLS with fingerprint based authentication is not affected by the 309 presence of intermediaries that modify the SDP MSRP URI information. 310 TLS with name based authentication can only be used in presence of 311 ALGs if these implement MSRP B2BUA functionality. Otherwise TLS 312 authentication will fail. That applies to MSRP in general, and is 313 not specific to the updates defined in this specification. 315 6. IANA Considerations 317 This document updates 5.4, 6, 6.1 and 7.3 of [RFC4975] 319 7. Acknowledgements 321 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 322 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 323 Ted Hardie and Richard L Barnes for their guidance and input in order 324 to produce this document. 326 8. References 328 8.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 334 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 336 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 337 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 338 September 2007. 340 8.2. Informative References 342 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 343 A., Peterson, J., Sparks, R., Handley, M., and E. 344 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 345 June 2002. 347 [3GPP.23.228] 348 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 349 TS 23.228 10.1.0, June 2010. 351 Authors' Addresses 353 Christer Holmberg 354 Ericsson 355 Hirsalantie 11 356 Jorvas 02420 357 Finland 359 Email: christer.holmberg@ericsson.com 360 Staffan Blau 361 Ericsson AB 362 P.O Box 407 363 Sweden 365 Email: staffan.blau@ericsson.com