Network Working Group P. Zimmermann Internet-Draft Zfone Project Intended status: Informational A. Johnston, Ed. Expires: April 1, 2009 Avaya J. Callas PGP Corporation September 28, 2008 ZRTP: Media Path Key Agreement for Secure RTP draft-zimmermann-avt-zrtp-09 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 April 1, 2009. 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. 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 Zimmermann, et al. Expires April 1, 2009 [Page 1] Internet-Draft ZRTP September 2008 signaling protocol, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Media Security Requirements . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 9 4.1.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 9 4.1.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 11 4.1.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 12 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Protocol Version Negotiation . . . . . . . . . . . . . 13 5.2. Commit Contention . . . . . . . . . . . . . . . . . . . . 15 5.3. Determination of whether cache has matching shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 17 5.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 18 5.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 19 5.4. DH and non-DH key agreements . . . . . . . . . . . . . . . 20 5.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 20 5.4.1.1. Hash Commitment . . . . . . . . . . . . . . . . . 20 5.4.1.2. Responder Behavior . . . . . . . . . . . . . . . . 21 5.4.1.3. Initiator Behavior . . . . . . . . . . . . . . . . 22 5.4.1.4. Shared Secret Calculation for DH Mode . . . . . . 22 5.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 24 5.4.2.1. Commitment in Multistream Mode . . . . . . . . . . 24 5.4.2.2. Shared Secret Calculation for Multistream Mode . . 25 5.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 26 5.4.3.1. Commitment in Preshared Mode . . . . . . . . . . . 26 5.4.3.2. Initiator Behavior . . . . . . . . . . . . . . . . 26 5.4.3.3. Responder Behavior . . . . . . . . . . . . . . . . 27 5.4.3.4. Shared Secret Calculation for Preshared Mode . . . 28 5.5. Key Generation . . . . . . . . . . . . . . . . . . . . . . 29 5.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 30 5.6.1. Updating the Cache of Shared Secrets . . . . . . . . . 31 5.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 31 5.7.1. Termination via Error message . . . . . . . . . . . . 32 5.7.2. Termination via GoClear message . . . . . . . . . . . 32 5.7.2.1. Key Destruction for GoClear message . . . . . . . 33 5.7.3. Key Destruction at Termination . . . . . . . . . . . . 34 5.8. Random Number Generation . . . . . . . . . . . . . . . . . 34 Zimmermann, et al. Expires April 1, 2009 [Page 2] Internet-Draft ZRTP September 2008 5.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 34 5.9.1. Self-healing Key Continuity Feature . . . . . . . . . 36 6. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 37 6.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 38 6.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 38 6.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 40 6.1.2.1. Implicit Hash and HMAC algorithm . . . . . . . . . 40 6.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 41 6.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 41 6.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 41 6.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 43 6.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 44 6.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 44 6.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 46 6.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 46 6.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 49 6.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 51 6.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 53 6.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 55 6.9. Error message . . . . . . . . . . . . . . . . . . . . . . 56 6.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 57 6.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 58 6.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 58 6.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 59 6.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 61 7. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 62 8. Short Authentication String . . . . . . . . . . . . . . . . . 63 8.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 64 8.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 66 8.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 66 8.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 68 9. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 69 9.1. Binding the media stream to the signaling layer via the Hello Hash . . . . . . . . . . . . . . . . . . . . . . 70 9.1.1. Integrity-protected signaling enables integrity-protected DH exchange . . . . . . . . . . . 71 9.2. Deriving the SRTP secret (srtps) from the signaling layer . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9.3. Codec Selection for Secure Media . . . . . . . . . . . . . 74 10. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 74 11. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 76 12. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 77 12.1. Guidelines on Proper Implementation of the Disclosure Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 13. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 80 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 15. Security Considerations . . . . . . . . . . . . . . . . . . . 81 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 Zimmermann, et al. Expires April 1, 2009 [Page 3] Internet-Draft ZRTP September 2008 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 17.1. Normative References . . . . . . . . . . . . . . . . . . . 86 17.2. Informative References . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Intellectual Property and Copyright Statements . . . . . . . . . . 91 Zimmermann, et al. Expires April 1, 2009 [Page 4] Internet-Draft ZRTP September 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) [RFC3550] media stream which has been established using a signaling protocol such as Session Initiation Protocol (SIP) [RFC3261]. This generates a shared secret which is then used to generate keys and salt for a Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone [pgpfone]. A reference implementation of ZRTP is available as Zfone [zfone]. 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 (SAS) for the users to read and verbally 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. In cases where the short authentication string (SAS) cannot be verbally compared by two human users, the SAS can be authenticated by exchanging an optional signature over the SAS (described in Section 8.2). 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. However, when ZRTP is indicated in the signaling via the zrtp-hash SDP attribute, ZRTP has additional useful properties. By sending a hash of the ZRTP Hello message in the signaling, ZRTP provides a useful binding between the signaling and media paths, which is explained in Zimmermann, et al. Expires April 1, 2009 [Page 5] Internet-Draft ZRTP September 2008 Section 9.1. When this is done through a signaling path that has end-to-end integrity protection, the DH exchange is automatically protected from a MiTM attack, which is explained in Section 9.1.1. The next section discusses how ZRTP meets every requirement for media security protocols documented in the IETF. Following sections provide an overview of the ZRTP protocol, describe the key agreement algorithm and RTP message formats. 2. Terminology 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 [RFC2119]. 3. Media Security Requirements This section discuses how ZRTP meets all RTP security requirements discussed in the SIP Working Group's Media Security Requirements [I-D.ietf-sip-media-security-requirements] document without any dependencies on other protocols or extensions. R-FORK-RETARGET is met since ZRTP is a media path key agreement protocol. R-DISTINCT is met since ZRTP uses ZIDs and allows multiple independent ZRTP exchanges to proceed. R-REUSE is met using the Multistream and Preshared modes. R-AVOID-CLIPPING is met since ZRTP is a media path key agreement protocol R-RTP-VALID is met since the ZRTP packet format does not pass the RTP validity check R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and responses. R-NEGOTIATE is met using the Commit message. R-PSTN is met since ZRTP can be implemented in Gateways. Zimmermann, et al. Expires April 1, 2009 [Page 6] Internet-Draft ZRTP September 2008 R-PFS is met using ZRTP Diffie-Hellman key agreement methods. R-COMPUTE is met using the Hello/Commit ZRTP exchange. R-CERTS is met using the optional signature field in ZRTP Confirm messages. R-FIPS is met since ZRTP uses algorithms that allow FIPS certification. R-DOS is met since ZRTP does not introduce any new denial of service attacks. R-EXISTING is met since ZRTP can support the use of certificates or keys. R-AGILITY is met since the set of hash, cipher, authentication tag length, key agreement method, SAS type, and signature type can all be extended and negotiated. R-DOWNGRADE is met since ZRTP has protection against downgrade attacks. R-PASS-MEDIA is met since ZRTP prevents a passive adversary with access to the media path from gaining access to keying material used to protect SRTP media packets. R-PASS-SIG is met since ZRTP prevents a passive adversary with access to the signaling path from gaining access to keying material used to protect SRTP media packets. R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs and responses. R-ID-BINDING is met using the a=zrtp-hash SDP attribute. R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs and responses. R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and hence best effort SRTP in every case. R-OTHER-SIGNALING is met since ZRTP can utilize modes in which there is no dependency on the signaling path. R-RECORDING is met using the ZRTP Disclosure flag. Zimmermann, et al. Expires April 1, 2009 [Page 7] Internet-Draft ZRTP September 2008 R-TRANSCODER is met if the transcoder operates as a trusted MitM (i.e. a PBX). 4. Overview This section provides a description of how ZRTP works. This 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 [I-D.ietf-mmusic-ice] 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. Zimmermann, et al. Expires April 1, 2009 [Page 8] Internet-Draft ZRTP September 2008 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. 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 [comsec]. 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 SHOULD NOT send RTP media after sending the Commit message, and MUST NOT send SRTP media before receiving the Conf2Ack. The responder SHOULD NOT send RTP media after receiving the Commit message, and MUST NOT send SRTP media before receiving the Confirm2 message. 4.1.1. Diffie-Hellman Mode An example ZRTP call flow is shown in Figure 1 below. Note that the 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 April 1, 2009 [Page 9] Internet-Draft ZRTP September 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. | | | | F8 Confirm1 (HMAC, D,A,V,E flags, sig) | |-------------------------------------------------->| | Confirm2 (HMAC, D,A,V,E flags, sig) F9 | |<--------------------------------------------------| | F10 Conf2ACK | |-------------------------------------------------->| | SRTP begins | |<=================================================>| | | 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 authenticated by exchanging an OPTIONAL digital signature (sig) over the short authentication string in the Confirm1 or Confirm2 messages (described in Section 8.2). 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 work. They also carry other information such as the Disclosure flag Zimmermann, et al. Expires April 1, 2009 [Page 10] Internet-Draft ZRTP September 2008 (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 should (and indeed, MUST) 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 MUST 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. Preshared mode MUST NOT be used for establishing a second media stream. Multistream mode is designed for that. Zimmermann, et al. Expires April 1, 2009 [Page 11] Internet-Draft ZRTP September 2008 Preshared mode is only included in this specification to meet the R-REUSE requirement in the Media Security Requirements [I-D.ietf-sip-media-security-requirements] document. A series of preshared-keyed calls between two ZRTP endpoints should use a DH key exchange periodically. Preshared mode SHOULD NOT be used unless a cached shared secret has been established in an earlier session by a DH exchange, as discussed in Section 5.9. Preshared mode has forward secrecy properties. If a phone's cache is captured by an opponent, the cached shared secrets cannot be used to recover earlier encrypted calls, because the shared secrets are replaced with new ones in each new call, as in DH mode. However, the captured secrets can be used by a passive wiretapper in the media path to decrypt the next call, if the next call is in Preshared mode. This differs from DH mode, which requires an active MiTM wiretapper to exploit captured secrets in the next call. However, if the next call is missed by the wiretapper, he cannot wiretap any further calls. It thus preserves most of the self-healing properties (Section 5.9.1) of key continuity enjoyed by DH mode. 5. Protocol Description ZRTP MUST be multiplexed on the same ports as the RTP media packets. To support best effort encryption from the Media Security Requirements [I-D.ietf-sip-media-security-requirements], 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, described in Section 6.2. ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers Zimmermann, et al. Expires April 1, 2009 [Page 12] Internet-Draft ZRTP September 2008 and answers, as defined in Section 9. ZRTP MAY use an RTP [RFC3550] 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 later in the protocol as an index into a cache of shared secrets that were previously negotiated and retained between the two parties. 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.1.1. Protocol Version Negotiation Each party declares what version of the ZRTP protocol they support via the version field in the Hello message (Section 6.2). If both parties have the same version number in their Hello messages, they can proceed with the rest of the protocol. To facilitate both parties reaching this state of protocol version agreement in their Hello messages, ZRTP should use information provided in the signaling layer, if available. If a ZRTP endpoint supports more than one version of the protocol, it SHOULD declare them all in a list of SIP SDP a=zrtp-hash attributes (defined in Section 9), listing separate hashes, with separate ZRTP version numbers in each item in the list. Both parties should inspect the list of ZRTP version numbers supplied by the other party in the SIP SDP a=zrtp-hash attributes. Both parties should choose the highest version number that appear in both parties' list of a=zrtp-hash version numbers, and use that version for their Hello messages. If both parties use the SIP signaling in this manner, their initial Hello messages will have the same ZRTP version number, provided they both have at least one supported protocol version in common. In that case, the protocol version number negotiation is completed. It is best if the signaling layer is used to negotiate the protocol version number. However, the a=zrtp-hash SDP attribute is not always Zimmermann, et al. Expires April 1, 2009 [Page 13] Internet-Draft ZRTP September 2008 present in the SIP packet, as explained in Section 9.1. In the absence of any guidance from the signaling layer, Alice MUST send her highest supported version in her own initial Hello message. If the two parties send different protocol version numbers in their Hello messages, they can reach agreement to use a common version, if one exists. They iteratively apply the following rules until they both have the same version in their Hello messages: If Alice receives a Hello message from Bob with an unsupported version number that is greater than Alice's current Hello message, she ignores the received Hello message and continues to retransmit Hello messages on the standard retry schedule (Section 7). If Alice receives a Hello message from Bob with a version number that is less than Alice's Hello message, and she also supports a version that is less than or equal to Bob's version number, she stops sending the old version number and starts sending Hello messages (on a renewed retry schedule) that have the highest supported version number that is less than or equal to Bob's version number. If Alice receives a Hello message from Bob with a version number that is less than Alice's Hello message, but she does not also support a version that is less than or equal to Bob's version number, she sends an Error message (Section 6.9) to Bob declaring that she does not support his ZRTP version. Bob stops sending Hellos upon receiving the Error message. This aborts the protocol. (Note that all Error messages are retransmitted (Section 7) until an ErrorACK (Section 6.10) is received). For example, assume that Alice supports protocol version 1.00 and 2.00, and Bob supports version 1.00 and 1.10. Alice initially sends a Hello with version 2.00, and Bob initially sends a Hello with version 1.10. Bob ignores Alice's 2.00 Hello and continues to send his 1.10 Hello. Alice detects that Bob does not support 2.00 and she starts sending a stream of 1.00 Hellos. Bob sees the 1.00 Hello from Alice and stops sending his 1.10 Hellos and switches to sending 1.00 Hellos. At that point, they have converged on using version 1.00 and the protocol proceeds on that basis. Only a simplified subset of the above behavior needs to be implemented in version 1.00, because no versions lower than version 1.00 will be encountered. A ZRTP version 1.00 endpoint need only implement the following rules until both parties converge to the same version in their Hello messages: If Alice receives a Hello message from Bob with an unsupported version number that is greater than Alice's current Hello message, she ignores the received Hello message and continues to retransmit Hello messages on the standard retry schedule (Section 7). Zimmermann, et al. Expires April 1, 2009 [Page 14] Internet-Draft ZRTP September 2008 If Alice receives an Error message (Section 6.9) from Bob, declaring an unsupported protocol version, she stops sending Hello messages. This aborts the protocol. Changes in protocol version numbers are expected be infrequent after version 1.00. Supporting multiple versions adds code complexity and may introduce security weaknesses in the implementation. The old adage about keeping it simple applies especially to implementing security protocols. Implementors SHOULD NOT support protocol versions earlier than version 1.00 after this specification reaches RFC status. 5.2. Commit Contention After both parties have received compatible Hello messages, a Commit message (Section 6.4) 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 two Commits are both Preshared mode, and one party has set the MiTM (M) flag in the Hello message and the other has not, the Commit message from the party who set the (M) flag is discarded, and the one who has not set the (M) flag becomes the initiator, regardless of the nonce values. In other words, for Preshared mode, the phone is the initiator and the PBX is the responder. If the two Commits are either both DH modes or both non-DH modes, then the Commit message with the lowest hvi value (for DH Commits), or lowest nonce value (for non-DH Commits), is discarded and the other side is the initiator, and the protocol proceeds with the initiator's Commit. The two hvi or nonce values are compared as large unsigned integers in network byte order. 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 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. Zimmermann, et al. Expires April 1, 2009 [Page 15] Internet-Draft ZRTP September 2008 5.3. Determination of whether cache has matching shared secrets The following sections describe how ZRTP endpoints generate and/or use the set of shared secrets s1, auxsecret, and pbxsecret through the exchange of the DHPart1 and DHPart2 messages. This doesn't cover the Diffie-Hellman calculations. It only covers the method whereby the two parties determine if they already have shared secrets in common in their caches. Each ZRTP endpoint maintains a long-term cache of shared secrets that it has previously negotiated with the other party. The ZID of the other party, received in the other party's Hello message, is used as an index into this cache to find the set of shared secrets, if any exist. This cache entry may contain previously retained shared secrets, rs1 and rs2, which give ZRTP its key continuity features. If the other party is a PBX, the cache may also contain a trusted MiTM PBX shared secret, called pbxsecret, defined in Section 8.3.1. The DHPart1 and DHPart2 messages contain a list of hashes of these shared secrets to allow the two endpoints to compare the hashes with what they have in their caches to detect whether the two sides share any secrets that can be used in the calculation of the session key. The use of this shared secret cache is described in Section 5.9. 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 which types of shared secrets are available between the endpoints. Section 5.3.1 and Section 5.3.2 both refer to the auxiliary shared secret auxsecret. The auxsecret shared secret may be defined by the VoIP user agent out-of-band from the ZRTP protocol. In some cases it may be provided by the signaling layer as srtps, which is defined in Section 9.2. If it's not provided by the signaling layer, the auxsecret shared secret may be manually provisioned in other application-specific ways that are out-of-band, such as computed from a hashed pass phrase by prior agreement between the two parties. Or it may be a family key used by an institution that the two parties both belong to. It is a generalized mechanism for providing a shared secret that is agreed to between the two parties out of scope of the ZRTP protocol. It is expected that most typical ZRTP endpoints will rarely use auxsecret. For both the initiator and the responder, the shared secrets s1, s2, and s3 will be calculated so that they can all be used later to calculate s0 in Section 5.4.1.4. Here is how s1, s2, and s3 are calculated by both parties: Zimmermann, et al. Expires April 1, 2009 [Page 16] Internet-Draft ZRTP September 2008 The shared secret s1 will be either the initiator's rs1 or the initiator's rs2, depending on which of them can be found in the responder's cache. If the initiator's rs1 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only if that match fails, then if the initiator's rs2 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. If that match also fails, then s1 MUST be set to null. The complexity of the s1 calculation is to recover from any loss of cache sync from an earlier aborted session, due to the Byzantine Generals' Problem [Byzantine]. The shared secret s2 MUST be set to the value of auxsecret if and only if both parties have matching values for auxsecret, as determined by comparing the hashes of auxsecret sent in the DH messages. If they don't match, s2 MUST be set to null. The shared secret s3 MUST be set to the value of pbxsecret if and only if both parties have matching values for pbxsecret, as determined by comparing the hashes of pbxsecret sent in the DH messages. If they don't match, s3 MUST be set to null. If s1, s2, or s3 have null values, they are assumed to have a zero length for the purposes of hashing them later during the s0 calculation. The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is described in the next sections. 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") auxsecretIDr = HMAC(auxsecret, "Responder") pbxsecretIDr = HMAC(pbxsecret, "Responder") The set of keyed hashes (HMACs) of shared secrets 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. From these comparisons, s1, s2, and s3 are calculated per the methods described above in Section 5.3. The expected HMAC values Zimmermann, et al. Expires April 1, 2009 [Page 17] Internet-Draft ZRTP September 2008 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 resulting s1, s2, and s3 values are used later to calculate s0 in Section 5.4.1.4. 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: rs1IDi = HMAC(rs1, "Initiator") rs2IDi = HMAC(rs2, "Initiator") auxsecretIDi = HMAC(auxsecret, "Initiator") pbxsecretIDi = HMAC(pbxsecret, "Initiator") These HMACs of shared secrets 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. From these comparisons, s1, s2, and s3 are calculated per the methods described above in Section 5.3. 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 resulting s1, s2, and s3 values are used later to calculate s0 in Section 5.4.1.4. For example, consider two ZRTP endpoints who share secrets rs1 and pbxsecret (defined in Section 8.3.1). During the comparison, rs1ID and pbxsecretID will match but auxsecretID will not. As a result, s1 = rs1, s2 will be null, and s3 = pbxsecret. Zimmermann, et al. Expires April 1, 2009 [Page 18] Internet-Draft ZRTP September 2008 5.3.3. Handling a Shared Secret Cache Mismatch A shared secret cache mismatch is defined to mean that we expected a cache match because rs1 exists in our local cache, but we computed a null value for s1 (per the method described in Section 5.3). 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 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 the mechanism described in Section 9.1.1 is available, which allows authentication of the DH exchange without human assistance. Or 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 [zfone]), 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 Zimmermann, et al. Expires April 1, 2009 [Page 19] Internet-Draft ZRTP September 2008 must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper." If the alert is rendered by a robot voice instead of a GUI, brevity may be more important: "Something's wrong. You must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper." 5.4. DH and non-DH key agreements 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 cached or previously stored shared secrets in common, and uses them as part of the calculation of the session keys. 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. 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 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 Section 5.8. The value for the DH generator g, the DH prime p, and the length of the DH secret value, svi, are defined in Section 6.1.5. Zimmermann, et al. Expires April 1, 2009 [Page 20] Internet-Draft ZRTP September 2008 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 9 (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. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct short authentication string (SAS) (Section 8) in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. 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 Section 5.8. The value for the DH generator g, the DH prime p, and the length of the DH secret value, svr, are defined in Section 6.1.5. 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. 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 Zimmermann, et al. Expires April 1, 2009 [Page 21] Internet-Draft ZRTP September 2008 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 shared secret IDs as defined in Section 5.3.2. The initiator calculates the same Diffie-Hellman result using: DHResult = pvr^svi mod p 5.4.1.4. Shared Secret Calculation for DH Mode A hash of the received and sent ZRTP messages in the current ZRTP exchange in the following order is calculated by both parties: total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2) Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and Figure 9), 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. 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 [SP800-56A]. This is done by hashing a concatenation of a number of items, including the DHResult, the ZID's of the initiator (ZIDi) and Zimmermann, et al. Expires April 1, 2009 [Page 22] Internet-Draft ZRTP September 2008 the responder (ZIDr), the total_hash, and the set of non-null shared secrets as described in Section 5.3. In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires certain parameters to be hashed together in a particular order, which 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 the set of three shared secrets s1, s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit big-endian integer counter to be included in the hash each time the 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 ) Note that temporary values s1, s2, and s3 were calculated per the methods described above in Section 5.3, and they are erased from memory immediately after they are used to calculate s0. 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 members of the set of shared secrets (s1, s2, and s3) may have lengths of zero if they are null (not shared), and are each preceded by a 4-octet length field. For example, if s2 is null, len(s2) is 0x00000000, and s2 itself would be absent from the hash calculation, which means len(s3) would immediately follow len(s2). 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 ZRTP Session Key is generated which then allows the ZRTP 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. Zimmermann, et al. Expires April 1, 2009 [Page 23] Internet-Draft ZRTP September 2008 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. ZRTPSess MUST be destroyed no later than the end of the call signaling session. The two endpoints proceed with key generation as described in Section 5.5, now that there is a defined s0 and ZRTPSess key. 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. 5.4.2.1. Commitment in Multistream Mode Multistream mode is selected by the initiator setting the Key Agreement Type to "Mult" in the Commit message (Figure 6). 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 does not have a ZRTP Session Key available, the exchange MUST be Zimmermann, et al. Expires April 1, 2009 [Page 24] Internet-Draft ZRTP September 2008 terminated. Otherwise, the responder proceeds to the next section on Shared Secret Calculation, Section 5.4.2.2. If both sides send Multistream Commit messages at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 5.2, and the protocol proceeds. In Multistream mode, both the DHPart1 and DHPart2 messages are skipped. 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.2. Shared Secret Calculation for Multistream Mode 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 messages (Figure 3 and Figure 6), 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. Zimmermann, et al. Expires April 1, 2009 [Page 25] Internet-Draft ZRTP September 2008 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. 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 MUST be used for this purpose. In the most severe resource-limited environments, Preshared mode may be useful with processors that cannot perform a DH calculation in an ergonomically acceptable time limit. Shared key material may be manually provisioned between two such endpoints in advance and still allow a limited subset of functionality. Such a "better than nothing" implementation would have to be regarded as non-compliant with the ZRTP specification, but it could interoperate in Preshared (and if applicable, Multistream) mode with a compliant ZRTP endpoint. Because Preshared mode affects the state of the retained shared secret cache, only one in-process ZRTP Preshared exchange may occur at a time between two ZRTP endpoints. This rule is explained in more detail in Section 5.4.1, and applies for the same reasons as in DH mode. 5.4.3.1. Commitment in Preshared Mode 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. 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. 5.4.3.2. Initiator Behavior The Commit message (Figure 7) 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. Zimmermann, et al. Expires April 1, 2009 [Page 26] Internet-Draft ZRTP September 2008 To assemble a Preshared commit, we must first construct a temporary preshared_key, which is constructed from one of several possible combinations of cached key material, depending on what is available in the shared secret cache. If rs1 is not available in the initiator's cache, then Preshared mode MUST NOT be used. preshared_key = hash( len(rs1) | rs1 | len(auxsecret) | auxsecret | len(pbxsecret) | pbxsecret ) 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 members of the set of shared secrets (rs1, auxsecret, and pbxsecret) may have lengths of zero if they are null (not available), and are each preceded by a 4-octet length field. For example, if auxsecret is null, len(auxsecret) is 0x00000000, and auxsecret itself would be absent from the hash calculation, which means len(pbxsecret) would immediately follow len(auxsecret). In place of hvi in the Commit message, two smaller fields are inserted by the initiator: - A random nonce of length 4-words (16 octets). - A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits. 5.4.3.3. Responder Behavior The responder uses the received keyID to search for matching key material in its cache. It does this by computing a preshared_key value and keyID value using the same formula as the initiator, depending on what is available in the responder's local cache. If the locally computed keyID does not match the received keyID in the Commit, the responder recomputes a new preshared_key and keyID from a different subset of shared keys from the cache, dropping auxsecret or pbxsecret or both from the hash calculation, until a matching preshared_key is found or it runs out of possibilities. Note that rs2 is not included in the process. If it finds the appropriate matching shared key material, it is used to derive s0 and a new ZRTPSess key, as described in the next section on Shared Secret Calculation, Section 5.4.3.4. If the responder determines that it does not have a cached shared secret from a previous DH exchange, or it fails to match the keyID hash from the initiator with any combination of its shared keys, it SHOULD 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 Zimmermann, et al. Expires April 1, 2009 [Page 27] Internet-Draft ZRTP September 2008 DH mode. However, if a severely resource-limited responder lacks the computing resources to respond in a reasonable time with a DH Commit, it MAY respond with a ZRTP Error message (Section 6.9) indicating that no shared secret is available. If both sides send Preshared Commit messages initiating a secure session at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 5.2, and the protocol proceeds. In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. 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.3.4. Shared Secret Calculation for Preshared Mode 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 messages (Figure 3 and Figure 7), 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. Next, the preshared_key is used to derive s0 and ZRTPSess: s0 = HMAC(preshared_key, total_hash) ZRTPSess = HMAC(s0,"ZRTP Session Key") The preshared_key is erased as soon as it has been used to calculate s0 and ZRTPSess. The ZRTPSess key allows the later use of Multistream mode for adding additional media streams to this session. 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 Zimmermann, et al. Expires April 1, 2009 [Page 28] Internet-Draft ZRTP September 2008 generation as described in Section 5.5, now that there is a defined s0 and ZRTPSess key. 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 activated in Multistream mode, s0 means s0n, for the n-th media stream. It is also assumed that the ZRTPSess key has been defined. Various keys, such as those used by SRTP, must be derived from the 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 Zimmermann, et al. Expires April 1, 2009 [Page 29] Internet-Draft ZRTP September 2008 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. zrtpkeyi = HMAC(s0,"Initiator ZRTP key") zrtpkeyr = HMAC(s0,"Responder ZRTP key") All key material is destroyed as soon as it is no longer needed, no later than the end of the call. s0 is erased in Section 5.6.1, and the rest of the session key material is erased in Section 5.7.2.1 and Section 5.7.3. 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 (Figure 10) contain the cache expiration interval (defined in Section 5.9) for the newly generated retained shared secret. The flagoctet is an 8 bit unsigned integer made up of these flags: the PBX Enrollment flag (E) defined in Section 8.3.1, SAS Verified flag (V) defined in Section 8.1, Allow Clear flag (A) defined in Section 5.7.2, and Disclosure flag (D) defined in Section 12. 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 (Section 8.2) (if present). For the responder hmac = HMAC(hmackeyr, encrypted part of Confirm1) For the initiator: Zimmermann, et al. Expires April 1, 2009 [Page 30] Internet-Draft ZRTP September 2008 hmac = HMAC(hmackeyi, encrypted part of Confirm2) The hmackeyi and hmackeyr keys are computed in Section 5.5. The Conf2ACK message sent by the responder completes the exchange. 5.6.1. Updating the Cache of Shared Secrets After receiving the Confirm messages, both parties must now update their retained shared secret rs1 in their respective caches, provided the following conditions hold: 1) This key exchange is either DH or Preshared mode, not Multistream mode, which does not update the cache. 2) Depending on the values of the cache expiration intervals that are received in the two Confirm messages, there are some scenarios that do not update the cache, as explained in Section 5.9. 3) The responder MUST receive the initiator's Confirm2 message before updating the responder's cache. 4) The initiator MUST receive the responder's Conf2Ack message before updating the initiator's cache. For DH mode only, before updating the retained shared secret rs1 in the cache, each party first discards their old rs2 and copies their old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of session interruption after one party has updated his own rs1 but before the other party has enough information to update her own rs1. If that happens, they may regain cache sync in the next session by using rs2 (per Section 5.3). This mitigates the well-known Byzantine Generals' Problem [Byzantine]. The old rs1 value is not saved in Preshared mode. For DH mode and Preshared mode, both parties compute a new rs1 value from s0 this way: rs1 = HMAC(s0,"retained secret") After s0 is used to derive the new rs1, it MUST be erased. Even if rs1 is not updated (in the case of Multistream mode), s0 MUST still be destroyed. 5.7. Termination A ZRTP session is normally terminated at the end of a call, but it may be terminated early by either the Error message or the GoClear message. Zimmermann, et al. Expires April 1, 2009 [Page 31] Internet-Draft ZRTP September 2008 5.7.1. Termination via Error message The Error message (Section 6.9) 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, ZRTPSess, is only deleted if the ZRTP session in which it was generated and all ZRTP sessions which are using it are terminated. 5.7.2. Termination via GoClear message The GoClear message (Section 6.11) 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 GoClear Message computed with the hmackey derived from the shared secret. This HMAC is truncated to the leftmost 64 bits. 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 (Figure 10) 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, and generates a ClearACK in response. It MUST also delete all the crypto key material for all the SRTP media streams, as defined in Section 5.7.2.1. 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 to the user an indication that the media session has switched to clear mode, and waits for Zimmermann, et al. Expires April 1, 2009 [Page 32] Internet-Draft ZRTP September 2008 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. 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, as defined in Section 5.7.2.1, 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, as defined in Section 5.7.2.1. 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.7.2.1. Key Destruction for GoClear message All SRTP session key material MUST be erased by the receiver of the GoClear message upon receiving a properly authenticated GoClear. The same key destruction MUST be done by the sender of GoClear message, upon receiving the ClearACK. In particular, the destroyed key material includes the SRTP session keys and salts, SRTP master keys and salts, and all material sufficient to reconstruct the SRTP keys and salts, including ZRTPSess (s0 should have been destroyed earlier, in Section 5.6.1). All key material that would have been erased at the end of the SIP session MUST be erased. However, ZRTPSess is destroyed in a manner different from the other key material. Both parties replace ZRTPSess with a hash of itself, without truncation: ZRTPSess = hash(ZRTPSess) This meets the requirements of Perfect Forward Secrecy (PFS), but preserves a new version of ZRTPSess, so that if the user later re- initiates secure mode during the same call, the new key negotiation Zimmermann, et al. Expires April 1, 2009 [Page 33] Internet-Draft ZRTP September 2008 can (and SHOULD) use a Multistream Commit message, which requires and assumes the existence of ZRTPSess with the same value at both ZRTP endpoints. Later, at the end of the entire call, ZRTPSess is finally destroyed along with the other key material, as described in Section 5.7.3. 5.7.3. Key Destruction at Termination All SRTP session key material MUST be erased by both parties at the end of the call. In particular, the destroyed key material includes the SRTP session keys and salts, SRTP master keys and salts, and all material sufficient to reconstruct the SRTP keys and salts, including ZRTPSess and s0 (although s0 should have been destroyed earlier, in Section 5.6.1). The only exceptions are the cached shared secrets needed for future calls, including rs1, rs2, and pbxsecret. 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 [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. 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 [SP800-90], and in [Ferguson]. Failure to use true entropy from the physical environment as a basis for generating random cryptographic key material would lead to a disastrous loss of security. 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 April 1, 2009 [Page 34] Internet-Draft ZRTP September 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. But first the previous rs1 is copied to 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 (Figure 10). 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. This means if either Confirm message contains a null cache expiration interval, and there is no cache entry already defined, no new cache entry is created. A value of 0xffffffff means the secret should be cached indefinitely and is the recommended value. If the ZRTP exchange is 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. If the expiration interval is not properly agreed to by both endpoints, it may later result in false alarms of MiTM attacks, due to apparent cache mismatches (Section 5.3.3). Zimmermann, et al. Expires April 1, 2009 [Page 35] Internet-Draft ZRTP September 2008 5.9.1. Self-healing Key Continuity Feature The key continuity features of ZRTP are analogous to those provided by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH caches public signature keys that never change, and uses a permanent private signature key that must be guarded from disclosure. If someone steals your SSH private signature key, they can impersonate you in all future sessions and mount a successful MiTM attack any time they want. ZRTP caches symmetric key material used to compute secret session keys, and these values change with each session. If someone steals your ZRTP shared secret cache, they only get one chance to mount a MiTM attack, in the very next session. If they miss that chance, the retained shared secret is refreshed with a new value, and the window of vulnerability heals itself, which means they are locked out of any future opportunities to mount a MiTM attack. This gives ZRTP a "self-healing" feature if any cached key material is compromised. A MiTM attacker must always be in the media path. This presents a significant operational burden for the attacker in many VoIP usage scenarios, because being in the media path for every call is often harder than being in the signaling path. This will likely create coverage gaps in the attacker's opportunities to mount a MiTM attack. ZRTP's self-healing key continuity features are better than SSH at exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP quickly recovers from any disclosure of cached key material. The infamous Debian OpenSSL weak key vulnerability [dsa-1571] (discovered and patched in May 2008) offers a real-world example of why ZRTP's self-healing scheme is a good way to do key continuity. The Debian bug resulted in the production of a lot of weak SSH (and TLS/SSL) keys, which continued to compromise security even after the bug had been patched. In contrast, ZRTP's key continuity scheme adds new entropy to the cached key material with every call, so old deficiencies in entropy are washed away with each new session. It should be noted that the addition of shared secret entropy from previous sessions can extend the strength of the new session key to AES-256 levels, even if the new session uses Diffie-Hellman keys no larger than DH-3072 or ECDH-256, provided the cached shared secrets were initially established when the wiretapper was not present. This is why AES-256 MAY be used with the smaller DH key sizes in Section 6.1.5. Zimmermann, et al. Expires April 1, 2009 [Page 36] Internet-Draft ZRTP September 2008 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. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ZRTP Packet Format 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. Zimmermann, et al. Expires April 1, 2009 [Page 37] Internet-Draft ZRTP September 2008 The ZRTP Messages are defined in Figure 3 to Figure 17 and are of variable length. The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as defined in RFC 3309 [RFC3309] 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 effects of a false announcement of this by ZRTP 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 Zimmermann, et al. Expires April 1, 2009 [Page 38] Internet-Draft ZRTP September 2008 may be defined in extensions to ZRTP. 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 April 1, 2009 [Page 39] Internet-Draft ZRTP September 2008 6.1.2. Hash Type Block Only one Hash Type is currently defined, SHA-256 [FIPS-180-2], and all ZRTP endpoints MUST support this hash. Additional Hash Types can be registered and used, such as the NIST SHA-3 hash [SHA-3] when it becomes available. Note that the Hash Type refers to the hash algorithm that will be used throughout the ZRTP key exchange, not the hash algorithm to be used in the SRTP Authentication Tag. ZRTP makes use of HMAC message authentication codes based on the negotiated Hash Type. The HMAC function is defined in [FIPS-198-1]. Test vectors for HMAC-SHA-256 may be found in [RFC4231]. Hash Type Block | Meaning --------------------------------------------------- "S256" | SHA-256 Hash defined in FIPS 180-2 --------------------------------------------------- Table 2. Hash Block Type Values All hashes and HMACs used throughout the ZRTP protocol will use the negotiated Hash Type, except for the special cases noted in Section 6.1.2.1. 6.1.2.1. Implicit Hash and HMAC algorithm While most of the HMACs used in ZRTP are defined by the negotiated Hash Type (Section 6.1.2), some hashes and HMACs must be precomputed prior to negotiations, and thus cannot have their algorithms negotiated during the ZRTP exchange. They are implicitly predetermined to use SHA-256 [FIPS-180-2] and HMAC-SHA-256. These are the hashes and HMACs that MUST use the Implicit hash and HMAC algorithm: The hash chain H0-H3 defined in Section 10. The HMACs that are keyed by this hash chain, as defined in Section 9.1.1. The Hello Hash in the a=zrtp-hash attribute defined in Section 9.1. ZRTP defines a method for negotiating different ZRTP protocol versions (Section 5.1.1). SHA-256 is the Implicit Hash for ZRTP protocol version 1.00. Future ZRTP protocol versions may, if appropriate, use another hash algorithm as the Implicit Hash, such as the NIST SHA-3 hash [SHA-3] when it becomes available. For example, a future SIP packet may list two a=zrtp-hash SDP attributes, one based on SHA-256 for ZRTP version 1.00, and another based on SHA-3 Zimmermann, et al. Expires April 1, 2009 [Page 40] Internet-Draft ZRTP September 2008 for ZRTP version 2.00. 6.1.3. Cipher Type Block All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- 256 (AES3). or other Cipher Types. The choice of the AES key length is coupled to the Key Agreement type, as explained in Section 6.1.5. The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- 256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. Cipher Type Block | Meaning --------------------------------------------------- "AES1" | AES-CM with 128 bit keys | as defined in RFC 3711 --------------------------------------------------- "AES3" | AES-CM with 256 bit keys | --------------------------------------------------- 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 [RFC3711]. 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 --------------------------------------------------- Table 4. Auth Tag Values 6.1.5. Key Agreement Type Block All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and MAY support EC25, EC38, and EC52. If a ZRTP endpoint supports multiple concurrent media streams, such as audio and video, it MUST support Multistream (Section 5.4.2) mode. Also, if a ZRTP endpoint supports the GoClear message (Section 5.7.2), it SHOULD support Multistream, to be used if the two parties choose to return to the secure state after going Clear (as Zimmermann, et al. Expires April 1, 2009 [Page 41] Internet-Draft ZRTP September 2008 explained in Section 5.7.2.1). For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the 3072-bit MODP group. The DH generator g is 2. The random Diffie- Hellman secret exponent SHOULD be twice as long as the AES key length. If AES-128 is used, the DH secret value SHOULD be 256 bits long. If AES-256 is used, the secret value SHOULD be 512 bits long. If Elliptic Curve DH is used, the ECDH algorithm and key generation is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by FIPS 186-3 [FIPS-186-3], and can also be found in RFC 4753 [RFC4753], sections 3.1 through 3.3. The validation procedures are from NIST SP 800-56A [SP800-56A] 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 either EC38 or EC52 is chosen as the key agreement, AES-256 (AES3) SHOULD be used. If DH3K or EC25 is chosen, either AES-128 (AES1) or AES-256 (AES3) MAY be used. ZRTP also defines two non-DH modes, Multistream and Preshared, in which the SRTP key is derived from a shared secret and some nonce material. 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 April 1, 2009 [Page 42] Internet-Draft ZRTP September 2008 Key Agreement | pv | message | Meaning Type Block | words | words | --------------------------------------------------- "DH3k" | 96 | 117 | DH mode with p=3072 bit prime | | | as defined in RFC 3526 --------------------------------------------------- "Prsh" | - | - | Preshared Non-DH mode | | | --------------------------------------------------- "Mult" | - | - | Multistream Non-DH mode | | | --------------------------------------------------- "EC25" | 16 | 37 | Elliptic Curve DH, P-256 | | | per RFC 4753, section 3.1 --------------------------------------------------- "EC38" | 24 | 45 | Elliptic Curve DH, P-384 | | | per RFC 4753, section 3.2 --------------------------------------------------- "EC52" | 33 | 54 | 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 8. 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 April 1, 2009 [Page 43] Internet-Draft ZRTP September 2008 6.1.7. Signature Type Block The signature type block is a 4 octet (1 word) block used to represent the signature algorithm discussed in Section 8.2. 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.95" (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 MiTM flag (M) is a boolean that is set to true if and only if this Hello message is sent from a device, usually a PBX, that has the capability to send an SASrelay message (Section 6.13). 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 Zimmermann, et al. Expires April 1, 2009 [Page 44] Internet-Draft ZRTP September 2008 whole message, not including the HMAC, of course. The HMAC key is the sender's H2 (defined in Section 10), and thus the HMAC cannot be checked by the receiving party until the sender's H2 value is known to the receiving party later in the protocol. 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.95" (1 word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Client Identifier (4 words) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Hash image H3 (8 words) | | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ZID (3 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|M|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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hello message format Figure 3: Hello message format Zimmermann, et al. Expires April 1, 2009 [Page 45] Internet-Draft ZRTP September 2008 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 shown in the Figure 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloACK message format 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), and hvi, which is a hash of the DHPart2 of the Initiator and the Responder's Hello message, as explained in Section 5.4.1.1. The hash image H2 is defined in Section 10. The Commit Message formats are shown in Figure 5, Figure 6, and 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 H1 (defined in Section 10), and thus the HMAC cannot be checked by the receiving party until the sender's H1 value is known to the receiving party later in the protocol. Zimmermann, et al. Expires April 1, 2009 [Page 46] Internet-Draft ZRTP September 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DH Commit message format Figure 5: DH Commit message format Zimmermann, et al. Expires April 1, 2009 [Page 47] Internet-Draft ZRTP September 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 = "Mult" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | nonce (4 words) | | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multistream Commit message format Figure 6: Multistream Commit message format Zimmermann, et al. Expires April 1, 2009 [Page 48] Internet-Draft ZRTP September 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) | | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | keyID (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Preshared Commit message format Figure 7: Preshared Commit message format 6.5. DHPart1 message The DHPart1 message begins the DH exchange. The format is shown in Figure 8 below. The DHPart1 message is sent by the Responder if a valid Commit message is received from the Initiator. The length of Zimmermann, et al. Expires April 1, 2009 [Page 49] Internet-Draft ZRTP September 2008 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 both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent. The 256-bit hash image H1 is defined in Section 10. The next four 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 auxsecretIDr, the HMAC of the responder's auxsecret (defined in Section 5.3), truncated to 64 bits. The last parameter is the HMAC of the trusted MiTM PBX shared secret pbxsecret, defined in Section 8.3.1. The Message format for the DHPart1 message is shown in Figure 8. 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 the HMAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol. Zimmermann, et al. Expires April 1, 2009 [Page 50] Internet-Draft ZRTP September 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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | auxsecretIDr (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pbxsecretIDr (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | pvr (length depends on KA Type) | | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (2 words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHPart1 message format Figure 8: DH Part1 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 both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent. The 256-bit hash image H1 is defined in Section 10. Zimmermann, et al. Expires April 1, 2009 [Page 51] Internet-Draft ZRTP September 2008 The next four 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 auxsecretIDi, the HMAC of the initiator's auxsecret (defined in Section 5.3), truncated to 64 bits. The last parameter is the HMAC of the trusted MiTM PBX shared secret pbxsecret, defined in Section 8.3.1. The message format for the DHPart2 message is shown in Figure 9. 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 the HMAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol. Zimmermann, et al. Expires April 1, 2009 [Page 52] Internet-Draft ZRTP September 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