< draft-zimmermann-avt-zrtp-09.txt   draft-zimmermann-avt-zrtp-10.txt >
Network Working Group P. Zimmermann Network Working Group P. Zimmermann
Internet-Draft Zfone Project Internet-Draft Zfone Project
Intended status: Informational A. Johnston, Ed. Intended status: Informational A. Johnston, Ed.
Expires: April 1, 2009 Avaya Expires: April 28, 2009 Avaya
J. Callas J. Callas
PGP Corporation PGP Corporation
September 28, 2008 October 25, 2008
ZRTP: Media Path Key Agreement for Secure RTP ZRTP: Media Path Key Agreement for Secure RTP
draft-zimmermann-avt-zrtp-09 draft-zimmermann-avt-zrtp-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2009. This Internet-Draft will expire on April 28, 2009.
Abstract Abstract
This document defines ZRTP, a protocol for media path Diffie-Hellman This document defines ZRTP, a protocol for media path Diffie-Hellman
exchange to agree on a session key and parameters for establishing exchange to agree on a session key and parameters for establishing
Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP
protocol is media path keying because it is multiplexed on the same protocol is media path keying because it is multiplexed on the same
port as RTP and does not require support in the signaling protocol. port as RTP and does not require support in the signaling protocol.
ZRTP does not assume a Public Key Infrastructure (PKI) or require the ZRTP does not assume a Public Key Infrastructure (PKI) or require the
complexity of certificates in end devices. For the media session, complexity of certificates in end devices. For the media session,
ZRTP provides confidentiality, protection against man-in-the-middle ZRTP provides confidentiality, protection against man-in-the-middle
(MITM) attacks, and, in cases where a secret is available from the (MiTM) attacks, and, in cases where the signaling protocol provides
signaling protocol, authentication. ZRTP can utilize a Session end-to-end integrity protection, authentication. ZRTP can utilize a
Description Protocol (SDP) attribute to provide discovery and Session Description Protocol (SDP) attribute to provide discovery and
authentication through the signaling channel. To provide best effort authentication through the signaling channel. To provide best effort
SRTP, ZRTP utilizes normal RTP/AVP profiles. SRTP, ZRTP utilizes normal RTP/AVP profiles.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Media Security Requirements . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 7
4.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 9 3.1.1. Diffie-Hellman Mode Overview . . . . . . . . . . . . . 7
4.1.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 9 3.1.2. Multistream Mode Overview . . . . . . . . . . . . . . 9
4.1.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 11 3.1.3. Preshared Mode Overview . . . . . . . . . . . . . . . 9
4.1.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 12 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Protocol Version Negotiation . . . . . . . . . . . . . 11
5.1.1. Protocol Version Negotiation . . . . . . . . . . . . . 13 4.2. Commit Contention . . . . . . . . . . . . . . . . . . . . 13
5.2. Commit Contention . . . . . . . . . . . . . . . . . . . . 15 4.3. Matching Shared Secret Determination . . . . . . . . . . . 13
5.3. Determination of whether cache has matching shared 4.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 15
secrets . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 16
5.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 17 4.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 16
5.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 18 4.4. DH and non-DH key agreements . . . . . . . . . . . . . . . 18
5.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 19 4.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 18
5.4. DH and non-DH key agreements . . . . . . . . . . . . . . . 20 4.4.1.1. Hash Commitment in Diffie-Hellman Mode . . . . . . 18
5.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 20 4.4.1.2. Responder Behavior in Diffie-Hellman Mode . . . . 19
5.4.1.1. Hash Commitment . . . . . . . . . . . . . . . . . 20 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode . . . . 20
5.4.1.2. Responder Behavior . . . . . . . . . . . . . . . . 21 4.4.1.4. Shared Secret Calculation for DH Mode . . . . . . 20
5.4.1.3. Initiator Behavior . . . . . . . . . . . . . . . . 22 4.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 22
5.4.1.4. Shared Secret Calculation for DH Mode . . . . . . 22 4.4.2.1. Commitment in Multistream Mode . . . . . . . . . . 22
5.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 24 4.4.2.2. Shared Secret Calculation for Multistream Mode . . 23
5.4.2.1. Commitment in Multistream Mode . . . . . . . . . . 24 4.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 24
5.4.2.2. Shared Secret Calculation for Multistream Mode . . 25 4.4.3.1. Commitment in Preshared Mode . . . . . . . . . . . 25
5.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 26 4.4.3.2. Initiator Behavior in Preshared Mode . . . . . . . 25
5.4.3.1. Commitment in Preshared Mode . . . . . . . . . . . 26 4.4.3.3. Responder Behavior in Preshared Mode . . . . . . . 25
5.4.3.2. Initiator Behavior . . . . . . . . . . . . . . . . 26 4.4.3.4. Shared Secret Calculation for Preshared Mode . . . 26
5.4.3.3. Responder Behavior . . . . . . . . . . . . . . . . 27 4.5. Key Generation . . . . . . . . . . . . . . . . . . . . . . 27
5.4.3.4. Shared Secret Calculation for Preshared Mode . . . 28 4.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 28
5.5. Key Generation . . . . . . . . . . . . . . . . . . . . . . 29 4.6.1. Updating the Cache of Shared Secrets . . . . . . . . . 29
5.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 30 4.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 30
5.6.1. Updating the Cache of Shared Secrets . . . . . . . . . 31 4.7.1. Termination via Error message . . . . . . . . . . . . 30
5.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 31 4.7.2. Termination via GoClear message . . . . . . . . . . . 30
5.7.1. Termination via Error message . . . . . . . . . . . . 32 4.7.2.1. Key Destruction for GoClear message . . . . . . . 32
5.7.2. Termination via GoClear message . . . . . . . . . . . 32 4.7.3. Key Destruction at Termination . . . . . . . . . . . . 32
5.7.2.1. Key Destruction for GoClear message . . . . . . . 33 4.8. Random Number Generation . . . . . . . . . . . . . . . . . 33
5.7.3. Key Destruction at Termination . . . . . . . . . . . . 34 4.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 33
5.8. Random Number Generation . . . . . . . . . . . . . . . . . 34 4.9.1. Cacheless implementations . . . . . . . . . . . . . . 34
5.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 34
5.9.1. Self-healing Key Continuity Feature . . . . . . . . . 36 5. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 35
6. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 36
6.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 38 5.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 36
6.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 38 5.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 37
6.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 40 5.1.2.1. Implicit Hash and HMAC algorithm . . . . . . . . . 38
6.1.2.1. Implicit Hash and HMAC algorithm . . . . . . . . . 40 5.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 38
6.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 41 5.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 39
6.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 41 5.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 39
6.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 41 5.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 41
6.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 43 5.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 41
6.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 44 5.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 44 5.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 43
6.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 46 5.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 44
6.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 46 5.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 47
6.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 49 5.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 49
6.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 51 5.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 51
6.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 53 5.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 52
6.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 55 5.9. Error message . . . . . . . . . . . . . . . . . . . . . . 53
6.9. Error message . . . . . . . . . . . . . . . . . . . . . . 56 5.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 54
6.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 57 5.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 55
6.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 58 5.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 55
6.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 58 5.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 56
6.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 59 5.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 58
6.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 61 6. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 59
7. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 62 7. Short Authentication String . . . . . . . . . . . . . . . . . 60
8. Short Authentication String . . . . . . . . . . . . . . . . . 63 7.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 61
8.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 64 7.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 63
8.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 66 7.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 63
8.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 66 7.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 65
8.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 68 8. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 66
9. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 69 8.1. Binding the media stream to the signaling layer via
9.1. Binding the media stream to the signaling layer via the Hello Hash . . . . . . . . . . . . . . . . . . . . . . 67
the Hello Hash . . . . . . . . . . . . . . . . . . . . . . 70 8.1.1. Integrity-protected signaling enables
9.1.1. Integrity-protected signaling enables integrity-protected DH exchange . . . . . . . . . . . 69
integrity-protected DH exchange . . . . . . . . . . . 71 8.2. Deriving the SRTP secret (srtps) from the signaling
9.2. Deriving the SRTP secret (srtps) from the signaling layer . . . . . . . . . . . . . . . . . . . . . . . . . . 70
layer . . . . . . . . . . . . . . . . . . . . . . . . . . 73 8.3. Codec Selection for Secure Media . . . . . . . . . . . . . 71
9.3. Codec Selection for Secure Media . . . . . . . . . . . . . 74 9. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 71
10. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 74 10. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 73
11. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 76 11. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 75
12. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 77 11.1. Guidelines on Proper Implementation of the Disclosure
12.1. Guidelines on Proper Implementation of the Disclosure Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 12. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 77
13. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 14. Appendix - Media Security Requirements . . . . . . . . . . . . 78
15. Security Considerations . . . . . . . . . . . . . . . . . . . 81 15. Security Considerations . . . . . . . . . . . . . . . . . . . 80
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 15.1. Self-healing Key Continuity Feature . . . . . . . . . . . 83
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
17.1. Normative References . . . . . . . . . . . . . . . . . . . 86 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
17.2. Informative References . . . . . . . . . . . . . . . . . . 87 17.1. Normative References . . . . . . . . . . . . . . . . . . . 85
17.2. Informative References . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89
Intellectual Property and Copyright Statements . . . . . . . . . . 91 Intellectual Property and Copyright Statements . . . . . . . . . . 90
1. Introduction 1. Introduction
ZRTP is a key agreement protocol which performs Diffie-Hellman key ZRTP is a key agreement protocol which performs Diffie-Hellman key
exchange during call setup in the media path, and is transported over exchange during call setup in the media path, and is transported over
the same port as the Real-time Transport Protocol (RTP) [RFC3550] the same port as the Real-time Transport Protocol (RTP) [RFC3550]
media stream which has been established using a signaling protocol media stream which has been established using a signaling protocol
such as Session Initiation Protocol (SIP) [RFC3261]. This generates such as Session Initiation Protocol (SIP) [RFC3261]. This generates
a shared secret which is then used to generate keys and salt for a a shared secret which is then used to generate keys and salt for a
Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone
[pgpfone]. A reference implementation of ZRTP is available as Zfone [pgpfone]. A reference implementation of ZRTP is available as Zfone
[zfone]. [zfone].
The ZRTP protocol has some nice cryptographic features lacking in The ZRTP protocol has some nice cryptographic features lacking in
many other approaches to media session encryption. Although it uses many other approaches to media session encryption. Although it uses
a public key algorithm, it does not rely on a public key a public key algorithm, it does not rely on a public key
infrastructure (PKI). In fact, it does not use persistent public infrastructure (PKI). In fact, it does not use persistent public
keys at all. It uses ephemeral Diffie-Hellman (DH) with hash keys at all. It uses ephemeral Diffie-Hellman (DH) with hash
commitment, and allows the detection of man-in-the-middle (MITM) commitment, and allows the detection of man-in-the-middle (MiTM)
attacks by displaying a short authentication string (SAS) for the attacks by displaying a short authentication string (SAS) for the
users to read and verbally compare over the phone. It has Perfect users to read and verbally compare over the phone. It has Perfect
Forward Secrecy, meaning the keys are destroyed at the end of the Forward Secrecy, meaning the keys are destroyed at the end of the
call, which precludes retroactively compromising the call by future call, which precludes retroactively compromising the call by future
disclosures of key material. But even if the users are too lazy to disclosures of key material. But even if the users are too lazy to
bother with short authentication strings, we still get reasonable bother with short authentication strings, we still get reasonable
authentication against a MITM attack, based on a form of key authentication against a MiTM attack, based on a form of key
continuity. It does this by caching some key material to use in the continuity. It does this by caching some key material to use in the
next call, to be mixed in with the next call's DH shared secret, next call, to be mixed in with the next call's DH shared secret,
giving it key continuity properties analogous to SSH. All this is giving it key continuity properties analogous to SSH. All this is
done without reliance on a PKI, key certification, trust models, done without reliance on a PKI, key certification, trust models,
certificate authorities, or key management complexity that bedevils certificate authorities, or key management complexity that bedevils
the email encryption world. It also does not rely on SIP signaling the email encryption world. It also does not rely on SIP signaling
for the key management, and in fact does not rely on any servers at for the key management, and in fact does not rely on any servers at
all. It performs its key agreements and key management in a purely all. It performs its key agreements and key management in a purely
peer-to-peer manner over the RTP packet stream. peer-to-peer manner over the RTP packet stream.
In cases where the short authentication string (SAS) cannot be In cases where the short authentication string (SAS) cannot be
verbally compared by two human users, the SAS can be authenticated by verbally compared by two human users, the SAS can be authenticated by
exchanging an optional signature over the SAS (described in exchanging an optional signature over the SAS (described in
Section 8.2). Section 7.2).
ZRTP can be used and discovered without being declared or indicated ZRTP can be used and discovered without being declared or indicated
in the signaling path. This provides a best effort SRTP capability. in the signaling path. This provides a best effort SRTP capability.
Also, this reduces the complexity of implementations and minimizes Also, this reduces the complexity of implementations and minimizes
interdependency between the signaling and media layers. However, interdependency between the signaling and media layers. However,
when ZRTP is indicated in the signaling via the zrtp-hash SDP when ZRTP is indicated in the signaling via the zrtp-hash SDP
attribute, ZRTP has additional useful properties. By sending a hash attribute, ZRTP has additional useful properties. By sending a hash
of the ZRTP Hello message in the signaling, ZRTP provides a useful of the ZRTP Hello message in the signaling, ZRTP provides a useful
binding between the signaling and media paths, which is explained in binding between the signaling and media paths, which is explained in
Section 9.1. When this is done through a signaling path that has Section 8.1. When this is done through a signaling path that has
end-to-end integrity protection, the DH exchange is automatically end-to-end integrity protection, the DH exchange is automatically
protected from a MiTM attack, which is explained in Section 9.1.1. protected from a MiTM attack, which is explained in Section 8.1.1.
The next section discusses how ZRTP meets every requirement for media
security protocols documented in the IETF. Following sections
provide an overview of the ZRTP protocol, describe the key agreement
algorithm and RTP message formats.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 and and "OPTIONAL" are to be interpreted as described in RFC 2119 and
indicate requirement levels for compliant implementations [RFC2119]. indicate requirement levels for compliant implementations [RFC2119].
3. Media Security Requirements 3. Overview
This section discuses how ZRTP meets all RTP security requirements
discussed in the SIP Working Group's Media Security Requirements
[I-D.ietf-sip-media-security-requirements] document without any
dependencies on other protocols or extensions.
R-FORK-RETARGET is met since ZRTP is a media path key agreement
protocol.
R-DISTINCT is met since ZRTP uses ZIDs and allows multiple
independent ZRTP exchanges to proceed.
R-REUSE is met using the Multistream and Preshared modes.
R-AVOID-CLIPPING is met since ZRTP is a media path key agreement
protocol
R-RTP-VALID is met since the ZRTP packet format does not pass the
RTP validity check
R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and
responses.
R-NEGOTIATE is met using the Commit message.
R-PSTN is met since ZRTP can be implemented in Gateways.
R-PFS is met using ZRTP Diffie-Hellman key agreement methods.
R-COMPUTE is met using the Hello/Commit ZRTP exchange.
R-CERTS is met using the optional signature field in ZRTP Confirm
messages.
R-FIPS is met since ZRTP uses algorithms that allow FIPS
certification.
R-DOS is met since ZRTP does not introduce any new denial of
service attacks.
R-EXISTING is met since ZRTP can support the use of certificates
or keys.
R-AGILITY is met since the set of hash, cipher, authentication tag
length, key agreement method, SAS type, and signature type can all
be extended and negotiated.
R-DOWNGRADE is met since ZRTP has protection against downgrade
attacks.
R-PASS-MEDIA is met since ZRTP prevents a passive adversary with
access to the media path from gaining access to keying material
used to protect SRTP media packets.
R-PASS-SIG is met since ZRTP prevents a passive adversary with
access to the signaling path from gaining access to keying
material used to protect SRTP media packets.
R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs
and responses.
R-ID-BINDING is met using the a=zrtp-hash SDP attribute.
R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs
and responses.
R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and
hence best effort SRTP in every case.
R-OTHER-SIGNALING is met since ZRTP can utilize modes in which
there is no dependency on the signaling path.
R-RECORDING is met using the ZRTP Disclosure flag.
R-TRANSCODER is met if the transcoder operates as a trusted MitM
(i.e. a PBX).
4. Overview
This section provides a description of how ZRTP works. This This section provides a description of how ZRTP works. This
description is non-normative in nature but is included to build description is non-normative in nature but is included to build
understanding of the protocol. understanding of the protocol.
ZRTP is negotiated the same way a conventional RTP session is ZRTP is negotiated the same way a conventional RTP session is
negotiated in an offer/answer exchange using the standard AVP/RTP negotiated in an offer/answer exchange using the standard AVP/RTP
profile. The ZRTP protocol begins after two endpoints have utilized profile. The ZRTP protocol begins after two endpoints have utilized
a signaling protocol such as SIP and are ready to exchange media. If a signaling protocol such as SIP and are ready to exchange media. If
ICE [I-D.ietf-mmusic-ice] is being used, ZRTP begins after ICE has ICE [I-D.ietf-mmusic-ice] is being used, ZRTP begins after ICE has
skipping to change at page 9, line 13 skipping to change at page 7, line 21
retransmissions of all other messages after receipt of a HelloACK. retransmissions of all other messages after receipt of a HelloACK.
If an integrity protected signaling channel is available, a hash of If an integrity protected signaling channel is available, a hash of
the Hello message can be sent. This allows rejection of false the Hello message can be sent. This allows rejection of false
injected ZRTP Hello messages by an attacker. injected ZRTP Hello messages by an attacker.
Hello and other ZRTP messages also contain a hash image that is used Hello and other ZRTP messages also contain a hash image that is used
to link the messages together. This allows rejection of false to link the messages together. This allows rejection of false
injected ZRTP messages during an exchange. injected ZRTP messages during an exchange.
4.1. Key Agreement Modes 3.1. Key Agreement Modes
After both endpoints exchange Hello and HelloACK messages, the key After both endpoints exchange Hello and HelloACK messages, the key
agreement exchange can begin with the ZRTP Commit message. ZRTP agreement exchange can begin with the ZRTP Commit message. ZRTP
supports a number of key agreement modes including both Diffie- supports a number of key agreement modes including both Diffie-
Hellman and non-Diffie-Hellman modes as described in the following Hellman and non-Diffie-Hellman modes as described in the following
sections. sections.
The Commit message may be sent immediately after both endpoints have The Commit message may be sent immediately after both endpoints have
completed the Hello/HelloAck discovery handshake. Or it may be completed the Hello/HelloAck discovery handshake. Or it may be
deferred until later in the call, after the participants engage in deferred until later in the call, after the participants engage in
some unencrypted conversation. The Commit message may be manually some unencrypted conversation. The Commit message may be manually
activated by a user interface element, such as a GO SECURE button, activated by a user interface element, such as a GO SECURE button,
which becomes enabled after the Hello/HelloAck discovery phase. This which becomes enabled after the Hello/HelloAck discovery phase. This
emulates the user experience of a number of secure phones in the PSTN emulates the user experience of a number of secure phones in the PSTN
world [comsec]. However, it is expected that most simple ZRTP user world [comsec]. However, it is expected that most simple ZRTP user
agents will omit such buttons and proceed directly to secure mode by agents will omit such buttons and proceed directly to secure mode by
sending a Commit message immediately after the Hello/HelloAck sending a Commit message immediately after the Hello/HelloAck
handshake. handshake.
In all key agreement modes, the initiator SHOULD NOT send RTP media 3.1.1. Diffie-Hellman Mode Overview
after sending the Commit message, and MUST NOT send SRTP media before
receiving the Conf2Ack. The responder SHOULD NOT send RTP media after
receiving the Commit message, and MUST NOT send SRTP media before
receiving the Confirm2 message.
4.1.1. Diffie-Hellman Mode
An example ZRTP call flow is shown in Figure 1 below. Note that the An example ZRTP call flow is shown in Figure 1 below. Note that the
order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be
reversed. That is, either Alice or Bob might send the first Hello reversed. That is, either Alice or Bob might send the first Hello
message. Note that the endpoint which sends the Commit message is message. Note that the endpoint which sends the Commit message is
considered the initiator of the ZRTP session and drives the key considered the initiator of the ZRTP session and drives the key
agreement exchange. The Diffie-Hellman public values are exchanged agreement exchange. The Diffie-Hellman public values are exchanged
in the DHPart1 and DHPart2 messages. SRTP keys and salts are then in the DHPart1 and DHPart2 messages. SRTP keys and salts are then
calculated. calculated.
skipping to change at page 10, line 46 skipping to change at page 8, line 46
| SRTP begins | | SRTP begins |
|<=================================================>| |<=================================================>|
| | | |
Figure 1: Establishment of an SRTP session using ZRTP Figure 1: Establishment of an SRTP session using ZRTP
ZRTP authentication uses a Short Authentication String (SAS) which is ZRTP authentication uses a Short Authentication String (SAS) which is
ideally displayed for the human user. Alternatively, the SAS can be ideally displayed for the human user. Alternatively, the SAS can be
authenticated by exchanging an OPTIONAL digital signature (sig) over authenticated by exchanging an OPTIONAL digital signature (sig) over
the short authentication string in the Confirm1 or Confirm2 messages the short authentication string in the Confirm1 or Confirm2 messages
(described in Section 8.2). (described in Section 7.2).
The ZRTP Confirm1 and Confirm2 messages are sent for a number of The ZRTP Confirm1 and Confirm2 messages are sent for a number of
reasons, not the least of which is they confirm that all the key reasons, not the least of which is they confirm that all the key
agreement calculations were successful and thus the encryption will agreement calculations were successful and thus the encryption will
work. They also carry other information such as the Disclosure flag work. They also carry other information such as the Disclosure flag
(D), the Allow Clear flag (A), the SAS Verified flag (V), and the PBX (D), the Allow Clear flag (A), the SAS Verified flag (V), and the PBX
Enrollment flag (E). All flags are encrypted to shield them from a Enrollment flag (E). All flags are encrypted to shield them from a
passive observer. passive observer.
4.1.2. Multistream Mode 3.1.2. Multistream Mode Overview
Multistream mode is an alternative key agreement method when two Multistream mode is an alternative key agreement method when two
endpoints have an established SRTP media stream between them and endpoints have an established SRTP media stream between them and
hence an active ZRTP Session key. ZRTP can derive multiple SRTP keys hence an active ZRTP Session key. ZRTP can derive multiple SRTP keys
from a single DH exchange. For example, an established secure voice from a single DH exchange. For example, an established secure voice
call that adds a video stream should (and indeed, MUST) use call that adds a video stream must use Multistream mode to quickly
Multistream mode to quickly initiate the video stream without a initiate the video stream without a second DH exchange.
second DH exchange.
When Multistream mode is indicated in the Commit message, a call flow When Multistream mode is indicated in the Commit message, a call flow
similar to Figure 1 is used, but no DH calculation is performed by similar to Figure 1 is used, but no DH calculation is performed by
either endpoint and the DHPart1 and DHPart2 messages are omitted. either endpoint and the DHPart1 and DHPart2 messages are omitted.
The Confirm1, Confirm2, and Conf2Ack messages are still sent. Since The Confirm1, Confirm2, and Conf2ACK messages are still sent. Since
the cache is not affected during this mode, multiple Multistream ZRTP the cache is not affected during this mode, multiple Multistream ZRTP
exchanges can be performed in parallel between two endpoints. exchanges can be performed in parallel between two endpoints.
When adding additional media streams to an existing call, Multistream When adding additional media streams to an existing call, only
mode MUST be used. Only one DH operation should be performed, just Multistream mode is used. Only one DH operation is performed, just
for the first media stream. The DH exchange must be completed for for the first media stream.
the first media stream before Multistream mode is used to add any
other media streams.
4.1.3. Preshared Mode 3.1.3. Preshared Mode Overview
In the Preshared Mode, endpoints can skip the DH calculation if they In the Preshared Mode, endpoints can skip the DH calculation if they
have a shared secret from a previous ZRTP session. Preshared mode is have a shared secret from a previous ZRTP session. Preshared mode is
indicated in the Commit message and results in the same call flow as indicated in the Commit message and results in the same call flow as
Multistream mode. The principal difference between Multistream mode Multistream mode. The principal difference between Multistream mode
and Preshared mode is that Preshared mode uses a previously cached and Preshared mode is that Preshared mode uses a previously cached
shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess, shared secret, rs1, instead of an active ZRTP Session key as the
as the initial keying material. initial keying material.
This mode could be useful for slow processor endpoints so that a DH This mode could be useful for slow processor endpoints so that a DH
calculation does not need to be performed every session. Or, this calculation does not need to be performed every session. Or, this
mode could be used to rapidly re-establish an earlier session that mode could be used to rapidly re-establish an earlier session that
was recently torn down or interrupted without the need to perform was recently torn down or interrupted without the need to perform
another DH calculation. Since the cache is not affected during this another DH calculation.
mode, multiple Preshared mode exchanges can be processed at a time
between two endpoints.
Preshared mode MUST NOT be used for establishing a second media
stream. Multistream mode is designed for that.
Preshared mode is only included in this specification to meet the
R-REUSE requirement in the Media Security Requirements
[I-D.ietf-sip-media-security-requirements] document. A series of
preshared-keyed calls between two ZRTP endpoints should use a DH key
exchange periodically. Preshared mode SHOULD NOT be used unless a
cached shared secret has been established in an earlier session by a
DH exchange, as discussed in Section 5.9.
Preshared mode has forward secrecy properties. If a phone's cache is Preshared mode has forward secrecy properties. If a phone's cache is
captured by an opponent, the cached shared secrets cannot be used to captured by an opponent, the cached shared secrets cannot be used to
recover earlier encrypted calls, because the shared secrets are recover earlier encrypted calls, because the shared secrets are
replaced with new ones in each new call, as in DH mode. However, the replaced with new ones in each new call, as in DH mode. However, the
captured secrets can be used by a passive wiretapper in the media captured secrets can be used by a passive wiretapper in the media
path to decrypt the next call, if the next call is in Preshared mode. path to decrypt the next call, if the next call is in Preshared mode.
This differs from DH mode, which requires an active MiTM wiretapper This differs from DH mode, which requires an active MiTM wiretapper
to exploit captured secrets in the next call. However, if the next to exploit captured secrets in the next call. However, if the next
call is missed by the wiretapper, he cannot wiretap any further call is missed by the wiretapper, he cannot wiretap any further
calls. It thus preserves most of the self-healing properties calls. It thus preserves most of the self-healing properties
(Section 5.9.1) of key continuity enjoyed by DH mode. (Section 15.1) of key continuity enjoyed by DH mode.
5. Protocol Description 4. Protocol Description
This section begins the normative description of the protocol.
ZRTP MUST be multiplexed on the same ports as the RTP media packets. ZRTP MUST be multiplexed on the same ports as the RTP media packets.
To support best effort encryption from the Media Security To support best effort encryption from the Media Security
Requirements [I-D.ietf-sip-media-security-requirements], ZRTP uses Requirements [I-D.ietf-sip-media-security-requirements], ZRTP uses
normal RTP/AVP profile (AVP) media lines in the initial offer/answer normal RTP/AVP profile (AVP) media lines in the initial offer/answer
exchange. The ZRTP SDP attribute flag a=zrtp-hash defined in exchange. The ZRTP SDP attribute a=zrtp-hash defined in Section 8
Section 9 SHOULD be used in all offers and answers to indicate SHOULD be used in all offers and answers to indicate support for the
support for the ZRTP protocol. The Secure RTP/AVP (SAVP) profile MAY ZRTP protocol. The Secure RTP/AVP (SAVP) profile MAY be used in
be used in subsequent offer/answer exchanges after a successful ZRTP subsequent offer/answer exchanges after a successful ZRTP exchange
exchange has resulted in an SRTP session, or if it is known the other has resulted in an SRTP session, or if it is known the other endpoint
endpoint supports this profile. supports this profile.
The use of the RTP/SAVP profile has caused failures in negotiating The use of the RTP/SAVP profile has caused failures in negotiating
best effort SRTP due to the limitations on negotiating profiles best effort SRTP due to the limitations on negotiating profiles
using SDP. This is why ZRTP supports the RTP/AVP profile and using SDP. This is why ZRTP supports the RTP/AVP profile and
includes its own discovery mechanisms. includes its own discovery mechanisms.
5.1. Discovery In all key agreement modes, the initiator SHOULD NOT send RTP media
after sending the Commit message, and MUST NOT send SRTP media before
receiving either the Conf2ACK or the first SRTP media (with a valid
SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
media after receiving the Commit message, and MUST NOT send SRTP
media before receiving the Confirm2 message.
4.1. Discovery
During the ZRTP discovery phase, a ZRTP endpoint discovers if the During the ZRTP discovery phase, a ZRTP endpoint discovers if the
other endpoint supports ZRTP and the supported algorithms and other endpoint supports ZRTP and the supported algorithms and
options. This information is transported in a Hello message, options. This information is transported in a Hello message,
described in Section 6.2. described in Section 5.2.
ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers
and answers, as defined in Section 9. ZRTP MAY use an RTP [RFC3550] and answers, as defined in Section 8. ZRTP MAY use an RTP [RFC3550]
extension field as a flag to indicate support for the ZRTP protocol extension field as a flag to indicate support for the ZRTP protocol
in RTP packets as described in Section 13. in RTP packets as described in Section 12.
The Hello message includes the ZRTP version, hash type, cipher type, The Hello message includes the ZRTP version, hash type, cipher type,
authentication method and tag length, key agreement type, and Short authentication method and tag length, key agreement type, and Short
Authentication String (SAS) algorithms that are supported. The Hello Authentication String (SAS) algorithms that are supported. The Hello
message also includes a hash image as described in Section 10. In message also includes a hash image as described in Section 9. In
addition, each endpoint sends and discovers ZIDs. The received ZID addition, each endpoint sends and discovers ZIDs. The received ZID
is used later in the protocol as an index into a cache of shared is used later in the protocol as an index into a cache of shared
secrets that were previously negotiated and retained between the two secrets that were previously negotiated and retained between the two
parties. parties.
A Hello message can be sent at any time, but is usually sent at the A Hello message can be sent at any time, but is usually sent at the
start of an RTP session to determine if the other endpoint supports start of an RTP session to determine if the other endpoint supports
ZRTP, and also if the SRTP implementations are compatible. A Hello ZRTP, and also if the SRTP implementations are compatible. A Hello
message is retransmitted using timer T1 and an exponential backoff message is retransmitted using timer T1 and an exponential backoff
mechanism detailed in Section 7 until the receipt of a HelloACK mechanism detailed in Section 6 until the receipt of a HelloACK
message or a Commit message. message or a Commit message.
The use of the a=zrtp-hash SDP attribute to authenticate the Hello The use of the a=zrtp-hash SDP attribute to authenticate the Hello
message is described in Section 9.1. message is described in Section 8.1.
5.1.1. Protocol Version Negotiation 4.1.1. Protocol Version Negotiation
This specification defines ZRTP version 1.00. Since new versions of
ZRTP may be developed in the future, this specification defines a
protocol version negotiation in this section.
Each party declares what version of the ZRTP protocol they support Each party declares what version of the ZRTP protocol they support
via the version field in the Hello message (Section 6.2). If both via the version field in the Hello message (Section 5.2). If both
parties have the same version number in their Hello messages, they parties have the same version number in their Hello messages, they
can proceed with the rest of the protocol. To facilitate both can proceed with the rest of the protocol. To facilitate both
parties reaching this state of protocol version agreement in their parties reaching this state of protocol version agreement in their
Hello messages, ZRTP should use information provided in the signaling Hello messages, ZRTP should use information provided in the signaling
layer, if available. If a ZRTP endpoint supports more than one layer, if available. If a ZRTP endpoint supports more than one
version of the protocol, it SHOULD declare them all in a list of SIP version of the protocol, it SHOULD declare them all in a list of SIP
SDP a=zrtp-hash attributes (defined in Section 9), listing separate SDP a=zrtp-hash attributes (defined in Section 8), listing separate
hashes, with separate ZRTP version numbers in each item in the list. hashes, with separate ZRTP version numbers in each item in the list.
Both parties should inspect the list of ZRTP version numbers supplied Both parties should inspect the list of ZRTP version numbers supplied
by the other party in the SIP SDP a=zrtp-hash attributes. Both by the other party in the SIP SDP a=zrtp-hash attributes. Both
parties should choose the highest version number that appear in both parties should choose the highest version number that appear in both
parties' list of a=zrtp-hash version numbers, and use that version parties' list of a=zrtp-hash version numbers, and use that version
for their Hello messages. If both parties use the SIP signaling in for their Hello messages. If both parties use the SIP signaling in
this manner, their initial Hello messages will have the same ZRTP this manner, their initial Hello messages will have the same ZRTP
version number, provided they both have at least one supported version number, provided they both have at least one supported
protocol version in common. In that case, the protocol version protocol version in common. Before the ZRTP key agreement can
number negotiation is completed. proceed, an endpoint MUST have sent and received Hellos with the same
protocol version.
It is best if the signaling layer is used to negotiate the protocol It is best if the signaling layer is used to negotiate the protocol
version number. However, the a=zrtp-hash SDP attribute is not always version number. However, the a=zrtp-hash SDP attribute is not always
present in the SIP packet, as explained in Section 9.1. In the present in the SIP packet, as explained in Section 8.1. In the
absence of any guidance from the signaling layer, Alice MUST send her absence of any guidance from the signaling layer, an endpoint MUST
highest supported version in her own initial Hello message. If the send the highest supported version in initial Hello messages. If the
two parties send different protocol version numbers in their Hello two parties send different protocol version numbers in their Hello
messages, they can reach agreement to use a common version, if one messages, they can reach agreement to use a common version, if one
exists. They iteratively apply the following rules until they both exists. They iteratively apply the following rules until they both
have the same version in their Hello messages: have matching version fields in their Hello messages and the key
agreement can proceed:
If Alice receives a Hello message from Bob with an unsupported
version number that is greater than Alice's current Hello message,
she ignores the received Hello message and continues to retransmit
Hello messages on the standard retry schedule (Section 7).
If Alice receives a Hello message from Bob with a version number
that is less than Alice's Hello message, and she also supports a
version that is less than or equal to Bob's version number, she
stops sending the old version number and starts sending Hello
messages (on a renewed retry schedule) that have the highest
supported version number that is less than or equal to Bob's
version number.
If Alice receives a Hello message from Bob with a version number
that is less than Alice's Hello message, but she does not also
support a version that is less than or equal to Bob's version
number, she sends an Error message (Section 6.9) to Bob declaring
that she does not support his ZRTP version. Bob stops sending
Hellos upon receiving the Error message. This aborts the
protocol. (Note that all Error messages are retransmitted
(Section 7) until an ErrorACK (Section 6.10) is received).
For example, assume that Alice supports protocol version 1.00 and o If an endpoint receives a Hello message with an unsupported
2.00, and Bob supports version 1.00 and 1.10. Alice initially sends version number that is higher than the endpoint's current Hello
a Hello with version 2.00, and Bob initially sends a Hello with message version, the received Hello message MUST be ignored. The
version 1.10. Bob ignores Alice's 2.00 Hello and continues to send endpoint continues to retransmit Hello messages on the standard
his 1.10 Hello. Alice detects that Bob does not support 2.00 and she retry schedule (Section 6).
starts sending a stream of 1.00 Hellos. Bob sees the 1.00 Hello from o If an endpoint receives a Hello message with a version number that
Alice and stops sending his 1.10 Hellos and switches to sending 1.00 is lower than the endpoint's current Hello message, and the
Hellos. At that point, they have converged on using version 1.00 and endpoint supports a version that is less than or equal to the
the protocol proceeds on that basis. received version number, the endpoint MUST stop retransmitting the
old version number and MUST start sending a new Hello message with
the highest supported version number that is less than or equal to
the received version number.
o If an endpoint receives a Hello message with an unsupported
version number that is lower than the endpoint's current Hello
message, the endpoint MUST send an Error message (Section 5.9)
indicating failure to support this ZRTP version.
Only a simplified subset of the above behavior needs to be The above comparisons are iterated until the version numbers match,
implemented in version 1.00, because no versions lower than version or until it exits on a failure to match.
1.00 will be encountered. A ZRTP version 1.00 endpoint need only
implement the following rules until both parties converge to the same
version in their Hello messages:
If Alice receives a Hello message from Bob with an unsupported For example, assume that Alice supports protocol version 1.00 and
version number that is greater than Alice's current Hello message, 2.00, and Bob supports version 1.00 and 1.10. Alice initially
she ignores the received Hello message and continues to retransmit sends a Hello with version 2.00, and Bob initially sends a Hello
Hello messages on the standard retry schedule (Section 7). with version 1.10. Bob ignores Alice's 2.00 Hello and continues
to send his 1.10 Hello. Alice detects that Bob does not support
2.00 and she stops sending her 2.00 Hellos and starts sending a
stream of 1.00 Hellos. Bob sees the 1.00 Hello from Alice and
stops sending his 1.10 Hellos and switches to sending 1.00 Hellos.
At that point, they have converged on using version 1.00 and the
protocol proceeds on that basis.
If Alice receives an Error message (Section 6.9) from Bob, When comparing protocol versions, a ZRTP endpoint MUST include only
declaring an unsupported protocol version, she stops sending Hello the first three octets of the version field in the comparison. The
messages. This aborts the protocol. final octet is ignored, because it is not significant for
interoperability. For example, "1.0 ", "1.00", "1.01", or "1.0a" are
all regarded as a version match, because they would all be
interoperable versions.
Changes in protocol version numbers are expected be infrequent after Changes in protocol version numbers are expected be infrequent after
version 1.00. Supporting multiple versions adds code complexity and version 1.00. Supporting multiple versions adds code complexity and
may introduce security weaknesses in the implementation. The old may introduce security weaknesses in the implementation. The old
adage about keeping it simple applies especially to implementing adage about keeping it simple applies especially to implementing
security protocols. Implementors SHOULD NOT support protocol security protocols. Endpoints SHOULD NOT support protocol versions
versions earlier than version 1.00 after this specification reaches earlier than version 1.00.
RFC status.
5.2. Commit Contention 4.2. Commit Contention
After both parties have received compatible Hello messages, a Commit After both parties have received compatible Hello messages, a Commit
message (Section 6.4) can be sent to begin the ZRTP key exchange. message (Section 5.4) can be sent to begin the ZRTP key exchange.
The endpoint that sends the Commit is known as the initiator, while The endpoint that sends the Commit is known as the initiator, while
the receiver of the Commit is known as the responder. the receiver of the Commit is known as the responder.
If both sides send Commit messages initiating a secure session at the If both sides send Commit messages initiating a secure session at the
same time the following rules are used to break the tie: same time the following rules are used to break the tie:
If one Commit is for a DH mode while the other is for a non-DH o If one Commit is for a DH mode while the other is for Preshared
mode, then the non-DH Commit is discarded and the DH Commit mode, then the Preshared Commit MUST be discarded and the DH
proceeds. Commit proceeds.
If the two Commits are both Preshared mode, and one party has set o If the two Commits are both Preshared mode, and one party has set
the MiTM (M) flag in the Hello message and the other has not, the the MiTM (M) flag in the Hello message and the other has not, the
Commit message from the party who set the (M) flag is discarded, Commit message from the party who set the (M) flag MUST be
and the one who has not set the (M) flag becomes the initiator, discarded, and the one who has not set the (M) flag becomes the
regardless of the nonce values. In other words, for Preshared initiator, regardless of the nonce values. In other words, for
mode, the phone is the initiator and the PBX is the responder. Preshared mode, the phone is the initiator and the PBX is the
If the two Commits are either both DH modes or both non-DH modes, responder.
o If the two Commits are either both DH modes or both non-DH modes,
then the Commit message with the lowest hvi value (for DH then the Commit message with the lowest hvi value (for DH
Commits), or lowest nonce value (for non-DH Commits), is discarded Commits), or lowest nonce value (for non-DH Commits), MUST be
and the other side is the initiator, and the protocol proceeds discarded and the other side is the initiator, and the protocol
with the initiator's Commit. The two hvi or nonce values are proceeds with the initiator's Commit. The two hvi or nonce values
compared as large unsigned integers in network byte order. are compared as large unsigned integers in network byte order.
If one Commit is for Multistream mode while the other is for non-
Multistream (DH or Preshared) mode, a software error has occurred and
the ZRTP negotiation should be terminated. This should never occur
because of the constraints on Multistream mode described in
Section 4.4.2.
In the event that Commit messages are sent by both ZRTP endpoints at In the event that Commit messages are sent by both ZRTP endpoints at
the same time, but are received in different media streams, the same the same time, but are received in different media streams, the same
resolution rules apply as if they were received on the same stream. resolution rules apply as if they were received on the same stream.
The media stream in which the Commit will proceed through the ZRTP The media stream in which the Commit will proceed through the ZRTP
exchange while the media stream with the discarded Commit must wait exchange while the media stream with the discarded Commit must wait
for the completion of the other ZRTP exchange. for the completion of the other ZRTP exchange.
5.3. Determination of whether cache has matching shared secrets 4.3. Matching Shared Secret Determination
The following sections describe how ZRTP endpoints generate and/or The following sections describe how ZRTP endpoints generate and/or
use the set of shared secrets s1, auxsecret, and pbxsecret through use the set of shared secrets s1, auxsecret, and pbxsecret through
the exchange of the DHPart1 and DHPart2 messages. This doesn't cover the exchange of the DHPart1 and DHPart2 messages. This doesn't cover
the Diffie-Hellman calculations. It only covers the method whereby the Diffie-Hellman calculations. It only covers the method whereby
the two parties determine if they already have shared secrets in the two parties determine if they already have shared secrets in
common in their caches. common in their caches.
Each ZRTP endpoint maintains a long-term cache of shared secrets that Each ZRTP endpoint maintains a long-term cache of shared secrets that
it has previously negotiated with the other party. The ZID of the it has previously negotiated with the other party. The ZID of the
other party, received in the other party's Hello message, is used as other party, received in the other party's Hello message, is used as
an index into this cache to find the set of shared secrets, if any an index into this cache to find the set of shared secrets, if any
exist. This cache entry may contain previously retained shared exist. This cache entry may contain previously retained shared
secrets, rs1 and rs2, which give ZRTP its key continuity features. secrets, rs1 and rs2, which give ZRTP its key continuity features.
If the other party is a PBX, the cache may also contain a trusted If the other party is a PBX, the cache may also contain a trusted
MiTM PBX shared secret, called pbxsecret, defined in Section 8.3.1. MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1.
The DHPart1 and DHPart2 messages contain a list of hashes of these The DHPart1 and DHPart2 messages contain a list of hashes of these
shared secrets to allow the two endpoints to compare the hashes with shared secrets to allow the two endpoints to compare the hashes with
what they have in their caches to detect whether the two sides share what they have in their caches to detect whether the two sides share
any secrets that can be used in the calculation of the session key. any secrets that can be used in the calculation of the session key.
The use of this shared secret cache is described in Section 5.9. The use of this shared secret cache is described in Section 4.9.
If no secret of a given type is available, a random value is If no secret of a given type is available, a random value is
generated and used for that secret to ensure a mismatch in the hash generated and used for that secret to ensure a mismatch in the hash
comparisons in the DHPart1 and DHPart2 messages. This prevents an comparisons in the DHPart1 and DHPart2 messages. This prevents an
eavesdropper from knowing which types of shared secrets are available eavesdropper from knowing which types of shared secrets are available
between the endpoints. between the endpoints.
Section 5.3.1 and Section 5.3.2 both refer to the auxiliary shared Section 4.3.1 and Section 4.3.2 both refer to the auxiliary shared
secret auxsecret. The auxsecret shared secret may be defined by the secret auxsecret. The auxsecret shared secret may be defined by the
VoIP user agent out-of-band from the ZRTP protocol. In some cases it VoIP user agent out-of-band from the ZRTP protocol. In some cases it
may be provided by the signaling layer as srtps, which is defined in may be provided by the signaling layer as srtps, which is defined in
Section 9.2. If it's not provided by the signaling layer, the Section 8.2. If it is not provided by the signaling layer, the
auxsecret shared secret may be manually provisioned in other auxsecret shared secret may be manually provisioned in other
application-specific ways that are out-of-band, such as computed from application-specific ways that are out-of-band, such as computed from
a hashed pass phrase by prior agreement between the two parties. Or a hashed pass phrase by prior agreement between the two parties. Or
it may be a family key used by an institution that the two parties it may be a family key used by an institution that the two parties
both belong to. It is a generalized mechanism for providing a shared both belong to. It is a generalized mechanism for providing a shared
secret that is agreed to between the two parties out of scope of the secret that is agreed to between the two parties out of scope of the
ZRTP protocol. It is expected that most typical ZRTP endpoints will ZRTP protocol. It is expected that most typical ZRTP endpoints will
rarely use auxsecret. rarely use auxsecret.
For both the initiator and the responder, the shared secrets s1, s2, For both the initiator and the responder, the shared secrets s1, s2,
and s3 will be calculated so that they can all be used later to and s3 will be calculated so that they can all be used later to
calculate s0 in Section 5.4.1.4. Here is how s1, s2, and s3 are calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are
calculated by both parties: calculated by both parties:
The shared secret s1 will be either the initiator's rs1 or the The shared secret s1 will be either the initiator's rs1 or the
initiator's rs2, depending on which of them can be found in the initiator's rs2, depending on which of them can be found in the
responder's cache. If the initiator's rs1 matches the responder's responder's cache. If the initiator's rs1 matches the responder's
rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only
if that match fails, then if the initiator's rs2 matches the if that match fails, then if the initiator's rs2 matches the
responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2.
If that match also fails, then s1 MUST be set to null. The If that match also fails, then s1 MUST be set to null. The
complexity of the s1 calculation is to recover from any loss of cache complexity of the s1 calculation is to recover from any loss of cache
skipping to change at page 17, line 28 skipping to change at page 15, line 24
determined by comparing the hashes of auxsecret sent in the DH determined by comparing the hashes of auxsecret sent in the DH
messages. If they don't match, s2 MUST be set to null. messages. If they don't match, s2 MUST be set to null.
The shared secret s3 MUST be set to the value of pbxsecret if and The shared secret s3 MUST be set to the value of pbxsecret if and
only if both parties have matching values for pbxsecret, as only if both parties have matching values for pbxsecret, as
determined by comparing the hashes of pbxsecret sent in the DH determined by comparing the hashes of pbxsecret sent in the DH
messages. If they don't match, s3 MUST be set to null. messages. If they don't match, s3 MUST be set to null.
If s1, s2, or s3 have null values, they are assumed to have a zero If s1, s2, or s3 have null values, they are assumed to have a zero
length for the purposes of hashing them later during the s0 length for the purposes of hashing them later during the s0
calculation. calculation in Section 4.4.1.4.
The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is
described in the next sections. described in the next sections.
5.3.1. Responder Behavior 4.3.1. Responder Behavior
The responder calculates an HMAC keyed hash using the first retained The responder calculates an HMAC keyed hash using the first retained
shared secret, rs1, as the key on the string "Responder" which shared secret, rs1, as the key on the string "Responder" which
generates a retained secret ID, rs1IDr, which is truncated to the generates a retained secret ID, rs1IDr, which is truncated to the
leftmost 64 bits. HMACs are calculated in a similar way for leftmost 64 bits. HMACs are calculated in a similar way for
additional shared secrets: additional shared secrets:
rs1IDr = HMAC(rs1, "Responder") rs1IDr = HMAC(rs1, "Responder")
rs2IDr = HMAC(rs2, "Responder") rs2IDr = HMAC(rs2, "Responder")
auxsecretIDr = HMAC(auxsecret, "Responder") auxsecretIDr = HMAC(auxsecret, "Responder")
pbxsecretIDr = HMAC(pbxsecret, "Responder") pbxsecretIDr = HMAC(pbxsecret, "Responder")
The set of keyed hashes (HMACs) of shared secrets are included by the The set of keyed hashes (HMACs) of shared secrets are included by the
responder in the DHPart1 message. responder in the DHPart1 message.
The HMACs of the possible shared secrets received in the DHPart2 can The HMACs of the possible shared secrets received in the DHPart2 can
be compared against the HMACs of the local set of possible shared be compared against the HMACs of the local set of possible shared
secrets. From these comparisons, s1, s2, and s3 are calculated per secrets. From these comparisons, s1, s2, and s3 are calculated per
the methods described above in Section 5.3. The expected HMAC values the methods described above in Section 4.3. The expected HMAC values
of the shared secrets are calculated (using the string "Initiator" of the shared secrets are calculated (using the string "Initiator"
instead of "Responder") as in Section 5.3.2 and compared to the HMACs instead of "Responder") as in Section 4.3.2 and compared to the HMACs
received in the DHPart2 message. The secrets corresponding to received in the DHPart2 message. The secrets corresponding to
matching HMACs are kept while the secrets corresponding to the non- matching HMACs are kept while the secrets corresponding to the non-
matching ones are replaced with a null, which is assumed to have a matching ones are replaced with a null, which is assumed to have a
zero length for the purposes of hashing them later. The resulting zero length for the purposes of hashing them later. The resulting
s1, s2, and s3 values are used later to calculate s0 in s1, s2, and s3 values are used later to calculate s0 in
Section 5.4.1.4. Section 4.4.1.4.
5.3.2. Initiator Behavior 4.3.2. Initiator Behavior
The initiator calculates an HMAC keyed hash using the first retained The initiator calculates an HMAC keyed hash using the first retained
shared secret, rs1, as the key on the string "Initiator" which shared secret, rs1, as the key on the string "Initiator" which
generates a retained secret ID, rs1IDi, which is truncated to the generates a retained secret ID, rs1IDi, which is truncated to the
leftmost 64 bits. HMACs are calculated in a similar way for leftmost 64 bits. HMACs are calculated in a similar way for
additional shared secrets: additional shared secrets:
rs1IDi = HMAC(rs1, "Initiator") rs1IDi = HMAC(rs1, "Initiator")
rs2IDi = HMAC(rs2, "Initiator") rs2IDi = HMAC(rs2, "Initiator")
auxsecretIDi = HMAC(auxsecret, "Initiator") auxsecretIDi = HMAC(auxsecret, "Initiator")
pbxsecretIDi = HMAC(pbxsecret, "Initiator") pbxsecretIDi = HMAC(pbxsecret, "Initiator")
These HMACs of shared secrets are included by the initiator in the These HMACs of shared secrets are included by the initiator in the
DHPart2 message. DHPart2 message.
The initiator then calculates the set of secret IDs that are expected The initiator then calculates the set of secret IDs that are expected
to be received from the responder in the DHPart1 message by to be received from the responder in the DHPart1 message by
substituting the string "Responder" instead of "Initiator" as in substituting the string "Responder" instead of "Initiator" as in
Section 5.3.1. Section 4.3.1.
The HMACs of the possible shared secrets received are compared The HMACs of the possible shared secrets received are compared
against the HMACs of the local set of possible shared secrets. From against the HMACs of the local set of possible shared secrets. From
these comparisons, s1, s2, and s3 are calculated per the methods these comparisons, s1, s2, and s3 are calculated per the methods
described above in Section 5.3. The secrets corresponding to described above in Section 4.3. The secrets corresponding to
matching HMACs are kept while the secrets corresponding to the non- matching HMACs are kept while the secrets corresponding to the non-
matching ones are replaced with a null, which is assumed to have a matching ones are replaced with a null, which is assumed to have a
zero length for the purposes of hashing them later. The resulting zero length for the purposes of hashing them later. The resulting
s1, s2, and s3 values are used later to calculate s0 in s1, s2, and s3 values are used later to calculate s0 in
Section 5.4.1.4. Section 4.4.1.4.
For example, consider two ZRTP endpoints who share secrets rs1 and For example, consider two ZRTP endpoints who share secrets rs1 and
pbxsecret (defined in Section 8.3.1). During the comparison, rs1ID pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID
and pbxsecretID will match but auxsecretID will not. As a result, s1 and pbxsecretID will match but auxsecretID will not. As a result, s1
= rs1, s2 will be null, and s3 = pbxsecret. = rs1, s2 will be null, and s3 = pbxsecret.
5.3.3. Handling a Shared Secret Cache Mismatch 4.3.3. Handling a Shared Secret Cache Mismatch
A shared secret cache mismatch is defined to mean that we expected a A shared secret cache mismatch is defined to mean that we expected a
cache match because rs1 exists in our local cache, but we computed a cache match because rs1 exists in our local cache, but we computed a
null value for s1 (per the method described in Section 5.3). null value for s1 (per the method described in Section 4.3).
If one party has a cached shared secret and the other party does not, If one party has a cached shared secret and the other party does not,
this indicates one of two possible situations. Either there is a this indicates one of two possible situations. Either there is a
man-in-the-middle (MiTM) attack, or one of the legitimate parties has man-in-the-middle (MiTM) attack, or one of the legitimate parties has
lost their cached shared secret by some mishap. Perhaps they lost their cached shared secret by some mishap. Perhaps they
inadvertently deleted their cache, or their cache was lost or inadvertently deleted their cache, or their cache was lost or
disrupted due to restoring their disk from an earlier backup copy. disrupted due to restoring their disk from an earlier backup copy.
The party that has the surviving cache entry can easily detect that a The party that has the surviving cache entry can easily detect that a
cache mismatch has occurred, because they expect their own cached cache mismatch has occurred, because they expect their own cached
secret to match the other party's cached secret, but it does not secret to match the other party's cached secret, but it does not
skipping to change at page 19, line 35 skipping to change at page 17, line 29
this discovery must treat this as a possible security event and MUST this discovery must treat this as a possible security event and MUST
alert their own user that there is a heightened risk of a MiTM alert their own user that there is a heightened risk of a MiTM
attack, and that the user should verbally compare the SAS with the attack, and that the user should verbally compare the SAS with the
other party to ascertain that no MiTM attack has occurred. If a other party to ascertain that no MiTM attack has occurred. If a
cache mismatch is detected and it is not possible to compare the SAS, cache mismatch is detected and it is not possible to compare the SAS,
either because the user interface does not support it or because one either because the user interface does not support it or because one
or both endpoints are unmanned devices, and no other SAS comparison or both endpoints are unmanned devices, and no other SAS comparison
mechanism is available, the session MAY be terminated. mechanism is available, the session MAY be terminated.
The session need not be terminated on a cache mismatch event if the The session need not be terminated on a cache mismatch event if the
mechanism described in Section 9.1.1 is available, which allows mechanism described in Section 8.1.1 is available, which allows
authentication of the DH exchange without human assistance. Or if authentication of the DH exchange without human assistance. Or if
any mechanism is available to determine if the SAS matches. This any mechanism is available to determine if the SAS matches. This
would require either circumstances that allow human verbal would require either circumstances that allow human verbal
comparisons of the SAS, or by using the OPTIONAL digital signature comparisons of the SAS, or by using the OPTIONAL digital signature
feature on the SAS hash, as described in Section 8.2. Even if the feature on the SAS hash, as described in Section 7.2. Even if the
user interface does not permit an SAS compare, the human user MUST be user interface does not permit an SAS comparison, the human user MUST
warned, and may elect to proceed with the call at their own risk. be warned, and may elect to proceed with the call at their own risk.
Here is a non-normative example of a cache-mismatch alert message Here is a non-normative example of a cache-mismatch alert message
from a ZRTP user agent (specifically, Zfone [zfone]), designed for a from a ZRTP user agent (specifically, Zfone [zfone]), designed for a
desktop PC graphical user interface environment. It is by no means desktop PC graphical user interface environment. It is by no means
required that the alert be this detailed: required that the alert be this detailed:
"We expected the other party to have a shared secret cached from a "We expected the other party to have a shared secret cached from a
previous call, but they don't have it. This may mean your partner previous call, but they don't have it. This may mean your partner
simply lost his cache of shared secrets, but it could also mean simply lost his cache of shared secrets, but it could also mean
someone is trying to wiretap you. To resolve this question you someone is trying to wiretap you. To resolve this question you
must check the authentication string with your partner. If it must check the authentication string with your partner. If it
doesn't match, it indicates the presence of a wiretapper." doesn't match, it indicates the presence of a wiretapper."
If the alert is rendered by a robot voice instead of a GUI, If the alert is rendered by a robot voice instead of a GUI,
brevity may be more important: "Something's wrong. You must check brevity may be more important: "Something's wrong. You must check
the authentication string with your partner. If it doesn't match, the authentication string with your partner. If it doesn't match,
it indicates the presence of a wiretapper." it indicates the presence of a wiretapper."
5.4. DH and non-DH key agreements 4.4. DH and non-DH key agreements
The next step is the generation of a secret for deriving SRTP keying The next step is the generation of a secret for deriving SRTP keying
material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes,
described in the following sections. described in the following sections.
5.4.1. Diffie-Hellman Mode 4.4.1. Diffie-Hellman Mode
The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman
or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP
endpoints to generate a new shared secret, s0. In addition, the endpoints to generate a new shared secret, s0. In addition, the
endpoints discover if they have any cached or previously stored endpoints discover if they have any cached or previously stored
shared secrets in common, and uses them as part of the calculation of shared secrets in common, and uses them as part of the calculation of
the session keys. the session keys.
Because the DH exchange affects the state of the retained shared Because the DH exchange affects the state of the retained shared
secret cache, only one in-process ZRTP DH exchange may occur at a secret cache, only one in-process ZRTP DH exchange may occur at a
time between two ZRTP endpoints. Otherwise, race conditions and time between two ZRTP endpoints. Otherwise, race conditions and
cache integrity problems will result. When multiple media streams cache integrity problems will result. When multiple media streams
are established in parallel between the same pair of ZRTP endpoints are established in parallel between the same pair of ZRTP endpoints
(determined by the ZIDs in the Hello Messages), only one can be (determined by the ZIDs in the Hello Messages), only one can be
processed. Once that exchange completes with Confirm2 and Conf2ACK processed. Once that exchange completes with Confirm2 and Conf2ACK
messages, another ZRTP DH exchange can begin. This constraint does messages, another ZRTP DH exchange can begin. This constraint does
not apply when Multistream mode key agreement is used since the not apply when Multistream mode key agreement is used since the
cached shared secrets are not affected. cached shared secrets are not affected.
5.4.1.1. Hash Commitment 4.4.1.1. Hash Commitment in Diffie-Hellman Mode
From the intersection of the algorithms in the sent and received From the intersection of the algorithms in the sent and received
Hello messages, the initiator chooses a hash, cipher, auth tag, key Hello messages, the initiator chooses a hash, cipher, auth tag, key
agreement type, and SAS type to be used. agreement type, and SAS type to be used.
A Diffie-Hellman mode is selected by setting the Key Agreement Type A Diffie-Hellman mode is selected by setting the Key Agreement Type
to one of the DH or ECDH values in Table 5 in the Commit. In this to one of the DH or ECDH values in Table 5 in the Commit. In this
mode, the key agreement begins with the initiator choosing a fresh mode, the key agreement begins with the initiator choosing a fresh
random Diffie-Hellman (DH) secret value (svi) based on the chosen key random Diffie-Hellman (DH) secret value (svi) based on the chosen key
agreement type value, and computing the public value. (Note that to agreement type value, and computing the public value. (Note that to
speed up processing, this computation can be done in advance.) For speed up processing, this computation can be done in advance.) For
guidance on generating random numbers, see Section 5.8. The value guidance on generating random numbers, see Section 4.8. The value
for the DH generator g, the DH prime p, and the length of the DH for the DH generator g, the DH prime p, and the length of the DH
secret value, svi, are defined in Section 6.1.5. secret value, svi, are defined in Section 5.1.5.
pvi = g^svi mod p pvi = g^svi mod p
where g and p are determined by the key agreement type value. The where g and p are determined by the key agreement type value. The
pvi value is formatted as a big-endian octet string, fixed to the pvi value is formatted as a big-endian octet string, fixed to the
width of the DH prime, and leading zeros MUST NOT be truncated. width of the DH prime, and leading zeros MUST NOT be truncated.
The hash commitment is performed by the initiator of the ZRTP The hash commitment is performed by the initiator of the ZRTP
exchange. The hash value of the initiator, hvi, includes a hash of exchange. The hash value of the initiator, hvi, includes a hash of
the entire DHPart2 message as shown in Figure 9 (which includes the the entire DHPart2 message as shown in Figure 9 (which includes the
skipping to change at page 21, line 29 skipping to change at page 19, line 23
Note that the Hello message includes the fields shown in Figure 3. Note that the Hello message includes the fields shown in Figure 3.
The information from the responder's Hello message is included in the The information from the responder's Hello message is included in the
hash calculation to prevent a bid-down attack by modification of the hash calculation to prevent a bid-down attack by modification of the
responder's Hello message. responder's Hello message.
The initiator sends hvi in the Commit message. The initiator sends hvi in the Commit message.
The use of hash commitment in the DH exchange constrains the attacker The use of hash commitment in the DH exchange constrains the attacker
to only one guess to generate the correct short authentication string to only one guess to generate the correct short authentication string
(SAS) (Section 8) in his attack, which means the SAS can be quite (SAS) (Section 7) in his attack, which means the SAS can be quite
short. A 16-bit SAS, for example, provides the attacker only one short. A 16-bit SAS, for example, provides the attacker only one
chance out of 65536 of not being detected. chance out of 65536 of not being detected.
5.4.1.2. Responder Behavior 4.4.1.2. Responder Behavior in Diffie-Hellman Mode
Upon receipt of the Commit message, the responder generates its own Upon receipt of the Commit message, the responder generates its own
fresh random DH secret value, svr, and computes the public value. fresh random DH secret value, svr, and computes the public value.
(Note that to speed up processing, this computation can be done in (Note that to speed up processing, this computation can be done in
advance.) For guidance on random number generation, see Section 5.8. advance.) For guidance on random number generation, see Section 4.8.
The value for the DH generator g, the DH prime p, and the length of The value for the DH generator g, the DH prime p, and the length of
the DH secret value, svr, are defined in Section 6.1.5. the DH secret value, svr, are defined in Section 5.1.5.
pvr = g^svr mod p pvr = g^svr mod p
The pvr value is formatted as a big-endian octet string, fixed to the The pvr value is formatted as a big-endian octet string, fixed to the
width of the DH prime, and leading zeros MUST NOT be truncated. width of the DH prime, and leading zeros MUST NOT be truncated.
Upon receipt of the DHPart2 message, the responder checks that the Upon receipt of the DHPart2 message, the responder checks that the
initiator's public DH value is not equal to 1 or p-1. An attacker initiator's public DH value is not equal to 1 or p-1. An attacker
might inject a false DHPart2 packet with a value of 1 or p-1 for might inject a false DHPart2 packet with a value of 1 or p-1 for
g^svi mod p, which would cause a disastrously weak final DH result to g^svi mod p, which would cause a disastrously weak final DH result to
be computed. If pvi is 1 or p-1, the user should be alerted of the be computed. If pvi is 1 or p-1, the user should be alerted of the
attack and the protocol exchange MUST be terminated. Otherwise, the attack and the protocol exchange MUST be terminated. Otherwise, the
responder computes its own value for the hash commitment using the responder computes its own value for the hash commitment using the
public DH value (pvi) received in the DHPart2 packet and its Hello public DH value (pvi) received in the DHPart2 packet and its Hello
packet and compares the result with the hvi received in the Commit packet and compares the result with the hvi received in the Commit
packet. If they are different, a MITM attack is taking place and the packet. If they are different, a MiTM attack is taking place and the
user is alerted and the protocol exchange terminated. user is alerted and the protocol exchange terminated.
The responder then calculates the Diffie-Hellman result: The responder then calculates the Diffie-Hellman result:
DHResult = pvi^svr mod p DHResult = pvi^svr mod p
5.4.1.3. Initiator Behavior 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode
Upon receipt of the DHPart1 message, the initiator checks that the Upon receipt of the DHPart1 message, the initiator checks that the
responder's public DH value is not equal to 1 or p-1. An attacker responder's public DH value is not equal to 1 or p-1. An attacker
might inject a false DHPart1 packet with a value of 1 or p-1 for might inject a false DHPart1 packet with a value of 1 or p-1 for
g^svr mod p, which would cause a disastrously weak final DH result to g^svr mod p, which would cause a disastrously weak final DH result to
be computed. If pvr is 1 or p-1, the user should be alerted of the be computed. If pvr is 1 or p-1, the user should be alerted of the
attack and the protocol exchange MUST be terminated. attack and the protocol exchange MUST be terminated.
The initiator then sends a DHPart2 message containing the initiator's The initiator then sends a DHPart2 message containing the initiator's
public DH value and the set of calculated shared secret IDs as public DH value and the set of calculated shared secret IDs as
defined in Section 5.3.2. defined in Section 4.3.2.
The initiator calculates the same Diffie-Hellman result using: The initiator calculates the same Diffie-Hellman result using:
DHResult = pvr^svi mod p DHResult = pvr^svi mod p
5.4.1.4. Shared Secret Calculation for DH Mode 4.4.1.4. Shared Secret Calculation for DH Mode
A hash of the received and sent ZRTP messages in the current ZRTP A hash of the received and sent ZRTP messages in the current ZRTP
exchange in the following order is calculated by both parties: exchange in the following order is calculated by both parties:
total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2) total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2)
Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and
Figure 9), not the entire ZRTP packets, are included in the Figure 9), not the entire ZRTP packets, are included in the
total_hash. total_hash.
skipping to change at page 23, line 5 skipping to change at page 20, line 48
big-endian octet string, fixed to the width of the DH prime, and big-endian octet string, fixed to the width of the DH prime, and
leading zeros MUST NOT be truncated. For example, for a 3072-bit p, leading zeros MUST NOT be truncated. For example, for a 3072-bit p,
DHResult would be a 384 octet value, with the first octet the most DHResult would be a 384 octet value, with the first octet the most
significant. significant.
The calculation of the final shared secret, s0, is in compliance with The calculation of the final shared secret, s0, is in compliance with
the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A
[SP800-56A]. This is done by hashing a concatenation of a number of [SP800-56A]. This is done by hashing a concatenation of a number of
items, including the DHResult, the ZID's of the initiator (ZIDi) and items, including the DHResult, the ZID's of the initiator (ZIDi) and
the responder (ZIDr), the total_hash, and the set of non-null shared the responder (ZIDr), the total_hash, and the set of non-null shared
secrets as described in Section 5.3. secrets as described in Section 4.3.
In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires
certain parameters to be hashed together in a particular order, which certain parameters to be hashed together in a particular order, which
NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo,
SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult
corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our
ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash
corresponds to SuppPubInfo, and the set of three shared secrets s1, corresponds to SuppPubInfo, and the set of three shared secrets s1,
s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit
big-endian integer counter to be included in the hash each time the big-endian integer counter to be included in the hash each time the
hash is computed, which we have set to the fixed value of 1, because hash is computed, which we have set to the fixed value of 1, because
we only compute the hash once. we only compute the hash once.
s0 = hash( counter | DHResult | "ZRTP-HMAC-KDF" | ZIDi | ZIDr | s0 = hash( counter | DHResult | "ZRTP-HMAC-KDF" | ZIDi | ZIDr |
total_hash | len(s1) | s1 | len(s2) | s2 | len(s3) | s3 ) total_hash | len(s1) | s1 | len(s2) | s2 | len(s3) | s3 )
Note that temporary values s1, s2, and s3 were calculated per the Note that temporary values s1, s2, and s3 were calculated per the
methods described above in Section 5.3, and they are erased from methods described above in Section 4.3, and they are erased from
memory immediately after they are used to calculate s0. memory immediately after they are used to calculate s0.
The length of the DHResult field was implicitly agreed to by the The length of the DHResult field was implicitly agreed to by the
negotiated DH prime size. The length of total_hash is implicitly negotiated DH prime size. The length of total_hash is implicitly
determined by the negotiated hash algorithm. All of the explicit determined by the negotiated hash algorithm. All of the explicit
length fields, len(), in the above hash are 32-bit big-endian length fields, len(), in the above hash are 32-bit big-endian
integers, giving the length in octets of the field that follows. integers, giving the length in octets of the field that follows.
Some members of the set of shared secrets (s1, s2, and s3) may have Some members of the set of shared secrets (s1, s2, and s3) may have
lengths of zero if they are null (not shared), and are each preceded lengths of zero if they are null (not shared), and are each preceded
by a 4-octet length field. For example, if s2 is null, len(s2) is by a 4-octet length field. For example, if s2 is null, len(s2) is
0x00000000, and s2 itself would be absent from the hash calculation, 0x00000000, and s2 itself would be absent from the hash calculation,
which means len(s3) would immediately follow len(s2). While which means len(s3) would immediately follow len(s2). While
inclusion of ZIDi and ZIDr may be redundant, because they are inclusion of ZIDi and ZIDr may be redundant, because they are
implicitly included in the total_hash, we explicitly include them implicitly included in the total_hash, we explicitly include them
here to follow NIST SP800-56A. The string "ZRTP-HMAC-KDF" (not null- here to follow NIST SP800-56A. The string "ZRTP-HMAC-KDF" (not null-
terminated) identifies what purpose the resulting s0 will be used terminated) identifies what purpose the resulting s0 will be used
for, which is to serve as the master key for the ZRTP HMAC-based key for, which is to serve as the master key for the ZRTP HMAC-based key
derivation function defined in Section 5.5. derivation function defined in Section 4.5.
A ZRTP Session Key is generated which then allows the ZRTP A ZRTP Session Key is generated which then allows the ZRTP
Multistream mode to be used to generate SRTP key and salt pairs for Multistream mode to be used to generate SRTP key and salt pairs for
additional concurrent media streams between this pair of ZRTP additional concurrent media streams between this pair of ZRTP
endpoints. If a ZRTP Session Key has already been generated between endpoints. If a ZRTP Session Key has already been generated between
this pair of endpoints and is available, no new ZRTP Session Key is this pair of endpoints and is available, no new ZRTP Session Key is
calculated. calculated.
ZRTPSess = HMAC(s0,"ZRTP Session Key") ZRTPSess = HMAC(s0,"ZRTP Session Key")
The ZRTPSess key is kept for the duration of the call signaling The ZRTPSess key is kept for the duration of the call signaling
session between the two ZRTP endpoints. That is, if there are two session between the two ZRTP endpoints. That is, if there are two
separate calls between the endpoints (in SIP terms, separate SIP separate calls between the endpoints (in SIP terms, separate SIP
dialogs), then a ZRTP Session Key MUST NOT be used across the two dialogs), then a ZRTP Session Key MUST NOT be used across the two
call signaling sessions. ZRTPSess MUST be destroyed no later than call signaling sessions. ZRTPSess MUST be destroyed no later than
the end of the call signaling session. the end of the call signaling session.
The two endpoints proceed with key generation as described in The two endpoints proceed with key generation as described in
Section 5.5, now that there is a defined s0 and ZRTPSess key. Section 4.5, now that there is a defined s0 and ZRTPSess key.
5.4.2. Multistream Mode 4.4.2. Multistream Mode
The Multistream key agreement mode can be used to generate SRTP keys The Multistream key agreement mode can be used to generate SRTP keys
and salts for additional media streams established between a pair of and salts for additional media streams established between a pair of
endpoints. Multistream mode cannot be used unless there is an active endpoints. Multistream mode cannot be used unless there is an active
SRTP session established between the endpoints which means a ZRTP SRTP session established between the endpoints which means a ZRTP
Session key is active. This ZRTP Session key can be used to generate Session key is active. This ZRTP Session key can be used to generate
keys and salts without performing another DH calculation. In this keys and salts without performing another DH calculation. In this
mode, the retained shared secret cache is not used or updated. As a mode, the retained shared secret cache is not used or updated. As a
result, multiple ZRTP Multistream mode exchanges can be processed in result, multiple ZRTP Multistream mode exchanges can be processed in
parallel between two endpoints. parallel between two endpoints.
5.4.2.1. Commitment in Multistream Mode Multistream mode is also used to resume a secure call that has gone
clear using a GoClear message as described in Section 4.7.2.1.
When adding additional media streams to an existing call, Multistream
mode MUST be used. The first media stream MUST use either DH mode or
Preshared mode. Only one DH exchange or Preshared exchange is
performed, just for the first media stream. The DH exchange or
Preshared exchange MUST be completed for the first media stream
before Multistream mode is used to add any other media streams.
4.4.2.1. Commitment in Multistream Mode
Multistream mode is selected by the initiator setting the Key Multistream mode is selected by the initiator setting the Key
Agreement Type to "Mult" in the Commit message (Figure 6). The Agreement Type to "Mult" in the Commit message (Figure 6). The
Cipher Type and Auth Tag Length in Multistream mode MUST be set by Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be
the initiator to the same as the values as in the initial DH Mode set by the initiator to the same as the values as in the initial DH
Commit. These values in the Multistream commit packet SHOULD be Mode Commit. The SAS Type is ignored as there is no SAS
ignored by the responder, and SHOULD be assumed to be the same as the authentication in this mode.
values in the previous DH commit message. The SAS Type is ignored as
there is no SAS authentication in this mode. Note: This requirement is needed since some endpoints cannot
support different SRTP algorithms for different media streams.
However, in the case of Multstream mode being used to go secure
after a GoClear, the requirement to use the same SRTP algorithms
is relaxed if there are no other active SRTP sessions.
In place of hvi in the Commit, a random nonce of length 4-words (16 In place of hvi in the Commit, a random nonce of length 4-words (16
octets) is chosen. Its value MUST be unique for all nonce values octets) is chosen. Its value MUST be unique for all nonce values
chosen for active ZRTP sessions between a pair of endpoints. If a chosen for active ZRTP sessions between a pair of endpoints. If a
Commit is received with a reused nonce value, the ZRTP exchange MUST Commit is received with a reused nonce value, the ZRTP exchange MUST
be immediately terminated. be immediately terminated.
Note: Since the nonce is used to calculate different SRTP key and Note: Since the nonce is used to calculate different SRTP key and
salt pairs for each media stream, a duplication will result in the salt pairs for each media stream, a duplication will result in the
same key and salt being generated for the two media streams, which same key and salt being generated for the two media streams, which
would have disastrous security consequences. would have disastrous security consequences.
If a Commit is received selecting Multistream mode, but the responder If a Commit is received selecting Multistream mode, but the responder
does not have a ZRTP Session Key available, the exchange MUST be does not have a ZRTP Session Key available, the exchange MUST be
terminated. Otherwise, the responder proceeds to the next section on terminated. Otherwise, the responder proceeds to the next section on
Shared Secret Calculation, Section 5.4.2.2. Shared Secret Calculation, Section 4.4.2.2.
If both sides send Multistream Commit messages at the same time, the If both sides send Multistream Commit messages at the same time, the
contention is resolved and the initiator/responder roles are settled contention is resolved and the initiator/responder roles are settled
according to Section 5.2, and the protocol proceeds. according to Section 4.2, and the protocol proceeds.
In Multistream mode, both the DHPart1 and DHPart2 messages are In Multistream mode, both the DHPart1 and DHPart2 messages are
skipped. After receiving the Commit message from the initiator, the skipped. After receiving the Commit message from the initiator, the
responder sends the Confirm1 message after calculating this stream's responder sends the Confirm1 message after calculating this stream's
SRTP keys, as described below. SRTP keys, as described below.
5.4.2.2. Shared Secret Calculation for Multistream Mode 4.4.2.2. Shared Secret Calculation for Multistream Mode
A hash of the received and sent ZRTP messages in the current ZRTP A hash of the received and sent ZRTP messages in the current ZRTP
exchange for the current media stream is calculated: exchange for the current media stream is calculated:
total_hash = hash(Hello of responder | Commit ) total_hash = hash(Hello of responder | Commit )
This refers to the Hello and Commit messages for the current media This refers to the Hello and Commit messages for the current media
stream which is using Multistream mode, not the original media stream stream which is using Multistream mode, not the original media stream
that included a full DH key agreement. Note that only the ZRTP that included a full DH key agreement. Note that only the ZRTP
messages (Figure 3 and Figure 6), not the entire ZRTP packets, are messages (Figure 3 and Figure 6), not the entire ZRTP packets, are
skipping to change at page 25, line 48 skipping to change at page 24, line 7
includes some unique nonce-derived material of its own (the H3 hash includes some unique nonce-derived material of its own (the H3 hash
image), thereby ensuring that each of the two parties can image), thereby ensuring that each of the two parties can
unilaterally force the resulting s0n shared secret to be unique for unilaterally force the resulting s0n shared secret to be unique for
each media stream, even if one party by some error fails to produce a each media stream, even if one party by some error fails to produce a
unique nonce. Note also that the ZRTPSess key is derived from unique nonce. Note also that the ZRTPSess key is derived from
material that also includes a different and more inclusive total_hash material that also includes a different and more inclusive total_hash
from the entire packet sequence that performed the original DH from the entire packet sequence that performed the original DH
exchange for the first media stream in this ZRTP session. exchange for the first media stream in this ZRTP session.
At this point in Multistream mode, the two endpoints begin key At this point in Multistream mode, the two endpoints begin key
generation as described in Section 5.5 using s0n in place of s0 in generation as described in Section 4.5 using s0n in place of s0 in
the key generation formulas for this media stream. the key generation formulas for this media stream.
5.4.3. Preshared Mode 4.4.3. Preshared Mode
The Preshared key agreement mode can be used to generate SRTP keys The Preshared key agreement mode can be used to generate SRTP keys
and salts without a DH calculation, instead relying on a shared and salts without a DH calculation, instead relying on a shared
secret from previous DH calculations between the endpoints. secret from previous DH calculations between the endpoints.
This key agreement mode is useful to rapidly re-establish a secure This key agreement mode is useful to rapidly re-establish a secure
session between two parties who have recently started and ended a session between two parties who have recently started and ended a
secure session that has already performed a DH key agreement, without secure session that has already performed a DH key agreement, without
performing another lengthy DH calculation, which may be desirable on performing another lengthy DH calculation, which may be desirable on
slow processors in resource-limited environments. Preshared mode slow processors in resource-limited environments. Preshared mode
skipping to change at page 26, line 31 skipping to change at page 24, line 36
ergonomically acceptable time limit. Shared key material may be ergonomically acceptable time limit. Shared key material may be
manually provisioned between two such endpoints in advance and still manually provisioned between two such endpoints in advance and still
allow a limited subset of functionality. Such a "better than allow a limited subset of functionality. Such a "better than
nothing" implementation would have to be regarded as non-compliant nothing" implementation would have to be regarded as non-compliant
with the ZRTP specification, but it could interoperate in Preshared with the ZRTP specification, but it could interoperate in Preshared
(and if applicable, Multistream) mode with a compliant ZRTP endpoint. (and if applicable, Multistream) mode with a compliant ZRTP endpoint.
Because Preshared mode affects the state of the retained shared Because Preshared mode affects the state of the retained shared
secret cache, only one in-process ZRTP Preshared exchange may occur secret cache, only one in-process ZRTP Preshared exchange may occur
at a time between two ZRTP endpoints. This rule is explained in more at a time between two ZRTP endpoints. This rule is explained in more
detail in Section 5.4.1, and applies for the same reasons as in DH detail in Section 4.4.1, and applies for the same reasons as in DH
mode. mode.
5.4.3.1. Commitment in Preshared Mode Preshared mode MUST NOT be used for establishing a second media
stream. Multistream mode is designed for that.
Preshared mode is only included in this specification to meet the
R-REUSE requirement in the Media Security Requirements
[I-D.ietf-sip-media-security-requirements] document. A series of
preshared-keyed calls between two ZRTP endpoints should use a DH key
exchange periodically. Preshared mode is only used if a cached
shared secret has been established in an earlier session by a DH
exchange, as discussed in Section 4.9.
4.4.3.1. Commitment in Preshared Mode
Preshared mode is selected by setting the Key Agreement Type to Preshared mode is selected by setting the Key Agreement Type to
Preshared in the Commit message. This results in the same call flow Preshared in the Commit message. This results in the same call flow
as Multistream mode. The principal difference between Multistream as Multistream mode. The principal difference between Multistream
mode and Preshared mode is that Preshared mode uses a previously mode and Preshared mode is that Preshared mode uses a previously
cached shared secret, rs1, instead of an active ZRTP Session key, cached shared secret, rs1, instead of an active ZRTP Session key,
ZRTPSess, as the initial keying material. ZRTPSess, as the initial keying material.
Because Preshared mode depends on having a reliable shared secret in Because Preshared mode depends on having a reliable shared secret in
its cache, it is RECOMMENDED that Preshared mode only be used when its cache, it is RECOMMENDED that Preshared mode only be used when
the SAS Verified flag has been previously set. the SAS Verified flag has been previously set.
5.4.3.2. Initiator Behavior 4.4.3.2. Initiator Behavior in Preshared Mode
The Commit message (Figure 7) is sent by the initiator of the ZRTP The Commit message (Figure 7) is sent by the initiator of the ZRTP
exchange. From the intersection of the algorithms in the sent and exchange. From the intersection of the algorithms in the sent and
received Hello messages, the initiator chooses a hash, cipher, auth received Hello messages, the initiator chooses a hash, cipher, auth
tag, key agreement type, and SAS type to be used. tag, key agreement type, and SAS type to be used.
To assemble a Preshared commit, we must first construct a temporary To assemble a Preshared commit, we must first construct a temporary
preshared_key, which is constructed from one of several possible preshared_key, which is constructed from one of several possible
combinations of cached key material, depending on what is available combinations of cached key material, depending on what is available
in the shared secret cache. If rs1 is not available in the in the shared secret cache. If rs1 is not available in the
skipping to change at page 27, line 29 skipping to change at page 25, line 49
For example, if auxsecret is null, len(auxsecret) is 0x00000000, and For example, if auxsecret is null, len(auxsecret) is 0x00000000, and
auxsecret itself would be absent from the hash calculation, which auxsecret itself would be absent from the hash calculation, which
means len(pbxsecret) would immediately follow len(auxsecret). means len(pbxsecret) would immediately follow len(auxsecret).
In place of hvi in the Commit message, two smaller fields are In place of hvi in the Commit message, two smaller fields are
inserted by the initiator: inserted by the initiator:
- A random nonce of length 4-words (16 octets). - A random nonce of length 4-words (16 octets).
- A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits. - A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits.
5.4.3.3. Responder Behavior 4.4.3.3. Responder Behavior in Preshared Mode
The responder uses the received keyID to search for matching key The responder uses the received keyID to search for matching key
material in its cache. It does this by computing a preshared_key material in its cache. It does this by computing a preshared_key
value and keyID value using the same formula as the initiator, value and keyID value using the same formula as the initiator,
depending on what is available in the responder's local cache. If depending on what is available in the responder's local cache. If
the locally computed keyID does not match the received keyID in the the locally computed keyID does not match the received keyID in the
Commit, the responder recomputes a new preshared_key and keyID from a Commit, the responder recomputes a new preshared_key and keyID from a
different subset of shared keys from the cache, dropping auxsecret or different subset of shared keys from the cache, dropping auxsecret or
pbxsecret or both from the hash calculation, until a matching pbxsecret or both from the hash calculation, until a matching
preshared_key is found or it runs out of possibilities. Note that preshared_key is found or it runs out of possibilities. Note that
rs2 is not included in the process. rs2 is not included in the process.
If it finds the appropriate matching shared key material, it is used If it finds the appropriate matching shared key material, it is used
to derive s0 and a new ZRTPSess key, as described in the next section to derive s0 and a new ZRTPSess key, as described in the next section
on Shared Secret Calculation, Section 5.4.3.4. on Shared Secret Calculation, Section 4.4.3.4.
If the responder determines that it does not have a cached shared If the responder determines that it does not have a cached shared
secret from a previous DH exchange, or it fails to match the keyID secret from a previous DH exchange, or it fails to match the keyID
hash from the initiator with any combination of its shared keys, it hash from the initiator with any combination of its shared keys, it
SHOULD respond with its own DH Commit message. This would reverse SHOULD respond with its own DH Commit message. This would reverse
the roles and the responder would become the initiator, because the the roles and the responder would become the initiator, because the
DH Commit must always "trump" the Preshared Commit message as DH Commit must always "trump" the Preshared Commit message as
described in Section 5.2. The key exchange would then proceeds using described in Section 4.2. The key exchange would then proceeds using
DH mode. However, if a severely resource-limited responder lacks the DH mode. However, if a severely resource-limited responder lacks the
computing resources to respond in a reasonable time with a DH Commit, computing resources to respond in a reasonable time with a DH Commit,
it MAY respond with a ZRTP Error message (Section 6.9) indicating it MAY respond with a ZRTP Error message (Section 5.9) indicating
that no shared secret is available. that no shared secret is available.
If both sides send Preshared Commit messages initiating a secure If both sides send Preshared Commit messages initiating a secure
session at the same time, the contention is resolved and the session at the same time, the contention is resolved and the
initiator/responder roles are settled according to Section 5.2, and initiator/responder roles are settled according to Section 4.2, and
the protocol proceeds. the protocol proceeds.
In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. In Preshared mode, both the DHPart1 and DHPart2 messages are skipped.
After receiving the Commit message from the initiator, the responder After receiving the Commit message from the initiator, the responder
sends the Confirm1 message after calculating this stream's SRTP keys, sends the Confirm1 message after calculating this stream's SRTP keys,
as described below. as described below.
5.4.3.4. Shared Secret Calculation for Preshared Mode 4.4.3.4. Shared Secret Calculation for Preshared Mode
A hash of the received and sent ZRTP messages in the current ZRTP A hash of the received and sent ZRTP messages in the current ZRTP
exchange for the current media stream is calculated: exchange for the current media stream is calculated:
total_hash = hash(Hello of responder | Commit ) total_hash = hash(Hello of responder | Commit )
Note that only the ZRTP messages (Figure 3 and Figure 7), not the Note that only the ZRTP messages (Figure 3 and Figure 7), not the
entire ZRTP packets, are included in the hash. The nonce from the entire ZRTP packets, are included in the hash. The nonce from the
Commit message is implicitly included in the total_hash, which hashed Commit message is implicitly included in the total_hash, which hashed
the entire Commit message and the other party's Hello message. Next, the entire Commit message and the other party's Hello message. Next,
skipping to change at page 28, line 46 skipping to change at page 27, line 19
s0 and ZRTPSess. The ZRTPSess key allows the later use of s0 and ZRTPSess. The ZRTPSess key allows the later use of
Multistream mode for adding additional media streams to this session. Multistream mode for adding additional media streams to this session.
Note that the responder's Hello message, included in the total_hash, Note that the responder's Hello message, included in the total_hash,
includes some unique nonce-derived material of its own (the H3 hash includes some unique nonce-derived material of its own (the H3 hash
image), thereby ensuring that each of the two parties can image), thereby ensuring that each of the two parties can
unilaterally force the resulting s0 shared secret to be unique for unilaterally force the resulting s0 shared secret to be unique for
each media stream, even if one party by some error fails to produce a each media stream, even if one party by some error fails to produce a
unique nonce. unique nonce.
Note: Since the nonce is used to calculate different SRTP key and Note: Since the nonce is used to calculate different SRTP key and
salt pairs for each media stream, a duplication will result in the salt pairs for each media stream, a duplication will result in the
same key and salt being generated for the two media streams, which same key and salt being generated for the two media streams, which
would have disastrous security consequences. would have disastrous security consequences.
At this point in Preshared mode, the two endpoints begin key At this point in Preshared mode, the two endpoints begin key
generation as described in Section 5.5, now that there is a defined generation as described in Section 4.5, now that there is a defined
s0 and ZRTPSess key. s0 and ZRTPSess key.
5.5. Key Generation 4.5. Key Generation
The following calculations derive a set of keys from s0. For the The following calculations derive a set of keys from s0. For the
original media stream that calculated s0 from the DH exchange, s0 original media stream that calculated s0 from the DH exchange, s0
means the original s0. For any additional media streams that were means the original s0. For any additional media streams that were
activated in Multistream mode, s0 means s0n, for the n-th media activated in Multistream mode, s0 means s0n, for the n-th media
stream. It is also assumed that the ZRTPSess key has been defined. stream. It is also assumed that the ZRTPSess key has been defined.
Various keys, such as those used by SRTP, must be derived from the Various keys, such as those used by SRTP, must be derived from the
shared secret s0. To do this, ZRTP uses an HMAC-based key derivation shared secret s0. To do this, ZRTP uses an HMAC-based key derivation
function, keyed by s0, instead of simply drawing subkey material function, keyed by s0, instead of simply drawing subkey material
skipping to change at page 29, line 47 skipping to change at page 28, line 19
srtpsaltr = HMAC(s0,"Responder SRTP master salt") srtpsaltr = HMAC(s0,"Responder SRTP master salt")
The SRTP key and salt values are truncated (taking the leftmost bits) The SRTP key and salt values are truncated (taking the leftmost bits)
to the length determined by the chosen SRTP algorithm. to the length determined by the chosen SRTP algorithm.
The HMAC keys are the same length as the output of the underlying The HMAC keys are the same length as the output of the underlying
hash function, and are thus generated without truncation by: hash function, and are thus generated without truncation by:
hmackeyi = HMAC(s0,"Initiator HMAC key") hmackeyi = HMAC(s0,"Initiator HMAC key")
hmackeyr = HMAC(s0,"Responder HMAC key") hmackeyr = HMAC(s0,"Responder HMAC key")
Note that these HMAC keys are used only by ZRTP and not by SRTP.
Note that these HMAC keys are used only by ZRTP and not by SRTP. Note: Different HMAC keys are needed for the initiator and the
responder to ensure that GoClear messages in each direction are
Note: Different HMAC keys are needed for the initiator and the unique and can not be cached by an attacker and reflected back to
responder to ensure that GoClear messages in each direction are the endpoint.
unique and can not be cached by an attacker and reflected back to the
endpoint.
ZRTP keys are generated for the initiator and responder to use to ZRTP keys are generated for the initiator and responder to use to
encrypt the Confirm1 and Confirm2 messages. They are truncated to encrypt the Confirm1 and Confirm2 messages. They are truncated to
the same size as the negotiated SRTP key size. the same size as the negotiated SRTP key size.
zrtpkeyi = HMAC(s0,"Initiator ZRTP key") zrtpkeyi = HMAC(s0,"Initiator ZRTP key")
zrtpkeyr = HMAC(s0,"Responder ZRTP key") zrtpkeyr = HMAC(s0,"Responder ZRTP key")
All key material is destroyed as soon as it is no longer needed, no All key material is destroyed as soon as it is no longer needed, no
later than the end of the call. s0 is erased in Section 5.6.1, and later than the end of the call. s0 is erased in Section 4.6.1, and
the rest of the session key material is erased in Section 5.7.2.1 and the rest of the session key material is erased in Section 4.7.2.1 and
Section 5.7.3. Section 4.7.3.
The Short Authentication String (SAS) value is calculated from the The Short Authentication String (SAS) value is calculated from the
HMAC of a fixed string, keyed with the ZRTPSess key derived from the HMAC of a fixed string, keyed with the ZRTPSess key derived from the
DH key agreement. This means the same SAS is used for all media DH key agreement. This means the same SAS is used for all media
streams which are derived from a single DH key agreement in a ZRTP streams which are derived from a single DH key agreement in a ZRTP
session. session.
sashash = HMAC(ZRTPSess,"SAS") sashash = HMAC(ZRTPSess,"SAS")
sasvalue = sashash [truncated to leftmost 32 bits] sasvalue = sashash [truncated to leftmost 32 bits]
5.6. Confirmation 4.6. Confirmation
The Confirm1 and Confirm2 messages (Figure 10) contain the cache The Confirm1 and Confirm2 messages (Figure 10) contain the cache
expiration interval (defined in Section 5.9) for the newly generated expiration interval (defined in Section 4.9) for the newly generated
retained shared secret. The flagoctet is an 8 bit unsigned integer retained shared secret. The flagoctet is an 8 bit unsigned integer
made up of these flags: the PBX Enrollment flag (E) defined in made up of these flags: the PBX Enrollment flag (E) defined in
Section 8.3.1, SAS Verified flag (V) defined in Section 8.1, Allow Section 7.3.1, SAS Verified flag (V) defined in Section 7.1, Allow
Clear flag (A) defined in Section 5.7.2, and Disclosure flag (D) Clear flag (A) defined in Section 4.7.2, and Disclosure flag (D)
defined in Section 12. defined in Section 11.
flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0)
Part of the Confirm1 and Confirm2 messages are encrypted using full- Part of the Confirm1 and Confirm2 messages are encrypted using full-
block Cipher Feedback Mode, and contain a 128-bit random CFB block Cipher Feedback Mode, and contain a 128-bit random CFB
Initialization Vector (IV). The Confirm1 and Confirm2 messages also Initialization Vector (IV). The Confirm1 and Confirm2 messages also
contain an HMAC covering the encrypted part of the Confirm1 or contain an HMAC covering the encrypted part of the Confirm1 or
Confirm2 message which includes a string of zeros, the signature Confirm2 message which includes a string of zeros, the signature
length, flag octet, cache expiration interval, signature type block length, flag octet, cache expiration interval, signature type block
(if present) and signature block (Section 8.2) (if present). For the (if present) and signature block (Section 7.2) (if present). For the
responder responder:
hmac = HMAC(hmackeyr, encrypted part of Confirm1) hmac = HMAC(hmackeyr, encrypted part of Confirm1)
For the initiator: For the initiator:
hmac = HMAC(hmackeyi, encrypted part of Confirm2) hmac = HMAC(hmackeyi, encrypted part of Confirm2)
The hmackeyi and hmackeyr keys are computed in Section 5.5. The hmackeyi and hmackeyr keys are computed in Section 4.5.
The Conf2ACK message sent by the responder completes the exchange. The exchange is completed when the responder sends either the
Conf2ACK message or the responder's first SRTP media packet (with a
valid SRTP auth tag). The initiator MUST treat the first valid SRTP
media from the responder as equivalent to receiving a Conf2ACK. The
responder may respond to Confirm2 with either SRTP media or Conf2ACK,
or both, in whichever order the responder chooses (or whichever order
the "cloud" chooses to deliver them).
5.6.1. Updating the Cache of Shared Secrets 4.6.1. Updating the Cache of Shared Secrets
After receiving the Confirm messages, both parties must now update After receiving the Confirm messages, both parties must now update
their retained shared secret rs1 in their respective caches, provided their retained shared secret rs1 in their respective caches, provided
the following conditions hold: the following conditions hold:
1) This key exchange is either DH or Preshared mode, not 1) This key exchange is either DH or Preshared mode, not
Multistream mode, which does not update the cache. Multistream mode, which does not update the cache.
2) Depending on the values of the cache expiration intervals that 2) Depending on the values of the cache expiration intervals that
are received in the two Confirm messages, there are some scenarios are received in the two Confirm messages, there are some scenarios
that do not update the cache, as explained in Section 5.9. that do not update the cache, as explained in Section 4.9.
3) The responder MUST receive the initiator's Confirm2 message 3) The responder MUST receive the initiator's Confirm2 message
before updating the responder's cache. before updating the responder's cache.
4) The initiator MUST receive the responder's Conf2Ack message 4) The initiator MUST receive either the responder's Conf2ACK
message or the responder's SRTP media (with a valid SRTP auth tag)
before updating the initiator's cache. before updating the initiator's cache.
For DH mode only, before updating the retained shared secret rs1 in For DH mode only, before updating the retained shared secret rs1 in
the cache, each party first discards their old rs2 and copies their the cache, each party first discards their old rs2 and copies their
old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of
session interruption after one party has updated his own rs1 but session interruption after one party has updated his own rs1 but
before the other party has enough information to update her own rs1. before the other party has enough information to update her own rs1.
If that happens, they may regain cache sync in the next session by If that happens, they may regain cache sync in the next session by
using rs2 (per Section 5.3). This mitigates the well-known Byzantine using rs2 (per Section 4.3). This mitigates the well-known Byzantine
Generals' Problem [Byzantine]. The old rs1 value is not saved in Generals' Problem [Byzantine]. The old rs1 value is not saved in
Preshared mode. Preshared mode.
For DH mode and Preshared mode, both parties compute a new rs1 value For DH mode and Preshared mode, both parties compute a new rs1 value
from s0 this way: from s0 this way:
rs1 = HMAC(s0,"retained secret") rs1 = HMAC(s0,"retained secret")
After s0 is used to derive the new rs1, it MUST be erased. Even if After s0 is used to derive the new rs1, it MUST be erased. Even if
rs1 is not updated (in the case of Multistream mode), s0 MUST still rs1 is not updated (in the case of Multistream mode), s0 MUST still
be destroyed. be destroyed.
5.7. Termination 4.7. Termination
A ZRTP session is normally terminated at the end of a call, but it A ZRTP session is normally terminated at the end of a call, but it
may be terminated early by either the Error message or the GoClear may be terminated early by either the Error message or the GoClear
message. message.
5.7.1. Termination via Error message 4.7.1. Termination via Error message
The Error message (Section 6.9) is used to terminate an in-progress The Error message (Section 5.9) is used to terminate an in-progress
ZRTP exchange due to an error. The Error message contains an integer ZRTP exchange due to an error. The Error message contains an integer
Error Code for debugging purposes. The termination of a ZRTP key Error Code for debugging purposes. The termination of a ZRTP key
agreement exchange results in no updates to the cached shared secrets agreement exchange results in no updates to the cached shared secrets
and deletion of all crypto context. and deletion of all crypto context.
The ZRTP Session key, ZRTPSess, is only deleted if the ZRTP session The ZRTP Session key, ZRTPSess, is only deleted if the ZRTP session
in which it was generated and all ZRTP sessions which are using it in which it was generated and all ZRTP sessions which are using it
are terminated. are terminated.
5.7.2. Termination via GoClear message 4.7.2. Termination via GoClear message
The GoClear message (Section 6.11) is used to switch from SRTP to The GoClear message (Section 5.11) is used to switch from SRTP to
RTP, usually because the user has chosen to do that by pressing a RTP, usually because the user has chosen to do that by pressing a
button. The GoClear uses an HMAC of the Message Type Block sent in button. The GoClear uses an HMAC of the Message Type Block sent in
the GoClear Message computed with the hmackey derived from the shared the GoClear Message computed with the hmackey derived from the shared
secret. This HMAC is truncated to the leftmost 64 bits. When sent secret. This HMAC is truncated to the leftmost 64 bits. When sent
by the initiator: by the initiator:
clear_hmac = HMAC(hmackeyi, "GoClear ") clear_hmac = HMAC(hmackeyi, "GoClear ")
When sent by the responder: When sent by the responder:
clear_hmac = HMAC(hmackeyr, "GoClear ") clear_hmac = HMAC(hmackeyr, "GoClear ")
A GoClear message which does not receive a ClearACK response must be A GoClear message which does not receive a ClearACK response must be
resent. If a GoClear message is received with a bad HMAC, it must be resent. If a GoClear message is received with a bad HMAC, it must be
ignored, and no ClearACK is sent. ignored, and no ClearACK is sent.
A ZRTP endpoint MAY choose to accept GoClear messages after the A ZRTP endpoint MAY choose to accept GoClear messages after the
session has switched to SRTP, allowing the session to revert to RTP. session has switched to SRTP, allowing the session to revert to RTP.
This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by
setting the Allow Clear flag (A). If both endpoints set the Allow setting the Allow Clear flag (A). If an endpoint sets the Allow
Clear (A) flag in their Confirm message, GoClear messages MAY be Clear (A) flag in their Confirm message, it indicates that they
sent. support receiving GoClear messages.
A ZRTP endpoint that receives a GoClear authenticates the message by A ZRTP endpoint that receives a GoClear MUST authenticate the message
checking the clear_hmac. If the message authenticates, the endpoint by checking the clear_hmac. If the message authenticates, the
stops sending SRTP packets, and generates a ClearACK in response. It endpoint stops sending SRTP packets, and generates a ClearACK in
MUST also delete all the crypto key material for all the SRTP media response. It MUST also delete all the crypto key material for all
streams, as defined in Section 5.7.2.1. the SRTP media streams, as defined in Section 4.7.2.1.
Until confirmation from the user is received (e.g. clicking a button, Until confirmation from the user is received (e.g. clicking a button,
pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending
RTP packets. The endpoint then renders to the user an indication RTP packets. The endpoint then renders to the user an indication
that the media session has switched to clear mode, and waits for that the media session has switched to clear mode, and waits for
confirmation from the user. To prevent pinholes from closing or NAT confirmation from the user. This blocks the flow of sensitive
discourse until the user is forced to take notice that he's no longer
protected by encryption. To prevent pinholes from closing or NAT
bindings from expiring, the ClearACK message MAY be resent at regular bindings from expiring, the ClearACK message MAY be resent at regular
intervals (e.g. every 5 seconds) while waiting for confirmation from intervals (e.g. every 5 seconds) while waiting for confirmation from
the user. After confirmation of the notification is received from the user. After confirmation of the notification is received from
the user, the sending of RTP packets may begin. the user, the sending of RTP packets may begin.
After sending a GoClear message, the ZRTP endpoint stops sending SRTP After sending a GoClear message, the ZRTP endpoint stops sending SRTP
packets. When a ClearACK is received, the ZRTP endpoint deletes the packets. When a ClearACK is received, the ZRTP endpoint deletes the
crypto context for the SRTP session, as defined in Section 5.7.2.1, crypto context for the SRTP session, as defined in Section 4.7.2.1,
and may then resume sending RTP packets. and may then resume sending RTP packets.
In the event a ClearACK is not received before the retransmissions of In the event a ClearACK is not received before the retransmissions of
GoClear are exhausted, the key material is deleted, as defined in GoClear are exhausted, the key material is deleted, as defined in
Section 5.7.2.1. Section 4.7.2.1.
After the users have transitioned from SRTP media back to RTP media After the users have transitioned from SRTP media back to RTP media
(clear mode), they may decide later to return to secure mode by (clear mode), they may decide later to return to secure mode by
manual activation, usually by pressing a GO SECURE button. In that manual activation, usually by pressing a GO SECURE button. In that
case, a new secure session is initiated by the party that presses the case, a new secure session is initiated by the party that presses the
button, by sending a new Commit packet, leadng to a new session key button, by sending a new Commit packet, leadng to a new session key
negotiation. It is not necessary to send another Hello packet, as negotiation. It is not necessary to send another Hello packet, as
the two parties have already done that at the start of the call and the two parties have already done that at the start of the call and
thus have already discovered each other's ZRTP capabilities. It is thus have already discovered each other's ZRTP capabilities. It is
possible for users to toggle back and forth between clear and secure possible for users to toggle back and forth between clear and secure
modes multiple times in the same call, just as they could in the old modes multiple times in the same call, just as they could in the old
days of secure PSTN phones. days of secure PSTN phones.
5.7.2.1. Key Destruction for GoClear message 4.7.2.1. Key Destruction for GoClear message
All SRTP session key material MUST be erased by the receiver of the All SRTP session key material MUST be erased by the receiver of the
GoClear message upon receiving a properly authenticated GoClear. The GoClear message upon receiving a properly authenticated GoClear. The
same key destruction MUST be done by the sender of GoClear message, same key destruction MUST be done by the sender of GoClear message,
upon receiving the ClearACK. upon receiving the ClearACK.
In particular, the destroyed key material includes the SRTP session In particular, the destroyed key material includes the SRTP session
keys and salts, SRTP master keys and salts, and all material keys and salts, SRTP master keys and salts, and all material
sufficient to reconstruct the SRTP keys and salts, including ZRTPSess sufficient to reconstruct the SRTP keys and salts, including ZRTPSess
(s0 should have been destroyed earlier, in Section 5.6.1). All key (s0 should have been destroyed earlier, in Section 4.6.1). All key
material that would have been erased at the end of the SIP session material that would have been erased at the end of the SIP session
MUST be erased. However, ZRTPSess is destroyed in a manner different MUST be erased. However, ZRTPSess is destroyed in a manner different
from the other key material. Both parties replace ZRTPSess with a from the other key material. Both parties replace ZRTPSess with a
hash of itself, without truncation: hash of itself, without truncation:
ZRTPSess = hash(ZRTPSess) ZRTPSess = hash(ZRTPSess)
This meets the requirements of Perfect Forward Secrecy (PFS), but This meets the requirements of Perfect Forward Secrecy (PFS), but
preserves a new version of ZRTPSess, so that if the user later re- preserves a new version of ZRTPSess, so that the user can later re-
initiates secure mode during the same call, the new key negotiation initiate secure mode during the same call without performing another
can (and SHOULD) use a Multistream Commit message, which requires and Diffie-Hellman calculation using Multistream mode which requires and
assumes the existence of ZRTPSess with the same value at both ZRTP assumes the existence of ZRTPSess with the same value at both ZRTP
endpoints. endpoints. A new key negotiation after a GoClear SHOULD use a
Multistream Commit message.
Note: Multistream mode is preferred over a Diffie-Hellman mode
since this does not require the generation of a new hash chain and
a new signaling exchange to exchange new hash values.
Later, at the end of the entire call, ZRTPSess is finally destroyed Later, at the end of the entire call, ZRTPSess is finally destroyed
along with the other key material, as described in Section 5.7.3. along with the other key material, as described in Section 4.7.3.
5.7.3. Key Destruction at Termination 4.7.3. Key Destruction at Termination
All SRTP session key material MUST be erased by both parties at the All SRTP session key material MUST be erased by both parties at the
end of the call. In particular, the destroyed key material includes end of the call. In particular, the destroyed key material includes
the SRTP session keys and salts, SRTP master keys and salts, and all the SRTP session keys and salts, SRTP master keys and salts, and all
material sufficient to reconstruct the SRTP keys and salts, including material sufficient to reconstruct the SRTP keys and salts, including
ZRTPSess and s0 (although s0 should have been destroyed earlier, in ZRTPSess and s0 (although s0 should have been destroyed earlier, in
Section 5.6.1). The only exceptions are the cached shared secrets Section 4.6.1). The only exceptions are the cached shared secrets
needed for future calls, including rs1, rs2, and pbxsecret. needed for future calls, including rs1, rs2, and pbxsecret.
5.8. Random Number Generation 4.8. Random Number Generation
The ZRTP protocol uses random numbers for cryptographic key material, The ZRTP protocol uses random numbers for cryptographic key material,
notably for the DH secret exponents and nonces, which must be freshly notably for the DH secret exponents and nonces, which must be freshly
generated with each session. Whenever a random number is needed, all generated with each session. Whenever a random number is needed, all
of the following criteria must be satisfied: of the following criteria must be satisfied:
It MUST be freshly generated, meaning that it must not have been used Random numbers MUST be freshly generated, meaning that it must not
in a previous calculation. have been used in a previous calculation.
When generating a random number k of L bits in length, k MUST be When generating a random number k of L bits in length, k MUST be
chosen with equal probability from the range of [1 < k < 2^L]. chosen with equal probability from the range of [1 < k < 2^L].
It MUST be derived from a physical entropy source, such as RF noise, It MUST be derived from a physical entropy source, such as RF noise,
acoustic noise, thermal noise, high resolution timings of acoustic noise, thermal noise, high resolution timings of
environmental events, or other unpredictable physical sources of environmental events, or other unpredictable physical sources of
entropy. For a detailed explanation of cryptographic grade random entropy. For a detailed explanation of cryptographic grade random
numbers and guidance for collecting suitable entropy, see RFC 4086 numbers and guidance for collecting suitable entropy, see RFC 4086
[RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. The [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. The
raw entropy must be distilled and processed through a deterministic raw entropy must be distilled and processed through a deterministic
random bit generator (DRBG). Examples of DRBGs may be found in NIST random bit generator (DRBG). Examples of DRBGs may be found in NIST
SP 800-90 [SP800-90], and in [Ferguson]. Failure to use true entropy SP 800-90 [SP800-90], and in [Ferguson]. Failure to use true entropy
from the physical environment as a basis for generating random from the physical environment as a basis for generating random
cryptographic key material would lead to a disastrous loss of cryptographic key material would lead to a disastrous loss of
security. security.
5.9. ZID and Cache Operation 4.9. ZID and Cache Operation
Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that
is generated once at installation time. It is used to look up is generated once at installation time. It is used to look up
retained shared secrets in a local cache. A single global ZID for a retained shared secrets in a local cache. A single global ZID for a
single installation is the simplest way to implement ZIDs. However, single installation is the simplest way to implement ZIDs. However,
it is specifically not precluded for an implementation to use it is specifically not precluded for an implementation to use
multiple ZIDs, up to the limit of a separate one per callee. This multiple ZIDs, up to the limit of a separate one per callee. This
then turns it into a long-lived "association ID" that does not apply then turns it into a long-lived "association ID" that does not apply
to any other associations between a different pair of parties. It is to any other associations between a different pair of parties. It is
a goal of this protocol to permit both options to interoperate a goal of this protocol to permit both options to interoperate
freely. freely.
Each time a new s0 is calculated, a new retained shared secret rs1 is Each time a new s0 is calculated, a new retained shared secret rs1 is
generated and stored in the cache, indexed by the ZID of the other generated and stored in the cache, indexed by the ZID of the other
endpoint. But first the previous rs1 is copied to rs2 and also endpoint. This cache updating is described in Section 4.6.1. For
stored in the cache. For the new retained shared secret, each the new retained shared secret, each endpoint chooses a cache
endpoint chooses a cache expiration value which is an unsigned 32 bit expiration value which is an unsigned 32 bit integer of the number of
integer of the number of seconds that this secret should be retained seconds that this secret should be retained in the cache. The time
in the cache. The time interval is relative to when the Confirm1 interval is relative to when the Confirm1 message is sent or
message is sent or received. received.
The cache intervals are exchanged in the Confirm1 and Confirm2 The cache intervals are exchanged in the Confirm1 and Confirm2
messages (Figure 10). The actual cache interval used by both messages (Figure 10). The actual cache interval used by both
endpoints is the minimum of the values from the Confirm1 and Confirm2 endpoints is the minimum of the values from the Confirm1 and Confirm2
messages. A value of 0 seconds means the newly-computed shared messages. A value of 0 seconds means the newly-computed shared
secret SHOULD NOT be stored in the cache, and if a cache entry secret SHOULD NOT be stored in the cache, and if a cache entry
already exists from an earlier call, the stored cache interval should already exists from an earlier call, the stored cache interval should
be set to 0. This means if either Confirm message contains a null be set to 0. This means if either Confirm message contains a null
cache expiration interval, and there is no cache entry already cache expiration interval, and there is no cache entry already
defined, no new cache entry is created. A value of 0xffffffff means defined, no new cache entry is created. A value of 0xffffffff means
skipping to change at page 35, line 47 skipping to change at page 34, line 33
means the shared secret MAY be deleted from that cache at any point means the shared secret MAY be deleted from that cache at any point
after the interval has expired without causing the other party to after the interval has expired without causing the other party to
note it as an unexpected security event when the next key negotiation note it as an unexpected security event when the next key negotiation
occurs between the same two parties. This means there need not be occurs between the same two parties. This means there need not be
perfectly synchronized deletion of expired secrets from the two perfectly synchronized deletion of expired secrets from the two
caches, and makes it easy to avoid a race condition that might caches, and makes it easy to avoid a race condition that might
otherwise be caused by clock skew. otherwise be caused by clock skew.
If the expiration interval is not properly agreed to by both If the expiration interval is not properly agreed to by both
endpoints, it may later result in false alarms of MiTM attacks, due endpoints, it may later result in false alarms of MiTM attacks, due
to apparent cache mismatches (Section 5.3.3). to apparent cache mismatches (Section 4.3.3).
5.9.1. Self-healing Key Continuity Feature
The key continuity features of ZRTP are analogous to those provided
by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH
caches public signature keys that never change, and uses a permanent
private signature key that must be guarded from disclosure. If
someone steals your SSH private signature key, they can impersonate
you in all future sessions and mount a successful MiTM attack any
time they want.
ZRTP caches symmetric key material used to compute secret session
keys, and these values change with each session. If someone steals
your ZRTP shared secret cache, they only get one chance to mount a
MiTM attack, in the very next session. If they miss that chance, the
retained shared secret is refreshed with a new value, and the window
of vulnerability heals itself, which means they are locked out of any
future opportunities to mount a MiTM attack. This gives ZRTP a
"self-healing" feature if any cached key material is compromised.
A MiTM attacker must always be in the media path. This presents a 4.9.1. Cacheless implementations
significant operational burden for the attacker in many VoIP usage
scenarios, because being in the media path for every call is often
harder than being in the signaling path. This will likely create
coverage gaps in the attacker's opportunities to mount a MiTM attack.
ZRTP's self-healing key continuity features are better than SSH at
exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP
quickly recovers from any disclosure of cached key material.
The infamous Debian OpenSSL weak key vulnerability [dsa-1571] It is possible to implement a simplified but nonetheless useful
(discovered and patched in May 2008) offers a real-world example of profile of the ZRTP protocol that does not support any caching of
why ZRTP's self-healing scheme is a good way to do key continuity. shared secrets. In this case the cache expiration interval should
The Debian bug resulted in the production of a lot of weak SSH (and always be set to zero, and the SAS Verified (V) flag (Section 7.1)
TLS/SSL) keys, which continued to compromise security even after the should always be set to false. The users would have to rely
bug had been patched. In contrast, ZRTP's key continuity scheme adds exclusively on the verbal SAS comparison for every call. That is,
new entropy to the cached key material with every call, so old unless MiTM protection is provided by the mechanisms in Section 8.1.1
deficiencies in entropy are washed away with each new session. or Section 7.2, which introduce their own forms of complexity.
It should be noted that the addition of shared secret entropy from If caching of shared secrets is not supported, it would sacrifice the
previous sessions can extend the strength of the new session key to key continuity features, as well as Preshared mode (Section 4.4.3).
AES-256 levels, even if the new session uses Diffie-Hellman keys no There would also be no PBX trusted MiTM (Section 7.3) features,
larger than DH-3072 or ECDH-256, provided the cached shared secrets including the PBX security enrollment (Section 7.3.1) mechanism.
were initially established when the wiretapper was not present. This
is why AES-256 MAY be used with the smaller DH key sizes in
Section 6.1.5.
6. ZRTP Messages 5. ZRTP Messages
All ZRTP messages use the message format defined in Figure 2. All All ZRTP messages use the message format defined in Figure 2. All
word lengths referenced in this specification are 32 bits or 4 word lengths referenced in this specification are 32 bits or 4
octets. All integer fields are carried in network byte order, that octets. All integer fields are carried in network byte order, that
is, most significant byte (octet) first, commonly known as big- is, most significant byte (octet) first, commonly known as big-
endian. endian.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Not Used (set to zero) | Sequence Number | |0 0 0 1|Not Used (set to zero) | Sequence Number |
skipping to change at page 37, line 29 skipping to change at page 35, line 29
| Source Identifier | | Source Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ZRTP Message (length depends on Message Type) | | ZRTP Message (length depends on Message Type) |
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (1 word) | | CRC (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ZRTP Packet Format
Figure 2: ZRTP Packet Format Figure 2: ZRTP Packet Format
The Sequence Number is a count that is incremented for each ZRTP The Sequence Number is a count that is incremented for each ZRTP
packet sent. The count is initialized to a random value. This is packet sent. The count is initialized to a random value. This is
useful in estimating ZRTP packet loss and also detecting when ZRTP useful in estimating ZRTP packet loss and also detecting when ZRTP
packets arrive out of sequence. packets arrive out of sequence.
The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a
ZRTP packet, and has the value 0x5a525450. ZRTP packet, and has the value 0x5a525450.
skipping to change at page 38, line 27 skipping to change at page 36, line 24
on a mere 16-bit checksum that usually protects UDP packets, so more on a mere 16-bit checksum that usually protects UDP packets, so more
error detection is needed. For these reasons, this belt-and- error detection is needed. For these reasons, this belt-and-
suspenders approach is used to minimize the chance of a transmission suspenders approach is used to minimize the chance of a transmission
error affecting the ZRTP key agreement. error affecting the ZRTP key agreement.
The CRC is calculated across the entire ZRTP packet shown in The CRC is calculated across the entire ZRTP packet shown in
Figure 2, including the ZRTP Header and the ZRTP Message, but not Figure 2, including the ZRTP Header and the ZRTP Message, but not
including the CRC field. If a ZRTP message fails the CRC check, it including the CRC field. If a ZRTP message fails the CRC check, it
is silently discarded. is silently discarded.
6.1. ZRTP Message Formats 5.1. ZRTP Message Formats
ZRTP messages are designed to simplify endpoint parsing requirements ZRTP messages are designed to simplify endpoint parsing requirements
and to reduce the opportunities for buffer overflow attacks (a good and to reduce the opportunities for buffer overflow attacks (a good
goal of any security extension should be to not introduce new attack goal of any security extension should be to not introduce new attack
vectors). vectors).
ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets
(1 word) blocks are used to encode Hash Type, Cipher Type, and Key (1 word) blocks are used to encode Hash Type, Cipher Type, and Key
Agreement Type, and Authentication Tag. The values in the blocks are Agreement Type, and Authentication Tag. The values in the blocks are
ASCII strings which are extended with spaces (0x20) to make them the ASCII strings which are extended with spaces (0x20) to make them the
desired length. Currently defined block values are listed in Tables desired length. Currently defined block values are listed in Tables
1-6 below. 1-6 below.
Additional block values may be defined and used. Additional block values may be defined and used.
ZRTP uses this ASCII encoding to simplify debugging and make it ZRTP uses this ASCII encoding to simplify debugging and make it
"Wireshark (Ethereal) friendly". "Wireshark (Ethereal) friendly".
6.1.1. Message Type Block 5.1.1. Message Type Block
Currently 14 Message Type Blocks are defined - they represent the set Currently 14 Message Type Blocks are defined - they represent the set
of ZRTP message primitives. ZRTP endpoints MUST support the Hello, of ZRTP message primitives. ZRTP endpoints MUST support the Hello,
HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK,
SASrelay, RelayACK, Error and ErrorACK block types. ZRTP endpoints SASrelay, RelayACK, Error and ErrorACK message types. ZRTP endpoints
MAY support the GoClear and ClearACK messages. Additional messages MAY support the GoClear and ClearACK messages. Additional messages
may be defined in extensions to ZRTP. may be defined in extensions to ZRTP.
Message Type Block | Meaning Message Type Block | Meaning
--------------------------------------------------- ---------------------------------------------------
"Hello " | Hello Message "Hello " | Hello Message
| defined in Section 6.2
--------------------------------------------------- ---------------------------------------------------
"HelloACK" | HelloACK Message "HelloACK" | HelloACK Message
| defined in Section 6.3
--------------------------------------------------- ---------------------------------------------------
"Commit " | Commit Message "Commit " | Commit Message
| defined in Section 6.4
--------------------------------------------------- ---------------------------------------------------
"DHPart1 " | DHPart1 Message "DHPart1 " | DHPart1 Message
| defined in Section 6.5
--------------------------------------------------- ---------------------------------------------------
"DHPart2 " | DHPart2 Message "DHPart2 " | DHPart2 Message
| defined in Section 6.6
--------------------------------------------------- ---------------------------------------------------
"Confirm1" | Confirm1 Message "Confirm1" | Confirm1 Message
| defined in Section 6.7
--------------------------------------------------- ---------------------------------------------------
"Confirm2" | Confirm2 Message "Confirm2" | Confirm2 Message
| defined in Section 6.7
--------------------------------------------------- ---------------------------------------------------
"Conf2ACK" | Conf2ACK Message "Conf2ACK" | Conf2ACK Message
| defined in Section 6.8
--------------------------------------------------- ---------------------------------------------------
"Error " | Error Message "Error " | Error Message
| defined in Section 6.9
--------------------------------------------------- ---------------------------------------------------
"ErrorACK" | ErrorACK Message "ErrorACK" | ErrorACK Message
| defined in Section 6.10
--------------------------------------------------- ---------------------------------------------------
"GoClear " | GoClear Message "GoClear " | GoClear Message
| defined in Section 6.11
--------------------------------------------------- ---------------------------------------------------
"ClearACK" | ClearACK Message "ClearACK" | ClearACK Message
| defined in Section 6.12
--------------------------------------------------- ---------------------------------------------------
"SASrelay" | SASrelay Message "SASrelay" | SASrelay Message
| defined in Section 6.13
--------------------------------------------------- ---------------------------------------------------
"RelayACK" | RelayACK Message "RelayACK" | RelayACK Message
| defined in Section 6.14
--------------------------------------------------- ---------------------------------------------------
Table 1. Message Block Type Values Table 1. Message Type Block Values
6.1.2. Hash Type Block 5.1.2. Hash Type Block
Only one Hash Type is currently defined, SHA-256 [FIPS-180-2], and Only one Hash Type is currently defined, SHA-256 [FIPS-180-2], and
all ZRTP endpoints MUST support this hash. Additional Hash Types can all ZRTP endpoints MUST support this hash. Additional Hash Types can
be registered and used, such as the NIST SHA-3 hash [SHA-3] when it be registered and used, such as the NIST SHA-3 hash [SHA-3] when it
becomes available. Note that the Hash Type refers to the hash becomes available. Note that the Hash Type refers to the hash
algorithm that will be used throughout the ZRTP key exchange, not the algorithm that will be used throughout the ZRTP key exchange, not the
hash algorithm to be used in the SRTP Authentication Tag. hash algorithm to be used in the SRTP Authentication Tag.
ZRTP makes use of HMAC message authentication codes based on the ZRTP makes use of HMAC message authentication codes based on the
negotiated Hash Type. The HMAC function is defined in [FIPS-198-1]. negotiated Hash Type. The HMAC function is defined in [FIPS-198-1].
Test vectors for HMAC-SHA-256 may be found in [RFC4231]. Test vectors for HMAC-SHA-256 may be found in [RFC4231].
Hash Type Block | Meaning Hash Type Block | Meaning
--------------------------------------------------- ---------------------------------------------------
"S256" | SHA-256 Hash defined in FIPS 180-2 "S256" | SHA-256 Hash defined in FIPS 180-2
--------------------------------------------------- ---------------------------------------------------
Table 2. Hash Block Type Values Table 2. Hash Type Block Values
All hashes and HMACs used throughout the ZRTP protocol will use the All hashes and HMACs used throughout the ZRTP protocol will use the
negotiated Hash Type, except for the special cases noted in negotiated Hash Type, except for the special cases noted in
Section 6.1.2.1. Section 5.1.2.1.
6.1.2.1. Implicit Hash and HMAC algorithm 5.1.2.1. Implicit Hash and HMAC algorithm
While most of the HMACs used in ZRTP are defined by the negotiated While most of the HMACs used in ZRTP are defined by the negotiated
Hash Type (Section 6.1.2), some hashes and HMACs must be precomputed Hash Type (Section 5.1.2), some hashes and HMACs must be precomputed
prior to negotiations, and thus cannot have their algorithms prior to negotiations, and thus cannot have their algorithms
negotiated during the ZRTP exchange. They are implicitly negotiated during the ZRTP exchange. They are implicitly
predetermined to use SHA-256 [FIPS-180-2] and HMAC-SHA-256. predetermined to use SHA-256 [FIPS-180-2] and HMAC-SHA-256.
These are the hashes and HMACs that MUST use the Implicit hash and These are the hashes and HMACs that MUST use the Implicit hash and
HMAC algorithm: HMAC algorithm:
The hash chain H0-H3 defined in Section 10. The hash chain H0-H3 defined in Section 9.
The HMACs that are keyed by this hash chain, as defined in The HMACs that are keyed by this hash chain, as defined in
Section 9.1.1. Section 8.1.1.
The Hello Hash in the a=zrtp-hash attribute defined in The Hello Hash in the a=zrtp-hash attribute defined in
Section 9.1. Section 8.1.
ZRTP defines a method for negotiating different ZRTP protocol ZRTP defines a method for negotiating different ZRTP protocol
versions (Section 5.1.1). SHA-256 is the Implicit Hash for ZRTP versions (Section 4.1.1). SHA-256 is the Implicit Hash for ZRTP
protocol version 1.00. Future ZRTP protocol versions may, if protocol version 1.00. Future ZRTP protocol versions may, if
appropriate, use another hash algorithm as the Implicit Hash, such as appropriate, use another hash algorithm as the Implicit Hash, such as
the NIST SHA-3 hash [SHA-3] when it becomes available. For example, the NIST SHA-3 hash [SHA-3] when it becomes available. For example,
a future SIP packet may list two a=zrtp-hash SDP attributes, one a future SIP packet may list two a=zrtp-hash SDP attributes, one
based on SHA-256 for ZRTP version 1.00, and another based on SHA-3 based on SHA-256 for ZRTP version 1.00, and another based on SHA-3
for ZRTP version 2.00. for ZRTP version 2.00.
6.1.3. Cipher Type Block 5.1.3. Cipher Type Block
All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES-
256 (AES3). or other Cipher Types. The choice of the AES key length 256 (AES3) or other Cipher Types. The choice of the AES key length
is coupled to the Key Agreement type, as explained in Section 6.1.5. is coupled to the Key Agreement type, as explained in Section 5.1.5.
The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES-
256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. 256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes].
Cipher Type Block | Meaning Cipher Type Block | Meaning
--------------------------------------------------- ---------------------------------------------------
"AES1" | AES-CM with 128 bit keys "AES1" | AES-CM with 128 bit keys
| as defined in RFC 3711 | as defined in RFC 3711
--------------------------------------------------- ---------------------------------------------------
"AES3" | AES-CM with 256 bit keys "AES3" | AES-CM with 256 bit keys
| |
--------------------------------------------------- ---------------------------------------------------
Table 3. Cipher Block Type Values Table 3. Cipher Type Block Values
6.1.4. Auth Tag Block 5.1.4. Auth Tag Block
All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and
80 bit length tags as defined in [RFC3711]. 80 bit length tags as defined in [RFC3711].
Auth Tag Block | Meaning Auth Tag Block | Meaning
--------------------------------------------------- ---------------------------------------------------
"HS32" | HMAC-SHA1 32 bit authentication "HS32" | HMAC-SHA1 32 bit authentication
| tag as defined in RFC 3711 | tag as defined in RFC 3711
--------------------------------------------------- ---------------------------------------------------
"HS80" | HMAC-SHA1 80 bit authentication "HS80" | HMAC-SHA1 80 bit authentication
| tag as defined in RFC 3711 | tag as defined in RFC 3711
--------------------------------------------------- ---------------------------------------------------
Table 4. Auth Tag Values Table 4. Auth Tag Values
6.1.5. Key Agreement Type Block 5.1.5. Key Agreement Type Block
All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and
MAY support EC25, EC38, and EC52. MAY support EC25, EC38, and EC52.
If a ZRTP endpoint supports multiple concurrent media streams, such If a ZRTP endpoint supports multiple concurrent media streams, such
as audio and video, it MUST support Multistream (Section 5.4.2) mode. as audio and video, it MUST support Multistream (Section 4.4.2) mode.
Also, if a ZRTP endpoint supports the GoClear message Also, if a ZRTP endpoint supports the GoClear message
(Section 5.7.2), it SHOULD support Multistream, to be used if the two (Section 4.7.2), it SHOULD support Multistream, to be used if the two
parties choose to return to the secure state after going Clear (as parties choose to return to the secure state after going Clear (as
explained in Section 5.7.2.1). explained in Section 4.7.2.1).
For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH
parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the
3072-bit MODP group. The DH generator g is 2. The random Diffie- 3072-bit MODP group. The DH generator g is 2. The random Diffie-
Hellman secret exponent SHOULD be twice as long as the AES key Hellman secret exponent SHOULD be twice as long as the AES key
length. If AES-128 is used, the DH secret value SHOULD be 256 bits length. If AES-128 is used, the DH secret value SHOULD be 256 bits
long. If AES-256 is used, the secret value SHOULD be 512 bits long. long. If AES-256 is used, the secret value SHOULD be 512 bits long.
If Elliptic Curve DH is used, the ECDH algorithm and key generation If Elliptic Curve DH is used, the ECDH algorithm and key generation
is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA
skipping to change at page 43, line 27 skipping to change at page 40, line 46
"EC25" | 16 | 37 | Elliptic Curve DH, P-256 "EC25" | 16 | 37 | Elliptic Curve DH, P-256
| | | per RFC 4753, section 3.1 | | | per RFC 4753, section 3.1
--------------------------------------------------- ---------------------------------------------------
"EC38" | 24 | 45 | Elliptic Curve DH, P-384 "EC38" | 24 | 45 | Elliptic Curve DH, P-384
| | | per RFC 4753, section 3.2 | | | per RFC 4753, section 3.2
--------------------------------------------------- ---------------------------------------------------
"EC52" | 33 | 54 | Elliptic Curve DH, P-521 "EC52" | 33 | 54 | Elliptic Curve DH, P-521
| | | per RFC 4753, section 3.3 | | | per RFC 4753, section 3.3
--------------------------------------------------- ---------------------------------------------------
Table 5. Key Agreement Block Type Values Table 5. Key Agreement Type Block Values
6.1.6. SAS Type Block 5.1.6. SAS Type Block
All ZRTP endpoints MUST support the base32 and MAY support base256 The SAS Type determines how the SAS is rendered to the user so that
Short Authentication String scheme, and other SAS rendering schemes. the user may verbally compare it with his partner over the voice
The ZRTP SAS is described in Section 8. channel. This allows detection of a man-in-the-middle (MiTM) attack.
All ZRTP endpoints MUST support the base32 and MAY support the
base256 rendering schemes for the Short Authentication String, and
other SAS rendering schemes. The ZRTP SAS rendering schemes are
described in Section 7.
SAS Type Block | Meaning SAS Type Block | Meaning
--------------------------------------------------- ---------------------------------------------------
"B32 " | Short Authentication String using "B32 " | Short Authentication String using
| base32 encoding defined in Section 8. | base32 encoding
--------------------------------------------------- ---------------------------------------------------
"B256" | Short Authentication String using "B256" | Short Authentication String using
| base256 encoding defined in Section 8. | base256 encoding (PGP Word List)
--------------------------------------------------- ---------------------------------------------------
Table 6. SAS Block Type Values Table 6. SAS Type Block Values
The SAS Type determines how the SAS is rendered to the user so that
the user may compare it with his partner over the voice channel.
This allows detection of a man-in-the-middle (MITM) attack.
6.1.7. Signature Type Block 5.1.7. Signature Type Block
The signature type block is a 4 octet (1 word) block used to The signature type block is a 4 octet (1 word) block used to
represent the signature algorithm discussed in Section 8.2. represent the signature algorithm discussed in Section 7.2.
Suggested signature algorithms and key lengths are a future subject Suggested signature algorithms and key lengths are a future subject
of standardization. of standardization.
6.2. Hello message 5.2. Hello message
The Hello message has the format shown in Figure 3. The Hello ZRTP The Hello message has the format shown in Figure 3. The Hello ZRTP
message begins with the preamble value 0x505a then a 16 bit length in message begins with the preamble value 0x505a then a 16 bit length in
32 bit words. This length includes only the ZRTP message (including 32 bit words. This length includes only the ZRTP message (including
the preamble and the length) but not the ZRTP header or CRC. the preamble and the length) but not the ZRTP header or CRC.
Next is the Message Type Block and a 4 character string containing Next is the Message Type Block and a 4 character string containing
the version (ver) of the ZRTP protocol, currently "0.95" (when this the version (ver) of the ZRTP protocol which is "1.00" for this
specification reaches RFC status, the protocol version will become specification. Next is the Client Identifier string (cid) which is 4
"1.00"). Next is the Client Identifier string (cid) which is 4 words words long and identifies the vendor and release of the ZRTP
long and identifies the vendor and release of the ZRTP software. The software. The 256-bit hash image H3 is defined in Section 9. The
256-bit hash image H3 is defined in Section 10. The next parameter next parameter is the ZID, the 96 bit long unique identifier for the
is the ZID, the 96 bit long unique identifier for the ZRTP endpoint. ZRTP endpoint.
The next four bits contains flag bits. The MiTM flag (M) is a The next four bits contains flag bits. The MiTM flag (M) is a
boolean that is set to true if and only if this Hello message is sent Boolean that is set to true if and only if this Hello message is sent
from a device, usually a PBX, that has the capability to send an from a device, usually a PBX, that has the capability to send an
SASrelay message (Section 6.13). The Passive flag (P) is a Boolean SASrelay message (Section 5.13). The Passive flag (P) is a Boolean
normally set to False. A ZRTP endpoint which is configured to never normally set to False. A ZRTP endpoint which is configured to never
initiate secure sessions is regarded as passive, and would set the P initiate secure sessions is regarded as passive, and would set the P
bit to True. The next 8 bits are unused. They should be set to zero bit to True. The next 8 bits are unused and SHOULD be set to zero
when sent and ignored on receipt. when sent and MUST be ignored on receipt.
Next is a list of supported Hash algorthms, Cipher algorithms, SRTP Next is a list of supported Hash algorithms, Cipher algorithms, SRTP
Auth Tag types, Key Agreement types, and SAS types. The number of Auth Tag types, Key Agreement types, and SAS types. The number of
listed algorithms are listed for each type: hc=hash count, cc=cipher listed algorithms are listed for each type: hc=hash count, cc=cipher
count, ac=auth tag count, kc=key agreement count, and sc=sas count. count, ac=auth tag count, kc=key agreement count, and sc=sas count.
The values for these algorithms are defined in Tables 2, 3, 4, 5, and The values for these algorithms are defined in Tables 2, 3, 4, 5, and
6. A count of zero means that only the mandatory to implement 6. A count of zero means that only the mandatory to implement
algorithms are supported. Mandatory algorithms MAY be included in algorithms are supported. Mandatory algorithms MAY be included in
the list. The order of the list indicates the preferences of the the list. The order of the list indicates the preferences of the
endpoint. If a mandatory algorithm is not included in the list, it endpoint. If a mandatory algorithm is not included in the list, it
is added to the end of the list for preference. is added to the end of the list for preference.
Note: Implementers are encouraged to keep these algorithm lists small Note: Implementers are encouraged to keep these algorithm lists
- the list does not need to include every cipher and hash supported, small - the list does not need to include every cipher and hash
just the ones the endpoint would prefer to use for this ZRTP supported, just the ones the endpoint would prefer to use for this
exchange. ZRTP exchange.
The 64-bit HMAC at the end of the message is computed across the The 64-bit HMAC at the end of the message is computed across the
whole message, not including the HMAC, of course. The HMAC key is whole message, not including the HMAC. The HMAC key is the sender's
the sender's H2 (defined in Section 10), and thus the HMAC cannot be H2 (defined in Section 9), and thus the HMAC cannot be checked by the
checked by the receiving party until the sender's H2 value is known receiving party until the sender's H2 value is known to the receiving
to the receiving party later in the protocol. party later in the protocol.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Hello " (2 words) | | Message Type Block="Hello " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="0.95" (1 word) | | version="1.00" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Client Identifier (4 words) | | Client Identifier (4 words) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Hash image H3 (8 words) | | Hash image H3 (8 words) |
| . . . | | . . . |
| | | |
skipping to change at page 45, line 49 skipping to change at page 43, line 45
| auth tag types (0 to 7 values) | | auth tag types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key agreement types (0 to 7 values) | | key agreement types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS types (0 to 7 values) | | SAS types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hello message format
Figure 3: Hello message format Figure 3: Hello message format
6.3. HelloACK message 5.3. HelloACK message
The HelloACK message is used to stop retransmissions of a Hello The HelloACK message is used to stop retransmissions of a Hello
message. A HelloACK is sent regardless if the version number in the message. A HelloACK is sent regardless if the version number in the
Hello is supported or the algorithm list supported. The receipt of a Hello is supported or the algorithm list supported. The receipt of a
HelloACK stops retransmission of the Hello message. The format is HelloACK stops retransmission of the Hello message. The format is
shown in the Figure below. Note that a Commit message can be sent in shown in the Figure below. Note that a Commit message can be sent in
place of a HelloACK by an Initiator. place of a HelloACK by an Initiator.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="HelloACK" (2 words) | | Message Type Block="HelloACK" (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloACK message format
Figure 4: HelloACK message format Figure 4: HelloACK message format
6.4. Commit message 5.4. Commit message
The Commit message is sent to initiate the key agreement process The Commit message is sent to initiate the key agreement process
after both sides have received a Hello message, which means it can after both sides have received a Hello message, which means it can
only be sent after receiving both a Hello message and a HelloACK only be sent after receiving both a Hello message and a HelloACK
message. The Commit message contains the Initiator's ZID and a list message. There are three subtypes of Commit messages, whose formats
of selected algorithms (hash, cipher, auth tag type, key agreement, are shown in Figure 5, Figure 6, and Figure 7.
sas type), and hvi, which is a hash of the DHPart2 of the Initiator
and the Responder's Hello message, as explained in Section 5.4.1.1. The Commit message contains the Message Type Block, then the 256-bit
The hash image H2 is defined in Section 10. The Commit Message hash image H2 which is defined in Section 9. The next parameter is
formats are shown in Figure 5, Figure 6, and Figure 7. the initiator's ZID, the 96 bit long unique identifier for the ZRTP
endpoint.
Next is a list of algorithms selected by the initiator (hash, cipher,
auth tag type, key agreement, sas type). For a DH Commit, the hash
value hvi is a hash of the DHPart2 of the Initiator and the
Responder's Hello message, as explained in Section 4.4.1.1.
The 64-bit HMAC at the end of the message is computed across the The 64-bit HMAC at the end of the message is computed across the
whole message, not including the HMAC, of course. The HMAC key is whole message, not including the HMAC. The HMAC key is the sender's
the sender's H1 (defined in Section 10), and thus the HMAC cannot be H1 (defined in Section 9), and thus the HMAC cannot be checked by the
checked by the receiving party until the sender's H1 value is known receiving party until the sender's H1 value is known to the receiving
to the receiving party later in the protocol. party later in the protocol.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) | | Message Type Block="Commit " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 47, line 41 skipping to change at page 45, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| hvi (8 words) | | hvi (8 words) |
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DH Commit message format
Figure 5: DH Commit message format Figure 5: DH Commit message format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) | | Message Type Block="Commit " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 41 skipping to change at page 46, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| nonce (4 words) | | nonce (4 words) |
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multistream Commit message format
Figure 6: Multistream Commit message format Figure 6: Multistream Commit message format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) | | Message Type Block="Commit " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 44 skipping to change at page 47, line 44
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyID (2 words) | | keyID (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preshared Commit message format
Figure 7: Preshared Commit message format Figure 7: Preshared Commit message format
6.5. DHPart1 message 5.5. DHPart1 message
The DHPart1 message begins the DH exchange. The format is shown in The DHPart1 message begins the DH exchange. The format is shown in
Figure 8 below. The DHPart1 message is sent by the Responder if a Figure 8 below. The DHPart1 message is sent by the Responder if a
valid Commit message is received from the Initiator. The length of valid Commit message is received from the Initiator. The length of
the pvr value and the length of the DHPart1 message depends on the the pvr value and the length of the DHPart1 message depends on the
Key Agreement Type chosen. This information is contained in Table 5. Key Agreement Type chosen. This information is contained in Table 5.
Note that for both Multistream and Preshared modes, no DHPart1 or Note that for both Multistream and Preshared modes, no DHPart1 or
DHPart2 message will be sent. DHPart2 message will be sent.
The 256-bit hash image H1 is defined in Section 10. The 256-bit hash image H1 is defined in Section 9.
The next four parameters are HMACs of potential shared secrets used The next four parameters are HMACs of potential shared secrets used
in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are
the HMACs of the responder's two retained shared secrets, truncated the HMACs of the responder's two retained shared secrets, truncated
to 64 bits. Next is auxsecretIDr, the HMAC of the responder's to 64 bits. Next is auxsecretIDr, the HMAC of the responder's
auxsecret (defined in Section 5.3), truncated to 64 bits. The last auxsecret (defined in Section 4.3), truncated to 64 bits. The last
parameter is the HMAC of the trusted MiTM PBX shared secret parameter is the HMAC of the trusted MiTM PBX shared secret
pbxsecret, defined in Section 8.3.1. The Message format for the pbxsecret, defined in Section 7.3.1. The Message format for the
DHPart1 message is shown in Figure 8. DHPart1 message is shown in Figure 8.
The 64-bit HMAC at the end of the message is computed across the The 64-bit HMAC at the end of the message is computed across the
whole message, not including the HMAC, of course. The HMAC key is whole message, not including the HMAC. The HMAC key is the sender's
the sender's H0 (defined in Section 10), and thus the HMAC cannot be H0 (defined in Section 9), and thus the HMAC cannot be checked by the
checked by the receiving party until the sender's H0 value is known receiving party until the sender's H0 value is known to the receiving
to the receiving party later in the protocol. party later in the protocol.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart1 " (2 words) | | Message Type Block="DHPart1 " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 51, line 39 skipping to change at page 49, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| pvr (length depends on KA Type) | | pvr (length depends on KA Type) |
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHPart1 message format Figure 8: DHPart1 message format
Figure 8: DH Part1 message format
6.6. DHPart2 message 5.6. DHPart2 message
The DHPart2 message completes the DH exchange. A DHPart2 message is The DHPart2 message completes the DH exchange. A DHPart2 message is
sent by the Initiator if a valid DHPart1 message is received from the sent by the Initiator if a valid DHPart1 message is received from the
Responder. The length of the pvr value and the length of the DHPart2 Responder. The length of the pvr value and the length of the DHPart2
message depends on the Key Agreement Type chosen. This information message depends on the Key Agreement Type chosen. This information
is contained in Table 5. Note that for both Multistream and is contained in Table 5. Note that for both Multistream and
Preshared modes, no DHPart1 or DHPart2 message will be sent. Preshared modes, no DHPart1 or DHPart2 message will be sent.
The 256-bit hash image H1 is defined in Section 10. The 256-bit hash image H1 is defined in Section 9.
The next four parameters are HMACs of potential shared secrets used The next four parameters are HMACs of potential shared secrets used
in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are
the HMACs of the initiator's two retained shared secrets, truncated the HMACs of the initiator's two retained shared secrets, truncated
to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's
auxsecret (defined in Section 5.3), truncated to 64 bits. The last auxsecret (defined in Section 4.3), truncated to 64 bits. The last
parameter is the HMAC of the trusted MiTM PBX shared secret parameter is the HMAC of the trusted MiTM PBX shared secret
pbxsecret, defined in Section 8.3.1. The message format for the pbxsecret, defined in Section 7.3.1. The message format for the
DHPart2 message is shown in Figure 9. DHPart2 message is shown in Figure 9.
The 64-bit HMAC at the end of the message is computed across the The 64-bit HMAC at the end of the message is computed across the
whole message, not including the HMAC, of course. The HMAC key is whole message, not including the HMAC. The HMAC key is the sender's
the sender's H0 (defined in Section 10), and thus the HMAC cannot be H0 (defined in Section 9), and thus the HMAC cannot be checked by the
checked by the receiving party until the sender's H0 value is known receiving party until the sender's H0 value is known to the receiving
to the receiving party later in the protocol. party later in the protocol.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart2 " (2 words) | | Message Type Block="DHPart2 " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 53, line 38 skipping to change at page 51, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| pvi (length depends on KA Type) | | pvi (length depends on KA Type) |
| . . . | | . . . |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) | | HMAC (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: DHPart2 message format
DHPart2 message format 5.7. Confirm1 and Confirm2 messages
Figure 9: DH Part2 message format
6.7. Confirm1 and Confirm2 messages
The Confirm1 message is sent by the Responder in response to a valid The Confirm1 message is sent by the Responder in response to a valid
DHPart2 message after the SRTP session key and parameters have been DHPart2 message after the SRTP session key and parameters have been
negotiated. The Confirm2 message is sent by the Initiator in negotiated. The Confirm2 message is sent by the Initiator in
response to a Confirm1 message. The format is shown in Figure 10 response to a Confirm1 message. The format is shown in Figure 10
below. The message contains the Message Type Block "Confirm1" or below. The message contains the Message Type Block "Confirm1" or
"Confirm2". Next is the HMAC, a keyed hash over encrypted part of "Confirm2". Next is the HMAC, a keyed hash over encrypted part of
the message (shown enclosed by "===" in Figure 10). This HMAC is the message (shown enclosed by "===" in Figure 10). This HMAC is
keyed and computed according to Section 5.6. The next 16 octets keyed and computed according to Section 4.6. The next 16 octets
contain the CFB Initialization Vector. The rest of the message is contain the CFB Initialization Vector. The rest of the message is
encrypted using CFB and protected by the HMAC. encrypted using CFB and protected by the HMAC.
The first field inside the encrypted region is the hash pre-image H0, The first field inside the encrypted region is the hash pre-image H0,
which is defined in detail in Section 10. which is defined in detail in Section 9.
The next 15 bits are not used. They SHOULD be set to zero and MUST The next 15 bits are not used and SHOULD be set to zero when sent and
be ignored in received Confirm1 or Confirm2 messages. MUST be ignored when received in Confirm1 or Confirm2 messages.
The next 9 bits contain the signature length. If no SAS signature The next 9 bits contain the signature length. If no SAS signature
(described in Section 8.2) is present, all bits are set to zero. The (described in Section 7.2) is present, all bits are set to zero. The
signature length is in words and includes the signature type block. signature length is in words and includes the signature type block.
If the calculated signature octet count is not a multiple of 4, zeros If the calculated signature octet count is not a multiple of 4, zeros
are added to pad it out to a word boundary. If no signature block is are added to pad it out to a word boundary. If no signature block is
present, the overall length of the Confirm1 or Confirm2 Message will present, the overall length of the Confirm1 or Confirm2 Message will
be set to 19 words. be set to 19 words.
The next 8 bits are used for flags. Undefined flags are set to zero The next 8 bits are used for flags. Undefined flags are set to zero
and ignored. Four flags are currently defined. The PBX Enrollment and ignored. Four flags are currently defined. The PBX Enrollment
flag (E) is a Boolean bit defined in Section 8.3.1. The SAS Verified flag (E) is a Boolean bit defined in Section 7.3.1. The SAS Verified
flag (V) is a Boolean bit defined in Section 8.1. The Allow Clear flag (V) is a Boolean bit defined in Section 7.1. The Allow Clear
flag (A) is a Boolean bit defined in Section 5.7.2. The Disclosure flag (A) is a Boolean bit defined in Section 4.7.2. The Disclosure
Flag (D) is a Boolean bit defined in Section 12. The cache Flag (D) is a Boolean bit defined in Section 11. The cache
expiration interval is defined in Section 5.9. expiration interval is defined in Section 4.9.
If the signature length (in words) is non-zero, a signature type If the signature length (in words) is non-zero, a signature type
block will be present along with a signature block. Next is the block will be present along with a signature block. Next is the
signature block. The signature block includes the key used to signature block. The signature block includes the key used to
generate the signature (Section 8.2). generate the signature (Section 7.2).
CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a
full cipher block, and the final block is truncated to match the full cipher block, and the final block is truncated to match the
exact length of the encrypted data. The CFB Initialization Vector is exact length of the encrypted data. The CFB Initialization Vector is
a 128 bit random nonce. The block cipher algorithm and the key size a 128 bit random nonce. The block cipher algorithm and the key size
is the same as what was negotiated for the media encryption. CFB is is the same as what was negotiated for the media encryption. CFB is
used to encrypt the part of the Confirm1 message beginning after the used to encrypt the part of the Confirm1 message beginning after the
CFB IV to the end of the message (the encrypted region is enclosed by CFB IV to the end of the message (the encrypted region is enclosed by
"======" in Figure 10). "======" in Figure 10).
skipping to change at page 55, line 39 skipping to change at page 52, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) | | optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| optional signature block (variable length) | | optional signature block (variable length) |
| . . . | | . . . |
| | | |
| | | |
+===============================================================+ +===============================================================+
Confirm1 and Confirm2 message format
Figure 10: Confirm1 and Confirm2 message format Figure 10: Confirm1 and Confirm2 message format
6.8. Conf2ACK message 5.8. Conf2ACK message
The Conf2ACK message is sent by the Responder in response to a valid The Conf2ACK message is sent by the Responder in response to a valid
Confirm2 message. The message format for the Conf2ACK is shown in Confirm2 message. The message format for the Conf2ACK is shown in
the Figure below. The receipt of a Conf2ACK stops retransmission of the Figure below. The receipt of a Conf2ACK stops retransmission of
the Confirm2 message. the Confirm2 message. Note that the first SRTP media (with a valid
SRTP auth tag) from the responder also stops retransmission of the
Confirm2 message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Conf2ACK" (2 words) | | Message Type Block="Conf2ACK" (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Conf2ACK message format
Figure 11: Conf2ACK message format Figure 11: Conf2ACK message format
6.9. Error message 5.9. Error message
The Error message is sent to terminate an in-process ZRTP key The Error message is sent to terminate an in-process ZRTP key
agreement exchange due to an error. The format is shown in the agreement exchange due to an error. The format is shown in the
Figure below. The use of the Error message is described in Figure below. The use of the Error message is described in
Section 5.7.1. Section 4.7.1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Error " (2 words) | | Message Type Block="Error " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Error Code (1 word) | | Integer Error Code (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error message format
Figure 12: Error message format Figure 12: Error message format
Defined hexadecimal values for the Error Code are listed in Table 7. Defined hexadecimal values for the Error Code are listed in Table 7.
Error Code | Meaning Error Code | Meaning
----------------------------------------------------------- -----------------------------------------------------------
0x10 | Malformed packet (CRC OK, but wrong structure) 0x10 | Malformed packet (CRC OK, but wrong structure)
----------------------------------------------------------- -----------------------------------------------------------
0x20 | Critical software error 0x20 | Critical software error
----------------------------------------------------------- -----------------------------------------------------------
skipping to change at page 57, line 39 skipping to change at page 54, line 39
0x62 | DH Error: hvi != hashed data 0x62 | DH Error: hvi != hashed data
----------------------------------------------------------- -----------------------------------------------------------
0x63 | Received relayed SAS from untrusted MiTM 0x63 | Received relayed SAS from untrusted MiTM
----------------------------------------------------------- -----------------------------------------------------------
0x70 | Auth. Error: Bad Confirm pkt HMAC 0x70 | Auth. Error: Bad Confirm pkt HMAC
----------------------------------------------------------- -----------------------------------------------------------
0x80 | Nonce reuse 0x80 | Nonce reuse
----------------------------------------------------------- -----------------------------------------------------------
0x90 | Equal ZIDs in Hello 0x90 | Equal ZIDs in Hello
----------------------------------------------------------- -----------------------------------------------------------
0xA0 | Service unavailable
-----------------------------------------------------------
0x100 | GoClear packet received, but not allowed 0x100 | GoClear packet received, but not allowed
----------------------------------------------------------- -----------------------------------------------------------
Table 7. ZRTP Error Codes Table 7. ZRTP Error Codes
6.10. ErrorACK message 5.10. ErrorACK message
The ErrorACK message is sent in response to an Error message. The The ErrorACK message is sent in response to an Error message. The
receipt of an ErrorACK stops retransmission of the Error message. receipt of an ErrorACK stops retransmission of the Error message.
The format is shown in the Figure below. The format is shown in the Figure below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ErrorACK" (2 words) | | Message Type Block="ErrorACK" (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ErrorACK message format
Figure 13: ErrorAck message format Figure 13: ErrorAck message format
6.11. GoClear message 5.11. GoClear message
Support for the GoClear message is OPTIONAL in the protocol, and it Support for the GoClear message is OPTIONAL in the protocol, and it
is sent to switch from SRTP to RTP. The format is shown in the is sent to switch from SRTP to RTP. The format is shown in the
Figure below. The clear_hmac is used to authenticate the GoClear Figure below. The clear_hmac is used to authenticate the GoClear
message so that bogus GoClear messages introduced by an attacker can message so that bogus GoClear messages introduced by an attacker can
be detected and discarded. The use of GoClear is described in be detected and discarded. The use of GoClear is described in
Section 5.7.2. Section 4.7.2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="GoClear " (2 words) | | Message Type Block="GoClear " (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clear_hmac (2 words) | | clear_hmac (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GoClear message format
Figure 14: GoClear message format Figure 14: GoClear message format
6.12. ClearACK message 5.12. ClearACK message
Support for the ClearACK message is OPTIONAL in the protocol, and it Support for the ClearACK message is OPTIONAL in the protocol, and it
is sent to acknowledge receipt of a GoClear. A ClearACK is only sent is sent to acknowledge receipt of a GoClear. A ClearACK is only sent
if the clear_hmac from the GoClear message is authenticated. if the clear_hmac from the GoClear message is authenticated.
Otherwise, no response is returned. The format is shown in the Otherwise, no response is returned. The format is shown in the
Figure below. Figure below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) | | Message Type Block="ClearACK" (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ClearACK message format
Figure 15: ClearAck message format Figure 15: ClearAck message format
6.13. SASrelay message 5.13. SASrelay message
The SASrelay message is sent by a trusted Man in The Middle (MiTM), The SASrelay message is sent by a trusted Man in The Middle (MiTM),
most often a PBX. It is not sent as a response to a packet, but is most often a PBX. It is not sent as a response to a packet, but is
sent as a self-initiated packet by the trusted MiTM. It can only be sent as a self-initiated packet by the trusted MiTM. It can only be
sent after the rest of the ZRTP key negotiations have completed, sent after the rest of the ZRTP key negotiations have completed,
after the Confirm packets and their ACKs. It can only be sent after after the Confirm packets and their ACKs. It can only be sent after
the trusted MiTM has finished key negotiations with the other party, the trusted MiTM has finished key negotiations with the other party,
because it is the other party's SAS that is being relayed. It is because it is the other party's SAS that is being relayed. It is
sent with retry logic until a RelayACK message (Section 6.14) is sent with retry logic until a RelayACK message (Section 5.14) is
received or the retry schedule has been exhausted. received or the retry schedule has been exhausted.
If a device, usually a PBX, sends an SASrelay message, it MUST have If a device, usually a PBX, sends an SASrelay message, it MUST have
previously declared itself as a MiTM device by setting the MiTM (M) previously declared itself as a MiTM device by setting the MiTM (M)
flag in the Hello message (Section 6.2). If the receiver of the flag in the Hello message (Section 5.2). If the receiver of the
SASrelay message did not previously receive a Hello message with the SASrelay message did not previously receive a Hello message with the
MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A
RelayACK is still sent, but no Error message is sent. RelayACK is still sent, but no Error message is sent.
The SASrelay message format is shown in Figure 16 below. The message The SASrelay message format is shown in Figure 16 below. The message
contains the Message Type Block "SASrelay". Next is the HMAC, a contains the Message Type Block "SASrelay". Next is the HMAC, a
keyed hash over encrypted part of the message (shown enclosed by keyed hash over encrypted part of the message (shown enclosed by
"===" in Figure 16). This HMAC is keyed the same way as the HMAC in "===" in Figure 16). This HMAC is keyed the same way as the HMAC in
the Confirm messages (see Section 5.6). The next 16 octets contain the Confirm messages (see Section 4.6). The next 16 octets contain
the CFB Initialization Vector. The rest of the message is encrypted the CFB Initialization Vector. The rest of the message is encrypted
using CFB and protected by the HMAC. using CFB and protected by the HMAC.
The next 15 bits are not used. They SHOULD be set to zero and MUST The next 15 bits are not used and SHOULD be set to zero when sent and
be ignored in received SASrelay messages. MUST be ignored when received in SASrelay messages.
The next 9 bits contain the signature length. The trusted MiTM MAY The next 9 bits contain the signature length. The trusted MiTM MAY
compute a digital signature on the SAS hash, as described in compute a digital signature on the SAS hash, as described in
Section 8.2, using a persistant signing key owned by the trusted Section 7.2, using a persistant signing key owned by the trusted
MiTM. If no SAS signature is present, all bits are set to zero. The MiTM. If no SAS signature is present, all bits are set to zero. The
signature length is in words and includes the signature type block. signature length is in words and includes the signature type block.
If the calculated signature octet count is not a multiple of 4, zeros If the calculated signature octet count is not a multiple of 4, zeros
are added to pad it out to a word boundary. If no signature block is are added to pad it out to a word boundary. If no signature block is
present, the overall length of the SASrelay Message will be set to 12 present, the overall length of the SASrelay Message will be set to 12
words. words.
The next 8 bits are used for flags. Undefined flags are set to zero The next 8 bits are used for flags. Undefined flags are set to zero
and ignored. Three flags are currently defined. The Disclosure Flag and ignored. Three flags are currently defined. The Disclosure Flag
(D) is a Boolean bit defined in Section 12. The Allow Clear flag (A) (D) is a Boolean bit defined in Section 11. The Allow Clear flag (A)
is a Boolean bit defined in Section 5.7.2. The SAS Verified flag (V) is a Boolean bit defined in Section 4.7.2. The SAS Verified flag (V)
is a Boolean bit defined in Section 8.1. These flags are updated is a Boolean bit defined in Section 7.1. These flags are updated
values to the same flags provided earlier in the Confirm packet, but values to the same flags provided earlier in the Confirm packet, but
they are updated to reflect the new flag information relayed by the they are updated to reflect the new flag information relayed by the
PBX from the other party. PBX from the other party.
The next 32 bit word contains the rendering scheme for the relayed The next 32 bit word contains the rendering scheme for the relayed
sasvalue, which will be the same rendering scheme used by the other sasvalue, which will be the same rendering scheme used by the other
party on the other side of the trusted MiTM. Section 8.3 describes party on the other side of the trusted MiTM. Section 7.3 describes
how the PBX determines whether the ZRTP client regards the PBX as a how the PBX determines whether the ZRTP client regards the PBX as a
trusted MiTM. If the PBX determines that the ZRTP client trusts the trusted MiTM. If the PBX determines that the ZRTP client trusts the
PBX, the next 32 bit word contains the binary sasvalue relayed from PBX, the next 32 bit word contains the binary sasvalue relayed from
the other party. If this SASrelay packet is being sent to a ZRTP the other party. If this SASrelay packet is being sent to a ZRTP
client that does not trust this MiTM, the next 32 bit word will be client that does not trust this MiTM, the next 32 bit word will be
ignored by the recipient and should be set to zero by the PBX. ignored by the recipient and should be set to zero by the PBX.
If the signature length (in words) is non-zero, a signature type If the signature length (in words) is non-zero, a signature type
block will be present along with a signature block. Next is the block will be present along with a signature block. Next is the
signature block. The signature block includes the key used to signature block. The signature block includes the key used to
generate the signature (Section 8.2). generate the signature (Section 7.2).
CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a
full cipher block, and the final block is truncated to match the full cipher block, and the final block is truncated to match the
exact length of the encrypted data. The CFB Initialization Vector is exact length of the encrypted data. The CFB Initialization Vector is
a 128 bit random nonce. The block cipher algorithm and the key size a 128 bit random nonce. The block cipher algorithm and the key size
is the same as what was negotiated for the media encryption. CFB is is the same as what was negotiated for the media encryption. CFB is
used to encrypt the part of the SASrelay message beginning after the used to encrypt the part of the SASrelay message beginning after the
CFB IV to the end of the message (the encrypted region is enclosed by CFB IV to the end of the message (the encrypted region is enclosed by
"======" in Figure 16). "======" in Figure 16).
skipping to change at page 61, line 25 skipping to change at page 58, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| CFB Initialization Vector (4 words) | | CFB Initialization Vector (4 words) |
| | | |
| | | |
+===============================================================+ +===============================================================+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D| | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rendering scheme of relayed sasvalue (1 word) | | rendering scheme of relayed sasvalue (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted MITM relayed sasvalue (1 word) | | Trusted MiTM relayed sasvalue (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) | | optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| optional signature block (variable length) | | optional signature block (variable length) |
| . . . | | . . . |
| | | |
| | | |
+===============================================================+ +===============================================================+
SASrelay message format
Figure 16: SASrelay message format Figure 16: SASrelay message format
6.14. RelayACK message 5.14. RelayACK message
The RelayACK message is sent in response to a valid SASrelay message. The RelayACK message is sent in response to a valid SASrelay message.
The message format for the RelayACK is shown in the Figure below. The message format for the RelayACK is shown in the Figure below.
The receipt of a RelayACK stops retransmission of the SASrelay The receipt of a RelayACK stops retransmission of the SASrelay
message. message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="RelayACK" (2 words) | | Message Type Block="RelayACK" (2 words) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RelayACK message format
Figure 17: RelayACK message format Figure 17: RelayACK message format
7. Retransmissions 6. Retransmissions
ZRTP uses two retransmission timers T1 and T2. T1 is used for ZRTP uses two retransmission timers T1 and T2. T1 is used for
retransmission of Hello messages, when the support of ZRTP by the retransmission of Hello messages, when the support of ZRTP by the
other endpoint may not be known. T2 is used in retransmissions of other endpoint may not be known. T2 is used in retransmissions of
all the other ZRTP messages. all the other ZRTP messages.
All message retransmissions MUST be identical to the initial message All message retransmissions MUST be identical to the initial message
including nonces, public values, etc; otherwise, hashes of the including nonces, public values, etc; otherwise, hashes of the
message sequences may not agree. message sequences may not agree.
skipping to change at page 62, line 51 skipping to change at page 59, line 49
T1 seconds and doubles after every retransmission, capping at 200ms. T1 seconds and doubles after every retransmission, capping at 200ms.
T1 has a recommended initial value of 50 ms. A Hello message is T1 has a recommended initial value of 50 ms. A Hello message is
retransmitted 20 times before giving up, which means the entire retry retransmitted 20 times before giving up, which means the entire retry
schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 schedule for Hello messages is exhausted after 3.75 seconds (50 + 100
+ 18*200 ms). Retransmission of a Hello ends upon receipt of a + 18*200 ms). Retransmission of a Hello ends upon receipt of a
HelloACK or Commit message. HelloACK or Commit message.
The post-Hello ZRTP messages are retransmitted only by the session The post-Hello ZRTP messages are retransmitted only by the session
initiator - that is, only Commit, DHPart2, and Confirm2 are initiator - that is, only Commit, DHPart2, and Confirm2 are
retransmitted if the corresponding message from the responder, retransmitted if the corresponding message from the responder,
DHPart1, Confirm1, and Conf2ACK, are not received. DHPart1, Confirm1, and Conf2ACK, are not received. Note that the
Confirm2 message retransmission can also be stopped by receiving the
first SRTP media (with a valid SRTP auth tag) from the responder.
The GoClear, Error, and SASrelay messages may be initiated and The GoClear, Error, and SASrelay messages may be initiated and
retransmitted by either party, and responded to by the other party, retransmitted by either party, and responded to by the other party,
regardless of which party is the overall session initiator. They are regardless of which party is the overall session initiator. They are
retransmitted if the corresponding response message ClearACK, retransmitted if the corresponding response message ClearACK,
ErrorACK, and RelayACK, are not received. ErrorACK, and RelayACK, are not received.
Non-Hello ZRTP messages are retransmitted at an interval that starts Non-Hello ZRTP messages are retransmitted at an interval that starts
at T2 seconds and doubles after every retransmission, capping at at T2 seconds and doubles after every retransmission, capping at
600ms. T2 has a recommended initial value of 150 ms. Each non-Hello 600ms. T2 has a recommended initial value of 150 ms. Each non-Hello
message is retransmitted 10 times before giving up, which means the message is retransmitted 10 times before giving up, which means the
entire retry schedule is exhausted after 5.25 seconds (150 + 300 + entire retry schedule is exhausted after 5.25 seconds (150 + 300 +
8*600 ms). Only the initiator performs retransmissions. Each 8*600 ms). Only the initiator performs retransmissions. Each
message has a response message that stops retransmissions, as shown message has a response message that stops retransmissions, as shown
below in Table 8. The higher values of T2 means that retransmissions below in Table 8. The higher values of T2 means that retransmissions
will likely only occur with packet loss. will likely only occur with packet loss.
These recommended retransmission intervals are designed for a typical These recommended retransmission intervals are designed for a typical
broadband Internet connection. In some low bandwidth communication broadband Internet connection. In some high latency communication
channels, such as those provided by some mobile phone environments, channels, such as those provided by some mobile phone environments or
the initial value for the T1 or T2 retransmission timer should be geostationary satellites, the initial value for the T1 or T2
increased to be no less than the round trip time provided by the retransmission timer should be increased to be no less than the round
communications channel. It should take into account the time trip time provided by the communications channel. It should take
required to transmit the entire message and the entire reply. into account the time required to transmit the entire message and the
entire reply.
Message Acknowledgement Message Message Acknowledgement Message
------- ----------------------- ------- -----------------------
Hello HelloACK or Commit Hello HelloACK or Commit
Commit DHPart1 or Confirm1 Commit DHPart1 or Confirm1
DHPart2 Confirm1 DHPart2 Confirm1
Confirm2 Conf2ACK Confirm2 Conf2ACK or SRTP media
GoClear ClearACK GoClear ClearACK
Error ErrorACK Error ErrorACK
SASrelay RelayACK SASrelay RelayACK
Table 8. Retransmitted ZRTP Messages and Responses Table 8. Retransmitted ZRTP Messages and Responses
8. Short Authentication String 7. Short Authentication String
This section will discuss the implementation of the Short This section will discuss the implementation of the Short
Authentication String, or SAS in ZRTP. The SAS can be verbally Authentication String, or SAS in ZRTP. The SAS can be verbally
verified by the human users reading the string aloud, or by verified by the human users reading the string aloud, or by
validating an OPTIONAL digital signature (described in Section 8.2) validating an OPTIONAL digital signature (described in Section 7.2)
exchanged in the Confirm1 or Confirm2 messages. exchanged in the Confirm1 or Confirm2 messages.
The use of hash commitment in the DH exchange (Section 5.4.1.1) The use of hash commitment in the DH exchange (Section 4.4.1.1)
constrains the attacker to only one guess to generate the correct SAS constrains the attacker to only one guess to generate the correct SAS
in his attack, which means the SAS can be quite short. A 16-bit SAS, in his attack, which means the SAS can be quite short. A 16-bit SAS,
for example, provides the attacker only one chance out of 65536 of for example, provides the attacker only one chance out of 65536 of
not being detected. not being detected.
The rendering of the SAS value to the user depends on the SAS Type The rendering of the SAS value to the user depends on the SAS Type
agreed upon in the Commit message. For the SAS Type of base32, the agreed upon in the Commit message. For the SAS Type of base32, the
leftmost 20 bits of the 32-bit sasvalue are rendered as a form of leftmost 20 bits of the 32-bit sasvalue are rendered as a form of
base32 encoding known as z-base-32 [z-base-32]. The purpose of base32 encoding known as z-base-32 [z-base-32]. The purpose of
z-base-32 is to represent arbitrary sequences of octets in a form z-base-32 is to represent arbitrary sequences of octets in a form
that is as convenient as possible for human users to manipulate. As that is as convenient as possible for human users to manipulate. As
a result, the choice of characters is slightly different from base32 a result, the choice of characters is slightly different from base32
as defined in RFC 3548. The leftmost 20 bits of the sasvalue results as defined in RFC 3548. The leftmost 20 bits of the sasvalue results
in four base32 characters which are rendered to both ZRTP endpoints. in four base32 characters which are rendered to both ZRTP endpoints.
For the SAS Type of base256, the leftmost 16 bits of the 32-bit For the SAS Type of base256, the leftmost 16 bits of the 32-bit
sasvalue are rendered using the PGP Wordlist [pgpwordlist] sasvalue are rendered using the PGP Wordlist [pgpwordlist]
[Juola1][Juola2]. Other SAS Types may be defined to render the SAS [Juola1][Juola2]. Other SAS Types may be defined to render the SAS
value in other ways. value in other ways.
The SAS SHOULD be rendered to the user for authentication. In The SAS SHOULD be rendered to the user for authentication.
addition, the SAS SHOULD be sent in a subsequent offer/answer
exchange (a re-INVITE in SIP) after the completion of ZRTP exchange
using the ZRTP SAS SDP attributes defined in Section 9.
The SAS is not treated as a secret value, but it must be compared to The SAS is not treated as a secret value, but it must be compared to
see if it matches at both ends of the communications channel. The see if it matches at both ends of the communications channel. The
two users read it aloud to their partners to see if it matches. This two users read it aloud to their partners to see if it matches. This
allows detection of a man-in-the-middle (MITM) attack. allows detection of a man-in-the-middle (MiTM) attack.
There is only one SAS value computed per call. That is the SAS value There is only one SAS value computed per call. That is the SAS value
for the first media stream established, which computes the ZRTPSess for the first media stream established, which computes the ZRTPSess
key, using DH mode. The ZRTPSess key is used to compute the SAS, as key, using DH mode. The ZRTPSess key is used to compute the SAS, as
well as the SRTP session keys for each additional media stream in well as the SRTP session keys for each additional media stream in
Multistream mode. This SAS applies to all media streams for the same Multistream mode. This SAS applies to all media streams for the same
call. call.
8.1. SAS Verified Flag 7.1. SAS Verified Flag
The SAS Verified flag (V) is set based on the user indicating that The SAS Verified flag (V) is set based on the user indicating that
SAS comparison has been successfully performed. The SAS Verified SAS comparison has been successfully performed. The SAS Verified
flag is exchanged securely in the Confirm1 and Confirm2 messages flag is exchanged securely in the Confirm1 and Confirm2 messages
(Figure 10) of the next session. In other words, each party sends (Figure 10) of the next session. In other words, each party sends
the SAS Verified flag from the previous session in the Confirm the SAS Verified flag from the previous session in the Confirm
message of the current session. It is perfectly reasonable to have a message of the current session. It is perfectly reasonable to have a
ZRTP endpoint that never sets the SAS Verified flag, because it would ZRTP endpoint that never sets the SAS Verified flag, because it would
require adding complexity to the user interface to allow the user to require adding complexity to the user interface to allow the user to
set it. The SAS Verified flag is not required to be set, but if it set it. The SAS Verified flag is not required to be set, but if it
skipping to change at page 65, line 12 skipping to change at page 62, line 10
that the client software could render to the user that the SAS verify that the client software could render to the user that the SAS verify
procedure was carried out in a previous session. procedure was carried out in a previous session.
Regardless of whether there is a user interface element to allow the Regardless of whether there is a user interface element to allow the
user to set the SAS Verified flag, it is worth caching a shared user to set the SAS Verified flag, it is worth caching a shared
secret, because doing so reduces opportunities for an attacker in the secret, because doing so reduces opportunities for an attacker in the
next call. next call.
If at any time the users carry out the SAS comparison procedure, and If at any time the users carry out the SAS comparison procedure, and
it actually fails to match, then this means there is a very it actually fails to match, then this means there is a very
resourceful man-in-the-middle. If this is the first call, the MITM resourceful man-in-the-middle. If this is the first call, the MiTM
was there on the first call, which is impressive enough. If it was there on the first call, which is impressive enough. If it
happens in a later call, it also means the MITM must also know the happens in a later call, it also means the MiTM must also know the
cached shared secret, because you could not have carried out any cached shared secret, because you could not have carried out any
voice traffic at all unless the session key was correctly computed voice traffic at all unless the session key was correctly computed
and is also known to the attacker. This implies the MITM must have and is also known to the attacker. This implies the MiTM must have
been present in all the previous sessions, since the initial been present in all the previous sessions, since the initial
establishment of the first shared secret. This is indeed a establishment of the first shared secret. This is indeed a
resourceful attacker. It also means that if at any time he ceases resourceful attacker. It also means that if at any time he ceases
his participation as a MITM on one of your calls, the protocol will his participation as a MiTM on one of your calls, the protocol will
detect that the cached shared secret is no longer valid -- because it detect that the cached shared secret is no longer valid -- because it
was really two different shared secrets all along, one of them was really two different shared secrets all along, one of them
between Alice and the attacker, and the other between the attacker between Alice and the attacker, and the other between the attacker
and Bob. The continuity of the cached shared secrets make it possible and Bob. The continuity of the cached shared secrets make it possible
for us to detect the MITM when he inserts himself into the ongoing for us to detect the MiTM when he inserts himself into the ongoing
relationship, as well as when he leaves. Also, if the attacker tries relationship, as well as when he leaves. Also, if the attacker tries
to stay with a long lineage of calls, but fails to execute a DH MITM to stay with a long lineage of calls, but fails to execute a DH MiTM
attack for even one missed call, he is permanently excluded. He can attack for even one missed call, he is permanently excluded. He can
no longer resynchronize with the chain of cached shared secrets. no longer resynchronize with the chain of cached shared secrets.
Some sort of user interface element (maybe a checkbox) is needed to Some sort of user interface element (maybe a checkbox) is needed to
allow the user to tell the software the SAS verify was successful, allow the user to tell the software the SAS verify was successful,
causing the software to set the SAS Verified flag (V), which causing the software to set the SAS Verified flag (V), which
(together with our cached shared secret) obviates the need to perform (together with our cached shared secret) obviates the need to perform
the SAS procedure in the next call. An additional user interface the SAS procedure in the next call. An additional user interface
element can be provided to let the user tell the software he detected element can be provided to let the user tell the software he detected
an actual SAS mismatch, which indicates a MITM attack. The software an actual SAS mismatch, which indicates a MiTM attack. The software
can then take appropriate action, clearing the SAS Verified flag, and can then take appropriate action, clearing the SAS Verified flag, and
erase the cached shared secret from this session. It is up to the erase the cached shared secret from this session. It is up to the
implementer to decide if this added user interface complexity is implementer to decide if this added user interface complexity is
warranted. warranted.
If the SAS matches, it means there is no MITM, which also implies it If the SAS matches, it means there is no MiTM, which also implies it
is now safe to trust a cached shared secret for later calls. If is now safe to trust a cached shared secret for later calls. If
inattentive users don't bother to check the SAS, it means we don't inattentive users don't bother to check the SAS, it means we don't
know whether there is or is not a MITM, so even if we do establish a know whether there is or is not a MiTM, so even if we do establish a
new cached shared secret, there is a risk that our potential attacker new cached shared secret, there is a risk that our potential attacker
may have a subsequent opportunity to continue inserting himself in may have a subsequent opportunity to continue inserting himself in
the call, until we finally get around to checking the SAS. If the the call, until we finally get around to checking the SAS. If the
SAS matches, it means no attacker was present for any previous SAS matches, it means no attacker was present for any previous
session since we started propagating cached shared secrets, because session since we started propagating cached shared secrets, because
this session and all the previous sessions were also authenticated this session and all the previous sessions were also authenticated
with a continuous lineage of shared secrets. with a continuous lineage of shared secrets.
8.2. Signing the SAS 7.2. Signing the SAS
In some applications, it may be hard to arrange for two human users In some applications, it may be hard to arrange for two human users
to verbally compare the SAS. To handle these cases, ZRTP allows for to verbally compare the SAS. To handle these cases, ZRTP allows for
an OPTIONAL signature feature, which allows the SAS to be checked an OPTIONAL signature feature, which allows the SAS to be checked
without human participation. The SAS MAY be signed and the signature without human participation. The SAS MAY be signed and the signature
sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay
(Figure 16) messages. The signature algorithm, length of the (Figure 16) messages. The signature algorithm, length of the
signature and the key used to create the signature are all sent along signature and the key used to create the signature are all sent along
with the signature. The key types and signature algorithms are for with the signature. The key types and signature algorithms are for
future study. The signature is calculated over the entire SAS hash future study. The signature is calculated over the entire SAS hash
result (sashash) that was truncated down to derive the sasvalue. The result (sashash) that was truncated down to derive the sasvalue. The
signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay
messages MAY be used to authenticate the ZRTP exchange. messages MAY be used to authenticate the ZRTP exchange.
8.3. Relaying the SAS through a PBX 7.3. Relaying the SAS through a PBX
ZRTP is designed to use end-to-end encryption. The two parties' ZRTP is designed to use end-to-end encryption. The two parties'
verbal comparison of the short authentication string (SAS) depends on verbal comparison of the short authentication string (SAS) depends on
this assumption. But in some PBX environments, such as Asterisk, this assumption. But in some PBX environments, such as Asterisk,
there are usage scenarios that have the PBX acting as a trusted man- there are usage scenarios that have the PBX acting as a trusted man-
in-the-middle (MiTM), which means there are two back-to-back ZRTP in-the-middle (MiTM), which means there are two back-to-back ZRTP
connections with separate session keys and separate SAS's. connections with separate session keys and separate SAS's.
For example, imagine that Bob has a ZRTP-enabled VoIP phone that has For example, imagine that Bob has a ZRTP-enabled VoIP phone that has
been registered with his company's PBX, so that it is regarded as an been registered with his company's PBX, so that it is regarded as an
skipping to change at page 66, line 47 skipping to change at page 63, line 46
call to Bob's phone (which might be offsite, many miles away from the call to Bob's phone (which might be offsite, many miles away from the
PBX through the Internet) and a separate ZRTP connection is PBX through the Internet) and a separate ZRTP connection is
negotiated between the PBX and Bob's phone. The two ZRTP sessions negotiated between the PBX and Bob's phone. The two ZRTP sessions
have different session keys and different SAS's, which would render have different session keys and different SAS's, which would render
the SAS useless for verbal comparison between Alice and Bob. They the SAS useless for verbal comparison between Alice and Bob. They
might even mistakenly believe that a wiretapper is present because of might even mistakenly believe that a wiretapper is present because of
the SAS mismatch, causing undue alarm. the SAS mismatch, causing undue alarm.
ZRTP has a mechanism for solving this problem by having the PBX relay ZRTP has a mechanism for solving this problem by having the PBX relay
the Alice/PBX SAS to Bob, sending it through to Bob in a special the Alice/PBX SAS to Bob, sending it through to Bob in a special
SASrelay packet as defined in Section 6.13, which is sent after the SASrelay packet as defined in Section 5.13, which is sent after the
PBX/Bob ZRTP negotiation is complete, after the Confirm packets. PBX/Bob ZRTP negotiation is complete, after the Confirm packets.
Only the PBX, acting as a special trusted MiTM (trusted by the Only the PBX, acting as a special trusted MiTM (trusted by the
recipient of the SAS relay packet), will relay the SAS. The SASrelay recipient of the SAS relay packet), will relay the SAS. The SASrelay
packet protects the relayed SAS from tampering via an included HMAC, packet protects the relayed SAS from tampering via an included HMAC,
similar to how the Confirm packet is protected. Bob's ZRTP-enabled similar to how the Confirm packet is protected. Bob's ZRTP-enabled
phone accepts the relayed SAS for rendering only because Bob's phone phone accepts the relayed SAS for rendering only because Bob's phone
had previously been configured to trust the PBX. This special had previously been configured to trust the PBX. This special
trusted relationship with the PBX can be established through a trusted relationship with the PBX can be established through a
special security enrollment procedure. After that enrollment special security enrollment procedure. After that enrollment
procedure, the PBX is treated by Bob as a special trusted MiTM. This procedure, the PBX is treated by Bob as a special trusted MiTM. This
skipping to change at page 67, line 21 skipping to change at page 64, line 20
may verbally compare them and thus prevent a MiTM attack by any other may verbally compare them and thus prevent a MiTM attack by any other
untrusted MiTM. untrusted MiTM.
A real bad-guy MiTM cannot exploit this protocol feature to mount a A real bad-guy MiTM cannot exploit this protocol feature to mount a
MiTM attack and relay Alice's SAS to Bob, because Bob has not MiTM attack and relay Alice's SAS to Bob, because Bob has not
previously carried out a special registration ritual with the bad previously carried out a special registration ritual with the bad
guy. The relayed SAS would not be rendered by Bob's phone, because guy. The relayed SAS would not be rendered by Bob's phone, because
it did not come from a trusted PBX. The recognition of the special it did not come from a trusted PBX. The recognition of the special
trust relationship is achieved with the prior establishment of a trust relationship is achieved with the prior establishment of a
special shared secret between Bob and his PBX, which is called special shared secret between Bob and his PBX, which is called
pbxsecret (defined in Section 8.3.1), also known as the trusted MiTM pbxsecret (defined in Section 7.3.1), also known as the trusted MiTM
key. key.
The trusted MiTM key can be stored in a special cache at the time of The trusted MiTM key can be stored in a special cache at the time of
the initial enrollment (which is carried out only once for Bob's the initial enrollment (which is carried out only once for Bob's
phone), and Bob's phone associates this key with the ZID of the PBX, phone), and Bob's phone associates this key with the ZID of the PBX,
while the PBX associates it with the ZID of Bob's phone. After the while the PBX associates it with the ZID of Bob's phone. After the
enrollment has established and stored this trusted MiTM key, it can enrollment has established and stored this trusted MiTM key, it can
be detected during subsequent ZRTP call negotiations between the PBX be detected during subsequent ZRTP call negotiations between the PBX
and Bob's phone, because the PBX and the phone MUST pass the hash of and Bob's phone, because the PBX and the phone MUST pass the hash of
the trusted MiTM key in the DH packet. It is then used as part of the trusted MiTM key in the DH packet. It is then used as part of
the key agreement to calculate s0. the key agreement to calculate s0.
During a key agreement with two other ZRTP endpoints, the PBX may
have a shared trusted MiTM key with both endpoints, only one
endpoint, or neither endpoint. If the PBX has a shared trusted MiTM
key with neither endpoint, the PBX SHOULD NOT relay the SAS. If the
PBX has a shared trusted MiTM key with only one endpoint, the PBX
SHOULD relay the SAS from one party the other by sending an SASrelay
message to the endpoint that it shares a trusted MiTM key. If the
PBX has a shared trusted MiTM key with both endpoints, the PBX SHOULD
relay the SAS from one party the other by sending an SASrelay message
to only one of the endpoints.
Note: In the case of sharing trusted MiTM key with both endpoints,
it does not matter which endpoint receives the relayed SAS as long
as only one endpoint receives it.
The PBX can determine whether it is trusted by the ZRTP user agent of The PBX can determine whether it is trusted by the ZRTP user agent of
the caller or callee. The presence of a shared trusted MiTM key in the caller or callee. The presence of a shared trusted MiTM key in
the key negotiation sequence indicates that the phone has been the key negotiation sequence indicates that the phone has been
enrolled with this PBX and therefore trusts it to act as a trusted enrolled with this PBX and therefore trusts it to act as a trusted
MiTM. The PBX SHOULD relay the SAS from the other party in this MiTM. The PBX SHOULD relay the SAS from the other party in this
case. case.
The relayed SAS fields contain the SAS rendering type and the binary The relayed SAS fields contain the SAS rendering type and the binary
32-bit sasvalue. The receiver absolutely MUST NOT render the relayed 32-bit sasvalue. The receiver absolutely MUST NOT render the relayed
SAS if it does not come from a specially trusted ZRTP endpoint. The SAS if it does not come from a specially trusted ZRTP endpoint. The
skipping to change at page 68, line 12 skipping to change at page 65, line 26
message to the unenrolled party (which does not regard this PBX as a message to the unenrolled party (which does not regard this PBX as a
trusted MiTM), conveying the SAS rendering scheme, but not the SAS trusted MiTM), conveying the SAS rendering scheme, but not the SAS
value, which it sets to zero. The unenrolled party will ignore the value, which it sets to zero. The unenrolled party will ignore the
relayed SAS field, but will use the specified SAS rendering scheme. relayed SAS field, but will use the specified SAS rendering scheme.
The next section describes the initial enrollment procedure that The next section describes the initial enrollment procedure that
establishes a special shared secret between the PBX and Bob's phone, establishes a special shared secret between the PBX and Bob's phone,
a trusted MiTM key, so that the phone will learn to recognize the PBX a trusted MiTM key, so that the phone will learn to recognize the PBX
as a trusted MiTM. as a trusted MiTM.
8.3.1. PBX Enrollment and the PBX Enrollment Flag 7.3.1. PBX Enrollment and the PBX Enrollment Flag
Both the PBX and the endpoint need to know when enrollment is taking Both the PBX and the endpoint need to know when enrollment is taking
place. One way of doing this is to setup an enrollment extension on place. One way of doing this is to setup an enrollment extension on
the PBX which a newly configured endpoint would call and establish a the PBX which a newly configured endpoint would call and establish a
ZRTP session. The PBX would then play audio media that offers the ZRTP session. The PBX would then play audio media that offers the
user an opportunity to configure his phone to trust this PBX as a user an opportunity to configure his phone to trust this PBX as a
trusted MiTM. The PBX calculates and stores the trusted MiTM shared trusted MiTM. The PBX calculates and stores the trusted MiTM shared
secret in its cache and associates it with this phone, indexed by the secret in its cache and associates it with this phone, indexed by the
phone's ZID. The trusted MiTM PBX shared secret is calculated this phone's ZID. The trusted MiTM PBX shared secret is calculated this
way: way:
skipping to change at page 68, line 43 skipping to change at page 66, line 9
in a special cache entry associated with this PBX. in a special cache entry associated with this PBX.
If the user elects not to enroll, perhaps because he dialed a wrong If the user elects not to enroll, perhaps because he dialed a wrong
number or does not yet feel comfortable with this PBX, he can simply number or does not yet feel comfortable with this PBX, he can simply
hang up and not save the pbxsecret in his cache. The PBX will have hang up and not save the pbxsecret in his cache. The PBX will have
it saved in the PBX cache, but that will do no harm. The SASrelay it saved in the PBX cache, but that will do no harm. The SASrelay
scheme does not depend on the PBX trusting the phone. It only scheme does not depend on the PBX trusting the phone. It only
depends on the phone trusting the PBX. It is the phone (the user) depends on the phone trusting the PBX. It is the phone (the user)
who is at risk if the PBX abuses its MiTM privileges. who is at risk if the PBX abuses its MiTM privileges.
An endpoint MUST NOT store the pbxsecret in the cache without
explicit user authorization.
After this enrollment process, the PBX and the ZRTP-enabled phone After this enrollment process, the PBX and the ZRTP-enabled phone
both share a secret that enables the phone to recognize the PBX as a both share a secret that enables the phone to recognize the PBX as a
trusted MiTM in future calls. This means that when a future call trusted MiTM in future calls. This means that when a future call
from an outside ZRTP-enabled caller is relayed through the PBX to from an outside ZRTP-enabled caller is relayed through the PBX to
this phone, the phone will render a relayed SAS from the PBX. If the this phone, the phone will render a relayed SAS from the PBX. If the
SASrelay packet comes from a MiTM which does not know the pbxsecret, SASrelay packet comes from a MiTM which does not know the pbxsecret,
the phone treats it as a "bad guy" MiTM, and refuses to render the the phone treats it as a "bad guy" MiTM, and refuses to render the
relayed SAS. Regardless of which party initiates any future phone relayed SAS. Regardless of which party initiates any future phone
calls through the PBX, the enrolled phone or the outside phone, the calls through the PBX, the enrolled phone or the outside phone, the
PBX will relay the SAS to the enrolled phone. PBX will relay the SAS to the enrolled phone.
There are other ways that ZRTP user agents can be configured to trust There are other ways that ZRTP user agents can be configured to trust
a PBX. Perhaps the pbxsecret can be configured into the phone by a PBX. Perhaps the pbxsecret can be configured into the phone by
some automated provisioning process in large IT environments. This some automated provisioning process in large IT environments. This
specification does not require that products be configured solely by specification does not require that products be configured solely by
this enrollment process. Any process that results in a pbxsecret to this enrollment process. Any process that results in a pbxsecret to
be computed and shared between the PBX and the phone will suffice. be computed and shared between the PBX and the phone will suffice.
This is one such method that has been shown to work. This is one such method that has been shown to work.
9. Signaling Interactions 8. Signaling Interactions
This section discusses how ZRTP, SIP, and SDP work together. This section discusses how ZRTP, SIP, and SDP work together.
Note that ZRTP may be implemented without coupling with the SIP Note that ZRTP may be implemented without coupling with the SIP
signaling. For example, ZRTP can be implemented as a "bump in the signaling. For example, ZRTP can be implemented as a "bump in the
wire" or as a "bump in the stack" in which RTP sent by the SIP UA is wire" or as a "bump in the stack" in which RTP sent by the SIP UA is
converted to ZRTP. In these cases, the SIP UA will have no knowledge converted to ZRTP. In these cases, the SIP UA will have no knowledge
of ZRTP. As a result, the signaling path discovery mechanisms of ZRTP. As a result, the signaling path discovery mechanisms
introduced in this section should not be definitive - they are a introduced in this section should not be definitive - they are a
hint. Despite the absence of an indication of ZRTP support in an hint. Despite the absence of an indication of ZRTP support in an
offer or answer, a ZRTP endpoint SHOULD still send Hello messages. offer or answer, a ZRTP endpoint SHOULD still send Hello messages.
ZRTP endpoints which have control over the signaling path include a ZRTP endpoints which have control over the signaling path include a
ZRTP SDP attributes in their SDP offers and answers. The ZRTP ZRTP SDP attributes in their SDP offers and answers. The ZRTP
attribute, a=zrtp-hash is used to indicate support for ZRTP and to attribute, a=zrtp-hash is used to indicate support for ZRTP and to
convey a hash of the Hello message. The hash is computed according convey a hash of the Hello message. The hash is computed according
to Section 9.1. to Section 8.1.
Aside from the advantages described in Section 9.1, there are a Aside from the advantages described in Section 8.1, there are a
number of potential uses for this attribute. It is useful when number of potential uses for this attribute. It is useful when
signaling elements would like to know when ZRTP may be utilized by signaling elements would like to know when ZRTP may be utilized by
endpoints. It is also useful if endpoints support multiple methods endpoints. It is also useful if endpoints support multiple methods
of SRTP key management. The ZRTP attribute can be used to ensure of SRTP key management. The ZRTP attribute can be used to ensure
that these key management approaches work together instead of against that these key management approaches work together instead of against
each other. For example, if only one endpoint supports ZRTP but both each other. For example, if only one endpoint supports ZRTP but both
support another method to key SRTP, then the other method will be support another method to key SRTP, then the other method will be
used instead. When used in parallel, an SRTP secret carried in an used instead. When used in parallel, an SRTP secret carried in an
a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a
shared secret for the srtps computation defined in Section 9.2. The shared secret for the srtps computation defined in Section 8.2. The
ZRTP attribute is also used to signal to an intermediary ZRTP device ZRTP attribute is also used to signal to an intermediary ZRTP device
not to act as a ZRTP endpoint, as discussed in Section 11. not to act as a ZRTP endpoint, as discussed in Section 10.
The a=zrtp-hash attribute can only be included at a media level since The a=zrtp-hash attribute can only be included in the SDP at the
Hello messages sent in different media streams will have unique media level since Hello messages sent in different media streams will
hashes. have unique hashes.
The ABNF for the ZRTP attribute is as follows: The ABNF for the ZRTP attribute is as follows:
zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
zrtp-version = token zrtp-version = token
zrtp-hash-value = 1*(HEXDIG) zrtp-hash-value = 1*(HEXDIG)
Example of the ZRTP attribute in an initial SDP offer or answer used Example of the ZRTP attribute in an initial SDP offer or answer used
skipping to change at page 70, line 26 skipping to change at page 67, line 42
v=0 v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s= s=
c=IN IP4 client.biloxi.example.com c=IN IP4 client.biloxi.example.com
t=0 0 t=0 0
m=audio 3456 RTP/AVP 97 33 m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000 a=rtpmap:33 no-op/8000
a=zrtp-hash:1.00 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df a=zrtp-hash:1.00 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
9.1. Binding the media stream to the signaling layer via the Hello Hash 8.1. Binding the media stream to the signaling layer via the Hello Hash
It is desirable to tie the media stream to the signaling channel to It is desirable to tie the media stream to the signaling channel to
prevent a third party from inserting false media packets. If the prevent a third party from inserting false media packets. If the
signaling layer contains information that ties it to the media signaling layer contains information that ties it to the media
stream, false media streams can be rejected. stream, false media streams can be rejected.
To accomplish this, a 256-bit hash (using the hash algorithm defined To accomplish this, a 256-bit hash (using the hash algorithm defined
in Section 6.1.2.1) is computed across the entire ZRTP Hello message in Section 5.1.2.1) is computed across the entire ZRTP Hello message
(as shown in Figure 3). This hash image is made available to the (as shown in Figure 3). This hash image is made available to the
signaling layer, where it is transmitted as a hexadecimal value in signaling layer, where it is transmitted as a hexadecimal value in
the SIP channel using the SDP attribute, a=zrtp-hash defined in this the SIP channel using the SDP attribute, a=zrtp-hash defined in this
specification. Each media stream (audio or video) will have a specification. Each media stream (audio or video) will have a
separate Hello packet, and thus will require a separate a=zrtp-hash separate Hello packet, and thus will require a separate a=zrtp-hash
in an SDP attribute. The recipient of the SIP/SDP message can then in an SDP attribute. The recipient of the SIP/SDP message can then
use this hash image to detect and reject false Hello packets in the use this hash image to detect and reject false Hello packets in the
media channel, as well as identify which media stream is associated media channel, as well as identify which media stream is associated
with this SIP call. Each Hello packet hashes uniquely, because it with this SIP call. Each Hello packet hashes uniquely, because it
contains the H3 field derived from a random nonce, defined in contains the H3 field derived from a random nonce, defined in
Section 10. Section 9.
The Hello Hash as an SDP attribute is an OPTIONAL feature, because The Hello Hash as an SDP attribute is an OPTIONAL feature, because
some ZRTP endpoints do not have the ability to add SDP attributes to some ZRTP endpoints do not have the ability to add SDP attributes to
the signaling. For example, if ZRTP is implemented in a hardware the signaling. For example, if ZRTP is implemented in a hardware
bump-in-the-wire device, it might only have the ability to modify the bump-in-the-wire device, it might only have the ability to modify the
media packets, not the SIP packets, especially if the SIP packets are media packets, not the SIP packets, especially if the SIP packets are
integrity protected and thus cannot be modified on the wire. If the integrity protected and thus cannot be modified on the wire. If the
SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP
user agent cannot check it, and thus will not be able to reject Hello user agent cannot check it, and thus will not be able to reject Hello
messages based on this hash. messages based on this hash.
After the Hello Hash is used to properly identify the ZRTP Hello After the Hello Hash is used to properly identify the ZRTP Hello
message as belonging to this particular SIP call, the rest of the message as belonging to this particular SIP call, the rest of the
ZRTP message sequence is protected from false packet injection by ZRTP message sequence is protected from false packet injection by
other protection mechanisms. For example, the use of the total_hash other protection mechanisms. For example, the use of the total_hash
in the shared secret calculation, and also the hash chaining in the shared secret calculation, and also the hash chaining
mechanism defined in Section 10. mechanism defined in Section 9.
An attacker who controls only the signaling layer, such as an An attacker who controls only the signaling layer, such as an
uncooperative VoIP service provider, may be able to deny service by uncooperative VoIP service provider, may be able to deny service by
corrupting the hash of the Hello message in the SDP attribute, which corrupting the hash of the Hello message in the SDP attribute, which
would force ZRTP to reject perfectly good Hello messages. If there would force ZRTP to reject perfectly good Hello messages. If there
is reason to believe this is happening, the ZRTP endpoint MAY allow is reason to believe this is happening, the ZRTP endpoint MAY allow
Hello messages to be accepted that do not match the hash image in the Hello messages to be accepted that do not match the hash image in the
SDP attribute. SDP attribute.
Even in the absence of SIP integrity protection, the inclusion of the Even in the absence of SIP integrity protection, the inclusion of the
a=zrtp-hash SDP attribute, when coupled with the hash chaining a=zrtp-hash SDP attribute, when coupled with the hash chaining
mechanism defined in Section 10, meets the R-ASSOC requirement in the mechanism defined in Section 9, meets the R-ASSOC requirement in the
Media Security Requirements Media Security Requirements
[I-D.ietf-sip-media-security-requirements], which requires: [I-D.ietf-sip-media-security-requirements], which requires:
"...a mechanism for associating key management messages with both "...a mechanism for associating key management messages with both
the signaling traffic that initiated the session and with the signaling traffic that initiated the session and with
protected media traffic. Allowing such an association also allows protected media traffic. Allowing such an association also allows
the SDP offerer to avoid performing CPU-consuming operations the SDP offerer to avoid performing CPU-consuming operations
(e.g., Diffie-Hellman or public key operations) with attackers (e.g., Diffie-Hellman or public key operations) with attackers
that have not seen the signaling messages." that have not seen the signaling messages."
The a=zrtp-hash SDP attribute becomes especially useful if the SDP is The a=zrtp-hash SDP attribute becomes especially useful if the SDP is
integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474] integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474]
or better still, Dan Wing's SIP Identity using Media Path or better still, Dan Wing's SIP Identity using Media Path
[I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM [I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM
attacks independent of ZRTP's SAS mechanism, as explained in attacks independent of ZRTP's SAS mechanism, as explained in
Section 9.1.1 below. Section 8.1.1 below.
9.1.1. Integrity-protected signaling enables integrity-protected DH 8.1.1. Integrity-protected signaling enables integrity-protected DH
exchange exchange
If and only if the signaling path and the SDP is protected by some If and only if the signaling path and the SDP is protected by some
form of end-to-end integrity protection, such as one of the form of end-to-end integrity protection, such as one of the
abovementioned mechanisms, so that it can guarantee delivery of the abovementioned mechanisms, so that it can guarantee delivery of the
a=zrtp-hash attribute without any tampering by a third party, and if a=zrtp-hash attribute without any tampering by a third party, and if
there is good reason to trust the signaling layer to protect the there is good reason to trust the signaling layer to protect the
interests of the end user, it is possible to authenticate the key interests of the end user, it is possible to authenticate the key
exchange and prevent a MiTM attack. This can be done without exchange and prevent a MiTM attack. This can be done without
requiring the users to verbally compare the SAS, by using the hash requiring the users to verbally compare the SAS, by using the hash
chaining mechanism defined in Section 10 to provide a series of HMAC chaining mechanism defined in Section 9 to provide a series of HMAC
keys that protect the entire ZRTP key exchange. Thus, an end-to-end keys that protect the entire ZRTP key exchange. Thus, an end-to-end
integrity-protected signaling layer automatically enables an integrity-protected signaling layer automatically enables an
integrity-protected Diffie-Hellman exchange in ZRTP, which in turn integrity-protected Diffie-Hellman exchange in ZRTP, which in turn
means immunity from a MiTM attack. Here's how it works. means immunity from a MiTM attack. Here's how it works.
The integrity-protected SIP SDP contains a hash commitment to the The integrity-protected SIP SDP contains a hash commitment to the
entire Hello message. The Hello message contains H3, which provides entire Hello message. The Hello message contains H3, which provides
a hash commitment for the rest of the hash chain H0-H2 (Section 10). a hash commitment for the rest of the hash chain H0-H2 (Section 9).
The Hello message is protected by a 64-bit HMAC, keyed by H2. The The Hello message is protected by a 64-bit HMAC, keyed by H2. The
Commit message is protected by a 64-bit HMAC keyed by H1. The Commit message is protected by a 64-bit HMAC keyed by H1. The
DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by
H0. The HMAC protecting the Confirm messages are computed by a H0. The HMAC protecting the Confirm messages are computed by a
different HMAC key derived from the resulting key agreement. Each different HMAC key derived from the resulting key agreement. Each
message's HMAC is checked when the HMAC key is received in the next message's HMAC is checked when the HMAC key is received in the next
message. If a bad HMAC is discovered, it MUST be treated as a message. If a bad HMAC is discovered, it MUST be treated as a
security exception indicating a MiTM attack, perhaps by logging or security exception indicating a MiTM attack, perhaps by logging or
alerting the user. It MUST NOT be treated as a random error. Random alerting the user, and MUST NOT be treated as a random error. Random
errors are already discovered and quietly rejected by bad CRCs errors are already discovered and quietly rejected by bad CRCs
(Figure 2). (Figure 2).
The Hello message must be assembled before any hash algorithms are The Hello message must be assembled before any hash algorithms are
negotiated, so an implicit predetermined hash algorthm and HMAC negotiated, so an implicit predetermined hash algorthm and HMAC
algorthm (both defined in Section 6.1.2.1) must be used. All of the algorthm (both defined in Section 5.1.2.1) must be used. All of the
aforementioned HMACs keyed by the hashes in the aforementioned hash aforementioned HMACs keyed by the hashes in the aforementioned hash
chain MUST be computed with the HMAC algorithm defined in chain MUST be computed with the HMAC algorithm defined in
Section 6.1.2.1, with the HMAC truncated to 64 bits. Section 5.1.2.1, with the HMAC truncated to 64 bits.
The Media Security Requirements The Media Security Requirements
[I-D.ietf-sip-media-security-requirements] R-EXISTING requirement can [I-D.ietf-sip-media-security-requirements] R-EXISTING requirement can
be fully met by leveraging a certificate-backed PKI in the signaling be fully met by leveraging a certificate-backed PKI in the signaling
layer to integrity-protect the delivery of the a=zrtp-hash SDP layer to integrity-protect the delivery of the a=zrtp-hash SDP
attribute. This would thereby protect ZRTP against a MiTM attack, attribute. This would thereby protect ZRTP against a MiTM attack,
without requiring the user to check the SAS, without adding any without requiring the user to check the SAS, without adding any
explicit signatures or signature keys to the ZRTP key exchange, and explicit signatures or signature keys to the ZRTP key exchange, and
without any extra public key operations or extra packets. without any extra public key operations or extra packets.
skipping to change at page 73, line 30 skipping to change at page 70, line 46
the complexity of building and maintaining a PKI. the complexity of building and maintaining a PKI.
In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend
heavily on end-to-end integrity protection in the SIP layer. heavily on end-to-end integrity protection in the SIP layer.
Further, DTLS-SRTP must bear the additional cost of a signature Further, DTLS-SRTP must bear the additional cost of a signature
calculation of its own, in addition to the signature calculation the calculation of its own, in addition to the signature calculation the
SIP layer uses to achieve its integrity protection. ZRTP needs no SIP layer uses to achieve its integrity protection. ZRTP needs no
signature calculation of its own to leverage the signature signature calculation of its own to leverage the signature
calculation carried out in the SIP layer. calculation carried out in the SIP layer.
9.2. Deriving the SRTP secret (srtps) from the signaling layer 8.2. Deriving the SRTP secret (srtps) from the signaling layer
The shared secret calculations defined in Section 5.3 make use of the The shared secret calculations defined in Section 4.3 make use of the
SRTP secret (srtps), if it is provided by the signaling layer. SRTP secret (srtps), if it is provided by the signaling layer.
It is desirable for only one SRTP key negotiation protocol to be It is desirable for only one SRTP key negotiation protocol to be
used, and that protocol should be ZRTP. But in the event the used, and that protocol should be ZRTP. But in the event the
signaling layer negotiates its own SRTP master key and salt, using signaling layer negotiates its own SRTP master key and salt, using
the SDES [RFC4568] or [RFC4567], it can be passed from the signaling the SDES [RFC4568] or [RFC4567], it can be passed from the signaling
to the ZRTP layer and mixed into ZRTP's own shared secret to the ZRTP layer and mixed into ZRTP's own shared secret
calculations, without compromising security by creating a dependency calculations, without compromising security by creating a dependency
on the signaling for media encryption. on the signaling for media encryption.
ZRTP computes srtps from the SRTP master key and salt parameters ZRTP computes srtps from the SRTP master key and salt parameters
provided by the signaling layer in this manner: provided by the signaling layer in this manner:
srtps = hash(SRTP master key | SRTP master salt) srtps = hash(SRTP master key | SRTP master salt)
It is expected that the srtps parameter will be rarely computed or It is expected that the srtps parameter will be rarely computed or
used in typical ZRTP endpoints, because it is likely and desirable used in typical ZRTP endpoints, because it is likely and desirable
that ZRTP will be the sole means of negotiating SRTP keys, needing no that ZRTP will be the sole means of negotiating SRTP keys, needing no
help from SDES [RFC4568] or [RFC4567]. If srtps is computed, it will help from SDES [RFC4568] or [RFC4567]. If srtps is computed, it will
be stored in the auxiliary shared secret auxsecret, defined in be stored in the auxiliary shared secret auxsecret, defined in
Section 5.3, and used in Section 5.3.1 and Section 5.3.2. Section 4.3, and used in Section 4.3.1 and Section 4.3.2.
9.3. Codec Selection for Secure Media 8.3. Codec Selection for Secure Media
Codec selection is negotiated in the signaling layer. If the Codec selection is negotiated in the signaling layer. If the
signaling layer determines that ZRTP is supported by both endpoints, signaling layer determines that ZRTP is supported by both endpoints,
this should provide guidance in codec selection to avoid VBR codecs this should provide guidance in codec selection to avoid variable
that leak information. bit-rate (VBR) codecs that leak information.
When voice is compressed with a variable bit-rate (VBR) codec, the When voice is compressed with a VBR codec, the packet lengths vary
packet lengths vary depending on the types of sounds being depending on the types of sounds being compressed. This leaks a lot
compressed. This leaks a lot of information about the content even of information about the content even if the packets are encrypted,
if the packets are encrypted, regardless of what encryption protocol regardless of what encryption protocol is used [Wright1]. It is
is used [Wright1]. It is RECOMMENDED that VBR codecs be avoided in RECOMMENDED that VBR codecs be avoided in encrypted calls. It is not
encrypted calls. It's not a problem if the codec adapts the bit rate a problem if the codec adapts the bit rate to the available channel
to the available channel bandwidth. The vulnerable codecs are the bandwidth. The vulnerable codecs are the ones that change their bit
ones that change their bit rate depending on the type of sound being rate depending on the type of sound being compressed.
compressed.
It also appears that voice activity detection (VAD) leaks information It also appears that voice activity detection (VAD) leaks information
about the content of the conversation, but to a lesser extent than about the content of the conversation, but to a lesser extent than
VBR. This effect can be ameliorated by lengthening the VAD hangover VBR. This effect can be ameliorated by lengthening the VAD hangover
time by about 1 to 2 seconds, if this is feasible in your time by about 1 to 2 seconds, if this is feasible in your
application. This is a topic that requires further study. application. This is a topic that requires further study.
10. False ZRTP Packet Rejection 9. False ZRTP Packet Rejection
An attacker who is not in the media path may attempt to inject false An attacker who is not in the media path may attempt to inject false
ZRTP protocol packets, possibly to effect a denial of service attack, ZRTP protocol packets, possibly to effect a denial of service attack,
or to inject his own media stream into the call. VoIP by its nature or to inject his own media stream into the call. VoIP by its nature
invites various forms of denial of service attacks and requires invites various forms of denial of service attacks and requires
protocol features to reject such attacks. While bogus SRTP packets protocol features to reject such attacks. While bogus SRTP packets
may be easily rejected via the SRTP auth tag field, that can only be may be easily rejected via the SRTP auth tag field, that can only be
applied after a key agreement is completed. During the ZRTP key applied after a key agreement is completed. During the ZRTP key
negotiation phase, other false packet rejection mechanisms are negotiation phase, other false packet rejection mechanisms are
needed. One such mechanism is the use of the total_hash in the final needed. One such mechanism is the use of the total_hash in the final
skipping to change at page 75, line 13 skipping to change at page 72, line 28
cheaply and rapidly as soon as they are received, ZRTP uses a hash cheaply and rapidly as soon as they are received, ZRTP uses a hash
chain, which is a series of successive hash images. Before each chain, which is a series of successive hash images. Before each
session, the following values are computed: session, the following values are computed:
H0 = 256-bit random nonce (different for each party) H0 = 256-bit random nonce (different for each party)
H1 = hash (H0) H1 = hash (H0)
H2 = hash (H1) H2 = hash (H1)
H3 = hash (H2) H3 = hash (H2)
The hash chain MUST use the hash algorithm defined in The hash chain MUST use the hash algorithm defined in
Section 6.1.2.1. Each 256-bit hash image is the pre-image of the Section 5.1.2.1. Each 256-bit hash image is the pre-image of the
next, and the sequence of images is sent in reverse order in the ZRTP next, and the sequence of images is sent in reverse order in the ZRTP
packet sequence. The hash image H3 is sent in the Hello packet, H2 packet sequence. The hash image H3 is sent in the Hello packet, H2
is sent in the Commit packet, H1 is sent in the DHPart1 or DHPart2 is sent in the Commit packet, H1 is sent in the DHPart1 or DHPart2
packets, and H0 is sent in the Confirm1 or Confirm2 packets. The packets, and H0 is sent in the Confirm1 or Confirm2 packets. The
initial random H0 nonces that each party generates MUST be initial random H0 nonces that each party generates MUST be
unpredictable to an attacker and unique within a ZRTP call, which unpredictable to an attacker and unique within a ZRTP call, which
thereby forces the derived hash images H1-H3 to also be unique and thereby forces the derived hash images H1-H3 to also be unique and
unpredictable. unpredictable.
The recipient checks if the packet has the correct hash pre-image, by The recipient checks if the packet has the correct hash pre-image, by
skipping to change at page 75, line 43 skipping to change at page 73, line 10
contents of the packet they reside in, this scheme assumes the contents of the packet they reside in, this scheme assumes the
attacker cannot modify the packet contents from a legitimate party, attacker cannot modify the packet contents from a legitimate party,
which is a reasonable assumption for an attacker who is not in the which is a reasonable assumption for an attacker who is not in the
media path. This covers an important range of denial-of-service media path. This covers an important range of denial-of-service
attacks. For dealing with the remaining set of attacks that involve attacks. For dealing with the remaining set of attacks that involve
packet modification, other mechanisms are used, such as the packet modification, other mechanisms are used, such as the
total_hash in the final shared secret calculation, and the hash total_hash in the final shared secret calculation, and the hash
commitment in the Commit packet. commitment in the Commit packet.
False Hello packets may be detected and rejected by the mechanism False Hello packets may be detected and rejected by the mechanism
defined in Section 9.1. This mechanism requires that each Hello defined in Section 8.1. This mechanism requires that each Hello
packet be unique, and the inclusion of the H3 hash image meets that packet be unique, and the inclusion of the H3 hash image meets that
requirement. requirement.
If and only if an integrity-protected signaling channel is available, If and only if an integrity-protected signaling channel is available,
this hash chaining scheme can be used to key HMACs to authenticate this hash chaining scheme can be used to key HMACs to authenticate
the entire ZRTP key exchange, and thereby prevent a MiTM attack, the entire ZRTP key exchange, and thereby prevent a MiTM attack,
without relying on the users verbally comparing the SAS. See without relying on the users verbally comparing the SAS. See
Section 9.1.1 for details. Section 8.1.1 for details.
Some ZRTP user agents allow the user to manually switch to clear mode Some ZRTP user agents allow the user to manually switch to clear mode
(via the GoClear packet) in the middle of a secure call, and then (via the GoClear packet) in the middle of a secure call, and then
later initiate secure mode again. Many consumer client products will later initiate secure mode again. Many consumer client products will
omit this feature, but those that allow it may return to secure mode omit this feature, but those that allow it may return to secure mode
again in the same media stream. Although the same chain of hash again in the same media stream. Although the same chain of hash
images will be re-used and thus rendered ineffective the second time, images will be re-used and thus rendered ineffective the second time,
no real harm is done because the new SRTP session keys will be no real harm is done because the new SRTP session keys will be
derived in part from a cached shared secret, which was safely derived in part from a cached shared secret, which was safely
protected from the MiTM in the previous DH exchange earlier in the protected from the MiTM in the previous DH exchange earlier in the
same call. same call.
11. Intermediary ZRTP Devices 10. Intermediary ZRTP Devices
This section discusses the operation of a ZRTP endpoint which is This section discusses the operation of a ZRTP endpoint which is
actually an intermediary. For example, consider a device which actually an intermediary. For example, consider a device which
proxies both signaling and media between endpoints. There are three proxies both signaling and media between endpoints. There are three
possible ways in which such a device could support ZRTP. possible ways in which such a device could support ZRTP.
An intermediary device can act transparently to the ZRTP protocol. An intermediary device can act transparently to the ZRTP protocol.
To do this, a device MUST pass RTP header extensions and payloads (to To do this, a device MUST pass RTP header extensions and payloads (to
allow the ZRTP Flag) and non-RTP protocols multiplexed on the same allow the ZRTP Flag) and non-RTP protocols multiplexed on the same
port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED
skipping to change at page 76, line 48 skipping to change at page 74, line 16
the media between the intermediary and the inside endpoint, such as the media between the intermediary and the inside endpoint, such as
IPSec or physical security. IPSec or physical security.
The third mode, which is NOT RECOMMENDED, is for the intermediary The third mode, which is NOT RECOMMENDED, is for the intermediary
device to attempt to back-to-back the ZRTP protocol. The only device to attempt to back-to-back the ZRTP protocol. The only
exception to this case is where the intermediary device is a trusted exception to this case is where the intermediary device is a trusted
element providing services to one of the endpoints - e.g. a Private element providing services to one of the endpoints - e.g. a Private
Branch Exchange or PBX. In this mode, the intermediary would attempt Branch Exchange or PBX. In this mode, the intermediary would attempt
to act as a ZRTP endpoint towards both endpoints of the media to act as a ZRTP endpoint towards both endpoints of the media
session. This approach MUST NOT be used except as described in session. This approach MUST NOT be used except as described in
Section 8.3 as it will always result in a detected man-in-the-middle Section 7.3 as it will always result in a detected man-in-the-middle
attack and will generate alarms on both endpoints and likely result attack and will generate alarms on both endpoints and likely result
in the immediate termination of the session. in the immediate termination of the session.
In cases where centralized media mixing is taking place, the SAS will In cases where centralized media mixing is taking place, the SAS will
not match when compared by the humans. However, this situation is not match when compared by the humans. However, this situation is
known in the SIP signaling by the presence of the isfocus feature tag known in the SIP signaling by the presence of the isfocus feature tag
[RFC4579]. As a result, when the isfocus feature tag is present, the [RFC4579]. As a result, when the isfocus feature tag is present, the
DH exchange can be authenticated by the mechanism defined in DH exchange can be authenticated by the mechanism defined in
Section 9.1.1 or by validating signatures (Section 8.2) in the Section 8.1.1 or by validating signatures (Section 7.2) in the
Confirm or SASrelay messages. For example, consider a audio Confirm or SASrelay messages. For example, consider a audio
conference call with three participants Alice, Bob, and Carol hosted conference call with three participants Alice, Bob, and Carol hosted
on a conference bridge in Dallas. There will be three ZRTP encrypted on a conference bridge in Dallas. There will be three ZRTP encrypted
media streams, one encrypted stream between each participant and media streams, one encrypted stream between each participant and
Dallas. Each will have a different SAS. Each participant will be Dallas. Each will have a different SAS. Each participant will be
able to validate their SAS with the conference bridge by using able to validate their SAS with the conference bridge by using
signatures optionally present in the Confirm messages (described in signatures optionally present in the Confirm messages (described in
Section 8.2). Or, if the signaling path has end-to-end integrity Section 7.2). Or, if the signaling path has end-to-end integrity
protection, each DH exchange will have automatic MiTM protection by protection, each DH exchange will have automatic MiTM protection by
using the mechanism in Section 9.1.1. using the mechanism in Section 8.1.1.
SIP feature tags can also be used to detect if a session is SIP feature tags can also be used to detect if a session is
established with an automaton such as an IVR, voicemail system, or established with an automaton such as an IVR, voicemail system, or
speech recognition system. The display of SAS strings to users speech recognition system. The display of SAS strings to users
should be disabled in these cases. should be disabled in these cases.
It is possible that an intermediary device acting as a ZRTP endpoint It is possible that an intermediary device acting as a ZRTP endpoint
might still receive ZRTP Hello and other messages from the inside might still receive ZRTP Hello and other messages from the inside
endpoint. This could occur if there is another inline ZRTP device endpoint. This could occur if there is another inline ZRTP device
which does not include the ZRTP SDP attribute flag. If this occurs, which does not include the ZRTP SDP attribute flag. An intermediary
the intermediary MUST NOT pass these ZRTP messages if it is acting as acting as a ZRTP endpoint receiving ZRTP Hello and other messages
the ZRTP endpoint. from the inside endpoint MUST NOT pass these ZRTP messages.
12. The ZRTP Disclosure flag 11. The ZRTP Disclosure flag
There are no back doors defined in the ZRTP protocol specification. There are no back doors defined in the ZRTP protocol specification.
The designers of ZRTP would like to discourage back doors in ZRTP- The designers of ZRTP would like to discourage back doors in ZRTP-
enabled products. However, despite the lack of back doors in the enabled products. However, despite the lack of back doors in the
actual ZRTP protocol, it must be recognized that a ZRTP implementer actual ZRTP protocol, it must be recognized that a ZRTP implementer
might still deliberately create a rogue ZRTP-enabled product that might still deliberately create a rogue ZRTP-enabled product that
implements a back door outside the scope of the ZRTP protocol. For implements a back door outside the scope of the ZRTP protocol. For
example, they could create a product that discloses the SRTP session example, they could create a product that discloses the SRTP session
key generated using ZRTP out-of-band to a third party. They may even key generated using ZRTP out-of-band to a third party. They may even
have a legitimate business reason to do this for some customers. have a legitimate business reason to do this for some customers.
skipping to change at page 78, line 16 skipping to change at page 75, line 35
the session key can undermine public confidence in the ZRTP protocol, the session key can undermine public confidence in the ZRTP protocol,
unless we do everything we can in the protocol to alert the other unless we do everything we can in the protocol to alert the other
user that this is happening. user that this is happening.
If one of the parties is using a product that is designed to disclose If one of the parties is using a product that is designed to disclose
their session key, ZRTP requires them to confess this fact to the their session key, ZRTP requires them to confess this fact to the
other party through a protocol message to the other party's ZRTP other party through a protocol message to the other party's ZRTP
client, which can properly alert that user, perhaps by rendering it client, which can properly alert that user, perhaps by rendering it
in a graphical user interface. The disclosing party does this by in a graphical user interface. The disclosing party does this by
sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as
described in Section 6.7. described in Section 5.7.
Note that the intention here is to have the Disclosure flag identify Note that the intention here is to have the Disclosure flag identify
products that are designed to disclose their session keys, not to products that are designed to disclose their session keys, not to
identify which particular calls are compromised on a call-by-call identify which particular calls are compromised on a call-by-call
basis. This is an important legal distinction, because most basis. This is an important legal distinction, because most
government sanctioned wiretap regulations require a VoIP service government sanctioned wiretap regulations require a VoIP service
provider to not reveal which particular calls are wiretapped. But provider to not reveal which particular calls are wiretapped. But
there is nothing illegal about revealing that a product is designed there is nothing illegal about revealing that a product is designed
to be wiretap-friendly. The ZRTP protocol mandates that such a to be wiretap-friendly. The ZRTP protocol mandates that such a
product "out" itself. product "out" itself.
skipping to change at page 79, line 16 skipping to change at page 76, line 34
a back door at all. From a civic hygiene perspective, we are better a back door at all. From a civic hygiene perspective, we are better
off with having the Disclosure flag in the protocol. off with having the Disclosure flag in the protocol.
If an endpoint stores or logs SRTP keys or information that can be If an endpoint stores or logs SRTP keys or information that can be
used to reconstruct or recover SRTP keys after they are no longer in used to reconstruct or recover SRTP keys after they are no longer in
use (i.e. the session is active), or otherwise discloses or passes use (i.e. the session is active), or otherwise discloses or passes
SRTP keys or information that can be used to reconstruct or recover SRTP keys or information that can be used to reconstruct or recover
SRTP keys to another application or device, the Disclosure flag D SRTP keys to another application or device, the Disclosure flag D
MUST be set in the Confirm1 or Confirm2 message. MUST be set in the Confirm1 or Confirm2 message.
12.1. Guidelines on Proper Implementation of the Disclosure Flag 11.1. Guidelines on Proper Implementation of the Disclosure Flag
Some implementers have asked for guidance on implementing the Some implementers have asked for guidance on implementing the
Disclosure Flag. Some people have incorrectly thought that a Disclosure Flag. Some people have incorrectly thought that a
connection secured with ZRTP cannot be used in a call center, with connection secured with ZRTP cannot be used in a call center, with
voluntary voice recording, or even with a voicemail system. voluntary voice recording, or even with a voicemail system.
Similarly, some potential users of ZRTP have overconsidered the Similarly, some potential users of ZRTP have over considered the
protection that ZRTP can give them. These guidelines clarify both protection that ZRTP can give them. These guidelines clarify both
concerns. concerns.
The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself.
It does not govern the underlying RTP media stream, nor the actual It does not govern the underlying RTP media stream, nor the actual
media itself. Consequently, a PBX that uses ZRTP may provide media itself. Consequently, a PBX that uses ZRTP may provide
conference calls, call monitoring, call recording, voicemail, or conference calls, call monitoring, call recording, voicemail, or
other PBX features and still say that it does not disclose the ZRTP other PBX features and still say that it does not disclose the ZRTP
key material. A video system may provide DVR features and still say key material. A video system may provide DVR features and still say
that it does not disclose the ZRTP key material. The ZRTP Disclosure that it does not disclose the ZRTP key material. The ZRTP Disclosure
skipping to change at page 80, line 11 skipping to change at page 77, line 29
A user of ZRTP should note that ZRTP is not a panacea against A user of ZRTP should note that ZRTP is not a panacea against
unauthorized recording. ZRTP does not and cannot protect against an unauthorized recording. ZRTP does not and cannot protect against an
untrustworthy partner who holds a microphone up to the speaker. It untrustworthy partner who holds a microphone up to the speaker. It
does not protect against someone else being in the room. It does not does not protect against someone else being in the room. It does not
protect against analog wiretaps in the phone or in the room. It does protect against analog wiretaps in the phone or in the room. It does
not mean your partner has not been hacked with spyware. It does not not mean your partner has not been hacked with spyware. It does not
mean that the software has no flaws. It means that the ZRTP mean that the software has no flaws. It means that the ZRTP
subsystem is not knowingly leaking ZRTP cryptographic key material. subsystem is not knowingly leaking ZRTP cryptographic key material.
13. RTP Header Extension Flag for ZRTP 12. RTP Header Extension Flag for ZRTP
This specification defines a new RTP header extension used only for This specification defines a new RTP header extension used only for
discovery of support for ZRTP. No ZRTP data is transported in the discovery of support for ZRTP. No ZRTP data is transported in the
extension. When used, the X bit is set in the RTP header to indicate extension. When used, the X bit is set in the RTP header to indicate
the presence of the RTP header extension. the presence of the RTP header extension.
Section 5.3.1 in RFC 3550 [RFC3550] defines the format of an RTP Section 5.3.1 in RFC 3550 [RFC3550] defines the format of an RTP
Header extension. The Header extension is appended to the RTP Header extension. The Header extension is appended to the RTP
header. The first 16 bits are an identifier for the header header. The first 16 bits are an identifier for the header
extension, and the following 16 bits are length of the extension extension, and the following 16 bits are length of the extension
header in 32 bit words. The ZRTP flag RTP header extension has the header in 32 bit words. The ZRTP flag RTP header extension has the
value of 0x505A and a length of 0. The format of the header value of 0x505A and a length of 0. The format of the header
extension is as shown in the Figure below. extension is as shown in the Figure below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP Extension header format for ZRTP Flag Figure 18: RTP Extension header format for ZRTP Flag
RTP Extension header format for ZRTP Flag
ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at ZRTP endpoints MAY include the ZRTP Flag in RTP packets sent at the
the start of a session. For example, an endpoint may decide to start of a session. For example, an endpoint may decide to include
include the flag in the first 2 seconds of RTP packets sent. The the flag in the first 2 seconds of RTP packets sent. The inclusion
inclusion of the flag MAY be ended if a ZRTP message (such as Hello) of the flag MAY be ended if a ZRTP message (such as Hello) is
is received. received.
14. IANA Considerations 13. IANA Considerations
This specification defines a new SDP [RFC4566] attribute in This specification defines a new SDP [RFC4566] attribute in
Section 9. Section 8.
Contact name: Philip Zimmermann <prz@mit.edu> Contact name: Philip Zimmermann <prz@mit.edu>
Attribute name: "zrtp-hash". Attribute name: "zrtp-hash".
Type of attribute: Media level. Type of attribute: Media level.
Subject to charset: Not. Subject to charset: Not.
Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the
ZRTP protocol and provides a hash of the ZRTP Hello ZRTP protocol and provides a hash of the ZRTP Hello
message. The ZRTP protocol version number is also message. The ZRTP protocol version number is also
specified. specified.
Allowed attribute values: Hex. Allowed attribute values: Hex.
14. Appendix - Media Security Requirements
This section discuses how ZRTP meets all RTP security requirements
discussed in the Media Security Requirements
[I-D.ietf-sip-media-security-requirements] document without any
dependencies on other protocols or extensions, unlike DTLS-SRTP
[I-D.ietf-avt-dtls-srtp] which requires additional protocols and
mechanisms.
R-FORK-RETARGET is met since ZRTP is a media path key agreement
protocol.
R-DISTINCT is met since ZRTP uses ZIDs and allows multiple
independent ZRTP exchanges to proceed.
R-REUSE is met using the Multistream and Preshared modes.
R-AVOID-CLIPPING is met since ZRTP is a media path key agreement
protocol
R-RTP-VALID is met since the ZRTP packet format does not pass the
RTP validity check
R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and
responses.
R-NEGOTIATE is met using the Commit message.
R-PSTN is met since ZRTP can be implemented in Gateways.
R-PFS is met using ZRTP Diffie-Hellman key agreement methods.
R-COMPUTE is met using the Hello/Commit ZRTP exchange.
R-CERTS is met using the optional signature field in ZRTP Confirm
messages.
R-FIPS is met since ZRTP uses algorithms that allow FIPS
certification.
R-DOS is met since ZRTP does not introduce any new denial of
service attacks.
R-EXISTING is met since ZRTP can support the use of certificates
or keys.
R-AGILITY is met since the set of hash, cipher, authentication tag
length, key agreement method, SAS type, and signature type can all
be extended and negotiated.
R-DOWNGRADE is met since ZRTP has protection against downgrade
attacks.
R-PASS-MEDIA is met since ZRTP prevents a passive adversary with
access to the media path from gaining access to keying material
used to protect SRTP media packets.
R-PASS-SIG is met since ZRTP prevents a passive adversary with
access to the signaling path from gaining access to keying
material used to protect SRTP media packets.
R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs
and responses.
R-ID-BINDING is met using the a=zrtp-hash SDP attribute.
R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs
and responses.
R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and
hence best effort SRTP in every case.
R-OTHER-SIGNALING is met since ZRTP can utilize modes in which
there is no dependency on the signaling path.
R-RECORDING is met using the ZRTP Disclosure flag.
R-TRANSCODER is met if the transcoder operates as a trusted MitM
(i.e. a PBX).
R-ALLOW-RTP is met due to ZRTP's best effort encryption.
15. Security Considerations 15. Security Considerations
This document is all about securely keying SRTP sessions. As such, This document is all about securely keying SRTP sessions. As such,
security is discussed in every section. security is discussed in every section.
Most secure phones rely on a Diffie-Hellman exchange to agree on a Most secure phones rely on a Diffie-Hellman exchange to agree on a
common session key. But since DH is susceptible to a man-in-the- common session key. But since DH is susceptible to a man-in-the-
middle (MITM) attack, it is common practice to provide a way to middle (MiTM) attack, it is common practice to provide a way to
authenticate the DH exchange. In some military systems, this is done authenticate the DH exchange. In some military systems, this is done
by depending on digital signatures backed by a centrally-managed PKI. by depending on digital signatures backed by a centrally-managed PKI.
A decade of industry experience has shown that deploying centrally A decade of industry experience has shown that deploying centrally
managed PKIs can be a painful and often futile experience. PKIs are managed PKIs can be a painful and often futile experience. PKIs are
just too messy, and require too much activation energy to get them just too messy, and require too much activation energy to get them
started. Setting up a PKI requires somebody to run it, which is not started. Setting up a PKI requires somebody to run it, which is not
practical for an equipment provider. A service provider like a practical for an equipment provider. A service provider like a
carrier might venture down this path, but even then you have to deal carrier might venture down this path, but even then you have to deal
with cross-carrier authentication, certificate revocation lists, and with cross-carrier authentication, certificate revocation lists, and
other complexities. It is much simpler to avoid PKIs altogether, other complexities. It is much simpler to avoid PKIs altogether,
skipping to change at page 82, line 26 skipping to change at page 81, line 27
using a list of words such as the PGP word list[Juola2], in a manner using a list of words such as the PGP word list[Juola2], in a manner
analogous to how pilots use the NATO phonetic alphabet to convey analogous to how pilots use the NATO phonetic alphabet to convey
information. This can make it even more complicated for the information. This can make it even more complicated for the
attacker, because these words can be worked into the conversation in attacker, because these words can be worked into the conversation in
unpredictable ways. Remember that the attacker places a very high unpredictable ways. Remember that the attacker places a very high
value on not being detected, and if he makes a mistake, he doesn't value on not being detected, and if he makes a mistake, he doesn't
get to do it over. Some people have raised the question that even if get to do it over. Some people have raised the question that even if
the attacker lacks voice impersonation capabilities, it may be unsafe the attacker lacks voice impersonation capabilities, it may be unsafe
for people who don't know each other's voices to depend on the SAS for people who don't know each other's voices to depend on the SAS
procedure. This is not as much of a problem as it seems, because it procedure. This is not as much of a problem as it seems, because it
isn't necessary that they recognize each other by their voice, it's isn't necessary that they recognize each other by their voice, it is
only necessary that they detect that the voice used for the SAS only necessary that they detect that the voice used for the SAS
procedure matches the voice in the rest of the phone conversation. procedure matches the voice in the rest of the phone conversation.
A popular and field-proven approach is used by SSH (Secure Shell) A popular and field-proven approach is used by SSH (Secure Shell)
[RFC4251], which Peter Gutmann likes to call the "baby duck" security [RFC4251], which Peter Gutmann likes to call the "baby duck" security
model. SSH establishes a relationship by exchanging public keys in model. SSH establishes a relationship by exchanging public keys in
the initial session, when we assume no attacker is present, and this the initial session, when we assume no attacker is present, and this
makes it possible to authenticate all subsequent sessions. A makes it possible to authenticate all subsequent sessions. A
successful MITM attacker has to have been present in all sessions all successful MiTM attacker has to have been present in all sessions all
the way back to the first one, which is assumed to be difficult for the way back to the first one, which is assumed to be difficult for
the attacker. ZRTP's key continuity features are actually better the attacker. ZRTP's key continuity features are actually better
than SSH, for reasons described in Section 5.9.1. All this is than SSH, at least for VoIP, for reasons described in Section 15.1.
accomplished without resorting to a centrally-managed PKI. All this is accomplished without resorting to a centrally-managed
PKI.
We use an analogous baby duck security model to authenticate the DH We use an analogous baby duck security model to authenticate the DH
exchange in ZRTP. We don't need to exchange persistent public keys, exchange in ZRTP. We don't need to exchange persistent public keys,
we can simply cache a shared secret and re-use it to authenticate a we can simply cache a shared secret and re-use it to authenticate a
long series of DH exchanges for secure phone calls over a long period long series of DH exchanges for secure phone calls over a long period
of time. If we read aloud just one SAS, and then cache a shared of time. If we read aloud just one SAS, and then cache a shared
secret for later calls to use for authentication, no new voice secret for later calls to use for authentication, no new voice
authentication rituals need to be executed. We just have to remember authentication rituals need to be executed. We just have to remember
we did one already. we did one already.
If one party ever loses this cached shared secret, it is no longer If one party ever loses this cached shared secret, it is no longer
available for authentication of DH exchanges. This cache mismatch available for authentication of DH exchanges. This cache mismatch
situation is easy to detect by the party that still has a surviving situation is easy to detect by the party that still has a surviving
shared secret cache entry. If it fails to match, either there is a shared secret cache entry. If it fails to match, either there is a
MiTM attack or one side has lost their shared secret cache entry. MiTM attack or one side has lost their shared secret cache entry.
The user agent that discovers the cache mismatch MUST alert the user The user agent that discovers the cache mismatch must alert the user
that a cache mismatch has been detected, and that he must do a verbal that a cache mismatch has been detected, and that he must do a verbal
comparison of the SAS to distinguish if the mismatch is because of a comparison of the SAS to distinguish if the mismatch is because of a
MiTM attack or because of the other party losing her cache. From MiTM attack or because of the other party losing her cache. From
that point on, the two parties start over with a new cached shared that point on, the two parties start over with a new cached shared
secret. Then they can go back to omitting the voice authentication secret. Then they can go back to omitting the voice authentication
on later calls. on later calls.
A particularly compelling reason why this approach is attractive is A particularly compelling reason why this approach is attractive is
that SAS is easiest to implement when a graphical user interface or that SAS is easiest to implement when a graphical user interface or
some sort of display is available, which raises the question of what some sort of display is available, which raises the question of what
to do when a display is less conveniently available. For example, to do when a display is less conveniently available. For example,
some devices that implement ZRTP might have a graphical user some devices that implement ZRTP might have a graphical user
interface that is only visible through a web browser, such as a PBX interface that is only visible through a web browser, such as a PBX
or some other nearby device that implements ZRTP as a "bump-in-the- or some other nearby device that implements ZRTP as a "bump-in-the-
wire". If we take an approach that greatly reduces the need for a wire". If we take an approach that greatly reduces the need for a
SAS in each and every call, we can operate in products without a SAS in each and every call, we can operate in products without a
graphical user interface with greater ease. Then the SAS can be graphical user interface with greater ease. Then the SAS can be
compared less frequently through a web browser, or it might even be compared less frequently through a web browser, or it might even be
presented as needed to the local user through a locally generated presented as needed to the local user through a locally generated
voice prompt, which the local user hears and verbally repeats and voice prompt, which the local user hears and verbally repeats and
compares with the remote party. compares with the remote party. Using a voice prompt in this way is
purely for the local ZRTP user agent to render the SAS to the local
user, and is not to be confused with the verbal comparison of the SAS
between two human users.
It's a good idea to force your opponent to have to solve multiple It is a good idea to force your opponent to have to solve multiple
problems in order to mount a successful attack. Some examples of problems in order to mount a successful attack. Some examples of
widely differing problems we might like to present him with are: widely differing problems we might like to present him with are:
Stealing a shared secret from one of the parties, being present on Stealing a shared secret from one of the parties, being present on
the very first session and every subsequent session to carry out an the very first session and every subsequent session to carry out an
active MITM attack, and solving the discrete log problem. We want to active MiTM attack, and solving the discrete log problem. We want to
force the opponent to solve more than one of these problems to force the opponent to solve more than one of these problems to
succeed. succeed.
ZRTP can use different kinds of shared secrets. Each type of shared ZRTP can use different kinds of shared secrets. Each type of shared
secret is determined by a different method. All of the shared secret is determined by a different method. All of the shared
secrets are hashed together to form a session key to encrypt the secrets are hashed together to form a session key to encrypt the
call. An attacker must defeat all of the methods in order to call. An attacker must defeat all of the methods in order to
determine the session key. determine the session key.
First, there is the shared secret determined entirely by a Diffie- First, there is the shared secret determined entirely by a Diffie-
Hellman key agreement. It changes with every call, based on random Hellman key agreement. It changes with every call, based on random
numbers. An attacker may attempt a classic DH MITM attack on this numbers. An attacker may attempt a classic DH MiTM attack on this
secret, but we can protect against this by displaying and reading secret, but we can protect against this by displaying and reading
aloud a SAS, combined with adding a hash commitment at the beginning aloud an SAS, combined with adding a hash commitment at the beginning
of the DH exchange. of the DH exchange.
Second, there is an evolving shared secret, or ongoing shared secret Second, there is an evolving shared secret, or ongoing shared secret
that is automatically changed and refreshed and cached with every new that is automatically changed and refreshed and cached with every new
session. We will call this the cached shared secret, or sometimes session. We will call this the cached shared secret, or sometimes
the retained shared secret. Each new image of this ongoing secret is the retained shared secret. Each new image of this ongoing secret is
a non-invertable function of its previous value and the new secret a non-invertable function of its previous value and the new secret
derived by the new DH agreement. It's possible that no cached shared derived by the new DH agreement. It is possible that no cached
secret is available, because there were no previous sessions to shared secret is available, because there were no previous sessions
inherit this value from, or because one side loses its cache. to inherit this value from, or because one side loses its cache.
There are other approaches for key agreement for SRTP that compute a There are other approaches for key agreement for SRTP that compute a
shared secret using information in the signaling. For example, shared secret using information in the signaling. For example,
[RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing) [RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing)
[RFC3830] payload in SDP [RFC4566]. Or RFC 4568 (SDES) [RFC4568] [RFC3830] payload in SDP [RFC4566]. Or RFC 4568 (SDES) [RFC4568]
describes directly carrying SRTP keying and configuration information describes directly carrying SRTP keying and configuration information
in SDP. ZRTP does not rely on the signaling to compute a shared in SDP. ZRTP does not rely on the signaling to compute a shared
secret, but If a client does produce a shared secret via the secret, but if a client does produce a shared secret via the
signaling, and makes it available to the ZRTP protocol, ZRTP can make signaling, and makes it available to the ZRTP protocol, ZRTP can make
use of this shared secret to augment the list of shared secrets that use of this shared secret to augment the list of shared secrets that
will be hashed together to form a session key. This way, any will be hashed together to form a session key. This way, any
security weaknesses that might compromise the shared secret security weaknesses that might compromise the shared secret
contributed by the signaling will not harm the final resulting contributed by the signaling will not harm the final resulting
session key. session key.
There may also be a static shared secret that the two parties agree
on out-of-band in advance. A hashed passphrase would suffice.
The shared secret provided by the signaling (if available), the The shared secret provided by the signaling (if available), the
shared secret computed by DH, and the cached shared secret are all shared secret computed by DH, and the cached shared secret are all
hashed together to compute the session key for a call. If the cached hashed together to compute the session key for a call. If the cached
shared secret is not available, it is omitted from the hash shared secret is not available, it is omitted from the hash
computation. If the signaling provides no shared secret, it is also computation. If the signaling provides no shared secret, it is also
omitted from the hash computation. omitted from the hash computation.
No DH MITM attack can succeed if the ongoing shared secret is No DH MiTM attack can succeed if the ongoing shared secret is
available to the two parties, but not to the attacker. This is available to the two parties, but not to the attacker. This is
because the attacker cannot compute a common session key with either because the attacker cannot compute a common session key with either
party without knowing the cached secret component, even if he party without knowing the cached secret component, even if he
correctly executes a classic DH MITM attack. Mixing in the cached correctly executes a classic DH MiTM attack.
shared secret for the session key calculation allows it to act as an
implicit authenticator to protect the DH exchange, without requiring
additional explicit HMACs to be computed on the DH parameters. If
the cached shared secret is available, a MITM attack would be
instantly detected by the failure to achieve a shared session key,
resulting in undecryptable packets. The protocol can easily detect
this. It would be more accurate to say that the MITM attack is not
merely detected, but thwarted.
When adding the complexity of additional shared secrets beyond the 15.1. Self-healing Key Continuity Feature
familiar DH key agreement, we must make sure the lack of availability
of the cached shared secret cannot prevent a call from going through,
and we must also prevent false alarms that claim an attack was
detected.
An small added benefit of using these cached shared secrets to mix in The key continuity features of ZRTP are analogous to those provided
with the session keys is that it augments the entropy of the session by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH
key. Even if limits on the size of the DH exchange produces a caches public signature keys that never change, and uses a permanent
session key with less than 256 bits of real work factor, the added private signature key that must be guarded from disclosure. If
entropy from the cached shared secret can bring up all the subsequent someone steals your SSH private signature key, they can impersonate
session keys to the full 256-bit AES key strength, assuming no you in all future sessions and mount a successful MiTM attack any
attacker was present in the first call. time they want.
We could have authenticated the DH exchange the same way SSH does it, ZRTP caches symmetric key material used to compute secret session
with digital signatures, caching public keys instead of shared keys, and these values change with each session. If someone steals
secrets. But this approach with caching shared secrets seemed a bit your ZRTP shared secret cache, they only get one chance to mount a
simpler, requiring less CPU time for low-powered mobile platforms MiTM attack, in the very next session. If they miss that chance, the
because it avoids an added digital signature step. retained shared secret is refreshed with a new value, and the window
of vulnerability heals itself, which means they are locked out of any
future opportunities to mount a MiTM attack. This gives ZRTP a
"self-healing" feature if any cached key material is compromised.
The ZRTP SDP attributes convey information through the signaling that A MiTM attacker must always be in the media path. This presents a
is already available in clear text through the media path. For significant operational burden for the attacker in many VoIP usage
example, the ZRTP flag is equivalent to sending a ZRTP Hello message. scenarios, because being in the media path for every call is often
The SAS is calculated from a hash of material from ZRTP messages sent harder than being in the signaling path. This will likely create
over the media path. As a result, none of the ZRTP SDP attributes coverage gaps in the attacker's opportunities to mount a MiTM attack.
require confidentiality from the signaling. ZRTP's self-healing key continuity features are better than SSH at
exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP
quickly recovers from any disclosure of cached key material.
The ZRTP SAS attributes can use the signaling channel as an out-of- The infamous Debian OpenSSL weak key vulnerability [dsa-1571]
band authentication mechanism. This authentication is only useful if (discovered and patched in May 2008) offers a real-world example of
the signaling channel has end-to-end integrity protection. Note that why ZRTP's self-healing scheme is a good way to do key continuity.
the SIP Identity header field [RFC4474] provides middle-to-end The Debian bug resulted in the production of a lot of weak SSH (and
integrity protection across SDP message bodies which provides useful TLS/SSL) keys, which continued to compromise security even after the
protection for ZRTP SAS attributes. bug had been patched. In contrast, ZRTP's key continuity scheme adds
new entropy to the cached key material with every call, so old
deficiencies in entropy are washed away with each new session.
It should be noted that the addition of shared secret entropy from
previous sessions can extend the strength of the new session key to
AES-256 levels, even if the new session uses Diffie-Hellman keys no
larger than DH-3072 or ECDH-256, provided the cached shared secrets
were initially established when the wiretapper was not present. This
is why AES-256 MAY be used with the smaller DH key sizes in
Section 5.1.5.
Caching shared symmetric key material is also less CPU intensive
compared with using digital signatures, which may be important for
low-power mobile platforms.
16. Acknowledgments 16. Acknowledgments
The authors would like to thank Bryce Wilcox-O'Hearn for his The authors would like to thank Bryce Wilcox-O'Hearn and Colin Plumb
contributions to the design of this protocol, and to thank Jon for their contributions to the design of this protocol, and to thank
Peterson, Colin Plumb, Hal Finney, Colin Perkins, and Dan Wing for Hal Finney, Viktor Krikun, Werner Dittmann, Jon Peterson, Dan Wing,
their helpful comments and suggestions. Also thanks to David McGrew, Sagar Pai, Colin Perkins, David McGrew, and Roni Even for their
Roni Even, Viktor Krikun, Werner Dittmann, Allen Pulsifer, Klaus helpful comments and suggestions.
Peters, and Abhishek Arya for their feedback and comments.
The use of hash chains to key HMACs in ZRTP is similar to Adrian The use of hash chains to key HMACs in ZRTP is similar to Adrian
Perrig's TESLA protocol [TESLA]. Perrig's TESLA protocol [TESLA].
17. References 17. References
17.1. Normative References 17.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] 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, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
 End of changes. 348 change blocks. 
804 lines changed or deleted 790 lines changed or added

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