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