RFC 6230
Media Control Channel Framework
12. Security Considerations
The Channel Framework provides confidentiality and integrity for the messages it transfers. It also provides assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked, as discussed in the remainder of this section. In design, the Channel Framework complies with the security-related requirements documented in "Media Server Control Protocol Requirements" [RFC5167] -- more specifically, REQ-MCP-11, REQ-MCP-12, REQ-MCP-13, and REQ-MCP-14. Specific security measures employed by the Channel Framework are summarized in the following sub-sections.12.1. Session Establishment
Channel Framework sessions are established as media sessions described by SDP within the context of a SIP INVITE dialog. In order to ensure secure rendezvous between Control Framework clients and servers, the Media Channel Control Framework should make full use of mechanisms provided by SIP. The use of the 'cfw-id' SDP attribute results in important session information being carried across the SIP network. For this reason, SIP clients using this specification MUST use appropriate security mechanisms, such as TLS [RFC5246] and SMIME [RFC5751], when deployed in open networks.12.2. Transport-Level Protection
When using only TCP connections, the Channel Framework security is weak. Although the Channel Framework requires the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see data exchanges. Sensitive data, such as private and financial data, is carried over the Control Framework channel. Clients and servers must be properly authenticated/authorized and the Control Channel must permit the use of confidentiality, replay protection, and integrity protection for the data. To ensure Control Channel protection, Control Framework clients and servers MUST support TLS and SHOULD use it by default
unless alternative Control Channel protection is used or a protected environment is guaranteed by the administrator of the network. Alternative Control Channel protection MAY be used if desired (e.g., IPsec [RFC5246]). TLS is used to authenticate devices and to provide integrity, replay protection, and confidentiality for the header fields being transported on the Control Channel. Channel Framework elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [RFC5246]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [RFC3261] MUST be supported. Other cipher-suites MAY also be supported. When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 7.3 ("Client Behavior") of RFC 5922 [RFC5922]. A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 7.4 ("Server Behavior") of RFC 5922 [RFC5922].12.3. Control Channel Policy Management
This specification permits the establishment of a dedicated Control Channel using SIP. It is also permitted for entities to create multiple channels for the purpose of failover and redundancy. As a general solution, the ability for multiple entities to create connections and have access to resources could be the cause of potential conflict in shared environments. It should be noted that this document does not carry any specific mechanism to overcome such conflicts but will provide a summary of how to do so. It can be determined that access to resources and use of Control Channels relate to policy. It can be considered implementation and deployment detail that dictates the level of policy that is adopted. The authorization and associated policy of a Control Channel can be linked to the authentication mechanisms described in this section. For example, strictly authenticating a Control Channel using TLS authentication allows entities to protect resources and ensure the required level of granularity. Such policy can be applied at the package level or even as low as a structure like a conference instance (Control Channel X is not permitted to issue commands for Control Package y OR Control Channel A is not permitted to issue commands for conference instance B). Systems should ensure that, if
required, an appropriate policy framework is adopted to satisfy the requirements for implemented packages. The most robust form of policy can be achieved using a strong authentication mechanism such as mutual TLS authentication on the Control Channel. This specification provides a Control Channel response code (403) to indicate to the issuer of a command that it is not permitted. The 403 response MUST be issued to Control Framework requests that are not permitted under the implemented policy. If a 403 response is received, a Control Framework client MAY choose to re-submit the request with differing requirements or to abandon the request. The 403 response does not provide any additional information on the policy failure due to the generic nature of this specification. Individual Control Packages can supply additional information if required. The mechanism for providing such additional information is not mandated in this specification. It should be noted that additional policy requirements to those covered in this section might be defined and applied in individual packages that specify a finer granularity for access to resources, etc.13. IANA Considerations
IANA has created a new registry for SIP Control Framework parameters. The "Media Control Channel Framework Parameters" registry is a container for sub-registries. This section further introduces sub- registries for control packages, method names, status codes, header field names, and port and transport protocol. Additionally, Section 13.6 registers a new MIME type for use with SDP. For all registries and sub-registries created by this document, the policy applied when creating a new registration is also applied when changing an existing registration.13.1. Control Packages Registration Information
This specification establishes the Control Packages sub-registry under Media Control Channel Framework Packages. New parameters in this sub-registry must be published in an RFC (either in the IETF stream or Independent Submission stream), using the IANA policy [RFC5226] "RFC Required". As this document specifies no package or template-package names, the initial IANA registration for Control Packages will be empty. The remainder of the text in this section gives an example of the type of information to be maintained by the IANA.
The table below lists the Control Packages defined in the "Media
Control Channel Framework".
Package Name Reference
------------ ---------
example1 [RFCXXXX]
13.1.1. Control Package Registration Template
Package Name:
(Package names must conform to the syntax described in
Section 8.1.)
Published Specification(s):
(Control Packages require an RFC.)
Person & email address to contact for further information:
13.2. Control Framework Method Names
This specification establishes the Method Names sub-registry under
Media Control Channel Framework Parameters and initiates its
population as follows. New parameters in this sub-registry must be
published in an RFC (either in the IETF stream or Independent
Submission stream).
CONTROL - [RFC6230]
REPORT - [RFC6230]
SYNC - [RFC6230]
K-ALIVE - [RFC6230]
The following information MUST be provided in an RFC in order to
register a new Control Framework method:
o The method name.
o The RFC number in which the method is registered.
13.3. Control Framework Status Codes
This specification establishes the Status Code sub-registry under
Media Control Channel Framework Parameters. New parameters in this
sub-registry must be published in an RFC (either in the IETF stream
or Independent Submission stream). Its initial population is defined
in Section 9. It takes the following format:
Code Description Reference
The following information MUST be provided in an RFC in order to
register a new Control Framework status code:
o The status code number.
o The RFC number in which the method is registered.
o A brief description of the status code.
13.4. Control Framework Header Fields
This specification establishes the Header Field sub-registry under
Media Control Channel Framework Parameters. New parameters in this
sub-registry must be published in an RFC (either in the IETF stream
or Independent Submission stream). Its initial population is defined
as follows:
Control-Package - [RFC6230]
Status - [RFC6230]
Seq - [RFC6230]
Timeout - [RFC6230]
Dialog-ID - [RFC6230]
Packages - [RFC6230]
Supported - [RFC6230]
Keep-Alive - [RFC6230]
Content-Type - [RFC6230]
Content-Length - [RFC6230]
The following information MUST be provided in an RFC in order to
register a new Channel Framework header field:
o The header field name.
o The RFC number in which the method is registered.
13.5. Control Framework Port
The Control Framework uses TCP port 7563, from the "registered" port
range. Usage of this value is described in Section 4.1.
13.6. Media Type Registrations
This section describes the media types and names associated with
payload formats used by the Control Framework. The registration uses
the templates defined in [RFC4288]. It follows [RFC4855].
13.6.1. Registration of MIME Media Type application/cfw
Type name: application Subtype name: cfw Required parameters: None Optional parameters: None Encoding considerations: Binary and see Section 4 of RFC 6230 Security considerations: See Section 12 of RFC 6230 Interoperability considerations: Endpoints compliant to this specification must use this MIME type. Receivers who cannot support this specification will reject using appropriate protocol mechanism. Published specification: RFC 6230 Applications that use this media type: Applications compliant with Media Control Channels. Additional Information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none) Person & email address to contact for further information: Chris Boulton <chris@ns-technologies.com> Intended usage: COMMON Restrictions on usage: Should be used only in conjunction with this specification, RFC 6230. Author: Chris Boulton Change controller: IETF MEDIACTRL working group, delegated from the IESG.
13.6.2. Registration of MIME Media Type application/ framework-attributes+xml
Type name: application Subtype name: framework-attributes+xml Required parameters: (none) Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023]. Security considerations: No known security considerations outside of those provided by core Media Control Channel Framework. Interoperability considerations: This content type provides common constructs for related Media Control Channel packages. Published specification: RFC 6230 Applications that use this media type: Implementations of appropriate Media Control Channel packages. Additional information: Magic number(s): (none) File extension(s): (none) Macintosh file type code(s): (none) Person & email address to contact for further information: Chris Boulton <chris@ns-technologies.com> Intended usage: LIMITED USE Author/Change controller: The IETF Other information: None.13.7. 'cfw-id' SDP Attribute
Contact name: Chris Boulton <chris@ns-technologies.com> Attribute name: "cfw-id". Type of attribute Media level.
Subject to charset: Not.
Purpose of attribute: The 'cfw-id' attribute indicates an
identifier that can be used to correlate the Control Channel with
the SIP INVITE dialog used to negotiate it, when the attribute
value is used within the Control Channel.
Allowed attribute values: A token.
13.8. URN Sub-Namespace for
urn:ietf:params:xml:ns:control:framework-attributes
IANA has registered a new XML namespace,
"urn:ietf:params:xml:ns:control:framework-attributes", per the
guidelines in RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>,
Chris Boulton <chris@ns-technologies.com>.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel attributes</h1>
<h2>urn:ietf:params:xml:ns:control:framework-attributes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6230.txt">
RFC 6230</a>.</p>
</body>
</html>
END
13.9. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688].
URI: urn:ietf:params:xml:ns:control:framework-attributes
Registrant Contact: IETF MEDIACTRL working group <mediactrl@ietf.org>,
Chris Boulton <chris@ns-technologies.com>.
Schema: The XML for this schema can be found in Appendix A.1 of this
document.
14. Contributors
Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document.
15. Acknowledgments
The authors would like to thank Ian Evans of Avaya, Michael
Bardzinski and John Dally of NS-Technologies, Adnan Saleem of
Radisys, and Dave Morgan for useful review and input to this work.
Eric Burger contributed to the early phases of this work.
Expert review was also provided by Spencer Dawkins, Krishna Prasad
Kalluri, Lorenzo Miniero, and Roni Even. Hadriel Kaplan provided
expert guidance on the dialog association mechanism. Lorenzo Miniero
has constantly provided excellent feedback based on his work.
Ben Campbell carried out the RAI expert review on this document and
provided a great deal of invaluable input. Brian Weis carried out a
thorough security review. Jonathan Lennox carried out a thorough SDP
review that provided some excellent modifications. Text from Eric
Burger was used in the introduction in the explanation for using SIP.
16. References
16.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.16.2. Informative References
[MSCL-THOUGHTS] Burger, E., "Media Server Control Language and Protocol Thoughts", Work in Progress, June 2006. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008. [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
Appendix A. Common Package Components
During the creation of the Control Framework, it has become clear that there are a number of components that are common across multiple packages. It has become apparent that it would be useful to collect such reusable components in a central location. In the short term, this appendix provides the placeholder for the utilities, and it is the intention that this section will eventually form the basis of an initial 'Utilities Document' that can be used by Control Packages.A.1. Common Dialog/Multiparty Reference Schema
The following schema provides some common attributes for allowing Control Packages to apply specific commands to a particular SIP media dialog (also referred to as "Connection") or conference. If used within a Control Package, the Connection and multiparty attributes will be imported and used appropriately to specifically identify either a SIP dialog or a conference instance. If used within a package, the value contained in the 'connectionid' attribute MUST be constructed by concatenating the 'Local' and 'Remote' SIP dialog identifier tags as defined in [RFC3261]. They MUST then be separated using the ':' character. So the format would be: 'Local Dialog tag' + ':' + 'Remote Dialog tag' As an example, for an entity that has a SIP Local dialog identifier of '7HDY839' and a Remote dialog identifier of 'HJKSkyHS', the 'connectionid' attribute for a Control Framework command would be: 7HDY839:HJKSkyHS It should be noted that Control Framework requests initiated in conjunction with a SIP dialog will produce a different 'connectionid' value depending on the directionality of the request; for example, Local and Remote tags are locally identifiable. As with the Connection attribute previously defined, it is useful to have the ability to apply specific Control Framework commands to a number of related dialogs, such as a multiparty call. This typically consists of a number of media dialogs that are logically bound by a single identifier. The following schema allows for Control Framework commands to explicitly reference such a grouping through a 'conferenceid' XML container. If used by a Control Package, any control XML referenced by the attribute applies to all related media dialogs. Unlike the dialog attribute, the 'conferenceid' attribute does not need to be constructed based on the overlying SIP dialog. The 'conferenceid' attribute value is system specific and should be selected with relevant context and uniqueness.
It should be noted that the values contained in both the
'connectionid' and 'conferenceid' identifiers MUST be compared in a
case-sensitive manner.
The full schema follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:control:framework-attributes"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns::control:framework-attributes"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:attributeGroup name="framework-attributes">
<xsd:annotation>
<xsd:documentation>
SIP Connection and Conf Identifiers
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="connectionid" type="xsd:string"/>
<xsd:attribute name="conferenceid" type="xsd:string"/>
</xsd:attributeGroup>
</xsd:schema>
Authors' Addresses
Chris Boulton NS-Technologies EMail: chris@ns-technologies.com Tim Melanchuk Rainwillow EMail: timm@rainwillow.com Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden EMail: smcg.stds01@mcglashan.org