One document matched: draft-ietf-simple-msrp-sessmatch-11.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200811" category="std" docName="draft-ietf-simple-msrp-sessmatch-11.txt" obsoletes="" extends="4975" submissionType="IETF" xml:lang="en">
<front>
    <title abbrev="MRSP">
		Session Matching Update for the Message Session Relay Protocol (MSRP)
	</title>
    <author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
		<organization>Ericsson</organization>
		<address>
			<postal>
				<street>Hirsalantie 11</street>
				<code>02420</code>
				<city>Jorvas</city>
				<country>Finland</country>
			</postal>
        <email>christer.holmberg@ericsson.com</email>
		</address>
    </author>
    <author initials="S.B." surname="Blau" fullname="Staffan Blau">
		<organization>Ericsson AB</organization>
		<address>
			<postal>
				<code>12637</code> 
				<city>Stockholm</city>
				<country>Sweden</country>
			</postal>
        <email>staffan.blau@ericsson.com</email>
		</address>
    </author>
    <date year="2011" />
    <area>Transport</area>
    <workgroup>SIMPLE Working Group</workgroup>
    <keyword>MSRP</keyword>
    <keyword>ALG</keyword>
    <keyword>IBCF</keyword>
    <keyword>SBC</keyword>
    <keyword>relay</keyword>
    <abstract>
		<t>		  
			This document defines an extension, sessmatch, for the Message Session Relay Protocol (MSRP)
			session matching procedure of MSRP entities. The extension extends the applicability of MSRP 
			communication to network scenarios where Application Layer Gateway (ALG) functions modify the Session
			Description Protocol (SDP) MSRP address information. The document also defines a Session Initiation
			Protocol (SIP) option-tag, sessmatch, that is used by MSRP entities to indicate support of the
			sessmatch extension.
		</t>
    </abstract>
