One document matched: draft-thomson-avtcore-sdp-uks-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-thomson-avtcore-sdp-uks-00" category="info">

  <front>
    <title abbrev="SDP UKS">Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP)</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rftm.com</email>
      </address>
    </author>

    <date year="2016"/>

    
    
    

    <abstract>


<t>Unknown key-share attacks on the use of Datagram Transport Layer Security for
the Secure Real-Time Transport Protocol (DTLS-SRTP) and its use with Web
Real-Time Communications (WebRTC) identity assertions are described.  Simple
mitigation techniques are defined.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The use of Transport Layer Security (TLS) <xref target="RFC5246"/> with the Session
Description Protocol (SDP) <xref target="RFC4566"/> is defined in <xref target="RFC4572"/>.  Further use
with Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/> and the Secure
Real-time Transport Protocol (SRTP) <xref target="RFC3711"/> is defined as DTLS-SRTP
<xref target="RFC5763"/>.</t>

<t>In these specifications, key agreement is performed using the TLS or DTLS
handshaking protocol, with authentication being tied back to the session
description (or SDP) through the use of certificate fingerprints.
Communication peers check that a hash, or fingerprint, provided in the SDP
matches the certificate that is used in the TLS (or DTLS) handshake.  This
is defined in <xref target="RFC4572"/>.</t>

<t>The design of DTLS-SRTP relies on the integrity of the signaling channel.
Certificate fingerprints are assumed to be provided by the communicating peers
and carried by the signaling channel without being subject to modification.
However, this design is vulnerable to an unknown key-share (UKS) attack where a
misbehaving endpoint is able to advertise a key that it does not control.  This
leads to the creation of sessions where peers are confused about the identify of
the participants.</t>

<t>An extension to TLS is defined that can be used to mitigate this attack.</t>

<t>A similar attack is possible with sessions that use WebRTC identity (see Section
5.6 of <xref target="I-D.ietf-rtcweb-security-arch"/>).  This issue and a mitigation for it
is discussed in more detail in <xref target="webrtc"/>.</t>

</section>
<section anchor="unknown-key-share-attack" title="Unknown Key-Share Attack">

<t>In an unknown key-share attack <xref target="UKS"/>, a malicious participant in a protocol
claims to control a key that is in reality controlled by some other actor.  This
arises when the identity associated with a key is not properly bound to the key.</t>

<t>In DTLS-SRTP, an endpoint is able to acquire the certificate fingerprint another
entity.  By advertising that fingerprint in place of one of its own, the
malicious endpoint can cause its peer to communicate with a different peer, even
though it believes that it is communicating with the malicious endpoint.</t>

<t>When the identity of communicating peers is established by higher-layer
signaling constructs, such as those in SIP <xref target="RFC4474"/> or WebRTC
<xref target="I-D.ietf-rtcweb-security-arch"/>, this allows an attacker to bind their own
identity to a session with any other entity.</t>

<t>By substituting the the fingerprint of one peer for its own, an attacker is able
to cause a session to be established where one endpoint has an incorrect value
for the identity of its peer.  However, the peer does not suffer any such
confusion, resulting in each peer involved in the session having a different
view of the nature of the session.</t>

<t>This attack applies to any communications established based on the
<spanx style="verb">a=fingerprint</spanx> SDP attribute <xref target="RFC4572"/>.</t>

<section anchor="attack-overview" title="Attack Overview">

<t>This vulnerability can be used by an attacker to create a call where
there is confusion about the communicating endpoints.</t>

<t>A SIP endpoint or WebRTC endpoint that is configured to reuse a certificate can
be attacked if it is willing to conduct two concurrent calls, one of which is
with an attacker.  The attacker can arrange for the victim to incorrectly
believe that is calling the attacker when it is in fact calling a second party.
The second party correctly believes that it is talking to the victim.</t>

<t>In a related attack, a single call using WebRTC identity can be attacked so that
it produces the same outcome.  This attack does not require a concurrent call.</t>

</section>
<section anchor="limits-on-attack-feasibility" title="Limits on Attack Feasibility">

<t>The use of TLS with SDP depends on the integrity of session signaling.  Assuming
signaling integrity limits the capabilities of an attacker in several ways.  In
particular:</t>

