Draft: draft-jones-perc-dtls-tunnel

Commentary: Update the tunnel spec to reflect the usage of TLS rather than DTLS between the media distributor and key distributor . Change the specification format of the tunnel message to the TLS style . Add an endpoint disconnect message .
Paragraph (version A):
This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.
Paragraph (version B):
This document defines a TLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.
Paragraph (version A):
By establishing this DTLS tunnel between the media distributor and
key distributor and implementing the protocol defined in this
document, it is possible for the media distributor to facilitate the
establishment of a secure DTLS association between an endpoint and
the key distributor in order for the endpoint to receive E2E and HBH
keying material.  At the same time, the key distributor can securely
provide the HBH keying material to the media distributor.
Paragraph (version B):
By establishing this TLS tunnel between the media distributor and key
distributor and implementing the protocol defined in this document,
it is possible for the media distributor to facilitate the
establishment of a secure DTLS association between an endpoint and
the key distributor in order for the endpoint to receive E2E and HBH
keying material.  At the same time, the key distributor can securely
provide the HBH keying material to the media distributor.
Paragraph (version A):
This section provides an example message flow to help clarify the
procedures described later in this document.  It is necessary that
the key distributor and media distributor establish a mutually
authenticated DTLS association for the purpose of sending tunneled
messages, though the complete DTLS handshake for the tunnel is not
shown in fig-message-flow since there is nothing new this document
introduces with regard to those procedures.
Paragraph (version B):
This section provides an example message flow to help clarify the
procedures described later in this document.  It is necessary that
the key distributor and media distributor establish a mutually
authenticated TLS association for the purpose of sending tunneled
messages, though the complete TLS handshake for the tunnel is not
shown in fig-message-flow since there is nothing new this document
introduces with regard to those procedures.
Paragraph (version A):
Once the tunnel is established, it is possible for the media
distributor to relay the DTLS messages between the endpoint and the
key distributor.  fig-message-flow shows a message flow wherein the
endpoint uses DTLS-SRTP to establish an association with the key
distributor.  In the process, the media distributor shares its
supported SRTP protection profile information (see RFC5764) and the
key distributor shares HBH keying material and selected cipher with
the media distributor.  The message used to tunnel the DTLS messages
is named "Tunnel" and can include Profiles or Key Info data.
Paragraph (version A):
All messages sent by the media distributor will contain SRTP
protection profiles supported by the media distributor at the end of
the Tunnel message.  The key distributor will select a common profile
supported by both the endpoint and the media distributor to ensure
that hop-by-hop operations can be successfully performed.
Paragraph (version A):
Further, the key distributor will provide the SRTP RFC3711 keying
material to the media distributor for HBH operations at the time it
sends a DTLS Finished message to the endpoint via the tunnel.  The
media distributor would extract this Key Info when received and use
it for hop-by-hop encryption and authentication.  The delivery of the
keying information along with the completion of the DTLS handshake
ensures the delivery of the keying information is fate shared with
completion of the DTLS handshake.  This guarantees that the media
distributor will have the HBH keying information before it receives
any media that is encrypted or authenticated with that key.
Paragraph (version B):
Once the tunnel is established, it is possible for the media
distributor to relay the DTLS messages between the endpoint and the
key distributor.  fig-message-flow shows a message flow wherein the
endpoint uses DTLS-SRTP to establish an association with the key
distributor.  In the process, the media distributor shares its
supported SRTP protection profile information (see RFC5764) and the
key distributor shares HBH keying material and selected cipher with
the media distributor.  The message used to tunnel the DTLS messages
is named "Tunnel" and can include Profiles, Media Keys data, or
endpoint disconnection notifications.
Paragraph (version B):
SRTP protection profiles supported by the media distributor will be
sent in a supported profiles message.  The key distributor will
select a common profile supported by both the endpoint and the media
distributor to ensure that hop-by-hop operations can be successfully
performed.
Paragraph (version B):
Further, the key distributor will provide the SRTP RFC3711 keying
material to the media distributor for HBH operations at the time it
sends a DTLS Finished message to the endpoint via the tunnel.  The
media distributor would extract this Media Keys when received and use
it for hop-by-hop encryption and authentication.  The delivery of the
keying information along with the completion of the DTLS handshake
ensures the delivery of the keying information is fate shared with
completion of the DTLS handshake.  This guarantees that the media
distributor will have the HBH keying information before it receives
any media that is encrypted or authenticated with that key.
Paragraph (version A):
It is important to note that the tunneling protocol described in this
document is not an extension to TLS RFC5246 or DTLS RFC6347.  Rather,
it is a protocol that transports DTLS messages generated by an
endpoint or key distributor as data inside of the DTLS association
established between the media distributor and key distributor.
Paragraph (version B):
It is important to note that the tunneling protocol described in this
document is not an extension to TLS RFC5246 or DTLS RFC6347.  Rather,
it is a protocol that transports DTLS messages generated by an
endpoint or key distributor as data inside of the TLS association
established between the media distributor and key distributor.
Paragraph (version A):
Either the media distributor or key distributor initiates the
establishment of a DTLS tunnel.  Which entity acts as the DTLS client
when establishing the tunnel and what event triggers the
establishment of the tunnel are outside the scope of this document.
Further, how the trust relationships are established between the key
distributor and media distributor are also outside the scope of this
document.
Paragraph (version A):
A tunnel MUST be a mutually authenticated DTLS association.  It is
used to relay DTLS messages between any number of endpoints and the
key distributor.
Paragraph (version B):
Either the media distributor or key distributor initiates the
establishment of a TLS tunnel.  Which entity acts as the TLS client
when establishing the tunnel and what event triggers the
establishment of the tunnel are outside the scope of this document.
Further, how the trust relationships are established between the key
distributor and media distributor are also outside the scope of this
document.
Paragraph (version B):
A tunnel MUST be a mutually authenticated TLS association.  It is
used to relay DTLS messages between any number of endpoints and the
key distributor.
Paragraph (version A):
When a message from the key distributor includes "Key Info," the
media distributor MUST extract the cipher and keying material
conveyed in order to subsequently perform HBH encryption and
authentication operations for RTP and RTCP packets sent between it
and an endpoint.  Since the HBH keying material will be different for
each endpoint, the media distributor uses the association identifier
included by the key distributor to ensure that the HBH keying
material is used with the correct endpoint.
Paragraph (version B):
When a message from the key distributor includes "Media Keys," the
media distributor MUST extract the cipher and keying material
conveyed in order to subsequently perform HBH encryption and
authentication operations for RTP and RTCP packets sent between it
and an endpoint.  Since the HBH keying material will be different for
each endpoint, the media distributor uses the association identifier
included by the key distributor to ensure that the HBH keying
material is used with the correct endpoint.
Paragraph (version B):
When the media distributor detects an endpoint has disconnected, the
media distributors SHOULD send a Endpoint Disconnect message with the
association identifier assigned to the endpoint.  The media
distributor SHOULD use RTP and RTCP behavior to detect disconnected
endpoints.  The particulars of how RTCP is to be used to detect
endpoint , such as timeout period, is not specified.  The media
distributor MAY use additional indicators to determine when an
endpoint has disconnected.
Paragraph (version A):
The key distributor MUST send a DTLS Finished message to the endpoint
at the point the DTLS handshake completes using the Tunnel + Key Info
message.  The Key Info includes the selected cipher (i.e. protection
profile), MKI RFC3711 value (if any), SRTP master keys, and SRTP
master salt values.
Paragraph (version B):
The key distributor MUST send a DTLS Finished message to the endpoint
at the point the DTLS handshake completes using the Tunnel + Media
Keys message.  The Media Keys includes the selected cipher (i.e.
protection profile), MKI RFC3711 value (if any), SRTP master keys,
and SRTP master salt values.
Paragraph (version A):
The tunneling protocol is transmitted over the DTLS association
established between the media distributor and key distributor as
application data.  The basic message is referred to as the Tunnel
message.  The media distributor will append supported SRTP protection
profiles to all Tunnel messages it sends, forming the Tunnel +
Profiles message.  The key distributor will append information
necessary for the media distributor to perform HBH encryption and
authentication as it transmits the DTLS Finished message to the
endpoint, forming the Tunnel + Key Info message.  The Tunnel, Tunnel
+ Profiles, and Tunnel + Key Info messages are detailed in the
following sub-sections.
Paragraph (version A):
Association Identifier: This is the association identifier used to
uniquely identify each endpoint in a conference (32-bits).
Paragraph (version A):
DTLS Message Length: Length in octets of following Tunneled DTLS
Message (16-bits).
Paragraph (version A):
Tunneled DTLS Message: This is the DTLS message exchanged between the
endpoint and key distributor.  The length varies based on the value
specified in the previous field.
Paragraph (version A):
Data Type: Indicates the type of data that follows.  The value is
0x01 for SRTP protection profiles supported by the media distributor.
Paragraph (version A):
Length: This is the length in octets of the protection profiles.
This length must be greater than or equal to 2.
Paragraph (version A):
Protection Profiles: This is an array of two-octet SRTP protection
profile values as per RFC5764, with each value represented in network
byte order.
Paragraph (version A):
Data Type: Indicates the type of data that follows.  This value is
0x02 for key information.
Paragraph (version A):
Protection Profile: This is the SRTP protection profile (see RFC5764)
the media distributor MUST use to encrypt and decrypt packets sent
and received between itself and the endpoint.
Paragraph (version A):
MKI Length: This is the length in octets of the MKI field.  A value
of zero indicates that the MKI field is absent.
Paragraph (version A):
CWSMK Length: The length of the "Client Write SRTP Master Key" field.
Paragraph (version A):
Client Write SRTP Master Key: The value of the SRTP master key used
by the client (endpoint).
Paragraph (version A):
SWSMK Length: The length of the "Server Write SRTP Master Key" field.
Paragraph (version A):
Server Write SRTP Master Key: The value of the SRTP master key used
by the server (media distributor).
Paragraph (version A):
CWSMS Length: The length of the "Client Write SRTP Master Salt"
field.
Paragraph (version A):
Client Write SRTP Master Salt: The value of the SRTP master salt used
by the client (endpoint).
Paragraph (version A):
SWSMS Length: The length of the "Server Write SRTP Master Salt"
field.
Paragraph (version A):
Server Write SRTP Master Salt: The value of the SRTP master salt used
by the server (media distributor).
Paragraph (version A):
Tunneling DTLS messages received by an endpoint inside the DTLS
tunnel between the media distributor and key distributor introduces
only a small risk of message fragmentation, particularly with the
initial handshake messages carrying client and server certificates.
The small risk of fragmentation is considered acceptable given that
DTLS specifies how to recover from loss of handshake messages.
Paragraph (version A):
The additional overhead required for the tunnel is calculated to be
approximately 50 octets for messages transmitted from the media
distributor to the key distributor.  Messages from the key
distributor would generally have slightly less overhead since they do
not carry a list of protection profiles.  The one exception is the
Tunnel + Key Info message, which is slightly larger as it contains
key and salt information for the media distributor.  While the Tunnel
+ Key Info message is larger than Tunnel + Profiles, the DTLS
message(s) transmitted in that flight (ChangeCipherSpec and Finished)
are very small and so the overhead does not impose a risk of
introducing packet fragmentation.
Paragraph (version B):
Tunneled messages are transported via the TLS tunnel as application
data between the media distributor and the key distributor.  Tunnel
messages are specified using the format described in rfc5246 section
4.  As in rfc5246, all values are stored in network byte (big-endian)
order; the uint32 represented by the hex bytes 01 02 03 04 is
equivalent to the decimal value 16909060.
Paragraph (version B):
enum.
Paragraph (version B):
version indicates the version of this protocol.
Paragraph (version B):
MsgType is represented by a single octet value.
Paragraph (version B):
The four possible message types are defined as following.
Paragraph (version B):
The fields are described as follows: * associationID: The value of
the association identifier used to uniquely identify each endpoint in
a conference * SRTPProtectionProfile: The value of the two-octet SRTP
protection profile value as per RFC5764.  * mki: Master key
identifier RFC3711.  * clientWriteKey: The value of the SRTP master
key used by the client (endpoint).  * serverWriteKey: The value of
the SRTP master key used by the server (media distributor).  *
clientWriteSalt: The value of the SRTP master salt used by the client
(endpoint).  * serverWriteSalt: The value of the SRTP master salt
used by the server (media distributor).