idnits 2.17.1 draft-zimmermann-avt-zrtp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4168. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 26, 2008) is 5630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4753 (Obsoleted by RFC 5903) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-08 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-06 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Zimmermann 3 Internet-Draft Zfone Project 4 Intended status: Informational A. Johnston, Ed. 5 Expires: May 30, 2009 Avaya 6 J. Callas 7 PGP Corporation 8 November 26, 2008 10 ZRTP: Media Path Key Agreement for Secure RTP 11 draft-zimmermann-avt-zrtp-11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 30, 2009. 38 Abstract 40 This document defines ZRTP, a protocol for media path Diffie-Hellman 41 exchange to agree on a session key and parameters for establishing 42 Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP 43 protocol is media path keying because it is multiplexed on the same 44 port as RTP and does not require support in the signaling protocol. 45 ZRTP does not assume a Public Key Infrastructure (PKI) or require the 46 complexity of certificates in end devices. For the media session, 47 ZRTP provides confidentiality, protection against man-in-the-middle 48 (MiTM) attacks, and, in cases where the signaling protocol provides 49 end-to-end integrity protection, authentication. ZRTP can utilize a 50 Session Description Protocol (SDP) attribute to provide discovery and 51 authentication through the signaling channel. To provide best effort 52 SRTP, ZRTP utilizes normal RTP/AVP profiles. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 7 60 3.1.1. Diffie-Hellman Mode Overview . . . . . . . . . . . . . 7 61 3.1.2. Multistream Mode Overview . . . . . . . . . . . . . . 9 62 3.1.3. Preshared Mode Overview . . . . . . . . . . . . . . . 9 63 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 64 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1.1. Protocol Version Negotiation . . . . . . . . . . . . . 11 66 4.2. Commit Contention . . . . . . . . . . . . . . . . . . . . 13 67 4.3. Matching Shared Secret Determination . . . . . . . . . . . 13 68 4.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 15 69 4.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 16 70 4.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 16 71 4.4. DH and non-DH key agreements . . . . . . . . . . . . . . . 18 72 4.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 18 73 4.4.1.1. Hash Commitment in Diffie-Hellman Mode . . . . . . 18 74 4.4.1.2. Responder Behavior in Diffie-Hellman Mode . . . . 19 75 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode . . . . 20 76 4.4.1.4. Shared Secret Calculation for DH Mode . . . . . . 20 77 4.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 22 78 4.4.2.1. Commitment in Multistream Mode . . . . . . . . . . 22 79 4.4.2.2. Shared Secret Calculation for Multistream Mode . . 23 80 4.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 24 81 4.4.3.1. Commitment in Preshared Mode . . . . . . . . . . . 25 82 4.4.3.2. Initiator Behavior in Preshared Mode . . . . . . . 25 83 4.4.3.3. Responder Behavior in Preshared Mode . . . . . . . 26 84 4.4.3.4. Shared Secret Calculation for Preshared Mode . . . 26 85 4.5. Key Derivations . . . . . . . . . . . . . . . . . . . . . 27 86 4.5.1. The ZRTP Key Derivation Function . . . . . . . . . . . 27 87 4.5.2. Deriving keys via the ZRTP KDF . . . . . . . . . . . . 28 88 4.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 29 89 4.6.1. Updating the Cache of Shared Secrets . . . . . . . . . 30 90 4.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 31 91 4.7.1. Termination via Error message . . . . . . . . . . . . 31 92 4.7.2. Termination via GoClear message . . . . . . . . . . . 31 93 4.7.2.1. Key Destruction for GoClear message . . . . . . . 33 94 4.7.3. Key Destruction at Termination . . . . . . . . . . . . 33 95 4.8. Random Number Generation . . . . . . . . . . . . . . . . . 34 96 4.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 34 97 4.9.1. Cacheless implementations . . . . . . . . . . . . . . 35 98 5. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 36 99 5.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 37 100 5.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 37 101 5.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 38 102 5.1.2.1. Implicit Hash and HMAC algorithm . . . . . . . . . 39 103 5.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 39 104 5.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 40 105 5.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 40 106 5.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 42 107 5.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 43 108 5.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 43 109 5.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 45 110 5.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 45 111 5.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 48 112 5.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 50 113 5.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 52 114 5.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 53 115 5.9. Error message . . . . . . . . . . . . . . . . . . . . . . 54 116 5.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 55 117 5.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 56 118 5.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 56 119 5.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 57 120 5.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 59 121 6. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 60 122 7. Short Authentication String . . . . . . . . . . . . . . . . . 61 123 7.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 62 124 7.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 64 125 7.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 64 126 7.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 66 127 8. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 67 128 8.1. Binding the media stream to the signaling layer via 129 the Hello Hash . . . . . . . . . . . . . . . . . . . . . . 68 130 8.1.1. Integrity-protected signaling enables 131 integrity-protected DH exchange . . . . . . . . . . . 70 132 8.2. Deriving the SRTP secret (srtps) from the signaling 133 layer . . . . . . . . . . . . . . . . . . . . . . . . . . 71 134 8.3. Codec Selection for Secure Media . . . . . . . . . . . . . 72 135 9. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 72 136 10. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 74 137 11. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 76 138 11.1. Guidelines on Proper Implementation of the Disclosure 139 Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 140 12. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 78 141 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 142 14. Appendix - Media Security Requirements . . . . . . . . . . . . 79 143 15. Security Considerations . . . . . . . . . . . . . . . . . . . 81 144 15.1. Self-healing Key Continuity Feature . . . . . . . . . . . 84 145 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 146 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 147 17.1. Normative References . . . . . . . . . . . . . . . . . . . 86 148 17.2. Informative References . . . . . . . . . . . . . . . . . . 87 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 150 Intellectual Property and Copyright Statements . . . . . . . . . . 91 152 1. Introduction 154 ZRTP is a key agreement protocol which performs Diffie-Hellman key 155 exchange during call setup in the media path, and is transported over 156 the same port as the Real-time Transport Protocol (RTP) [RFC3550] 157 media stream which has been established using a signaling protocol 158 such as Session Initiation Protocol (SIP) [RFC3261]. This generates 159 a shared secret which is then used to generate keys and salt for a 160 Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone 161 [pgpfone]. A reference implementation of ZRTP is available as Zfone 162 [zfone]. 164 The ZRTP protocol has some nice cryptographic features lacking in 165 many other approaches to media session encryption. Although it uses 166 a public key algorithm, it does not rely on a public key 167 infrastructure (PKI). In fact, it does not use persistent public 168 keys at all. It uses ephemeral Diffie-Hellman (DH) with hash 169 commitment, and allows the detection of man-in-the-middle (MiTM) 170 attacks by displaying a short authentication string (SAS) for the 171 users to read and verbally compare over the phone. It has Perfect 172 Forward Secrecy, meaning the keys are destroyed at the end of the 173 call, which precludes retroactively compromising the call by future 174 disclosures of key material. But even if the users are too lazy to 175 bother with short authentication strings, we still get reasonable 176 authentication against a MiTM attack, based on a form of key 177 continuity. It does this by caching some key material to use in the 178 next call, to be mixed in with the next call's DH shared secret, 179 giving it key continuity properties analogous to SSH. All this is 180 done without reliance on a PKI, key certification, trust models, 181 certificate authorities, or key management complexity that bedevils 182 the email encryption world. It also does not rely on SIP signaling 183 for the key management, and in fact does not rely on any servers at 184 all. It performs its key agreements and key management in a purely 185 peer-to-peer manner over the RTP packet stream. 187 In cases where the short authentication string (SAS) cannot be 188 verbally compared by two human users, the SAS can be authenticated by 189 exchanging an optional signature over the SAS (described in 190 Section 7.2). 192 ZRTP can be used and discovered without being declared or indicated 193 in the signaling path. This provides a best effort SRTP capability. 194 Also, this reduces the complexity of implementations and minimizes 195 interdependency between the signaling and media layers. However, 196 when ZRTP is indicated in the signaling via the zrtp-hash SDP 197 attribute, ZRTP has additional useful properties. By sending a hash 198 of the ZRTP Hello message in the signaling, ZRTP provides a useful 199 binding between the signaling and media paths, which is explained in 200 Section 8.1. When this is done through a signaling path that has 201 end-to-end integrity protection, the DH exchange is automatically 202 protected from a MiTM attack, which is explained in Section 8.1.1. 204 2. Terminology 206 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 207 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 208 and "OPTIONAL" are to be interpreted as described in RFC 2119 and 209 indicate requirement levels for compliant implementations [RFC2119]. 211 3. Overview 213 This section provides a description of how ZRTP works. This 214 description is non-normative in nature but is included to build 215 understanding of the protocol. 217 ZRTP is negotiated the same way a conventional RTP session is 218 negotiated in an offer/answer exchange using the standard AVP/RTP 219 profile. The ZRTP protocol begins after two endpoints have utilized 220 a signaling protocol such as SIP and are ready to exchange media. If 221 ICE [I-D.ietf-mmusic-ice] is being used, ZRTP begins after ICE has 222 completed its connectivity checks. 224 ZRTP is multiplexed on the same ports as RTP. It uses a unique 225 header that makes it clearly differentiable from RTP or STUN. 227 In environments in which sending ZRTP packets to non-ZRTP endpoints 228 might cause problems and signaling path discovery is not an option, 229 ZRTP endpoints can include the RTP header extension flag for ZRTP in 230 normal RTP packets sent at the start of a session as a probe to 231 discover if the other endpoint supports ZRTP. If the flag is 232 received from the other endpoint, ZRTP messages can then be 233 exchanged. 235 A ZRTP endpoint initiates the exchange by sending a ZRTP Hello 236 message to the other endpoint. The purpose of the Hello message is 237 to confirm the endpoint supports the protocol and to see what 238 algorithms the two ZRTP endpoints have in common. 240 The Hello message contains the SRTP configuration options, and the 241 ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID 242 that is generated once at installation time. ZIDs are discovered 243 during the Hello message exchange. The received ZID is used to look 244 up retained shared secrets from previous ZRTP sessions with the 245 endpoint. 247 A response to a ZRTP Hello message is a ZRTP HelloACK message. The 248 HelloACK message simply acknowledges receipt of the Hello. Since RTP 249 commonly uses best effort UDP transport, ZRTP has retransmission 250 timers in case of lost datagrams. There are two timers, both with 251 exponential backoff mechanisms. One timer is used for 252 retransmissions of Hello messages and the other is used for 253 retransmissions of all other messages after receipt of a HelloACK. 255 If an integrity protected signaling channel is available, a hash of 256 the Hello message can be sent. This allows rejection of false 257 injected ZRTP Hello messages by an attacker. 259 Hello and other ZRTP messages also contain a hash image that is used 260 to link the messages together. This allows rejection of false 261 injected ZRTP messages during an exchange. 263 3.1. Key Agreement Modes 265 After both endpoints exchange Hello and HelloACK messages, the key 266 agreement exchange can begin with the ZRTP Commit message. ZRTP 267 supports a number of key agreement modes including both Diffie- 268 Hellman and non-Diffie-Hellman modes as described in the following 269 sections. 271 The Commit message may be sent immediately after both endpoints have 272 completed the Hello/HelloAck discovery handshake. Or it may be 273 deferred until later in the call, after the participants engage in 274 some unencrypted conversation. The Commit message may be manually 275 activated by a user interface element, such as a GO SECURE button, 276 which becomes enabled after the Hello/HelloAck discovery phase. This 277 emulates the user experience of a number of secure phones in the PSTN 278 world [comsec]. However, it is expected that most simple ZRTP user 279 agents will omit such buttons and proceed directly to secure mode by 280 sending a Commit message immediately after the Hello/HelloAck 281 handshake. 283 3.1.1. Diffie-Hellman Mode Overview 285 An example ZRTP call flow is shown in Figure 1 below. Note that the 286 order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be 287 reversed. That is, either Alice or Bob might send the first Hello 288 message. Note that the endpoint which sends the Commit message is 289 considered the initiator of the ZRTP session and drives the key 290 agreement exchange. The Diffie-Hellman public values are exchanged 291 in the DHPart1 and DHPart2 messages. SRTP keys and salts are then 292 calculated. 294 Alice Bob 295 | | 296 | Alice and Bob establish a media session. | 297 | They initiate ZRTP on media ports | 298 | | 299 | F1 Hello (version, options, Alice's ZID) | 300 |-------------------------------------------------->| 301 | HelloACK F2 | 302 |<--------------------------------------------------| 303 | Hello (version, options, Bob's ZID) F3 | 304 |<--------------------------------------------------| 305 | F4 HelloACK | 306 |-------------------------------------------------->| 307 | | 308 | Bob acts as the initiator | 309 | | 310 | Commit (Bob's ZID, options, hvi) F5 | 311 |<--------------------------------------------------| 312 | F6 DHPart1 (pvr, shared secret hashes) | 313 |-------------------------------------------------->| 314 | DHPart2 (pvi, shared secret hashes) F7 | 315 |<--------------------------------------------------| 316 | | 317 | Alice and Bob generate SRTP session key. | 318 | | 319 | F8 Confirm1 (HMAC, D,A,V,E flags, sig) | 320 |-------------------------------------------------->| 321 | Confirm2 (HMAC, D,A,V,E flags, sig) F9 | 322 |<--------------------------------------------------| 323 | F10 Conf2ACK | 324 |-------------------------------------------------->| 325 | SRTP begins | 326 |<=================================================>| 327 | | 329 Figure 1: Establishment of an SRTP session using ZRTP 331 ZRTP authentication uses a Short Authentication String (SAS) which is 332 ideally displayed for the human user. Alternatively, the SAS can be 333 authenticated by exchanging an OPTIONAL digital signature (sig) over 334 the short authentication string in the Confirm1 or Confirm2 messages 335 (described in Section 7.2). 337 The ZRTP Confirm1 and Confirm2 messages are sent for a number of 338 reasons, not the least of which is they confirm that all the key 339 agreement calculations were successful and thus the encryption will 340 work. They also carry other information such as the Disclosure flag 341 (D), the Allow Clear flag (A), the SAS Verified flag (V), and the PBX 342 Enrollment flag (E). All flags are encrypted to shield them from a 343 passive observer. 345 3.1.2. Multistream Mode Overview 347 Multistream mode is an alternative key agreement method when two 348 endpoints have an established SRTP media stream between them and 349 hence an active ZRTP Session key. ZRTP can derive multiple SRTP keys 350 from a single DH exchange. For example, an established secure voice 351 call that adds a video stream must use Multistream mode to quickly 352 initiate the video stream without a second DH exchange. 354 When Multistream mode is indicated in the Commit message, a call flow 355 similar to Figure 1 is used, but no DH calculation is performed by 356 either endpoint and the DHPart1 and DHPart2 messages are omitted. 357 The Confirm1, Confirm2, and Conf2ACK messages are still sent. Since 358 the cache is not affected during this mode, multiple Multistream ZRTP 359 exchanges can be performed in parallel between two endpoints. 361 When adding additional media streams to an existing call, only 362 Multistream mode is used. Only one DH operation is performed, just 363 for the first media stream. 365 3.1.3. Preshared Mode Overview 367 In the Preshared Mode, endpoints can skip the DH calculation if they 368 have a shared secret from a previous ZRTP session. Preshared mode is 369 indicated in the Commit message and results in the same call flow as 370 Multistream mode. The principal difference between Multistream mode 371 and Preshared mode is that Preshared mode uses a previously cached 372 shared secret, rs1, instead of an active ZRTP Session key as the 373 initial keying material. 375 This mode could be useful for slow processor endpoints so that a DH 376 calculation does not need to be performed every session. Or, this 377 mode could be used to rapidly re-establish an earlier session that 378 was recently torn down or interrupted without the need to perform 379 another DH calculation. 381 Preshared mode has forward secrecy properties. If a phone's cache is 382 captured by an opponent, the cached shared secrets cannot be used to 383 recover earlier encrypted calls, because the shared secrets are 384 replaced with new ones in each new call, as in DH mode. However, the 385 captured secrets can be used by a passive wiretapper in the media 386 path to decrypt the next call, if the next call is in Preshared mode. 387 This differs from DH mode, which requires an active MiTM wiretapper 388 to exploit captured secrets in the next call. However, if the next 389 call is missed by the wiretapper, he cannot wiretap any further 390 calls. It thus preserves most of the self-healing properties 391 (Section 15.1) of key continuity enjoyed by DH mode. 393 4. Protocol Description 395 This section begins the normative description of the protocol. 397 ZRTP MUST be multiplexed on the same ports as the RTP media packets. 399 To support best effort encryption from the Media Security 400 Requirements [I-D.ietf-sip-media-security-requirements], ZRTP uses 401 normal RTP/AVP profile (AVP) media lines in the initial offer/answer 402 exchange. The ZRTP SDP attribute a=zrtp-hash defined in Section 8 403 SHOULD be used in all offers and answers to indicate support for the 404 ZRTP protocol. The Secure RTP/AVP (SAVP) profile MAY be used in 405 subsequent offer/answer exchanges after a successful ZRTP exchange 406 has resulted in an SRTP session, or if it is known the other endpoint 407 supports this profile. 409 The use of the RTP/SAVP profile has caused failures in negotiating 410 best effort SRTP due to the limitations on negotiating profiles 411 using SDP. This is why ZRTP supports the RTP/AVP profile and 412 includes its own discovery mechanisms. 414 In all key agreement modes, the initiator SHOULD NOT send RTP media 415 after sending the Commit message, and MUST NOT send SRTP media before 416 receiving either the Conf2ACK or the first SRTP media (with a valid 417 SRTP auth tag) from the responder. The responder SHOULD NOT send RTP 418 media after receiving the Commit message, and MUST NOT send SRTP 419 media before receiving the Confirm2 message. 421 4.1. Discovery 423 During the ZRTP discovery phase, a ZRTP endpoint discovers if the 424 other endpoint supports ZRTP and the supported algorithms and 425 options. This information is transported in a Hello message, 426 described in Section 5.2. 428 ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers 429 and answers, as defined in Section 8. ZRTP MAY use an RTP [RFC3550] 430 extension field as a flag to indicate support for the ZRTP protocol 431 in RTP packets as described in Section 12. 433 The Hello message includes the ZRTP version, hash type, cipher type, 434 authentication method and tag length, key agreement type, and Short 435 Authentication String (SAS) algorithms that are supported. The Hello 436 message also includes a hash image as described in Section 9. In 437 addition, each endpoint sends and discovers ZIDs. The received ZID 438 is used later in the protocol as an index into a cache of shared 439 secrets that were previously negotiated and retained between the two 440 parties. 442 A Hello message can be sent at any time, but is usually sent at the 443 start of an RTP session to determine if the other endpoint supports 444 ZRTP, and also if the SRTP implementations are compatible. A Hello 445 message is retransmitted using timer T1 and an exponential backoff 446 mechanism detailed in Section 6 until the receipt of a HelloACK 447 message or a Commit message. 449 The use of the a=zrtp-hash SDP attribute to authenticate the Hello 450 message is described in Section 8.1. 452 4.1.1. Protocol Version Negotiation 454 This specification defines ZRTP version 1.00. Since new versions of 455 ZRTP may be developed in the future, this specification defines a 456 protocol version negotiation in this section. 458 Each party declares what version of the ZRTP protocol they support 459 via the version field in the Hello message (Section 5.2). If both 460 parties have the same version number in their Hello messages, they 461 can proceed with the rest of the protocol. To facilitate both 462 parties reaching this state of protocol version agreement in their 463 Hello messages, ZRTP should use information provided in the signaling 464 layer, if available. If a ZRTP endpoint supports more than one 465 version of the protocol, it SHOULD declare them all in a list of SIP 466 SDP a=zrtp-hash attributes (defined in Section 8), listing separate 467 hashes, with separate ZRTP version numbers in each item in the list. 469 Both parties should inspect the list of ZRTP version numbers supplied 470 by the other party in the SIP SDP a=zrtp-hash attributes. Both 471 parties should choose the highest version number that appear in both 472 parties' list of a=zrtp-hash version numbers, and use that version 473 for their Hello messages. If both parties use the SIP signaling in 474 this manner, their initial Hello messages will have the same ZRTP 475 version number, provided they both have at least one supported 476 protocol version in common. Before the ZRTP key agreement can 477 proceed, an endpoint MUST have sent and received Hellos with the same 478 protocol version. 480 It is best if the signaling layer is used to negotiate the protocol 481 version number. However, the a=zrtp-hash SDP attribute is not always 482 present in the SIP packet, as explained in Section 8.1. In the 483 absence of any guidance from the signaling layer, an endpoint MUST 484 send the highest supported version in initial Hello messages. If the 485 two parties send different protocol version numbers in their Hello 486 messages, they can reach agreement to use a common version, if one 487 exists. They iteratively apply the following rules until they both 488 have matching version fields in their Hello messages and the key 489 agreement can proceed: 491 o If an endpoint receives a Hello message with an unsupported 492 version number that is higher than the endpoint's current Hello 493 message version, the received Hello message MUST be ignored. The 494 endpoint continues to retransmit Hello messages on the standard 495 retry schedule (Section 6). 496 o If an endpoint receives a Hello message with a version number that 497 is lower than the endpoint's current Hello message, and the 498 endpoint supports a version that is less than or equal to the 499 received version number, the endpoint MUST stop retransmitting the 500 old version number and MUST start sending a new Hello message with 501 the highest supported version number that is less than or equal to 502 the received version number. 503 o If an endpoint receives a Hello message with an unsupported 504 version number that is lower than the endpoint's current Hello 505 message, the endpoint MUST send an Error message (Section 5.9) 506 indicating failure to support this ZRTP version. 508 The above comparisons are iterated until the version numbers match, 509 or until it exits on a failure to match. 511 For example, assume that Alice supports protocol version 1.00 and 512 2.00, and Bob supports version 1.00 and 1.10. Alice initially 513 sends a Hello with version 2.00, and Bob initially sends a Hello 514 with version 1.10. Bob ignores Alice's 2.00 Hello and continues 515 to send his 1.10 Hello. Alice detects that Bob does not support 516 2.00 and she stops sending her 2.00 Hellos and starts sending a 517 stream of 1.00 Hellos. Bob sees the 1.00 Hello from Alice and 518 stops sending his 1.10 Hellos and switches to sending 1.00 Hellos. 519 At that point, they have converged on using version 1.00 and the 520 protocol proceeds on that basis. 522 When comparing protocol versions, a ZRTP endpoint MUST include only 523 the first three octets of the version field in the comparison. The 524 final octet is ignored, because it is not significant for 525 interoperability. For example, "1.0 ", "1.00", "1.01", or "1.0a" are 526 all regarded as a version match, because they would all be 527 interoperable versions. 529 Changes in protocol version numbers are expected be infrequent after 530 version 1.00. Supporting multiple versions adds code complexity and 531 may introduce security weaknesses in the implementation. The old 532 adage about keeping it simple applies especially to implementing 533 security protocols. Endpoints SHOULD NOT support protocol versions 534 earlier than version 1.00. 536 4.2. Commit Contention 538 After both parties have received compatible Hello messages, a Commit 539 message (Section 5.4) can be sent to begin the ZRTP key exchange. 540 The endpoint that sends the Commit is known as the initiator, while 541 the receiver of the Commit is known as the responder. 543 If both sides send Commit messages initiating a secure session at the 544 same time the following rules are used to break the tie: 546 o If one Commit is for a DH mode while the other is for Preshared 547 mode, then the Preshared Commit MUST be discarded and the DH 548 Commit proceeds. 549 o If the two Commits are both Preshared mode, and one party has set 550 the MiTM (M) flag in the Hello message and the other has not, the 551 Commit message from the party who set the (M) flag MUST be 552 discarded, and the one who has not set the (M) flag becomes the 553 initiator, regardless of the nonce values. In other words, for 554 Preshared mode, the phone is the initiator and the PBX is the 555 responder. 556 o If the two Commits are either both DH modes or both non-DH modes, 557 then the Commit message with the lowest hvi value (for DH 558 Commits), or lowest nonce value (for non-DH Commits), MUST be 559 discarded and the other side is the initiator, and the protocol 560 proceeds with the initiator's Commit. The two hvi or nonce values 561 are compared as large unsigned integers in network byte order. 563 If one Commit is for Multistream mode while the other is for non- 564 Multistream (DH or Preshared) mode, a software error has occurred and 565 the ZRTP negotiation should be terminated. This should never occur 566 because of the constraints on Multistream mode described in 567 Section 4.4.2. 569 In the event that Commit messages are sent by both ZRTP endpoints at 570 the same time, but are received in different media streams, the same 571 resolution rules apply as if they were received on the same stream. 572 The media stream in which the Commit will proceed through the ZRTP 573 exchange while the media stream with the discarded Commit must wait 574 for the completion of the other ZRTP exchange. 576 4.3. Matching Shared Secret Determination 578 The following sections describe how ZRTP endpoints generate and/or 579 use the set of shared secrets s1, auxsecret, and pbxsecret through 580 the exchange of the DHPart1 and DHPart2 messages. This doesn't cover 581 the Diffie-Hellman calculations. It only covers the method whereby 582 the two parties determine if they already have shared secrets in 583 common in their caches. 585 Each ZRTP endpoint maintains a long-term cache of shared secrets that 586 it has previously negotiated with the other party. The ZID of the 587 other party, received in the other party's Hello message, is used as 588 an index into this cache to find the set of shared secrets, if any 589 exist. This cache entry may contain previously retained shared 590 secrets, rs1 and rs2, which give ZRTP its key continuity features. 591 If the other party is a PBX, the cache may also contain a trusted 592 MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1. 594 The DHPart1 and DHPart2 messages contain a list of hashes of these 595 shared secrets to allow the two endpoints to compare the hashes with 596 what they have in their caches to detect whether the two sides share 597 any secrets that can be used in the calculation of the session key. 598 The use of this shared secret cache is described in Section 4.9. 600 If no secret of a given type is available, a random value is 601 generated and used for that secret to ensure a mismatch in the hash 602 comparisons in the DHPart1 and DHPart2 messages. This prevents an 603 eavesdropper from knowing which types of shared secrets are available 604 between the endpoints. 606 Section 4.3.1 and Section 4.3.2 both refer to the auxiliary shared 607 secret auxsecret. The auxsecret shared secret may be defined by the 608 VoIP user agent out-of-band from the ZRTP protocol. In some cases it 609 may be provided by the signaling layer as srtps, which is defined in 610 Section 8.2. If it is not provided by the signaling layer, the 611 auxsecret shared secret may be manually provisioned in other 612 application-specific ways that are out-of-band, such as computed from 613 a hashed pass phrase by prior agreement between the two parties. Or 614 it may be a family key used by an institution that the two parties 615 both belong to. It is a generalized mechanism for providing a shared 616 secret that is agreed to between the two parties out of scope of the 617 ZRTP protocol. It is expected that most typical ZRTP endpoints will 618 rarely use auxsecret. 620 For both the initiator and the responder, the shared secrets s1, s2, 621 and s3 will be calculated so that they can all be used later to 622 calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are 623 calculated by both parties: 625 The shared secret s1 will be either the initiator's rs1 or the 626 initiator's rs2, depending on which of them can be found in the 627 responder's cache. If the initiator's rs1 matches the responder's 628 rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only 629 if that match fails, then if the initiator's rs2 matches the 630 responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. 631 If that match also fails, then s1 MUST be set to null. The 632 complexity of the s1 calculation is to recover from any loss of cache 633 sync from an earlier aborted session, due to the Byzantine Generals' 634 Problem [Byzantine]. 636 The shared secret s2 MUST be set to the value of auxsecret if and 637 only if both parties have matching values for auxsecret, as 638 determined by comparing the hashes of auxsecret sent in the DH 639 messages. If they don't match, s2 MUST be set to null. 641 The shared secret s3 MUST be set to the value of pbxsecret if and 642 only if both parties have matching values for pbxsecret, as 643 determined by comparing the hashes of pbxsecret sent in the DH 644 messages. If they don't match, s3 MUST be set to null. 646 If s1, s2, or s3 have null values, they are assumed to have a zero 647 length for the purposes of hashing them later during the s0 648 calculation in Section 4.4.1.4. 650 The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is 651 described in the next sections. 653 4.3.1. Responder Behavior 655 The responder calculates an HMAC keyed hash using the first retained 656 shared secret, rs1, as the key on the string "Responder" which 657 generates a retained secret ID, rs1IDr, which is truncated to the 658 leftmost 64 bits. HMACs are calculated in a similar way for 659 additional shared secrets: 661 rs1IDr = HMAC(rs1, "Responder") 662 rs2IDr = HMAC(rs2, "Responder") 663 auxsecretIDr = HMAC(auxsecret, "Responder") 664 pbxsecretIDr = HMAC(pbxsecret, "Responder") 666 The set of keyed hashes (HMACs) of shared secrets are included by the 667 responder in the DHPart1 message. 669 The HMACs of the possible shared secrets received in the DHPart2 can 670 be compared against the HMACs of the local set of possible shared 671 secrets. From these comparisons, s1, s2, and s3 are calculated per 672 the methods described above in Section 4.3. The expected HMAC values 673 of the shared secrets are calculated (using the string "Initiator" 674 instead of "Responder") as in Section 4.3.2 and compared to the HMACs 675 received in the DHPart2 message. The secrets corresponding to 676 matching HMACs are kept while the secrets corresponding to the non- 677 matching ones are replaced with a null, which is assumed to have a 678 zero length for the purposes of hashing them later. The resulting 679 s1, s2, and s3 values are used later to calculate s0 in 680 Section 4.4.1.4. 682 4.3.2. Initiator Behavior 684 The initiator calculates an HMAC keyed hash using the first retained 685 shared secret, rs1, as the key on the string "Initiator" which 686 generates a retained secret ID, rs1IDi, which is truncated to the 687 leftmost 64 bits. HMACs are calculated in a similar way for 688 additional shared secrets: 690 rs1IDi = HMAC(rs1, "Initiator") 691 rs2IDi = HMAC(rs2, "Initiator") 692 auxsecretIDi = HMAC(auxsecret, "Initiator") 693 pbxsecretIDi = HMAC(pbxsecret, "Initiator") 695 These HMACs of shared secrets are included by the initiator in the 696 DHPart2 message. 698 The initiator then calculates the set of secret IDs that are expected 699 to be received from the responder in the DHPart1 message by 700 substituting the string "Responder" instead of "Initiator" as in 701 Section 4.3.1. 703 The HMACs of the possible shared secrets received are compared 704 against the HMACs of the local set of possible shared secrets. From 705 these comparisons, s1, s2, and s3 are calculated per the methods 706 described above in Section 4.3. The secrets corresponding to 707 matching HMACs are kept while the secrets corresponding to the non- 708 matching ones are replaced with a null, which is assumed to have a 709 zero length for the purposes of hashing them later. The resulting 710 s1, s2, and s3 values are used later to calculate s0 in 711 Section 4.4.1.4. 713 For example, consider two ZRTP endpoints who share secrets rs1 and 714 pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID 715 and pbxsecretID will match but auxsecretID will not. As a result, s1 716 = rs1, s2 will be null, and s3 = pbxsecret. 718 4.3.3. Handling a Shared Secret Cache Mismatch 720 A shared secret cache mismatch is defined to mean that we expected a 721 cache match because rs1 exists in our local cache, but we computed a 722 null value for s1 (per the method described in Section 4.3). 724 If one party has a cached shared secret and the other party does not, 725 this indicates one of two possible situations. Either there is a 726 man-in-the-middle (MiTM) attack, or one of the legitimate parties has 727 lost their cached shared secret by some mishap. Perhaps they 728 inadvertently deleted their cache, or their cache was lost or 729 disrupted due to restoring their disk from an earlier backup copy. 730 The party that has the surviving cache entry can easily detect that a 731 cache mismatch has occurred, because they expect their own cached 732 secret to match the other party's cached secret, but it does not 733 match. It is possible for both parties to detect this condition if 734 both parties have surviving cached secrets that have fallen out of 735 sync, due perhaps to one party restoring from a disk backup. 737 If either party discovers a cache mismatch, the user agent who makes 738 this discovery must treat this as a possible security event and MUST 739 alert their own user that there is a heightened risk of a MiTM 740 attack, and that the user should verbally compare the SAS with the 741 other party to ascertain that no MiTM attack has occurred. If a 742 cache mismatch is detected and it is not possible to compare the SAS, 743 either because the user interface does not support it or because one 744 or both endpoints are unmanned devices, and no other SAS comparison 745 mechanism is available, the session MAY be terminated. 747 The session need not be terminated on a cache mismatch event if the 748 mechanism described in Section 8.1.1 is available, which allows 749 authentication of the DH exchange without human assistance. Or if 750 any mechanism is available to determine if the SAS matches. This 751 would require either circumstances that allow human verbal 752 comparisons of the SAS, or by using the OPTIONAL digital signature 753 feature on the SAS hash, as described in Section 7.2. Even if the 754 user interface does not permit an SAS comparison, the human user MUST 755 be warned, and may elect to proceed with the call at their own risk. 757 Here is a non-normative example of a cache-mismatch alert message 758 from a ZRTP user agent (specifically, Zfone [zfone]), designed for a 759 desktop PC graphical user interface environment. It is by no means 760 required that the alert be this detailed: 762 "We expected the other party to have a shared secret cached from a 763 previous call, but they don't have it. This may mean your partner 764 simply lost his cache of shared secrets, but it could also mean 765 someone is trying to wiretap you. To resolve this question you 766 must check the authentication string with your partner. If it 767 doesn't match, it indicates the presence of a wiretapper." 768 If the alert is rendered by a robot voice instead of a GUI, 769 brevity may be more important: "Something's wrong. You must check 770 the authentication string with your partner. If it doesn't match, 771 it indicates the presence of a wiretapper." 773 4.4. DH and non-DH key agreements 775 The next step is the generation of a secret for deriving SRTP keying 776 material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, 777 described in the following sections. 779 4.4.1. Diffie-Hellman Mode 781 The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman 782 or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP 783 endpoints to generate a new shared secret, s0. In addition, the 784 endpoints discover if they have any cached or previously stored 785 shared secrets in common, and uses them as part of the calculation of 786 the session keys. 788 Because the DH exchange affects the state of the retained shared 789 secret cache, only one in-process ZRTP DH exchange may occur at a 790 time between two ZRTP endpoints. Otherwise, race conditions and 791 cache integrity problems will result. When multiple media streams 792 are established in parallel between the same pair of ZRTP endpoints 793 (determined by the ZIDs in the Hello Messages), only one can be 794 processed. Once that exchange completes with Confirm2 and Conf2ACK 795 messages, another ZRTP DH exchange can begin. This constraint does 796 not apply when Multistream mode key agreement is used since the 797 cached shared secrets are not affected. 799 4.4.1.1. Hash Commitment in Diffie-Hellman Mode 801 From the intersection of the algorithms in the sent and received 802 Hello messages, the initiator chooses a hash, cipher, auth tag, key 803 agreement type, and SAS type to be used. 805 A Diffie-Hellman mode is selected by setting the Key Agreement Type 806 to one of the DH or ECDH values in Table 5 in the Commit. In this 807 mode, the key agreement begins with the initiator choosing a fresh 808 random Diffie-Hellman (DH) secret value (svi) based on the chosen key 809 agreement type value, and computing the public value. (Note that to 810 speed up processing, this computation can be done in advance.) For 811 guidance on generating random numbers, see Section 4.8. The value 812 for the DH generator g, the DH prime p, and the length of the DH 813 secret value, svi, are defined in Section 5.1.5. 815 pvi = g^svi mod p 817 where g and p are determined by the key agreement type value. The 818 pvi value is formatted as a big-endian octet string, fixed to the 819 width of the DH prime, and leading zeros MUST NOT be truncated. 821 The hash commitment is performed by the initiator of the ZRTP 822 exchange. The hash value of the initiator, hvi, includes a hash of 823 the entire DHPart2 message as shown in Figure 9 (which includes the 824 Diffie-Hellman public value, pvi), and the responder's Hello message: 826 hvi = hash(initiator's DHPart2 message | responder's Hello 827 message) 829 Note that the Hello message includes the fields shown in Figure 3. 831 The information from the responder's Hello message is included in the 832 hash calculation to prevent a bid-down attack by modification of the 833 responder's Hello message. 835 The initiator sends hvi in the Commit message. 837 The use of hash commitment in the DH exchange constrains the attacker 838 to only one guess to generate the correct short authentication string 839 (SAS) (Section 7) in his attack, which means the SAS can be quite 840 short. A 16-bit SAS, for example, provides the attacker only one 841 chance out of 65536 of not being detected. 843 4.4.1.2. Responder Behavior in Diffie-Hellman Mode 845 Upon receipt of the Commit message, the responder generates its own 846 fresh random DH secret value, svr, and computes the public value. 847 (Note that to speed up processing, this computation can be done in 848 advance.) For guidance on random number generation, see Section 4.8. 849 The value for the DH generator g, the DH prime p, and the length of 850 the DH secret value, svr, are defined in Section 5.1.5. 852 pvr = g^svr mod p 854 The pvr value is formatted as a big-endian octet string, fixed to the 855 width of the DH prime, and leading zeros MUST NOT be truncated. 857 Upon receipt of the DHPart2 message, the responder checks that the 858 initiator's public DH value is not equal to 1 or p-1. An attacker 859 might inject a false DHPart2 packet with a value of 1 or p-1 for 860 g^svi mod p, which would cause a disastrously weak final DH result to 861 be computed. If pvi is 1 or p-1, the user should be alerted of the 862 attack and the protocol exchange MUST be terminated. Otherwise, the 863 responder computes its own value for the hash commitment using the 864 public DH value (pvi) received in the DHPart2 packet and its Hello 865 packet and compares the result with the hvi received in the Commit 866 packet. If they are different, a MiTM attack is taking place and the 867 user is alerted and the protocol exchange terminated. 869 The responder then calculates the Diffie-Hellman result: 871 DHResult = pvi^svr mod p 873 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode 875 Upon receipt of the DHPart1 message, the initiator checks that the 876 responder's public DH value is not equal to 1 or p-1. An attacker 877 might inject a false DHPart1 packet with a value of 1 or p-1 for 878 g^svr mod p, which would cause a disastrously weak final DH result to 879 be computed. If pvr is 1 or p-1, the user should be alerted of the 880 attack and the protocol exchange MUST be terminated. 882 The initiator then sends a DHPart2 message containing the initiator's 883 public DH value and the set of calculated shared secret IDs as 884 defined in Section 4.3.2. 886 The initiator calculates the same Diffie-Hellman result using: 888 DHResult = pvr^svi mod p 890 4.4.1.4. Shared Secret Calculation for DH Mode 892 A hash of the received and sent ZRTP messages in the current ZRTP 893 exchange in the following order is calculated by both parties: 895 total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2) 897 Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and 898 Figure 9), not the entire ZRTP packets, are included in the 899 total_hash. 901 For both the initiator and responder, the DHResult is formatted as a 902 big-endian octet string, fixed to the width of the DH prime, and 903 leading zeros MUST NOT be truncated. For example, for a 3072-bit p, 904 DHResult would be a 384 octet value, with the first octet the most 905 significant. 907 The calculation of the final shared secret, s0, is in compliance with 908 the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A 909 [SP800-56A]. This is done by hashing a concatenation of a number of 910 items, including the DHResult, the ZID's of the initiator (ZIDi) and 911 the responder (ZIDr), the total_hash, and the set of non-null shared 912 secrets as described in Section 4.3. 914 In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires 915 certain parameters to be hashed together in a particular order, which 916 NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, 917 SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult 918 corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our 919 ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash 920 corresponds to SuppPubInfo, and the set of three shared secrets s1, 921 s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit 922 big-endian integer counter to be included in the hash each time the 923 hash is computed, which we have set to the fixed value of 1, because 924 we only compute the hash once. NIST refers to the final hash output 925 as DerivedKeyingMaterial, which corresponds to our s0 in this 926 calculation. 928 s0 = hash( counter | DHResult | "ZRTP-HMAC-KDF" | ZIDi | ZIDr | 929 total_hash | len(s1) | s1 | len(s2) | s2 | len(s3) | s3 ) 931 Note that temporary values s1, s2, and s3 were calculated per the 932 methods described above in Section 4.3, and they are erased from 933 memory immediately after they are used to calculate s0. 935 The length of the DHResult field was implicitly agreed to by the 936 negotiated DH prime size. The length of total_hash is implicitly 937 determined by the negotiated hash algorithm. All of the explicit 938 length fields, len(), in the above hash are 32-bit big-endian 939 integers, giving the length in octets of the field that follows. 940 Some members of the set of shared secrets (s1, s2, and s3) may have 941 lengths of zero if they are null (not shared), and are each preceded 942 by a 4-octet length field. For example, if s2 is null, len(s2) is 943 0x00000000, and s2 itself would be absent from the hash calculation, 944 which means len(s3) would immediately follow len(s2). While 945 inclusion of ZIDi and ZIDr may be redundant, because they are 946 implicitly included in the total_hash, we explicitly include them 947 here to follow NIST SP800-56A. The string "ZRTP-HMAC-KDF" (not null- 948 terminated) identifies what purpose the resulting s0 will be used 949 for, which is to serve as the master key for the ZRTP HMAC-based key 950 derivation function (KDF) defined in Section 4.5.1 and used in 951 Section 4.5.2. 953 A ZRTP Session Key is derived from s0 via the ZRTP key derivation 954 function (Section 4.5.1) which then allows the ZRTP Multistream mode 955 to be used to generate SRTP key and salt pairs for additional 956 concurrent media streams between this pair of ZRTP endpoints. If a 957 ZRTP Session Key has already been generated between this pair of 958 endpoints and is available, no new ZRTP Session Key is calculated. 960 ZRTPSess = KDF(s0, "ZRTP Session Key", negotiated hash length) 962 The ZRTPSess key is kept for the duration of the call signaling 963 session between the two ZRTP endpoints. That is, if there are two 964 separate calls between the endpoints (in SIP terms, separate SIP 965 dialogs), then a ZRTP Session Key MUST NOT be used across the two 966 call signaling sessions. ZRTPSess MUST be destroyed no later than 967 the end of the call signaling session. 969 The two endpoints proceed with key derivations as described in 970 Section 4.5.2, now that there is a defined s0 and ZRTPSess key. 972 4.4.2. Multistream Mode 974 The Multistream key agreement mode can be used to generate SRTP keys 975 and salts for additional media streams established between a pair of 976 endpoints. Multistream mode cannot be used unless there is an active 977 SRTP session established between the endpoints which means a ZRTP 978 Session key is active. This ZRTP Session key can be used to generate 979 keys and salts without performing another DH calculation. In this 980 mode, the retained shared secret cache is not used or updated. As a 981 result, multiple ZRTP Multistream mode exchanges can be processed in 982 parallel between two endpoints. 984 Multistream mode is also used to resume a secure call that has gone 985 clear using a GoClear message as described in Section 4.7.2.1. 987 When adding additional media streams to an existing call, Multistream 988 mode MUST be used. The first media stream MUST use either DH mode or 989 Preshared mode. Only one DH exchange or Preshared exchange is 990 performed, just for the first media stream. The DH exchange or 991 Preshared exchange MUST be completed for the first media stream 992 before Multistream mode is used to add any other media streams. 994 4.4.2.1. Commitment in Multistream Mode 996 Multistream mode is selected by the initiator setting the Key 997 Agreement Type to "Mult" in the Commit message (Figure 6). The 998 Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be 999 set by the initiator to the same as the values as in the initial DH 1000 Mode Commit. The SAS Type is ignored as there is no SAS 1001 authentication in this mode. 1003 Note: This requirement is needed since some endpoints cannot 1004 support different SRTP algorithms for different media streams. 1005 However, in the case of Multstream mode being used to go secure 1006 after a GoClear, the requirement to use the same SRTP algorithms 1007 is relaxed if there are no other active SRTP sessions. 1009 In place of hvi in the Commit, a random nonce of length 4-words (16 1010 octets) is chosen. Its value MUST be unique for all nonce values 1011 chosen for active ZRTP sessions between a pair of endpoints. If a 1012 Commit is received with a reused nonce value, the ZRTP exchange MUST 1013 be immediately terminated. 1015 Note: Since the nonce is used to calculate different SRTP key and 1016 salt pairs for each media stream, a duplication will result in the 1017 same key and salt being generated for the two media streams, which 1018 would have disastrous security consequences. 1020 If a Commit is received selecting Multistream mode, but the responder 1021 does not have a ZRTP Session Key available, the exchange MUST be 1022 terminated. Otherwise, the responder proceeds to the next section on 1023 Shared Secret Calculation, Section 4.4.2.2. 1025 If both sides send Multistream Commit messages at the same time, the 1026 contention is resolved and the initiator/responder roles are settled 1027 according to Section 4.2, and the protocol proceeds. 1029 In Multistream mode, both the DHPart1 and DHPart2 messages are 1030 skipped. After receiving the Commit message from the initiator, the 1031 responder sends the Confirm1 message after calculating this stream's 1032 SRTP keys, as described below. 1034 4.4.2.2. Shared Secret Calculation for Multistream Mode 1036 A hash of the received and sent ZRTP messages in the current ZRTP 1037 exchange for the current media stream is calculated: 1039 total_hash = hash(Hello of responder | Commit ) 1041 This refers to the Hello and Commit messages for the current media 1042 stream which is using Multistream mode, not the original media stream 1043 that included a full DH key agreement. Note that only the ZRTP 1044 messages (Figure 3 and Figure 6), not the entire ZRTP packets, are 1045 included in the hash. 1047 The SRTP keys and salts for the initiator and responder are 1048 calculated using the ZRTP Session Key ZRTPSess and the nonce from the 1049 Commit message. The nonce from the Commit message is implicitly 1050 included in the total_hash, which hashed the entire Commit message 1051 and the other party's Hello message. For the n-th media stream, s0n 1052 is derived from ZRTPSess via the ZRTP key derivation function 1053 (Section 4.5.1): 1055 s0n = KDF(ZRTPSess, total_hash, negotiated hash length) 1057 Note that the responder's Hello message, included in the total_hash, 1058 includes some unique nonce-derived material of its own (the H3 hash 1059 image), thereby ensuring that each of the two parties can 1060 unilaterally force the resulting s0n shared secret to be unique for 1061 each media stream, even if one party by some error fails to produce a 1062 unique nonce. Note also that the ZRTPSess key is derived from 1063 material that also includes a different and more inclusive total_hash 1064 from the entire packet sequence that performed the original DH 1065 exchange for the first media stream in this ZRTP session. 1067 At this point in Multistream mode, the two endpoints begin key 1068 derivations as described in Section 4.5.2 using s0n in place of s0 in 1069 the key derivation formulas for this media stream. 1071 4.4.3. Preshared Mode 1073 The Preshared key agreement mode can be used to generate SRTP keys 1074 and salts without a DH calculation, instead relying on a shared 1075 secret from previous DH calculations between the endpoints. 1077 This key agreement mode is useful to rapidly re-establish a secure 1078 session between two parties who have recently started and ended a 1079 secure session that has already performed a DH key agreement, without 1080 performing another lengthy DH calculation, which may be desirable on 1081 slow processors in resource-limited environments. Preshared mode 1082 MUST NOT be used for adding additional media streams to an existing 1083 call. Multistream mode MUST be used for this purpose. 1085 In the most severe resource-limited environments, Preshared mode may 1086 be useful with processors that cannot perform a DH calculation in an 1087 ergonomically acceptable time limit. Shared key material may be 1088 manually provisioned between two such endpoints in advance and still 1089 allow a limited subset of functionality. Such a "better than 1090 nothing" implementation would have to be regarded as non-compliant 1091 with the ZRTP specification, but it could interoperate in Preshared 1092 (and if applicable, Multistream) mode with a compliant ZRTP endpoint. 1094 Because Preshared mode affects the state of the retained shared 1095 secret cache, only one in-process ZRTP Preshared exchange may occur 1096 at a time between two ZRTP endpoints. This rule is explained in more 1097 detail in Section 4.4.1, and applies for the same reasons as in DH 1098 mode. 1100 Preshared mode MUST NOT be used for establishing a second media 1101 stream. Multistream mode is designed for that. 1103 Preshared mode is only included in this specification to meet the 1104 R-REUSE requirement in the Media Security Requirements 1105 [I-D.ietf-sip-media-security-requirements] document. A series of 1106 preshared-keyed calls between two ZRTP endpoints should use a DH key 1107 exchange periodically. Preshared mode is only used if a cached 1108 shared secret has been established in an earlier session by a DH 1109 exchange, as discussed in Section 4.9. 1111 4.4.3.1. Commitment in Preshared Mode 1113 Preshared mode is selected by setting the Key Agreement Type to 1114 Preshared in the Commit message. This results in the same call flow 1115 as Multistream mode. The principal difference between Multistream 1116 mode and Preshared mode is that Preshared mode uses a previously 1117 cached shared secret, rs1, instead of an active ZRTP Session key, 1118 ZRTPSess, as the initial keying material. 1120 Because Preshared mode depends on having a reliable shared secret in 1121 its cache, it is RECOMMENDED that Preshared mode only be used when 1122 the SAS Verified flag has been previously set. 1124 4.4.3.2. Initiator Behavior in Preshared Mode 1126 The Commit message (Figure 7) is sent by the initiator of the ZRTP 1127 exchange. From the intersection of the algorithms in the sent and 1128 received Hello messages, the initiator chooses a hash, cipher, auth 1129 tag, key agreement type, and SAS type to be used. 1131 To assemble a Preshared commit, we must first construct a temporary 1132 preshared_key, which is constructed from one of several possible 1133 combinations of cached key material, depending on what is available 1134 in the shared secret cache. If rs1 is not available in the 1135 initiator's cache, then Preshared mode MUST NOT be used. 1137 preshared_key = hash( len(rs1) | rs1 | len(auxsecret) | auxsecret 1138 | len(pbxsecret) | pbxsecret ) 1140 All of the explicit length fields, len(), in the above hash are 32- 1141 bit big-endian integers, giving the length in octets of the field 1142 that follows. Some members of the set of shared secrets (rs1, 1143 auxsecret, and pbxsecret) may have lengths of zero if they are null 1144 (not available), and are each preceded by a 4-octet length field. 1145 For example, if auxsecret is null, len(auxsecret) is 0x00000000, and 1146 auxsecret itself would be absent from the hash calculation, which 1147 means len(pbxsecret) would immediately follow len(auxsecret). 1149 In place of hvi in the Commit message, two smaller fields are 1150 inserted by the initiator: 1152 - A random nonce of length 4-words (16 octets). 1153 - A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits. 1155 4.4.3.3. Responder Behavior in Preshared Mode 1157 The responder uses the received keyID to search for matching key 1158 material in its cache. It does this by computing a preshared_key 1159 value and keyID value using the same formula as the initiator, 1160 depending on what is available in the responder's local cache. If 1161 the locally computed keyID does not match the received keyID in the 1162 Commit, the responder recomputes a new preshared_key and keyID from a 1163 different subset of shared keys from the cache, dropping auxsecret or 1164 pbxsecret or both from the hash calculation, until a matching 1165 preshared_key is found or it runs out of possibilities. Note that 1166 rs2 is not included in the process. 1168 If it finds the appropriate matching shared key material, it is used 1169 to derive s0 and a new ZRTPSess key, as described in the next section 1170 on Shared Secret Calculation, Section 4.4.3.4. 1172 If the responder determines that it does not have a cached shared 1173 secret from a previous DH exchange, or it fails to match the keyID 1174 hash from the initiator with any combination of its shared keys, it 1175 SHOULD respond with its own DH Commit message. This would reverse 1176 the roles and the responder would become the initiator, because the 1177 DH Commit must always "trump" the Preshared Commit message as 1178 described in Section 4.2. The key exchange would then proceeds using 1179 DH mode. However, if a severely resource-limited responder lacks the 1180 computing resources to respond in a reasonable time with a DH Commit, 1181 it MAY respond with a ZRTP Error message (Section 5.9) indicating 1182 that no shared secret is available. 1184 If both sides send Preshared Commit messages initiating a secure 1185 session at the same time, the contention is resolved and the 1186 initiator/responder roles are settled according to Section 4.2, and 1187 the protocol proceeds. 1189 In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. 1190 After receiving the Commit message from the initiator, the responder 1191 sends the Confirm1 message after calculating this stream's SRTP keys, 1192 as described below. 1194 4.4.3.4. Shared Secret Calculation for Preshared Mode 1196 A hash of the received and sent ZRTP messages in the current ZRTP 1197 exchange for the current media stream is calculated: 1199 total_hash = hash(Hello of responder | Commit ) 1201 Note that only the ZRTP messages (Figure 3 and Figure 7), not the 1202 entire ZRTP packets, are included in the hash. The nonce from the 1203 Commit message is implicitly included in the total_hash, which hashed 1204 the entire Commit message and the other party's Hello message. Next, 1205 the preshared_key is used to derive s0 and ZRTPSess, via the ZRTP key 1206 derivation function (Section 4.5.1): 1208 s0 = KDF(preshared_key, total_hash, negotiated hash length) 1209 ZRTPSess = KDF(s0, "ZRTP Session Key", negotiated hash length) 1211 The preshared_key MUST be erased as soon as it has been used to 1212 calculate s0 and ZRTPSess. The ZRTPSess key allows the later use of 1213 Multistream mode for adding additional media streams to this session. 1215 Note that the responder's Hello message, included in the total_hash, 1216 includes some unique nonce-derived material of its own (the H3 hash 1217 image), thereby ensuring that each of the two parties can 1218 unilaterally force the resulting s0 shared secret to be unique for 1219 each media stream, even if one party by some error fails to produce a 1220 unique nonce. 1222 Note: Since the nonce is used to calculate different SRTP key and 1223 salt pairs for each media stream, a duplication will result in the 1224 same key and salt being generated for the two media streams, which 1225 would have disastrous security consequences. 1227 At this point in Preshared mode, the two endpoints begin key 1228 derivations as described in Section 4.5.2, now that there is a 1229 defined s0 and ZRTPSess key. 1231 4.5. Key Derivations 1233 4.5.1. The ZRTP Key Derivation Function 1235 To derive keys from a shared secret, ZRTP uses an HMAC-based key 1236 derivation function, or KDF. It is used throughout Section 4.5.2 and 1237 in other sections. 1239 The ZRTP KDF is defined in this manner: 1241 KDF(KI, Label, L) returns HMAC(KI, Label), truncated to L bits 1243 The HMAC function for the KDF is based on the negotiated hash 1244 algorithm defined in Section 5.1.2. The HMAC in the KDF is keyed by 1245 KI, which is a secret key derivation key that is unknown to the 1246 wiretapper (for example, s0), and the HMAC is computed on a string 1247 (Label) that need not be a secret. The output of the KDF is 1248 truncated to the leftmost L bits, where L is not to exceed the length 1249 of the output of the HMAC. If SHA-256 is the negotiated hash 1250 algorithm, the HMAC would be HMAC-SHA-256, thus the maximum value of 1251 L would be 256, the negotiated hash length. 1253 The ZRTP KDF is designed to provide key separation, which is a 1254 security requirement for the cryptographic keys derived from the same 1255 key derivation key. The keys shall be separate in the sense that the 1256 compromise of some derived keys will not degrade the security 1257 strength of any of the other derived keys. 1259 This KDF was designed before the publication of NIST SP 800-108 1260 [SP800-108], but has the same security properties as the KDF in the 1261 NIST document, when used within the confines of the ZRTP protocol. 1262 The ZRTP KDF is similar to the NIST KDF using the HMAC-based 1263 pseudorandom function in counter mode, with only a single iteration 1264 of the counter. The ZRTP KDF never has to generate more than 256 1265 bits of output key material, so only a single invocation of the HMAC 1266 function is needed. 1268 The ZRTP KDF is not to be confused with the SRTP KDF defined in 1269 [RFC3711]. 1271 4.5.2. Deriving keys via the ZRTP KDF 1273 The following calculations derive a set of keys from s0. For the 1274 original media stream that calculated s0 from the DH exchange, s0 1275 means the original s0. For any additional media streams that were 1276 activated in Multistream mode, s0 means s0n, for the n-th media 1277 stream. It is also assumed that the ZRTPSess key has been defined. 1279 Subkeys are not drawn directly from s0, as done in NIST SP800-56A. To 1280 enhance key separation, ZRTP uses s0 to key an HMAC-based Key 1281 Derivation Function (Section 4.5.1). 1283 Separate SRTP master keys and master salts are derived for use in 1284 each direction for each media stream. Unless otherwise specified, 1285 ZRTP uses SRTP with no MKI, 32 bit authentication using HMAC-SHA1, 1286 AES-CM 128 or 256 bit key length, 112 bit session salt key length, 1287 2^48 key derivation rate, and SRTP prefix length 0. 1289 The ZRTP initiator encrypts and the ZRTP responder decrypts packets 1290 by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts 1291 and the ZRTP initiator decrypts packets by using srtpkeyr and 1292 srtpsaltr. These are generated by: 1294 srtpkeyi = KDF(s0, "Initiator SRTP master key", negotiated AES key 1295 length) 1296 srtpsalti = KDF(s0, "Initiator SRTP master salt", 112) 1297 srtpkeyr = KDF(s0, "Responder SRTP master key", negotiated AES key 1298 length) 1299 srtpsaltr = KDF(s0, "Responder SRTP master salt", 112) 1301 The SRTP key and salt values are truncated (taking the leftmost bits) 1302 to the length determined by the chosen SRTP algorithm. 1304 The HMAC keys are the same length as the output of the underlying 1305 hash function in the KDF, and are thus generated without truncation 1306 by: 1308 hmackeyi = KDF(s0, "Initiator HMAC key", negotiated hash length) 1309 hmackeyr = KDF(s0, "Responder HMAC key", negotiated hash length) 1310 Note that these HMAC keys are used only by ZRTP and not by SRTP. 1311 Note: Different HMAC keys are needed for the initiator and the 1312 responder to ensure that GoClear messages in each direction are 1313 unique and can not be cached by an attacker and reflected back to 1314 the endpoint. 1316 ZRTP keys are generated for the initiator and responder to use to 1317 encrypt the Confirm1 and Confirm2 messages. They are truncated to 1318 the same size as the negotiated SRTP key size. 1320 zrtpkeyi = KDF(s0, "Initiator ZRTP key", negotiated AES key 1321 length) 1322 zrtpkeyr = KDF(s0, "Responder ZRTP key", negotiated AES key 1323 length) 1325 All key material is destroyed as soon as it is no longer needed, no 1326 later than the end of the call. s0 is erased in Section 4.6.1, and 1327 the rest of the session key material is erased in Section 4.7.2.1 and 1328 Section 4.7.3. 1330 The Short Authentication String (SAS) value is calculated from the 1331 HMAC of a fixed string, keyed with the ZRTPSess key derived from the 1332 DH key agreement. This means the same SAS is used for all media 1333 streams which are derived from a single DH key agreement in a ZRTP 1334 session. 1336 sashash = KDF(ZRTPSess, "SAS", negotiated hash length) 1337 sasvalue = sashash [truncated to leftmost 32 bits] 1339 4.6. Confirmation 1341 The Confirm1 and Confirm2 messages (Figure 10) contain the cache 1342 expiration interval (defined in Section 4.9) for the newly generated 1343 retained shared secret. The flagoctet is an 8 bit unsigned integer 1344 made up of these flags: the PBX Enrollment flag (E) defined in 1345 Section 7.3.1, SAS Verified flag (V) defined in Section 7.1, Allow 1346 Clear flag (A) defined in Section 4.7.2, and Disclosure flag (D) 1347 defined in Section 11. 1349 flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) 1351 Part of the Confirm1 and Confirm2 messages are encrypted using full- 1352 block Cipher Feedback Mode, and contain a 128-bit random CFB 1353 Initialization Vector (IV). The Confirm1 and Confirm2 messages also 1354 contain an HMAC covering the encrypted part of the Confirm1 or 1355 Confirm2 message which includes a string of zeros, the signature 1356 length, flag octet, cache expiration interval, signature type block 1357 (if present) and signature block (Section 7.2) (if present). For the 1358 responder: 1360 hmac = HMAC(hmackeyr, encrypted part of Confirm1) 1362 For the initiator: 1364 hmac = HMAC(hmackeyi, encrypted part of Confirm2) 1366 The hmackeyi and hmackeyr keys are computed in Section 4.5.2. 1368 The exchange is completed when the responder sends either the 1369 Conf2ACK message or the responder's first SRTP media packet (with a 1370 valid SRTP auth tag). The initiator MUST treat the first valid SRTP 1371 media from the responder as equivalent to receiving a Conf2ACK. The 1372 responder may respond to Confirm2 with either SRTP media or Conf2ACK, 1373 or both, in whichever order the responder chooses (or whichever order 1374 the "cloud" chooses to deliver them). 1376 4.6.1. Updating the Cache of Shared Secrets 1378 After receiving the Confirm messages, both parties must now update 1379 their retained shared secret rs1 in their respective caches, provided 1380 the following conditions hold: 1382 1) This key exchange is either DH or Preshared mode, not 1383 Multistream mode, which does not update the cache. 1384 2) Depending on the values of the cache expiration intervals that 1385 are received in the two Confirm messages, there are some scenarios 1386 that do not update the cache, as explained in Section 4.9. 1387 3) The responder MUST receive the initiator's Confirm2 message 1388 before updating the responder's cache. 1389 4) The initiator MUST receive either the responder's Conf2ACK 1390 message or the responder's SRTP media (with a valid SRTP auth tag) 1391 before updating the initiator's cache. 1393 For DH mode only, before updating the retained shared secret rs1 in 1394 the cache, each party first discards their old rs2 and copies their 1395 old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of 1396 session interruption after one party has updated his own rs1 but 1397 before the other party has enough information to update her own rs1. 1398 If that happens, they may regain cache sync in the next session by 1399 using rs2 (per Section 4.3). This mitigates the well-known Byzantine 1400 Generals' Problem [Byzantine]. The old rs1 value is not saved in 1401 Preshared mode. 1403 For DH mode and Preshared mode, both parties compute a new rs1 value 1404 from s0 via the ZRTP key derivation function (Section 4.5.1): 1406 rs1 = KDF(s0, "retained secret", negotiated hash length) 1408 After s0 is used to derive the new rs1, it MUST be erased. Even if 1409 rs1 is not updated (in the case of Multistream mode), s0 MUST still 1410 be destroyed. 1412 4.7. Termination 1414 A ZRTP session is normally terminated at the end of a call, but it 1415 may be terminated early by either the Error message or the GoClear 1416 message. 1418 4.7.1. Termination via Error message 1420 The Error message (Section 5.9) is used to terminate an in-progress 1421 ZRTP exchange due to an error. The Error message contains an integer 1422 Error Code for debugging purposes. The termination of a ZRTP key 1423 agreement exchange results in no updates to the cached shared secrets 1424 and deletion of all crypto context. 1426 The ZRTP Session key, ZRTPSess, is only deleted if the ZRTP session 1427 in which it was generated and all ZRTP sessions which are using it 1428 are terminated. 1430 4.7.2. Termination via GoClear message 1432 The GoClear message (Section 5.11) is used to switch from SRTP to 1433 RTP, usually because the user has chosen to do that by pressing a 1434 button. The GoClear uses an HMAC of the Message Type Block sent in 1435 the GoClear Message computed with the hmackey derived from the shared 1436 secret. This HMAC is truncated to the leftmost 64 bits. When sent 1437 by the initiator: 1439 clear_hmac = HMAC(hmackeyi, "GoClear ") 1441 When sent by the responder: 1443 clear_hmac = HMAC(hmackeyr, "GoClear ") 1445 A GoClear message which does not receive a ClearACK response must be 1446 resent. If a GoClear message is received with a bad HMAC, it must be 1447 ignored, and no ClearACK is sent. 1449 A ZRTP endpoint MAY choose to accept GoClear messages after the 1450 session has switched to SRTP, allowing the session to revert to RTP. 1451 This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by 1452 setting the Allow Clear flag (A). If an endpoint sets the Allow 1453 Clear (A) flag in their Confirm message, it indicates that they 1454 support receiving GoClear messages. 1456 A ZRTP endpoint that receives a GoClear MUST authenticate the message 1457 by checking the clear_hmac. If the message authenticates, the 1458 endpoint stops sending SRTP packets, and generates a ClearACK in 1459 response. It MUST also delete all the crypto key material for all 1460 the SRTP media streams, as defined in Section 4.7.2.1. 1462 Until confirmation from the user is received (e.g. clicking a button, 1463 pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending 1464 RTP packets. The endpoint then renders to the user an indication 1465 that the media session has switched to clear mode, and waits for 1466 confirmation from the user. This blocks the flow of sensitive 1467 discourse until the user is forced to take notice that he's no longer 1468 protected by encryption. To prevent pinholes from closing or NAT 1469 bindings from expiring, the ClearACK message MAY be resent at regular 1470 intervals (e.g. every 5 seconds) while waiting for confirmation from 1471 the user. After confirmation of the notification is received from 1472 the user, the sending of RTP packets may begin. 1474 After sending a GoClear message, the ZRTP endpoint stops sending SRTP 1475 packets. When a ClearACK is received, the ZRTP endpoint deletes the 1476 crypto context for the SRTP session, as defined in Section 4.7.2.1, 1477 and may then resume sending RTP packets. 1479 In the event a ClearACK is not received before the retransmissions of 1480 GoClear are exhausted, the key material is deleted, as defined in 1481 Section 4.7.2.1. 1483 After the users have transitioned from SRTP media back to RTP media 1484 (clear mode), they may decide later to return to secure mode by 1485 manual activation, usually by pressing a GO SECURE button. In that 1486 case, a new secure session is initiated by the party that presses the 1487 button, by sending a new Commit packet, leadng to a new session key 1488 negotiation. It is not necessary to send another Hello packet, as 1489 the two parties have already done that at the start of the call and 1490 thus have already discovered each other's ZRTP capabilities. It is 1491 possible for users to toggle back and forth between clear and secure 1492 modes multiple times in the same call, just as they could in the old 1493 days of secure PSTN phones. 1495 4.7.2.1. Key Destruction for GoClear message 1497 All SRTP session key material MUST be erased by the receiver of the 1498 GoClear message upon receiving a properly authenticated GoClear. The 1499 same key destruction MUST be done by the sender of GoClear message, 1500 upon receiving the ClearACK. 1502 In particular, the destroyed key material includes the SRTP session 1503 keys and salts, SRTP master keys and salts, and all material 1504 sufficient to reconstruct the SRTP keys and salts, including ZRTPSess 1505 (s0 should have been destroyed earlier, in Section 4.6.1). All key 1506 material that would have been erased at the end of the SIP session 1507 MUST be erased. However, ZRTPSess is destroyed in a manner different 1508 from the other key material. Both parties replace ZRTPSess with a 1509 hash of itself, without truncation: 1511 ZRTPSess = hash(ZRTPSess) 1513 This meets the requirements of Perfect Forward Secrecy (PFS), but 1514 preserves a new version of ZRTPSess, so that the user can later re- 1515 initiate secure mode during the same call without performing another 1516 Diffie-Hellman calculation using Multistream mode which requires and 1517 assumes the existence of ZRTPSess with the same value at both ZRTP 1518 endpoints. A new key negotiation after a GoClear SHOULD use a 1519 Multistream Commit message. 1521 Note: Multistream mode is preferred over a Diffie-Hellman mode 1522 since this does not require the generation of a new hash chain and 1523 a new signaling exchange to exchange new hash values. 1525 Later, at the end of the entire call, ZRTPSess is finally destroyed 1526 along with the other key material, as described in Section 4.7.3. 1528 4.7.3. Key Destruction at Termination 1530 All SRTP session key material MUST be erased by both parties at the 1531 end of the call. In particular, the destroyed key material includes 1532 the SRTP session keys and salts, SRTP master keys and salts, and all 1533 material sufficient to reconstruct the SRTP keys and salts, including 1534 ZRTPSess and s0 (although s0 should have been destroyed earlier, in 1535 Section 4.6.1). The only exceptions are the cached shared secrets 1536 needed for future calls, including rs1, rs2, and pbxsecret. 1538 4.8. Random Number Generation 1540 The ZRTP protocol uses random numbers for cryptographic key material, 1541 notably for the DH secret exponents and nonces, which must be freshly 1542 generated with each session. Whenever a random number is needed, all 1543 of the following criteria must be satisfied: 1545 Random numbers MUST be freshly generated, meaning that it must not 1546 have been used in a previous calculation. 1548 When generating a random number k of L bits in length, k MUST be 1549 chosen with equal probability from the range of [1 < k < 2^L]. 1551 It MUST be derived from a physical entropy source, such as RF noise, 1552 acoustic noise, thermal noise, high resolution timings of 1553 environmental events, or other unpredictable physical sources of 1554 entropy. For a detailed explanation of cryptographic grade random 1555 numbers and guidance for collecting suitable entropy, see RFC 4086 1556 [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. The 1557 raw entropy must be distilled and processed through a deterministic 1558 random bit generator (DRBG). Examples of DRBGs may be found in NIST 1559 SP 800-90 [SP800-90], and in [Ferguson]. Failure to use true entropy 1560 from the physical environment as a basis for generating random 1561 cryptographic key material would lead to a disastrous loss of 1562 security. 1564 4.9. ZID and Cache Operation 1566 Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that 1567 is generated once at installation time. It is used to look up 1568 retained shared secrets in a local cache. A single global ZID for a 1569 single installation is the simplest way to implement ZIDs. However, 1570 it is specifically not precluded for an implementation to use 1571 multiple ZIDs, up to the limit of a separate one per callee. This 1572 then turns it into a long-lived "association ID" that does not apply 1573 to any other associations between a different pair of parties. It is 1574 a goal of this protocol to permit both options to interoperate 1575 freely. 1577 Each time a new s0 is calculated, a new retained shared secret rs1 is 1578 generated and stored in the cache, indexed by the ZID of the other 1579 endpoint. This cache updating is described in Section 4.6.1. For 1580 the new retained shared secret, each endpoint chooses a cache 1581 expiration value which is an unsigned 32 bit integer of the number of 1582 seconds that this secret should be retained in the cache. The time 1583 interval is relative to when the Confirm1 message is sent or 1584 received. 1586 The cache intervals are exchanged in the Confirm1 and Confirm2 1587 messages (Figure 10). The actual cache interval used by both 1588 endpoints is the minimum of the values from the Confirm1 and Confirm2 1589 messages. A value of 0 seconds means the newly-computed shared 1590 secret SHOULD NOT be stored in the cache, and if a cache entry 1591 already exists from an earlier call, the stored cache interval should 1592 be set to 0. This means if either Confirm message contains a null 1593 cache expiration interval, and there is no cache entry already 1594 defined, no new cache entry is created. A value of 0xffffffff means 1595 the secret should be cached indefinitely and is the recommended 1596 value. If the ZRTP exchange is Multistream Mode, the field in the 1597 Confirm1 and Confirm2 is set to 0xffffffff and ignored, and the cache 1598 is not updated. 1600 The expiration interval need not be used to force the deletion of a 1601 shared secret from the cache when the interval has expired. It just 1602 means the shared secret MAY be deleted from that cache at any point 1603 after the interval has expired without causing the other party to 1604 note it as an unexpected security event when the next key negotiation 1605 occurs between the same two parties. This means there need not be 1606 perfectly synchronized deletion of expired secrets from the two 1607 caches, and makes it easy to avoid a race condition that might 1608 otherwise be caused by clock skew. 1610 If the expiration interval is not properly agreed to by both 1611 endpoints, it may later result in false alarms of MiTM attacks, due 1612 to apparent cache mismatches (Section 4.3.3). 1614 4.9.1. Cacheless implementations 1616 It is possible to implement a simplified but nonetheless useful 1617 profile of the ZRTP protocol that does not support any caching of 1618 shared secrets. In this case the cache expiration interval should 1619 always be set to zero, and the SAS Verified (V) flag (Section 7.1) 1620 should always be set to false. The users would have to rely 1621 exclusively on the verbal SAS comparison for every call. That is, 1622 unless MiTM protection is provided by the mechanisms in Section 8.1.1 1623 or Section 7.2, which introduce their own forms of complexity. 1625 If caching of shared secrets is not supported, it would sacrifice the 1626 key continuity features, as well as Preshared mode (Section 4.4.3). 1627 There would also be no PBX trusted MiTM (Section 7.3) features, 1628 including the PBX security enrollment (Section 7.3.1) mechanism. 1630 5. ZRTP Messages 1632 All ZRTP messages use the message format defined in Figure 2. All 1633 word lengths referenced in this specification are 32 bits or 4 1634 octets. All integer fields are carried in network byte order, that 1635 is, most significant byte (octet) first, commonly known as big- 1636 endian. 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 |0 0 0 1|Not Used (set to zero) | Sequence Number | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | ZRTP Magic Cookie (0x5a525450) | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Source Identifier | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | | 1647 | ZRTP Message (length depends on Message Type) | 1648 | . . . | 1649 | | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | CRC (1 word) | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Figure 2: ZRTP Packet Format 1656 The Sequence Number is a count that is incremented for each ZRTP 1657 packet sent. The count is initialized to a random value. This is 1658 useful in estimating ZRTP packet loss and also detecting when ZRTP 1659 packets arrive out of sequence. 1661 The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a 1662 ZRTP packet, and has the value 0x5a525450. 1664 Source Identifier is the SSRC number of the RTP stream that this ZRTP 1665 packet relates to. For cases of forking or forwarding, RTP and hence 1666 ZRTP may arrive at the same port from several different sources - 1667 each of these sources will have a different SSRC and may initiate an 1668 independent ZRTP protocol session. 1670 This format is clearly identifiable as non-RTP due to the first two 1671 bits being zero which looks like RTP version 0, which is not a valid 1672 RTP version number. It is clearly distinguishable from STUN since 1673 the magic cookies are different. The 12 not used bits are set to 1674 zero and MUST be ignored when received. 1676 The ZRTP Messages are defined in Figure 3 to Figure 17 and are of 1677 variable length. 1679 The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as 1680 defined in RFC 3309 [RFC3309] to detect transmission errors. ZRTP 1681 packets are typically transported by UDP, which carries its own 1682 built-in 16-bit checksum for integrity, but ZRTP does not rely on it. 1683 This is because of the effect of an undetected transmission error in 1684 a ZRTP message. For example, an undetected error in the DH exchange 1685 could appear to be an active man-in-the-middle attack. The 1686 psychological effects of a false announcement of this by ZRTP clients 1687 can not be overstated. The probability of such a false alarm hinges 1688 on a mere 16-bit checksum that usually protects UDP packets, so more 1689 error detection is needed. For these reasons, this belt-and- 1690 suspenders approach is used to minimize the chance of a transmission 1691 error affecting the ZRTP key agreement. 1693 The CRC is calculated across the entire ZRTP packet shown in 1694 Figure 2, including the ZRTP Header and the ZRTP Message, but not 1695 including the CRC field. If a ZRTP message fails the CRC check, it 1696 is silently discarded. 1698 5.1. ZRTP Message Formats 1700 ZRTP messages are designed to simplify endpoint parsing requirements 1701 and to reduce the opportunities for buffer overflow attacks (a good 1702 goal of any security extension should be to not introduce new attack 1703 vectors). 1705 ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets 1706 (1 word) blocks are used to encode Hash Type, Cipher Type, and Key 1707 Agreement Type, and Authentication Tag. The values in the blocks are 1708 ASCII strings which are extended with spaces (0x20) to make them the 1709 desired length. Currently defined block values are listed in Tables 1710 1-6 below. 1712 Additional block values may be defined and used. 1714 ZRTP uses this ASCII encoding to simplify debugging and make it 1715 "Wireshark (Ethereal) friendly". 1717 5.1.1. Message Type Block 1719 Currently 14 Message Type Blocks are defined - they represent the set 1720 of ZRTP message primitives. ZRTP endpoints MUST support the Hello, 1721 HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, 1722 SASrelay, RelayACK, Error and ErrorACK message types. ZRTP endpoints 1723 MAY support the GoClear and ClearACK messages. Additional messages 1724 may be defined in extensions to ZRTP. 1726 Message Type Block | Meaning 1727 --------------------------------------------------- 1728 "Hello " | Hello Message 1729 --------------------------------------------------- 1730 "HelloACK" | HelloACK Message 1731 --------------------------------------------------- 1732 "Commit " | Commit Message 1733 --------------------------------------------------- 1734 "DHPart1 " | DHPart1 Message 1735 --------------------------------------------------- 1736 "DHPart2 " | DHPart2 Message 1737 --------------------------------------------------- 1738 "Confirm1" | Confirm1 Message 1739 --------------------------------------------------- 1740 "Confirm2" | Confirm2 Message 1741 --------------------------------------------------- 1742 "Conf2ACK" | Conf2ACK Message 1743 --------------------------------------------------- 1744 "Error " | Error Message 1745 --------------------------------------------------- 1746 "ErrorACK" | ErrorACK Message 1747 --------------------------------------------------- 1748 "GoClear " | GoClear Message 1749 --------------------------------------------------- 1750 "ClearACK" | ClearACK Message 1751 --------------------------------------------------- 1752 "SASrelay" | SASrelay Message 1753 --------------------------------------------------- 1754 "RelayACK" | RelayACK Message 1755 --------------------------------------------------- 1757 Table 1. Message Type Block Values 1759 5.1.2. Hash Type Block 1761 Only one Hash Type is currently defined, SHA-256 [FIPS-180-2], and 1762 all ZRTP endpoints MUST support this hash. Additional Hash Types can 1763 be registered and used, such as the NIST SHA-3 hash [SHA-3] when it 1764 becomes available. Note that the Hash Type refers to the hash 1765 algorithm that will be used throughout the ZRTP key exchange, not the 1766 hash algorithm to be used in the SRTP Authentication Tag. 1768 ZRTP makes use of HMAC message authentication codes based on the 1769 negotiated Hash Type. The HMAC function is defined in [FIPS-198-1]. 1770 Test vectors for HMAC-SHA-256 may be found in [RFC4231]. The HMAC 1771 function based on the negotiated Hash Type is also used in the ZRTP 1772 key derivation function (Section 4.5.1). 1774 Hash Type Block | Meaning 1775 --------------------------------------------------- 1776 "S256" | SHA-256 Hash defined in FIPS 180-2 1777 --------------------------------------------------- 1779 Table 2. Hash Type Block Values 1781 All hashes and HMACs used throughout the ZRTP protocol will use the 1782 negotiated Hash Type, except for the special cases noted in 1783 Section 5.1.2.1. 1785 5.1.2.1. Implicit Hash and HMAC algorithm 1787 While most of the HMACs used in ZRTP are defined by the negotiated 1788 Hash Type (Section 5.1.2), some hashes and HMACs must be precomputed 1789 prior to negotiations, and thus cannot have their algorithms 1790 negotiated during the ZRTP exchange. They are implicitly 1791 predetermined to use SHA-256 [FIPS-180-2] and HMAC-SHA-256. 1793 These are the hashes and HMACs that MUST use the Implicit hash and 1794 HMAC algorithm: 1796 The hash chain H0-H3 defined in Section 9. 1797 The HMACs that are keyed by this hash chain, as defined in 1798 Section 8.1.1. 1799 The Hello Hash in the a=zrtp-hash attribute defined in 1800 Section 8.1. 1802 ZRTP defines a method for negotiating different ZRTP protocol 1803 versions (Section 4.1.1). SHA-256 is the Implicit Hash for ZRTP 1804 protocol version 1.00. Future ZRTP protocol versions may, if 1805 appropriate, use another hash algorithm as the Implicit Hash, such as 1806 the NIST SHA-3 hash [SHA-3] when it becomes available. For example, 1807 a future SIP packet may list two a=zrtp-hash SDP attributes, one 1808 based on SHA-256 for ZRTP version 1.00, and another based on SHA-3 1809 for ZRTP version 2.00. 1811 5.1.3. Cipher Type Block 1813 All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- 1814 256 (AES3) or other Cipher Types. The choice of the AES key length 1815 is coupled to the Key Agreement type, as explained in Section 5.1.5. 1817 The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- 1818 256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. 1820 Cipher Type Block | Meaning 1821 --------------------------------------------------- 1822 "AES1" | AES-CM with 128 bit keys 1823 | as defined in RFC 3711 1824 --------------------------------------------------- 1825 "AES3" | AES-CM with 256 bit keys 1826 | 1827 --------------------------------------------------- 1829 Table 3. Cipher Type Block Values 1831 5.1.4. Auth Tag Block 1833 All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and 1834 80 bit length tags as defined in [RFC3711]. 1836 Auth Tag Block | Meaning 1837 --------------------------------------------------- 1838 "HS32" | HMAC-SHA1 32 bit authentication 1839 | tag as defined in RFC 3711 1840 --------------------------------------------------- 1841 "HS80" | HMAC-SHA1 80 bit authentication 1842 | tag as defined in RFC 3711 1843 --------------------------------------------------- 1845 Table 4. Auth Tag Values 1847 5.1.5. Key Agreement Type Block 1849 All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and 1850 MAY support EC25, EC38, EC52, and DH2k. 1852 If a ZRTP endpoint supports multiple concurrent media streams, such 1853 as audio and video, it MUST support Multistream (Section 4.4.2) mode. 1854 Also, if a ZRTP endpoint supports the GoClear message 1855 (Section 4.7.2), it SHOULD support Multistream, to be used if the two 1856 parties choose to return to the secure state after going Clear (as 1857 explained in Section 4.7.2.1). 1859 For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH 1860 parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the 1861 3072-bit MODP group. DH2k uses the 2048-bit MODP group. The DH 1862 generator g is 2. The random Diffie-Hellman secret exponent SHOULD 1863 be twice as long as the AES key length. If AES-128 is used, the DH 1864 secret value SHOULD be 256 bits long. If AES-256 is used, the secret 1865 value SHOULD be 512 bits long. 1867 If Elliptic Curve DH is used, the ECDH algorithm and key generation 1868 is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA 1869 Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by 1870 FIPS 186-3 [FIPS-186-3], and can also be found in RFC 4753 [RFC4753], 1871 sections 3.1 through 3.3. The validation procedures are from NIST SP 1872 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC Partial 1873 Validation. Both the X and Y coordinates of the point on the curve 1874 are sent, in the first and second half of the ECDH public value, 1875 respectively. 1877 The choice of AES key length is coupled to the choice of key 1878 agreement type. If either EC38 or EC52 is chosen as the key 1879 agreement, AES-256 (AES3) SHOULD be used. If DH3K or EC25 is chosen, 1880 either AES-128 (AES1) or AES-256 (AES3) MAY be used. 1882 DH2k is intended only for low power applications, and may be used 1883 with AES-128. DH2k is not recommended for high security 1884 applications. Its security can be augmented by implementing the key 1885 continuity features (Section 15.1). 1887 ECDH-521 is not recommended for low power environments, due to 1888 inconvenient computational delays. Note that ECDH-521 is not part of 1889 NSA Suite B. 1891 ZRTP also defines two non-DH modes, Multistream and Preshared, in 1892 which the SRTP key is derived from a shared secret and some nonce 1893 material. 1895 Table 5 lists the pv length in words and DHPart1 and DHPart2 message 1896 length in words for each Key Agreement Type Block. 1898 Key Agreement | pv | message | Meaning 1899 Type Block | words | words | 1900 --------------------------------------------------- 1901 "DH3k" | 96 | 117 | DH mode with p=3072 bit prime 1902 | | | as defined in RFC 3526 1903 --------------------------------------------------- 1904 "Prsh" | - | - | Preshared Non-DH mode 1905 | | | 1906 --------------------------------------------------- 1907 "Mult" | - | - | Multistream Non-DH mode 1908 | | | 1909 --------------------------------------------------- 1910 "EC25" | 16 | 37 | Elliptic Curve DH, P-256 1911 | | | per RFC 4753, section 3.1 1912 --------------------------------------------------- 1913 "EC38" | 24 | 45 | Elliptic Curve DH, P-384 1914 | | | per RFC 4753, section 3.2 1915 --------------------------------------------------- 1916 "EC52" | 33 | 54 | Elliptic Curve DH, P-521 1917 | | | per RFC 4753, section 3.3 1918 --------------------------------------------------- 1919 "DH2k" | 64 | 85 | DH mode with p=2048 bit prime 1920 | | | as defined in RFC 3526 1921 --------------------------------------------------- 1923 Table 5. Key Agreement Type Block Values 1925 5.1.6. SAS Type Block 1927 The SAS Type determines how the SAS is rendered to the user so that 1928 the user may verbally compare it with his partner over the voice 1929 channel. This allows detection of a man-in-the-middle (MiTM) attack. 1931 All ZRTP endpoints MUST support the base32 and MAY support the 1932 base256 rendering schemes for the Short Authentication String, and 1933 other SAS rendering schemes. The ZRTP SAS rendering schemes are 1934 described in Section 7. 1936 SAS Type Block | Meaning 1937 --------------------------------------------------- 1938 "B32 " | Short Authentication String using 1939 | base32 encoding 1940 --------------------------------------------------- 1941 "B256" | Short Authentication String using 1942 | base256 encoding (PGP Word List) 1943 --------------------------------------------------- 1945 Table 6. SAS Type Block Values 1947 5.1.7. Signature Type Block 1949 The signature type block is a 4 octet (1 word) block used to 1950 represent the signature algorithm discussed in Section 7.2. 1951 Suggested signature algorithms and key lengths are a future subject 1952 of standardization. 1954 5.2. Hello message 1956 The Hello message has the format shown in Figure 3. The Hello ZRTP 1957 message begins with the preamble value 0x505a then a 16 bit length in 1958 32 bit words. This length includes only the ZRTP message (including 1959 the preamble and the length) but not the ZRTP header or CRC. 1961 Next is the Message Type Block and a 4 character string containing 1962 the version (ver) of the ZRTP protocol which is "1.00" for this 1963 specification. Next is the Client Identifier string (cid) which is 4 1964 words long and identifies the vendor and release of the ZRTP 1965 software. The 256-bit hash image H3 is defined in Section 9. The 1966 next parameter is the ZID, the 96 bit long unique identifier for the 1967 ZRTP endpoint. 1969 The next four bits contains flag bits. The MiTM flag (M) is a 1970 Boolean that is set to true if and only if this Hello message is sent 1971 from a device, usually a PBX, that has the capability to send an 1972 SASrelay message (Section 5.13). The Passive flag (P) is a Boolean 1973 normally set to False. A ZRTP endpoint which is configured to never 1974 initiate secure sessions is regarded as passive, and would set the P 1975 bit to True. The next 8 bits are unused and SHOULD be set to zero 1976 when sent and MUST be ignored on receipt. 1978 Next is a list of supported Hash algorithms, Cipher algorithms, SRTP 1979 Auth Tag types, Key Agreement types, and SAS types. The number of 1980 listed algorithms are listed for each type: hc=hash count, cc=cipher 1981 count, ac=auth tag count, kc=key agreement count, and sc=sas count. 1982 The values for these algorithms are defined in Tables 2, 3, 4, 5, and 1983 6. A count of zero means that only the mandatory to implement 1984 algorithms are supported. Mandatory algorithms MAY be included in 1985 the list. The order of the list indicates the preferences of the 1986 endpoint. If a mandatory algorithm is not included in the list, it 1987 is added to the end of the list for preference. 1989 Note: Implementers are encouraged to keep these algorithm lists 1990 small - the list does not need to include every cipher and hash 1991 supported, just the ones the endpoint would prefer to use for this 1992 ZRTP exchange. 1994 The 64-bit HMAC at the end of the message is computed across the 1995 whole message, not including the HMAC. The HMAC key is the sender's 1996 H2 (defined in Section 9), and thus the HMAC cannot be checked by the 1997 receiving party until the sender's H2 value is known to the receiving 1998 party later in the protocol. 2000 0 1 2 3 2001 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 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Message Type Block="Hello " (2 words) | 2006 | | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | version="1.00" (1 word) | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | | 2011 | Client Identifier (4 words) | 2012 | | 2013 | | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 | | 2016 | Hash image H3 (8 words) | 2017 | . . . | 2018 | | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | | 2021 | ZID (3 words) | 2022 | | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 |0|0|M|P| unused (zeros)| hc | cc | ac | kc | sc | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | hash algorthms (0 to 7 values) | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | cipher algorthms (0 to 7 values) | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | auth tag types (0 to 7 values) | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | key agreement types (0 to 7 values) | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | SAS types (0 to 7 values) | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | HMAC (2 words) | 2037 | | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 Figure 3: Hello message format 2042 5.3. HelloACK message 2044 The HelloACK message is used to stop retransmissions of a Hello 2045 message. A HelloACK is sent regardless if the version number in the 2046 Hello is supported or the algorithm list supported. The receipt of a 2047 HelloACK stops retransmission of the Hello message. The format is 2048 shown in the Figure below. Note that a Commit message can be sent in 2049 place of a HelloACK by an Initiator. 2051 0 1 2 3 2052 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 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | Message Type Block="HelloACK" (2 words) | 2057 | | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 Figure 4: HelloACK message format 2062 5.4. Commit message 2064 The Commit message is sent to initiate the key agreement process 2065 after both sides have received a Hello message, which means it can 2066 only be sent after receiving both a Hello message and a HelloACK 2067 message. There are three subtypes of Commit messages, whose formats 2068 are shown in Figure 5, Figure 6, and Figure 7. 2070 The Commit message contains the Message Type Block, then the 256-bit 2071 hash image H2 which is defined in Section 9. The next parameter is 2072 the initiator's ZID, the 96 bit long unique identifier for the ZRTP 2073 endpoint. 2075 Next is a list of algorithms selected by the initiator (hash, cipher, 2076 auth tag type, key agreement, sas type). For a DH Commit, the hash 2077 value hvi is a hash of the DHPart2 of the Initiator and the 2078 Responder's Hello message, as explained in Section 4.4.1.1. 2080 The 64-bit HMAC at the end of the message is computed across the 2081 whole message, not including the HMAC. The HMAC key is the sender's 2082 H1 (defined in Section 9), and thus the HMAC cannot be checked by the 2083 receiving party until the sender's H1 value is known to the receiving 2084 party later in the protocol. 2086 0 1 2 3 2087 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 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2091 | Message Type Block="Commit " (2 words) | 2092 | | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | | 2095 | Hash image H2 (8 words) | 2096 | . . . | 2097 | | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | | 2100 | ZID (3 words) | 2101 | | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | hash algorihm | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | cipher algorihm | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | auth tag type | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | key agreement type | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | SAS type | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | | 2114 | hvi (8 words) | 2115 | . . . | 2116 | | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | HMAC (2 words) | 2119 | | 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 Figure 5: DH Commit message format 2124 0 1 2 3 2125 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 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Message Type Block="Commit " (2 words) | 2130 | | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | | 2133 | Hash image H2 (8 words) | 2134 | . . . | 2135 | | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | | 2138 | ZID (3 words) | 2139 | | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | hash algorihm | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | cipher algorihm | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | auth tag type | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | key agreement type = "Mult" | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | SAS type | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | | 2152 | nonce (4 words) | 2153 | . . . | 2154 | | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | HMAC (2 words) | 2157 | | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 Figure 6: Multistream Commit message format 2162 0 1 2 3 2163 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 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Message Type Block="Commit " (2 words) | 2168 | | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | | 2171 | Hash image H2 (8 words) | 2172 | . . . | 2173 | | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | | 2176 | ZID (3 words) | 2177 | | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | hash algorihm | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | cipher algorihm | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | auth tag type | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | key agreement type = "Prsh" | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | SAS type | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | | 2190 | nonce (4 words) | 2191 | . . . | 2192 | | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | keyID (2 words) | 2195 | | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | HMAC (2 words) | 2198 | | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 Figure 7: Preshared Commit message format 2203 5.5. DHPart1 message 2205 The DHPart1 message begins the DH exchange. The format is shown in 2206 Figure 8 below. The DHPart1 message is sent by the Responder if a 2207 valid Commit message is received from the Initiator. The length of 2208 the pvr value and the length of the DHPart1 message depends on the 2209 Key Agreement Type chosen. This information is contained in Table 5. 2211 Note that for both Multistream and Preshared modes, no DHPart1 or 2212 DHPart2 message will be sent. 2214 The 256-bit hash image H1 is defined in Section 9. 2216 The next four parameters are HMACs of potential shared secrets used 2217 in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are 2218 the HMACs of the responder's two retained shared secrets, truncated 2219 to 64 bits. Next is auxsecretIDr, the HMAC of the responder's 2220 auxsecret (defined in Section 4.3), truncated to 64 bits. The last 2221 parameter is the HMAC of the trusted MiTM PBX shared secret 2222 pbxsecret, defined in Section 7.3.1. The Message format for the 2223 DHPart1 message is shown in Figure 8. 2225 The 64-bit HMAC at the end of the message is computed across the 2226 whole message, not including the HMAC. The HMAC key is the sender's 2227 H0 (defined in Section 9), and thus the HMAC cannot be checked by the 2228 receiving party until the sender's H0 value is known to the receiving 2229 party later in the protocol. 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Message Type Block="DHPart1 " (2 words) | 2237 | | 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 | | 2240 | Hash image H1 (8 words) | 2241 | . . . | 2242 | | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | rs1IDr (2 words) | 2245 | | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | rs2IDr (2 words) | 2248 | | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | auxsecretIDr (2 words) | 2251 | | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | pbxsecretIDr (2 words) | 2254 | | 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 | | 2257 | pvr (length depends on KA Type) | 2258 | . . . | 2259 | | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | HMAC (2 words) | 2262 | | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Figure 8: DHPart1 message format 2267 5.6. DHPart2 message 2269 The DHPart2 message completes the DH exchange. A DHPart2 message is 2270 sent by the Initiator if a valid DHPart1 message is received from the 2271 Responder. The length of the pvr value and the length of the DHPart2 2272 message depends on the Key Agreement Type chosen. This information 2273 is contained in Table 5. Note that for both Multistream and 2274 Preshared modes, no DHPart1 or DHPart2 message will be sent. 2276 The 256-bit hash image H1 is defined in Section 9. 2278 The next four parameters are HMACs of potential shared secrets used 2279 in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are 2280 the HMACs of the initiator's two retained shared secrets, truncated 2281 to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's 2282 auxsecret (defined in Section 4.3), truncated to 64 bits. The last 2283 parameter is the HMAC of the trusted MiTM PBX shared secret 2284 pbxsecret, defined in Section 7.3.1. The message format for the 2285 DHPart2 message is shown in Figure 9. 2287 The 64-bit HMAC at the end of the message is computed across the 2288 whole message, not including the HMAC. The HMAC key is the sender's 2289 H0 (defined in Section 9), and thus the HMAC cannot be checked by the 2290 receiving party until the sender's H0 value is known to the receiving 2291 party later in the protocol. 2293 0 1 2 3 2294 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 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Message Type Block="DHPart2 " (2 words) | 2299 | | 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | | 2302 | Hash image H1 (8 words) | 2303 | . . . | 2304 | | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | rs1IDi (2 words) | 2307 | | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | rs2IDi (2 words) | 2310 | | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | auxsecretIDi (2 words) | 2313 | | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | pbxsecretIDi (2 words) | 2316 | | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | | 2319 | pvi (length depends on KA Type) | 2320 | . . . | 2321 | | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | HMAC (2 words) | 2324 | | 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 Figure 9: DHPart2 message format 2328 5.7. Confirm1 and Confirm2 messages 2330 The Confirm1 message is sent by the Responder in response to a valid 2331 DHPart2 message after the SRTP session key and parameters have been 2332 negotiated. The Confirm2 message is sent by the Initiator in 2333 response to a Confirm1 message. The format is shown in Figure 10 2334 below. The message contains the Message Type Block "Confirm1" or 2335 "Confirm2". Next is the HMAC, a keyed hash over encrypted part of 2336 the message (shown enclosed by "===" in Figure 10). This HMAC is 2337 keyed and computed according to Section 4.6. The next 16 octets 2338 contain the CFB Initialization Vector. The rest of the message is 2339 encrypted using CFB and protected by the HMAC. 2341 The first field inside the encrypted region is the hash pre-image H0, 2342 which is defined in detail in Section 9. 2344 The next 15 bits are not used and SHOULD be set to zero when sent and 2345 MUST be ignored when received in Confirm1 or Confirm2 messages. 2347 The next 9 bits contain the signature length. If no SAS signature 2348 (described in Section 7.2) is present, all bits are set to zero. The 2349 signature length is in words and includes the signature type block. 2350 If the calculated signature octet count is not a multiple of 4, zeros 2351 are added to pad it out to a word boundary. If no signature block is 2352 present, the overall length of the Confirm1 or Confirm2 Message will 2353 be set to 19 words. 2355 The next 8 bits are used for flags. Undefined flags are set to zero 2356 and ignored. Four flags are currently defined. The PBX Enrollment 2357 flag (E) is a Boolean bit defined in Section 7.3.1. The SAS Verified 2358 flag (V) is a Boolean bit defined in Section 7.1. The Allow Clear 2359 flag (A) is a Boolean bit defined in Section 4.7.2. The Disclosure 2360 Flag (D) is a Boolean bit defined in Section 11. The cache 2361 expiration interval is defined in Section 4.9. 2363 If the signature length (in words) is non-zero, a signature type 2364 block will be present along with a signature block. Next is the 2365 signature block. The signature block includes the key used to 2366 generate the signature (Section 7.2). 2368 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2369 full cipher block, and the final block is truncated to match the 2370 exact length of the encrypted data. The CFB Initialization Vector is 2371 a 128 bit random nonce. The block cipher algorithm and the key size 2372 is the same as what was negotiated for the media encryption. CFB is 2373 used to encrypt the part of the Confirm1 message beginning after the 2374 CFB IV to the end of the message (the encrypted region is enclosed by 2375 "======" in Figure 10). 2377 The responder uses the zrtpkeyr to encrypt the Confirm1 message. The 2378 initiator uses the zrtpkeyi to encrypt the Confirm2 message. 2380 0 1 2 3 2381 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 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Message Type Block="Confirm1" or "Confirm2" (2 words) | 2386 | | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | HMAC (2 words) | 2389 | | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 | | 2392 | CFB Initialization Vector (4 words) | 2393 | | 2394 | | 2395 +===============================================================+ 2396 | | 2397 | Hash pre-image H0 (8 words) | 2398 | . . . | 2399 | | 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D| 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | cache expiration interval (1 word) | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | optional signature type block (1 word if present) | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | | 2408 | optional signature block (variable length) | 2409 | . . . | 2410 | | 2411 | | 2412 +===============================================================+ 2414 Figure 10: Confirm1 and Confirm2 message format 2416 5.8. Conf2ACK message 2418 The Conf2ACK message is sent by the Responder in response to a valid 2419 Confirm2 message. The message format for the Conf2ACK is shown in 2420 the Figure below. The receipt of a Conf2ACK stops retransmission of 2421 the Confirm2 message. Note that the first SRTP media (with a valid 2422 SRTP auth tag) from the responder also stops retransmission of the 2423 Confirm2 message. 2425 0 1 2 3 2426 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 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Message Type Block="Conf2ACK" (2 words) | 2431 | | 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 Figure 11: Conf2ACK message format 2436 5.9. Error message 2438 The Error message is sent to terminate an in-process ZRTP key 2439 agreement exchange due to an error. The format is shown in the 2440 Figure below. The use of the Error message is described in 2441 Section 4.7.1. 2443 0 1 2 3 2444 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 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | Message Type Block="Error " (2 words) | 2449 | | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Integer Error Code (1 word) | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 Figure 12: Error message format 2456 Defined hexadecimal values for the Error Code are listed in Table 7. 2458 Error Code | Meaning 2459 ----------------------------------------------------------- 2460 0x10 | Malformed packet (CRC OK, but wrong structure) 2461 ----------------------------------------------------------- 2462 0x20 | Critical software error 2463 ----------------------------------------------------------- 2464 0x30 | Unsupported ZRTP version 2465 ----------------------------------------------------------- 2466 0x40 | Hello components mismatch 2467 ----------------------------------------------------------- 2468 0x51 | Hash type not supported 2469 ----------------------------------------------------------- 2470 0x52 | Cipher type not supported 2471 ----------------------------------------------------------- 2472 0x53 | Public key exchange not supported 2473 ----------------------------------------------------------- 2474 0x54 | SRTP auth. tag not supported 2475 ----------------------------------------------------------- 2476 0x55 | SAS scheme not supported 2477 ----------------------------------------------------------- 2478 0x56 | No shared secret available, DH mode required 2479 ----------------------------------------------------------- 2480 0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1) 2481 ----------------------------------------------------------- 2482 0x62 | DH Error: hvi != hashed data 2483 ----------------------------------------------------------- 2484 0x63 | Received relayed SAS from untrusted MiTM 2485 ----------------------------------------------------------- 2486 0x70 | Auth. Error: Bad Confirm pkt HMAC 2487 ----------------------------------------------------------- 2488 0x80 | Nonce reuse 2489 ----------------------------------------------------------- 2490 0x90 | Equal ZIDs in Hello 2491 ----------------------------------------------------------- 2492 0xA0 | Service unavailable 2493 ----------------------------------------------------------- 2494 0x100 | GoClear packet received, but not allowed 2495 ----------------------------------------------------------- 2497 Table 7. ZRTP Error Codes 2499 5.10. ErrorACK message 2501 The ErrorACK message is sent in response to an Error message. The 2502 receipt of an ErrorACK stops retransmission of the Error message. 2503 The format is shown in the Figure below. 2505 0 1 2 3 2506 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 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | Message Type Block="ErrorACK" (2 words) | 2511 | | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 Figure 13: ErrorAck message format 2516 5.11. GoClear message 2518 Support for the GoClear message is OPTIONAL in the protocol, and it 2519 is sent to switch from SRTP to RTP. The format is shown in the 2520 Figure below. The clear_hmac is used to authenticate the GoClear 2521 message so that bogus GoClear messages introduced by an attacker can 2522 be detected and discarded. The use of GoClear is described in 2523 Section 4.7.2. 2525 0 1 2 3 2526 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 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Message Type Block="GoClear " (2 words) | 2531 | | 2532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2533 | clear_hmac (2 words) | 2534 | | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 Figure 14: GoClear message format 2539 5.12. ClearACK message 2541 Support for the ClearACK message is OPTIONAL in the protocol, and it 2542 is sent to acknowledge receipt of a GoClear. A ClearACK is only sent 2543 if the clear_hmac from the GoClear message is authenticated. 2544 Otherwise, no response is returned. The format is shown in the 2545 Figure below. 2547 0 1 2 3 2548 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 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | Message Type Block="ClearACK" (2 words) | 2553 | | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 Figure 15: ClearAck message format 2558 5.13. SASrelay message 2560 The SASrelay message is sent by a trusted Man in The Middle (MiTM), 2561 most often a PBX. It is not sent as a response to a packet, but is 2562 sent as a self-initiated packet by the trusted MiTM. It can only be 2563 sent after the rest of the ZRTP key negotiations have completed, 2564 after the Confirm packets and their ACKs. It can only be sent after 2565 the trusted MiTM has finished key negotiations with the other party, 2566 because it is the other party's SAS that is being relayed. It is 2567 sent with retry logic until a RelayACK message (Section 5.14) is 2568 received or the retry schedule has been exhausted. 2570 If a device, usually a PBX, sends an SASrelay message, it MUST have 2571 previously declared itself as a MiTM device by setting the MiTM (M) 2572 flag in the Hello message (Section 5.2). If the receiver of the 2573 SASrelay message did not previously receive a Hello message with the 2574 MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A 2575 RelayACK is still sent, but no Error message is sent. 2577 The SASrelay message format is shown in Figure 16 below. The message 2578 contains the Message Type Block "SASrelay". Next is the HMAC, a 2579 keyed hash over encrypted part of the message (shown enclosed by 2580 "===" in Figure 16). This HMAC is keyed the same way as the HMAC in 2581 the Confirm messages (see Section 4.6). The next 16 octets contain 2582 the CFB Initialization Vector. The rest of the message is encrypted 2583 using CFB and protected by the HMAC. 2585 The next 15 bits are not used and SHOULD be set to zero when sent and 2586 MUST be ignored when received in SASrelay messages. 2588 The next 9 bits contain the signature length. The trusted MiTM MAY 2589 compute a digital signature on the SAS hash, as described in 2590 Section 7.2, using a persistant signing key owned by the trusted 2591 MiTM. If no SAS signature is present, all bits are set to zero. The 2592 signature length is in words and includes the signature type block. 2593 If the calculated signature octet count is not a multiple of 4, zeros 2594 are added to pad it out to a word boundary. If no signature block is 2595 present, the overall length of the SASrelay Message will be set to 12 2596 words. 2598 The next 8 bits are used for flags. Undefined flags are set to zero 2599 and ignored. Three flags are currently defined. The Disclosure Flag 2600 (D) is a Boolean bit defined in Section 11. The Allow Clear flag (A) 2601 is a Boolean bit defined in Section 4.7.2. The SAS Verified flag (V) 2602 is a Boolean bit defined in Section 7.1. These flags are updated 2603 values to the same flags provided earlier in the Confirm packet, but 2604 they are updated to reflect the new flag information relayed by the 2605 PBX from the other party. 2607 The next 32 bit word contains the rendering scheme for the relayed 2608 sasvalue, which will be the same rendering scheme used by the other 2609 party on the other side of the trusted MiTM. Section 7.3 describes 2610 how the PBX determines whether the ZRTP client regards the PBX as a 2611 trusted MiTM. If the PBX determines that the ZRTP client trusts the 2612 PBX, the next 32 bit word contains the binary sasvalue relayed from 2613 the other party. If this SASrelay packet is being sent to a ZRTP 2614 client that does not trust this MiTM, the next 32 bit word will be 2615 ignored by the recipient and should be set to zero by the PBX. 2617 If the signature length (in words) is non-zero, a signature type 2618 block will be present along with a signature block. Next is the 2619 signature block. The signature block includes the key used to 2620 generate the signature (Section 7.2). 2622 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2623 full cipher block, and the final block is truncated to match the 2624 exact length of the encrypted data. The CFB Initialization Vector is 2625 a 128 bit random nonce. The block cipher algorithm and the key size 2626 is the same as what was negotiated for the media encryption. CFB is 2627 used to encrypt the part of the SASrelay message beginning after the 2628 CFB IV to the end of the message (the encrypted region is enclosed by 2629 "======" in Figure 16). 2631 Depending on whether the trusted MiTM had taken the role of the 2632 initiator or the responder during the ZRTP key negotiation, the 2633 SASrelay message is encrypted with zrtpkeyi or zrtpkeyr. 2635 0 1 2 3 2636 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 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 | Message Type Block="SASrelay" (2 words) | 2641 | | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | HMAC (2 words) | 2644 | | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2646 | | 2647 | CFB Initialization Vector (4 words) | 2648 | | 2649 | | 2650 +===============================================================+ 2651 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D| 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | rendering scheme of relayed sasvalue (1 word) | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | Trusted MiTM relayed sasvalue (1 word) | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | optional signature type block (1 word if present) | 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | | 2660 | optional signature block (variable length) | 2661 | . . . | 2662 | | 2663 | | 2664 +===============================================================+ 2666 Figure 16: SASrelay message format 2668 5.14. RelayACK message 2670 The RelayACK message is sent in response to a valid SASrelay message. 2671 The message format for the RelayACK is shown in the Figure below. 2672 The receipt of a RelayACK stops retransmission of the SASrelay 2673 message. 2675 0 1 2 3 2676 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 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | Message Type Block="RelayACK" (2 words) | 2681 | | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 Figure 17: RelayACK message format 2686 6. Retransmissions 2688 ZRTP uses two retransmission timers T1 and T2. T1 is used for 2689 retransmission of Hello messages, when the support of ZRTP by the 2690 other endpoint may not be known. T2 is used in retransmissions of 2691 all the other ZRTP messages. 2693 All message retransmissions MUST be identical to the initial message 2694 including nonces, public values, etc; otherwise, hashes of the 2695 message sequences may not agree. 2697 Practical experience has shown that RTP packet loss at the start of 2698 an RTP session can be extremely high. Since the entire ZRTP message 2699 exchange occurs during this period, the defined retransmission scheme 2700 is defined to be aggressive. Since ZRTP packets with the exception 2701 of the DHPart1 and DHPart2 messages are small, this should have 2702 minimal effect on overall bandwidth utilization of the media session. 2704 ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media 2705 session as determined by the offer/answer exchange in the signaling 2706 layer. 2708 Hello ZRTP messages are retransmitted at an interval that starts at 2709 T1 seconds and doubles after every retransmission, capping at 200ms. 2710 T1 has a recommended initial value of 50 ms. A Hello message is 2711 retransmitted 20 times before giving up, which means the entire retry 2712 schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 2713 + 18*200 ms). Retransmission of a Hello ends upon receipt of a 2714 HelloACK or Commit message. 2716 The post-Hello ZRTP messages are retransmitted only by the session 2717 initiator - that is, only Commit, DHPart2, and Confirm2 are 2718 retransmitted if the corresponding message from the responder, 2719 DHPart1, Confirm1, and Conf2ACK, are not received. Note that the 2720 Confirm2 message retransmission can also be stopped by receiving the 2721 first SRTP media (with a valid SRTP auth tag) from the responder. 2723 The GoClear, Error, and SASrelay messages may be initiated and 2724 retransmitted by either party, and responded to by the other party, 2725 regardless of which party is the overall session initiator. They are 2726 retransmitted if the corresponding response message ClearACK, 2727 ErrorACK, and RelayACK, are not received. 2729 Non-Hello ZRTP messages are retransmitted at an interval that starts 2730 at T2 seconds and doubles after every retransmission, capping at 2731 600ms. T2 has a recommended initial value of 150 ms. Each non-Hello 2732 message is retransmitted 10 times before giving up, which means the 2733 entire retry schedule is exhausted after 5.25 seconds (150 + 300 + 2734 8*600 ms). Only the initiator performs retransmissions. Each 2735 message has a response message that stops retransmissions, as shown 2736 below in Table 8. The higher values of T2 means that retransmissions 2737 will likely only occur with packet loss. 2739 These recommended retransmission intervals are designed for a typical 2740 broadband Internet connection. In some high latency communication 2741 channels, such as those provided by some mobile phone environments or 2742 geostationary satellites, the initial value for the T1 or T2 2743 retransmission timer should be increased to be no less than the round 2744 trip time provided by the communications channel. It should take 2745 into account the time required to transmit the entire message and the 2746 entire reply. 2748 Message Acknowledgement Message 2749 ------- ----------------------- 2750 Hello HelloACK or Commit 2751 Commit DHPart1 or Confirm1 2752 DHPart2 Confirm1 2753 Confirm2 Conf2ACK or SRTP media 2754 GoClear ClearACK 2755 Error ErrorACK 2756 SASrelay RelayACK 2758 Table 8. Retransmitted ZRTP Messages and Responses 2760 7. Short Authentication String 2762 This section will discuss the implementation of the Short 2763 Authentication String, or SAS in ZRTP. The SAS can be verbally 2764 verified by the human users reading the string aloud, or by 2765 validating an OPTIONAL digital signature (described in Section 7.2) 2766 exchanged in the Confirm1 or Confirm2 messages. 2768 The use of hash commitment in the DH exchange (Section 4.4.1.1) 2769 constrains the attacker to only one guess to generate the correct SAS 2770 in his attack, which means the SAS can be quite short. A 16-bit SAS, 2771 for example, provides the attacker only one chance out of 65536 of 2772 not being detected. 2774 The rendering of the SAS value to the user depends on the SAS Type 2775 agreed upon in the Commit message. For the SAS Type of base32, the 2776 leftmost 20 bits of the 32-bit sasvalue are rendered as a form of 2777 base32 encoding known as z-base-32 [z-base-32]. The purpose of 2778 z-base-32 is to represent arbitrary sequences of octets in a form 2779 that is as convenient as possible for human users to manipulate. As 2780 a result, the choice of characters is slightly different from base32 2781 as defined in RFC 3548. The leftmost 20 bits of the sasvalue results 2782 in four base32 characters which are rendered to both ZRTP endpoints. 2783 For the SAS Type of base256, the leftmost 16 bits of the 32-bit 2784 sasvalue are rendered using the PGP Wordlist [pgpwordlist] 2785 [Juola1][Juola2]. Other SAS Types may be defined to render the SAS 2786 value in other ways. 2788 The SAS SHOULD be rendered to the user for authentication. 2790 The SAS is not treated as a secret value, but it must be compared to 2791 see if it matches at both ends of the communications channel. The 2792 two users read it aloud to their partners to see if it matches. This 2793 allows detection of a man-in-the-middle (MiTM) attack. 2795 There is only one SAS value computed per call. That is the SAS value 2796 for the first media stream established, which computes the ZRTPSess 2797 key, using DH mode. The ZRTPSess key is used to compute the SAS, as 2798 well as the SRTP session keys for each additional media stream in 2799 Multistream mode. This SAS applies to all media streams for the same 2800 call. 2802 7.1. SAS Verified Flag 2804 The SAS Verified flag (V) is set based on the user indicating that 2805 SAS comparison has been successfully performed. The SAS Verified 2806 flag is exchanged securely in the Confirm1 and Confirm2 messages 2807 (Figure 10) of the next session. In other words, each party sends 2808 the SAS Verified flag from the previous session in the Confirm 2809 message of the current session. It is perfectly reasonable to have a 2810 ZRTP endpoint that never sets the SAS Verified flag, because it would 2811 require adding complexity to the user interface to allow the user to 2812 set it. The SAS Verified flag is not required to be set, but if it 2813 is available to the client software, it allows for the possibility 2814 that the client software could render to the user that the SAS verify 2815 procedure was carried out in a previous session. 2817 Regardless of whether there is a user interface element to allow the 2818 user to set the SAS Verified flag, it is worth caching a shared 2819 secret, because doing so reduces opportunities for an attacker in the 2820 next call. 2822 If at any time the users carry out the SAS comparison procedure, and 2823 it actually fails to match, then this means there is a very 2824 resourceful man-in-the-middle. If this is the first call, the MiTM 2825 was there on the first call, which is impressive enough. If it 2826 happens in a later call, it also means the MiTM must also know the 2827 cached shared secret, because you could not have carried out any 2828 voice traffic at all unless the session key was correctly computed 2829 and is also known to the attacker. This implies the MiTM must have 2830 been present in all the previous sessions, since the initial 2831 establishment of the first shared secret. This is indeed a 2832 resourceful attacker. It also means that if at any time he ceases 2833 his participation as a MiTM on one of your calls, the protocol will 2834 detect that the cached shared secret is no longer valid -- because it 2835 was really two different shared secrets all along, one of them 2836 between Alice and the attacker, and the other between the attacker 2837 and Bob. The continuity of the cached shared secrets make it possible 2838 for us to detect the MiTM when he inserts himself into the ongoing 2839 relationship, as well as when he leaves. Also, if the attacker tries 2840 to stay with a long lineage of calls, but fails to execute a DH MiTM 2841 attack for even one missed call, he is permanently excluded. He can 2842 no longer resynchronize with the chain of cached shared secrets. 2844 Some sort of user interface element (maybe a checkbox) is needed to 2845 allow the user to tell the software the SAS verify was successful, 2846 causing the software to set the SAS Verified flag (V), which 2847 (together with our cached shared secret) obviates the need to perform 2848 the SAS procedure in the next call. An additional user interface 2849 element can be provided to let the user tell the software he detected 2850 an actual SAS mismatch, which indicates a MiTM attack. The software 2851 can then take appropriate action, clearing the SAS Verified flag, and 2852 erase the cached shared secret from this session. It is up to the 2853 implementer to decide if this added user interface complexity is 2854 warranted. 2856 If the SAS matches, it means there is no MiTM, which also implies it 2857 is now safe to trust a cached shared secret for later calls. If 2858 inattentive users don't bother to check the SAS, it means we don't 2859 know whether there is or is not a MiTM, so even if we do establish a 2860 new cached shared secret, there is a risk that our potential attacker 2861 may have a subsequent opportunity to continue inserting himself in 2862 the call, until we finally get around to checking the SAS. If the 2863 SAS matches, it means no attacker was present for any previous 2864 session since we started propagating cached shared secrets, because 2865 this session and all the previous sessions were also authenticated 2866 with a continuous lineage of shared secrets. 2868 7.2. Signing the SAS 2870 In some applications, it may be hard to arrange for two human users 2871 to verbally compare the SAS. To handle these cases, ZRTP allows for 2872 an OPTIONAL signature feature, which allows the SAS to be checked 2873 without human participation. The SAS MAY be signed and the signature 2874 sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay 2875 (Figure 16) messages. The signature algorithm, length of the 2876 signature and the key used to create the signature are all sent along 2877 with the signature. The key types and signature algorithms are for 2878 future study. The signature is calculated over the entire SAS hash 2879 result (sashash) that was truncated down to derive the sasvalue. The 2880 signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay 2881 messages MAY be used to authenticate the ZRTP exchange. 2883 7.3. Relaying the SAS through a PBX 2885 ZRTP is designed to use end-to-end encryption. The two parties' 2886 verbal comparison of the short authentication string (SAS) depends on 2887 this assumption. But in some PBX environments, such as Asterisk, 2888 there are usage scenarios that have the PBX acting as a trusted man- 2889 in-the-middle (MiTM), which means there are two back-to-back ZRTP 2890 connections with separate session keys and separate SAS's. 2892 For example, imagine that Bob has a ZRTP-enabled VoIP phone that has 2893 been registered with his company's PBX, so that it is regarded as an 2894 extension of the PBX. Alice, whose phone is not associated with the 2895 PBX, might dial the PBX from the outside, and a ZRTP connection is 2896 negotiated between her phone and the PBX. She then selects Bob's 2897 extension from the company directory in the PBX. The PBX makes a 2898 call to Bob's phone (which might be offsite, many miles away from the 2899 PBX through the Internet) and a separate ZRTP connection is 2900 negotiated between the PBX and Bob's phone. The two ZRTP sessions 2901 have different session keys and different SAS's, which would render 2902 the SAS useless for verbal comparison between Alice and Bob. They 2903 might even mistakenly believe that a wiretapper is present because of 2904 the SAS mismatch, causing undue alarm. 2906 ZRTP has a mechanism for solving this problem by having the PBX relay 2907 the Alice/PBX SAS to Bob, sending it through to Bob in a special 2908 SASrelay packet as defined in Section 5.13, which is sent after the 2909 PBX/Bob ZRTP negotiation is complete, after the Confirm packets. 2910 Only the PBX, acting as a special trusted MiTM (trusted by the 2911 recipient of the SAS relay packet), will relay the SAS. The SASrelay 2912 packet protects the relayed SAS from tampering via an included HMAC, 2913 similar to how the Confirm packet is protected. Bob's ZRTP-enabled 2914 phone accepts the relayed SAS for rendering only because Bob's phone 2915 had previously been configured to trust the PBX. This special 2916 trusted relationship with the PBX can be established through a 2917 special security enrollment procedure. After that enrollment 2918 procedure, the PBX is treated by Bob as a special trusted MiTM. This 2919 results in Alice's SAS being rendered to Bob, so that Alice and Bob 2920 may verbally compare them and thus prevent a MiTM attack by any other 2921 untrusted MiTM. 2923 A real bad-guy MiTM cannot exploit this protocol feature to mount a 2924 MiTM attack and relay Alice's SAS to Bob, because Bob has not 2925 previously carried out a special registration ritual with the bad 2926 guy. The relayed SAS would not be rendered by Bob's phone, because 2927 it did not come from a trusted PBX. The recognition of the special 2928 trust relationship is achieved with the prior establishment of a 2929 special shared secret between Bob and his PBX, which is called 2930 pbxsecret (defined in Section 7.3.1), also known as the trusted MiTM 2931 key. 2933 The trusted MiTM key can be stored in a special cache at the time of 2934 the initial enrollment (which is carried out only once for Bob's 2935 phone), and Bob's phone associates this key with the ZID of the PBX, 2936 while the PBX associates it with the ZID of Bob's phone. After the 2937 enrollment has established and stored this trusted MiTM key, it can 2938 be detected during subsequent ZRTP call negotiations between the PBX 2939 and Bob's phone, because the PBX and the phone MUST pass the hash of 2940 the trusted MiTM key in the DH packet. It is then used as part of 2941 the key agreement to calculate s0. 2943 During a key agreement with two other ZRTP endpoints, the PBX may 2944 have a shared trusted MiTM key with both endpoints, only one 2945 endpoint, or neither endpoint. If the PBX has a shared trusted MiTM 2946 key with neither endpoint, the PBX SHOULD NOT relay the SAS. If the 2947 PBX has a shared trusted MiTM key with only one endpoint, the PBX 2948 SHOULD relay the SAS from one party the other by sending an SASrelay 2949 message to the endpoint that it shares a trusted MiTM key. If the 2950 PBX has a shared trusted MiTM key with both endpoints, the PBX SHOULD 2951 relay the SAS from one party the other by sending an SASrelay message 2952 to only one of the endpoints. 2954 Note: In the case of sharing trusted MiTM key with both endpoints, 2955 it does not matter which endpoint receives the relayed SAS as long 2956 as only one endpoint receives it. 2958 The PBX can determine whether it is trusted by the ZRTP user agent of 2959 the caller or callee. The presence of a shared trusted MiTM key in 2960 the key negotiation sequence indicates that the phone has been 2961 enrolled with this PBX and therefore trusts it to act as a trusted 2962 MiTM. The PBX SHOULD relay the SAS from the other party in this 2963 case. 2965 The relayed SAS fields contain the SAS rendering type and the binary 2966 32-bit sasvalue. The receiver absolutely MUST NOT render the relayed 2967 SAS if it does not come from a specially trusted ZRTP endpoint. The 2968 security of the ZRTP protocol depends on not rendering a relayed SAS 2969 from an untrusted MiTM, because it may be relayed by a MiTM attacker. 2970 See the SASrelay packet definition (Figure 16) for further details. 2972 To ensure that both Alice and Bob will use the same SAS rendering 2973 scheme after the keys are negotiated, the PBX also sends the SASrelay 2974 message to the unenrolled party (which does not regard this PBX as a 2975 trusted MiTM), conveying the SAS rendering scheme, but not the SAS 2976 value, which it sets to zero. The unenrolled party will ignore the 2977 relayed SAS field, but will use the specified SAS rendering scheme. 2979 The next section describes the initial enrollment procedure that 2980 establishes a special shared secret between the PBX and Bob's phone, 2981 a trusted MiTM key, so that the phone will learn to recognize the PBX 2982 as a trusted MiTM. 2984 7.3.1. PBX Enrollment and the PBX Enrollment Flag 2986 Both the PBX and the endpoint need to know when enrollment is taking 2987 place. One way of doing this is to setup an enrollment extension on 2988 the PBX which a newly configured endpoint would call and establish a 2989 ZRTP session. The PBX would then play audio media that offers the 2990 user an opportunity to configure his phone to trust this PBX as a 2991 trusted MiTM. The PBX calculates and stores the trusted MiTM shared 2992 secret in its cache and associates it with this phone, indexed by the 2993 phone's ZID. The trusted MiTM PBX shared secret is derived from 2994 ZRTPSess via the ZRTP key derivation function (Section 4.5.1) in this 2995 manner: 2997 pbxsecret = KDF(ZRTPSess, "Trusted MiTM key", negotiated hash 2998 length) 3000 The PBX signals the enrollment process by setting the PBX Enrollment 3001 flag (E) in the Confirm message (Figure 10). This flag is used to 3002 trigger the ZRTP endpoint's user interface to prompt the user if they 3003 want to trust this PBX and calculate and store the pbxsecret in the 3004 cache. If the user decides to respond by activating the appropriate 3005 user interface element (a menu item, checkbox, or button), his ZRTP 3006 user agent calculates pbxsecret using the same formula and saves it 3007 in a special cache entry associated with this PBX. 3009 If the user elects not to enroll, perhaps because he dialed a wrong 3010 number or does not yet feel comfortable with this PBX, he can simply 3011 hang up and not save the pbxsecret in his cache. The PBX will have 3012 it saved in the PBX cache, but that will do no harm. The SASrelay 3013 scheme does not depend on the PBX trusting the phone. It only 3014 depends on the phone trusting the PBX. It is the phone (the user) 3015 who is at risk if the PBX abuses its MiTM privileges. 3017 An endpoint MUST NOT store the pbxsecret in the cache without 3018 explicit user authorization. 3020 After this enrollment process, the PBX and the ZRTP-enabled phone 3021 both share a secret that enables the phone to recognize the PBX as a 3022 trusted MiTM in future calls. This means that when a future call 3023 from an outside ZRTP-enabled caller is relayed through the PBX to 3024 this phone, the phone will render a relayed SAS from the PBX. If the 3025 SASrelay packet comes from a MiTM which does not know the pbxsecret, 3026 the phone treats it as a "bad guy" MiTM, and refuses to render the 3027 relayed SAS. Regardless of which party initiates any future phone 3028 calls through the PBX, the enrolled phone or the outside phone, the 3029 PBX will relay the SAS to the enrolled phone. 3031 There are other ways that ZRTP user agents can be configured to trust 3032 a PBX. Perhaps the pbxsecret can be configured into the phone by 3033 some automated provisioning process in large IT environments. This 3034 specification does not require that products be configured solely by 3035 this enrollment process. Any process that results in a pbxsecret to 3036 be computed and shared between the PBX and the phone will suffice. 3037 This is one such method that has been shown to work. 3039 8. Signaling Interactions 3041 This section discusses how ZRTP, SIP, and SDP work together. 3043 Note that ZRTP may be implemented without coupling with the SIP 3044 signaling. For example, ZRTP can be implemented as a "bump in the 3045 wire" or as a "bump in the stack" in which RTP sent by the SIP UA is 3046 converted to ZRTP. In these cases, the SIP UA will have no knowledge 3047 of ZRTP. As a result, the signaling path discovery mechanisms 3048 introduced in this section should not be definitive - they are a 3049 hint. Despite the absence of an indication of ZRTP support in an 3050 offer or answer, a ZRTP endpoint SHOULD still send Hello messages. 3052 ZRTP endpoints which have control over the signaling path include a 3053 ZRTP SDP attributes in their SDP offers and answers. The ZRTP 3054 attribute, a=zrtp-hash is used to indicate support for ZRTP and to 3055 convey a hash of the Hello message. The hash is computed according 3056 to Section 8.1. 3058 Aside from the advantages described in Section 8.1, there are a 3059 number of potential uses for this attribute. It is useful when 3060 signaling elements would like to know when ZRTP may be utilized by 3061 endpoints. It is also useful if endpoints support multiple methods 3062 of SRTP key management. The ZRTP attribute can be used to ensure 3063 that these key management approaches work together instead of against 3064 each other. For example, if only one endpoint supports ZRTP but both 3065 support another method to key SRTP, then the other method will be 3066 used instead. When used in parallel, an SRTP secret carried in an 3067 a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a 3068 shared secret for the srtps computation defined in Section 8.2. The 3069 ZRTP attribute is also used to signal to an intermediary ZRTP device 3070 not to act as a ZRTP endpoint, as discussed in Section 10. 3072 The a=zrtp-hash attribute can only be included in the SDP at the 3073 media level since Hello messages sent in different media streams will 3074 have unique hashes. 3076 The ABNF for the ZRTP attribute is as follows: 3078 zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value 3080 zrtp-version = token 3082 zrtp-hash-value = 1*(HEXDIG) 3084 Example of the ZRTP attribute in an initial SDP offer or answer used 3085 at the session level: 3087 v=0 3088 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 3089 s= 3090 c=IN IP4 client.biloxi.example.com 3091 t=0 0 3092 m=audio 3456 RTP/AVP 97 33 3093 a=rtpmap:97 iLBC/8000 3094 a=rtpmap:33 no-op/8000 3095 a=zrtp-hash:1.00 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df 3097 8.1. Binding the media stream to the signaling layer via the Hello Hash 3099 It is desirable to tie the media stream to the signaling channel to 3100 prevent a third party from inserting false media packets. If the 3101 signaling layer contains information that ties it to the media 3102 stream, false media streams can be rejected. 3104 To accomplish this, a 256-bit hash (using the hash algorithm defined 3105 in Section 5.1.2.1) is computed across the entire ZRTP Hello message 3106 (as shown in Figure 3). This hash image is made available to the 3107 signaling layer, where it is transmitted as a hexadecimal value in 3108 the SIP channel using the SDP attribute, a=zrtp-hash defined in this 3109 specification. Each media stream (audio or video) will have a 3110 separate Hello packet, and thus will require a separate a=zrtp-hash 3111 in an SDP attribute. The recipient of the SIP/SDP message can then 3112 use this hash image to detect and reject false Hello packets in the 3113 media channel, as well as identify which media stream is associated 3114 with this SIP call. Each Hello packet hashes uniquely, because it 3115 contains the H3 field derived from a random nonce, defined in 3116 Section 9. 3118 The Hello Hash as an SDP attribute is an OPTIONAL feature, because 3119 some ZRTP endpoints do not have the ability to add SDP attributes to 3120 the signaling. For example, if ZRTP is implemented in a hardware 3121 bump-in-the-wire device, it might only have the ability to modify the 3122 media packets, not the SIP packets, especially if the SIP packets are 3123 integrity protected and thus cannot be modified on the wire. If the 3124 SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP 3125 user agent cannot check it, and thus will not be able to reject Hello 3126 messages based on this hash. 3128 After the Hello Hash is used to properly identify the ZRTP Hello 3129 message as belonging to this particular SIP call, the rest of the 3130 ZRTP message sequence is protected from false packet injection by 3131 other protection mechanisms. For example, the use of the total_hash 3132 in the shared secret calculation, and also the hash chaining 3133 mechanism defined in Section 9. 3135 An attacker who controls only the signaling layer, such as an 3136 uncooperative VoIP service provider, may be able to deny service by 3137 corrupting the hash of the Hello message in the SDP attribute, which 3138 would force ZRTP to reject perfectly good Hello messages. If there 3139 is reason to believe this is happening, the ZRTP endpoint MAY allow 3140 Hello messages to be accepted that do not match the hash image in the 3141 SDP attribute. 3143 Even in the absence of SIP integrity protection, the inclusion of the 3144 a=zrtp-hash SDP attribute, when coupled with the hash chaining 3145 mechanism defined in Section 9, meets the R-ASSOC requirement in the 3146 Media Security Requirements 3147 [I-D.ietf-sip-media-security-requirements], which requires: 3149 "...a mechanism for associating key management messages with both 3150 the signaling traffic that initiated the session and with 3151 protected media traffic. Allowing such an association also allows 3152 the SDP offerer to avoid performing CPU-consuming operations 3153 (e.g., Diffie-Hellman or public key operations) with attackers 3154 that have not seen the signaling messages." 3156 The a=zrtp-hash SDP attribute becomes especially useful if the SDP is 3157 integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474] 3158 or better still, Dan Wing's SIP Identity using Media Path 3159 [I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM 3160 attacks independent of ZRTP's SAS mechanism, as explained in 3161 Section 8.1.1 below. 3163 8.1.1. Integrity-protected signaling enables integrity-protected DH 3164 exchange 3166 If and only if the signaling path and the SDP is protected by some 3167 form of end-to-end integrity protection, such as one of the 3168 abovementioned mechanisms, so that it can guarantee delivery of the 3169 a=zrtp-hash attribute without any tampering by a third party, and if 3170 there is good reason to trust the signaling layer to protect the 3171 interests of the end user, it is possible to authenticate the key 3172 exchange and prevent a MiTM attack. This can be done without 3173 requiring the users to verbally compare the SAS, by using the hash 3174 chaining mechanism defined in Section 9 to provide a series of HMAC 3175 keys that protect the entire ZRTP key exchange. Thus, an end-to-end 3176 integrity-protected signaling layer automatically enables an 3177 integrity-protected Diffie-Hellman exchange in ZRTP, which in turn 3178 means immunity from a MiTM attack. Here's how it works. 3180 The integrity-protected SIP SDP contains a hash commitment to the 3181 entire Hello message. The Hello message contains H3, which provides 3182 a hash commitment for the rest of the hash chain H0-H2 (Section 9). 3183 The Hello message is protected by a 64-bit HMAC, keyed by H2. The 3184 Commit message is protected by a 64-bit HMAC keyed by H1. The 3185 DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by 3186 H0. The HMAC protecting the Confirm messages are computed by a 3187 different HMAC key derived from the resulting key agreement. Each 3188 message's HMAC is checked when the HMAC key is received in the next 3189 message. If a bad HMAC is discovered, it MUST be treated as a 3190 security exception indicating a MiTM attack, perhaps by logging or 3191 alerting the user, and MUST NOT be treated as a random error. Random 3192 errors are already discovered and quietly rejected by bad CRCs 3193 (Figure 2). 3195 The Hello message must be assembled before any hash algorithms are 3196 negotiated, so an implicit predetermined hash algorthm and HMAC 3197 algorthm (both defined in Section 5.1.2.1) must be used. All of the 3198 aforementioned HMACs keyed by the hashes in the aforementioned hash 3199 chain MUST be computed with the HMAC algorithm defined in 3200 Section 5.1.2.1, with the HMAC truncated to 64 bits. 3202 The Media Security Requirements 3203 [I-D.ietf-sip-media-security-requirements] R-EXISTING requirement can 3204 be fully met by leveraging a certificate-backed PKI in the signaling 3205 layer to integrity-protect the delivery of the a=zrtp-hash SDP 3206 attribute. This would thereby protect ZRTP against a MiTM attack, 3207 without requiring the user to check the SAS, without adding any 3208 explicit signatures or signature keys to the ZRTP key exchange, and 3209 without any extra public key operations or extra packets. 3211 Without an end-to-end integrity protection mechanism in the signaling 3212 layer to guarantee delivery of the a=zrtp-hash SDP attribute without 3213 modification by a third party, these HMACs alone will not prevent a 3214 MiTM attack. In that case, ZRTP's built-in SAS mechanism will still 3215 have to be used to authenticate the key exchange. At the time of 3216 this writing, very few deployed VoIP clients offer a fully 3217 implemented SIP stack that provides end-to-end integrity protection 3218 for the delivery of SDP attributes. Also, end-to-end signaling 3219 integrity becomes more problematic if E.164 numbers [RFC3824] are 3220 used in SIP. Thus, real-world implementations of ZRTP endpoints will 3221 continue to depend on SAS authentication for quite some time. Even 3222 after there is widespread availability of SIP user agents that offer 3223 integrity protected delivery of SDP attributes, many users will still 3224 be faced with the fact that the signaling path may be controlled by 3225 institutions that do not have the best interests of the end user in 3226 mind. In those cases, SAS authentication will remain the gold 3227 standard for the prudent user. 3229 Even without SIP integrity protection, the Media Security 3230 Requirements [I-D.ietf-sip-media-security-requirements] R-ACT-ACT 3231 requirement can be met by ZRTP's SAS mechanism. Although ZRTP may 3232 benefit from an integrity-protected SIP layer, it is fortunate that 3233 ZRTP's self-contained MiTM defenses do not actually require an 3234 integrity-protected SIP layer. ZRTP can bypass the delays and 3235 problems that SIP integrity faces, such as E.164 number usage, and 3236 the complexity of building and maintaining a PKI. 3238 In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend 3239 heavily on end-to-end integrity protection in the SIP layer. 3240 Further, DTLS-SRTP must bear the additional cost of a signature 3241 calculation of its own, in addition to the signature calculation the 3242 SIP layer uses to achieve its integrity protection. ZRTP needs no 3243 signature calculation of its own to leverage the signature 3244 calculation carried out in the SIP layer. 3246 8.2. Deriving the SRTP secret (srtps) from the signaling layer 3248 The shared secret calculations defined in Section 4.3 make use of the 3249 SRTP secret (srtps), if it is provided by the signaling layer. 3251 It is desirable for only one SRTP key negotiation protocol to be 3252 used, and that protocol should be ZRTP. But in the event the 3253 signaling layer negotiates its own SRTP master key and salt, using 3254 the SDES [RFC4568] or [RFC4567], it can be passed from the signaling 3255 to the ZRTP layer and mixed into ZRTP's own shared secret 3256 calculations, without compromising security by creating a dependency 3257 on the signaling for media encryption. 3259 ZRTP computes srtps from the SRTP master key and salt parameters 3260 provided by the signaling layer in this manner: 3262 srtps = hash(SRTP master key | SRTP master salt) 3264 It is expected that the srtps parameter will be rarely computed or 3265 used in typical ZRTP endpoints, because it is likely and desirable 3266 that ZRTP will be the sole means of negotiating SRTP keys, needing no 3267 help from SDES [RFC4568] or [RFC4567]. If srtps is computed, it will 3268 be stored in the auxiliary shared secret auxsecret, defined in 3269 Section 4.3, and used in Section 4.3.1 and Section 4.3.2. 3271 8.3. Codec Selection for Secure Media 3273 Codec selection is negotiated in the signaling layer. If the 3274 signaling layer determines that ZRTP is supported by both endpoints, 3275 this should provide guidance in codec selection to avoid variable 3276 bit-rate (VBR) codecs that leak information. 3278 When voice is compressed with a VBR codec, the packet lengths vary 3279 depending on the types of sounds being compressed. This leaks a lot 3280 of information about the content even if the packets are encrypted, 3281 regardless of what encryption protocol is used [Wright1]. It is 3282 RECOMMENDED that VBR codecs be avoided in encrypted calls. It is not 3283 a problem if the codec adapts the bit rate to the available channel 3284 bandwidth. The vulnerable codecs are the ones that change their bit 3285 rate depending on the type of sound being compressed. 3287 It also appears that voice activity detection (VAD) leaks information 3288 about the content of the conversation, but to a lesser extent than 3289 VBR. This effect can be ameliorated by lengthening the VAD hangover 3290 time by about 1 to 2 seconds, if this is feasible in your 3291 application. This is a topic that requires further study. 3293 9. False ZRTP Packet Rejection 3295 An attacker who is not in the media path may attempt to inject false 3296 ZRTP protocol packets, possibly to effect a denial of service attack, 3297 or to inject his own media stream into the call. VoIP by its nature 3298 invites various forms of denial of service attacks and requires 3299 protocol features to reject such attacks. While bogus SRTP packets 3300 may be easily rejected via the SRTP auth tag field, that can only be 3301 applied after a key agreement is completed. During the ZRTP key 3302 negotiation phase, other false packet rejection mechanisms are 3303 needed. One such mechanism is the use of the total_hash in the final 3304 shared secret calculation, but that can only detect false packets 3305 after performing the computationally expensive Diffie-Hellman 3306 calculation. 3308 The VoIP developer community expects to see a lot of denial of 3309 service attacks, especially from attackers who are not in the media 3310 path. Such an attacker might inject false ZRTP packets to force a 3311 ZRTP endpoint to engage in an endless series of pointless and 3312 expensive DH calculations. To detect and reject false packets 3313 cheaply and rapidly as soon as they are received, ZRTP uses a hash 3314 chain, which is a series of successive hash images. Before each 3315 session, the following values are computed: 3317 H0 = 256-bit random nonce (different for each party) 3318 H1 = hash (H0) 3319 H2 = hash (H1) 3320 H3 = hash (H2) 3322 The hash chain MUST use the hash algorithm defined in 3323 Section 5.1.2.1. Each 256-bit hash image is the pre-image of the 3324 next, and the sequence of images is sent in reverse order in the ZRTP 3325 packet sequence. The hash image H3 is sent in the Hello packet, H2 3326 is sent in the Commit packet, H1 is sent in the DHPart1 or DHPart2 3327 packets, and H0 is sent in the Confirm1 or Confirm2 packets. The 3328 initial random H0 nonces that each party generates MUST be 3329 unpredictable to an attacker and unique within a ZRTP call, which 3330 thereby forces the derived hash images H1-H3 to also be unique and 3331 unpredictable. 3333 The recipient checks if the packet has the correct hash pre-image, by 3334 hashing it and comparing the result with the hash image for the 3335 preceding packet. Packets which contain an incorrect hash pre-image 3336 MUST NOT be used by the recipient, but MAY be processed as security 3337 exceptions, perhaps by logging or alerting the user. As long as 3338 these bogus packets are not used, and correct packets are still being 3339 received, the protocol SHOULD be allowed to run to completion, 3340 thereby rendering ineffective this denial of service attack. 3342 Because these hash images alone do not protect the rest of the 3343 contents of the packet they reside in, this scheme assumes the 3344 attacker cannot modify the packet contents from a legitimate party, 3345 which is a reasonable assumption for an attacker who is not in the 3346 media path. This covers an important range of denial-of-service 3347 attacks. For dealing with the remaining set of attacks that involve 3348 packet modification, other mechanisms are used, such as the 3349 total_hash in the final shared secret calculation, and the hash 3350 commitment in the Commit packet. 3352 False Hello packets may be detected and rejected by the mechanism 3353 defined in Section 8.1. This mechanism requires that each Hello 3354 packet be unique, and the inclusion of the H3 hash image meets that 3355 requirement. 3357 If and only if an integrity-protected signaling channel is available, 3358 this hash chaining scheme can be used to key HMACs to authenticate 3359 the entire ZRTP key exchange, and thereby prevent a MiTM attack, 3360 without relying on the users verbally comparing the SAS. See 3361 Section 8.1.1 for details. 3363 Some ZRTP user agents allow the user to manually switch to clear mode 3364 (via the GoClear packet) in the middle of a secure call, and then 3365 later initiate secure mode again. Many consumer client products will 3366 omit this feature, but those that allow it may return to secure mode 3367 again in the same media stream. Although the same chain of hash 3368 images will be re-used and thus rendered ineffective the second time, 3369 no real harm is done because the new SRTP session keys will be 3370 derived in part from a cached shared secret, which was safely 3371 protected from the MiTM in the previous DH exchange earlier in the 3372 same call. 3374 10. Intermediary ZRTP Devices 3376 This section discusses the operation of a ZRTP endpoint which is 3377 actually an intermediary. For example, consider a device which 3378 proxies both signaling and media between endpoints. There are three 3379 possible ways in which such a device could support ZRTP. 3381 An intermediary device can act transparently to the ZRTP protocol. 3382 To do this, a device MUST pass RTP header extensions and payloads (to 3383 allow the ZRTP Flag) and non-RTP protocols multiplexed on the same 3384 port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED 3385 behavior for intermediaries as ZRTP and SRTP are best when done end- 3386 to-end. 3388 An intermediary device could implement the ZRTP protocol and act as a 3389 ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary 3390 device. The intermediary could determine on a call-by-call basis 3391 whether the endpoint behind it supports ZRTP based on the presence or 3392 absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP 3393 endpoints, the intermediary device could act as the ZRTP endpoint 3394 using its own ZID and cache. This approach SHOULD only be used when 3395 there is some other security method protecting the confidentiality of 3396 the media between the intermediary and the inside endpoint, such as 3397 IPSec or physical security. 3399 The third mode, which is NOT RECOMMENDED, is for the intermediary 3400 device to attempt to back-to-back the ZRTP protocol. The only 3401 exception to this case is where the intermediary device is a trusted 3402 element providing services to one of the endpoints - e.g. a Private 3403 Branch Exchange or PBX. In this mode, the intermediary would attempt 3404 to act as a ZRTP endpoint towards both endpoints of the media 3405 session. This approach MUST NOT be used except as described in 3406 Section 7.3 as it will always result in a detected man-in-the-middle 3407 attack and will generate alarms on both endpoints and likely result 3408 in the immediate termination of the session. 3410 In cases where centralized media mixing is taking place, the SAS will 3411 not match when compared by the humans. However, this situation is 3412 known in the SIP signaling by the presence of the isfocus feature tag 3413 [RFC4579]. As a result, when the isfocus feature tag is present, the 3414 DH exchange can be authenticated by the mechanism defined in 3415 Section 8.1.1 or by validating signatures (Section 7.2) in the 3416 Confirm or SASrelay messages. For example, consider a audio 3417 conference call with three participants Alice, Bob, and Carol hosted 3418 on a conference bridge in Dallas. There will be three ZRTP encrypted 3419 media streams, one encrypted stream between each participant and 3420 Dallas. Each will have a different SAS. Each participant will be 3421 able to validate their SAS with the conference bridge by using 3422 signatures optionally present in the Confirm messages (described in 3423 Section 7.2). Or, if the signaling path has end-to-end integrity 3424 protection, each DH exchange will have automatic MiTM protection by 3425 using the mechanism in Section 8.1.1. 3427 SIP feature tags can also be used to detect if a session is 3428 established with an automaton such as an IVR, voicemail system, or 3429 speech recognition system. The display of SAS strings to users 3430 should be disabled in these cases. 3432 It is possible that an intermediary device acting as a ZRTP endpoint 3433 might still receive ZRTP Hello and other messages from the inside 3434 endpoint. This could occur if there is another inline ZRTP device 3435 which does not include the ZRTP SDP attribute flag. An intermediary 3436 acting as a ZRTP endpoint receiving ZRTP Hello and other messages 3437 from the inside endpoint MUST NOT pass these ZRTP messages. 3439 11. The ZRTP Disclosure flag 3441 There are no back doors defined in the ZRTP protocol specification. 3442 The designers of ZRTP would like to discourage back doors in ZRTP- 3443 enabled products. However, despite the lack of back doors in the 3444 actual ZRTP protocol, it must be recognized that a ZRTP implementer 3445 might still deliberately create a rogue ZRTP-enabled product that 3446 implements a back door outside the scope of the ZRTP protocol. For 3447 example, they could create a product that discloses the SRTP session 3448 key generated using ZRTP out-of-band to a third party. They may even 3449 have a legitimate business reason to do this for some customers. 3451 For example, some environments have a need to monitor or record 3452 calls, such as stock brokerage houses who want to discourage insider 3453 trading, or special high security environments with special needs to 3454 monitor their own phone calls. We've all experienced automated 3455 messages telling us that "This call may be monitored for quality 3456 assurance". A ZRTP endpoint in such an environment might 3457 unilaterally disclose the session key to someone monitoring the call. 3458 ZRTP-enabled products that perform such out-of-band disclosures of 3459 the session key can undermine public confidence in the ZRTP protocol, 3460 unless we do everything we can in the protocol to alert the other 3461 user that this is happening. 3463 If one of the parties is using a product that is designed to disclose 3464 their session key, ZRTP requires them to confess this fact to the 3465 other party through a protocol message to the other party's ZRTP 3466 client, which can properly alert that user, perhaps by rendering it 3467 in a graphical user interface. The disclosing party does this by 3468 sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as 3469 described in Section 5.7. 3471 Note that the intention here is to have the Disclosure flag identify 3472 products that are designed to disclose their session keys, not to 3473 identify which particular calls are compromised on a call-by-call 3474 basis. This is an important legal distinction, because most 3475 government sanctioned wiretap regulations require a VoIP service 3476 provider to not reveal which particular calls are wiretapped. But 3477 there is nothing illegal about revealing that a product is designed 3478 to be wiretap-friendly. The ZRTP protocol mandates that such a 3479 product "out" itself. 3481 You might be using a ZRTP-enabled product with no back doors, but if 3482 your own graphical user interface tells you the call is (mostly) 3483 secure, except that the other party is using a product that is 3484 designed in such a way that it may have disclosed the session key for 3485 monitoring purposes, you might ask him what brand of secure telephone 3486 he is using, and make a mental note not to purchase that brand 3487 yourself. If we create a protocol environment that requires such 3488 back-doored phones to confess their nature, word will spread quickly, 3489 and the "invisible hand" of the free market will act. The free 3490 market has effectively dealt with this in the past. 3492 Of course, a ZRTP implementer can lie about his product having a back 3493 door, but the ZRTP standard mandates that ZRTP-compliant products 3494 MUST adhere to the requirement that a back door be confessed by 3495 sending the Disclosure flag to the other party. 3497 There will be inevitable comparisons to Steve Bellovin's 2003 April 3498 fool's joke, when he submitted RFC 3514 [RFC3514] which defined the 3499 "Evil bit" in the IPV4 header, for packets with "evil intent". But 3500 we submit that a similar idea can actually have some merit for 3501 securing VoIP. Sure, one can always imagine that some implementer 3502 will not be fazed by the rules and will lie, but they would have lied 3503 anyway even without the Disclosure flag. There are good reasons to 3504 believe that it will improve the overall percentage of 3505 implementations that at least tell us if they put a back door in 3506 their products, and may even get some of them to decide not to put in 3507 a back door at all. From a civic hygiene perspective, we are better 3508 off with having the Disclosure flag in the protocol. 3510 If an endpoint stores or logs SRTP keys or information that can be 3511 used to reconstruct or recover SRTP keys after they are no longer in 3512 use (i.e. the session is active), or otherwise discloses or passes 3513 SRTP keys or information that can be used to reconstruct or recover 3514 SRTP keys to another application or device, the Disclosure flag D 3515 MUST be set in the Confirm1 or Confirm2 message. 3517 11.1. Guidelines on Proper Implementation of the Disclosure Flag 3519 Some implementers have asked for guidance on implementing the 3520 Disclosure Flag. Some people have incorrectly thought that a 3521 connection secured with ZRTP cannot be used in a call center, with 3522 voluntary voice recording, or even with a voicemail system. 3523 Similarly, some potential users of ZRTP have over considered the 3524 protection that ZRTP can give them. These guidelines clarify both 3525 concerns. 3527 The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. 3528 It does not govern the underlying RTP media stream, nor the actual 3529 media itself. Consequently, a PBX that uses ZRTP may provide 3530 conference calls, call monitoring, call recording, voicemail, or 3531 other PBX features and still say that it does not disclose the ZRTP 3532 key material. A video system may provide DVR features and still say 3533 that it does not disclose the ZRTP key material. The ZRTP Disclosure 3534 Flag, when not set, means only that the ZRTP cryptographic key 3535 material stays within the bounds of the ZRTP subsystem. 3537 If an application has a need to disclose the ZRTP cryptographic key 3538 material, the easiest way to comply with the protocol is to set the 3539 flag to the proper value. The next easiest way is to overestimate 3540 disclosure. For example, a call center that commonly records calls 3541 might choose to set the disclosure flag even though all recording is 3542 an analog recording of a call (and thus outside the ZRTP scope) 3543 because it sets an expectation with clients that their calls might be 3544 recorded. 3546 Note also that the ZRTP Disclosure Flag does not require an 3547 implementation to preclude hacking or malware. Malware that leaks 3548 ZRTP cryptographic key material does not create a liability for the 3549 implementor from non-compliance with the ZRTP specification. 3551 A user of ZRTP should note that ZRTP is not a panacea against 3552 unauthorized recording. ZRTP does not and cannot protect against an 3553 untrustworthy partner who holds a microphone up to the speaker. It 3554 does not protect against someone else being in the room. It does not 3555 protect against analog wiretaps in the phone or in the room. It does 3556 not mean your partner has not been hacked with spyware. It does not 3557 mean that the software has no flaws. It means that the ZRTP 3558 subsystem is not knowingly leaking ZRTP cryptographic key material. 3560 12. RTP Header Extension Flag for ZRTP 3562 This specification defines a new RTP header extension used only for 3563 discovery of support for ZRTP. No ZRTP data is transported in the 3564 extension. When used, the X bit is set in the RTP header to indicate 3565 the presence of the RTP header extension. 3567 Section 5.3.1 in RFC 3550 [RFC3550] defines the format of an RTP 3568 Header extension. The Header extension is appended to the RTP 3569 header. The first 16 bits are an identifier for the header 3570 extension, and the following 16 bits are length of the extension 3571 header in 32 bit words. The ZRTP flag RTP header extension has the 3572 value of 0x505A and a length of 0. The format of the header 3573 extension is as shown in the Figure below. 3575 0 1 2 3 3576 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 3577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3578 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 3579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3581 Figure 18: RTP Extension header format for ZRTP Flag 3583 ZRTP endpoints MAY include the ZRTP Flag in RTP packets sent at the 3584 start of a session. For example, an endpoint may decide to include 3585 the flag in the first 2 seconds of RTP packets sent. The inclusion 3586 of the flag MAY be ended if a ZRTP message (such as Hello) is 3587 received. 3589 13. IANA Considerations 3591 This specification defines a new SDP [RFC4566] attribute in 3592 Section 8. 3594 Contact name: Philip Zimmermann 3596 Attribute name: "zrtp-hash". 3598 Type of attribute: Media level. 3600 Subject to charset: Not. 3602 Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the 3603 ZRTP protocol and provides a hash of the ZRTP Hello 3604 message. The ZRTP protocol version number is also 3605 specified. 3607 Allowed attribute values: Hex. 3609 14. Appendix - Media Security Requirements 3611 This section discuses how ZRTP meets all RTP security requirements 3612 discussed in the Media Security Requirements 3613 [I-D.ietf-sip-media-security-requirements] document without any 3614 dependencies on other protocols or extensions, unlike DTLS-SRTP 3615 [I-D.ietf-avt-dtls-srtp] which requires additional protocols and 3616 mechanisms. 3618 R-FORK-RETARGET is met since ZRTP is a media path key agreement 3619 protocol. 3621 R-DISTINCT is met since ZRTP uses ZIDs and allows multiple 3622 independent ZRTP exchanges to proceed. 3624 R-REUSE is met using the Multistream and Preshared modes. 3626 R-AVOID-CLIPPING is met since ZRTP is a media path key agreement 3627 protocol 3628 R-RTP-VALID is met since the ZRTP packet format does not pass the 3629 RTP validity check 3631 R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and 3632 responses. 3634 R-NEGOTIATE is met using the Commit message. 3636 R-PSTN is met since ZRTP can be implemented in Gateways. 3638 R-PFS is met using ZRTP Diffie-Hellman key agreement methods. 3640 R-COMPUTE is met using the Hello/Commit ZRTP exchange. 3642 R-CERTS is met using the optional signature field in ZRTP Confirm 3643 messages. 3645 R-FIPS is met since ZRTP uses algorithms that allow FIPS 3646 certification. 3648 R-DOS is met since ZRTP does not introduce any new denial of 3649 service attacks. 3651 R-EXISTING is met since ZRTP can support the use of certificates 3652 or keys. 3654 R-AGILITY is met since the set of hash, cipher, authentication tag 3655 length, key agreement method, SAS type, and signature type can all 3656 be extended and negotiated. 3658 R-DOWNGRADE is met since ZRTP has protection against downgrade 3659 attacks. 3661 R-PASS-MEDIA is met since ZRTP prevents a passive adversary with 3662 access to the media path from gaining access to keying material 3663 used to protect SRTP media packets. 3665 R-PASS-SIG is met since ZRTP prevents a passive adversary with 3666 access to the signaling path from gaining access to keying 3667 material used to protect SRTP media packets. 3669 R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs 3670 and responses. 3672 R-ID-BINDING is met using the a=zrtp-hash SDP attribute. 3674 R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs 3675 and responses. 3677 R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and 3678 hence best effort SRTP in every case. 3680 R-OTHER-SIGNALING is met since ZRTP can utilize modes in which 3681 there is no dependency on the signaling path. 3683 R-RECORDING is met using the ZRTP Disclosure flag. 3685 R-TRANSCODER is met if the transcoder operates as a trusted MitM 3686 (i.e. a PBX). 3688 R-ALLOW-RTP is met due to ZRTP's best effort encryption. 3690 15. Security Considerations 3692 This document is all about securely keying SRTP sessions. As such, 3693 security is discussed in every section. 3695 Most secure phones rely on a Diffie-Hellman exchange to agree on a 3696 common session key. But since DH is susceptible to a man-in-the- 3697 middle (MiTM) attack, it is common practice to provide a way to 3698 authenticate the DH exchange. In some military systems, this is done 3699 by depending on digital signatures backed by a centrally-managed PKI. 3700 A decade of industry experience has shown that deploying centrally 3701 managed PKIs can be a painful and often futile experience. PKIs are 3702 just too messy, and require too much activation energy to get them 3703 started. Setting up a PKI requires somebody to run it, which is not 3704 practical for an equipment provider. A service provider like a 3705 carrier might venture down this path, but even then you have to deal 3706 with cross-carrier authentication, certificate revocation lists, and 3707 other complexities. It is much simpler to avoid PKIs altogether, 3708 especially when developing secure commercial products. It is 3709 therefore more common for commercial secure phones in the PSTN world 3710 to augment the DH exchange with a Short Authentication String (SAS) 3711 combined with a hash commitment at the start of the key exchange, to 3712 shorten the length of SAS material that must be read aloud. No PKI 3713 is required for this approach to authenticating the DH exchange. The 3714 AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], PGPfone 3715 [pgpfone], and CryptoPhone [cryptophone] are all examples of products 3716 that took this simpler lightweight approach. 3718 The main problem with this approach is inattentive users who may not 3719 execute the voice authentication procedure, or unattended secure 3720 phone calls to answering machines that cannot execute it. 3722 Additionally, some people worry about voice spoofing. But it is a 3723 mistake to think this is simply an exercise in voice impersonation 3724 (perhaps this could be called the "Rich Little" attack). Although 3725 there are digital signal processing techniques for changing a 3726 person's voice, that does not mean a man-in-the-middle attacker can 3727 safely break into a phone conversation and inject his own short 3728 authentication string (SAS) at just the right moment. He doesn't 3729 know exactly when or in what manner the users will choose to read 3730 aloud the SAS, or in what context they will bring it up or say it, or 3731 even which of the two speakers will say it, or if indeed they both 3732 will say it. In addition, some methods of rendering the SAS involve 3733 using a list of words such as the PGP word list[Juola2], in a manner 3734 analogous to how pilots use the NATO phonetic alphabet to convey 3735 information. This can make it even more complicated for the 3736 attacker, because these words can be worked into the conversation in 3737 unpredictable ways. Remember that the attacker places a very high 3738 value on not being detected, and if he makes a mistake, he doesn't 3739 get to do it over. Some people have raised the question that even if 3740 the attacker lacks voice impersonation capabilities, it may be unsafe 3741 for people who don't know each other's voices to depend on the SAS 3742 procedure. This is not as much of a problem as it seems, because it 3743 isn't necessary that they recognize each other by their voice, it is 3744 only necessary that they detect that the voice used for the SAS 3745 procedure matches the voice in the rest of the phone conversation. 3747 A popular and field-proven approach is used by SSH (Secure Shell) 3748 [RFC4251], which Peter Gutmann likes to call the "baby duck" security 3749 model. SSH establishes a relationship by exchanging public keys in 3750 the initial session, when we assume no attacker is present, and this 3751 makes it possible to authenticate all subsequent sessions. A 3752 successful MiTM attacker has to have been present in all sessions all 3753 the way back to the first one, which is assumed to be difficult for 3754 the attacker. ZRTP's key continuity features are actually better 3755 than SSH, at least for VoIP, for reasons described in Section 15.1. 3756 All this is accomplished without resorting to a centrally-managed 3757 PKI. 3759 We use an analogous baby duck security model to authenticate the DH 3760 exchange in ZRTP. We don't need to exchange persistent public keys, 3761 we can simply cache a shared secret and re-use it to authenticate a 3762 long series of DH exchanges for secure phone calls over a long period 3763 of time. If we read aloud just one SAS, and then cache a shared 3764 secret for later calls to use for authentication, no new voice 3765 authentication rituals need to be executed. We just have to remember 3766 we did one already. 3768 If one party ever loses this cached shared secret, it is no longer 3769 available for authentication of DH exchanges. This cache mismatch 3770 situation is easy to detect by the party that still has a surviving 3771 shared secret cache entry. If it fails to match, either there is a 3772 MiTM attack or one side has lost their shared secret cache entry. 3773 The user agent that discovers the cache mismatch must alert the user 3774 that a cache mismatch has been detected, and that he must do a verbal 3775 comparison of the SAS to distinguish if the mismatch is because of a 3776 MiTM attack or because of the other party losing her cache. From 3777 that point on, the two parties start over with a new cached shared 3778 secret. Then they can go back to omitting the voice authentication 3779 on later calls. 3781 A particularly compelling reason why this approach is attractive is 3782 that SAS is easiest to implement when a graphical user interface or 3783 some sort of display is available, which raises the question of what 3784 to do when a display is less conveniently available. For example, 3785 some devices that implement ZRTP might have a graphical user 3786 interface that is only visible through a web browser, such as a PBX 3787 or some other nearby device that implements ZRTP as a "bump-in-the- 3788 wire". If we take an approach that greatly reduces the need for a 3789 SAS in each and every call, we can operate in products without a 3790 graphical user interface with greater ease. Then the SAS can be 3791 compared less frequently through a web browser, or it might even be 3792 presented as needed to the local user through a locally generated 3793 voice prompt, which the local user hears and verbally repeats and 3794 compares with the remote party. Using a voice prompt in this way is 3795 purely for the local ZRTP user agent to render the SAS to the local 3796 user, and is not to be confused with the verbal comparison of the SAS 3797 between two human users. 3799 It is a good idea to force your opponent to have to solve multiple 3800 problems in order to mount a successful attack. Some examples of 3801 widely differing problems we might like to present him with are: 3802 Stealing a shared secret from one of the parties, being present on 3803 the very first session and every subsequent session to carry out an 3804 active MiTM attack, and solving the discrete log problem. We want to 3805 force the opponent to solve more than one of these problems to 3806 succeed. 3808 ZRTP can use different kinds of shared secrets. Each type of shared 3809 secret is determined by a different method. All of the shared 3810 secrets are hashed together to form a session key to encrypt the 3811 call. An attacker must defeat all of the methods in order to 3812 determine the session key. 3814 First, there is the shared secret determined entirely by a Diffie- 3815 Hellman key agreement. It changes with every call, based on random 3816 numbers. An attacker may attempt a classic DH MiTM attack on this 3817 secret, but we can protect against this by displaying and reading 3818 aloud an SAS, combined with adding a hash commitment at the beginning 3819 of the DH exchange. 3821 Second, there is an evolving shared secret, or ongoing shared secret 3822 that is automatically changed and refreshed and cached with every new 3823 session. We will call this the cached shared secret, or sometimes 3824 the retained shared secret. Each new image of this ongoing secret is 3825 a non-invertable function of its previous value and the new secret 3826 derived by the new DH agreement. It is possible that no cached 3827 shared secret is available, because there were no previous sessions 3828 to inherit this value from, or because one side loses its cache. 3830 There are other approaches for key agreement for SRTP that compute a 3831 shared secret using information in the signaling. For example, 3832 [RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing) 3833 [RFC3830] payload in SDP [RFC4566]. Or RFC 4568 (SDES) [RFC4568] 3834 describes directly carrying SRTP keying and configuration information 3835 in SDP. ZRTP does not rely on the signaling to compute a shared 3836 secret, but if a client does produce a shared secret via the 3837 signaling, and makes it available to the ZRTP protocol, ZRTP can make 3838 use of this shared secret to augment the list of shared secrets that 3839 will be hashed together to form a session key. This way, any 3840 security weaknesses that might compromise the shared secret 3841 contributed by the signaling will not harm the final resulting 3842 session key. 3844 The shared secret provided by the signaling (if available), the 3845 shared secret computed by DH, and the cached shared secret are all 3846 hashed together to compute the session key for a call. If the cached 3847 shared secret is not available, it is omitted from the hash 3848 computation. If the signaling provides no shared secret, it is also 3849 omitted from the hash computation. 3851 No DH MiTM attack can succeed if the ongoing shared secret is 3852 available to the two parties, but not to the attacker. This is 3853 because the attacker cannot compute a common session key with either 3854 party without knowing the cached secret component, even if he 3855 correctly executes a classic DH MiTM attack. 3857 15.1. Self-healing Key Continuity Feature 3859 The key continuity features of ZRTP are analogous to those provided 3860 by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH 3861 caches public signature keys that never change, and uses a permanent 3862 private signature key that must be guarded from disclosure. If 3863 someone steals your SSH private signature key, they can impersonate 3864 you in all future sessions and mount a successful MiTM attack any 3865 time they want. 3867 ZRTP caches symmetric key material used to compute secret session 3868 keys, and these values change with each session. If someone steals 3869 your ZRTP shared secret cache, they only get one chance to mount a 3870 MiTM attack, in the very next session. If they miss that chance, the 3871 retained shared secret is refreshed with a new value, and the window 3872 of vulnerability heals itself, which means they are locked out of any 3873 future opportunities to mount a MiTM attack. This gives ZRTP a 3874 "self-healing" feature if any cached key material is compromised. 3876 A MiTM attacker must always be in the media path. This presents a 3877 significant operational burden for the attacker in many VoIP usage 3878 scenarios, because being in the media path for every call is often 3879 harder than being in the signaling path. This will likely create 3880 coverage gaps in the attacker's opportunities to mount a MiTM attack. 3881 ZRTP's self-healing key continuity features are better than SSH at 3882 exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP 3883 quickly recovers from any disclosure of cached key material. 3885 The infamous Debian OpenSSL weak key vulnerability [dsa-1571] 3886 (discovered and patched in May 2008) offers a real-world example of 3887 why ZRTP's self-healing scheme is a good way to do key continuity. 3888 The Debian bug resulted in the production of a lot of weak SSH (and 3889 TLS/SSL) keys, which continued to compromise security even after the 3890 bug had been patched. In contrast, ZRTP's key continuity scheme adds 3891 new entropy to the cached key material with every call, so old 3892 deficiencies in entropy are washed away with each new session. 3894 It should be noted that the addition of shared secret entropy from 3895 previous sessions can extend the strength of the new session key to 3896 AES-256 levels, even if the new session uses Diffie-Hellman keys no 3897 larger than DH-3072 or ECDH-256, provided the cached shared secrets 3898 were initially established when the wiretapper was not present. This 3899 is why AES-256 MAY be used with the smaller DH key sizes in 3900 Section 5.1.5. 3902 Caching shared symmetric key material is also less CPU intensive 3903 compared with using digital signatures, which may be important for 3904 low-power mobile platforms. 3906 16. Acknowledgments 3908 The authors would like to thank Bryce Wilcox-O'Hearn and Colin Plumb 3909 for their contributions to the design of this protocol, and to thank 3910 Hal Finney, Viktor Krikun, Werner Dittmann, Jon Peterson, Dan Wing, 3911 Sagar Pai, Colin Perkins, David McGrew, and Roni Even for their 3912 helpful comments and suggestions. 3914 The use of hash chains to key HMACs in ZRTP is similar to Adrian 3915 Perrig's TESLA protocol [TESLA]. 3917 17. References 3919 17.1. Normative References 3921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3922 Requirement Levels", BCP 14, RFC 2119, March 1997. 3924 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3925 Jacobson, "RTP: A Transport Protocol for Real-Time 3926 Applications", STD 64, RFC 3550, July 2003. 3928 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3929 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3930 RFC 3711, March 2004. 3932 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3933 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3934 RFC 3526, May 2003. 3936 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 3937 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 3938 September 2002. 3940 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 3941 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 3942 RFC 4231, December 2005. 3944 [SP800-90] 3945 Barker, E. and J. Kelsey, "Recommendation for Random 3946 Number Generation Using Deterministic Random Bit 3947 Generators", NIST Special Publication 800-90 (Revised) 3948 March 2007. 3950 [SP800-56A] 3951 Barker, E., Johnson, D., and M. Smid, "Recommendation for 3952 Pair-Wise Key Establishment Schemes Using Discrete 3953 Logarithm Cryptography", NIST Special Publication 800- 3954 56A Revision 1, March 2007. 3956 [FIPS-180-2] 3957 "Secure Hash Signature Standard (SHS)", NIST FIPS PUB 180- 3958 2 August 2002. 3960 [FIPS-198-1] 3961 "The Keyed-Hash Message Authentication Code (HMAC)", NIST 3962 FIPS PUB 198-1 July 2008. 3964 [NSA-Suite-B] 3965 "Fact Sheet NSA Suite B Cryptography", NSA Information 3966 Assurance Directorate Fact Sheet NSA Suite B. 3968 [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", 3969 RFC 4753, January 2007. 3971 [FIPS-186-3] 3972 "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3973 3 Draft, November 2008. 3975 [SP800-38A] 3976 Dworkin, M., "Recommendation for Block Cipher: Methods and 3977 Techniques", NIST Special Publication 800-38A 2001 3978 Edition. 3980 [z-base-32] 3981 Wilcox, B., "Human-oriented base-32 encoding", 3982 http://zooko.com/repos/z-base-32/base32/DESIGN . 3984 [pgpwordlist] 3985 "PGP Words", http://en.wikipedia.org/wiki/PGP_Words . 3987 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3988 Description Protocol", RFC 4566, July 2006. 3990 17.2. Informative References 3992 [I-D.ietf-sip-media-security-requirements] 3993 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 3994 "Requirements and Analysis of Media Security Management 3995 Protocols", draft-ietf-sip-media-security-requirements-08 3996 (work in progress), October 2008. 3998 [SP800-108] 3999 Chen, L., "Recommendation for Key Derivation Using 4000 Pseudorandom Functions", NIST Special Publication 800- 4001 108 November 2008. 4003 [Ferguson] 4004 Ferguson, N. and B. Schneier, "Practical Cryptography", 4005 Wiley Publishing 2003. 4007 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 4008 Requirements for Security", BCP 106, RFC 4086, June 2005. 4010 [Juola1] Juola, P. and P. Zimmermann, "Whole-Word Phonetic 4011 Distances and the PGPfone Alphabet", Proceedings of the 4012 International Conference of Spoken Language Processing 4013 (ICSLP-96) 1996. 4015 [Juola2] Juola, P., "Isolated Word Confusion Metrics and the 4016 PGPfone Alphabet", Proceedings of New Methods in Language 4017 Processing 1996. 4019 [pgpfone] Zimmermann, P., "PGPfone", 4020 http://philzimmermann.com/docs/pgpfone10b7.pdf . 4022 [zfone] Zimmermann, P., "Zfone", 4023 http://www.philzimmermann.com/zfone . 4025 [Byzantine] 4026 "The Two Generals' Problem", 4027 http://en.wikipedia.org/wiki/Two_Generals%27_Problem . 4029 [TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The 4030 TESLA Broadcast Authentication Protocol", http:// 4031 www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ 4032 tesla-cryptobytes.pdf . 4034 [SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer 4035 Security Resource Center Cryptographic Hash Project. 4037 [comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices 4038 Version 1.2", http://www.comsec.com/vp1-protocol.pdf . 4040 [cryptophone] 4041 "CryptoPhone", http://www.cryptophone.de/ . 4043 [Wright1] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. 4044 Masson, "Spot me if you can: Uncovering spoken phrases in 4045 encrypted VoIP conversations", Proceedings of the 2008 4046 IEEE Symposium on Security and Privacy 2008. 4048 [dsa-1571] 4049 "Debian Security Advisory - OpenSSL predictable random 4050 number generator", 4051 http://www.debian.org/security/2008/dsa-1571 . 4053 [I-D.ietf-avt-srtp-big-aes] 4054 McGrew, D., "The use of AES-192 and AES-256 in Secure 4055 RTP", http://www1.tools.ietf.org/html/ 4056 draft-ietf-avt-srtp-big-aes . 4058 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4059 A., Peterson, J., Sparks, R., Handley, M., and E. 4060 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4061 June 2002. 4063 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 4064 Protocol Architecture", RFC 4251, January 2006. 4066 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 4067 Description Protocol (SDP) Security Descriptions for Media 4068 Streams", RFC 4568, July 2006. 4070 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 4071 Carrara, "Key Management Extensions for Session 4072 Description Protocol (SDP) and Real Time Streaming 4073 Protocol (RTSP)", RFC 4567, July 2006. 4075 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 4076 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 4077 August 2004. 4079 [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", 4080 RFC 3514, April 1 2003. 4082 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 4083 Authenticated Identity Management in the Session 4084 Initiation Protocol (SIP)", RFC 4474, August 2006. 4086 [I-D.ietf-mmusic-ice] 4087 Rosenberg, J., "Interactive Connectivity Establishment 4088 (ICE): A Protocol for Network Address Translator (NAT) 4089 Traversal for Offer/Answer Protocols", 4090 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 4092 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 4093 (SIP) Call Control - Conferencing for User Agents", 4094 BCP 119, RFC 4579, August 2006. 4096 [I-D.wing-sip-identity-media] 4097 Wing, D. and H. Kaplan, "SIP Identity using Media Path", 4098 draft-wing-sip-identity-media-02 (work in progress), 4099 February 2008. 4101 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 4102 E.164 numbers with the Session Initiation Protocol (SIP)", 4103 RFC 3824, June 2004. 4105 [I-D.ietf-avt-dtls-srtp] 4106 McGrew, D. and E. Rescorla, "Datagram Transport Layer 4107 Security (DTLS) Extension to Establish Keys for Secure 4108 Real-time Transport Protocol (SRTP)", 4109 draft-ietf-avt-dtls-srtp-06 (work in progress), 4110 October 2008. 4112 Authors' Addresses 4114 Philip Zimmermann 4115 Zfone Project 4117 Email: prz@mit.edu 4119 Alan Johnston (editor) 4120 Avaya 4121 St. Louis, MO 63124 4123 Email: alan@sipstation.com 4125 Jon Callas 4126 PGP Corporation 4128 Email: jon@pgp.com 4130 Full Copyright Statement 4132 Copyright (C) The IETF Trust (2008). 4134 This document is subject to the rights, licenses and restrictions 4135 contained in BCP 78, and except as set forth therein, the authors 4136 retain all their rights. 4138 This document and the information contained herein are provided on an 4139 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4140 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4141 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4142 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4143 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4144 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4146 Intellectual Property 4148 The IETF takes no position regarding the validity or scope of any 4149 Intellectual Property Rights or other rights that might be claimed to 4150 pertain to the implementation or use of the technology described in 4151 this document or the extent to which any license under such rights 4152 might or might not be available; nor does it represent that it has 4153 made any independent effort to identify any such rights. Information 4154 on the procedures with respect to rights in RFC documents can be 4155 found in BCP 78 and BCP 79. 4157 Copies of IPR disclosures made to the IETF Secretariat and any 4158 assurances of licenses to be made available, or the result of an 4159 attempt made to obtain a general license or permission for the use of 4160 such proprietary rights by implementers or users of this 4161 specification can be obtained from the IETF on-line IPR repository at 4162 http://www.ietf.org/ipr. 4164 The IETF invites any interested party to bring to its attention any 4165 copyrights, patents or patent applications, or other proprietary 4166 rights that may cover technology that may be required to implement 4167 this standard. Please address the information to the IETF at 4168 ietf-ipr@ietf.org.