<t><list style="numbers">
  <t>An attacker can only modify the parts of the session signaling for a session
that they are part of, which is limited to their own offers and answers.</t>
  <t>No entity will complete communications with a peer unless they are willing to
participate in a session with that peer.</t>
</list></t>

<t>The combination of these two constraints make the spectrum of possible attacks
quite limited.  An attacker is only able to switch its own certificate
fingerprint for a valid certificate that is acceptable to its peer.  Attacks
therefore rely on joining two separate sessions into a single session.</t>

<t>The second condition is not necessary with WebRTC identity if the victim has or
is configured with a target peer identity (this is defined in <xref target="WEBRTC"/>).
Furthermore, any identity displayed by a browser could be different to the
identity used by the application, since the attack affects the browser’s
understanding of the peer’s identity.</t>

</section>
<section anchor="example" title="Example">

<t>In this example, two outgoing sessions are created by the same endpoint.  One of
those sessions is initiated with the attacker, another session is created toward
another honest endpoint.  The attacker convinces the endpoint that their session
has completed, and that the session with the other endpoint has succeeded.</t>

<figure><artwork><![CDATA[
  Norma               Mallory             Patsy
  (fp=N)               -----              (fp=P)
    |                    |                  |
    +---Offer1 (fp=N)--->|                  |
    +-----Offer2 (fp=N)-------------------->|
    |<--------------------Answer2 (fp=P)----+
    |<--Answer1 (fp=P)---+                  |
    |                    |                  |
    |======DTLS1====>(Forward)====DTLS1====>|
    |<=====DTLS2=====(Forward)<===DTLS2=====|
    |======Media1===>(Forward)====Media1===>|
    |<=====Media2====(Forward)<===Media2====|
    |                    |                  |
    |======DTLS2===========>(Drop)          |
    |                    |                  |
]]></artwork></figure>

<t>In this case, Norma is willing to conduct two concurrent sessions.  The first
session is established with Mallory, who falsely uses Patsy’s certificate
fingerprint.  A second session is initiated between Norma and Patsy.  Signaling
for both sessions is permitted to complete.</t>

<t>Once complete, the session that is ostensibly between Mallory and Norma is
completed by forwarding packets between Norma and Patsy.  This requires that
Mallory is able to intercept DTLS and media packets from Patsy so that they can
be forwarded to Norma at the transport addresses that Norma associates with the
first session.</t>

<t>The second session - between Norma and Patsy - is permitted to continue to the
point where Patsy believes that it has succeeded.  This ensures that Patsy
believes that she is communicating with Norma.  In the end, Norma believes that
she is communicating with Mallory, when she is actually communicating with
Patsy.</t>

<t>Though Patsy needs to believe that the second session is successful, Mallory has
no real interest in seeing that session complete.  Mallory only needs to ensure
that Patsy does not abandon the session prematurely.  For this reason, it might
be necessary to permit the answer from Patsy to reach Norma to allow Patsy to
receive a call completion signal, such as a SIP ACK.  Once the second session
completes, Mallory causes any DTLS packets sent by Norma to Patsy to be dropped.</t>

<t>For the attacked session to be sustained beyond the point that Norma detects
errors in the second session, Mallory also needs to block any signaling that
Norma might send to Patsy asking for the call to be abandoned.  Otherwise, Patsy
might receive a notice that the call is failed and thereby abort the call.</t>

<t>This attack creates an asymmetry in the beliefs about the identity of peers.
However, this attack is only possible if the victim (Norma) is willing to
conduct two sessions concurrently, and if the same certificate - and therefore
<spanx style="verb">a=fingerprint</spanx> value - is used in both sessions.</t>

</section>
<section anchor="continuity" title="Interactions with Key Continuity">

<t>Systems that use key continuity might be able to detect an unknown key-share
attack if a session with the actual peer (i.e., Patsy in the example) was
established in the past.  Whether this is possible depends on how key continuity
is implemented.</t>

<t>Implementations that maintain a single database of identities with an index on
peer keys could discover that the identity saved for the peer key does not match
the claimed identity.  Such an implementation could notice the disparity between
the actual keys (Patsy) and the expected keys (Mallory).</t>

