Network Working Group P. Zimmermann
Internet-Draft Zfone Project
Intended status: Informational A. Johnston, Ed.
Expires: August 28, 2008 Avaya
J. Callas
PGP Corporation
February 25, 2008
ZRTP: Media Path Key Agreement for Secure RTP
draft-zimmermann-avt-zrtp-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines ZRTP, a protocol for media path Diffie-Hellman
exchange to agree on a session key and parameters for establishing
Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP
protocol is media path keying because it is multiplexed on the same
port as RTP and does not require support in the signaling protocol.
Zimmermann, et al. Expires August 28, 2008 [Page 1]
Internet-Draft ZRTP February 2008
ZRTP does not assume a Public Key Infrastructure (PKI) or require the
complexity of certificates in end devices. For the media session,
ZRTP provides confidentiality, protection against man-in-the-middle
(MITM) attacks, and, in cases where a secret is available from the
signaling protocol, authentication. ZRTP can utilize two Session
Description Protocol (SDP) attributes to provide discovery and
authentication through the signaling channel. To provide best effort
SRTP, ZRTP utilizes normal RTP/AVP profiles.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Media Security Requirements . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 8
4.1.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 8
4.1.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 10
4.1.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 10
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Commit . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Shared Secret Determination . . . . . . . . . . . . . . . 13
5.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 13
5.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 13
5.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 14
5.4. Secret Generation . . . . . . . . . . . . . . . . . . . . 15
5.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 15
5.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 19
5.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 20
5.5. Key Generation . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 24
5.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Random Number Generation . . . . . . . . . . . . . . . . . 26
5.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 26
6. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 29
6.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 29
6.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 31
6.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 31
6.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 31
6.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 32
6.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 33
6.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 34
6.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 34
6.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 35
6.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 36
Zimmermann, et al. Expires August 28, 2008 [Page 2]
Internet-Draft ZRTP February 2008
6.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 39
6.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 41
6.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 43
6.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 45
6.9. Error message . . . . . . . . . . . . . . . . . . . . . . 46
6.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 47
6.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 48
6.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 48
6.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 49
6.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 51
7. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 52
8. Short Authentication String . . . . . . . . . . . . . . . . . 53
8.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 54
8.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 55
8.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 55
8.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 57
8.4. Rendering SAS for Multiple Media Streams . . . . . . . . . 58
9. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 58
9.1. Tying the media stream to the signaling layer via the
Hello Hash . . . . . . . . . . . . . . . . . . . . . . . . 59
9.2. Deriving the signaling secret (sigs) from the
signaling layer . . . . . . . . . . . . . . . . . . . . . 61
9.3. Deriving the SRTP secret (srtps) from the signaling
layer . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.4. Using the signaling path to check the SAS . . . . . . . . 62
10. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 64
11. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 65
12. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 67
12.1. Guidelines on Proper Implementation of the Disclosure
Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
13. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 69
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
14.1. IANA Registration of a=zrtp-hash SDP attribute . . . . . . 70
14.2. IANA Registration of a=zrtp-sas SDP attribute . . . . . . 71
15. Security Considerations . . . . . . . . . . . . . . . . . . . 71
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 75
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
17.1. Normative References . . . . . . . . . . . . . . . . . . . 76
17.2. Informative References . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 79
Zimmermann, et al. Expires August 28, 2008 [Page 3]
Internet-Draft ZRTP February 2008
1. Introduction
ZRTP is a key agreement protocol which performs Diffie-Hellman key
exchange during call setup in the media path, and is transported over
the same port as the Real-time Transport Protocol (RTP) [2] media
stream which has been established using a signaling protocol such as
Session Initiation Protocol (SIP) [24]. This generates a shared
secret which is then used to generate keys and salt for a Secure RTP
(SRTP) [3] session. ZRTP borrows ideas from PGPfone [19]. A
reference implementation of ZRTP is available as Zfone [20].
The ZRTP protocol has some nice cryptographic features lacking in
many other approaches to media session encryption. Although it uses
a public key algorithm, it does not rely on a public key
infrastructure (PKI). In fact, it does not use persistent public
keys at all. It uses ephemeral Diffie-Hellman (DH) with hash
commitment, and allows the detection of man-in-the-middle (MITM)
attacks by displaying a short authentication string for the users to
read and compare over the phone. It has Perfect Forward Secrecy,
meaning the keys are destroyed at the end of the call, which
precludes retroactively compromising the call by future disclosures
of key material. But even if the users are too lazy to bother with
short authentication strings, we still get reasonable authentication
against a MITM attack, based on a form of key 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, giving it key
continuity properties analogous to SSH. All this is done without
reliance on a PKI, key certification, trust models, certificate
authorities, or key management complexity that bedevils 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 all. It
performs its key agreements and key management in a purely peer-to-
peer manner over the RTP packet stream.
If the endpoints have a mechanism for knowing or retrieving the other
endpoint's signature key, the short authentication string can be
authenticated by exchanging a signature over the short authentication
string.
ZRTP can be used and discovered without being declared or indicated
in the signaling path. This provides a best effort SRTP capability.
Also, this reduces the complexity of implementations and minimizes
interdependency between the signaling and media layers. When ZRTP is
indicated in the signaling and the SDP attribute extensions are used,
ZRTP has additional useful properties. When the signaling path has
end-to-end integrity protection, the short authentication string can
be compared automatically by the ZRTP endpoints. By sending a hash
of the ZRTP Hello message in the signaling, ZRTP provides a useful
Zimmermann, et al. Expires August 28, 2008 [Page 4]
Internet-Draft ZRTP February 2008
binding between the signaling and media paths.
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
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 and
indicate requirement levels for compliant implementations [1].
3. Media Security Requirements
This section discuses how ZRTP meets all RTP security requirements
discussed in the SIP Working Group's Media Security Requirements [16]
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.
Zimmermann, et al. Expires August 28, 2008 [Page 5]
Internet-Draft ZRTP February 2008
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 and a=zrtp-sas SDP
attributes in INVITEs and responses.
R-ID-BINDING is met using the a=zrtp-hash and a=zrtp-sas SDP
attributes.
R-ACT-ACT is met using the a=zrtp-hash and a=zrtp-sas SDP
attributes 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 transoder operates as a trusted MitM
(i.e. a PBX).
Zimmermann, et al. Expires August 28, 2008 [Page 6]
Internet-Draft ZRTP February 2008
4. Overview
This section provides a description of how ZRTP works. This
description is non-normative in nature but is included to build
understanding of the protocol.
ZRTP is negotiated the same way a conventional RTP session is
negotiated in an offer/answer exchange using the standard AVP/RTP
profile. The ZRTP protocol begins after two endpoints have utilized
a signaling protocol such as SIP and are ready to exchange media. If
ICE [31] is being used, ZRTP begins after ICE has completed its
connectivity checks.
ZRTP is multiplexed on the same ports as RTP. It uses a unique
header that makes it clearly differentiable from RTP or STUN.
In environments in which sending ZRTP packets to non-ZRTP endpoints
might cause problems and signaling path discovery is not an option,
ZRTP endpoints can include the RTP header extension flag for ZRTP in
normal RTP packets sent at the start of a session as a probe to
discover if the other endpoint supports ZRTP. If the flag is
received from the other endpoint, ZRTP messages can then be
exchanged.
A ZRTP endpoint initiates the exchange by sending a ZRTP Hello
message to the other endpoint. The purpose of the Hello message is
to confirm the endpoint supports the protocol and to see what
algorithms the two ZRTP endpoints have in common.
The Hello message contains the SRTP configuration options, and the
ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID
that is generated once at installation time. ZIDs are discovered
during the Hello message exchange. The received ZID is used to look
up retained shared secrets from previous ZRTP sessions with the
endpoint.
A response to a ZRTP Hello message is a ZRTP HelloACK message. The
HelloACK message simply acknowledges receipt of the Hello. Since RTP
commonly uses best effort UDP transport, ZRTP has retransmission
timers in case of lost datagrams. There are two timers, both with
exponential backoff mechanisms. One timer is used for
retransmissions of Hello messages and the other is used for
retransmissions of all other messages after receipt of a HelloACK.
If an integrity protected signaling channel is available, a hash of
the Hello message can be sent. This allows rejection of false
injected ZRTP Hello messages by an attacker.
Zimmermann, et al. Expires August 28, 2008 [Page 7]
Internet-Draft ZRTP February 2008
Hello and other ZRTP messages also contain a hash image that is used
to link the messages together. This allows rejection of false
injected ZRTP messages during an exchange.
4.1. Key Agreement Modes
After both endpoints exchange Hello and HelloACK messages, the key
agreement exchange can begin with the ZRTP Commit message. ZRTP
supports a number of key agreement modes including both Diffie-
Hellman and non-Diffie-Hellman modes as described in the following
sections.
The Commit message may be sent immediately after both endpoints have
completed the Hello/HelloAck discovery handshake. Or it may be
deferred until later in the call, after the participants engage in
some unencrypted conversation. The Commit message may be manually
activated by a user interface element, such as a GO SECURE button,
which becomes enabled after the Hello/HelloAck discovery phase. This
emulates the user experience of a number of secure phones in the PSTN
world [22]. However, it is expected that most simple ZRTP user
agents will omit such buttons and proceed directly to secure mode by
sending a Commit message immediately after the Hello/HelloAck
handshake.
In all key agreement modes, the initiator sends no RTP media after
sending the Commit message, and begins sending SRTP media only after
receiving the Conf2Ack. The responder sends no RTP media after
receiving the Commit message, and begins sending SRTP media only
after receiving the Confirm2 message.
4.1.1. Diffie-Hellman Mode
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
reversed. That is, either Alice or Bob might send the first Hello
message. Note that the endpoint which sends the Commit message is
considered the initiator of the ZRTP session and drives the key
agreement exchange. The Diffie-Hellman public values are exchanged
in the DHPart1 and DHPart2 messages. SRTP keys and salts are then
calculated.
Zimmermann, et al. Expires August 28, 2008 [Page 8]
Internet-Draft ZRTP February 2008
Alice Bob
| |
| Alice and Bob establish a media session. |
| They initiate ZRTP on media ports |
| |
| F1 Hello (version, options, Alice's ZID) |
|-------------------------------------------------->|
| HelloACK F2 |
|<--------------------------------------------------|
| Hello (version, options, Bob's ZID) F3 |
|<--------------------------------------------------|
| F4 HelloACK |
|-------------------------------------------------->|
| |
| Bob acts as the initiator |
| |
| Commit (Bob's ZID, options, hvi) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
| |
| Alice and Bob generate SRTP session key. |
| |
| SRTP begins |
|<=================================================>|
| |
| F8 Confirm1 (HMAC, D,A,V,E flags, sig) |
|-------------------------------------------------->|
| Confirm2 (HMAC, D,A,V,E flags, sig) F9 |
|<--------------------------------------------------|
| F10 Conf2ACK |
|-------------------------------------------------->|
Figure 1. Establishment of an SRTP session using ZRTP
ZRTP authentication uses a Short Authentication String (SAS) which is
ideally displayed for the human user. Alternatively, the SAS can be
transported over the signaling channel in the SDP and compared
automatically, provided the signaling has end-to-end integrity
protection. Or, the SAS can be authenticated by exchanging a digital
signature (sig) over the short authentication string in the Confirm1
or Confirm2 messages.
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
agreement calculations were successful and thus the encryption will
Zimmermann, et al. Expires August 28, 2008 [Page 9]
Internet-Draft ZRTP February 2008
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
Enrollment flag (E). All flags are encrypted to shield them from a
passive observer.
4.1.2. Multistream Mode
Multistream mode is an alternative key agreement method when two
endpoints have an established SRTP media stream between them and
hence an active ZRTP Session key. ZRTP can derive multiple SRTP keys
from a single DH exchange. For example, an established secure voice
call that adds a video stream could use Multistream mode to quickly
initiate the video stream without a second DH exchange.
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
either endpoint and the DHPart1 and DHPart2 messages are omitted.
The Confirm1, Confirm2, and Conf2Ack messages are still sent. Since
the cache is not affected during this mode, multiple Multistream ZRTP
exchanges can be performed in parallel between two endpoints.
When adding additional media streams to an existing call, Multistream
mode SHOULD be used. Only one DH operation should be performed, just
for the first media stream. The DH exchange must be completed for
the first media stream before Multistream mode is used to add any
other media streams.
4.1.3. Preshared Mode
In the Preshared Mode, endpoints can skip the DH calculation if they
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
Multistream mode. The principal difference between Multistream mode
and Preshared mode is that Preshared mode uses a previously cached
shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess,
as the initial keying material.
This mode could be useful for slow processor endpoints so that a DH
calculation does not need to be performed every session. Or, this
mode could be used to rapidly re-establish an earlier session that
was recently torn down or interrupted without the need to perform
another DH calculation. Since the cache is not affected during this
mode, multiple Preshared mode exchanges can be processed at a time
between two endpoints.
A major drawback to Preshared mode is that it lacks Perfect Forward
Secrecy (PFS). For this reason, Preshared mode is not recommended
for establishing a second media stream. Multistream mode is designed
Zimmermann, et al. Expires August 28, 2008 [Page 10]
Internet-Draft ZRTP February 2008
for that role, without sacrificing PFS.
Because of the loss of PFS, Preshared mode should be used sparingly,
if used at all. Preshared mode is only included in this
specification to meet the R-REUSE requirement in the Media Security
Requirements [16] document. A series of preshared-keyed calls
between two ZRTP endpoints should use a DH key exchange periodically
to replace the cached key material, to limit the interval of exposure
from no PFS.
5. Protocol Description
ZRTP MUST be multiplexed on the same ports as the RTP media packets.
To support best effort encryption [16], ZRTP uses normal RTP/AVP
profile (AVP) media lines in the initial offer/answer exchange. The
ZRTP SDP attribute flag a=zrtp-hash defined in Section 9 SHOULD be
used in all offers and answers to indicate support for the ZRTP
protocol. The Secure RTP/AVP (SAVP) profile MAY be used in
subsequent offer/answer exchanges after a successful ZRTP exchange
has resulted in an SRTP session, or if it is known the other endpoint
supports this profile.
The use of the RTP/SAVP profile has caused failures in negotiating
best effort SRTP due to the limitations on negotiating profiles
using SDP. This is why ZRTP supports the RTP/AVP profile and
includes its own discovery mechanisms.
5.1. Discovery
During the ZRTP discovery phase, a ZRTP endpoint discovers if the
other endpoint supports ZRTP and the supported algorithms and
options. This information is transported in a Hello message.
ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers
and answers, as defined in Section 9. ZRTP MAY use an RTP [2]
extension field as a flag to indicate support for the ZRTP protocol
in RTP packets as described in Section 13.
The Hello message includes the ZRTP version, hash type, cipher type,
authentication method and tag length, key agreement type, and Short
Authentication String (SAS) algorithms that are supported. The Hello
message also includes a hash image as described in Section 10. In
addition, each endpoint sends and discovers ZIDs. The received ZID
is used to retrieve previous retained shared secrets, rs1 and rs2.
If the endpoint has other secrets, then they are also collected.
Details on how to derive the signaling secret, sigs, and SRTP secret,
Zimmermann, et al. Expires August 28, 2008 [Page 11]
Internet-Draft ZRTP February 2008
srtps, are in Section 9.
Additional shared secrets can be defined and used as other_secret.
For example, the trusted man in the middle key is used for
other_secret in PBX cases as described in Section 8.3. 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 comparisons in the
DHPart1 and DHPart2 messages. This prevents an eavesdropper from
knowing how many shared secrets are available between the endpoints.
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
ZRTP, and also if the SRTP implementations are compatible. A Hello
message is retransmitted using timer T1 and an exponential backoff
mechanism detailed in Section 7 until the receipt of a HelloACK
message or a Commit message.
The use of the a=zrtp-hash SDP attribute to authenticate the Hello
message is described in Section 9.1.
5.2. Commit
After both parties have received Hello messages, a Commit message can
be sent to begin the ZRTP key exchange. The endpoint that sends the
Commit is known as the initiator, while the receiver of the Commit is
known as the responder.
If both sides send Commit messages initiating a secure session at the
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 mode, then
the non-DH Commit is discarded and the DH Commit proceeds. If the
Commits are either both DH modes or both non-DH modes, then the
Commit message with the lowest hvi value is discarded and the other
side is the initiator.
Because the DH exchange affects the state of the retained shared
secret cache, only one in-process ZRTP DH exchange may occur at a
time between two ZRTP endpoints. Otherwise, race conditions and
cache integrity problems will result. When multiple media streams
are established in parallel between the same pair of ZRTP endpoints
(determined by the ZIDs in the Hello Messages), only one can be
processed. Once that exchange completes with Confirm2 and Conf2ACK
messages, another ZRTP DH exchange can begin. This constraint does
not apply when Multistream mode key agreement is used since the
cached shared secrets are not affected.
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
Zimmermann, et al. Expires August 28, 2008 [Page 12]
Internet-Draft ZRTP February 2008
resolution rules apply as if they were received on the same stream.
The media stream in which the Commit will proceed through the ZRTP
exchange while the media stream with the discarded Commit must wait
for the completion of the other ZRTP exchange.
5.3. Shared Secret Determination
The following sections describe how ZRTP endpoints generate the set
of shared secrets s1, s2, s3, s4, and s5 through the exchange of the
DHPart1 and DHPart2 messages.
5.3.1. Responder Behavior
The responder calculates an HMAC keyed hash using the first retained
shared secret, rs1, as the key on the string "Responder" which
generates a retained secret ID, rs1IDr, which is truncated to the
leftmost 64 bits. HMACs are calculated in a similar way for
additional shared secrets:
rs1IDr = HMAC(rs1, "Responder")
rs2IDr = HMAC(rs2, "Responder")
sigsIDr = HMAC(sigs, "Responder")
srtpsIDr = HMAC(srtps, "Responder")
other_secretIDr = HMAC(other_secret, "Responder")
The set of keyed hashes (HMACs) are included by the responder in the
DHPart1 message.
The HMACs of the possible shared secrets received in the DHPart2 can
be compared against the HMACs of the local set of possible shared
secrets.
The expected HMAC values of the shared secrets are calculated (using
the string "Initiator" instead of "Responder") as in Section 5.3.2
and compared to the HMACs received in the DHPart2 message. The
secrets corresponding to matching HMACs are kept while the secrets
corresponding to the non-matching ones are replaced with a null,
which is assumed to have a zero length for the purposes of hashing
them later. The set of up to five actual shared secrets are then s1,
s2, s3, s4, and s5 - the order is that chosen by the initiator.
5.3.2. Initiator Behavior
The initiator calculates an HMAC keyed hash using the first retained
shared secret, rs1, as the key on the string "Initiator" which
generates a retained secret ID, rs1IDi, which is truncated to the
leftmost 64 bits. HMACs are calculated in a similar way for
additional shared secrets:
Zimmermann, et al. Expires August 28, 2008 [Page 13]
Internet-Draft ZRTP February 2008
rs1IDi = HMAC(rs1, "Initiator")
rs2IDi = HMAC(rs2, "Initiator")
sigsIDi = HMAC(sigs, "Initiator")
srtpsIDi = HMAC(srtps, "Initiator")
other_secretIDi = HMAC(other_secret, "Initiator")
These HMACs are included by the initiator in the DHPart2 message.
The initiator then calculates the set of secret IDs that are expected
to be received from the responder in the DHPart1 message by
substituting the string "Responder" instead of "Initiator" as in
Section 5.3.1.
The HMACs of the possible shared secrets received are compared
against the HMACs of the local set of possible shared secrets.
The secrets corresponding to matching HMACs are kept while the
secrets corresponding to the non-matching ones are replaced with a
null, which is assumed to have a zero length for the purposes of
hashing them later. The set of up to five actual shared secrets are
then s1, s2, s3, s4, and s5 - the order is that chosen by the
initiator.
For example, consider two ZRTP endpoints who share secrets rs1, rs2,
and other_secret, which is a hash of a secret passphrase. During the
comparison, rs1ID, rs2ID, and other_secretID will match but sigsID
and srtpsID will not. As a result, s1 = rs1, s2 = rs2, s5 =
other_secret, while s3 and s4 will be nulls.
5.3.3. Handling a Shared Secret Cache Mismatch
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
man-in-the-middle (MiTM) attack, or one of the legitimate parties has
lost their cached shared secret by some mishap. Perhaps they
inadvertently deleted their cache, or their cache was lost or
disrupted due to restoring their disk from an earlier backup copy.
The party that has the surviving cache entry can easily detect that a
cache mismatch has occurred, because they expect their own cached
secret to match the other party's cached secret, but it does not
match. It is possible for both parties to detect this condition if
both parties have surviving cached secrets that have fallen out of
sync, due perhaps to one party restoring from a disk backup.
If either party discovers a cache mismatch, the user agent who makes
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
attack, and that the user should verbally compare the SAS with the
Zimmermann, et al. Expires August 28, 2008 [Page 14]
Internet-Draft ZRTP February 2008
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,
either because the user interface does not support it or because one
or both endpoints are unmanned devices, and no other SAS comparison
mechanism is available, the session MAY be terminated.
The session need not be terminated on a cache mismatch event if any
mechanism is available to determine if the SAS matches. This would
require either circumstances that allow human verbal 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 user interface
does not permit an SAS compare, the human user MUST 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
from a ZRTP user agent (specifically, Zfone [20]), designed for a
desktop PC graphical user interface environment. It is by no means
required that the alert be this detailed:
"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
simply lost his cache of shared secrets, but it could also mean
someone is trying to wiretap you. To resolve this question you
must check the authentication string with your partner. If it
doesn't match, it indicates the presence of a wiretapper."
5.4. Secret Generation
The next step is the generation of a secret for deriving SRTP keying
material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes,
described in the following sections.
5.4.1. Diffie-Hellman Mode
The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman
or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP
endpoints to generate a new shared secret, s0. In addition, the
endpoints discover if they have any shared secrets in common. If
they do, this exchange allows them to discover how many and agree on
an ordering for them: s1, s2, etc.
5.4.1.1. Hash Commitment
From the intersection of the algorithms in the sent and received
Hello messages, the initiator chooses a hash, cipher, auth tag, key
agreement type, and SAS type to be used.
A Diffie-Hellman mode is selected by setting the Key Agreement Type
Zimmermann, et al. Expires August 28, 2008 [Page 15]
Internet-Draft ZRTP February 2008
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
random Diffie-Hellman (DH) secret value (svi) based on the chosen key
agreement type value, and computing the public value. (Note that to
speed up processing, this computation can be done in advance.) For
guidance on generating random numbers, see the section on Random
Number Generation. The Diffie-Hellman secret value, svi, SHOULD be
twice as long as the AES key length. This means, 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.
pvi = g^svi mod p
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
width of the DH prime, and leading zeros MUST NOT be truncated.
The hash commitment is performed by the initiator of the ZRTP
exchange. The hash value of the initiator, hvi, includes a hash of
the entire DHPart2 message as shown in Figure 7 (which includes the
Diffie-Hellman public value, pvi), and the responder's Hello message:
hvi = hash(initiator's DHPart2 message | responder's Hello
message)
Note that the Hello message includes the fields shown in Figure 3.
The information from the responder's Hello message is included in the
hash calculation to prevent a bid-down attack by modification of the
responder's Hello message.
The initiator sends hvi in the Commit message.
5.4.1.2. Responder Behavior
Upon receipt of the Commit message, the responder generates its own
fresh random DH secret value, svr, and computes the public value.
(Note that to speed up processing, this computation can be done in
advance.) For guidance on random number generation, see the section
on Random Number Generation. The Diffie-Hellman secret value, svr,
SHOULD be twice as long as the AES key length. This means, 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.
pvr = g^svr mod p
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.
Zimmermann, et al. Expires August 28, 2008 [Page 16]
Internet-Draft ZRTP February 2008
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
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
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
responder computes its own value for the hash commitment using the
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. If they are different, a MITM attack is taking place and the
user is alerted and the protocol exchange terminated.
The responder then calculates the Diffie-Hellman result:
DHResult = pvi^svr mod p
5.4.1.3. Initiator Behavior
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
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
be computed. If pvr is 1 or p-1, the user should be alerted of the
attack and the protocol exchange MUST be terminated.
The initiator then sends a DHPart2 message containing the initiator's
public DH value and the set of calculated retained secret IDs as
described in 5.3.2.
The initiator calculates the same Diffie-Hellman result using:
DHResult = pvr^svi mod p
5.4.1.4. Shared Secret Calculation
A hash of the received and sent ZRTP messages in the current ZRTP
exchange in the following order is calculated:
total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2)
Note that only the ZRTP message (Figures 3, 5, 6, and 7), not the
entire ZRTP packets, are included in the total_hash.
For both the initiator and responder, the DHResult is formatted as a
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,
DHResult would be a 384 octet value, with the first octet the most
significant.
Zimmermann, et al. Expires August 28, 2008 [Page 17]
Internet-Draft ZRTP February 2008
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
[7]. This is done by hashing a concatenation of a number of 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
secrets as described in 5.2.
In section 5.8.1 of NIST SP 800-56A [7], NIST requires certain
parameters to be hashed together in a particular order, which NIST
refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo,
and SuppPrivInfo. In our implementation, our DHResult corresponds to
Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our ZIDi and ZIDr
correspond to PartyUInfo and PartyVInfo, our total_hash corresponds
to SuppPubInfo, and s1 through s5 corresponds to SuppPrivInfo. NIST
also requires a 32-bit 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 we only compute the hash once.
s0 = hash( counter | DHResult | "ZRTP-HMAC-KDF" | ZIDi | ZIDr |
total_hash | len(s1) | s1 | len(s2) | s2 | len(s3) | s3 | len(s4)
| s4 | len(s5) | s5 )
The length of the DHResult field was implicitly agreed to by the
negotiated DH prime size. The length of total_hash is implicitly
determined by the negotiated hash algorithm. All of the explicit
length fields, len(), in the above hash are 32-bit big-endian
integers, giving the length in octets of the field that follows.
Some of the shared secrets s1 through s5 may have lengths of zero if
they are null (not shared), and are each preceded by a 4-octet length
field. For example, if s4 is null, len(s4) is 0x00000000, and s4
itself would be absent from the hash calculation, which means len(s5)
would immediately follow len(s4). While inclusion of ZIDi and ZIDr
may be redundant, because they are implicitly included in the
total_hash, we explicitly include them here to follow NIST SP800-56A.
The string "ZRTP-HMAC-KDF" (not null-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 derivation function defined in
Section 5.5.
A new rs1 is calculated from s0:
rs1 = HMAC(s0,"retained secret")
After a successful exchange of Confirm1 and Confirm2 messages
described later in this document, both sides discard the rs2 value
and store rs1 as rs2.
A ZRTP Session Key is generated which then allows the ZRTP
Zimmermann, et al. Expires August 28, 2008 [Page 18]
Internet-Draft ZRTP February 2008
Multistream mode to be used to generate SRTP key and salt pairs for
additional concurrent media streams between this pair of ZRTP
endpoints. If a ZRTP Session Key has already been generated between
this pair of endpoints and is available, no new ZRTP Session Key is
calculated.
ZRTPsess = HMAC(s0,"ZRTP Session Key")
The ZRTPsess key is kept for the duration of the call signaling
session between the two ZRTP endpoints. That is, if there are two
separate calls between the endpoints (in SIP terms, separate SIP
dialogs), then a ZRTP Session Key MUST NOT be used across the two
call signaling sessions. At the end of the call signaling session,
ZRTPSess is destroyed.
5.4.2. Multistream Mode
The Multistream key agreement mode can be used to generate SRTP keys
and salts for additional media streams established between a pair of
endpoints. Multistream mode cannot be used unless there is an active
SRTP session established between the endpoints which means a ZRTP
Session key is active. This ZRTP Session key can be used to generate
keys and salts without performing another DH calculation. In this
mode, the retained shared secret cache is not used or updated. As a
result, multiple ZRTP Multistream mode exchanges can be processed in
parallel between two endpoints.
Multistream mode is selected by the initiator setting the Key
Agreement Type to "Mult" in the Commit message. The Cipher Type and
Auth Tag Length in Multistream mode MUST be set by the initiator to
the same as the values as in the initial DH Mode Commit. These
values in the Multistream commit packet SHOULD be ignored by the
responder, and SHOULD be assumed to be the same as the values in the
previous DH commit message. The SAS Type is ignored as there is no
SAS authentication in this mode.
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
chosen for active ZRTP sessions between a pair of endpoints. If a
Commit is received with a reused nonce value, the ZRTP exchange MUST
be immediately terminated.
Note: Since the nonce is used to calculate different SRTP key and
salt pairs for each media stream, a duplication will result in the
same key and salt being generated for the two media streams, which
would have disastrous security consequences.
If a Commit is received selecting Multistream mode, but the responder
Zimmermann, et al. Expires August 28, 2008 [Page 19]
Internet-Draft ZRTP February 2008
does not have a ZRTP Session Key available, the exchange MUST be
terminated.
In Multistream mode, both the DHPart1 and DHPart2 messages are not
sent. After receiving the Commit message from the initiator, the
responder sends the Confirm1 message after calculating this stream's
SRTP keys, as described below.
5.4.2.1. Shared Secret Calculation
A hash of the received and sent ZRTP messages in the current ZRTP
exchange for the current media stream is calculated:
total_hash = hash(Hello of responder | Commit )
This refers to the Hello and Commit messages for the current media
stream which is using Multistream mode, not the original media stream
that included a full DH key agreement. Note that only the ZRTP
message (Figures 3 and 5), not the entire ZRTP packets, are included
in the hash.
The SRTP keys and salts for the initiator and responder are
calculated using the ZRTP Session Key ZRTPSess and the nonce from the
Commit message. The nonce from the Commit message is implicitly
included in the total_hash, which hashed the entire Commit message
and the other party's Hello message. For the nth media stream:
s0n = HMAC(ZRTPSess, 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
image), thereby ensuring that each of the two parties can
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
unique nonce. Note also that the ZRTPSess key is derived from
material that also includes a different and more inclusive total_hash
from the entire packet sequence that performed the original DH
exchange for the first media stream in this ZRTP session.
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
the key generation formulas for this media stream.
5.4.3. Preshared Mode
The Preshared key agreement mode can be used to generate SRTP keys
and salts without a DH calculation, instead relying on a shared
secret from previous DH calculations between the endpoints.
Zimmermann, et al. Expires August 28, 2008 [Page 20]
Internet-Draft ZRTP February 2008
This key agreement mode is useful to rapidly re-establish a secure
session between two parties who have recently started and ended a
secure session that has already performed a DH key agreement, without
performing another lengthy DH calculation, which may be desirable on
slow processors in resource-limited environments. Preshared mode
MUST NOT be used for adding additional media streams to an existing
call. Multistream mode SHOULD be used, since it is designed for that
role, without sacrificing PFS.
5.4.3.1. Commitment
Preshared mode is selected by setting the Key Agreement Type to
Preshared in the Commit message. This results in the same call flow
as Multistream mode. The principal difference between Multistream
mode and Preshared mode is that Preshared mode uses a previously
cached shared secret, rs1, instead of an active ZRTP Session key,
ZRTPSess, as the initial keying material.
The Commit message is sent by the initiator of the ZRTP exchange.
From the intersection of the algorithms in the sent and received
Hello messages, the initiator chooses a hash, cipher, auth tag, key
agreement type, and SAS type to be used.
In place of hvi in the Commit, two smaller fields are inserted by the
initiator:
- A random nonce of length 4-words (16 octets).
- A keyID = HMAC(key, "Prsh") truncated to 64 bits.
The above HMAC key is the cached shared secret rs1, if one is
available or alternatively it could be the PBX trustemitmkey. If no
such shared key is available in the cache, Preshared mode cannot be
used.
The responder uses the received keyID to search for matching key
material in its cache, comparing it with hashes of rs1, rs2, or the
PBX trustedmitmkey.
When it finds the appropriate shared key, it is used to derive s0 and
a new ZRTPSess key, as described in the next section on Shared Secret
Calculation.
If the responder determines that it does not have a cached shared
secret from a previous DH exchange, it MAY respond with its own DH
Commit message. This would reverse the roles and the responder would
become the initiator, because the DH Commit must always "trump" the
Preshared Commit message as described in Section 5.2. The key
exchange would then proceeds using DH mode.
Zimmermann, et al. Expires August 28, 2008 [Page 21]
Internet-Draft ZRTP February 2008
Because Preshared mode depends on having a reliable shared secret in
its cache, it is RECOMMENDED that Preshared mode only be used when
the SAS Verified flag has been previously set.
If both sides send Preshared Commit messages initiating a secure
session at the same time, the Commit message with the lowest nonce
value is discarded and the other side is the initiator. This breaks
the tie, allowing the protocol to proceed from this point with a
clear definition of who is the initiator and who is the responder.
5.4.3.2. Shared Secret Calculation
A hash of the received and sent ZRTP messages in the current ZRTP
exchange for the current media stream is calculated:
total_hash = hash(Hello of responder | Commit )
Note that only the ZRTP message (Figures 3 and 5), not the entire
ZRTP packets, are included in the hash. The nonce from the Commit
message is implicitly included in the total_hash, which hashed the
entire Commit message and the other party's Hello message.
s0 = HMAC(rs1, total_hash) [use rs1, rs2, or whatever matched the
keyID]
ZRTPsess = HMAC(s0,"ZRTP Session Key")
Note that the responder's Hello message, included in the total_hash,
includes some unique nonce-derived material of its own (the H3 hash
image), thereby ensuring that each of the two parties can
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
unique nonce.
Note: Since the nonce is used to calculate different SRTP key and
salt pairs for each media stream, a duplication will result in the
same key and salt being generated for the two media streams, which
would have disastrous security consequences.
At this point in Preshared mode, the two endpoints begin key
generation as described in Section 5.5, now that there is a defined
s0 and ZRTPSess key. The ZRTPSess key allows the later use of
Multistream mode for adding additional media streams.
5.5. Key Generation
The following calculations derive a set of keys from s0. For the
original media stream that calculated s0 from the DH exchange, s0
means the original s0. For any additional media streams that were
Zimmermann, et al. Expires August 28, 2008 [Page 22]
Internet-Draft ZRTP February 2008
activated in Multistream mode, s0 means s0n, for the n-th media
stream.
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
function, keyed by s0, instead of simply drawing subkey material
directly from s0, as defined in NIST SP800-56A. The possibly greater
noninvertability of HMAC may add an extra measure of isolation for
the derived keys.
The SRTP master key and master salt are derived from s0. Separate
SRTP keys and salts are used in each direction for each media stream.
Unless otherwise specified, ZRTP uses SRTP with no MKI, 32 bit
authentication using HMAC-SHA1, AES-CM 128 or 256 bit key length, 112
bit session salt key length, 2^48 key derivation rate, and SRTP
prefix length 0.
The ZRTP initiator encrypts and the ZRTP responder decrypts packets
by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts
and the ZRTP initiator decrypts packets by using srtpkeyr and
srtpsaltr. These are generated by:
srtpkeyi = HMAC(s0,"Initiator SRTP master key")
srtpsalti = HMAC(s0,"Initiator SRTP master salt")
srtpkeyr = HMAC(s0,"Responder SRTP master key")
srtpsaltr = HMAC(s0,"Responder SRTP master salt")
The SRTP key and salt values are truncated (taking the leftmost bits)
to the length determined by the chosen SRTP algorithm.
The HMAC keys are the same length as the output of the underlying
hash function, and are thus generated without truncation by:
hmackeyi = HMAC(s0,"Initiator HMAC key")
hmackeyr = HMAC(s0,"Responder HMAC key")
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
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
encrypt the Confirm1 and Confirm2 messages. They are truncated to
the same size as the negotiated SRTP key size.
Zimmermann, et al. Expires August 28, 2008 [Page 23]
Internet-Draft ZRTP February 2008
zrtpkeyi = HMAC(s0,"Initiator ZRTP key")
zrtpkeyr = HMAC(s0,"Responder ZRTP key")
After s0 has been used to calculate all the subkeys that are derived
from it, it MUST be erased from memory. All other key material,
especially the SRTP keys and salts, MUST also be erased from memory
when they are no longer used, no later than the end of the call. The
only exceptions are the retained shared secrets, or other cached
secrets needed for future calls.
The Short Authentication String (SAS) value is calculated 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
streams which are derived from a single DH key agreement in a ZRTP
session.
sashash = HMAC(ZRTPSess,"SAS")
sasvalue = sashash [truncated to leftmost 32 bits]
5.6. Confirmation
The Confirm1 and Confirm2 messages contain the cache expiration
interval for the newly generated retained shared secret. The
flagoctet is an 8 bit unsigned integer made up of the PBX Enrollment
flag (E), Disclosure flag (D), Allow clear flag (A), SAS Verified
flag (V):
flagoctet = E * 2^3 + V * 2^2 + A * 2^1 + D * 2^0
Part of the Confirm1 and Confirm2 messages are encrypted using full-
block Cipher Feedback Mode, and contain a 128-bit random CFB
Initialization Vector (IV). The Confirm1 and Confirm2 messages also
contain an HMAC covering the encrypted part of the Confirm1 or
Confirm2 message which includes a string of zeros, the signature
length, flag octet, cache expiration interval, signature type block
(if present) and signature block (if present). For the responder
hmac = HMAC(hmackeyr, encrypted part of Confirm1)
For the initiator:
hmac = HMAC(hmackeyi, encrypted part of Confirm2)
The Conf2ACK message sent by the responder completes the exchange.
Zimmermann, et al. Expires August 28, 2008 [Page 24]
Internet-Draft ZRTP February 2008
5.7. Termination
The Error message is used to terminate an in-progress ZRTP exchange
due to an error. The Error message contains an integer Error Code
for debugging purposes. The termination of a ZRTP key agreement
exchange results in no updates to the cached shared secrets and
deletion of all crypto context.
The ZRTP Session key is only deleted if the ZRTP session in which it
was generated and all ZRTP sessions which are using it are
terminated.
The GoClear message is used to switch from SRTP to 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 the GoGlear
Message computed with the hmackey derived from the shared secret.
When sent by the initiator:
clear_hmac = HMAC(hmackeyi, "GoClear ")
When sent by the responder:
clear_hmac = HMAC(hmackeyr, "GoClear ")
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
ignored, and no ClearACK is sent.
A ZRTP endpoint MAY choose to accept GoClear messages after the
session has switched to SRTP, allowing the session to revert to RTP.
This is indicated in the Confirm1 or Confirm2 messages by setting the
Allow Clear flag (A). If both endpoints set the Allow Clear (A) flag
in their Confirm message, GoClear messages MAY be sent.
A ZRTP endpoint that receives a GoClear authenticates the message by
checking the clear_hmac. If the message authenticates, the endpoint
stops sending SRTP packets, generates a ClearACK in response, and
deletes all the crypto key material for the SRTP session. Until
confirmation from the user is received (e.g. clicking a button,
pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending
RTP packets. The endpoint then renders an indication that the media
session has switched to clear mode to the user and waits for
confirmation from the user. To prevent pinholes from closing or NAT
bindings from expiring, the ClearACK message MAY be resent at regular
intervals (e.g. every 5 seconds) while waiting for confirmation from
the user. After confirmation of the notification is received from
the user, the sending of RTP packets may begin.
Zimmermann, et al. Expires August 28, 2008 [Page 25]
Internet-Draft ZRTP February 2008
After sending a GoClear message, the ZRTP endpoint stops sending SRTP
packets. When a ClearACK is received, the ZRTP endpoint deletes the
crypto context for the SRTP session and may then resume sending RTP
packets.
In the event a ClearACK is not received before the retransmissions of
GoClear are exhausted, the key material is deleted.
After the users have transitioned from SRTP media back to RTP media
(clear mode), they may decide later to return to secure mode by
manual activation, usually by pressing a GO SECURE button. In that
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
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
thus have already discovered each other's ZRTP capabilities. It is
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
days of secure PSTN phones.
5.8. Random Number Generation
The ZRTP protocol uses random numbers for cryptographic key material,
notably for the DH secret exponents and nonces, which must be freshly
generated with each session. Whenever a random number is needed, all
of the following criteria must be satisfied:
It MUST be freshly generated, meaning that it must not have been used
in a previous calculation.
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].
It MUST be derived from a physical entropy source, such as RF noise,
acoustic noise, thermal noise, high resolution timings of
environmental events, or other unpredictable physical sources of
entropy. For a detailed explanation of cryptographic grade random
numbers and guidance for collecting suitable entropy, see RFC 4086
[18] and Chapter 10 of Practical Cryptography [17]. The raw entropy
must be distilled and processed through a deterministic random bit
generator (DRBG). Examples of DRBGs may be found in NIST SP 800-90
[6], and in [17].
5.9. ZID and Cache Operation
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
retained shared secrets in a local cache. A single global ZID for a
Zimmermann, et al. Expires August 28, 2008 [Page 26]
Internet-Draft ZRTP February 2008
single installation is the simplest way to implement ZIDs. However,
it is specifically not precluded for an implementation to use
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
to any other associations between a different pair of parties. It is
a goal of this protocol to permit both options to interoperate
freely.
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
endpoint. The previous retained shared secret is then renamed rs2
and also stored in the cache. For the new retained shared secret,
each endpoint chooses a cache expiration value which is an unsigned
32 bit integer of the number of seconds that this secret should be
retained in the cache. The time interval is relative to when the
Confirm1 message is sent or received.
The cache intervals are exchanged in the Confirm1 and Confirm2
messages. The actual cache interval used by both endpoints is the
minimum of the values from the Confirm1 and Confirm2 messages. A
value of 0 seconds means the newly-computed shared secret SHOULD NOT
be stored in the cache, and if a cache entry already exists from an
earlier call, the stored cache interval should be set to 0. A value
of 0xffffffff means the secret should be cached indefinitely and is
the recommended value. If the ZRTP exchange results in no new shared
secret generation (i.e. Multistream Mode), the field in the Confirm1
and Confirm2 is set to 0xffffffff and ignored, and the cache is not
updated.
The expiration interval need not be used to force the deletion of a
shared secret from the cache when the interval has expired. It just
means the shared secret MAY be deleted from that cache at any point
after the interval has expired without causing the other party to
note it as an unexpected security event when the next key negotiation
occurs between the same two parties. This means there need not be
perfectly synchronized deletion of expired secrets from the two
caches, and makes it easy to avoid a race condition that might
otherwise be caused by clock skew.
6. ZRTP Messages
All ZRTP messages use the message format defined in Figure 2. All
word lengths referenced in this specification are 32 bits or 4
octets. All integer fields are carried in network byte order, that
is, most significant byte (octet) first, commonly known as big-
endian.
Zimmermann, et al. Expires August 28, 2008 [Page 27]
Internet-Draft ZRTP February 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZRTP Magic Cookie (0x5a525450) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZRTP Message (length depends on Message Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. ZRTP Packet Format
The Sequence Number is a count that is incremented for each ZRTP
packet sent. The count is initialized to a random value. This is
useful in estimating ZRTP packet loss and also detecting when ZRTP
packets arrive out of sequence.
The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a
ZRTP packet, and has the value 0x5a525450.
Source Identifier is the SSRC number of the RTP stream that this ZRTP
packet relates to. For cases of forking or forwarding, RTP and hence
ZRTP may arrive at the same port from several different sources -
each of these sources will have a different SSRC and may initiate an
independent ZRTP protocol session.
This format is clearly identifiable as non-RTP due to the first two
bits being zero which looks like RTP version 0, which is not a valid
RTP version number. It is clearly distinguishable from STUN since
the magic cookies are different. The 12 not used bits are set to
zero and MUST be ignored when received.
The ZRTP Messages are defined in Figures 3 to 11 and are of variable
length.
The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as
defined in RFC 3309 [5] to detect transmission errors. ZRTP packets
are typically transported by UDP, which carries its own built-in 16-
bit checksum for integrity, but ZRTP does not rely on it. This is
because of the effect of an undetected transmission error in a ZRTP
message. For example, an undetected error in the DH exchange could
appear to be an active man-in-the-middle attack. The psychological
Zimmermann, et al. Expires August 28, 2008 [Page 28]
Internet-Draft ZRTP February 2008
effects of a false announcement of this by ZTRP clients can not be
overstated. The probability of such a false alarm hinges on a mere
16-bit checksum that usually protects UDP packets, so more error
detection is needed. For these reasons, this belt-and-suspenders
approach is used to minimize the chance of a transmission error
affecting the ZRTP key agreement.
The CRC is calculated across the entire ZRTP packet shown in 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 is silently
discarded.
6.1. ZRTP Message Formats
ZRTP messages are designed to simplify endpoint parsing requirements
and to reduce the opportunities for buffer overflow attacks (a good
goal of any security extension should be to not introduce new attack
vectors).
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
Agreement Type, and Authentication Tag. The values in the blocks are
ASCII strings which are extended with spaces (0x20) to make them the
desired length. Currently defined block values are listed in Tables
1-6 below.
Additional block values may be defined and used.
ZRTP uses this ASCII encoding to simplify debugging and make it
"Wireshark (Ethereal) friendly".
6.1.1. Message Type Block
Currently 14 Message Type Blocks are defined - they represent the set
of ZRTP message primitives. ZRTP endpoints MUST support the Hello,
HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK,
SASrelay, RelayACK, Error and ErrorACK block types. ZRTP endpoints
MAY support the GoClear and ClearACK messages. Additional messages
may be defined in extensions to ZRTP.
Zimmermann, et al. Expires August 28, 2008 [Page 29]
Internet-Draft ZRTP February 2008
Message Type Block | Meaning
---------------------------------------------------
"Hello " | Hello Message
| defined in Section 6.2
---------------------------------------------------
"HelloACK" | HelloACK Message
| defined in Section 6.3
---------------------------------------------------
"Commit " | Commit Message
| defined in Section 6.4
---------------------------------------------------
"DHPart1 " | DHPart1 Message
| defined in Section 6.5
---------------------------------------------------
"DHPart2 " | DHPart2 Message
| defined in Section 6.6
---------------------------------------------------
"Confirm1" | Confirm1 Message
| defined in Section 6.7
---------------------------------------------------
"Confirm2" | Confirm2 Message
| defined in Section 6.7
---------------------------------------------------
"Conf2ACK" | Conf2ACK Message
| defined in Section 6.8
---------------------------------------------------
"Error " | Error Message
| defined in Section 6.9
---------------------------------------------------
"ErrorACK" | ErrorACK Message
| defined in Section 6.10
---------------------------------------------------
"GoClear " | GoClear Message
| defined in Section 6.11
---------------------------------------------------
"ClearACK" | ClearACK Message
| defined in Section 6.12
---------------------------------------------------
"SASrelay" | SASrelay Message
| defined in Section 6.13
---------------------------------------------------
"RelayACK" | RelayACK Message
| defined in Section 6.14
---------------------------------------------------
Table 1. Message Block Type Values
Zimmermann, et al. Expires August 28, 2008 [Page 30]
Internet-Draft ZRTP February 2008
6.1.2. Hash Type Block
Only one Hash Type is currently defined, SHA256, and all ZRTP
endpoints MUST support this hash. Additional Hash Types can be
registered and used.
Hash Type Block | Meaning
---------------------------------------------------
"S256" | SHA-256 Hash defined in [SHA-256]
---------------------------------------------------
Table 2. Hash Block Type Values
6.1.3. Cipher Type Block
All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES-
256 (AES3). or other Cipher Types. Also, if AES-128 is used, DH3k
should be used. If AES-256 is used, the public key echange algorithm
should be one of EC38, EC52, or DH4k.
Note: DH4k may be deprecated in the future in favor of elliptic curve
algorithms.
Cipher Type Block | Meaning
---------------------------------------------------
"AES1" | AES-CM with 128 bit keys
| as defined in RFC 3711
---------------------------------------------------
"AES3" | AES-CM with 256 bit keys
| as defined in RFC 3711
---------------------------------------------------
Table 3. Cipher Block Type Values
6.1.4. Auth Tag Block
All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and
80 bit length tags as defined in RFC 3711.
Auth Tag Block | Meaning
---------------------------------------------------
"HS32" | HMAC-SHA1 32 bit authentication
| tag as defined in RFC 3711
---------------------------------------------------
"HS80" | HMAC-SHA1 80 bit authentication
| tag as defined in RFC 3711
---------------------------------------------------
Zimmermann, et al. Expires August 28, 2008 [Page 31]
Internet-Draft ZRTP February 2008
Table 4. Auth Tag Values
6.1.5. Key Agreement Type Block
All ZRTP endpoints MUST support DH3k and Multistream, SHOULD support
Preshared, and MAY support EC25, EC38, EC52, or DH4k. For DH3k or
DH4k, ZRTP endpoints MUST use the DH generator g=2.
If Elliptic Curve DH is used, the ECDH algorithm and key generation
is from NIST SP 800-56A [7]. The curves used are from NSA Suite B
[8], which uses the same curves as ECDSA defined by FIPS 186-3 [10],
and can also be found in RFC 4753 [9], sections 3.1 through 3.3. The
validation procedures are from NIST SP 800-56A [7] section 5.6.2.6,
method 3, ECC Partial Validation. Both the X and Y coordinates of
the point on the curve are sent, in the first and second half of the
ECDH public value, respectively.
The choice of AES key length is coupled to the choice of key
agreement type. If AES 128 is chosen, DH3k SHOULD be used. If AES
256 is chosen, one of EC38, EC52, or DH4k SHOULD be used. ZRTP also
defines a non-DH mode, Multistream, which MUST be supported. In
Multistream mode, the SRTP key is derived from a shared secret and
some nonce material.
Note: DH4k may be deprecated in the future in favor of elliptic curve
algorithms.
Table 5 lists the pv length in words and DHPart1 and DHPart2 message
length in words for each Key Agreement Type Block.
Zimmermann, et al. Expires August 28, 2008 [Page 32]
Internet-Draft ZRTP February 2008
Key Agreement | pv | message | Meaning
Type Block | words | words |
---------------------------------------------------
"DH3k" | 96 | 119 | DH mode with p=3072 bit prime
| | | as defined in RFC 3526
---------------------------------------------------
"DH4k" | 128 | 151 | DH mode with p=4096 bit prime
| | | as defined in RFC 3526
---------------------------------------------------
"Prsh" | - | - | Preshared Non-DH mode
| | |
---------------------------------------------------
"Mult" | - | - | Multistream Non-DH mode
| | |
---------------------------------------------------
"EC25" | 16 | 39 | Elliptic Curve DH, P-256
| | | per RFC 4753, Section 3.1
---------------------------------------------------
"EC38" | 24 | 47 | Elliptic Curve DH, P-384
| | | per RFC 4753, Section 3.2
---------------------------------------------------
"EC52" | 33 | 56 | Elliptic Curve DH, P-521
| | | per RFC 4753, Section 3.3
---------------------------------------------------
Table 5. Key Agreement Block Type Values
6.1.6. SAS Type Block
All ZRTP endpoints MUST support the base32 and MAY support base256
Short Authentication String scheme, and other SAS rendering schemes.
The ZRTP SAS is described in Section 7.
SAS Type Block | Meaning
---------------------------------------------------
"B32 " | Short Authentication String using
| base32 encoding defined in Section 8.
---------------------------------------------------
"B256" | Short Authentication String using
| base256 encoding defined in Section 8.
---------------------------------------------------
Table 6. SAS Block Type 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.
Zimmermann, et al. Expires August 28, 2008 [Page 33]
Internet-Draft ZRTP February 2008
6.1.7. Signature Type Block
The signature type block is a 4 octet (1 word) block used to
represent the signature algorithm. Suggested signature algorithms
and key lengths are a future subject of standardization.
6.2. Hello message
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
32 bit words. This length includes only the ZRTP message (including
the preamble and the length) but not the ZRTP header or CRC.
Next is the Message Type Block and a 4 character string containing
the version (ver) of the ZRTP protocol, currently "0.83" (when this
specification reaches RFC status, the protocol version will become
"1.00"). Next is the Client Identifier string (cid) which is 4 words
long and identifies the vendor and release of the ZRTP software. The
256-bit hash image H3 is defined in Section 10. The next parameter
is the ZID, the 96 bit long unique identifier for the ZRTP endpoint.
The next four bits contains flag bits. The Passive flag (P) is a
Boolean normally set to False. A ZRTP endpoint which is configured
to never 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 when sent and ignored on receipt.
Next is a list of supported Hash algorthms, Cipher algorithms, SRTP
Auth Tag types, Key Agreement types, and SAS types. The number of
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.
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
algorithms are supported. Mandatory algorithms MAY be included in
the list. The order of the list indicates the preferences of the
endpoint. If a mandatory algorithm is not included in the list, it
is added to the end of the list for preference.
Note: Implementers are encouraged to keep these algorithm lists small
- the list does not need to include every cipher and hash supported,
just the ones the endpoint would prefer to use for this ZRTP
exchange.
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
the sender's H2 (defined in Section 10), and thus cannot be checked
by the receiving party until the sender's H2 value is known to the
receiving party.
Zimmermann, et al. Expires August 28, 2008 [Page 34]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Hello " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="0.83" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client Identifier (4 words) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H3 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|P| unused (zeros)| hc | cc | ac | kc | sc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorthms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorthms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key agreement types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Hello message format
6.3. HelloACK message
The HelloACK message is used to stop retransmissions of a Hello
message. A HelloACK is sent regardless if the version number in the
Hello is supported or the algorithm list supported. The receipt of a
HelloACK stops retransmission of the Hello message. The format is
Zimmermann, et al. Expires August 28, 2008 [Page 35]
Internet-Draft ZRTP February 2008
shown in Figure 4 below. Note that a Commit message can be sent in
place of a HelloACK by an Initiator.
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="HelloACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. HelloACK message format
6.4. Commit message
The Commit message is sent to initiate the key agreement process
after both sides have received a Hello message, which means it can
only be sent after receiving both a Hello message and a HelloACK
message. The Commit message contains the Initiator's ZID and a list
of selected algorithms (hash, cipher, auth tag type, key agreement,
sas type), the ZRTP mode, and hvi, a hash of the DHPart2 of the
Initiator and the algorithm list from the Responder's Hello message.
The hash image H2 is defined in Section 10. The Commit Message
formats are shown in Figures 5a, 5b, and 5c.
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
the sender's H1 (defined in Section 10), and thus cannot be checked
by the receiving party until the sender's H1 value is known to the
receiving party.
Zimmermann, et al. Expires August 28, 2008 [Page 36]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key agreement type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| hvi (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5a. DH Commit message format
Zimmermann, et al. Expires August 28, 2008 [Page 37]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key agreement type = "Multi" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5b. Multistream Commit message format
Zimmermann, et al. Expires August 28, 2008 [Page 38]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorihm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key agreement type = "Prsh" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key-ID (2 words) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5c. Preshared Commit message format
6.5. DHPart1 message
The DHPart1 message begins the DH exchange. The format is shown in
Figure 5 below. The DHPart1 message is sent by the Responder if a
valid Commit message is received from the Initiator. The length of
the pvr value and the length of the DHPart1 message depends on the
Key Agreement Type chosen. This information is contained in Table 5.
Note that for Multistream mode, no DHPart1 or DHPart2 message will be
Zimmermann, et al. Expires August 28, 2008 [Page 39]
Internet-Draft ZRTP February 2008
sent.
The 256-bit hash image H1 is defined in Section 10.
The next five parameters are HMACs of potential shared secrets used
in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are
the HMACs of the responder's two retained shared secrets, truncated
to 64 bits. Next is sigsIDr, the HMAC of the responder's signaling
secret, truncated to 64 bits. Next is srtpsIDr, the HMAC of the
responder's SRTP secret, truncated to 64 bits. The last parameter is
the HMAC of an additional shared secret. For example, if multiple
SRTP secrets are available or some other secret is used, it can be
used as the other_secret. The Message format for the DHPart1 message
is shown in Figure 6.
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
the sender's H0 (defined in Section 10), and thus cannot be checked
by the receiving party until the sender's H0 value is known to the
receiving party.
Zimmermann, et al. Expires August 28, 2008 [Page 40]
Internet-Draft ZRTP February 2008
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 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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sigsIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srtpsIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| other_secretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvr (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. DHPart1 message format
6.6. DHPart2 message
The DHPart2 message completes the DH exchange. A DHPart2 message is
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
message depends on the Key Agreement Type chosen. This information
is contained in Table 5. Note that for Multistream mode, no DHPart1
or DHPart2 message will be sent.
Zimmermann, et al. Expires August 28, 2008 [Page 41]
Internet-Draft ZRTP February 2008
The 256-bit hash image H1 is defined in Section 10.
The next five parameters are HMACs of potential shared secrets used
in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are
the HMACs of the initiator's two retained shared secrets, truncated
to 64 bits. Next is sigsIDi, the HMAC of the initiator's signaling
secret, truncated to 64 bits. Next is srtpsIDi, the HMAC of the
initiator's SRTP secret, truncated to 64 bits. The last parameter is
the HMAC of an additional shared secret. For example, if multiple
SRTP secrets are available or some other secret is used, it can be
included. The message format for the DHPart2 message is shown in
Figure 7.
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
the sender's H0 (defined in Section 10), and thus cannot be checked
by the receiving party until the sender's H0 value is known to the
receiving party.
Zimmermann, et al. Expires August 28, 2008 [Page 42]
Internet-Draft ZRTP February 2008
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 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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sigsIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srtpsIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| other_secretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvi (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. DHPart2 message format
6.7. Confirm1 and Confirm2 messages
The Confirm1 message is sent by the Responder in response to a valid
DHPart2 message after the SRTP session key and parameters have been
negotiated. The Confirm2 message is sent by the Initiator in
response to a Confirm1 message. The format is shown in Figure 8
below. The message contains the Message Type Block "Confirm1" or
"Confirm2". Next is the HMAC, a keyed hash over encrypted part of
the message (shown enclosed by "===" in Figure 8.) The next 16
Zimmermann, et al. Expires August 28, 2008 [Page 43]
Internet-Draft ZRTP February 2008
octets contain the CFB Initialization Vector. The rest of the
message is encrypted using CFB and protected by the HMAC.
The first field inside the encrypted region is the hash pre-image H0,
which is defined in detail in Section 10.
The next 16 bits are not used. They SHOULD be set to zero and MUST
be ignored in received Confirm1 or Confirm2 messages.
The next 8 bits contain the signature length. If no SAS signature
(described in Section 8.2) is present, all bits are set to zero. The
signature length is in words and includes the signature type block.
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
present, the overall length of the Confirm1 or Confirm2 Message will
be set to 15 words.
The next 8 bits are used for flags. Undefined flags are set to zero
and ignored. Four flags are currently defined. The Disclosure Flag
(D) is a Boolean bit defined in Section 12. The Allow Clear flag (A)
is a Boolean bit defined in Section 5.11. The SAS Verified flag (V)
is a Boolean bit defined in Section 8.1. The PBX Enrollment flag (E)
is a Boolean bit defined in Section 8.3. The cache expiration
interval is an unsigned 32 bit integer of the number of seconds that
the newly generated cached shared secret, rs1, should be stored.
If the signature length (in words) is non-zero, a signature type
block will be present along with a signature block. Next is the
signature block. The signature block includes the key used to
generate the signature.
CFB [11] mode is applied with a feedback length of 128-bits, a full
cipher block, and the final block is truncated to match the exact
length of the encrypted data. The CFB Initialization Vector is 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 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
"======" in Figure 8).
The responder uses the zrtpkeyr to encrypt the Confirm1 message. The
initiator uses the zrtpkeyi to encrypt the Confirm2 message.
Zimmermann, et al. Expires August 28, 2008 [Page 44]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Confirm1" or "Confirm2" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| |
| Hash pre-image H0 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (Set to zero, ignored) | sig length |0 0 0 0|E|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cache expiration interval (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 8. Confirm1 and Confirm2 message format
6.8. Conf2ACK message
The Conf2ACK message is sent by the Responder in response to a valid
Confirm2 message. The message format for the Conf2ACK is shown in
Figure 9. The receipt of a Conf2ACK stops retransmission of the
Confirm2 message.
Zimmermann, et al. Expires August 28, 2008 [Page 45]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Conf2ACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Conf2ACK message format
6.9. Error message
The Error message is sent to terminate an in-process ZRTP key
agreement exchange due to an error. The format is shown in Figure 10
below. The use of the Error message is described in Section 5.11.
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Error " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Error Code (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Error message format
Defined hexadecimal values for the Error Code are listed in Table 7.
Zimmermann, et al. Expires August 28, 2008 [Page 46]
Internet-Draft ZRTP February 2008
Error Code | Meaning
---------------------------------------------------
0x10 | Malformed packet (CRC OK, but wrong structure)
---------------------------------------------------
0x20 | Critical software error
---------------------------------------------------
0x30 | Unsupported ZRTP version
---------------------------------------------------
0x40 | Hello components mismatch
---------------------------------------------------
0x51 | Hash type not supported
---------------------------------------------------
0x52 | Cipher type not supported
---------------------------------------------------
0x53 | Public key exchange not supported
---------------------------------------------------
0x54 | SRTP auth. tag not supported
---------------------------------------------------
0x55 | SAS scheme not supported
---------------------------------------------------
0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1)
---------------------------------------------------
0x62 | DH Error: hvi != hashed data
---------------------------------------------------
0x63 | Received relayed SAS from untrusted MiTM
---------------------------------------------------
0x70 | Auth. Error: Bad Confirm pkt HMAC
---------------------------------------------------
0x80 | Nonce reuse
---------------------------------------------------
0x90 | Equal ZIDs in Hello
---------------------------------------------------
0x100 | GoClear packet received, but not allowed
---------------------------------------------------
Table 7. ZRTP Error Codes
6.10. ErrorACK message
The ErrorACK message is sent in response to an Error message. The
format is shown in Figure 11 below.
Zimmermann, et al. Expires August 28, 2008 [Page 47]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ErrorACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11. ErrorACK message format
6.11. GoClear message
The optional GoClear message is sent to switch from SRTP to RTP. The
format is shown in Figure 12 below. The clear_hmac is used to
authenticate the GoClear message so that bogus GoClear messages
introduced by an attacker can be detected and discarded. The use of
GoClear is described in Section 5.11.
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="GoClear " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clear_hmac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. GoClear message format
6.12. ClearACK message
The optional ClearACK message is sent to acknowledge receipt of a
GoClear. A ClearACK is only sent if the clear_hmac from the GoClear
message is authenticated. Otherwise, no response is returned. The
format is shown in Figure 13.
Zimmermann, et al. Expires August 28, 2008 [Page 48]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. ClearACK message format
6.13. SASrelay message
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
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,
after the Confirm packets and their ACKs. It can only be sent after
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
sent with retry logic until a RelayACK message (Figure 15) is
received or the retry schedule has been exhausted. The SASrelay
message format is shown in Figure 14 below. The message contains the
Message Type Block "SASrelay". Next is the HMAC, a keyed hash over
encrypted part of the message (shown enclosed by "===" in Figure 14.)
The next 16 octets contain the CFB Initialization Vector. The rest
of the message is encrypted using CFB and protected by the HMAC.
The next 16 bits are not used. They SHOULD be set to zero and MUST
be ignored in received SASrelay messages.
The next 8 bits contain the signature length. The trusted MiTM MAY
compute a digital signature on the SAS hash, as described in section
8.2, using a persistant signing key owned by the trusted 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. 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
present, the overall length of the SASrelay Message will be set to 12
words.
The next 8 bits are used for flags. Undefined flags are set to zero
and ignored. Three flags are currently defined. The Disclosure Flag
(D) is a Boolean bit defined in Section 12. The Allow Clear flag (A)
is a Boolean bit defined in Section 5.11. The SAS Verified flag (V)
is a Boolean bit defined in Section 8.1. These flags are updated
values to the same flags provided earlier in the Confirm packet, but
they are updated to reflect the new flag information relayed by the
Zimmermann, et al. Expires August 28, 2008 [Page 49]
Internet-Draft ZRTP February 2008
PBX from the other party.
The next 32 bit word contains the rendering scheme for the relayed
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
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
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
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.
If the signature length (in words) is non-zero, a signature type
block will be present along with a signature block. Next is the
signature block. The signature block includes the key used to
generate the signature.
CFB [11] mode is applied with a feedback length of 128-bits, a full
cipher block, and the final block is truncated to match the exact
length of the encrypted data. The CFB Initialization Vector is 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 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
"======" in Figure 14).
Depending on whether the trusted MiTM had taken the role of the
initiator or the responder during the ZRTP key negotiation, the
SASrelay message is encrypted with zrtpkeyi or zrtpkeyr.
Zimmermann, et al. Expires August 28, 2008 [Page 50]
Internet-Draft ZRTP February 2008
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="SASrelay" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| Unused (Set to zero, ignored) | sig length |0 0 0 0|0|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rendering scheme of relayed sasvalue (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted MITM relayed sasvalue (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 14. SASrelay message format
6.14. RelayACK message
The RelayACK message is sent in response to a valid SASrelay message.
The message format for the RelayACK is shown in Figure 15. The
receipt of a RelayACK stops retransmission of the SASrelay message.
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 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="RelayACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zimmermann, et al. Expires August 28, 2008 [Page 51]
Internet-Draft ZRTP February 2008
Figure 15. RelayACK message format
7. Retransmissions
ZRTP uses two retransmission timers T1 and T2. T1 is used for
retransmission of Hello messages, when the support of ZRTP by the
other endpoint may not be known. T2 is used in retransmissions of
all the other ZRTP messages with the exception of GoClear.
All message retransmissions MUST be identical to the initial message
including nonces, public values, etc; otherwise, hashes of the
message sequences may not agree.
Practical experience has shown that RTP packet loss at the start of
an RTP session can be extremely high. Since the entire ZRTP message
exchange occurs during this period, the defined retransmission scheme
is defined to be aggressive. Since ZRTP packets with the exception
of the DHPart1 and DHPart2 messages are small, this should have
minimal effect on overall bandwidth utilization of the media session.
ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media
session as determined by the offer/answer exchange.
Hello ZRTP requests are retransmitted at an interval that starts at
T1 seconds and doubles after every retransmission, capping at 200ms.
A Hello message is retransmitted 20 times before giving up. T1 has a
recommended value of 50 ms. Retransmission of a Hello ends upon
receipt of a HelloACK or Commit message.
Non-Hello ZRTP requests are retransmitted only by the initiator -
that is, only Commit, DHPart2, Confirm2, and GoClear are
retransmitted if the corresponding message from the responder,
DHPart1, Confirm1, Conf2ACK, and ClearACK, are not received. Non-
Hello ZRTP messages are retransmitted at an interval that starts at
T2 seconds and doubles after every retransmission, capping at 600ms.
Only the ZRTP initiator performs retransmissions. Each message is
retransmitted 10 times before giving up and resuming a normal RTP
session. T2 has a default value of 150ms. Each message has a
response message that stops retransmissions, as shown in Table 8.
The high value of T2 means that retransmissions will likely only
occur with packet loss.
Zimmermann, et al. Expires August 28, 2008 [Page 52]
Internet-Draft ZRTP February 2008
Message Acknowledgement Message
------- -----------------------
Hello HelloACK or Commit
Commit DHPart1 or Confirm1
DHPart2 Confirm1
Confirm1 Confirm2
Confirm2 Conf2ACK
GoClear ClearACK
Error ErrorACK
SASrelay RelayACK
Table 8. Retransmitted ZRTP Messages and Responses
8. Short Authentication String
This section will discuss the implementation of the Short
Authentication String, or SAS in ZRTP. The SAS can be verbally
verified by the human users reading the string aloud, exchanging and
comparing over an integrity-protected signaling channel using the
a=zrtp-sas attribute, or validating a digital signature exchanged in
the Confirm1 or Confirm2 messages.
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
leftmost 20 bits of the 32-bit sasvalue are rendered as a form of
base32 encoding known as z-base-32 [12]. The purpose of 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 a result,
the choice of characters is slightly different from base32 as defined
in RFC 3548. The leftmost 20 bits of the sasvalue results 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 sasvalue are
rendered using the PGP Wordlist [13], [14]. Other SAS Types may be
defined to render the SAS value in other ways.
The SAS SHOULD be rendered to the user for authentication. In
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
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
allows detection of a man-in-the-middle (MITM) attack.
Zimmermann, et al. Expires August 28, 2008 [Page 53]
Internet-Draft ZRTP February 2008
8.1. SAS Verified Flag
The SAS Verified flag (V) is set based on the user indicating that
SAS comparison has been successfully performed. The SAS Verified
flag is exchanged securely in the Confirm1 and Confirm2 messages of
the next session. In other words, each party sends the SAS Verified
flag from the previous session in the Confirm message of the current
session. It is perfectly reasonable to have a ZRTP endpoint that
never sets the SAS Verified flag, because it would 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 is available
to the client software, it allows for the possibility that the client
software could render to the user that the SAS verify procedure was
carried out in a previous session.
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
secret, because doing so reduces opportunities for an attacker in the
next call.
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
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
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
voice traffic at all unless the session key was correctly computed
and is also known to the attacker. This implies the MITM must have
been present in all the previous sessions, since the initial
establishment of the first shared secret. This is indeed a
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
detect that the cached shared secret is no longer valid -- because it
was really two different shared secrets all along, one of them
between Alice and the attacker, and the other between the attacker
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
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
attack for even one missed call, he is permanently excluded. He can
no longer resynchronize with the chain of cached shared secrets.
Some sort of user interface element (maybe a checkbox) is needed to
allow the user to tell the software the SAS verify was successful,
causing the software to set the SAS Verified flag (V), which
(together with our cached shared secret) obviates the need to perform
the SAS procedure in the next call. An additional user interface
element can be provided to let the user tell the software he detected
Zimmermann, et al. Expires August 28, 2008 [Page 54]
Internet-Draft ZRTP February 2008
an actual SAS mismatch, which indicates a MITM attack. The software
can then take appropriate action, clearing the SAS Verified flag, and
erase the cached shared secret from this session. It is up to the
implementer to decide if this added user interface complexity is
warranted.
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
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
new cached shared secret, there is a risk that our potential attacker
may have a subsequent opportunity to continue inserting himself in
the call, until we finally get around to checking the SAS. If the
SAS matches, it means no attacker was present for any previous
session since we started propagating cached shared secrets, because
this session and all the previous sessions were also authenticated
with a continuous lineage of shared secrets.
8.2. Signing the SAS
The SAS MAY be signed and the signature sent using the Confirm1,
Confirm2, or SASrelay messages. The signature algorithm is also sent
in the Confirm1, Confirm2, or SASrelay message, along with the length
of the signature. The key types and signature algorithms are for
future study. The signature is calculated over the entire SAS hash
result (sashash) that was truncated down to derive the sasvalue. The
signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay
messages MAY be used to authenticate the ZRTP exchange.
8.3. Relaying the SAS through a PBX
ZRTP is designed to use end-to-end encryption. The two parties'
verbal comparison of the short authentication string (SAS) depends on
this assumption. But in some PBX environments, such as Asterisk,
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
connections with separate session keys and separate SAS's.
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
extension of the PBX. Alice, whose phone is not associated with the
PBX, might dial the PBX from the outside, and a ZRTP connection is
negotiated between her phone and the PBX. She then selects Bob's
extension from the company directory in the PBX. The PBX makes a
call to Bob's phone (which might be offsite, many miles away from the
PBX through the Internet) and a separate ZRTP connection is
negotiated between the PBX and Bob's phone. The two ZRTP sessions
have different session keys and different SAS's, which would render
Zimmermann, et al. Expires August 28, 2008 [Page 55]
Internet-Draft ZRTP February 2008
the SAS useless for verbal comparison between Alice and Bob. They
might even mistakenly believe that a wiretapper is present because of
the SAS mismatch, causing undue alarm.
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
SASrelay packet as defined in Section 6.13, which is sent after the
PBX/Bob ZRTP negotiation is complete, after the Confirm packets.
Only the PBX, acting as a special trusted MiTM (trusted by the
recipient of the SAS relay packet), will relay the SAS. The SASrelay
packet protects the relayed SAS from tampering via an included HMAC,
similar to how the Confirm packet is protected. Bob's ZRTP-enabled
phone accepts the relayed SAS for rendering only because Bob's phone
had previously been configured to trust the PBX. This special
trusted relationship with the PBX can be established through a
special security enrollment procedure. After that enrollment
procedure, the PBX is treated by Bob as a special trusted MiTM. This
results in Alice's SAS being rendered to Bob, so that Alice and Bob
may verbally compare them and thus prevent a MiTM attack by any other
untrusted MiTM.
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
previously carried out a special registration ritual with the bad
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
trust relationship is achieved with the prior establishment of a
special shared secret between Bob and his PBX, which is called the
trusted MiTM key.
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
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
enrollment has established and stored this trusted MiTM key, it can
be detected during subsequent ZRTP call negotiations between the PBX
and Bob's phone, because the PBX and the phone SHOULD pass the hash
of the trusted MiTM key in the other_secret (s5) position in the DH
packet. It is then used as part of the key agreement to calculate
s0.
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 key negotiation sequence indicates that the phone has been
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
case.
Zimmermann, et al. Expires August 28, 2008 [Page 56]
Internet-Draft ZRTP February 2008
The relayed SAS fields contain the SAS rendering type and the binary
32-bit sasvalue. The receiver absolutely MUST NOT render the relayed
SAS if it does not come from a specially trusted ZRTP endpoint. The
security of the ZRTP protocol depends on not rendering a relayed SAS
from an untrusted MiTM, because it may be relayed by a MiTM attacker.
See the SASrelay packet definition (Figure 14) for further details.
To ensure that both Alice and Bob will use to the same SAS rendering
scheme after the keys are negotiated, the PBX also sends the SASrelay
message to the unenrolled party (which does not regard this PBX as a
trusted MiTM), conveying the SAS rendering scheme, but not the SAS
value, which it sets to zero. The unenrolled party will ignore the
relayed SAS field, but will use the specified SAS rendering scheme.
The next section describes the initial enrollment procedure that
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
as a trusted MiTM.
8.3.1. PBX Enrollment and the PBX Enrollment Flag
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
the PBX which a newly configured endpoint would call and establish a
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
trusted MiTM. The PBX calculates and stores the trusted MiTM key in
its cache and associates it with this phone, indexed by the phone's
ZID. The key is calculated this way:
trustedmitmkey = HMAC(ZRTPSess,"Trusted MiTM key")
The PBX signals the enrollment process by setting the PBX Enrollment
flag (E) in the Confirm message. This flag is used to trigger the
ZRTP endpoint's user interface to prompt the user if they want to
trust this PBX and calculate and store the trustedmitmkey in the
cache. If the user decides to respond by activating the appropriate
user interface element (a menu item, checkbox, or button), his ZRTP
user agent calculates trustedmitmkey using the same formula and saves
it in a special cache entry associated with this PBX.
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
hang up and not save the trustedmitmkey in his cache. The PBX will
have 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 depends on the phone trusting the PBX. It is the phone (the
user) who is at risk if the PBX abuses its MiTM privileges.
Zimmermann, et al. Expires August 28, 2008 [Page 57]
Internet-Draft ZRTP February 2008
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
trusted MiTM in future calls. This means that when a future call
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
SASrelay packet comes from a MiTM which does not know the
trustedmitmkey, the phone treats it as a "bad guy" MiTM, and refuses
to render the relayed SAS. Regardless of which party initiates any
future phone calls through the PBX, the enrolled phone or the outside
phone, the PBX will relay the SAS to the enrolled phone.
There are other ways that ZRTP user agents can be configured to trust
a PBX. Perhaps the trustedmitmkey can be configured into the phone
by some automated process in large IT environments. This
specification does not require that products be configured solely by
this enrollment process. Any process that results in a
trustedmitmkey to be computed and shared between the PBX and the
phone will suffice. This is one such method that has been shown to
work.
8.4. Rendering SAS for Multiple Media Streams
There is only one SAS value computed per call. That is the SAS value
for the first media stream established, which computes the ZRTPSess
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
Multistream mode. This SAS applies to all media streams for the same
call.
9. Signaling Interactions
This section discusses how ZRTP, SIP, and SDP work together.
Note that ZRTP may be implemented without coupling with the SIP
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
converted to ZRTP. In these cases, the SIP UA will have no knowledge
of ZRTP. As a result, the signaling path discovery mechanisms
introduced in this section should not be definitive - they are a
hint. Despite the absence of an indication of ZRTP support in an
offer or answer, a ZRTP endpoint SHOULD still send Hello messages.
ZRTP endpoints which have control over the signaling path include a
ZRTP SDP attributes in their SDP offers and answers. The ZRTP
attribute, a=zrtp-hash is used to indicate support for ZRTP and to
convey a hash of the Hello message. There are a number of potential
uses for this attribute. It is useful when signaling elements would
Zimmermann, et al. Expires August 28, 2008 [Page 58]
Internet-Draft ZRTP February 2008
like to know when ZRTP may be utilized by endpoints. It is also
useful if endpoints support multiple methods of SRTP key management.
The ZRTP attribute can be used to ensure that these key management
approaches work together instead of against each other. For example,
if only one endpoint supports ZRTP but both support another method to
key SRTP, then the other method will be used instead. When used in
parallel, an SRTP secret carried in an a=keymgt [27] or a=crypto [26]
attribute can be used as a shared secret for the srtp_secret. The
ZRTP attribute is also used to signal to an intermediary ZRTP device
not to act as a ZRTP endpoint, as discussed in Section 11.
The a=zrtp-hash attribute can only be included at a media level since
Hello messages sent in different media streams will have unique
hashes.
9.1. Tying the media stream to the signaling layer via the Hello Hash
It is desirable to tie the media stream to the signaling channel to
prevent a third party from inserting false media packets. If the
signaling channel is properly integrity protected, and the signaling
layer contains information that ties it to the media stream, false
media streams can be rejected.
To accomplish this, a SHA-256 hash is computed across the entire ZRTP
Hello message (as shown in Figure 3). This hash image is made
available to the signaling layer, where it is transmitted as a
hexadecimal value in the SIP channel using the SDP attribute, a=zrtp-
hash defined in this specification. Each media stream (audio or
video) will have a 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 use this hash image to detect and reject false
Hello packets in the media channel, as well as identify which media
stream is associated with this SIP call. Each Hello packet hashes
uniquely, because it contains the H3 field derived from a random
nonce, defined in Section 10.
This is an optional feature, because some ZRTP endpoints do not have
the ability to add SDP attributes to 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 media packets, not the SIP
packets, especially if the SIP packets are integrity protected and
thus cannot be modified on the wire. If the SDP has no hash image of
the ZRTP Hello packet, the recipient's ZRTP user agent cannot check
it, and thus will not be able to reject Hello packets based on this
hash.
After the Hello Hash is used to properly identify the ZRTP Hello
packet as belonging to this particular SIP call, the rest of the ZRTP
Zimmermann, et al. Expires August 28, 2008 [Page 59]
Internet-Draft ZRTP February 2008
packet sequence is protected from false packet injection by other
protection mechanisms. For example, the use of the total_hash in the
shared secret calculation, and also the hash chaining mechanism
defined in Section 10.
An attacker who controls only the signaling layer, such as an
uncooperative VoIP service provider, may be able to deny service by
corrupting the hash of the Hello packet in the SDP attribute, which
would force ZRTP to reject perfectly good Hello packets. If there is
reason to believe this is happening, the ZRTP endpoint MAY allow
Hello packets to be accepted that do not match the hash image in the
SDP attribute.
The inclusion of the a=zrtp-hash as an SDP attribute becomes
especially useful if the SDP is protected by SIP Identity (RFC 4474)
[30] or better still, Dan Wing's SIP Identity using Media Path [33].
This creates a chain of authentication from the media SRTP auth tag,
back to the ZRTP session key negotiation, back to the a=zrtp-hash in
the SDP, back to the SIP Identity Media mechanism.
If and only if the signaling path and the SDP is protected by some
form of integrity protection, such as one 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 there is
good reason to trust the signaling layer to protect the interests of
the end user, it is possible to authenticate the key exchange and
prevent a MiTM attack without requiring the users to verbally compare
the SAS. To do this, the hash chaining mechanism defined in Section
10 is used to provide a series of HMAC keys that protect the entire
ZRTP key exchange. The following mechanism is used.
The Hello packet is protected by a 64-bit HMAC, keyed by H2. The
Commit packet is protected by a 64-bit HMAC keyed by H1. The DHPart1
or DHPart2 packets are protected by a 64-bit HMAC keyed by H0. The
HMAC protecting the Confirm packets are computed by a different HMAC
key derived from the key agreement, not from the hash chain. Each
packet's HMAC is checked when the HMAC key is received in the next
packet. If a bad HMAC is discovered, it MUST be treated as a
security exception indicating a MiTM attack, perhaps by logging or
alerting the user. It must not be treated as a random error. Random
errors are already discovered and quietly rejected by bad CRCs.
Without an authenticated mechanism in the signaling layer to
guarantee delivery of the a=zrtp-hash SDP attribute without
modification by a third party, these HMACs alone will not prevent a
MiTM attack. In that case, the SAS will still have to be used to
authenticate the key exchange. At the time of this writing, very few
deployed VoIP clients offer a fully implemented SIP stack that
Zimmermann, et al. Expires August 28, 2008 [Page 60]
Internet-Draft ZRTP February 2008
provides integrity protection for the delivery of SDP attributes end-
to-end. Thus, real-world implementations of ZRTP endpoints will
continue to depend on SAS authentication for quite some time. Even
after there is widespread availability of SIP user agents that offer
integrity protected delivery of SDP attributes, many users will still
be faced with the fact that the signaling path may be controlled by
institutions that do not have the best interests of the end user in
mind. In those cases, SAS authentication will remain the gold
standard for the prudent user.
Some potential ZRTP users have expressed a desire to use a PKI if
they already have one up and running, to authenticate the ZRTP
exchange. This is expressed by the R-EXISTING requirement in the
Media Security Requirements [16] document. This requirement can be
fully met by leveraging a certificate-backed PKI in the signaling
layer to integrity protect the delivery of the a=zrtp-hash SDP
attribute. This enables authentication of the entire ZRTP key
exchange through the use of ZRTP's hash chains to key the HMACs in
the ZRTP packets. A trustworthy PKI in the signaling can be
leveraged to protect the media against a MiTM attack without
requiring the user to check the SAS, without adding any explicit
signatures or signature keys to the ZRTP key exchange, without any
extra public key operations, without any extra packets, and offering
the same level of assurance as the authentication in the signaling
layer, no more, no less.
This use of hash chains to key HMACs is similar to Adrian Perrig's
TESLA protocol [21].
9.2. Deriving the signaling secret (sigs) from the signaling layer
The shared secret calculations defined in Section 5.3 make use of the
signaling secret (sigs), if it is provided by the signaling layer.
The signaling secret can be derived from SIP signaling and passed
from the signaling protocol used to establish the RTP session to
ZRTP. It's the dialog identifier of a Secure SIP (sips) session: a
string composed of Call-ID and the local and remote tags. It can be
considered a secret because it is always transported using TLS and is
randomly generated for each SIP call. The local and remote tags are
sorted in ascending order in the hash. From the definitions in RFC
3261 [24]:
sigs = hash(call-id | tag1 | tag2)
Note: the dialog identifier of a non-secure SIP session should not be
considered a signaling secret as it has no confidentiality
protection.
Zimmermann, et al. Expires August 28, 2008 [Page 61]
Internet-Draft ZRTP February 2008
Note: The signaling secret may not be regarded as having adequate
entropy for cryptographic protection without augmentation by key
material from other sources.
9.3. Deriving the SRTP secret (srtps) from the signaling layer
The shared secret calculations defined in Section 5.3 make use of the
SRTP secret (srtps), if it is provided by the signaling layer.
It is desirable for only one SRTP key negotiation protocol to be
used, and that protocol should be ZRTP. But in the event the
signaling layer negotiates its own SRTP master key and salt, using
the RFC 4568 (SDES) [26] or [27], it can be passed from the signaling
to the ZRTP layer and mixed into ZRTP's own shared secret
calculations, without compromising security by creating a dependency
on the signaling for media encryption.
ZRTP computes srtps from the SRTP master key and salt parameters
provided by the signaling layer in this manner:
srtps = hash(SRTP master key | SRTP master salt)
9.4. Using the signaling path to check the SAS
In some scenarios, it is desirable for a signaling intermediary to be
able to validate the SAS on behalf of the user. This could be due to
an endpoint which has a user interface unable to render the SAS. Or,
this could be a protection by an organization against lazy users who
never check the SAS. Using either the ZRTP SAS or ZRTP SASvalue
attribute, the SAS check can be performed without requiring the human
users to speak the SAS. Note that this check can only be relied on
if the signaling path has end-to-end integrity protection.
The ZRTP SAS attribute a=zrtp-sas is a Media level SDP attribute that
can be used to carry the SAS string and value. The string is
identical to that rendered to the user while contents of the string
passed depends on the negotiated SAS Type. The value is the leftmost
64 bits of the SAS hash result (sashash) encoded as hex. Since the
SAS is not known at the start of a session, the a=zrtp-sas attribute
will never be present in the initial offer/answer exchange. After
the ZRTP exchange has completed, the SAS is known and can be
exchanged over the signaling using a second offer/answer exchange (a
re-INVITE in SIP terms). Note that the SAS is not treated as a
secret and as such does not need confidentiality protection when sent
over the signaling path.
The ABNF for the ZRTP attribute is as follows:
Zimmermann, et al. Expires August 28, 2008 [Page 62]
Internet-Draft ZRTP February 2008
zrtp-attribute = "a=zrtp-hash:" zrtp-hash-value
zrtp-hash-value = 1*(HEXDIG)
The ABNF for the ZRTP SAS attribute is as follows:
zrtp-sas-attribute = "a=zrtp-sas:" sas-string sas-value
sas-string = non-ws-string
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
sas-value = 1*(HEXDIG)
Example of the ZRTP attribute in an initial SDP offer or answer used
at the session level:
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000
a=zrtp-hash:fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
An Example of the ZRTP SAS attribute in a subsequent SDP offer or
answer used at the media level:
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000
a=zrtp-sas: opzf 5e017f3a6563876a
Another example showing a second media stream being added to the
session. A second DH exchange is performed (instead of using the
Preshared mode) resulting in a second ZRTP SAS attribute.
Zimmermann, et al. Expires August 28, 2008 [Page 63]
Internet-Draft ZRTP February 2008
v=0
o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000
a=zrtp-sas: opzf 5e017f3a6563876a
m=video 51372 RTP/AVP 31 33
a=rtpmap:31 H261/90000
a=rtpmap:33 no-op/8000
a=zrtp-sas: gwif e1027fa9f865221c
10. False ZRTP Packet Rejection
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,
or to inject his own media stream into the call. VoIP by its nature
invites various forms of denial of service attacks and requires
protocol features to reject such attacks. While bogus SRTP packets
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
negotiation phase, other false packet rejection mechanisms are
needed. One such mechanism is the use of the total_hash in the final
shared secret calculation, but that can only detect false packets
after performing the computationally expensive Diffie-Hellman
calculation.
The VoIP developer community expects to see a lot of denial of
service attacks, especially from attackers who are not in the media
path. Such an attacker might inject false ZRTP packets to force a
ZRTP endpoint to engage in an endless series of pointless and
expensive DH calculations. To detect and reject false packets
cheaply and rapidly as soon as they are received, ZRTP uses a hash
chain, which is a series of successive hash images. Before each
session, the following values are computed:
H0 = 256-bit random nonce (different for each party)
H1 = hash (H0)
H2 = hash (H1)
H3 = hash (H2)
The hash function is defined to be SHA-256. 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 packet sequence. The hash image H3 is sent
in the Hello packet, H2 is sent in the Commit packet, H1 is sent in
Zimmermann, et al. Expires August 28, 2008 [Page 64]
Internet-Draft ZRTP February 2008
the DHPart1 or DHPart2 packets, and H0 is sent in the Confirm1 or
Confirm2 packets. The initial random H0 nonces that each party
generates MUST be unpredictable to an attacker and unique within a
ZRTP call, which thereby forces the derived hash images H1-H3 to also
be unique and unpredictable.
The recipient checks if the packet has the correct hash pre-image, by
hashing it and comparing the result with the hash image for the
preceding packet. Packets which contain an incorrect hash pre-image
MUST NOT be used by the recipient, but MAY be processed as security
exceptions, perhaps by logging or alerting the user.
Because these hash images alone do not protect the rest of the
contents of the packet they reside in, this scheme assumes the
attacker cannot modify the packet contents from a legitimate party,
which is a reasonable assumption for an attacker who is not in the
media path. This covers an important range of denial-of-service
attacks. For dealing with the remaining set of attacks that involve
packet modification, other mechanisms are used, such as the
total_hash in the final shared secret calculation, and the hash
commitment in the Commit packet.
If and only if an authenticated signaling channel is available, this
hash chaining scheme can be used to key HMACs to authenticate the
entire ZRTP key exchange. See Section 9.1 for details.
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
later initiate secure mode again. Many consumer client products will
omit this feature, but those that allow it will use Multistream mode
to return to secure mode again in the same media stream. Although
the same chain of hash images will be re-used and thus rendered
ineffective the second time, no harm is done because the new SRTP
session keys will be derived from new nonce material and ZRTPSess,
which was safely protected from the MiTM in the first DH exchange.
False Hello packets may be detected and rejected by the mechanism
defined in Section 9.1. This mechanism requires that each Hello
packet be unique, and the inclusion of the H3 hash image meets that
requirement.
11. Intermediary ZRTP Devices
This section discusses the operation of a ZRTP endpoint which is
actually an intermediary. For example, consider a device which
proxies both signaling and media between endpoints. There are three
possible ways in which such a device could support ZRTP.
Zimmermann, et al. Expires August 28, 2008 [Page 65]
Internet-Draft ZRTP February 2008
An intermediary device can act transparently to the ZRTP protocol.
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
port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED
behavior for intermediaries as ZRTP and SRTP are best when done end-
to-end.
An intermediary device could implement the ZRTP protocol and act as a
ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary
device. The intermediary could determine on a call-by-call basis
whether the endpoint behind it supports ZRTP based on the presence or
absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP
endpoints, the intermediary device could act as the ZRTP endpoint
using its own ZID and cache. This approach MUST only be used when
there is some other security method protecting the confidentiality of
the media between the intermediary and the inside endpoint, such as
IPSec or physical security.
The third mode, which is NOT RECOMMENDED, is for the intermediary
device to attempt to back-to-back the ZRTP protocol. The only
exception to this case is where the intermediary device is a trusted
element providing services to one of the endpoints - e.g. a Private
Branch Exchange or PBX. In this mode, the intermediary would attempt
to act as a ZRTP endpoint towards both endpoints of the media
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
attack and will generate alarms on both endpoints and likely result
in the immediate termination of the session.
In cases where centralized media mixing is taking place, the SAS will
not match when compared by the humans. However, this situation is
known in the SIP signaling by the presence of the isfocus feature tag
[32]. As a result, when the isfocus feature tag is present, the SAS
can only be verified by comparison in the signaling or by validating
signatures in the Confirm or SASrelay messages. For example,
consider a audio conference call with three participants Alice, Bob,
and Carol hosted on a conference bridge in Dallas. There will be
three ZRTP encrypted media streams between each participant and
Dallas. Each will have a different SAS. Each participant will be
able to validates their SAS with the conference bridge using a=zrtp-
sas or Confirm messages containing signatures.
SIP feature tags can also be used to detect if a session is
established with an automaton such as an IVR, voicemail system, or
speech recognition system. The display of SAS strings to users
should be disabled in these cases.
It is possible that an intermediary device acting as a ZRTP endpoint
Zimmermann, et al. Expires August 28, 2008 [Page 66]
Internet-Draft ZRTP February 2008
might still receive ZRTP Hello and other messages from the inside
endpoint. This could occur if there is another inline ZRTP device
which does not include the ZRTP SDP attribute flag. If this occurs,
the intermediary MUST NOT pass these ZRTP messages if it is acting as
the ZRTP endpoint.
12. The ZRTP Disclosure flag
There are no back doors defined in the ZRTP protocol specification.
The designers of ZRTP would like to discourage back doors in ZRTP-
enabled products. However, despite the lack of back doors in the
actual ZRTP protocol, it must be recognized that a ZRTP implementer
might still deliberately create a rogue ZRTP-enabled product that
implements a back door outside the scope of the ZRTP protocol. For
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
have a legitimate business reason to do this for some customers.
For example, some environments have a need to monitor or record
calls, such as stock brokerage houses who want to discourage insider
trading, or special high security environments with special needs to
monitor their own phone calls. We've all experienced automated
messages telling us that "This call may be monitored for quality
assurance". A ZRTP endpoint in such an environment might
unilaterally disclose the session key to someone monitoring the call.
ZRTP-enabled products that perform such out-of-band disclosures of
the session key can undermine public confidence in the ZRTP protocol,
unless we do everything we can in the protocol to alert the other
user that this is happening.
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
other party through a protocol message to the other party's ZRTP
client, which can properly alert that user, perhaps by rendering it
in a graphical user interface. The disclosing party does this by
sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as
described in Section 6.7.
Note that the intention here is to have the Disclosure flag identify
products that are designed to disclose their session keys, not to
identify which particular calls are compromised on a call-by-call
basis. This is an important legal distinction, because most
government sanctioned wiretap regulations require a VoIP service
provider to not reveal which particular calls are wiretapped. But
there is nothing illegal about revealing that a product is designed
to be wiretap-friendly. The ZRTP protocol mandates that such a
product "out" itself.
Zimmermann, et al. Expires August 28, 2008 [Page 67]
Internet-Draft ZRTP February 2008
You might be using a ZRTP-enabled product with no back doors, but if
your own graphical user interface tells you the call is (mostly)
secure, except that the other party is using a product that is
designed in such a way that it may have disclosed the session key for
monitoring purposes, you might ask him what brand of secure telephone
he is using, and make a mental note not to purchase that brand
yourself. If we create a protocol environment that requires such
back-doored phones to confess their nature, word will spread quickly,
and the "invisible hand" of the free market will act. The free
market has effectively dealt with this in the past.
Of course, a ZRTP implementer can lie about his product having a back
door, but the ZRTP standard mandates that ZRTP-compliant products
MUST adhere to the requirement that a back door be confessed by
sending the Disclosure flag to the other party.
There will be inevitable comparisons to Steve Bellovin's 2003 April
fool's joke, when he submitted RFC 3514 [29] which defined the "Evil
bit" in the IPV4 header, for packets with "evil intent". But we
submit that a similar idea can actually have some merit for securing
VoIP. Sure, one can always imagine that some implementer will not be
fazed by the rules and will lie, but they would have lied anyway even
without the Disclosure flag. There are good reasons to believe that
it will improve the overall percentage of implementations that at
least tell us if they put a back door in their products, and may even
get some of them to decide not to put in a back door at all. From a
civic hygiene perspective, we are better off with having the
Disclosure flag in the protocol.
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
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 to another application or device, the Disclosure flag D
MUST be set in the Confirm1 or Confirm2 message.
12.1. Guidelines on Proper Implementation of the Disclosure Flag
Some implementers have asked for guidance on implementing the
Disclosure Flag. Some people have incorrectly thought that a
connection secured with ZRTP cannot be used in a call center, with
voluntary voice recording, or even with a voicemail system.
Similarly, some potential users of ZRTP have overconsidered the
protection that ZRTP can give them. These guidelines clarify both
concerns.
The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself.
It does not govern the underlying RTP media stream, nor the actual
Zimmermann, et al. Expires August 28, 2008 [Page 68]
Internet-Draft ZRTP February 2008
media itself. Consequently, a PBX that uses ZRTP may provide
conference calls, call monitoring, call recording, voicemail, or
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
that it does not disclose the ZRTP key material. The ZRTP Disclosure
Flag, when not set, means only that the ZRTP cryptographic key
material stays within the bounds of the ZRTP subsystem.
If an application has a need to disclose the ZRTP cryptographic key
material, the easiest way to comply with the protocol is to set the
flag to the proper value. The next easiest way is to overestimate
disclosure. For example, a call center that commonly records calls
might choose to set the disclosure flag even though all recording is
an analog recording of a call (and thus outside the ZRTP scope)
because it sets an expectation with clients that their calls might be
recorded.
Note also that the ZRTP Disclosure Flag does not require an
implementation to preclude hacking or malware. Malware that leaks
ZRTP cryptographic key material does not create a liability for the
implementor from non-compliance with the ZRTP specification.
A user of ZRTP should note that ZRTP is not a panacea against
unauthorized recording. ZRTP does not and cannot protect against an
untrustworthy partner who holds a microphone up to the speaker. It
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
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
subsystem is not knowingly leaking ZRTP cryptographic key material.
13. RTP Header Extension Flag for ZRTP
This specification defines a new RTP header extension used only for
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
the presence of the RTP header extension.
Section 5.3.1 in RFC 3550 defines the format of an RTP Header
extension. The Header extension is appended to the RTP header. The
first 16 bits are an identifier for the header extension, and the
following 16 bits are length of the extension 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 extension is as shown in
Figure 16.
Zimmermann, et al. Expires August 28, 2008 [Page 69]
Internet-Draft ZRTP February 2008
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 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16. RTP Extension header format for ZRTP Flag
ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at
the start of a session. For example, and endpoint may decide to
include the flag in the first 1 second of RTP packets sent. The
inclusion of the flag MAY be ended if a ZRTP message (such as Hello)
is received.
14. IANA Considerations
This specification defines two new SDP [15] attributes in Section 9.
14.1. IANA Registration of a=zrtp-hash SDP attribute
Contact name: Philip Zimmermann <prz@mit.edu>
Attribute name: "zrtp-hash".
Type of attribute: Media level.
Subject to charset: Not.
Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the
ZRTP protocol and provides a hash of the ZRTP Hello
message.
Allowed attribute values: Hex.
Zimmermann, et al. Expires August 28, 2008 [Page 70]
Internet-Draft ZRTP February 2008
14.2. IANA Registration of a=zrtp-sas SDP attribute
Contact name: Philip Zimmermann <prz@mit.edu>
Attribute name: "zrtp-sas".
Type of attribute: Media level.
Subject to charset: Yes.
Purpose of attribute: The 'zrtp-sas' is used to convey the ZRTP SAS
string and value. The string is identical to that
rendered to the users. The value is the 64 bit SAS
encoded as hex.
Allowed attribute values: String and Hex.
15. Security Considerations
This document is all about securely keying SRTP sessions. As such,
security is discussed in every section.
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-
middle (MITM) attack, it is common practice to provide a way to
authenticate the DH exchange. In some military systems, this is done
by depending on digital signatures backed by a centrally-managed PKI.
A decade of industry experience has shown that deploying centrally
managed PKIs can be a painful and often futile experience. PKIs are
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
practical for an equipment provider. A service provider like a
carrier might venture down this path, but even then you have to deal
with cross-carrier authentication, certificate revocation lists, and
other complexities. It is much simpler to avoid PKIs altogether,
especially when developing secure commercial products. It is
therefore more common for commercial secure phones in the PSTN world
to augment the DH exchange with a Short Authentication String (SAS)
combined with a hash commitment at the start of the key exchange, to
shorten the length of SAS material that must be read aloud. No PKI
is required for this approach to authenticating the DH exchange. The
AT&T TSD 3600, Eric Blossom's COMSEC secure phones [22], PGPfone
[19], and CryptoPhone [23] are all examples of products that took
this simpler lightweight approach.
The main problem with this approach is inattentive users who may not
execute the voice authentication procedure, or unattended secure
Zimmermann, et al. Expires August 28, 2008 [Page 71]
Internet-Draft ZRTP February 2008
phone calls to answering machines that cannot execute it.
Additionally, some people worry about voice spoofing. But it is a
mistake to think this is simply an exercise in voice impersonation
(perhaps this could be called the "Rich Little" attack). Although
there are digital signal processing techniques for changing a
person's voice, that does not mean a man-in-the-middle attacker can
safely break into a phone conversation and inject his own short
authentication string (SAS) at just the right moment. He doesn't
know exactly when or in what manner the users will choose to read
aloud the SAS, or in what context they will bring it up or say it, or
even which of the two speakers will say it, or if indeed they both
will say it. In addition, some methods of rendering the SAS involve
using a list of words such as the PGP word list, in a manner
analogous to how pilots use the NATO phonetic alphabet to convey
information. This can make it even more complicated for the
attacker, because these words can be worked into the conversation in
unpredictable ways. Remember that the attacker places a very high
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
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
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
only necessary that they detect that the voice used for the SAS
procedure matches the voice in the rest of the phone conversation.
A popular and field-proven approach is used by SSH (Secure Shell)
[25], which Peter Gutmann likes to call the "baby duck" security
model. SSH establishes a relationship by exchanging public keys in
the initial session, when we assume no attacker is present, and this
makes it possible to authenticate all subsequent sessions. A
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 attacker. All this is accomplished without resorting to a
centrally-managed PKI.
We use an analogous baby duck security model to authenticate the DH
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
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
secret for later calls to use for authentication, no new voice
authentication rituals need to be executed. We just have to remember
we did one already.
If one party ever loses this cached shared secret, it is no longer
available for authentication of DH exchanges. This cache mismatch
Zimmermann, et al. Expires August 28, 2008 [Page 72]
Internet-Draft ZRTP February 2008
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
MiTM attack or one side has lost their shared secret cache entry.
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
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
that point on, the two parties start over with a new cached shared
secret. Then they can go back to omitting the voice authentication
on later calls.
A particularly compelling reason why this approach is attractive is
that SAS is easiest to implement when a graphical user interface or
some sort of display is available, which raises the question of what
to do when a display is less conveniently available. For example,
some devices that implement ZRTP might have a graphical user
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-
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
graphical user interface with greater ease. Then the SAS can be
compared less frequently through a web browser, or it might even be
presented as needed to the local user through a locally generated
voice prompt, which the local user hears and verbally repeats and
compares with the remote party.
It's a good idea to force your opponent to have to solve multiple
problems in order to mount a successful attack. Some examples of
widely differing problems we might like to present him with are:
Stealing a shared secret from one of the parties, being present on
the very first session and every subsequent session to carry out an
active MITM attack, and solving the discrete log problem. We want to
force the opponent to solve more than one of these problems to
succeed.
ZRTP can use different kinds of shared secrets. Each type of shared
secret is determined by a different method. All of the shared
secrets are hashed together to form a session key to encrypt the
call. An attacker must defeat all of the methods in order to
determine the session key.
First, there is the shared secret determined entirely by a Diffie-
Hellman key agreement. It changes with every call, based on random
numbers. An attacker may attempt a classic DH MITM attack on this
secret, but we can protect against this by displaying and reading
aloud a SAS, combined with adding a hash commitment at the beginning
of the DH exchange.
Zimmermann, et al. Expires August 28, 2008 [Page 73]
Internet-Draft ZRTP February 2008
Second, there is an evolving shared secret, or ongoing shared secret
that is automatically changed and refreshed and cached with every new
session. We will call this the cached shared secret, or sometimes
the retained shared secret. Each new image of this ongoing secret is
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
secret is available, because there were no previous sessions to
inherit this value from, or because one side loses its cache.
There are other approaches for key agreement for SRTP that compute a
shared secret using information in the signaling. For example, [27]
describes how to carry a MIKEY (Multimedia Internet KEYing) [28]
payload in SDP [15]. Or RFC 4568 (SDES) [26] describes directly
carrying SRTP keying and configuration information 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 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 will be hashed
together to form a session key. This way, any security weaknesses
that might compromise the shared secret contributed by the signaling
will not harm the final resulting 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
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
shared secret is not available, it is omitted from the hash
computation. If the signaling provides no shared secret, it is also
omitted from the hash computation.
No DH MITM attack can succeed if the ongoing shared secret is
available to the two parties, but not to the attacker. This is
because the attacker cannot compute a common session key with either
party without knowing the cached secret component, even if he
correctly executes a classic DH MITM attack. Mixing in the cached
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
familiar DH key agreement, we must make sure the lack of availability
Zimmermann, et al. Expires August 28, 2008 [Page 74]
Internet-Draft ZRTP February 2008
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
with the session keys is that it augments the entropy of the session
key. Even if limits on the size of the DH exchange produces a
session key with less than 256 bits of real work factor, the added
entropy from the cached shared secret can bring up all the subsequent
session keys to the full 256-bit AES key strength, assuming no
attacker was present in the first call.
We could have authenticated the DH exchange the same way SSH does it,
with digital signatures, caching public keys instead of shared
secrets. But this approach with caching shared secrets seemed a bit
simpler, requiring less CPU time for low-powered mobile platforms
because it avoids an added digital signature step.
The ZRTP SDP attributes convey information through the signaling that
is already available in clear text through the media path. For
example, the ZRTP flag is equivalent to sending a ZRTP Hello message.
The SAS is calculated from a hash of material from ZRTP messages sent
over the media path. As a result, none of the ZRTP SDP attributes
require confidentiality from the signaling.
The ZRTP SAS attributes can use the signaling channel as an out-of-
band authentication mechanism. This authentication is only useful if
the signaling channel has end-to-end integrity protection. Note that
the SIP Identity header field [30] provides middle-to-end integrity
protection across SDP message bodies which provides useful protection
for ZRTP SAS attributes.
16. Acknowledgments
The authors would like to thank Bryce Wilcox-O'Hearn for his
contributions to the design of this protocol, and to thank Jon
Peterson, Colin Plumb, Hal Finney, Colin Perkins, and Dan Wing for
their helpful comments and suggestions. Also thanks to David McGrew,
Roni Even, Viktor Krikun, Werner Dittmann, Allen Pulsifer, Klaus
Peters, and Abhishek Arya for their feedback and comments.
17. References
Zimmermann, et al. Expires August 28, 2008 [Page 75]
Internet-Draft ZRTP February 2008
17.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[4] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[5] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[6] Barker, E. and J. Kelsey, "Recommendation for Random Number
Generation Using Deterministic Random Bit Generators", NIST
Special Publication 800-90 (Revised) March 2007.
[7] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-
Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography", NIST Special Publication 800-56A Revision 1,
March 2007.
[8] "Fact Sheet NSA Suite B Cryptography", NSA Information
Assurance Directorate Fact Sheet NSA Suite B.
[9] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2",
RFC 4753, January 2007.
[10] "Digital Signature Standard (DSS)", NIST FIPS PUB 186-3 Draft,
March 2006.
[11] Dworkin, M., "Recommendation for Block Cipher: Methods and
Techniques", NIST Special Publication 800-38A 2001 Edition.
[12] Wilcox, B., "Human-oriented base-32 encoding",
http://zooko.com/repos/z-base-32/base32/DESIGN .
[13] Juola, P. and P. Zimmermann, "Whole-Word Phonetic Distances and
the PGPfone Alphabet", Proceedings of the International
Conference of Spoken Language Processing (ICSLP-96) .
Zimmermann, et al. Expires August 28, 2008 [Page 76]
Internet-Draft ZRTP February 2008
[14] "PGP Wordlist", http://en.wikipedia.org/wiki/PGP_Words .
[15] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
17.2. Informative References
[16] Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management
Protocols", draft-ietf-sip-media-security-requirements-03 (work
in progress), February 2008.
[17] Ferguson, N. and B. Schneier, "Practical Cryptography", Wiley
Publishing 2003.
[18] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[19] Zimmermann, P., "PGPfone",
http://www.pgpi.org/products/pgpfone/ .
[20] Zimmermann, P., "Zfone", http://www.philzimmermann.com/zfone .
[21] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The TESLA
Broadcast Authentication Protocol", http://www.ece.cmu.edu/
~adrian/projects/tesla-cryptobytes/tesla-cryptobytes.pdf .
[22] Blossom, E., "The VP1 Protocol for Voice Privacy Devices
Version 1.2", http://www.comsec.com/vp1-protocol.pdf .
[23] "CryptoPhone", http://www.cryptophone.de/ .
[24] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[25] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.
[26] Andreasen, F., Baugher, M., and D. Wing, "Session Description
Protocol (SDP) Security Descriptions for Media Streams",
RFC 4568, July 2006.
[27] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
RFC 4567, July 2006.
Zimmermann, et al. Expires August 28, 2008 [Page 77]
Internet-Draft ZRTP February 2008
[28] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[29] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514,
April 1 2003.
[30] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[31] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in
progress), October 2007.
[32] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", BCP 119,
RFC 4579, August 2006.
[33] Wing, D. and H. Kaplan, "SIP Identity using Media Path",
draft-wing-sip-identity-media-02 (work in progress),
February 2008.
Authors' Addresses
Philip Zimmermann
Zfone Project
Email: prz@mit.edu
Alan Johnston (editor)
Avaya
St. Louis, MO 63124
Email: alan@sipstation.com
Jon Callas
PGP Corporation
Email: jon@pgp.com
Zimmermann, et al. Expires August 28, 2008 [Page 78]
Internet-Draft ZRTP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zimmermann, et al. Expires August 28, 2008 [Page 79]
