SIMPLE Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track S. Blau
Expires: November 13, 2011 Ericsson AB
May 12, 2011
Session Matching Update for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-sessmatch-11.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 13, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Holmberg & Blau Expires November 13, 2011 [Page 1]
Internet-Draft MRSP May 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability statement . . . . . . . . . . . . . . . . . . . 4
4. Sessmatch mechanism . . . . . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Session matching . . . . . . . . . . . . . . . . . . . . . 4
4.3. Usage of 'sessmatch' option-tag . . . . . . . . . . . . . 5
4.4. Uniqueness of the session-id . . . . . . . . . . . . . . . 6
5. ALG assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. MSRP awareness . . . . . . . . . . . . . . . . . . . . . . 6
5.3. TCP connection reuse . . . . . . . . . . . . . . . . . . . 6
5.4. SDP integrity . . . . . . . . . . . . . . . . . . . . . . 7
5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . 7
6.2. Man in the middle . . . . . . . . . . . . . . . . . . . . 7
6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. IANA Registration of the sessmatch Option Tag . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Holmberg & Blau Expires November 13, 2011 [Page 2]
Internet-Draft MRSP May 2011
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is designed to
use MSRP relays [RFC4976] as a means for Network Address Translation
(NAT) traversal and policy enforcement.
However, many Session Initiation Protocol (SIP) [RFC3261] 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) [3GPP.23.228] 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).
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], 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 [RFC4975]
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.
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.
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.
Holmberg & Blau Expires November 13, 2011 [Page 3]
Internet-Draft MRSP May 2011
2. Conventions
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
[RFC2119].
In this specification the terminology "fingerprint based TLS
authentication" and "name based TLS authentication" are used to refer
to the two cases where:
1. An endpoint use a self-signed TLS certificate and sends a
certificate fingerprint in SDP (fingerprint based TLS
authentication).
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).
3. Applicability statement
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.
4. Sessmatch mechanism
4.1. General
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.
4.2. Session matching
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.
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
Holmberg & Blau Expires November 13, 2011 [Page 4]
Internet-Draft MRSP May 2011
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.
4.3. Usage of 'sessmatch' option-tag
This section describes how an MSRP entity that supports the sessmatch
extension uses the sessmatch option-tag.
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.
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.
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.
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
Holmberg & Blau Expires November 13, 2011 [Page 5]
Internet-Draft MRSP May 2011
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.
4.4. Uniqueness of the session-id
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.
5. ALG assumptions
5.1. General
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.
5.2. MSRP awareness
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.
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.
5.3. TCP connection reuse
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.
Holmberg & Blau Expires November 13, 2011 [Page 6]
Internet-Draft MRSP May 2011
5.4. SDP integrity
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.
5.5. TLS
This document considers two approaches how an ALG handles TLS
protected MSRP connections.
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.
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.
6. Security Considerations
6.1. MSRP URI as shared secret
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.
6.2. Man in the middle
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
Holmberg & Blau Expires November 13, 2011 [Page 7]
Internet-Draft MRSP May 2011
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.
6.3. TLS
If an ALG relays TLS connections, MSRP endpoints will not be able to
use name based authentication nor fingerprint based authentication
for TLS.
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.
With fingerprint based authentication the problem is instead that the
"SIP Identity" based integrity protection of SDP will break.
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.
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:
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
2) TLS-PSK managed e.g by MIKEY-TICKET based Key Management and Key
Management Service [RFC6043].
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
Holmberg & Blau Expires November 13, 2011 [Page 8]
Internet-Draft MRSP May 2011
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.
NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key
Management and Key Management Service authentication mechanism for
the IP Multimedia Subsystem (IMS).
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):
1) Use a TLS authenctication mechanism defined in RFC 4975, which
will succeed if there are no ALGs in the MSRP path; or
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.
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.
7. IANA Considerations
This section registers a new SIP option-tag, according to the
procedures of RFC 3261.
7.1. IANA Registration of the sessmatch Option Tag
This section registers a new SIP option tag, sessmatch. The required
information for this registration, as specified in RFC 3261, is:
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.
Holmberg & Blau Expires November 13, 2011 [Page 9]
Internet-Draft MRSP May 2011
8. Acknowledgements
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.
9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-simple-msrp-sessmatch-10
o Sessmatch option-tag added, based on WG discussions and concensus.
Changes from draft-ietf-simple-msrp-sessmatch-08
o OPEN ISSUE regarding the need for a sessmatch option-tag removed.
Changes from draft-ietf-simple-msrp-sessmatch-07
o Sessmatch defined as an MSRP extension, rather than MSRP update
o Additional security considerations text added
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
10.2. Informative References
[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based
Modes of Key Distribution in Multimedia Internet KEYing
(MIKEY)", RFC 6043, March 2011.
Holmberg & Blau Expires November 13, 2011 [Page 10]
Internet-Draft MRSP May 2011
[3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 10.4.0, March 2011.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Staffan Blau
Ericsson AB
Stockholm 12637
Sweden
Email: staffan.blau@ericsson.com
Holmberg & Blau Expires November 13, 2011 [Page 11]