<t>In comparison, implementations that first match based on peer identity could
treat an unknown key-share attack as though their peer had used a
newly-configured device.  The apparent addition of a new device could generate
user-visible notices (e.g., “Mallory appears to have a new device”).  However,
such an event is not always considered alarming; some implementations might
silently save a new key.</t>

</section>
</section>
<section anchor="sess-id" title="Adding a Session Identifier">

<t>An attack on DTLS-SRTP is possible because the identity of peers involved is not
established prior to establishing the call.  Endpoints use certificate
fingerprints as a proxy for authentication, but as long as fingerprints are used
in multiple calls, they are vulnerable to attacks of the sort described.</t>

<t>The solution to this problem is to assign a new identifier to communicating
peers.  Each endpoint assigns their peer a unique identifier during call
signaling.  The peer echoes that identifier in the TLS handshake, binding that
identity into the session.  Including this new identity in the TLS handshake
means that it will be covered by the TLS Finished message, which is necessary to
authenticate it (see <xref target="SIGMA"/>).  Validating that peers use the correct
identifier then means that the session is established between the correct two
endpoints.</t>

<t>Rather than define a new identifier and means for signaling it, the <spanx style="verb">sess-id</spanx>
field of the o= line in the SDP is used.  This field is already required to be
unique, thus, no two offers or answers from the same client will have the same
value.</t>

<t>The <spanx style="verb">sess-id</spanx> is defined as a decimal sequence <xref target="RFC4566"/>.  <xref target="RFC3264"/>
subsequently limits <spanx style="verb">sess-id</spanx> to a 63-bit value.  Endpoints MUST include a
unique 63-bit value in every session description (offer or answer) they
generate.  Endpoints SHOULD generate this value using a cryptographically-secure
random process <xref target="RFC4086"/>.</t>

<t><list style="hanging">
  <t hangText='Note:'>
  We could define a new attribute for this purpose, but that just makes things
harder to deploy.  This design limits the protocol changes to the TLS
extension and its validation.</t>
</list></t>

<t>A new <spanx style="verb">sdp_session_id</spanx> extension is added to the TLS or DTLS handshake for
connections that are established as part of the same call or real-time session.</t>

<section anchor="sdp_session_id" title="The sdp_session_id TLS Extension">

<t>The <spanx style="verb">sdp_session_id</spanx> TLS extension carries the unique identifier that an
endpoint selects.  The value includes the <spanx style="verb">sess-id</spanx> field from the SDP that the
endpoint generated when negotiating the session.</t>

<t>The <spanx style="verb">extension_data</spanx> for the <spanx style="verb">sdp_session_id</spanx> extension contains a SdpSessionId
struct, described below using the syntax defined in <xref target="RFC5246"/>:</t>

<figure><artwork><![CDATA[
   struct {
      uint64 sess_id;
      uint16 m_line;
   } SdpSessionId;
]]></artwork></figure>

<t>The <spanx style="verb">sess_id</spanx> field of the extension includes the value of the <spanx style="verb">sess-id</spanx> field
from the <spanx style="verb">o=</spanx> line of the SDP offer or answer that the endpoint generates.</t>

<t>The <spanx style="verb">m_line</spanx> field of the extension includes the index of the <spanx style="verb">m=</spanx> section of
the session description that the TLS connection is generated for, starting at
index 0.  Bundled media sections <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> are
identified by the index of the <spanx style="verb">m=</spanx> section associated with the Answerer
BUNDLE-tag.  This prevents an attacker from rearranging <spanx style="verb">m=</spanx> sections within the
same session.</t>

<t>Where RTP and RTCP <xref target="RFC3550"/> are not multiplexed, it is possible that the two
separate DTLS connections carrying RTP and RTCP can be switched.  This is
considered benign since these protocols are often distinguishable.  RTP/RTCP
multiplexing is advised to address this problem.</t>

<t>The <spanx style="verb">sdp_session_id</spanx> extension is included in a ClientHello and either ServerHello
(for TLS and DTLS versions less than 1.3) or EncryptedExtensions (for TLS 1.3).
In TLS 1.3, the extension MUST NOT be included in a ServerHello.</t>

