Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6230

Media Control Channel Framework

Pages: 49
Proposed Standard
Errata
Part 3 of 3 – Pages 36 to 49
First   Prev   None

Top   ToC   RFC6230 - Page 36   prevText

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
Top   ToC   RFC6230 - Page 37
   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
Top   ToC   RFC6230 - Page 38
   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.
Top   ToC   RFC6230 - Page 39
   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:
Top   ToC   RFC6230 - Page 40
    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].
Top   ToC   RFC6230 - Page 41

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.
Top   ToC   RFC6230 - Page 42

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.
Top   ToC   RFC6230 - Page 43
   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
Top   ToC   RFC6230 - Page 44
  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.
Top   ToC   RFC6230 - Page 45
   [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.
Top   ToC   RFC6230 - Page 46
   [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.
Top   ToC   RFC6230 - Page 47

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.
Top   ToC   RFC6230 - Page 48
   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>
Top   ToC   RFC6230 - Page 49

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