</front>
<middle>
    <section title="Introduction" toc="default">
		<t>
			The Message Session Relay Protocol (MSRP) <xref target="RFC4975" pageno="false" format="default" /> is designed 
			to use MSRP relays <xref target="RFC4976" pageno="false" format="default" /> as a means for Network Address 
			Translation (NAT) traversal and policy enforcement.
		</t>       
		<t>     
			However, many Session Initiation Protocol (SIP) <xref target="RFC3261" pageno="false" format="default" /> 
			networks, in which MSRP usage is emerging, also contain SIP Application Layer Gateways (ALGs), which 
			anchor and controls media, perform tasks such as NAT traversal, performance monitoring, lawful intercept, 
			address domain bridging, interconnect Service Layer Agreement (SLA) policy enforcement, etc. An example is the 
			Interconnect Border Control Function (IBCF) <xref target="3GPP.23.228" pageno="false" format="default" /> defined 
			by the 3rd Generation Partnership Project (3GPP), which controls a media relay that handles all types of SIP 
			session media (voice, video, MSRP, etc).
		</t>
		<t>
			MSRP, as defined in RFC 4975 <xref target="RFC4975" pageno="false" format="default" /> and RFC 4976 <xref 
			target="RFC4976" pageno="false" format="default" />, does not work when an MSRP entities communicate with 
			such ALGs, unless the ALGs implement MSRP Back-To-Back User Agent (B2BUA) functionality. The reason is that 
			entities use the MSRP URI comparison <xref target="RFC4975" pageno="false" format="default" /> procedure in 
			order to match an MSRP message to an MSRP session. That requires consistency between the address information 
			in the MSRP messages and the address information carried in the SDP a=path attribute. The matching will fail 
			if ALGs modify the address information of the SDP a=path attribute, but do not implement MSRP B2BUA functionality 
			and perform the corresponding modification in the associated MSRP messages. However, few ALGs implement MSRP B2BUA 
			functionality, due to complexity and poor scalability.
		</t>
		<t>
			This specification defines an MSRP extension, sessmatch, that allows MSRP entities to communicate
			with ALGs that do not implement MSRP B2BUA functionality. MSRP entities that support the sessmatch
			extension use a different mechanism for matching an MSRP message with an MSRP session, called session matching.
			Instead of using the MSRP URI comparison procedure defined in RFC 4975, only the MSRP session-id part 
			is used for the session matching. 
		</t>
		<t>
			The sessmatch extension is backward compatible. In the absence of ALGs, MSRP entities that do not implement
			the sessmatch extension can interoperate with entities that do implement it. The reason is that the
			matching of an MSRP message to an ongoing session will not fail. MSRP entities that do not implement 
			the sessmatch extension, and communicate with ALGs that do not implement MSRP B2BUA functionality, can 
			normally not establish MSRP sessions, since the session matching will fail in case the address 
			information of the SDP a=path attribute has been modified by the ALGs.
		</t>
    </section>
    <section title="Conventions" toc="default">
		<t>
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
			and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 <xref target="RFC2119" 
			pageno="false" format="default" />.
		</t>
		<t>
			In this specification the terminology "fingerprint based TLS authentication" and "name based TLS authentication" 
			are used to refer to the two cases where:
		</t>
		<t>
			1.	An endpoint use a self-signed TLS certificate and sends a certificate fingerprint in SDP (fingerprint 
			based TLS authentication).
		</t>
		<t>
			2.	An endpoint use a certificate from a well known certificate authority and the other endpoint matches 
			the hostname in the received TLS communication SubjectAltName parameter towards the hostname received in the 
			MSRP URI in SDP (name based TLS authentication).
		</t>
    </section>
    <section title="Applicability statement" toc="default">
		<t>
			This document defines an MSRP extension, sessmatch. Support of the extension is optional. MSRP entities
			can implement the extension in order to allow MSRP communication in networks where ALGs that
			might modify the address information of the SDP a=path attribute, but do not implement MSRP B2BUA functionality,
			are present.
		</t>
    </section>
    <section title="Sessmatch mechanism" toc="default">
		<section title="General" toc="default">
			<t>
				This section defines how an MSRP entity that supports the sessmatch extension performs session matching, 
				i.e. matches an incoming MSRP message to an MSRP session.
			</t>
		</section>
		<section title="Session matching" toc="default">
			<t>
				The difference between the session matching mechanism in RFC 4975, and the one defined in 
				this specification for the sessmatch extension, is that while the mechanism in RFC 4975 uses the 
				MSRP URI comparison rules for session matching, the sessmatch extension only uses the session-id 
				part of the MSRP URI.
			</t>
			<t>
				When an MSRP entity that receives the first MSRP request for an MSRP session, the To-Path header 
				field of the request should contain a URI with a session-id part that was provided in 
				the SDP associated with the MSRP session. The entity that accepted the connection looks up the 
				session-id part of the MSRP URI in the received requests, in order to determine which session 
				it matches. The session-id part is compared as case sensitive. If a match exists, the entity MUST 
				assume that the host that formed the connection is the host to which this URI was given. If no 
				match exists, the entity MUST reject the request with a 481 response. The entity MUST also check to 
				make sure the session is not already in use on another connection. If the session is already in 
				use, it MUST reject the request with a 506 response.			
			</t>
		</section>
		
		<section title="Usage of 'sessmatch' option-tag" toc="default">
			<t>
				This section describes how an MSRP entity that supports the sessmatch
				extension uses the sessmatch option-tag.
			</t>
			<t>
				An MSRP entity that supports the sessmatch extension, and is not 
				located behind an MSRP relay, MUST insert the 'sessmatch' option-tag  
				in the Supported header field of the initial INVITE request for a session 
				that contains MSRP media. If at least one reliably sent successful 
				response to the intial INVITE request contains the 'sessmatch' option-tag
				in the Supported header field of the response, the MSRP entity MUST 
				use the session matching procedures defined in this specification during 
				the session. Otherwise, if the MSRP entity wants the MSRP session to 
				proceed, the MSRP entity MUST use the procedures defined in RFC 4975.
			</t>
			<t>
				If an MSRP entity that supports the sessmatch extension receives an 
				initial INVITE request that contains the 'sessmatch' option-tag in 
				the Supported or Require header field of the request, and if it is not 
				located behind an MSRP relay, it MUST insert the 'sessmatch' option-tag 
				in the Supported header field of at least one reliably sent successful 
				response to the intial INVITE request, and it MUST use the session
				matching procedures defined in this specification during the session.
				Otherwise, if the MSRP entity wants the MSRP session to proceed,
				the MSRP entity MUST NOT insert the 'sessmatch' option-tag in
				a successful response to the initial INVITE request, and it MUST use 
				the session matching procedures defined in RFC 4975.			
			</t>
			<t>
				In addition to inserting the 'sessmatch' option-tag in the Supported
				header field of the INVITE request, if an entity is performing MSRP 
				related procedures that require the remote MSRP entity to support 
				the sessmatch extension in order to enable MSRP media, it MUST also 
				insert the 'sessmatch' option-tag in the Require header field.
			</t>
			<t> 
				NOTE: An example of a scenarios where an entity needs to insert the 
				'sessmatch' option-tag in the Require header field, is when it acts as 
				an intermediary entity that modifies the SDP a=path attribute 
				address information, in order to anchor and forward MSRP traffic, but 
				will not be able to perform the corresponding address information changes in the 
				associated MSRP messages. The actions taken by such entity in 
				case the remote MSRP entity does not support the sessmatch extension, 
				and therfore sends a 420 (Not Supported) response to the INVITE request, 
				is outside the scope of this specification.
			</t>
		</section>
		
		<section title="Uniqueness of the session-id" anchor="sec-security-unique" toc="default">
			<t>
				The session-id used to perform session matching is retrieved from the To-Path header field
				MSRP URI of a received MSRP message. The session-id has been generated by the receiving 
				MSRP entity itself. The MSRP entity MUST ensure that the session-id is unique among
				the other session-ids generated by that MSRP entity.
			</t>
		</section>
    </section>  

	<section title="ALG assumptions" toc="default">
		<section title="General" toc="default">
			<t>
				This document does not specify ALG behavior. However, as the main reason behind the sessmatch extension is to
				allow MSRP entities to communicate in networks where ALGs are present, this document makes certain assumptions 
				regarding to how such ALGs behave.
			</t>
		</section>
		<section title="MSRP awareness" toc="default">
			<t>
				This document assumes that an ALG is MSRP aware, meaning that it modifies the address information in
				the SDP a=path attribute in order to anchor the MSRP communication, but that the ALG does not perform 
				the associated modification in the To-Path and From-Path header fields of MSRP messages.
			</t>
			<t>
				NOTE: Other types of media traffic are normally routed using the SDP c/m-lines, which an ALG can
				modify in order to anchor such media communication.
			</t>
		</section>
		<section title="TCP connection reuse" toc="default">
			<t>
				When the sessmatch extension is used, ALGs are not required to parse and modify the MSRP payload.
				An ALG that does not parse the MSRP payload might not enable re-usage of TCP connections for multiple 
				MSRP sessions. Instead, in order to associate an MSRP message with a specific session, the ALG often 
				assigns a unique local address:port combination for each MSRP session.
			</t>
		</section>
		<section title="SDP integrity" toc="default">
			<t>
				This document assumes that an ALG, in order to anchor the MSRP communication, modifies the 
				address and port information in the SDP a=path attribute, and therefor can not be
				deployed in environments that require SIP identity based peer-to-peer SDP protection. 
			</t>				
		</section>		
		<section title="TLS" toc="default">
			<t>				
				This document considers two approaches how an ALG handles TLS 
				protected MSRP connections.
			</t>
			<t>
				In the first approach, the ALG relays the MSRP media packages at the       
				transport layer. The TLS handshake and resulting security association (SA)
				are established peer-to-peer between the MSRP endpoints. The ALG will 
				see encrypted MSRP media pacakges, but is unable to inspect the cleartext 
				content.
			</t>
			<t>
				In the second approach, the ALG acts as a TLS B2BUA, meaning that
				separate SAs are established between the ALG and each MSRP endpoint. The ALG
				decrypts MSRP media packages received from one MSRP endpoint, and then re-encrypts 
				them before sending them toward the other MSRP endpoint. With this approach, the ALG 
				can inspect and modify the cleartext content.
			</t>
		</section>		
    </section>	
	
    <section title="Security Considerations" anchor="sec-security" toc="default">		
		<section title="MSRP URI as shared secret" anchor="sec-security-secret" toc="default">
			<t>
				An MSRP entity that does not support the sessmatch extension uses the complete 
				MSRP URI (scheme, authority, transport, session-id) as a shared secret in order to 
				determine that an incoming transport connection originates from the intended endpoint device. 
				The shared secret needs to be hard to guess, but in reality only the session-id 
				part with it's minimum 80 bit of randomness is hard to guess. Using only the 
				MSRP URI session-id part as shared secret is therefore roughly as good as using the 
				complete URI.		
			</t>
		</section>
			
		<section title="Man in the middle" anchor="sec-security-mitm" toc="default">
			<t>
				The sessmatch extension makes it easier for a man in the middle (MiTM) to transparently 
				insert itself in the communication between MSRP endpoints in order to monitor or record 
				unproteted MSRP communication. It does not however enable a MiTM to monitor TLS protected 
				MSRP or to in any significant way modify the MSRP communication content. 
				That would require the MiTM to terminate the TCP/MSRP or TCP/TLS/MSRP connection 
				in both directions, eventhough it would not need to allign the address information in 
				the TCP/IP header of the media packets with the modification in the associated SDP a=path 
				attribute.
			</t>
		</section>
				
		<section title="TLS" anchor="sec-security-tls" toc="default">
			<t>
				If an ALG relays TLS connections, MSRP endpoints will not be able to use name based 
				authentication nor fingerprint based authentication for TLS.
			</t>
			<t>
				With name based authentication the problem is that each MSRP endpoint would present a  
				certificate associated to its the hostname, which would match the authority 
				part of the MSRP URI inserted in the SDP a=path attribute of the offer or
				answer. However, when the ALG modifies the MSRP URI in the SDP a=path attribute, 
				the resulting authority part will no long match, and the TLS handshake 
				will fail.
			</t>
			<t>
				With fingerprint based authentication the problem is instead that the "SIP 
				Identity" based integrity protection of SDP will break. 
			</t>
			<t>
				If an ALG acts as a TLS B2BUA, MSRP endpoints will be able to use
				both name based and fingerprint based authentication for TLS, as the ALG 
				acts as a TLS endpoint. As the ALG acts as a TLS endpoints, MSRP endpoint might 
				be given an incorrect impression that there is an end-to-end SA between the 
				MSRP endpoints.
			</t>
			<t>
				Considering the issues above, in order for MSRP endpoints to be able 
				to authenticate TLS in a secure manner in a network where ALGs are 
				present, an MSRP endpoint supporting the sessmatch extension SHOULD, 
				in addition to the authentication mechanisms described in RFC 4975, 
				support an authentication mechanism that does not rely on the a=path
				attribute value being transported unchanged peer-to-peer. It is 
				RECOMMENDED that an MSRP endpoint supporting the sessmatch extension 
				supports one of the following authentication mechanisms:
			</t>
			<t>
				1) TLS certificates together with support of interacting with a
				Certificate Management Service [ref to draft-ietf-sip-certs], to which it
				publishes the public version of its own self-signed certificate and
				from which it fetches on need the public certificates of other
				endpoints; or
			</t>
			<t>
				2) TLS-PSK managed e.g by MIKEY-TICKET based Key Management and Key
				Management Service <xref target="RFC6043" pageno="false" format="default" />.
			</t>
			<t>
				An MSRP endpoint that supports the sessmatch extension and one of the
				mechanisms above SHALL, when it creates an SDP offer for MSRPS, in 
				addition to including the SDP attributes associated with the
				TLS authentication mechanisms described in RFC 4975, include the
				SDP attributes associated with the supported authentication 
				mechanism above. If both MSRP endpoints support the same
				authentication mechanism based on pre-shared secrets, that
				mechanism SHALL be used, rather than a mechanism defined in RFC 4975.
			</t>
			<t>
				NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key Management and Key
				Management Service authentication mechanism for the IP Multimedia Subsystem (IMS).
			</t>
			<t>
				If MSRP endpoints supporting sessmatch do not support a common TLS authentication 
				based on a pre-shared secret, and neither MSRP endpoint is located 
				behind an MSRP relay, they SHALL either (based on local policy or configuration):
			</t>
			<t>
				1) Use a TLS authenctication mechanism defined in RFC 4975, which will succeed 
				if there are no ALGs in the MSRP path; or 
			</t>
			<t>
				2) When support of the sessmatch extension is indicated in a request or response 
				received from the other MSRP endpoint, use fingerprint based authentication without 
				performing SIP Identity based integrity check, and thus trust the network entities 
				in the signaling path.
			</t>
			<t>
				NOTE: The second alternative is needed, in networks where ALGs are present, if 
				the user whishes to establish a TLS based communication even if one of the MSRP endpoint, 
				or the network, does not support a common TLS authentication mechanism based on a
				pre-shared secret. As defined in RFC 4975, if TLS autentication fails, users 
				need to be able to decide whether to try to establish an MSRP connection without TLS 
				protection. 
			</t>
		</section>
				
    </section>
	
	<section title="IANA Considerations" toc="default">
		<t>
			This section registers a new SIP option-tag, according to the procedures of RFC 3261.
		</t>
		<section title="IANA Registration of the sessmatch Option Tag" toc="default">
			<t>
				This section registers a new SIP option tag, sessmatch. The
				required information for this registration, as specified in RFC 3261,
				is:
			</t>
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
    Name: sessmatch

    Description: This option tag is for indicating support of the MSRP session
		matching mechanism defined in RFC XXXX. When present in a Supported header
		field, it indicates that the sending UA supports the session matching 
		mechanism. When present in a Require header field of a request, it indicates 
		that the reciving UA MUST support the session matching mechanism.
]]></artwork>
      </section>
    </section>
	
    <section title="Acknowledgements" anchor="sec-acks" toc="default">
		<t>
			Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, 
			Robert Sparks, Salvatore Loreto, Shida Schubert, Ted Hardie and Richard L Barnes for their 
			guidance and input in order to produce this document.
		</t>
    </section>
	<section title="Change Log">
			<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
			<t>
				Changes from draft-ietf-simple-msrp-sessmatch-10
				<list style="symbols">
					<t>Sessmatch option-tag added, based on WG discussions and concensus.</t>	
				</list>
			</t>
			<t>
				Changes from draft-ietf-simple-msrp-sessmatch-08
				<list style="symbols">
					<t>OPEN ISSUE regarding the need for a sessmatch option-tag removed.</t>	
				</list>
			</t>
			<t>
				Changes from draft-ietf-simple-msrp-sessmatch-07
				<list style="symbols">
					<t>Sessmatch defined as an MSRP extension, rather than MSRP update</t>
					<t>Additional security considerations text added</t>
				</list>
			</t>
	</section>	
</middle>
<back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.3261"?>		
		<?rfc include="reference.RFC.4975"?>
		<?rfc include="reference.RFC.4976"?>
    </references>
    <references title="Informative References">
		<?rfc include="reference.RFC.6043"?>
		<?rfc include="reference.3GPP.23.228"?>
	</references>
</back>
</rfc>