<t>Endpoints MUST check that the <spanx style="verb">sess_id</spanx> parameter in the extension that they
receive includes the <spanx style="verb">sess-id</spanx> value that they received in their peer’s session
description.  Endpoints MUST also check that the <spanx style="verb">m_line</spanx> parameter matches
their expectations.  An endpoint that has receives a <spanx style="verb">sdp_session_id</spanx> extension
that is not identical to the value that it expects MUST abort the connection
with a fatal <spanx style="verb">handshake_failure</spanx> alert.</t>

<t>An endpoint that is communicating with a peer that does not support this
extension will receive a ClientHello, ServerHello or EncryptedExtensions that
does not include this extension.  An endpoint MAY choose to continue a session
without this extension in order to interoperate with peers that do not implement
this specification.</t>

<t>In TLS 1.3, the <spanx style="verb">sdp_session_id</spanx> extension MUST be sent in the
EncryptedExtensions message.</t>

</section>
</section>
<section anchor="webrtc" title="WebRTC Identity Binding">

<t>The identity assertion used for WebRTC <xref target="I-D.ietf-rtcweb-security-arch"/> is
bound only to the certificate fingerprint of an endpoint and can therefore be
copied by an attacker along with the <spanx style="verb">a=fingerprint</spanx> attributes.</t>

<t>The problem is compounded by the fact that an identity provider is not required
to verify that the entity requesting an identity assertion controls the keys.
Nor is it currently able to perform this validation.  Note however that this
verification is not a necessary condition for a secure protocol, as established
in <xref target="SIGMA"/>.</t>

<t>A simple solution to this problem is suggested by <xref target="SIGMA"/>.  The identity of
endpoints is included under a message authentication code (MAC) during the
cryptographic handshake.  Endpoints are then expected to validate that their
peer has provided an identity that matches their expectations.</t>

<t>In TLS, the Finished message provides a MAC over the entire handshake, so that
including the identity in a TLS extension is sufficient to implement this
solution.  Rather than include a complete identity assertion, a hash of the
identity assertion is included in a TLS extension.  Peers then need only
validate that the extension contains a hash of the identity assertion they
received in signaling in addition to validating the identity assertion.</t>

<t>Endpoints MAY use the <spanx style="verb">sdp_session_id</spanx> extension in addition to this so that two
calls between the same parties can’t be altered by an attacker.</t>

<section anchor="webrtc_id_hash" title="The webrtc_id_hash TLS Extension">

<t>The <spanx style="verb">webrtc_id_hash</spanx> TLS extension carries a hash of the identity assertion that
communicating peers have exchanged.</t>

<t>The <spanx style="verb">extension_data</spanx> for the <spanx style="verb">webrtc_id_hash</spanx> extension contains a
WebrtcIdentityHash struct, described below using the syntax defined in
<xref target="RFC5246"/>:</t>

<figure><artwork><![CDATA[
   struct {
      opaque assertion_hash[32];
   } WebrtcIdentityHash;
]]></artwork></figure>

<t>A WebRTC identity assertion is provided as a JSON <xref target="RFC7159"/> object that is
encoded into a JSON text.  The resulting string is then encoded using UTF-8
<xref target="RFC3629"/>.  The content of the <spanx style="verb">webrtc_id_hash</spanx> extension are produced by
hashing the resulting octets with SHA-256 <xref target="FIPS180-2"/>.  This produces the 32
octets of the assertion_hash parameter, which is the sole contents of the
extension.</t>

<t>The <spanx style="verb">a=identity</spanx> attribute includes the base64 <xref target="RFC4648"/> encoding of the same
octets that were input to the hash.  The <spanx style="verb">webrtc_id_hash</spanx> extension is validated
by performing base64 decoding on the value of the <spanx style="verb">a=identity</spanx> attribute,
hashing the resulting octets using SHA-256, and comparing the results with the
content of the extension.</t>

<t>Identity assertions might be provided by only one peer.  An endpoint that does
not produce an identity assertion MUST generate an empty <spanx style="verb">webrtc_id_hash</spanx>
extension in its ClientHello.  This allows its peer to include a hash of its
identity assertion.  An endpoint without an identity assertion MUST omit the
<spanx style="verb">webrtc_id_hash</spanx> extension from its ServerHello or EncryptedExtensions message.</t>

<t>A peer that receives a <spanx style="verb">webrtc_id_hash</spanx> extension that is not equal to the value
of the identity assertion from its peer MUST immediately fail the TLS handshake
with an error.  This includes cases where the <spanx style="verb">a=identity</spanx> attribute is not
present in the SDP.</t>

