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