draft-ietf-mmusic-sdp-uks-06.txt   draft-ietf-mmusic-sdp-uks-07.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft E. Rescorla Internet-Draft E. Rescorla
Updates: 8122 (if approved) Mozilla Updates: 8122 (if approved) Mozilla
Intended status: Standards Track July 17, 2019 Intended status: Standards Track August 09, 2019
Expires: January 18, 2020 Expires: February 10, 2020
Unknown Key Share Attacks on uses of TLS with the Session Description Unknown Key Share Attacks on uses of TLS with the Session Description
Protocol (SDP) Protocol (SDP)
draft-ietf-mmusic-sdp-uks-06 draft-ietf-mmusic-sdp-uks-07
Abstract Abstract
This document describes unknown key-share attacks on the use of This document describes unknown key-share attacks on the use of
Datagram Transport Layer Security for the Secure Real-Time Transport Datagram Transport Layer Security for the Secure Real-Time Transport
Protocol (DTLS-SRTP). Similar attacks are described on the use of Protocol (DTLS-SRTP). Similar attacks are described on the use of
DTLS-SRTP with the identity bindings used in Web Real-Time DTLS-SRTP with the identity bindings used in Web Real-Time
Communications (WebRTC) and SIP identity. These attacks are Communications (WebRTC) and SIP identity. These attacks are
difficult to mount, but they cause a victim to be mislead about the difficult to mount, but they cause a victim to be mislead about the
identity of a communicating peer. Mitigation techniques are defined identity of a communicating peer. Mitigation techniques are defined
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 18, 2020. This Internet-Draft will expire on February 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3
2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4
2.2. Interactions with Key Continuity . . . . . . . . . . . . 5 2.2. Interactions with Key Continuity . . . . . . . . . . . . 5
2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5 2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5
3. Attack on Identity Bindings . . . . . . . . . . . . . . . . . 6 3. Unknown Key-Share with Identity Bindings . . . . . . . . . . 6
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8
4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 9 3.2.1. Calculating external_id_hash for WebRTC Identity . . 9
3.2.2. Calculating external_id_hash for PASSPoRT . . . . . . 10
4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 10
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12
4.3. The external_session_id TLS Extension . . . . . . . . . . 13 4.3. The external_session_id TLS Extension . . . . . . . . . . 13
5. Consequences of Session Concatenation . . . . . . . . . . . . 14 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The use of Transport Layer Security (TLS) [TLS13] with the Session The use of Transport Layer Security (TLS) [TLS13] with the Session
Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. Description Protocol (SDP) [SDP] is defined in [FINGERPRINT].
Further use with Datagram Transport Layer Security (DTLS) [DTLS] and Further use with Datagram Transport Layer Security (DTLS) [DTLS] and
the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as
DTLS-SRTP [DTLS-SRTP]. DTLS-SRTP [DTLS-SRTP].
In these specifications, key agreement is performed using TLS or In these specifications, key agreement is performed using TLS or
skipping to change at page 4, line 10 skipping to change at page 4, line 13
it is communicating with the attacker. it is communicating with the attacker.
When the identity of communicating peers is established by higher- When the identity of communicating peers is established by higher-
layer signaling constructs, such as those in SIP identity [SIP-ID] or layer signaling constructs, such as those in SIP identity [SIP-ID] or
WebRTC [WEBRTC-SEC], this allows an attacker to bind their own WebRTC [WEBRTC-SEC], this allows an attacker to bind their own
identity to a session with any other entity. identity to a session with any other entity.
The attacker obtains an identity assertion for an identity it The attacker obtains an identity assertion for an identity it
controls, but binds that to the fingerprint of one peer. The controls, but binds that to the fingerprint of one peer. The
attacker is then able to cause a TLS connection to be established attacker is then able to cause a TLS connection to be established
where two endpoints communicate. The victim that has its fingerprint where two victim endpoints communicate. The victim that has its
copied by the attack correctly believes that it is communicating with fingerprint copied by the attack correctly believes that it is
the other victim; however, the other victim incorrectly believes that communicating with the other victim; however, the other victim
it is communicating with the attacker. incorrectly believes that it is communicating with the attacker.
An unknown key-share attack does not result in the attacker having An unknown key-share attack does not result in the attacker having
access to any confidential information exchanged between victims. access to any confidential information exchanged between victims.
However, the failure in mutual authentication can enable other However, the failure in mutual authentication can enable other
attacks. A victim might send information to the wrong entity as a attacks. A victim might send information to the wrong entity as a
result. Where information is interpreted in context, misrepresenting result. Where information is interpreted in context, misrepresenting
that context could lead to the information being misinterpreted. that context could lead to the information being misinterpreted.
A similar attack can be mounted without any communications A similar attack can be mounted based solely on the SDP "fingerprint"
established based on the SDP "fingerprint" attribute [FINGERPRINT]. attribute [FINGERPRINT] without compromising the integrity of the
signaling channel.
This attack is an aspect of SDP-based protocols that the technique This attack is an aspect of SDP-based protocols that the technique
known as third-party call control (3PCC) [RFC3725] relies on. 3PCC known as third-party call control (3PCC) [RFC3725] relies on. 3PCC
exploits the potential for the identity of a signaling peer to be exploits the potential for the identity of a signaling peer to be
different than the media peer, allowing the media peer to be selected different than the media peer, allowing the media peer to be selected
by the signaling peer. Section 2.3 describes the consequences of the by the signaling peer. Section 2.3 describes the consequences of the
mitigations described here for systems that use 3PCC. mitigations described here for systems that use 3PCC.
2.1. Limits on Attack Feasibility 2.1. Limits on Attack Feasibility
The use of TLS with SDP depends on the integrity of session The use of TLS with SDP depends on the integrity of session
signaling. Assuming signaling integrity limits the capabilities of signaling. Assuming signaling integrity limits the capabilities of
an attacker in several ways. In particular: an attacker in several ways. In particular:
1. An attacker can only modify the parts of the session signaling 1. An attacker can only modify the parts of the session signaling
for a session that they are part of, which is limited to their that they are responsible for producing, namely their own offers
own offers and answers. and answers.
2. No entity will successfully establish a session with a peer 2. No entity will successfully establish a session with a peer
unless they are willing to participate in a session with that unless they are willing to participate in a session with that
peer. peer.
The combination of these two constraints make the spectrum of The combination of these two constraints make the spectrum of
possible attacks quite limited. An attacker is only able to switch possible attacks quite limited. An attacker is only able to switch
its own certificate fingerprint for a valid certificate that is its own certificate fingerprint for a valid certificate that is
acceptable to its peer. Attacks therefore rely on joining two acceptable to its peer. Attacks therefore rely on joining two
separate sessions into a single session. separate sessions into a single session. Section 4 describes an
attack on SDP signaling under these constraints.
Systems that rely on strong identity bindings, such as those defined Systems that rely on strong identity bindings, such as those defined
in [WEBRTC] or [SIP-ID], have a different threat model, which admits in [WEBRTC] or [SIP-ID], have a different threat model, which admits
the possibility of attack by an entity with access to the signaling the possibility of attack by an entity with access to the signaling
channel. Attacks under these conditions are more feasible as an channel. Attacks under these conditions are more feasible as an
attacker is assumed to be able to both observe and modify signaling attacker is assumed to be able to both observe and modify signaling
messages. messages. Section 3 describes an attack that assumes this threat
model.
2.2. Interactions with Key Continuity 2.2. Interactions with Key Continuity
Systems that use key continuity (as defined in Section 15.1 of [ZRTP] Systems that use key continuity (as defined in Section 15.1 of [ZRTP]
or as recommended in Section 7 of [FINGERPRINT]) might be able to or as recommended in Section 7 of [FINGERPRINT]) might be able to
detect an unknown key-share attack if a session with either the detect an unknown key-share attack if a session with either the
attacker or the genuine peer (i.e., the victim whose fingerprint was attacker or the genuine peer (i.e., the victim whose fingerprint was
copied by an attacker) was established in the past. Whether this is copied by an attacker) was established in the past. Whether this is
possible depends on how key continuity is implemented. possible depends on how key continuity is implemented.
skipping to change at page 5, line 38 skipping to change at page 5, line 42
identity could treat an unknown key-share attack as though their 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 had used a newly-configured device. The apparent addition of a new
device could generate user-visible notices (e.g., "Mallory appears to device could generate user-visible notices (e.g., "Mallory appears to
have a new device"). However, such an event is not always considered have a new device"). However, such an event is not always considered
alarming; some implementations might silently save a new key. alarming; some implementations might silently save a new key.
2.3. Third-Party Call Control 2.3. Third-Party Call Control
Third-party call control (3PCC) [RFC3725] is a technique where a Third-party call control (3PCC) [RFC3725] is a technique where a
signaling peer establishes a call that is terminated by a different signaling peer establishes a call that is terminated by a different
entity. This attack is very similar to the 3PCC technique, except entity. An unknown key-share attack is very similar in effect to
where the TLS peers are aware of the use of 3PCC. some 3PCC practices, so use of 3PCC could appear to be an attack.
However, 3PCC that follows RFC 3725 guidance is unaffected, and peers
that are aware of changes made by a 3PCC controller can correctly
distinguish actions of a 3PCC controller from attack.
3PCC as described in RFC 3725 is incompatible with SIP identity 3PCC as described in RFC 3725 is incompatible with SIP identity
[SIP-ID] as SIP Identity relies on creating a binding between SIP [SIP-ID] as SIP Identity relies on creating a binding between SIP
requests and SDP. The controller is the only entity that generates requests and SDP. The controller is the only entity that generates
SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use
of the "fingerprint" attribute without additional bindings or WebRTC of the "fingerprint" attribute without additional bindings or WebRTC
identity [WEBRTC-SEC] is possible. identity [WEBRTC-SEC] is possible.
The attack mitigation mechanisms described in this document will
prevent the use of 3PCC if peers have different views of the involved
identities, or the value of SDP "tls-id" attributes.
For 3PCC to work with the proposed mechanisms, TLS peers need to be For 3PCC to work with the proposed mechanisms, TLS peers need to be
aware of the signaling so that they can correctly generate and check aware of the signaling so that they can correctly generate and check
the TLS extensions. For a connection to be successfully established, the TLS extensions. For a connection to be successfully established,
a 3PCC controller needs to either forward SDP without modification, a 3PCC controller needs to either forward SDP without modification,
or to avoid modifications to "fingerprint", "tls-id", and "identity" or to avoid modifications to "fingerprint", "tls-id", and "identity"
attributes. A controller that follows the best practices in RFC 3725 attributes. A controller that follows the best practices in RFC 3725
is expected to forward SDP without modification, thus ensuring the is expected to forward SDP without modification, thus ensuring the
integrity of these attributes. integrity of these attributes.
It is understood that this technique will prevent the use of 3PCC if 3. Unknown Key-Share with Identity Bindings
peers have different views of the involved identities, or the value
of SDP "tls-id" attributes.
3. Attack on Identity Bindings
The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC])
and the SIP PASSPoRT using in SIP identity ([SIP-ID], [PASSPoRT]) are and the SIP PASSPoRT used in SIP identity ([SIP-ID], [PASSPoRT]) are
bound to the certificate fingerprint of an endpoint. An attacker bound to the certificate fingerprint of an endpoint. An attacker can
causes an identity binding to be created that binds an identity they cause an identity binding to be created that binds an identity they
control to the fingerprint of a first victim. control to the fingerprint of a first victim.
An attacker can thereby cause a second victim to believe that they An attacker can thereby cause a second victim to believe that they
are communicating with an attacker-controlled identity, when they are are communicating with an attacker-controlled identity, when they are
really talking to the first victim. The attacker only needs to really talking to the first victim. The attacker does this by
create an identity assertion that covers a certificate fingerprint of creating an identity assertion that covers a certificate fingerprint
the first victim. of the first victim.
A variation on the same technique can be used to cause both victims A variation on the same technique can be used to cause both victims
to both believe they are talking to the attacker when they are to both believe they are talking to the attacker when they are
talking to each other. In this case, the attacker performs the talking to each other. In this case, the attacker performs the
identity misbinding once for each victim. identity misbinding once for each victim.
The problem might appear to be caused by the fact that the authority The problem might appear to be caused by the fact that the authority
that certifies the identity binding is not required to verify that that certifies the identity binding is not required to verify that
the entity requesting the binding controls the keys associated with the entity requesting the binding controls the keys associated with
the fingerprints. Neither SIP nor WebRTC identity providers are not the fingerprints. SIP and WebRTC identity providers are not required
required to perform this validation. However, validation of keys by to perform this validation. However, validation of keys by the
the identity provided is not relevant because verifying control of identity provider is not relevant because verifying control of the
the associated keys is not a necessary condition for a secure associated keys is not a necessary condition for a secure protocol,
protocol, nor would it be sufficient to prevent attack [SIGMA]. nor would it be sufficient to prevent attack [SIGMA].
A simple solution to this problem is suggested by [SIGMA]. The A simple solution to this problem is suggested by [SIGMA]. The
identity of endpoints is included under a message authentication code identity of endpoints is included under a message authentication code
(MAC) during the cryptographic handshake. Endpoints then validate (MAC) during the cryptographic handshake. Endpoints then validate
that their peer has provided an identity that matches their that their peer has provided an identity that matches their
expectations. In TLS, the Finished message provides a MAC over the expectations. In TLS, the Finished message provides a MAC over the
entire handshake, so that including the identity in a TLS extension entire handshake, so that including the identity in a TLS extension
is sufficient to implement this solution. is sufficient to implement this solution.
Rather than include a complete identity binding - which could be Rather than include a complete identity binding - which could be
sizeable - a collision- and pre-image-resistant hash of the binding sizeable - a collision- and pre-image-resistant hash of the binding
is included in a TLS extension as described in Section 3.2. is included in a TLS extension as described in Section 3.2.
Endpoints then need only validate that the extension contains a hash Endpoints then need only validate that the extension contains a hash
of the identity binding they received in signaling. If the identity of the identity binding they received in signaling. If the identity
binding is successfully validated, the identity of a peer is verified binding is successfully validated, the identity of a peer is verified
and bound to the session. and bound to the session.
This form of unknown key-share attack is possible without This form of unknown key-share attack is possible without
compromising signaling integrity, unless the defenses described in compromising signaling integrity, unless the defenses described in
Section 4 are used. Endpoints MUST use the "external_session_id" Section 4 are used. In order to prevent both forms of attack,
extension (see Section 4.3) in addition to the "external_id_hash" endpoints MUST use the "external_session_id" extension (see
(Section 3.2) so that two calls between the same parties can't be Section 4.3) in addition to the "external_id_hash" (Section 3.2) so
altered by an attacker. that two calls between the same parties can't be altered by an
attacker.
3.1. Example 3.1. Example
In the example shown in Figure 1, it is assumed that the attacker In the example shown in Figure 1, it is assumed that the attacker
also controls the signaling channel. also controls the signaling channel.
Mallory (the attacker) presents two victims, Norma and Patsy, with Mallory (the attacker) presents two victims, Norma and Patsy, with
two separate sessions. In the first session, Norma is presented with two separate sessions. In the first session, Norma is presented with
the option to communicate with Mallory; a second session with Norma the option to communicate with Mallory; a second session with Norma
is presented to Patsy. is presented to Patsy.
skipping to change at page 8, line 16 skipping to change at page 8, line 24
As a result, Patsy correctly believes that she is communicating with As a result, Patsy correctly believes that she is communicating with
Norma. However, Norma incorrectly believes she is talking to Norma. However, Norma incorrectly believes she is talking to
Mallory. As stated in Section 2, Mallory cannot access media, but Mallory. As stated in Section 2, Mallory cannot access media, but
Norma might send information to Patsy that is Norma might not intend Norma might send information to Patsy that is Norma might not intend
or that Patsy might misinterpret. or that Patsy might misinterpret.
3.2. The external_id_hash TLS Extension 3.2. The external_id_hash TLS Extension
The "external_id_hash" TLS extension carries a hash of the identity The "external_id_hash" TLS extension carries a hash of the identity
assertion that communicating peers have exchanged. assertion that the endpoint sending the extension has asserted to its
peer. Both peers include a hash of their own identity assertion.
The "extension_data" for the "external_id_hash" extension contains a The "extension_data" for the "external_id_hash" extension contains a
"ExternalIdentityHash" struct, described below using the syntax "ExternalIdentityHash" struct, described below using the syntax
defined in Section 3 of [TLS13]: defined in Section 3 of [TLS13]:
struct { struct {
opaque binding_hash<0..32>; opaque binding_hash<0..32>;
} ExternalIdentityHash; } ExternalIdentityHash;
A WebRTC identity assertion is provided as a JSON [JSON] object that Where an identity assertion has been asserted by a peer, this
is encoded into a JSON text. The resulting string is then encoded extension includes a SHA-256 hash of the assertion. An empty value
using UTF-8 [UTF8]. The content of the "external_id_hash" extension is used to indicate support for the extension.
are produced by hashing the resulting octets with SHA-256 [SHA].
This produces the 32 octets of the "binding_hash" parameter, which is Note: For both types of identity assertion, if SHA-256 should prove
the sole contents of the extension. to be inadequate at some point in the future (see [AGILITY]), a
new TLS extension can be defined that uses a different hash
function.
Identity bindings might be provided by only one peer. An endpoint
that does not produce an identity binding MUST generate an empty
"external_id_hash" extension in its ClientHello or - if a client
provides the extension - in ServerHello or EncryptedExtensions. An
empty extension has a zero-length binding_hash field.
A peer that receives an "external_id_hash" extension that does not
match the value of the identity binding from its peer MUST
immediately fail the TLS handshake with a illegal_parameter alert.
The absence of an identity binding does not relax this requirement;
if a peer provided no identity binding, a zero-length extension MUST
be present to be considered valid.
Implementations written prior to the definition of the extensions in
this document will not support this extension for some time. A peer
that receives an identity binding but does not receive an
"external_id_hash" extension MAY accept a TLS connection rather than
fail a connection where the extension is absent.
Any validation performed of the "external_id_hash" extension is done
in addition to the validation required by [FINGERPRINT] and any
identity assertion definition.
An "external_id_hash" extension that is any length other than 0 or 32
is invalid and MUST cause the receiving endpoint to generate a fatal
"decode_error" alert.
In TLS 1.3, an "external_id_hash" extension sent by a server MUST be
sent in the EncryptedExtensions message.
3.2.1. Calculating external_id_hash for WebRTC Identity
A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided
as a JSON [JSON] object that is encoded into a JSON text. The JSON
text is encoded using UTF-8 [UTF8] as described by Section 8.1 of
[JSON]. The content of the "external_id_hash" extension is produced
by hashing the resulting octets with SHA-256 [SHA]. This produces
the 32 octets of the "binding_hash" parameter, which is the sole
contents of the extension.
The SDP "identity" attribute includes the base64 [BASE64] encoding of The SDP "identity" attribute includes the base64 [BASE64] encoding of
the UTF-8 encoding of the same JSON text. The "external_id_hash" the UTF-8 encoding of the same JSON text. The "external_id_hash"
extension is validated by performing base64 decoding on the value of extension is validated by performing base64 decoding on the value of
the SDP "identity" attribute, hashing the resulting octets using SHA- the SDP "identity" attribute, hashing the resulting octets using SHA-
256, and comparing the results with the content of the extension. In 256, and comparing the results with the content of the extension. In
pseudocode form, using the "identity-assertion-value" field from the pseudocode form, using the "identity-assertion-value" field from the
"identity" attribute grammar as defined in [WEBRTC-SEC]: "identity" attribute grammar as defined in [WEBRTC-SEC]:
"external_id_hash = SHA-256(b64decode(identity-assertion-value)) " "external_id_hash = SHA-256(b64decode(identity-assertion-value)) "
Note: The base64 is decoded to avoid capturing variations in Note: The base64 of the SDP "identity" attribute is decoded to avoid
padding. The base64-decoded identity assertion could include capturing variations in padding. The base64-decoded identity
leading or trailing whitespace octets. WebRTC identity assertions assertion could include leading or trailing whitespace octets.
are not canonicalized; all octets are hashed. WebRTC identity assertions are not canonicalized; all octets are
hashed.
Where a PASSPoRT is used, the compact form of the PASSPoRT MUST be 3.2.2. Calculating external_id_hash for PASSPoRT
Where the compact form of PASSPoRT [PASSPoRT] is used, it MUST be
expanded into the full form. The base64 encoding used in the SIP expanded into the full form. The base64 encoding used in the SIP
Identity (or 'y') header field MUST be decoded then used as input to Identity (or 'y') header field MUST be decoded then used as input to
SHA-256. This produces the 32 octet "binding_hash" value used for SHA-256. This produces the 32 octet "binding_hash" value used for
creating or validating the extension. In pseudocode, using the creating or validating the extension. In pseudocode, using the
"signed-identity-digest" field from the "Identity" grammar defined "signed-identity-digest" field from the "Identity" grammar defined
[SIP-ID]: [SIP-ID]:
"external_id_hash = SHA-256(b64decode(signed-identity-digest)) " "external_id_hash = SHA-256(b64decode(signed-identity-digest)) "
Note: Should SHA-256 prove to be inadequate at some point in the
future (see [AGILITY]), a new TLS extension can be defined that
uses a different hash function.
Identity bindings in either form might be provided by only one peer.
An endpoint that does not produce an identity binding MUST generate
an empty "external_id_hash" extension in its ClientHello. An empty
extension has a zero-length binding_hash field. This allows its peer
to include a hash of its identity binding. An endpoint without an
identity binding MUST include an empty "external_id_hash" extension
in its ServerHello or EncryptedExtensions message, to indicate
support for the extension.
A peer that receives an "external_id_hash" extension that does not
match the value of the identity binding from its peer MUST
immediately fail the TLS handshake with an error. This includes
cases where the binding is absent, in which case the extension MUST
be present and empty.
An "external_id_hash" extension that is any length other than 0 or 32
is invalid and MUST cause the receiving endpoint to generate a fatal
"decode_error" alert.
A peer that receives an identity binding, but does not receive an
"external_id_hash" extension MAY choose to fail the connection,
though it is expected that implementations written prior to the
definition of the extensions in this document will not support both
for some time.
In TLS 1.3, the "external_id_hash" extension MUST be sent in the
EncryptedExtensions message.
4. Unknown Key-Share with Fingerprints 4. Unknown Key-Share with Fingerprints
An attack on DTLS-SRTP is possible because the identity of peers An attack on DTLS-SRTP is possible because the identity of peers
involved is not established prior to establishing the call. involved is not established prior to establishing the call.
Endpoints use certificate fingerprints as a proxy for authentication, Endpoints use certificate fingerprints as a proxy for authentication,
but as long as fingerprints are used in multiple calls, they are but as long as fingerprints are used in multiple calls, they are
vulnerable to attack. vulnerable to attack.
Even if the integrity session signaling can be relied upon, an Even if the integrity of session signaling can be relied upon, an
attacker might still be able to create a session where there is attacker might still be able to create a session where there is
confusion about the communicating endpoints by substituting the confusion about the communicating endpoints by substituting the
fingerprint of a communicating endpoint. fingerprint of a communicating endpoint.
An endpoint that is configured to reuse a certificate can be attacked An endpoint that is configured to reuse a certificate can be attacked
if it is willing to initiate two calls at the same time, one of which if it is willing to initiate two calls at the same time, one of which
is with an attacker. The attacker can arrange for the victim to is with an attacker. The attacker can arrange for the victim to
incorrectly believe that it is calling the attacker when it is in incorrectly believe that it is calling the attacker when it is in
fact calling a second party. The second party correctly believes fact calling a second party. The second party correctly believes
that it is talking to the victim. that it is talking to the victim.
As with the attack on identity bindings, this can be used to cause As with the attack on identity bindings, this can be used to cause
two victims to both believe they are talking to the attacker when two victims to both believe they are talking to the attacker when
they are talking to each other. they are talking to each other.
4.1. Example 4.1. Example
To mount this attack, two sessions need to be created with the same To mount this attack, two sessions need to be created with the same
endpoint at almost precisely the same time. One of those sessions is endpoint at almost precisely the same time. One of those sessions is
initiated with the attacker, the second session is created toward initiated with the attacker, the second session is created toward
another honest endpoint. The attacker convinces the endpoint that another honest endpoint. The attacker convinces the first endpoint
their session has completed, and that the session with the other that their session with the attacker has been successfully
endpoint has succeeded. established, but media is exchanged with the other honest endpoint.
The attacker permits the session with the other honest endpoint to
complete only to the extent necessary to convince the other honest
endpoint to participate in the attacked session.
In addition to the constraints described in Section 2.1, the attacker In addition to the constraints described in Section 2.1, the attacker
in this example also needs the ability to view and drop packets in this example also needs the ability to view and drop packets
between victims. That is, the attacker is on-path. between victims. That is, the attacker is on-path for media.
The attack shown in Figure 2 depends on a somewhat implausible set of The attack shown in Figure 2 depends on a somewhat implausible set of
conditions. It is intended to demonstrate what sort of attack is conditions. It is intended to demonstrate what sort of attack is
possible and what conditions are necessary to exploit this weakness possible and what conditions are necessary to exploit this weakness
in the protocol. in the protocol.
Norma Mallory Patsy Norma Mallory Patsy
(fp=N) ----- (fp=P) (fp=N) ----- (fp=P)
| | | | | |
+---Signaling1 (fp=N)--->| | +---Signaling1 (fp=N)--->| |
skipping to change at page 12, line 13 skipping to change at page 12, line 22
not intend or that Patsy might misinterpret. not intend or that Patsy might misinterpret.
Though Patsy needs to believe that the second signaling session has Though Patsy needs to believe that the second signaling session has
been successfully established, Mallory has no real interest in seeing been successfully established, Mallory has no real interest in seeing
that session also be established. Mallory only needs to ensure that that session also be established. Mallory only needs to ensure that
Patsy maintains the active session and does not abandon the session Patsy maintains the active session and does not abandon the session
prematurely. For this reason, it might be necessary to permit the prematurely. For this reason, it might be necessary to permit the
signaling from Patsy to reach Norma to allow Patsy to receive a call signaling from Patsy to reach Norma to allow Patsy to receive a call
setup completion signal, such as a SIP ACK. Once the second session setup completion signal, such as a SIP ACK. Once the second session
is established, Mallory might cause DTLS packets sent by Norma to is established, Mallory might cause DTLS packets sent by Norma to
Patsy to be dropped. It is likely that these DTLS packets will be Patsy to be dropped. However, if Mallory allows DTLS packets to
discarded by Patsy as Patsy will already have a successful DTLS pass, it is likely that Patsy will discard them as Patsy will already
connection established. have a successful DTLS connection established.
For the attacked session to be sustained beyond the point that Norma For the attacked session to be sustained beyond the point that Norma
detects errors in the second session, Mallory also needs to block any 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 signaling that Norma might send to Patsy asking for the call to be
abandoned. Otherwise, Patsy might receive a notice that the call is abandoned. Otherwise, Patsy might receive a notice that the call is
failed and thereby abort the call. failed and thereby abort the call.
This attack creates an asymmetry in the beliefs about the identity of This attack creates an asymmetry in the beliefs about the identity of
peers. However, this attack is only possible if the victim (Norma) peers. However, this attack is only possible if the victim (Norma)
is willing to conduct two sessions nearly simultaneously, if the is willing to conduct two sessions nearly simultaneously, if the
attacker (Mallory) is on the network path between the victims, and if attacker (Mallory) is on the network path between the victims, and if
the same certificate - and therefore SDP "fingerprint" attribute the same certificate - and therefore SDP "fingerprint" attribute
value - is used in both sessions. value - is used by Norma for both sessions.
Where ICE [ICE] is used, Mallory also needs to ensure that Where ICE [ICE] is used, Mallory also needs to ensure that
connectivity checks between Patsy and Norma succeed, either by connectivity checks between Patsy and Norma succeed, either by
forwarding checks or answering and generating the necessary messages. forwarding checks or answering and generating the necessary messages.
4.2. Unique Session Identity Solution 4.2. Unique Session Identity Solution
The solution to this problem is to assign a new identifier to The solution to this problem is to assign a new identifier to
communicating peers. Each endpoint assigns their peer a unique communicating peers. Each endpoint assigns their peer a unique
identifier during call signaling. The peer echoes that identifier in identifier during call signaling. The peer echoes that identifier in
skipping to change at page 13, line 36 skipping to change at page 13, line 45
} ExternalSessionId; } ExternalSessionId;
For SDP, the "session_id" field of the extension includes the value For SDP, the "session_id" field of the extension includes the value
of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the
"tls-id-value" ABNF production). The value of the "tls-id" attribute "tls-id-value" ABNF production). The value of the "tls-id" attribute
is encoded using ASCII [ASCII]. is encoded using ASCII [ASCII].
Where RTP and RTCP [RTP] are not multiplexed, it is possible that the Where RTP and RTCP [RTP] are not multiplexed, it is possible that the
two separate DTLS connections carrying RTP and RTCP can be switched. two separate DTLS connections carrying RTP and RTCP can be switched.
This is considered benign since these protocols are designed to be This is considered benign since these protocols are designed to be
distinguishable. RTP/RTCP multiplexing is advised to address this distinguishable as SRTP [SRTP] provides key separation. Using RTP/
problem. RTCP multiplexing [RTCP-MUX] further avoids this problem.
The "external_session_id" extension is included in a ClientHello and The "external_session_id" extension is included in a ClientHello and
either ServerHello (for TLS and DTLS versions less than 1.3) or - if the extension is present in the ClientHello - either ServerHello
EncryptedExtensions (for TLS 1.3). In TLS 1.3, the (for TLS and DTLS versions less than 1.3) or EncryptedExtensions (for
"external_session_id" extension MUST NOT be included in a TLS 1.3).
ServerHello.
Endpoints MUST check that the "session_id" parameter in the extension Endpoints MUST check that the "session_id" parameter in the extension
that they receive includes the "tls-id" attribute value that they that they receive includes the "tls-id" attribute value that they
received in their peer's session description. Endpoints can perform received in their peer's session description. Endpoints can perform
string comparison by ASCII decoding the TLS extension value and string comparison by ASCII decoding the TLS extension value and
comparing it to the SDP attribute value, or compare the encoded TLS comparing it to the SDP attribute value, or compare the encoded TLS
extension octets with the encoded SDP attribute value. An endpoint extension octets with the encoded SDP attribute value. An endpoint
that receives a "external_session_id" extension that is not identical that receives a "external_session_id" extension that is not identical
to the value that it expects MUST abort the connection with a fatal to the value that it expects MUST abort the connection with a fatal
"handshake_failure" alert. "illegal_parameter" alert.
Any validation performed of the "external_session_id" extension is
done in addition to the validation required by [FINGERPRINT].
An endpoint that is communicating with a peer that does not support An endpoint that is communicating with a peer that does not support
this extension will receive a ClientHello, ServerHello or this extension will receive a ClientHello, ServerHello or
EncryptedExtensions that does not include this extension. An EncryptedExtensions that does not include this extension. An
endpoint MAY choose to continue a session without this extension in endpoint MAY choose to continue a session without this extension in
order to interoperate with peers that do not implement this order to interoperate with peers that do not implement this
specification. specification.
In TLS 1.3, the "external_session_id" extension MUST be sent in the In TLS 1.3, an "external_session_id" extension sent by a server MUST
EncryptedExtensions message. be sent in the EncryptedExtensions message.
This defense is not effective if an attacker can rewrite "tls-id" This defense is not effective if an attacker can rewrite "tls-id"
values in signaling. Only the mechanism in "external_id_hash" is values in signaling. Only the mechanism in "external_id_hash" is
able to defend against an attacker that can compromise session able to defend against an attacker that can compromise session
integrity. integrity.
5. Consequences of Session Concatenation 5. Session Concatenation
Use of session identifiers does not prevent an attacker from Use of session identifiers does not prevent an attacker from
establishing two concurrent sessions with different peers and establishing two concurrent sessions with different peers and
forwarding signaling from those peers to each other. Concatenating forwarding signaling from those peers to each other. Concatenating
two signaling sessions in this way creates two signaling sessions, two signaling sessions in this way creates two signaling sessions,
with two session identifiers, but only the TLS connections from a with two session identifiers, but only the TLS connections from a
single session are established as a result. In doing so, the single session are established as a result. In doing so, the
attacker creates a situation where both peers believe that they are attacker creates a situation where both peers believe that they are
talking to the attacker when they are talking to each other. talking to the attacker when they are talking to each other.
skipping to change at page 14, line 46 skipping to change at page 15, line 8
session to another. This kind of attack is prevented by systems that session to another. This kind of attack is prevented by systems that
enable peer authentication such as WebRTC identity [WEBRTC-SEC] or enable peer authentication such as WebRTC identity [WEBRTC-SEC] or
SIP identity [SIP-ID]. However, session concatenation remains SIP identity [SIP-ID]. However, session concatenation remains
possible at higher layers: an attacker can establish two independent possible at higher layers: an attacker can establish two independent
sessions and simply forward any data it receives from one into the sessions and simply forward any data it receives from one into the
other. other.
Use of the "external_session_id" does not guarantee that the identity Use of the "external_session_id" does not guarantee that the identity
of the peer at the TLS layer is the same as the identity of the of the peer at the TLS layer is the same as the identity of the
signaling peer. The advantage an attacker gains by concatenating signaling peer. The advantage an attacker gains by concatenating
sessions is limited unless it is assumed that signaling and TLS peers sessions is limited unless data is exchanged on the assumption that
are the same. If a secondary protocol uses the signaling channel signaling and TLS peers are the same. If a secondary protocol uses
with the assumption that the signaling and TLS peers are the same the signaling channel with the assumption that the signaling and TLS
then that protocol is vulnerable to attack unless they also validate peers are the same then that protocol is vulnerable to attack. A
the identity of peers at both layers. signaling system that can defend against session concatenation, while
out of scope for this document, requires that the signaling layer is
authenticated and bound to any TLS connections.
It is important to note that multiple connections can be created It is important to note that multiple connections can be created
within the same signaling session. An attacker might concatenate within the same signaling session. An attacker might concatenate
only part of a session, choosing to terminate some connections (and only part of a session, choosing to terminate some connections (and
optionally forward data) while arranging to have peers interact optionally forward data) while arranging to have peers interact
directly for other connections. It is even possible to have directly for other connections. It is even possible to have
different peers interact for each connection. This means that the different peers interact for each connection. This means that the
actual identity of the peer for one connection might differ from the actual identity of the peer for one connection might differ from the
peer on another connection. peer on another connection.
Information extracted from a TLS connection therefore MUST NOT be Critically, information about the identity of TLS peers provides no
used in a secondary protocol outside of that connection if that assurances about the identity of signaling peers and do not transfer
protocol relies on the signaling protocol having the same peers. between TLS connections in the same session. Information extracted
Similarly, security-sensitive information from one TLS connection from a TLS connection therefore MUST NOT be used in a secondary
MUST NOT be used in other TLS connections even if they are protocol outside of that connection if that protocol assumes that the
established as a result of the same signaling session. signaling protocol has the same peers. Similarly, security-sensitive
information 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.
6. Security Considerations 6. Security Considerations
This entire document contains security considerations. The mitigations in this document, when combined with identity
assertions, ensure that there is no opportunity to misrepresent the
identity of TLS peers. This assurance is provided even if an
attacker can modify signaling messages.
Without identity assertions, the mitigations in this document prevent
the session splicing attack described in Section 4. Defense against
session concatenation (Section 5) additionally requires protocol
peers are not able to claim the certificate fingerprints of other
entities.
7. IANA Considerations 7. IANA Considerations
This document registers two extensions in the TLS "ExtensionType This document registers two extensions in the TLS "ExtensionType
Values" registry established in [TLS13]: Values" registry established in [TLS13]:
o The "external_id_hash" extension defined in Section 3.2 has been o The "external_id_hash" extension defined in Section 3.2 has been
assigned a code point of TBD; it is recommended and is marked as assigned a code point of TBD; it is recommended and is marked as
"CH, EE" in TLS 1.3. "CH, EE" in TLS 1.3.
skipping to change at page 15, line 46 skipping to change at page 16, line 21
as "CH, EE" in TLS 1.3. as "CH, EE" in TLS 1.3.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80, [ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[DTLS-SDP] [DTLS-SDP]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
skipping to change at page 16, line 26 skipping to change at page 17, line 5
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[FINGERPRINT] [FINGERPRINT]
Lennox, J. and C. Holmberg, "Connection-Oriented Media Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[PASSPoRT] [PASSPoRT]
Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 26 skipping to change at page 18, line 7
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[WEBRTC-SEC] [WEBRTC-SEC]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-19 (work in progress), July 2019. rtcweb-security-arch-20 (work in progress), July 2019.
8.2. Informative References 8.2. Informative References
[AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<https://www.rfc-editor.org/info/rfc3725>. <https://www.rfc-editor.org/info/rfc3725>.
[RTCP-MUX]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to
authenticated Diffie-Hellman and its use in the IKE authenticated Diffie-Hellman and its use in the IKE
protocols", Annual International Cryptology Conference, protocols", Annual International Cryptology Conference,
Springer, pp. 400-425 , 2003. Springer, pp. 400-425 , 2003.
 End of changes. 43 change blocks. 
129 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/