<t>A peer that receives an identity assertion, but does not receive a
<spanx style="verb">webrtc_id_hash</spanx> extension MAY choose to fail the connection, though it is
expected that implementations that were written prior to the existence of this
document will not support these extensions for some time.</t>

<t>In TLS 1.3, the <spanx style="verb">webrtc_id_hash</spanx> extension MUST be sent in the
EncryptedExtensions message.</t>

</section>
</section>
<section anchor="session-concatenation" title="Session Concatenation">

<t>Use of session identifiers does not prevent an attacker from establishing two
concurrent sessions with different peers and forwarding signaling from those
peers to each other.  Concatenating two signaling sessions creates a situation
where both peers believe that they are talking to the attacker when they are
talking to each other.</t>

<t>Session concatention is possible at higher layers: an attacker can establish two
independent sessions and simply forward any data it receives from one into the
other.  This kind of attack is prevented by systems that enable peer
authentication such as WebRTC identity <xref target="I-D.ietf-rtcweb-security-arch"/> or
SIP identity <xref target="RFC4474"/>.</t>

<t>In the absence of any higher-level concept of peer identity, the use of session
identifiers does not prevent session concatenation.  The value to an attacker is
limited unless information from the TLS connection is extracted and used with
the signaling.  For instance, a key exporter <xref target="RFC5705"/> might be used to
create a shared secret or unique identifier that is used in a secondary
protocol.</t>

<t>If a secondary protocol uses the signaling channel with the assumption that the
signaling and TLS peers are the same then that protocol is vulnerable to attack.
The identity of the peer at the TLS layer is not guranteed to be the same as the
identity of the signaling peer.</t>

<t>It is important to note that multiple connections can be created within the same
signaling session.  An attacker can concatenate only part of a session, choosing
to terminate some connections (and optionally forward data) while arranging to
have peers interact directly for other connections.  It is even possible to have
different peers interact for each connection.  This means that the actual
identity of the peer for one connection might differ from the peer on another
connection.</t>

<t>Information extracted from a TLS connection therefore MUST NOT be used in a
secondary protocol outside of that connection if that protocol relies on the
signaling protocol having the same peers.  Similarly, data from one TLS
connection MUST NOT be used in other TLS connections even if they are
established as a result of the same signaling session.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This entire document contains security considerations.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document registers two extensions in the TLS “ExtensionType Values” registry
established in <xref target="RFC5246"/>:</t>

<t><list style="symbols">
  <t>The <spanx style="verb">sdp_session_id</spanx> extension has been assigned a code point of TBD; it is
recommended and is marked as “Encrypted” in TLS 1.3.</t>
  <t>The <spanx style="verb">webrtc_id_hash</spanx> extension has been assigned a code point of TBD; it is
recommended and is marked as “Encrypted” in TLS 1.3.</t>
</list></t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="FIPS180-2" >
  <front>
    <title>NIST FIPS 180-2, Secure Hash Standard</title>
    <author initials="National Institute of Standards and Technology, U.S." surname="Department of Commerce" fullname="NIST">
      <organization></organization>
    </author>
    <date year="2002" month="August"/>
  </front>
</reference>




<reference  anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor='RFC4566' target='http://www.rfc-editor.org/info/rfc4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>
</reference>



<reference  anchor='RFC4572' target='http://www.rfc-editor.org/info/rfc4572'>
<front>
<title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
<author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP).  It defines a new SDP protocol identifier, 'TCP/TLS'.  It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session.  This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</t><t>This document extends and updates RFC 4145.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4572'/>
<seriesInfo name='DOI' value='10.17487/RFC4572'/>
</reference>



<reference  anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>



<reference  anchor='RFC3711' target='http://www.rfc-editor.org/info/rfc3711'>
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials='M.' surname='Baugher' fullname='M. Baugher'><organization /></author>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='M.' surname='Naslund' fullname='M. Naslund'><organization /></author>
<author initials='E.' surname='Carrara' fullname='E. Carrara'><organization /></author>
<author initials='K.' surname='Norrman' fullname='K. Norrman'><organization /></author>
<date year='2004' month='March' />
<abstract><t>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3711'/>
<seriesInfo name='DOI' value='10.17487/RFC3711'/>
</reference>



