SIMPLE Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Standards Track S. Blau
Expires: May 13, 2011 Ericsson AB
November 9, 2010
Session Matching Update for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-sessmatch-08.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.
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 May 13, 2011.
Copyright Notice
Copyright (c) 2010 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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Holmberg & Blau Expires May 13, 2011 [Page 1]
Internet-Draft MRSP November 2010
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. Session matching mechanism . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 5
5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 5
5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 6
5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Holmberg & Blau Expires May 13, 2011 [Page 2]
Internet-Draft MRSP November 2010
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 generic 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 3rd Generation
Partnership Project (3GPP) Interconnect Border Control Function
(IBCF) [3GPP.23.228].
An MSRP entity, compliant with RFC 4975 [RFC4975] and RFC 4976
[RFC4976] cannot communicate with ALGs described above, unless the
ALGs implement MSRP Back-To-Back User Agent (B2BUA) functionality.
The reason is that such MSRP entities use the MSRP URI comparison
mechanism defined in RFC 4975 in order to match an MSRP message to an
MSRP session (session matching). 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 use a
different mechanism for matching an MSRP message with an MSRP
session. Instead of using the MSRP URI comparison procedure defined
in RFC 4975, only the MSRP session-id part is used for the session
matching by entities that support the sessmatch extension.
If an MSRP entity that supports the sessmatch extension communicates
with an ALG that does not implement MSRP B2BUA functionality, there
are restrictions regarding the usage of TLS authentication. In case
TLS with name based authentication is used, ALGs need to implement
MSRP B2BUA functionality communicating with MSRP entities that
support the sessmatch extension, in order to prevent the MSRP
communication from failing due to a certificate missmatch.
The sessmatch extension is backward compatible. In the absence of
ALGs that do not implement MSRP B2BUA functionality, MSRP entities
that do not implement the sessmatch extension can interoperate with
Holmberg & Blau Expires May 13, 2011 [Page 3]
Internet-Draft MRSP November 2010
entities that do implement the extension, as none of the session
matching mechanisms will not fail.
MSRP entities that do not support 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.
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. Session matching mechanism
This section defines how MSRP entities that support the sessmatch
extension perform session matching.
Session matching, as defined in RFC 4975, is performed in order to
associate a MSRP message with a session. The passive MSRP entity
(the entity that does not initiate the TCP connection) of a session
Holmberg & Blau Expires May 13, 2011 [Page 4]
Internet-Draft MRSP November 2010
will also, when it receives the first MSRP message, use session
matching in order to bind the session to the specific TCP connection,
in order to know on which TCP connection to send outgoing MSRP
messages associated with the session.
When a MSRP entity that supports the sessmatch extension receives an
MSRP message, it uses the To-Path header field MSRP URI session-id
part value to associate the MSRP mesage with a session.
In accordance wih RFC 4975, the session-id part value is compared as
case sensitive. If the session-id value is matched with an existing
session, the MSRP entity must check that the MSRP message was
received on the TCP connection bound to the session. If not, the
MSRP message is rejected with a 506 response.
The difference between the session matching mechanism defined in RFC
4975, and the mechanism defined in this specification for the
sessmatch extension, is that while the mechanism in RFC 4975 uses the
MSRI URI comparison rules for session matching, the sessmatch
extension only uses the MSRP URI session-id part.
OPEN ISSUE: It needs to be studied whether an SIP option-tag is
needed in order to indicate and/or negotiate support and usage of the
sessmatch extension.
5. Security Considerations
5.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 peer 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 that 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.
5.2. Uniqueness of the session-id
For session matching, the session-id only needs to be unique within
the scope of the MSRP entity that created it. In order for an MSRP
entity to ensure this, there is no need to scope the session-id
namespace by the MSRP URI authority part.
As stated in the RFC4975, when using the complete URI as shared
secret, the secrecy is entirely provided by the 80-bit randomness of
Holmberg & Blau Expires May 13, 2011 [Page 5]
Internet-Draft MRSP November 2010
the MSRP URI session-id par, so it makes no difference if only the
session-id part is used as shared secret.
5.3. Man in the middle
A man-in-the-middle (MiTM) that wants to insert itself in the MSRP
communication path, in order to modify unprotected MSRP messages,
needs to implement MSRP B2BUA functionality. If the MiTM
communicates with MSRP entities that support the sessmatch extension,
it does not need to modify the ToPath and FromPath header fields in
the MSRP messages, which is the case if it communicates with an MSRP
entities that do not support the extension. In both cases, however,
the MiTM needs to terminate the TCP/TLS connection used for the MSRP
communication.
The sessmatch extension makes it easier for a MiTM to monitor and
record unprotected MSRP communication, as it allows the MiTM to
anchor the MSRP communication even if it does not implement MSRP
B2BUA functionality.
The sessmatch extension does not make it easier for a MiTM to insert
itself in the SIP/SDP signaling path, neither does it make it easier
for a MiTM to forward MSRP messages towards malicious MSRP entities
(as it does not require the MiTM to anchor the MSRP communication).
5.4. TLS
The sessmatch extension does not in any way modify Transport layer
security (TLS) [RFC5246] security procedures as such, and in general
MSRP entities that support the sessmatch extension can use the TLS
security mechanisms defined in RFC 4975. However, as the sessmatch
extension makes it possible for ALGs to anchor MSRP communication,
without having to implement MSRP B2BUA functionality, TLS with name
based authentication cannot be used if MSRP entities are
communicating with such ALGs. In order to be able to use TLS with
name based authentication from failing, ALGs need to implement MSRP
B2BUA functionality.
An ALG that anchors MSRP communication modifies the MSRP routing
information in the associated SDP signalling. Such behavior will
prevent end-to-end SDP integrity. In the presence of such ALGs it
will therefore generally only be possible to provide hop-to-hop SDP
integrity, which means that malicious ALGs will be able to modify the
SDP information.
When possible, it is RECOMMENDED that MSRP entities that support the
sessmatch extension use TLS pre-shared key ciphersuites (TLS-PSK)
[RFC4279] together with a key management scheme where the key
Holmberg & Blau Expires May 13, 2011 [Page 6]
Internet-Draft MRSP November 2010
security does not rely on SDP integrity protection, such as
Multimedia Internet KEYing (MIKEY) [RFC3830] or Ticket Based Modes of
Key Distribution Multimedia Internet KEYing (MIKEY-TICKET) [RFC6043].
RFC 4567 [RFC4567] defines Key Management Extensions for SDP.
6. IANA Considerations
OPEN ISSUE: It needs to be studied whether an SIP option-tag is
needed in order to indicate and/or negotiate support and usage of the
sessmatch extension.
7. 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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
8.2. Informative References
[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.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
Holmberg & Blau Expires May 13, 2011 [Page 7]
Internet-Draft MRSP November 2010
December 2005.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 10.2.0, September 2010.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Staffan Blau
Ericsson AB
P.O Box 407
Sweden
Email: staffan.blau@ericsson.com
Holmberg & Blau Expires May 13, 2011 [Page 8]