<reference  anchor='RFC5763' target='http://www.rfc-editor.org/info/rfc5763'>
<front>
<title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
<author initials='J.' surname='Fischl' fullname='J. Fischl'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5763'/>
<seriesInfo name='DOI' value='10.17487/RFC5763'/>
</reference>



<reference anchor='I-D.ietf-rtcweb-security-arch'>
<front>
<title>WebRTC Security Architecture</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='June' day='8' year='2016' />

<abstract><t>The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC").  This document defines the security architecture for WebRTC.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-12.txt' />
</reference>



<reference  anchor='RFC3264' target='http://www.rfc-editor.org/info/rfc3264'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>
</reference>



<reference  anchor='RFC4086' target='http://www.rfc-editor.org/info/rfc4086'>
<front>
<title>Randomness Requirements for Security</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /></author>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></author>
<date year='2005' month='June' />
<abstract><t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts.  However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities.  The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult.  This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities.  It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>



<reference anchor='I-D.ietf-mmusic-sdp-bundle-negotiation'>
<front>
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>

<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>

<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>

<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
    <organization />
</author>

<date month='October' day='7' year='2016' />

<abstract><t>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'.  The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines).  To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled.  The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected.  There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions.  This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-bundle-negotiation-33' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-33.txt' />
</reference>



<reference  anchor='RFC3629' target='http://www.rfc-editor.org/info/rfc3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
<date year='2003' month='November' />
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract>
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="UKS" >
  <front>
    <title>Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol</title>
    <author initials="S." surname="Blake-Wilson">
      <organization></organization>
    </author>
    <author initials="A." surname="Menezes">
      <organization></organization>
    </author>
    <date year="1999"/>
  </front>
  <seriesInfo name="Lecture Notes in Computer Science 1560, Springer, pp. 154–170" value=""/>
</reference>
<reference anchor="SIGMA" >
  <front>
    <title>SIGMA: The ‘SIGn-and-MAc’approach to authenticated Diffie-Hellman and its use in the IKE protocols</title>
    <author initials="H." surname="Krawczyk">
      <organization></organization>
    </author>
    <date year="2003"/>
  </front>
  <seriesInfo name="Annual International Cryptology Conference, Springer, pp. 400-425" value=""/>
</reference>
<reference anchor="WEBRTC" >
  <front>
    <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
    <author initials="A." surname="Bergkvist">
      <organization></organization>
    </author>
    <author initials="D." surname="Burnett">
      <organization></organization>
    </author>
    <author initials="A." surname="Narayanan">
      <organization></organization>
    </author>
    <author initials="C." surname="Jennings">
      <organization></organization>
    </author>
    <author initials="B." surname="Aboba">
      <organization></organization>
    </author>
    <date year="2016" month="May" day="31"/>
  </front>
  <seriesInfo name="W3C WD-webrtc-30160531" value=""/>
</reference>




<reference  anchor='RFC4474' target='http://www.rfc-editor.org/info/rfc4474'>
<front>
<title>Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<date year='2006' month='August' />
<abstract><t>The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP messages.  It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4474'/>
<seriesInfo name='DOI' value='10.17487/RFC4474'/>
</reference>



<reference  anchor='RFC3550' target='http://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<date year='2003' month='July' />
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>



<reference  anchor='RFC7159' target='http://www.rfc-editor.org/info/rfc7159'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2014' month='March' />
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='RFC' value='7159'/>
<seriesInfo name='DOI' value='10.17487/RFC7159'/>
</reference>



<reference  anchor='RFC4648' target='http://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='October' />
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>



<reference  anchor='RFC5705' target='http://www.rfc-editor.org/info/rfc5705'>
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='March' />
<abstract><t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5705'/>
<seriesInfo name='DOI' value='10.17487/RFC5705'/>
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

<t>This problem would not have been discovered if it weren’t for discussions with
Sam Scott, Hugo Krawczyk, and Richard Barnes.  A solution similar to the one
presented here was first proposed by Karthik Bhargavan who provided valuable
input on this document.  Thyla van der Merwe assisted with a formal model of the
solution.  Adam Roach provided useful input.</t>

</section>


  </back>
</rfc>