idnits 2.17.1 draft-zimmermann-avt-zrtp-08.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 4081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4105. 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 23, 2008) is 5691 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: March 27, 2009 Avaya 6 J. Callas 7 PGP Corporation 8 September 23, 2008 10 ZRTP: Media Path Key Agreement for Secure RTP 11 draft-zimmermann-avt-zrtp-08 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 March 27, 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 5.4.3.1. Commitment in Preshared Mode 1166 Preshared mode is selected by setting the Key Agreement Type to 1167 Preshared in the Commit message. This results in the same call flow 1168 as Multistream mode. The principal difference between Multistream 1169 mode and Preshared mode is that Preshared mode uses a previously 1170 cached shared secret, rs1, instead of an active ZRTP Session key, 1171 ZRTPSess, as the initial keying material. 1173 Because Preshared mode depends on having a reliable shared secret in 1174 its cache, it is RECOMMENDED that Preshared mode only be used when 1175 the SAS Verified flag has been previously set. 1177 5.4.3.2. Initiator Behavior 1179 The Commit message (Figure 7) is sent by the initiator of the ZRTP 1180 exchange. From the intersection of the algorithms in the sent and 1181 received Hello messages, the initiator chooses a hash, cipher, auth 1182 tag, key agreement type, and SAS type to be used. 1184 To assemble a Preshared commit, we must first construct a temporary 1185 preshared_key, which is constructed from one of several possible 1186 combinations of cached key material, depending on what is available 1187 in the shared secret cache. If rs1 is not available in the 1188 initiator's cache, then Preshared mode MUST NOT be used. 1190 preshared_key = hash( len(rs1) | rs1 | len(auxsecret) | auxsecret 1191 | len(pbxsecret) | pbxsecret ) 1193 All of the explicit length fields, len(), in the above hash are 32- 1194 bit big-endian integers, giving the length in octets of the field 1195 that follows. Some members of the set of shared secrets (rs1, 1196 auxsecret, and pbxsecret) may have lengths of zero if they are null 1197 (not available), and are each preceded by a 4-octet length field. 1198 For example, if auxsecret is null, len(auxsecret) is 0x00000000, and 1199 auxsecret itself would be absent from the hash calculation, which 1200 means len(pbxsecret) would immediately follow len(auxsecret). 1202 In place of hvi in the Commit message, two smaller fields are 1203 inserted by the initiator: 1205 - A random nonce of length 4-words (16 octets). 1206 - A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits. 1208 5.4.3.3. Responder Behavior 1210 The responder uses the received keyID to search for matching key 1211 material in its cache. It does this by computing a preshared_key 1212 value and keyID value using the same formula as the initiator, 1213 depending on what is available in the responder's local cache. If 1214 the locally computed keyID does not match the received keyID in the 1215 Commit, the responder recomputes a new preshared_key and keyID from a 1216 different subset of shared keys from the cache, dropping auxsecret or 1217 pbxsecret or both from the hash calculation, until a matching 1218 preshared_key is found or it runs out of possibilities. If 1219 necessary, the responder should also substitute rs2 for rs1 in the 1220 hash. 1222 If it finds the appropriate matching shared key material, it is used 1223 to derive s0 and a new ZRTPSess key, as described in the next section 1224 on Shared Secret Calculation, Section 5.4.3.4. 1226 If the responder determines that it does not have a cached shared 1227 secret from a previous DH exchange, or it fails to match the keyID 1228 hash from the initiator with any combination of its shared keys, it 1229 SHOULD respond with its own DH Commit message. This would reverse 1230 the roles and the responder would become the initiator, because the 1231 DH Commit must always "trump" the Preshared Commit message as 1232 described in Section 5.2. The key exchange would then proceeds using 1233 DH mode. However, if a severely resource-limited responder lacks the 1234 computing resources to respond in a reasonable time with a DH Commit, 1235 it MAY respond with a ZRTP Error message (Section 6.9) indicating 1236 that no shared secret is available. 1238 If both sides send Preshared Commit messages initiating a secure 1239 session at the same time, the contention is resolved and the 1240 initiator/responder roles are settled according to Section 5.2, and 1241 the protocol proceeds. 1243 In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. 1244 After receiving the Commit message from the initiator, the responder 1245 sends the Confirm1 message after calculating this stream's SRTP keys, 1246 as described below. 1248 5.4.3.4. Shared Secret Calculation for Preshared Mode 1250 A hash of the received and sent ZRTP messages in the current ZRTP 1251 exchange for the current media stream is calculated: 1253 total_hash = hash(Hello of responder | Commit ) 1255 Note that only the ZRTP messages (Figure 3 and Figure 7), not the 1256 entire ZRTP packets, are included in the hash. The nonce from the 1257 Commit message is implicitly included in the total_hash, which hashed 1258 the entire Commit message and the other party's Hello message. Next, 1259 the preshared_key is used to derive s0 and ZRTPSess: 1261 s0 = HMAC(preshared_key, total_hash) 1262 ZRTPSess = HMAC(s0,"ZRTP Session Key") 1264 The preshared_key is erased as soon as it has been used to calculate 1265 s0 and ZRTPSess. The ZRTPSess key allows the later use of 1266 Multistream mode for adding additional media streams to this session. 1268 Note that the responder's Hello message, included in the total_hash, 1269 includes some unique nonce-derived material of its own (the H3 hash 1270 image), thereby ensuring that each of the two parties can 1271 unilaterally force the resulting s0 shared secret to be unique for 1272 each media stream, even if one party by some error fails to produce a 1273 unique nonce. 1275 Note: Since the nonce is used to calculate different SRTP key and 1276 salt pairs for each media stream, a duplication will result in the 1277 same key and salt being generated for the two media streams, which 1278 would have disastrous security consequences. 1280 At this point in Preshared mode, the two endpoints begin key 1281 generation as described in Section 5.5, now that there is a defined 1282 s0 and ZRTPSess key. 1284 5.5. Key Generation 1286 The following calculations derive a set of keys from s0. For the 1287 original media stream that calculated s0 from the DH exchange, s0 1288 means the original s0. For any additional media streams that were 1289 activated in Multistream mode, s0 means s0n, for the n-th media 1290 stream. It is also assumed that the ZRTPSess key has been defined. 1292 Various keys, such as those used by SRTP, must be derived from the 1293 shared secret s0. To do this, ZRTP uses an HMAC-based key derivation 1294 function, keyed by s0, instead of simply drawing subkey material 1295 directly from s0, as defined in NIST SP800-56A. The possibly greater 1296 noninvertability of HMAC may add an extra measure of isolation for 1297 the derived keys. 1299 The SRTP master key and master salt are derived from s0. Separate 1300 SRTP keys and salts are used in each direction for each media stream. 1301 Unless otherwise specified, ZRTP uses SRTP with no MKI, 32 bit 1302 authentication using HMAC-SHA1, AES-CM 128 or 256 bit key length, 112 1303 bit session salt key length, 2^48 key derivation rate, and SRTP 1304 prefix length 0. 1306 The ZRTP initiator encrypts and the ZRTP responder decrypts packets 1307 by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts 1308 and the ZRTP initiator decrypts packets by using srtpkeyr and 1309 srtpsaltr. These are generated by: 1311 srtpkeyi = HMAC(s0,"Initiator SRTP master key") 1312 srtpsalti = HMAC(s0,"Initiator SRTP master salt") 1313 srtpkeyr = HMAC(s0,"Responder SRTP master key") 1314 srtpsaltr = HMAC(s0,"Responder SRTP master salt") 1316 The SRTP key and salt values are truncated (taking the leftmost bits) 1317 to the length determined by the chosen SRTP algorithm. 1319 The HMAC keys are the same length as the output of the underlying 1320 hash function, and are thus generated without truncation by: 1322 hmackeyi = HMAC(s0,"Initiator HMAC key") 1323 hmackeyr = HMAC(s0,"Responder HMAC key") 1325 Note that these HMAC keys are used only by ZRTP and not by SRTP. 1327 Note: Different HMAC keys are needed for the initiator and the 1328 responder to ensure that GoClear messages in each direction are 1329 unique and can not be cached by an attacker and reflected back to the 1330 endpoint. 1332 ZRTP keys are generated for the initiator and responder to use to 1333 encrypt the Confirm1 and Confirm2 messages. They are truncated to 1334 the same size as the negotiated SRTP key size. 1336 zrtpkeyi = HMAC(s0,"Initiator ZRTP key") 1337 zrtpkeyr = HMAC(s0,"Responder ZRTP key") 1339 All key material is destroyed as soon as it is no longer needed, no 1340 later than the end of the call. s0 is erased in Section 5.6.1, and 1341 the rest of the session key material is erased in Section 5.7.2.1 and 1342 Section 5.7.3. 1344 The Short Authentication String (SAS) value is calculated from the 1345 HMAC of a fixed string, keyed with the ZRTPSess key derived from the 1346 DH key agreement. This means the same SAS is used for all media 1347 streams which are derived from a single DH key agreement in a ZRTP 1348 session. 1350 sashash = HMAC(ZRTPSess,"SAS") 1351 sasvalue = sashash [truncated to leftmost 32 bits] 1353 5.6. Confirmation 1355 The Confirm1 and Confirm2 messages (Figure 10) contain the cache 1356 expiration interval (defined in Section 5.9) for the newly generated 1357 retained shared secret. The flagoctet is an 8 bit unsigned integer 1358 made up of these flags: the PBX Enrollment flag (E) defined in 1359 Section 8.3.1, SAS Verified flag (V) defined in Section 8.1, Allow 1360 Clear flag (A) defined in Section 5.7.2, and Disclosure flag (D) 1361 defined in Section 12. 1363 flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) 1365 Part of the Confirm1 and Confirm2 messages are encrypted using full- 1366 block Cipher Feedback Mode, and contain a 128-bit random CFB 1367 Initialization Vector (IV). The Confirm1 and Confirm2 messages also 1368 contain an HMAC covering the encrypted part of the Confirm1 or 1369 Confirm2 message which includes a string of zeros, the signature 1370 length, flag octet, cache expiration interval, signature type block 1371 (if present) and signature block (Section 8.2) (if present). For the 1372 responder 1374 hmac = HMAC(hmackeyr, encrypted part of Confirm1) 1376 For the initiator: 1378 hmac = HMAC(hmackeyi, encrypted part of Confirm2) 1380 The hmackeyi and hmackeyr keys are computed in Section 5.5. 1382 The Conf2ACK message sent by the responder completes the exchange. 1384 5.6.1. Updating the Cache of Shared Secrets 1386 After receiving the Confirm messages, both parties must now update 1387 their retained shared secret rs1 in their respective caches, provided 1388 the following conditions hold: 1390 1) This key exchange is either DH or Preshared mode, not 1391 Multistream mode, which does not update the cache. 1392 2) Depending on the values of the cache expiration intervals that 1393 are received in the two Confirm messages, there are some scenarios 1394 that do not update the cache, as explained in Section 5.9. 1395 3) The responder MUST receive the initiator's Confirm2 message 1396 before updating the responder's cache. 1397 4) The initiator MUST receive the responder's Conf2Ack message 1398 before updating the initiator's cache. 1400 Before updating the retained shared secret rs1 in the cache, each 1401 party first discards their old rs2 and copies their old rs1 to rs2. 1402 Then they compute a new rs1 value from s0 this way: 1404 rs1 = HMAC(s0,"retained secret") 1406 The old rs1 was saved to rs2 because of the risk of session 1407 interruption after one party has updated his own rs1 but before the 1408 other party has enough information to update her own rs1. If that 1409 happens, they may regain cache sync in the next session by using rs2 1410 (per Section 5.3). This mitigates the well-known Byzantine Generals' 1411 Problem [Byzantine]. 1413 After s0 is used to derive the new rs1, it MUST be erased. Even if 1414 rs1 is not updated (in the case of Multistream mode), s0 MUST still 1415 be destroyed. 1417 5.7. Termination 1419 A ZRTP session is normally terminated at the end of a call, but it 1420 may be terminated early by either the Error message or the GoClear 1421 message. 1423 5.7.1. Termination via Error message 1425 The Error message (Section 6.9) is used to terminate an in-progress 1426 ZRTP exchange due to an error. The Error message contains an integer 1427 Error Code for debugging purposes. The termination of a ZRTP key 1428 agreement exchange results in no updates to the cached shared secrets 1429 and deletion of all crypto context. 1431 The ZRTP Session key, ZRTPSess, is only deleted if the ZRTP session 1432 in which it was generated and all ZRTP sessions which are using it 1433 are terminated. 1435 5.7.2. Termination via GoClear message 1437 The GoClear message (Section 6.11) is used to switch from SRTP to 1438 RTP, usually because the user has chosen to do that by pressing a 1439 button. The GoClear uses an HMAC of the Message Type Block sent in 1440 the GoClear Message computed with the hmackey derived from the shared 1441 secret. This HMAC is truncated to the leftmost 64 bits. When sent 1442 by the initiator: 1444 clear_hmac = HMAC(hmackeyi, "GoClear ") 1446 When sent by the responder: 1448 clear_hmac = HMAC(hmackeyr, "GoClear ") 1450 A GoClear message which does not receive a ClearACK response must be 1451 resent. If a GoClear message is received with a bad HMAC, it must be 1452 ignored, and no ClearACK is sent. 1454 A ZRTP endpoint MAY choose to accept GoClear messages after the 1455 session has switched to SRTP, allowing the session to revert to RTP. 1456 This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by 1457 setting the Allow Clear flag (A). If both endpoints set the Allow 1458 Clear (A) flag in their Confirm message, GoClear messages MAY be 1459 sent. 1461 A ZRTP endpoint that receives a GoClear authenticates the message by 1462 checking the clear_hmac. If the message authenticates, the endpoint 1463 stops sending SRTP packets, and generates a ClearACK in response. It 1464 MUST also delete all the crypto key material for all the SRTP media 1465 streams, as defined in Section 5.7.2.1. 1467 Until confirmation from the user is received (e.g. clicking a button, 1468 pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending 1469 RTP packets. The endpoint then renders to the user an indication 1470 that the media session has switched to clear mode, and waits for 1471 confirmation from the user. To prevent pinholes from closing or NAT 1472 bindings from expiring, the ClearACK message MAY be resent at regular 1473 intervals (e.g. every 5 seconds) while waiting for confirmation from 1474 the user. After confirmation of the notification is received from 1475 the user, the sending of RTP packets may begin. 1477 After sending a GoClear message, the ZRTP endpoint stops sending SRTP 1478 packets. When a ClearACK is received, the ZRTP endpoint deletes the 1479 crypto context for the SRTP session, as defined in Section 5.7.2.1, 1480 and may then resume sending RTP packets. 1482 In the event a ClearACK is not received before the retransmissions of 1483 GoClear are exhausted, the key material is deleted, as defined in 1484 Section 5.7.2.1. 1486 After the users have transitioned from SRTP media back to RTP media 1487 (clear mode), they may decide later to return to secure mode by 1488 manual activation, usually by pressing a GO SECURE button. In that 1489 case, a new secure session is initiated by the party that presses the 1490 button, by sending a new Commit packet, leadng to a new session key 1491 negotiation. It is not necessary to send another Hello packet, as 1492 the two parties have already done that at the start of the call and 1493 thus have already discovered each other's ZRTP capabilities. It is 1494 possible for users to toggle back and forth between clear and secure 1495 modes multiple times in the same call, just as they could in the old 1496 days of secure PSTN phones. 1498 5.7.2.1. Key Destruction for GoClear message 1500 All SRTP session key material MUST be erased by the receiver of the 1501 GoClear message upon receiving a properly authenticated GoClear. The 1502 same key destruction MUST be done by the sender of GoClear message, 1503 upon receiving the ClearACK. 1505 In particular, the destroyed key material includes the SRTP session 1506 keys and salts, SRTP master keys and salts, and all material 1507 sufficient to reconstruct the SRTP keys and salts, including ZRTPSess 1508 (s0 should have been destroyed earlier, in Section 5.6.1). All key 1509 material that would have been erased at the end of the SIP session 1510 MUST be erased. However, ZRTPSess is destroyed in a manner different 1511 from the other key material. Both parties replace ZRTPSess with a 1512 hash of itself, without truncation: 1514 ZRTPSess = hash(ZRTPSess) 1516 This meets the requirements of Perfect Forward Secrecy (PFS), but 1517 preserves a new version of ZRTPSess, so that if the user later re- 1518 initiates secure mode during the same call, the new key negotiation 1519 can (and SHOULD) use a Multistream Commit message, which requires and 1520 assumes the existence of ZRTPSess with the same value at both ZRTP 1521 endpoints. 1523 Later, at the end of the entire call, ZRTPSess is finally destroyed 1524 along with the other key material, as described in Section 5.7.3. 1526 5.7.3. Key Destruction at Termination 1528 All SRTP session key material MUST be erased by both parties at the 1529 end of the call. In particular, the destroyed key material includes 1530 the SRTP session keys and salts, SRTP master keys and salts, and all 1531 material sufficient to reconstruct the SRTP keys and salts, including 1532 ZRTPSess and s0 (although s0 should have been destroyed earlier, in 1533 Section 5.6.1). The only exceptions are the cached shared secrets 1534 needed for future calls, including rs1, rs2, and pbxsecret. 1536 5.8. Random Number Generation 1538 The ZRTP protocol uses random numbers for cryptographic key material, 1539 notably for the DH secret exponents and nonces, which must be freshly 1540 generated with each session. Whenever a random number is needed, all 1541 of the following criteria must be satisfied: 1543 It MUST be freshly generated, meaning that it must not have been used 1544 in a previous calculation. 1546 When generating a random number k of L bits in length, k MUST be 1547 chosen with equal probability from the range of [1 < k < 2^L]. 1549 It MUST be derived from a physical entropy source, such as RF noise, 1550 acoustic noise, thermal noise, high resolution timings of 1551 environmental events, or other unpredictable physical sources of 1552 entropy. For a detailed explanation of cryptographic grade random 1553 numbers and guidance for collecting suitable entropy, see RFC 4086 1554 [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. The 1555 raw entropy must be distilled and processed through a deterministic 1556 random bit generator (DRBG). Examples of DRBGs may be found in NIST 1557 SP 800-90 [SP800-90], and in [Ferguson]. Failure to use true entropy 1558 from the physical environment as a basis for generating random 1559 cryptographic key material would lead to a disastrous loss of 1560 security. 1562 5.9. ZID and Cache Operation 1564 Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that 1565 is generated once at installation time. It is used to look up 1566 retained shared secrets in a local cache. A single global ZID for a 1567 single installation is the simplest way to implement ZIDs. However, 1568 it is specifically not precluded for an implementation to use 1569 multiple ZIDs, up to the limit of a separate one per callee. This 1570 then turns it into a long-lived "association ID" that does not apply 1571 to any other associations between a different pair of parties. It is 1572 a goal of this protocol to permit both options to interoperate 1573 freely. 1575 Each time a new s0 is calculated, a new retained shared secret rs1 is 1576 generated and stored in the cache, indexed by the ZID of the other 1577 endpoint. But first the previous rs1 is copied to rs2 and also 1578 stored in the cache. For the new retained shared secret, each 1579 endpoint chooses a cache expiration value which is an unsigned 32 bit 1580 integer of the number of seconds that this secret should be retained 1581 in the cache. The time interval is relative to when the Confirm1 1582 message is sent or received. 1584 The cache intervals are exchanged in the Confirm1 and Confirm2 1585 messages (Figure 10). The actual cache interval used by both 1586 endpoints is the minimum of the values from the Confirm1 and Confirm2 1587 messages. A value of 0 seconds means the newly-computed shared 1588 secret SHOULD NOT be stored in the cache, and if a cache entry 1589 already exists from an earlier call, the stored cache interval should 1590 be set to 0. This means if either Confirm message contains a null 1591 cache expiration interval, and there is no cache entry already 1592 defined, no new cache entry is created. A value of 0xffffffff means 1593 the secret should be cached indefinitely and is the recommended 1594 value. If the ZRTP exchange is Multistream Mode, the field in the 1595 Confirm1 and Confirm2 is set to 0xffffffff and ignored, and the cache 1596 is not updated. 1598 The expiration interval need not be used to force the deletion of a 1599 shared secret from the cache when the interval has expired. It just 1600 means the shared secret MAY be deleted from that cache at any point 1601 after the interval has expired without causing the other party to 1602 note it as an unexpected security event when the next key negotiation 1603 occurs between the same two parties. This means there need not be 1604 perfectly synchronized deletion of expired secrets from the two 1605 caches, and makes it easy to avoid a race condition that might 1606 otherwise be caused by clock skew. 1608 If the expiration interval is not properly agreed to by both 1609 endpoints, it may later result in false alarms of MiTM attacks, due 1610 to apparent cache mismatches (Section 5.3.3). 1612 5.9.1. Self-healing Key Continuity Feature 1614 The key continuity features of ZRTP are analogous to those provided 1615 by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH 1616 caches public signature keys that never change, and uses a permanent 1617 private signature key that must be guarded from disclosure. If 1618 someone steals your SSH private signature key, they can impersonate 1619 you in all future sessions and mount a successful MiTM attack any 1620 time they want. 1622 ZRTP caches symmetric key material used to compute secret session 1623 keys, and these values change with each session. If someone steals 1624 your ZRTP shared secret cache, they only get one chance to mount a 1625 MiTM attack, in the very next session. If they miss that chance, the 1626 retained shared secret is refreshed with a new value, and the window 1627 of vulnerability heals itself, which means they are locked out of any 1628 future opportunities to mount a MiTM attack. This gives ZRTP a 1629 "self-healing" feature if any cached key material is compromised. 1631 A MiTM attacker must always be in the media path. This presents a 1632 significant operational burden for the attacker in many VoIP usage 1633 scenarios, because being in the media path for every call is often 1634 harder than being in the signaling path. This will likely create 1635 coverage gaps in the attacker's opportunities to mount a MiTM attack. 1636 ZRTP's self-healing key continuity features are better than SSH at 1637 exploiting any temporary gaps in MiTM attack coverage. Thus, ZRTP 1638 quickly recovers from any disclosure of cached key material. 1640 The infamous Debian OpenSSL weak key vulnerability [dsa-1571] 1641 (discovered and patched in May 2008) offers a real-world example of 1642 why ZRTP's self-healing scheme is a good way to do key continuity. 1643 The Debian bug resulted in the production of a lot of weak SSH (and 1644 TLS/SSL) keys, which continued to compromise security even after the 1645 bug had been patched. In contrast, ZRTP's key continuity scheme adds 1646 new entropy to the cached key material with every call, so old 1647 deficiencies in entropy are washed away with each new session. 1649 It should be noted that the addition of shared secret entropy from 1650 previous sessions can extend the strength of the new session key to 1651 AES-256 levels, even if the new session uses Diffie-Hellman keys no 1652 larger than DH-3072 or ECDH-256, provided the cached shared secrets 1653 were initially established when the wiretapper was not present. This 1654 is why AES-256 MAY be used with the smaller DH key sizes in 1655 Section 6.1.5. 1657 6. ZRTP Messages 1659 All ZRTP messages use the message format defined in Figure 2. All 1660 word lengths referenced in this specification are 32 bits or 4 1661 octets. All integer fields are carried in network byte order, that 1662 is, most significant byte (octet) first, commonly known as big- 1663 endian. 1665 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 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 |0 0 0 1|Not Used (set to zero) | Sequence Number | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | ZRTP Magic Cookie (0x5a525450) | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | Source Identifier | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | | 1674 | ZRTP Message (length depends on Message Type) | 1675 | . . . | 1676 | | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | CRC (1 word) | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 ZRTP Packet Format 1683 Figure 2: ZRTP Packet Format 1685 The Sequence Number is a count that is incremented for each ZRTP 1686 packet sent. The count is initialized to a random value. This is 1687 useful in estimating ZRTP packet loss and also detecting when ZRTP 1688 packets arrive out of sequence. 1690 The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a 1691 ZRTP packet, and has the value 0x5a525450. 1693 Source Identifier is the SSRC number of the RTP stream that this ZRTP 1694 packet relates to. For cases of forking or forwarding, RTP and hence 1695 ZRTP may arrive at the same port from several different sources - 1696 each of these sources will have a different SSRC and may initiate an 1697 independent ZRTP protocol session. 1699 This format is clearly identifiable as non-RTP due to the first two 1700 bits being zero which looks like RTP version 0, which is not a valid 1701 RTP version number. It is clearly distinguishable from STUN since 1702 the magic cookies are different. The 12 not used bits are set to 1703 zero and MUST be ignored when received. 1705 The ZRTP Messages are defined in Figure 3 to Figure 17 and are of 1706 variable length. 1708 The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as 1709 defined in RFC 3309 [RFC3309] to detect transmission errors. ZRTP 1710 packets are typically transported by UDP, which carries its own 1711 built-in 16-bit checksum for integrity, but ZRTP does not rely on it. 1712 This is because of the effect of an undetected transmission error in 1713 a ZRTP message. For example, an undetected error in the DH exchange 1714 could appear to be an active man-in-the-middle attack. The 1715 psychological effects of a false announcement of this by ZRTP clients 1716 can not be overstated. The probability of such a false alarm hinges 1717 on a mere 16-bit checksum that usually protects UDP packets, so more 1718 error detection is needed. For these reasons, this belt-and- 1719 suspenders approach is used to minimize the chance of a transmission 1720 error affecting the ZRTP key agreement. 1722 The CRC is calculated across the entire ZRTP packet shown in 1723 Figure 2, including the ZRTP Header and the ZRTP Message, but not 1724 including the CRC field. If a ZRTP message fails the CRC check, it 1725 is silently discarded. 1727 6.1. ZRTP Message Formats 1729 ZRTP messages are designed to simplify endpoint parsing requirements 1730 and to reduce the opportunities for buffer overflow attacks (a good 1731 goal of any security extension should be to not introduce new attack 1732 vectors). 1734 ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets 1735 (1 word) blocks are used to encode Hash Type, Cipher Type, and Key 1736 Agreement Type, and Authentication Tag. The values in the blocks are 1737 ASCII strings which are extended with spaces (0x20) to make them the 1738 desired length. Currently defined block values are listed in Tables 1739 1-6 below. 1741 Additional block values may be defined and used. 1743 ZRTP uses this ASCII encoding to simplify debugging and make it 1744 "Wireshark (Ethereal) friendly". 1746 6.1.1. Message Type Block 1748 Currently 14 Message Type Blocks are defined - they represent the set 1749 of ZRTP message primitives. ZRTP endpoints MUST support the Hello, 1750 HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, 1751 SASrelay, RelayACK, Error and ErrorACK block types. ZRTP endpoints 1752 MAY support the GoClear and ClearACK messages. Additional messages 1753 may be defined in extensions to ZRTP. 1755 Message Type Block | Meaning 1756 --------------------------------------------------- 1757 "Hello " | Hello Message 1758 | defined in Section 6.2 1759 --------------------------------------------------- 1760 "HelloACK" | HelloACK Message 1761 | defined in Section 6.3 1762 --------------------------------------------------- 1763 "Commit " | Commit Message 1764 | defined in Section 6.4 1765 --------------------------------------------------- 1766 "DHPart1 " | DHPart1 Message 1767 | defined in Section 6.5 1768 --------------------------------------------------- 1769 "DHPart2 " | DHPart2 Message 1770 | defined in Section 6.6 1771 --------------------------------------------------- 1772 "Confirm1" | Confirm1 Message 1773 | defined in Section 6.7 1774 --------------------------------------------------- 1775 "Confirm2" | Confirm2 Message 1776 | defined in Section 6.7 1777 --------------------------------------------------- 1778 "Conf2ACK" | Conf2ACK Message 1779 | defined in Section 6.8 1780 --------------------------------------------------- 1781 "Error " | Error Message 1782 | defined in Section 6.9 1783 --------------------------------------------------- 1784 "ErrorACK" | ErrorACK Message 1785 | defined in Section 6.10 1786 --------------------------------------------------- 1787 "GoClear " | GoClear Message 1788 | defined in Section 6.11 1789 --------------------------------------------------- 1790 "ClearACK" | ClearACK Message 1791 | defined in Section 6.12 1792 --------------------------------------------------- 1793 "SASrelay" | SASrelay Message 1794 | defined in Section 6.13 1795 --------------------------------------------------- 1796 "RelayACK" | RelayACK Message 1797 | defined in Section 6.14 1798 --------------------------------------------------- 1800 Table 1. Message Block Type Values 1802 6.1.2. Hash Type Block 1804 Only one Hash Type is currently defined, SHA-256 [FIPS-180-2], and 1805 all ZRTP endpoints MUST support this hash. Additional Hash Types can 1806 be registered and used, such as the NIST SHA-3 hash [SHA-3] when it 1807 becomes available. Note that the Hash Type refers to the hash 1808 algorithm that will be used throughout the ZRTP key exchange, not the 1809 hash algorithm to be used in the SRTP Authentication Tag. 1811 ZRTP makes use of HMAC message authentication codes based on the 1812 negotiated Hash Type. The HMAC function is defined in [FIPS-198-1]. 1813 Test vectors for HMAC-SHA-256 may be found in [RFC4231]. 1815 Hash Type Block | Meaning 1816 --------------------------------------------------- 1817 "S256" | SHA-256 Hash defined in FIPS 180-2 1818 --------------------------------------------------- 1820 Table 2. Hash Block Type Values 1822 All hashes and HMACs used throughout the ZRTP protocol will use the 1823 negotiated Hash Type, except for the special cases noted in 1824 Section 6.1.2.1. 1826 6.1.2.1. Implicit Hash and HMAC algorithm 1828 While most of the HMACs used in ZRTP are defined by the negotiated 1829 Hash Type (Section 6.1.2), some hashes and HMACs must be precomputed 1830 prior to negotiations, and thus cannot have their algorithms 1831 negotiated during the ZRTP exchange. They are implicitly 1832 predetermined to use SHA-256 [FIPS-180-2] and HMAC-SHA-256. 1834 These are the hashes and HMACs that MUST use the Implicit hash and 1835 HMAC algorithm: 1837 The hash chain H0-H3 defined in Section 10. 1838 The HMACs that are keyed by this hash chain, as defined in 1839 Section 9.1.1. 1840 The Hello Hash in the a=zrtp-hash attribute defined in 1841 Section 9.1. 1843 ZRTP defines a method for negotiating different ZRTP protocol 1844 versions (Section 5.1.1). SHA-256 is the Implicit Hash for ZRTP 1845 protocol version 1.00. Future ZRTP protocol versions may, if 1846 appropriate, use another hash algorithm as the Implicit Hash, such as 1847 the NIST SHA-3 hash [SHA-3] when it becomes available. For example, 1848 a future SIP packet may list two a=zrtp-hash SDP attributes, one 1849 based on SHA-256 for ZRTP version 1.00, and another based on SHA-3 1850 for ZRTP version 2.00. 1852 6.1.3. Cipher Type Block 1854 All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- 1855 256 (AES3). or other Cipher Types. The choice of the AES key length 1856 is coupled to the Key Agreement type, as explained in Section 6.1.5. 1858 The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- 1859 256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. 1861 Cipher Type Block | Meaning 1862 --------------------------------------------------- 1863 "AES1" | AES-CM with 128 bit keys 1864 | as defined in RFC 3711 1865 --------------------------------------------------- 1866 "AES3" | AES-CM with 256 bit keys 1867 | 1868 --------------------------------------------------- 1870 Table 3. Cipher Block Type Values 1872 6.1.4. Auth Tag Block 1874 All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and 1875 80 bit length tags as defined in [RFC3711]. 1877 Auth Tag Block | Meaning 1878 --------------------------------------------------- 1879 "HS32" | HMAC-SHA1 32 bit authentication 1880 | tag as defined in RFC 3711 1881 --------------------------------------------------- 1882 "HS80" | HMAC-SHA1 80 bit authentication 1883 | tag as defined in RFC 3711 1884 --------------------------------------------------- 1886 Table 4. Auth Tag Values 1888 6.1.5. Key Agreement Type Block 1890 All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and 1891 MAY support EC25, EC38, and EC52. 1893 If a ZRTP endpoint supports multiple concurrent media streams, such 1894 as audio and video, it MUST support Multistream (Section 5.4.2) mode. 1895 Also, if a ZRTP endpoint supports the GoClear message 1896 (Section 5.7.2), it SHOULD support Multistream, to be used if the two 1897 parties choose to return to the secure state after going Clear (as 1898 explained in Section 5.7.2.1). 1900 For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH 1901 parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the 1902 3072-bit MODP group. The DH generator g is 2. The random Diffie- 1903 Hellman secret exponent SHOULD be twice as long as the AES key 1904 length. If AES-128 is used, the DH secret value SHOULD be 256 bits 1905 long. If AES-256 is used, the secret value SHOULD be 512 bits long. 1907 If Elliptic Curve DH is used, the ECDH algorithm and key generation 1908 is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA 1909 Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by 1910 FIPS 186-3 [FIPS-186-3], and can also be found in RFC 4753 [RFC4753], 1911 sections 3.1 through 3.3. The validation procedures are from NIST SP 1912 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC Partial 1913 Validation. Both the X and Y coordinates of the point on the curve 1914 are sent, in the first and second half of the ECDH public value, 1915 respectively. 1917 The choice of AES key length is coupled to the choice of key 1918 agreement type. If either EC38 or EC52 is chosen as the key 1919 agreement, AES-256 (AES3) SHOULD be used. If DH3K or EC25 is chosen, 1920 either AES-128 (AES1) or AES-256 (AES3) MAY be used. 1922 ZRTP also defines two non-DH modes, Multistream and Preshared, in 1923 which the SRTP key is derived from a shared secret and some nonce 1924 material. 1926 Table 5 lists the pv length in words and DHPart1 and DHPart2 message 1927 length in words for each Key Agreement Type Block. 1929 Key Agreement | pv | message | Meaning 1930 Type Block | words | words | 1931 --------------------------------------------------- 1932 "DH3k" | 96 | 117 | DH mode with p=3072 bit prime 1933 | | | as defined in RFC 3526 1934 --------------------------------------------------- 1935 "Prsh" | - | - | Preshared Non-DH mode 1936 | | | 1937 --------------------------------------------------- 1938 "Mult" | - | - | Multistream Non-DH mode 1939 | | | 1940 --------------------------------------------------- 1941 "EC25" | 16 | 37 | Elliptic Curve DH, P-256 1942 | | | per RFC 4753, section 3.1 1943 --------------------------------------------------- 1944 "EC38" | 24 | 45 | Elliptic Curve DH, P-384 1945 | | | per RFC 4753, section 3.2 1946 --------------------------------------------------- 1947 "EC52" | 33 | 54 | Elliptic Curve DH, P-521 1948 | | | per RFC 4753, section 3.3 1949 --------------------------------------------------- 1951 Table 5. Key Agreement Block Type Values 1953 6.1.6. SAS Type Block 1955 All ZRTP endpoints MUST support the base32 and MAY support base256 1956 Short Authentication String scheme, and other SAS rendering schemes. 1957 The ZRTP SAS is described in Section 8. 1959 SAS Type Block | Meaning 1960 --------------------------------------------------- 1961 "B32 " | Short Authentication String using 1962 | base32 encoding defined in Section 8. 1963 --------------------------------------------------- 1964 "B256" | Short Authentication String using 1965 | base256 encoding defined in Section 8. 1966 --------------------------------------------------- 1968 Table 6. SAS Block Type Values 1970 The SAS Type determines how the SAS is rendered to the user so that 1971 the user may compare it with his partner over the voice channel. 1972 This allows detection of a man-in-the-middle (MITM) attack. 1974 6.1.7. Signature Type Block 1976 The signature type block is a 4 octet (1 word) block used to 1977 represent the signature algorithm discussed in Section 8.2. 1978 Suggested signature algorithms and key lengths are a future subject 1979 of standardization. 1981 6.2. Hello message 1983 The Hello message has the format shown in Figure 3. The Hello ZRTP 1984 message begins with the preamble value 0x505a then a 16 bit length in 1985 32 bit words. This length includes only the ZRTP message (including 1986 the preamble and the length) but not the ZRTP header or CRC. 1988 Next is the Message Type Block and a 4 character string containing 1989 the version (ver) of the ZRTP protocol, currently "0.95" (when this 1990 specification reaches RFC status, the protocol version will become 1991 "1.00"). Next is the Client Identifier string (cid) which is 4 words 1992 long and identifies the vendor and release of the ZRTP software. The 1993 256-bit hash image H3 is defined in Section 10. The next parameter 1994 is the ZID, the 96 bit long unique identifier for the ZRTP endpoint. 1996 The next four bits contains flag bits. The MiTM flag (M) is a 1997 boolean that is set to true if and only if this Hello message is sent 1998 from a device, usually a PBX, that has the capability to send an 1999 SASrelay message (Section 6.13). The Passive flag (P) is a Boolean 2000 normally set to False. A ZRTP endpoint which is configured to never 2001 initiate secure sessions is regarded as passive, and would set the P 2002 bit to True. The next 8 bits are unused. They should be set to zero 2003 when sent and ignored on receipt. 2005 Next is a list of supported Hash algorthms, Cipher algorithms, SRTP 2006 Auth Tag types, Key Agreement types, and SAS types. The number of 2007 listed algorithms are listed for each type: hc=hash count, cc=cipher 2008 count, ac=auth tag count, kc=key agreement count, and sc=sas count. 2009 The values for these algorithms are defined in Tables 2, 3, 4, 5, and 2010 6. A count of zero means that only the mandatory to implement 2011 algorithms are supported. Mandatory algorithms MAY be included in 2012 the list. The order of the list indicates the preferences of the 2013 endpoint. If a mandatory algorithm is not included in the list, it 2014 is added to the end of the list for preference. 2016 Note: Implementers are encouraged to keep these algorithm lists small 2017 - the list does not need to include every cipher and hash supported, 2018 just the ones the endpoint would prefer to use for this ZRTP 2019 exchange. 2021 The 64-bit HMAC at the end of the message is computed across the 2022 whole message, not including the HMAC, of course. The HMAC key is 2023 the sender's H2 (defined in Section 10), and thus the HMAC cannot be 2024 checked by the receiving party until the sender's H2 value is known 2025 to the receiving party later in the protocol. 2027 0 1 2 3 2028 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 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Message Type Block="Hello " (2 words) | 2033 | | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | version="0.95" (1 word) | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | | 2038 | Client Identifier (4 words) | 2039 | | 2040 | | 2041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2042 | | 2043 | Hash image H3 (8 words) | 2044 | . . . | 2045 | | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | | 2048 | ZID (3 words) | 2049 | | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 |0|0|M|P| unused (zeros)| hc | cc | ac | kc | sc | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | hash algorthms (0 to 7 values) | 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | cipher algorthms (0 to 7 values) | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | auth tag types (0 to 7 values) | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | key agreement types (0 to 7 values) | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | SAS types (0 to 7 values) | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | HMAC (2 words) | 2064 | | 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 Hello message format 2069 Figure 3: Hello message format 2071 6.3. HelloACK message 2073 The HelloACK message is used to stop retransmissions of a Hello 2074 message. A HelloACK is sent regardless if the version number in the 2075 Hello is supported or the algorithm list supported. The receipt of a 2076 HelloACK stops retransmission of the Hello message. The format is 2077 shown in the Figure below. Note that a Commit message can be sent in 2078 place of a HelloACK by an Initiator. 2080 0 1 2 3 2081 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 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | Message Type Block="HelloACK" (2 words) | 2086 | | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 HelloACK message format 2091 Figure 4: HelloACK message format 2093 6.4. Commit message 2095 The Commit message is sent to initiate the key agreement process 2096 after both sides have received a Hello message, which means it can 2097 only be sent after receiving both a Hello message and a HelloACK 2098 message. The Commit message contains the Initiator's ZID and a list 2099 of selected algorithms (hash, cipher, auth tag type, key agreement, 2100 sas type), and hvi, which is a hash of the DHPart2 of the Initiator 2101 and the Responder's Hello message, as explained in Section 5.4.1.1. 2102 The hash image H2 is defined in Section 10. The Commit Message 2103 formats are shown in Figure 5, Figure 6, and Figure 7. 2105 The 64-bit HMAC at the end of the message is computed across the 2106 whole message, not including the HMAC, of course. The HMAC key is 2107 the sender's H1 (defined in Section 10), and thus the HMAC cannot be 2108 checked by the receiving party until the sender's H1 value is known 2109 to the receiving party later in the protocol. 2111 0 1 2 3 2112 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 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Message Type Block="Commit " (2 words) | 2117 | | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | | 2120 | Hash image H2 (8 words) | 2121 | . . . | 2122 | | 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | | 2125 | ZID (3 words) | 2126 | | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | hash algorihm | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | cipher algorihm | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | auth tag type | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | key agreement type | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | SAS type | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | | 2139 | hvi (8 words) | 2140 | . . . | 2141 | | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | HMAC (2 words) | 2144 | | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 DH Commit message format 2149 Figure 5: DH Commit message format 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | Message Type Block="Commit " (2 words) | 2157 | | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 | | 2160 | Hash image H2 (8 words) | 2161 | . . . | 2162 | | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | | 2165 | ZID (3 words) | 2166 | | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | hash algorihm | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | cipher algorihm | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | auth tag type | 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | key agreement type = "Mult" | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | SAS type | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | | 2179 | nonce (4 words) | 2180 | . . . | 2181 | | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 | HMAC (2 words) | 2184 | | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 Multistream Commit message format 2189 Figure 6: Multistream Commit message format 2191 0 1 2 3 2192 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 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Message Type Block="Commit " (2 words) | 2197 | | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | | 2200 | Hash image H2 (8 words) | 2201 | . . . | 2202 | | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | | 2205 | ZID (3 words) | 2206 | | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | hash algorihm | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | cipher algorihm | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | auth tag type | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | key agreement type = "Prsh" | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | SAS type | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | | 2219 | nonce (4 words) | 2220 | . . . | 2221 | | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | keyID (2 words) | 2224 | | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | HMAC (2 words) | 2227 | | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 Preshared Commit message format 2232 Figure 7: Preshared Commit message format 2234 6.5. DHPart1 message 2236 The DHPart1 message begins the DH exchange. The format is shown in 2237 Figure 8 below. The DHPart1 message is sent by the Responder if a 2238 valid Commit message is received from the Initiator. The length of 2239 the pvr value and the length of the DHPart1 message depends on the 2240 Key Agreement Type chosen. This information is contained in Table 5. 2241 Note that for both Multistream and Preshared modes, no DHPart1 or 2242 DHPart2 message will be sent. 2244 The 256-bit hash image H1 is defined in Section 10. 2246 The next four parameters are HMACs of potential shared secrets used 2247 in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are 2248 the HMACs of the responder's two retained shared secrets, truncated 2249 to 64 bits. Next is auxsecretIDr, the HMAC of the responder's 2250 auxsecret (defined in Section 5.3), truncated to 64 bits. The last 2251 parameter is the HMAC of the trusted MiTM PBX shared secret 2252 pbxsecret, defined in Section 8.3.1. The Message format for the 2253 DHPart1 message is shown in Figure 8. 2255 The 64-bit HMAC at the end of the message is computed across the 2256 whole message, not including the HMAC, of course. The HMAC key is 2257 the sender's H0 (defined in Section 10), and thus the HMAC cannot be 2258 checked by the receiving party until the sender's H0 value is known 2259 to the receiving party later in the protocol. 2261 0 1 2 3 2262 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 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | Message Type Block="DHPart1 " (2 words) | 2267 | | 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 | | 2270 | Hash image H1 (8 words) | 2271 | . . . | 2272 | | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | rs1IDr (2 words) | 2275 | | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | rs2IDr (2 words) | 2278 | | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | auxsecretIDr (2 words) | 2281 | | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 | pbxsecretIDr (2 words) | 2284 | | 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | | 2287 | pvr (length depends on KA Type) | 2288 | . . . | 2289 | | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | HMAC (2 words) | 2292 | | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 DHPart1 message format 2297 Figure 8: DH Part1 message format 2299 6.6. DHPart2 message 2301 The DHPart2 message completes the DH exchange. A DHPart2 message is 2302 sent by the Initiator if a valid DHPart1 message is received from the 2303 Responder. The length of the pvr value and the length of the DHPart2 2304 message depends on the Key Agreement Type chosen. This information 2305 is contained in Table 5. Note that for both Multistream and 2306 Preshared modes, no DHPart1 or DHPart2 message will be sent. 2308 The 256-bit hash image H1 is defined in Section 10. 2310 The next four parameters are HMACs of potential shared secrets used 2311 in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are 2312 the HMACs of the initiator's two retained shared secrets, truncated 2313 to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's 2314 auxsecret (defined in Section 5.3), truncated to 64 bits. The last 2315 parameter is the HMAC of the trusted MiTM PBX shared secret 2316 pbxsecret, defined in Section 8.3.1. The message format for the 2317 DHPart2 message is shown in Figure 9. 2319 The 64-bit HMAC at the end of the message is computed across the 2320 whole message, not including the HMAC, of course. The HMAC key is 2321 the sender's H0 (defined in Section 10), and thus the HMAC cannot be 2322 checked by the receiving party until the sender's H0 value is known 2323 to the receiving party later in the protocol. 2325 0 1 2 3 2326 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 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Message Type Block="DHPart2 " (2 words) | 2331 | | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | | 2334 | Hash image H1 (8 words) | 2335 | . . . | 2336 | | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | rs1IDi (2 words) | 2339 | | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | rs2IDi (2 words) | 2342 | | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | auxsecretIDi (2 words) | 2345 | | 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | pbxsecretIDi (2 words) | 2348 | | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | | 2351 | pvi (length depends on KA Type) | 2352 | . . . | 2353 | | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 | HMAC (2 words) | 2356 | | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 DHPart2 message format 2361 Figure 9: DH Part2 message format 2363 6.7. Confirm1 and Confirm2 messages 2365 The Confirm1 message is sent by the Responder in response to a valid 2366 DHPart2 message after the SRTP session key and parameters have been 2367 negotiated. The Confirm2 message is sent by the Initiator in 2368 response to a Confirm1 message. The format is shown in Figure 10 2369 below. The message contains the Message Type Block "Confirm1" or 2370 "Confirm2". Next is the HMAC, a keyed hash over encrypted part of 2371 the message (shown enclosed by "===" in Figure 10). This HMAC is 2372 keyed and computed according to Section 5.6. The next 16 octets 2373 contain the CFB Initialization Vector. The rest of the message is 2374 encrypted using CFB and protected by the HMAC. 2376 The first field inside the encrypted region is the hash pre-image H0, 2377 which is defined in detail in Section 10. 2379 The next 15 bits are not used. They SHOULD be set to zero and MUST 2380 be ignored in received Confirm1 or Confirm2 messages. 2382 The next 9 bits contain the signature length. If no SAS signature 2383 (described in Section 8.2) is present, all bits are set to zero. The 2384 signature length is in words and includes the signature type block. 2385 If the calculated signature octet count is not a multiple of 4, zeros 2386 are added to pad it out to a word boundary. If no signature block is 2387 present, the overall length of the Confirm1 or Confirm2 Message will 2388 be set to 19 words. 2390 The next 8 bits are used for flags. Undefined flags are set to zero 2391 and ignored. Four flags are currently defined. The PBX Enrollment 2392 flag (E) is a Boolean bit defined in Section 8.3.1. The SAS Verified 2393 flag (V) is a Boolean bit defined in Section 8.1. The Allow Clear 2394 flag (A) is a Boolean bit defined in Section 5.7.2. The Disclosure 2395 Flag (D) is a Boolean bit defined in Section 12. The cache 2396 expiration interval is defined in Section 5.9. 2398 If the signature length (in words) is non-zero, a signature type 2399 block will be present along with a signature block. Next is the 2400 signature block. The signature block includes the key used to 2401 generate the signature (Section 8.2). 2403 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2404 full cipher block, and the final block is truncated to match the 2405 exact length of the encrypted data. The CFB Initialization Vector is 2406 a 128 bit random nonce. The block cipher algorithm and the key size 2407 is the same as what was negotiated for the media encryption. CFB is 2408 used to encrypt the part of the Confirm1 message beginning after the 2409 CFB IV to the end of the message (the encrypted region is enclosed by 2410 "======" in Figure 10). 2412 The responder uses the zrtpkeyr to encrypt the Confirm1 message. The 2413 initiator uses the zrtpkeyi to encrypt the Confirm2 message. 2415 0 1 2 3 2416 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 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | Message Type Block="Confirm1" or "Confirm2" (2 words) | 2421 | | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | HMAC (2 words) | 2424 | | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | | 2427 | CFB Initialization Vector (4 words) | 2428 | | 2429 | | 2430 +===============================================================+ 2431 | | 2432 | Hash pre-image H0 (8 words) | 2433 | . . . | 2434 | | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D| 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | cache expiration interval (1 word) | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | optional signature type block (1 word if present) | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | | 2443 | optional signature block (variable length) | 2444 | . . . | 2445 | | 2446 | | 2447 +===============================================================+ 2449 Confirm1 and Confirm2 message format 2451 Figure 10: Confirm1 and Confirm2 message format 2453 6.8. Conf2ACK message 2455 The Conf2ACK message is sent by the Responder in response to a valid 2456 Confirm2 message. The message format for the Conf2ACK is shown in 2457 the Figure below. The receipt of a Conf2ACK stops retransmission of 2458 the Confirm2 message. 2460 0 1 2 3 2461 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 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2465 | Message Type Block="Conf2ACK" (2 words) | 2466 | | 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2469 Conf2ACK message format 2471 Figure 11: Conf2ACK message format 2473 6.9. Error message 2475 The Error message is sent to terminate an in-process ZRTP key 2476 agreement exchange due to an error. The format is shown in the 2477 Figure below. The use of the Error message is described in 2478 Section 5.7.1. 2480 0 1 2 3 2481 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 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | Message Type Block="Error " (2 words) | 2486 | | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | Integer Error Code (1 word) | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 Error message format 2493 Figure 12: Error message format 2495 Defined hexadecimal values for the Error Code are listed in Table 7. 2497 Error Code | Meaning 2498 ----------------------------------------------------------- 2499 0x10 | Malformed packet (CRC OK, but wrong structure) 2500 ----------------------------------------------------------- 2501 0x20 | Critical software error 2502 ----------------------------------------------------------- 2503 0x30 | Unsupported ZRTP version 2504 ----------------------------------------------------------- 2505 0x40 | Hello components mismatch 2506 ----------------------------------------------------------- 2507 0x51 | Hash type not supported 2508 ----------------------------------------------------------- 2509 0x52 | Cipher type not supported 2510 ----------------------------------------------------------- 2511 0x53 | Public key exchange not supported 2512 ----------------------------------------------------------- 2513 0x54 | SRTP auth. tag not supported 2514 ----------------------------------------------------------- 2515 0x55 | SAS scheme not supported 2516 ----------------------------------------------------------- 2517 0x56 | No shared secret available, DH mode required 2518 ----------------------------------------------------------- 2519 0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1) 2520 ----------------------------------------------------------- 2521 0x62 | DH Error: hvi != hashed data 2522 ----------------------------------------------------------- 2523 0x63 | Received relayed SAS from untrusted MiTM 2524 ----------------------------------------------------------- 2525 0x70 | Auth. Error: Bad Confirm pkt HMAC 2526 ----------------------------------------------------------- 2527 0x80 | Nonce reuse 2528 ----------------------------------------------------------- 2529 0x90 | Equal ZIDs in Hello 2530 ----------------------------------------------------------- 2531 0x100 | GoClear packet received, but not allowed 2532 ----------------------------------------------------------- 2534 Table 7. ZRTP Error Codes 2536 6.10. ErrorACK message 2538 The ErrorACK message is sent in response to an Error message. The 2539 receipt of an ErrorACK stops retransmission of the Error message. 2540 The format is shown in the Figure below. 2542 0 1 2 3 2543 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 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Message Type Block="ErrorACK" (2 words) | 2548 | | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 ErrorACK message format 2553 Figure 13: ErrorAck message format 2555 6.11. GoClear message 2557 Support for the GoClear message is OPTIONAL in the protocol, and it 2558 is sent to switch from SRTP to RTP. The format is shown in the 2559 Figure below. The clear_hmac is used to authenticate the GoClear 2560 message so that bogus GoClear messages introduced by an attacker can 2561 be detected and discarded. The use of GoClear is described in 2562 Section 5.7.2. 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | Message Type Block="GoClear " (2 words) | 2570 | | 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | clear_hmac (2 words) | 2573 | | 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2576 GoClear message format 2578 Figure 14: GoClear message format 2580 6.12. ClearACK message 2582 Support for the ClearACK message is OPTIONAL in the protocol, and it 2583 is sent to acknowledge receipt of a GoClear. A ClearACK is only sent 2584 if the clear_hmac from the GoClear message is authenticated. 2585 Otherwise, no response is returned. The format is shown in the 2586 Figure below. 2588 0 1 2 3 2589 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 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | Message Type Block="ClearACK" (2 words) | 2594 | | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 ClearACK message format 2599 Figure 15: ClearAck message format 2601 6.13. SASrelay message 2603 The SASrelay message is sent by a trusted Man in The Middle (MiTM), 2604 most often a PBX. It is not sent as a response to a packet, but is 2605 sent as a self-initiated packet by the trusted MiTM. It can only be 2606 sent after the rest of the ZRTP key negotiations have completed, 2607 after the Confirm packets and their ACKs. It can only be sent after 2608 the trusted MiTM has finished key negotiations with the other party, 2609 because it is the other party's SAS that is being relayed. It is 2610 sent with retry logic until a RelayACK message (Section 6.14) is 2611 received or the retry schedule has been exhausted. 2613 If a device, usually a PBX, sends an SASrelay message, it MUST have 2614 previously declared itself as a MiTM device by setting the MiTM (M) 2615 flag in the Hello message (Section 6.2). If the receiver of the 2616 SASrelay message did not previously receive a Hello message with the 2617 MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A 2618 RelayACK is still sent, but no Error message is sent. 2620 The SASrelay message format is shown in Figure 16 below. The message 2621 contains the Message Type Block "SASrelay". Next is the HMAC, a 2622 keyed hash over encrypted part of the message (shown enclosed by 2623 "===" in Figure 16). This HMAC is keyed the same way as the HMAC in 2624 the Confirm messages (see Section 5.6). The next 16 octets contain 2625 the CFB Initialization Vector. The rest of the message is encrypted 2626 using CFB and protected by the HMAC. 2628 The next 15 bits are not used. They SHOULD be set to zero and MUST 2629 be ignored in received SASrelay messages. 2631 The next 9 bits contain the signature length. The trusted MiTM MAY 2632 compute a digital signature on the SAS hash, as described in 2633 Section 8.2, using a persistant signing key owned by the trusted 2634 MiTM. If no SAS signature is present, all bits are set to zero. The 2635 signature length is in words and includes the signature type block. 2637 If the calculated signature octet count is not a multiple of 4, zeros 2638 are added to pad it out to a word boundary. If no signature block is 2639 present, the overall length of the SASrelay Message will be set to 12 2640 words. 2642 The next 8 bits are used for flags. Undefined flags are set to zero 2643 and ignored. Three flags are currently defined. The Disclosure Flag 2644 (D) is a Boolean bit defined in Section 12. The Allow Clear flag (A) 2645 is a Boolean bit defined in Section 5.7.2. The SAS Verified flag (V) 2646 is a Boolean bit defined in Section 8.1. These flags are updated 2647 values to the same flags provided earlier in the Confirm packet, but 2648 they are updated to reflect the new flag information relayed by the 2649 PBX from the other party. 2651 The next 32 bit word contains the rendering scheme for the relayed 2652 sasvalue, which will be the same rendering scheme used by the other 2653 party on the other side of the trusted MiTM. Section 8.3 describes 2654 how the PBX determines whether the ZRTP client regards the PBX as a 2655 trusted MiTM. If the PBX determines that the ZRTP client trusts the 2656 PBX, the next 32 bit word contains the binary sasvalue relayed from 2657 the other party. If this SASrelay packet is being sent to a ZRTP 2658 client that does not trust this MiTM, the next 32 bit word will be 2659 ignored by the recipient and should be set to zero by the PBX. 2661 If the signature length (in words) is non-zero, a signature type 2662 block will be present along with a signature block. Next is the 2663 signature block. The signature block includes the key used to 2664 generate the signature (Section 8.2). 2666 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2667 full cipher block, and the final block is truncated to match the 2668 exact length of the encrypted data. The CFB Initialization Vector is 2669 a 128 bit random nonce. The block cipher algorithm and the key size 2670 is the same as what was negotiated for the media encryption. CFB is 2671 used to encrypt the part of the SASrelay message beginning after the 2672 CFB IV to the end of the message (the encrypted region is enclosed by 2673 "======" in Figure 16). 2675 Depending on whether the trusted MiTM had taken the role of the 2676 initiator or the responder during the ZRTP key negotiation, the 2677 SASrelay message is encrypted with zrtpkeyi or zrtpkeyr. 2679 0 1 2 3 2680 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 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | Message Type Block="SASrelay" (2 words) | 2685 | | 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | HMAC (2 words) | 2688 | | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | | 2691 | CFB Initialization Vector (4 words) | 2692 | | 2693 | | 2694 +===============================================================+ 2695 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D| 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | rendering scheme of relayed sasvalue (1 word) | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | Trusted MITM relayed sasvalue (1 word) | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | optional signature type block (1 word if present) | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | | 2704 | optional signature block (variable length) | 2705 | . . . | 2706 | | 2707 | | 2708 +===============================================================+ 2710 SASrelay message format 2712 Figure 16: SASrelay message format 2714 6.14. RelayACK message 2716 The RelayACK message is sent in response to a valid SASrelay message. 2717 The message format for the RelayACK is shown in the Figure below. 2718 The receipt of a RelayACK stops retransmission of the SASrelay 2719 message. 2721 0 1 2 3 2722 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 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | Message Type Block="RelayACK" (2 words) | 2727 | | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 RelayACK message format 2732 Figure 17: RelayACK message format 2734 7. Retransmissions 2736 ZRTP uses two retransmission timers T1 and T2. T1 is used for 2737 retransmission of Hello messages, when the support of ZRTP by the 2738 other endpoint may not be known. T2 is used in retransmissions of 2739 all the other ZRTP messages. 2741 All message retransmissions MUST be identical to the initial message 2742 including nonces, public values, etc; otherwise, hashes of the 2743 message sequences may not agree. 2745 Practical experience has shown that RTP packet loss at the start of 2746 an RTP session can be extremely high. Since the entire ZRTP message 2747 exchange occurs during this period, the defined retransmission scheme 2748 is defined to be aggressive. Since ZRTP packets with the exception 2749 of the DHPart1 and DHPart2 messages are small, this should have 2750 minimal effect on overall bandwidth utilization of the media session. 2752 ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media 2753 session as determined by the offer/answer exchange in the signaling 2754 layer. 2756 Hello ZRTP messages are retransmitted at an interval that starts at 2757 T1 seconds and doubles after every retransmission, capping at 200ms. 2758 T1 has a recommended initial value of 50 ms. A Hello message is 2759 retransmitted 20 times before giving up, which means the entire retry 2760 schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 2761 + 18*200 ms). Retransmission of a Hello ends upon receipt of a 2762 HelloACK or Commit message. 2764 The post-Hello ZRTP messages are retransmitted only by the session 2765 initiator - that is, only Commit, DHPart2, and Confirm2 are 2766 retransmitted if the corresponding message from the responder, 2767 DHPart1, Confirm1, and Conf2ACK, are not received. 2769 The GoClear, Error, and SASrelay messages may be initiated and 2770 retransmitted by either party, and responded to by the other party, 2771 regardless of which party is the overall session initiator. They are 2772 retransmitted if the corresponding response message ClearACK, 2773 ErrorACK, and RelayACK, are not received. 2775 Non-Hello ZRTP messages are retransmitted at an interval that starts 2776 at T2 seconds and doubles after every retransmission, capping at 2777 600ms. T2 has a recommended initial value of 150 ms. Each non-Hello 2778 message is retransmitted 10 times before giving up, which means the 2779 entire retry schedule is exhausted after 5.25 seconds (150 + 300 + 2780 8*600 ms). Only the initiator performs retransmissions. Each 2781 message has a response message that stops retransmissions, as shown 2782 below in Table 8. The higher values of T2 means that retransmissions 2783 will likely only occur with packet loss. 2785 These recommended retransmission intervals are designed for a typical 2786 broadband Internet connection. In some low bandwidth communication 2787 channels, such as those provided by some mobile phone environments, 2788 the initial value for the T1 or T2 retransmission timer should be 2789 increased to be no less than the round trip time provided by the 2790 communications channel. It should take into account the time 2791 required to transmit the entire message and the entire reply. 2793 Message Acknowledgement Message 2794 ------- ----------------------- 2795 Hello HelloACK or Commit 2796 Commit DHPart1 or Confirm1 2797 DHPart2 Confirm1 2798 Confirm2 Conf2ACK 2799 GoClear ClearACK 2800 Error ErrorACK 2801 SASrelay RelayACK 2803 Table 8. Retransmitted ZRTP Messages and Responses 2805 8. Short Authentication String 2807 This section will discuss the implementation of the Short 2808 Authentication String, or SAS in ZRTP. The SAS can be verbally 2809 verified by the human users reading the string aloud, or by 2810 validating an OPTIONAL digital signature (described in Section 8.2) 2811 exchanged in the Confirm1 or Confirm2 messages. 2813 The use of hash commitment in the DH exchange (Section 5.4.1.1) 2814 constrains the attacker to only one guess to generate the correct SAS 2815 in his attack, which means the SAS can be quite short. A 16-bit SAS, 2816 for example, provides the attacker only one chance out of 65536 of 2817 not being detected. 2819 The rendering of the SAS value to the user depends on the SAS Type 2820 agreed upon in the Commit message. For the SAS Type of base32, the 2821 leftmost 20 bits of the 32-bit sasvalue are rendered as a form of 2822 base32 encoding known as z-base-32 [z-base-32]. The purpose of 2823 z-base-32 is to represent arbitrary sequences of octets in a form 2824 that is as convenient as possible for human users to manipulate. As 2825 a result, the choice of characters is slightly different from base32 2826 as defined in RFC 3548. The leftmost 20 bits of the sasvalue results 2827 in four base32 characters which are rendered to both ZRTP endpoints. 2828 For the SAS Type of base256, the leftmost 16 bits of the 32-bit 2829 sasvalue are rendered using the PGP Wordlist [pgpwordlist] 2830 [Juola1][Juola2]. Other SAS Types may be defined to render the SAS 2831 value in other ways. 2833 The SAS SHOULD be rendered to the user for authentication. In 2834 addition, the SAS SHOULD be sent in a subsequent offer/answer 2835 exchange (a re-INVITE in SIP) after the completion of ZRTP exchange 2836 using the ZRTP SAS SDP attributes defined in Section 9. 2838 The SAS is not treated as a secret value, but it must be compared to 2839 see if it matches at both ends of the communications channel. The 2840 two users read it aloud to their partners to see if it matches. This 2841 allows detection of a man-in-the-middle (MITM) attack. 2843 There is only one SAS value computed per call. That is the SAS value 2844 for the first media stream established, which computes the ZRTPSess 2845 key, using DH mode. The ZRTPSess key is used to compute the SAS, as 2846 well as the SRTP session keys for each additional media stream in 2847 Multistream mode. This SAS applies to all media streams for the same 2848 call. 2850 8.1. SAS Verified Flag 2852 The SAS Verified flag (V) is set based on the user indicating that 2853 SAS comparison has been successfully performed. The SAS Verified 2854 flag is exchanged securely in the Confirm1 and Confirm2 messages 2855 (Figure 10) of the next session. In other words, each party sends 2856 the SAS Verified flag from the previous session in the Confirm 2857 message of the current session. It is perfectly reasonable to have a 2858 ZRTP endpoint that never sets the SAS Verified flag, because it would 2859 require adding complexity to the user interface to allow the user to 2860 set it. The SAS Verified flag is not required to be set, but if it 2861 is available to the client software, it allows for the possibility 2862 that the client software could render to the user that the SAS verify 2863 procedure was carried out in a previous session. 2865 Regardless of whether there is a user interface element to allow the 2866 user to set the SAS Verified flag, it is worth caching a shared 2867 secret, because doing so reduces opportunities for an attacker in the 2868 next call. 2870 If at any time the users carry out the SAS comparison procedure, and 2871 it actually fails to match, then this means there is a very 2872 resourceful man-in-the-middle. If this is the first call, the MITM 2873 was there on the first call, which is impressive enough. If it 2874 happens in a later call, it also means the MITM must also know the 2875 cached shared secret, because you could not have carried out any 2876 voice traffic at all unless the session key was correctly computed 2877 and is also known to the attacker. This implies the MITM must have 2878 been present in all the previous sessions, since the initial 2879 establishment of the first shared secret. This is indeed a 2880 resourceful attacker. It also means that if at any time he ceases 2881 his participation as a MITM on one of your calls, the protocol will 2882 detect that the cached shared secret is no longer valid -- because it 2883 was really two different shared secrets all along, one of them 2884 between Alice and the attacker, and the other between the attacker 2885 and Bob. The continuity of the cached shared secrets make it possible 2886 for us to detect the MITM when he inserts himself into the ongoing 2887 relationship, as well as when he leaves. Also, if the attacker tries 2888 to stay with a long lineage of calls, but fails to execute a DH MITM 2889 attack for even one missed call, he is permanently excluded. He can 2890 no longer resynchronize with the chain of cached shared secrets. 2892 Some sort of user interface element (maybe a checkbox) is needed to 2893 allow the user to tell the software the SAS verify was successful, 2894 causing the software to set the SAS Verified flag (V), which 2895 (together with our cached shared secret) obviates the need to perform 2896 the SAS procedure in the next call. An additional user interface 2897 element can be provided to let the user tell the software he detected 2898 an actual SAS mismatch, which indicates a MITM attack. The software 2899 can then take appropriate action, clearing the SAS Verified flag, and 2900 erase the cached shared secret from this session. It is up to the 2901 implementer to decide if this added user interface complexity is 2902 warranted. 2904 If the SAS matches, it means there is no MITM, which also implies it 2905 is now safe to trust a cached shared secret for later calls. If 2906 inattentive users don't bother to check the SAS, it means we don't 2907 know whether there is or is not a MITM, so even if we do establish a 2908 new cached shared secret, there is a risk that our potential attacker 2909 may have a subsequent opportunity to continue inserting himself in 2910 the call, until we finally get around to checking the SAS. If the 2911 SAS matches, it means no attacker was present for any previous 2912 session since we started propagating cached shared secrets, because 2913 this session and all the previous sessions were also authenticated 2914 with a continuous lineage of shared secrets. 2916 8.2. Signing the SAS 2918 In some applications, it may be hard to arrange for two human users 2919 to verbally compare the SAS. To handle these cases, ZRTP allows for 2920 an OPTIONAL signature feature, which allows the SAS to be checked 2921 without human participation. The SAS MAY be signed and the signature 2922 sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay 2923 (Figure 16) messages. The signature algorithm, length of the 2924 signature and the key used to create the signature are all sent along 2925 with the signature. The key types and signature algorithms are for 2926 future study. The signature is calculated over the entire SAS hash 2927 result (sashash) that was truncated down to derive the sasvalue. The 2928 signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay 2929 messages MAY be used to authenticate the ZRTP exchange. 2931 8.3. Relaying the SAS through a PBX 2933 ZRTP is designed to use end-to-end encryption. The two parties' 2934 verbal comparison of the short authentication string (SAS) depends on 2935 this assumption. But in some PBX environments, such as Asterisk, 2936 there are usage scenarios that have the PBX acting as a trusted man- 2937 in-the-middle (MiTM), which means there are two back-to-back ZRTP 2938 connections with separate session keys and separate SAS's. 2940 For example, imagine that Bob has a ZRTP-enabled VoIP phone that has 2941 been registered with his company's PBX, so that it is regarded as an 2942 extension of the PBX. Alice, whose phone is not associated with the 2943 PBX, might dial the PBX from the outside, and a ZRTP connection is 2944 negotiated between her phone and the PBX. She then selects Bob's 2945 extension from the company directory in the PBX. The PBX makes a 2946 call to Bob's phone (which might be offsite, many miles away from the 2947 PBX through the Internet) and a separate ZRTP connection is 2948 negotiated between the PBX and Bob's phone. The two ZRTP sessions 2949 have different session keys and different SAS's, which would render 2950 the SAS useless for verbal comparison between Alice and Bob. They 2951 might even mistakenly believe that a wiretapper is present because of 2952 the SAS mismatch, causing undue alarm. 2954 ZRTP has a mechanism for solving this problem by having the PBX relay 2955 the Alice/PBX SAS to Bob, sending it through to Bob in a special 2956 SASrelay packet as defined in Section 6.13, which is sent after the 2957 PBX/Bob ZRTP negotiation is complete, after the Confirm packets. 2958 Only the PBX, acting as a special trusted MiTM (trusted by the 2959 recipient of the SAS relay packet), will relay the SAS. The SASrelay 2960 packet protects the relayed SAS from tampering via an included HMAC, 2961 similar to how the Confirm packet is protected. Bob's ZRTP-enabled 2962 phone accepts the relayed SAS for rendering only because Bob's phone 2963 had previously been configured to trust the PBX. This special 2964 trusted relationship with the PBX can be established through a 2965 special security enrollment procedure. After that enrollment 2966 procedure, the PBX is treated by Bob as a special trusted MiTM. This 2967 results in Alice's SAS being rendered to Bob, so that Alice and Bob 2968 may verbally compare them and thus prevent a MiTM attack by any other 2969 untrusted MiTM. 2971 A real bad-guy MiTM cannot exploit this protocol feature to mount a 2972 MiTM attack and relay Alice's SAS to Bob, because Bob has not 2973 previously carried out a special registration ritual with the bad 2974 guy. The relayed SAS would not be rendered by Bob's phone, because 2975 it did not come from a trusted PBX. The recognition of the special 2976 trust relationship is achieved with the prior establishment of a 2977 special shared secret between Bob and his PBX, which is called 2978 pbxsecret (defined in Section 8.3.1), also known as the trusted MiTM 2979 key. 2981 The trusted MiTM key can be stored in a special cache at the time of 2982 the initial enrollment (which is carried out only once for Bob's 2983 phone), and Bob's phone associates this key with the ZID of the PBX, 2984 while the PBX associates it with the ZID of Bob's phone. After the 2985 enrollment has established and stored this trusted MiTM key, it can 2986 be detected during subsequent ZRTP call negotiations between the PBX 2987 and Bob's phone, because the PBX and the phone MUST pass the hash of 2988 the trusted MiTM key in the DH packet. It is then used as part of 2989 the key agreement to calculate s0. 2991 The PBX can determine whether it is trusted by the ZRTP user agent of 2992 the caller or callee. The presence of a shared trusted MiTM key in 2993 the key negotiation sequence indicates that the phone has been 2994 enrolled with this PBX and therefore trusts it to act as a trusted 2995 MiTM. The PBX SHOULD relay the SAS from the other party in this 2996 case. 2998 The relayed SAS fields contain the SAS rendering type and the binary 2999 32-bit sasvalue. The receiver absolutely MUST NOT render the relayed 3000 SAS if it does not come from a specially trusted ZRTP endpoint. The 3001 security of the ZRTP protocol depends on not rendering a relayed SAS 3002 from an untrusted MiTM, because it may be relayed by a MiTM attacker. 3003 See the SASrelay packet definition (Figure 16) for further details. 3005 To ensure that both Alice and Bob will use the same SAS rendering 3006 scheme after the keys are negotiated, the PBX also sends the SASrelay 3007 message to the unenrolled party (which does not regard this PBX as a 3008 trusted MiTM), conveying the SAS rendering scheme, but not the SAS 3009 value, which it sets to zero. The unenrolled party will ignore the 3010 relayed SAS field, but will use the specified SAS rendering scheme. 3012 The next section describes the initial enrollment procedure that 3013 establishes a special shared secret between the PBX and Bob's phone, 3014 a trusted MiTM key, so that the phone will learn to recognize the PBX 3015 as a trusted MiTM. 3017 8.3.1. PBX Enrollment and the PBX Enrollment Flag 3019 Both the PBX and the endpoint need to know when enrollment is taking 3020 place. One way of doing this is to setup an enrollment extension on 3021 the PBX which a newly configured endpoint would call and establish a 3022 ZRTP session. The PBX would then play audio media that offers the 3023 user an opportunity to configure his phone to trust this PBX as a 3024 trusted MiTM. The PBX calculates and stores the trusted MiTM shared 3025 secret in its cache and associates it with this phone, indexed by the 3026 phone's ZID. The trusted MiTM PBX shared secret is calculated this 3027 way: 3029 pbxsecret = HMAC(ZRTPSess,"Trusted MiTM key") 3031 The PBX signals the enrollment process by setting the PBX Enrollment 3032 flag (E) in the Confirm message (Figure 10). This flag is used to 3033 trigger the ZRTP endpoint's user interface to prompt the user if they 3034 want to trust this PBX and calculate and store the pbxsecret in the 3035 cache. If the user decides to respond by activating the appropriate 3036 user interface element (a menu item, checkbox, or button), his ZRTP 3037 user agent calculates pbxsecret using the same formula and saves it 3038 in a special cache entry associated with this PBX. 3040 If the user elects not to enroll, perhaps because he dialed a wrong 3041 number or does not yet feel comfortable with this PBX, he can simply 3042 hang up and not save the pbxsecret in his cache. The PBX will have 3043 it saved in the PBX cache, but that will do no harm. The SASrelay 3044 scheme does not depend on the PBX trusting the phone. It only 3045 depends on the phone trusting the PBX. It is the phone (the user) 3046 who is at risk if the PBX abuses its MiTM privileges. 3048 After this enrollment process, the PBX and the ZRTP-enabled phone 3049 both share a secret that enables the phone to recognize the PBX as a 3050 trusted MiTM in future calls. This means that when a future call 3051 from an outside ZRTP-enabled caller is relayed through the PBX to 3052 this phone, the phone will render a relayed SAS from the PBX. If the 3053 SASrelay packet comes from a MiTM which does not know the pbxsecret, 3054 the phone treats it as a "bad guy" MiTM, and refuses to render the 3055 relayed SAS. Regardless of which party initiates any future phone 3056 calls through the PBX, the enrolled phone or the outside phone, the 3057 PBX will relay the SAS to the enrolled phone. 3059 There are other ways that ZRTP user agents can be configured to trust 3060 a PBX. Perhaps the pbxsecret can be configured into the phone by 3061 some automated provisioning process in large IT environments. This 3062 specification does not require that products be configured solely by 3063 this enrollment process. Any process that results in a pbxsecret to 3064 be computed and shared between the PBX and the phone will suffice. 3065 This is one such method that has been shown to work. 3067 9. Signaling Interactions 3069 This section discusses how ZRTP, SIP, and SDP work together. 3071 Note that ZRTP may be implemented without coupling with the SIP 3072 signaling. For example, ZRTP can be implemented as a "bump in the 3073 wire" or as a "bump in the stack" in which RTP sent by the SIP UA is 3074 converted to ZRTP. In these cases, the SIP UA will have no knowledge 3075 of ZRTP. As a result, the signaling path discovery mechanisms 3076 introduced in this section should not be definitive - they are a 3077 hint. Despite the absence of an indication of ZRTP support in an 3078 offer or answer, a ZRTP endpoint SHOULD still send Hello messages. 3080 ZRTP endpoints which have control over the signaling path include a 3081 ZRTP SDP attributes in their SDP offers and answers. The ZRTP 3082 attribute, a=zrtp-hash is used to indicate support for ZRTP and to 3083 convey a hash of the Hello message. The hash is computed according 3084 to Section 9.1. 3086 Aside from the advantages described in Section 9.1, there are a 3087 number of potential uses for this attribute. It is useful when 3088 signaling elements would like to know when ZRTP may be utilized by 3089 endpoints. It is also useful if endpoints support multiple methods 3090 of SRTP key management. The ZRTP attribute can be used to ensure 3091 that these key management approaches work together instead of against 3092 each other. For example, if only one endpoint supports ZRTP but both 3093 support another method to key SRTP, then the other method will be 3094 used instead. When used in parallel, an SRTP secret carried in an 3095 a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a 3096 shared secret for the srtps computation defined in Section 9.2. The 3097 ZRTP attribute is also used to signal to an intermediary ZRTP device 3098 not to act as a ZRTP endpoint, as discussed in Section 11. 3100 The a=zrtp-hash attribute can only be included at a media level since 3101 Hello messages sent in different media streams will have unique 3102 hashes. 3104 The ABNF for the ZRTP attribute is as follows: 3106 zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value 3108 zrtp-version = token 3110 zrtp-hash-value = 1*(HEXDIG) 3112 Example of the ZRTP attribute in an initial SDP offer or answer used 3113 at the session level: 3115 v=0 3116 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 3117 s= 3118 c=IN IP4 client.biloxi.example.com 3119 t=0 0 3120 m=audio 3456 RTP/AVP 97 33 3121 a=rtpmap:97 iLBC/8000 3122 a=rtpmap:33 no-op/8000 3123 a=zrtp-hash:1.00 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df 3125 9.1. Binding the media stream to the signaling layer via the Hello Hash 3127 It is desirable to tie the media stream to the signaling channel to 3128 prevent a third party from inserting false media packets. If the 3129 signaling layer contains information that ties it to the media 3130 stream, false media streams can be rejected. 3132 To accomplish this, a 256-bit hash (using the hash algorithm defined 3133 in Section 6.1.2.1) is computed across the entire ZRTP Hello message 3134 (as shown in Figure 3). This hash image is made available to the 3135 signaling layer, where it is transmitted as a hexadecimal value in 3136 the SIP channel using the SDP attribute, a=zrtp-hash defined in this 3137 specification. Each media stream (audio or video) will have a 3138 separate Hello packet, and thus will require a separate a=zrtp-hash 3139 in an SDP attribute. The recipient of the SIP/SDP message can then 3140 use this hash image to detect and reject false Hello packets in the 3141 media channel, as well as identify which media stream is associated 3142 with this SIP call. Each Hello packet hashes uniquely, because it 3143 contains the H3 field derived from a random nonce, defined in 3144 Section 10. 3146 The Hello Hash as an SDP attribute is an OPTIONAL feature, because 3147 some ZRTP endpoints do not have the ability to add SDP attributes to 3148 the signaling. For example, if ZRTP is implemented in a hardware 3149 bump-in-the-wire device, it might only have the ability to modify the 3150 media packets, not the SIP packets, especially if the SIP packets are 3151 integrity protected and thus cannot be modified on the wire. If the 3152 SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP 3153 user agent cannot check it, and thus will not be able to reject Hello 3154 messages based on this hash. 3156 After the Hello Hash is used to properly identify the ZRTP Hello 3157 message as belonging to this particular SIP call, the rest of the 3158 ZRTP message sequence is protected from false packet injection by 3159 other protection mechanisms. For example, the use of the total_hash 3160 in the shared secret calculation, and also the hash chaining 3161 mechanism defined in Section 10. 3163 An attacker who controls only the signaling layer, such as an 3164 uncooperative VoIP service provider, may be able to deny service by 3165 corrupting the hash of the Hello message in the SDP attribute, which 3166 would force ZRTP to reject perfectly good Hello messages. If there 3167 is reason to believe this is happening, the ZRTP endpoint MAY allow 3168 Hello messages to be accepted that do not match the hash image in the 3169 SDP attribute. 3171 Even in the absence of SIP integrity protection, the inclusion of the 3172 a=zrtp-hash SDP attribute, when coupled with the hash chaining 3173 mechanism defined in Section 10, meets the R-ASSOC requirement in the 3174 Media Security Requirements 3175 [I-D.ietf-sip-media-security-requirements], which requires: 3177 "...a mechanism for associating key management messages with both 3178 the signaling traffic that initiated the session and with 3179 protected media traffic. Allowing such an association also allows 3180 the SDP offerer to avoid performing CPU-consuming operations 3181 (e.g., Diffie-Hellman or public key operations) with attackers 3182 that have not seen the signaling messages." 3184 The a=zrtp-hash SDP attribute becomes especially useful if the SDP is 3185 integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474] 3186 or better still, Dan Wing's SIP Identity using Media Path 3187 [I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM 3188 attacks independent of ZRTP's SAS mechanism, as explained in 3189 Section 9.1.1 below. 3191 9.1.1. Integrity-protected signaling enables integrity-protected DH 3192 exchange 3194 If and only if the signaling path and the SDP is protected by some 3195 form of end-to-end integrity protection, such as one of the 3196 abovementioned mechanisms, so that it can guarantee delivery of the 3197 a=zrtp-hash attribute without any tampering by a third party, and if 3198 there is good reason to trust the signaling layer to protect the 3199 interests of the end user, it is possible to authenticate the key 3200 exchange and prevent a MiTM attack. This can be done without 3201 requiring the users to verbally compare the SAS, by using the hash 3202 chaining mechanism defined in Section 10 to provide a series of HMAC 3203 keys that protect the entire ZRTP key exchange. Thus, an end-to-end 3204 integrity-protected signaling layer automatically enables an 3205 integrity-protected Diffie-Hellman exchange in ZRTP, which in turn 3206 means immunity from a MiTM attack. Here's how it works. 3208 The integrity-protected SIP SDP contains a hash commitment to the 3209 entire Hello message. The Hello message contains H3, which provides 3210 a hash commitment for the rest of the hash chain H0-H2 (Section 10). 3211 The Hello message is protected by a 64-bit HMAC, keyed by H2. The 3212 Commit message is protected by a 64-bit HMAC keyed by H1. The 3213 DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by 3214 H0. The HMAC protecting the Confirm messages are computed by a 3215 different HMAC key derived from the resulting key agreement. Each 3216 message's HMAC is checked when the HMAC key is received in the next 3217 message. If a bad HMAC is discovered, it MUST be treated as a 3218 security exception indicating a MiTM attack, perhaps by logging or 3219 alerting the user. It MUST NOT be treated as a random error. Random 3220 errors are already discovered and quietly rejected by bad CRCs 3221 (Figure 2). 3223 The Hello message must be assembled before any hash algorithms are 3224 negotiated, so an implicit predetermined hash algorthm and HMAC 3225 algorthm (both defined in Section 6.1.2.1) must be used. All of the 3226 aforementioned HMACs keyed by the hashes in the aforementioned hash 3227 chain MUST be computed with the HMAC algorithm defined in 3228 Section 6.1.2.1, with the HMAC truncated to 64 bits. 3230 The Media Security Requirements 3231 [I-D.ietf-sip-media-security-requirements] R-EXISTING requirement can 3232 be fully met by leveraging a certificate-backed PKI in the signaling 3233 layer to integrity-protect the delivery of the a=zrtp-hash SDP 3234 attribute. This would thereby protect ZRTP against a MiTM attack, 3235 without requiring the user to check the SAS, without adding any 3236 explicit signatures or signature keys to the ZRTP key exchange, and 3237 without any extra public key operations or extra packets. 3239 Without an end-to-end integrity protection mechanism in the signaling 3240 layer to guarantee delivery of the a=zrtp-hash SDP attribute without 3241 modification by a third party, these HMACs alone will not prevent a 3242 MiTM attack. In that case, ZRTP's built-in SAS mechanism will still 3243 have to be used to authenticate the key exchange. At the time of 3244 this writing, very few deployed VoIP clients offer a fully 3245 implemented SIP stack that provides end-to-end integrity protection 3246 for the delivery of SDP attributes. Also, end-to-end signaling 3247 integrity becomes more problematic if E.164 numbers [RFC3824] are 3248 used in SIP. Thus, real-world implementations of ZRTP endpoints will 3249 continue to depend on SAS authentication for quite some time. Even 3250 after there is widespread availability of SIP user agents that offer 3251 integrity protected delivery of SDP attributes, many users will still 3252 be faced with the fact that the signaling path may be controlled by 3253 institutions that do not have the best interests of the end user in 3254 mind. In those cases, SAS authentication will remain the gold 3255 standard for the prudent user. 3257 Even without SIP integrity protection, the Media Security 3258 Requirements [I-D.ietf-sip-media-security-requirements] R-ACT-ACT 3259 requirement can be met by ZRTP's SAS mechanism. Although ZRTP may 3260 benefit from an integrity-protected SIP layer, it is fortunate that 3261 ZRTP's self-contained MiTM defenses do not actually require an 3262 integrity-protected SIP layer. ZRTP can bypass the delays and 3263 problems that SIP integrity faces, such as E.164 number usage, and 3264 the complexity of building and maintaining a PKI. 3266 In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend 3267 heavily on end-to-end integrity protection in the SIP layer. 3268 Further, DTLS-SRTP must bear the additional cost of a signature 3269 calculation of its own, in addition to the signature calculation the 3270 SIP layer uses to achieve its integrity protection. ZRTP needs no 3271 signature calculation of its own to leverage the signature 3272 calculation carried out in the SIP layer. 3274 9.2. Deriving the SRTP secret (srtps) from the signaling layer 3276 The shared secret calculations defined in Section 5.3 make use of the 3277 SRTP secret (srtps), if it is provided by the signaling layer. 3279 It is desirable for only one SRTP key negotiation protocol to be 3280 used, and that protocol should be ZRTP. But in the event the 3281 signaling layer negotiates its own SRTP master key and salt, using 3282 the SDES [RFC4568] or [RFC4567], it can be passed from the signaling 3283 to the ZRTP layer and mixed into ZRTP's own shared secret 3284 calculations, without compromising security by creating a dependency 3285 on the signaling for media encryption. 3287 ZRTP computes srtps from the SRTP master key and salt parameters 3288 provided by the signaling layer in this manner: 3290 srtps = hash(SRTP master key | SRTP master salt) 3292 It is expected that the srtps parameter will be rarely computed or 3293 used in typical ZRTP endpoints, because it is likely and desirable 3294 that ZRTP will be the sole means of negotiating SRTP keys, needing no 3295 help from SDES [RFC4568] or [RFC4567]. If srtps is computed, it will 3296 be stored in the auxiliary shared secret auxsecret, defined in 3297 Section 5.3, and used in Section 5.3.1 and Section 5.3.2. 3299 9.3. Codec Selection for Secure Media 3301 Codec selection is negotiated in the signaling layer. If the 3302 signaling layer determines that ZRTP is supported by both endpoints, 3303 this should provide guidance in codec selection to avoid VBR codecs 3304 that leak information. 3306 When voice is compressed with a variable bit-rate (VBR) codec, the 3307 packet lengths vary depending on the types of sounds being 3308 compressed. This leaks a lot of information about the content even 3309 if the packets are encrypted, regardless of what encryption protocol 3310 is used [Wright1]. It is RECOMMENDED that VBR codecs be avoided in 3311 encrypted calls. It's not a problem if the codec adapts the bit rate 3312 to the available channel bandwidth. The vulnerable codecs are the 3313 ones that change their bit rate depending on the type of sound being 3314 compressed. 3316 It also appears that voice activity detection (VAD) leaks information 3317 about the content of the conversation, but to a lesser extent than 3318 VBR. This effect can be ameliorated by lengthening the VAD hangover 3319 time by about 1 to 2 seconds, if this is feasible in your 3320 application. This is a topic that requires further study. 3322 10. False ZRTP Packet Rejection 3324 An attacker who is not in the media path may attempt to inject false 3325 ZRTP protocol packets, possibly to effect a denial of service attack, 3326 or to inject his own media stream into the call. VoIP by its nature 3327 invites various forms of denial of service attacks and requires 3328 protocol features to reject such attacks. While bogus SRTP packets 3329 may be easily rejected via the SRTP auth tag field, that can only be 3330 applied after a key agreement is completed. During the ZRTP key 3331 negotiation phase, other false packet rejection mechanisms are 3332 needed. One such mechanism is the use of the total_hash in the final 3333 shared secret calculation, but that can only detect false packets 3334 after performing the computationally expensive Diffie-Hellman 3335 calculation. 3337 The VoIP developer community expects to see a lot of denial of 3338 service attacks, especially from attackers who are not in the media 3339 path. Such an attacker might inject false ZRTP packets to force a 3340 ZRTP endpoint to engage in an endless series of pointless and 3341 expensive DH calculations. To detect and reject false packets 3342 cheaply and rapidly as soon as they are received, ZRTP uses a hash 3343 chain, which is a series of successive hash images. Before each 3344 session, the following values are computed: 3346 H0 = 256-bit random nonce (different for each party) 3347 H1 = hash (H0) 3348 H2 = hash (H1) 3349 H3 = hash (H2) 3351 The hash chain MUST use the hash algorithm defined in 3352 Section 6.1.2.1. Each 256-bit hash image is the pre-image of the 3353 next, and the sequence of images is sent in reverse order in the ZRTP 3354 packet sequence. The hash image H3 is sent in the Hello packet, H2 3355 is sent in the Commit packet, H1 is sent in the DHPart1 or DHPart2 3356 packets, and H0 is sent in the Confirm1 or Confirm2 packets. The 3357 initial random H0 nonces that each party generates MUST be 3358 unpredictable to an attacker and unique within a ZRTP call, which 3359 thereby forces the derived hash images H1-H3 to also be unique and 3360 unpredictable. 3362 The recipient checks if the packet has the correct hash pre-image, by 3363 hashing it and comparing the result with the hash image for the 3364 preceding packet. Packets which contain an incorrect hash pre-image 3365 MUST NOT be used by the recipient, but MAY be processed as security 3366 exceptions, perhaps by logging or alerting the user. As long as 3367 these bogus packets are not used, and correct packets are still being 3368 received, the protocol SHOULD be allowed to run to completion, 3369 thereby rendering ineffective this denial of service attack. 3371 Because these hash images alone do not protect the rest of the 3372 contents of the packet they reside in, this scheme assumes the 3373 attacker cannot modify the packet contents from a legitimate party, 3374 which is a reasonable assumption for an attacker who is not in the 3375 media path. This covers an important range of denial-of-service 3376 attacks. For dealing with the remaining set of attacks that involve 3377 packet modification, other mechanisms are used, such as the 3378 total_hash in the final shared secret calculation, and the hash 3379 commitment in the Commit packet. 3381 False Hello packets may be detected and rejected by the mechanism 3382 defined in Section 9.1. This mechanism requires that each Hello 3383 packet be unique, and the inclusion of the H3 hash image meets that 3384 requirement. 3386 If and only if an integrity-protected signaling channel is available, 3387 this hash chaining scheme can be used to key HMACs to authenticate 3388 the entire ZRTP key exchange, and thereby prevent a MiTM attack, 3389 without relying on the users verbally comparing the SAS. See 3390 Section 9.1.1 for details. 3392 Some ZRTP user agents allow the user to manually switch to clear mode 3393 (via the GoClear packet) in the middle of a secure call, and then 3394 later initiate secure mode again. Many consumer client products will 3395 omit this feature, but those that allow it may return to secure mode 3396 again in the same media stream. Although the same chain of hash 3397 images will be re-used and thus rendered ineffective the second time, 3398 no real harm is done because the new SRTP session keys will be 3399 derived in part from a cached shared secret, which was safely 3400 protected from the MiTM in the previous DH exchange earlier in the 3401 same call. 3403 11. Intermediary ZRTP Devices 3405 This section discusses the operation of a ZRTP endpoint which is 3406 actually an intermediary. For example, consider a device which 3407 proxies both signaling and media between endpoints. There are three 3408 possible ways in which such a device could support ZRTP. 3410 An intermediary device can act transparently to the ZRTP protocol. 3411 To do this, a device MUST pass RTP header extensions and payloads (to 3412 allow the ZRTP Flag) and non-RTP protocols multiplexed on the same 3413 port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED 3414 behavior for intermediaries as ZRTP and SRTP are best when done end- 3415 to-end. 3417 An intermediary device could implement the ZRTP protocol and act as a 3418 ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary 3419 device. The intermediary could determine on a call-by-call basis 3420 whether the endpoint behind it supports ZRTP based on the presence or 3421 absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP 3422 endpoints, the intermediary device could act as the ZRTP endpoint 3423 using its own ZID and cache. This approach SHOULD only be used when 3424 there is some other security method protecting the confidentiality of 3425 the media between the intermediary and the inside endpoint, such as 3426 IPSec or physical security. 3428 The third mode, which is NOT RECOMMENDED, is for the intermediary 3429 device to attempt to back-to-back the ZRTP protocol. The only 3430 exception to this case is where the intermediary device is a trusted 3431 element providing services to one of the endpoints - e.g. a Private 3432 Branch Exchange or PBX. In this mode, the intermediary would attempt 3433 to act as a ZRTP endpoint towards both endpoints of the media 3434 session. This approach MUST NOT be used except as described in 3435 Section 8.3 as it will always result in a detected man-in-the-middle 3436 attack and will generate alarms on both endpoints and likely result 3437 in the immediate termination of the session. 3439 In cases where centralized media mixing is taking place, the SAS will 3440 not match when compared by the humans. However, this situation is 3441 known in the SIP signaling by the presence of the isfocus feature tag 3442 [RFC4579]. As a result, when the isfocus feature tag is present, the 3443 DH exchange can be authenticated by the mechanism defined in 3444 Section 9.1.1 or by validating signatures (Section 8.2) in the 3445 Confirm or SASrelay messages. For example, consider a audio 3446 conference call with three participants Alice, Bob, and Carol hosted 3447 on a conference bridge in Dallas. There will be three ZRTP encrypted 3448 media streams, one encrypted stream between each participant and 3449 Dallas. Each will have a different SAS. Each participant will be 3450 able to validate their SAS with the conference bridge by using 3451 signatures optionally present in the Confirm messages (described in 3452 Section 8.2). Or, if the signaling path has end-to-end integrity 3453 protection, each DH exchange will have automatic MiTM protection by 3454 using the mechanism in Section 9.1.1. 3456 SIP feature tags can also be used to detect if a session is 3457 established with an automaton such as an IVR, voicemail system, or 3458 speech recognition system. The display of SAS strings to users 3459 should be disabled in these cases. 3461 It is possible that an intermediary device acting as a ZRTP endpoint 3462 might still receive ZRTP Hello and other messages from the inside 3463 endpoint. This could occur if there is another inline ZRTP device 3464 which does not include the ZRTP SDP attribute flag. If this occurs, 3465 the intermediary MUST NOT pass these ZRTP messages if it is acting as 3466 the ZRTP endpoint. 3468 12. The ZRTP Disclosure flag 3470 There are no back doors defined in the ZRTP protocol specification. 3471 The designers of ZRTP would like to discourage back doors in ZRTP- 3472 enabled products. However, despite the lack of back doors in the 3473 actual ZRTP protocol, it must be recognized that a ZRTP implementer 3474 might still deliberately create a rogue ZRTP-enabled product that 3475 implements a back door outside the scope of the ZRTP protocol. For 3476 example, they could create a product that discloses the SRTP session 3477 key generated using ZRTP out-of-band to a third party. They may even 3478 have a legitimate business reason to do this for some customers. 3480 For example, some environments have a need to monitor or record 3481 calls, such as stock brokerage houses who want to discourage insider 3482 trading, or special high security environments with special needs to 3483 monitor their own phone calls. We've all experienced automated 3484 messages telling us that "This call may be monitored for quality 3485 assurance". A ZRTP endpoint in such an environment might 3486 unilaterally disclose the session key to someone monitoring the call. 3487 ZRTP-enabled products that perform such out-of-band disclosures of 3488 the session key can undermine public confidence in the ZRTP protocol, 3489 unless we do everything we can in the protocol to alert the other 3490 user that this is happening. 3492 If one of the parties is using a product that is designed to disclose 3493 their session key, ZRTP requires them to confess this fact to the 3494 other party through a protocol message to the other party's ZRTP 3495 client, which can properly alert that user, perhaps by rendering it 3496 in a graphical user interface. The disclosing party does this by 3497 sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as 3498 described in Section 6.7. 3500 Note that the intention here is to have the Disclosure flag identify 3501 products that are designed to disclose their session keys, not to 3502 identify which particular calls are compromised on a call-by-call 3503 basis. This is an important legal distinction, because most 3504 government sanctioned wiretap regulations require a VoIP service 3505 provider to not reveal which particular calls are wiretapped. But 3506 there is nothing illegal about revealing that a product is designed 3507 to be wiretap-friendly. The ZRTP protocol mandates that such a 3508 product "out" itself. 3510 You might be using a ZRTP-enabled product with no back doors, but if 3511 your own graphical user interface tells you the call is (mostly) 3512 secure, except that the other party is using a product that is 3513 designed in such a way that it may have disclosed the session key for 3514 monitoring purposes, you might ask him what brand of secure telephone 3515 he is using, and make a mental note not to purchase that brand 3516 yourself. If we create a protocol environment that requires such 3517 back-doored phones to confess their nature, word will spread quickly, 3518 and the "invisible hand" of the free market will act. The free 3519 market has effectively dealt with this in the past. 3521 Of course, a ZRTP implementer can lie about his product having a back 3522 door, but the ZRTP standard mandates that ZRTP-compliant products 3523 MUST adhere to the requirement that a back door be confessed by 3524 sending the Disclosure flag to the other party. 3526 There will be inevitable comparisons to Steve Bellovin's 2003 April 3527 fool's joke, when he submitted RFC 3514 [RFC3514] which defined the 3528 "Evil bit" in the IPV4 header, for packets with "evil intent". But 3529 we submit that a similar idea can actually have some merit for 3530 securing VoIP. Sure, one can always imagine that some implementer 3531 will not be fazed by the rules and will lie, but they would have lied 3532 anyway even without the Disclosure flag. There are good reasons to 3533 believe that it will improve the overall percentage of 3534 implementations that at least tell us if they put a back door in 3535 their products, and may even get some of them to decide not to put in 3536 a back door at all. From a civic hygiene perspective, we are better 3537 off with having the Disclosure flag in the protocol. 3539 If an endpoint stores or logs SRTP keys or information that can be 3540 used to reconstruct or recover SRTP keys after they are no longer in 3541 use (i.e. the session is active), or otherwise discloses or passes 3542 SRTP keys or information that can be used to reconstruct or recover 3543 SRTP keys to another application or device, the Disclosure flag D 3544 MUST be set in the Confirm1 or Confirm2 message. 3546 12.1. Guidelines on Proper Implementation of the Disclosure Flag 3548 Some implementers have asked for guidance on implementing the 3549 Disclosure Flag. Some people have incorrectly thought that a 3550 connection secured with ZRTP cannot be used in a call center, with 3551 voluntary voice recording, or even with a voicemail system. 3552 Similarly, some potential users of ZRTP have overconsidered the 3553 protection that ZRTP can give them. These guidelines clarify both 3554 concerns. 3556 The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. 3557 It does not govern the underlying RTP media stream, nor the actual 3558 media itself. Consequently, a PBX that uses ZRTP may provide 3559 conference calls, call monitoring, call recording, voicemail, or 3560 other PBX features and still say that it does not disclose the ZRTP 3561 key material. A video system may provide DVR features and still say 3562 that it does not disclose the ZRTP key material. The ZRTP Disclosure 3563 Flag, when not set, means only that the ZRTP cryptographic key 3564 material stays within the bounds of the ZRTP subsystem. 3566 If an application has a need to disclose the ZRTP cryptographic key 3567 material, the easiest way to comply with the protocol is to set the 3568 flag to the proper value. The next easiest way is to overestimate 3569 disclosure. For example, a call center that commonly records calls 3570 might choose to set the disclosure flag even though all recording is 3571 an analog recording of a call (and thus outside the ZRTP scope) 3572 because it sets an expectation with clients that their calls might be 3573 recorded. 3575 Note also that the ZRTP Disclosure Flag does not require an 3576 implementation to preclude hacking or malware. Malware that leaks 3577 ZRTP cryptographic key material does not create a liability for the 3578 implementor from non-compliance with the ZRTP specification. 3580 A user of ZRTP should note that ZRTP is not a panacea against 3581 unauthorized recording. ZRTP does not and cannot protect against an 3582 untrustworthy partner who holds a microphone up to the speaker. It 3583 does not protect against someone else being in the room. It does not 3584 protect against analog wiretaps in the phone or in the room. It does 3585 not mean your partner has not been hacked with spyware. It does not 3586 mean that the software has no flaws. It means that the ZRTP 3587 subsystem is not knowingly leaking ZRTP cryptographic key material. 3589 13. RTP Header Extension Flag for ZRTP 3591 This specification defines a new RTP header extension used only for 3592 discovery of support for ZRTP. No ZRTP data is transported in the 3593 extension. When used, the X bit is set in the RTP header to indicate 3594 the presence of the RTP header extension. 3596 Section 5.3.1 in RFC 3550 [RFC3550] defines the format of an RTP 3597 Header extension. The Header extension is appended to the RTP 3598 header. The first 16 bits are an identifier for the header 3599 extension, and the following 16 bits are length of the extension 3600 header in 32 bit words. The ZRTP flag RTP header extension has the 3601 value of 0x505A and a length of 0. The format of the header 3602 extension is as shown in the Figure below. 3604 0 1 2 3 3605 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 3606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 |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| 3608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 RTP Extension header format for ZRTP Flag 3612 RTP Extension header format for ZRTP Flag 3614 ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at 3615 the start of a session. For example, an endpoint may decide to 3616 include the flag in the first 2 seconds of RTP packets sent. The 3617 inclusion of the flag MAY be ended if a ZRTP message (such as Hello) 3618 is received. 3620 14. IANA Considerations 3622 This specification defines a new SDP [RFC4566] attribute in 3623 Section 9. 3625 Contact name: Philip Zimmermann 3627 Attribute name: "zrtp-hash". 3629 Type of attribute: Media level. 3631 Subject to charset: Not. 3633 Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the 3634 ZRTP protocol and provides a hash of the ZRTP Hello 3635 message. The ZRTP protocol version number is also 3636 specified. 3638 Allowed attribute values: Hex. 3640 15. Security Considerations 3642 This document is all about securely keying SRTP sessions. As such, 3643 security is discussed in every section. 3645 Most secure phones rely on a Diffie-Hellman exchange to agree on a 3646 common session key. But since DH is susceptible to a man-in-the- 3647 middle (MITM) attack, it is common practice to provide a way to 3648 authenticate the DH exchange. In some military systems, this is done 3649 by depending on digital signatures backed by a centrally-managed PKI. 3650 A decade of industry experience has shown that deploying centrally 3651 managed PKIs can be a painful and often futile experience. PKIs are 3652 just too messy, and require too much activation energy to get them 3653 started. Setting up a PKI requires somebody to run it, which is not 3654 practical for an equipment provider. A service provider like a 3655 carrier might venture down this path, but even then you have to deal 3656 with cross-carrier authentication, certificate revocation lists, and 3657 other complexities. It is much simpler to avoid PKIs altogether, 3658 especially when developing secure commercial products. It is 3659 therefore more common for commercial secure phones in the PSTN world 3660 to augment the DH exchange with a Short Authentication String (SAS) 3661 combined with a hash commitment at the start of the key exchange, to 3662 shorten the length of SAS material that must be read aloud. No PKI 3663 is required for this approach to authenticating the DH exchange. The 3664 AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], PGPfone 3665 [pgpfone], and CryptoPhone [cryptophone] are all examples of products 3666 that took this simpler lightweight approach. 3668 The main problem with this approach is inattentive users who may not 3669 execute the voice authentication procedure, or unattended secure 3670 phone calls to answering machines that cannot execute it. 3672 Additionally, some people worry about voice spoofing. But it is a 3673 mistake to think this is simply an exercise in voice impersonation 3674 (perhaps this could be called the "Rich Little" attack). Although 3675 there are digital signal processing techniques for changing a 3676 person's voice, that does not mean a man-in-the-middle attacker can 3677 safely break into a phone conversation and inject his own short 3678 authentication string (SAS) at just the right moment. He doesn't 3679 know exactly when or in what manner the users will choose to read 3680 aloud the SAS, or in what context they will bring it up or say it, or 3681 even which of the two speakers will say it, or if indeed they both 3682 will say it. In addition, some methods of rendering the SAS involve 3683 using a list of words such as the PGP word list[Juola2], in a manner 3684 analogous to how pilots use the NATO phonetic alphabet to convey 3685 information. This can make it even more complicated for the 3686 attacker, because these words can be worked into the conversation in 3687 unpredictable ways. Remember that the attacker places a very high 3688 value on not being detected, and if he makes a mistake, he doesn't 3689 get to do it over. Some people have raised the question that even if 3690 the attacker lacks voice impersonation capabilities, it may be unsafe 3691 for people who don't know each other's voices to depend on the SAS 3692 procedure. This is not as much of a problem as it seems, because it 3693 isn't necessary that they recognize each other by their voice, it's 3694 only necessary that they detect that the voice used for the SAS 3695 procedure matches the voice in the rest of the phone conversation. 3697 A popular and field-proven approach is used by SSH (Secure Shell) 3698 [RFC4251], which Peter Gutmann likes to call the "baby duck" security 3699 model. SSH establishes a relationship by exchanging public keys in 3700 the initial session, when we assume no attacker is present, and this 3701 makes it possible to authenticate all subsequent sessions. A 3702 successful MITM attacker has to have been present in all sessions all 3703 the way back to the first one, which is assumed to be difficult for 3704 the attacker. ZRTP's key continuity features are actually better 3705 than SSH, for reasons described in Section 5.9.1. All this is 3706 accomplished without resorting to a centrally-managed PKI. 3708 We use an analogous baby duck security model to authenticate the DH 3709 exchange in ZRTP. We don't need to exchange persistent public keys, 3710 we can simply cache a shared secret and re-use it to authenticate a 3711 long series of DH exchanges for secure phone calls over a long period 3712 of time. If we read aloud just one SAS, and then cache a shared 3713 secret for later calls to use for authentication, no new voice 3714 authentication rituals need to be executed. We just have to remember 3715 we did one already. 3717 If one party ever loses this cached shared secret, it is no longer 3718 available for authentication of DH exchanges. This cache mismatch 3719 situation is easy to detect by the party that still has a surviving 3720 shared secret cache entry. If it fails to match, either there is a 3721 MiTM attack or one side has lost their shared secret cache entry. 3722 The user agent that discovers the cache mismatch MUST alert the user 3723 that a cache mismatch has been detected, and that he must do a verbal 3724 comparison of the SAS to distinguish if the mismatch is because of a 3725 MiTM attack or because of the other party losing her cache. From 3726 that point on, the two parties start over with a new cached shared 3727 secret. Then they can go back to omitting the voice authentication 3728 on later calls. 3730 A particularly compelling reason why this approach is attractive is 3731 that SAS is easiest to implement when a graphical user interface or 3732 some sort of display is available, which raises the question of what 3733 to do when a display is less conveniently available. For example, 3734 some devices that implement ZRTP might have a graphical user 3735 interface that is only visible through a web browser, such as a PBX 3736 or some other nearby device that implements ZRTP as a "bump-in-the- 3737 wire". If we take an approach that greatly reduces the need for a 3738 SAS in each and every call, we can operate in products without a 3739 graphical user interface with greater ease. Then the SAS can be 3740 compared less frequently through a web browser, or it might even be 3741 presented as needed to the local user through a locally generated 3742 voice prompt, which the local user hears and verbally repeats and 3743 compares with the remote party. 3745 It's a good idea to force your opponent to have to solve multiple 3746 problems in order to mount a successful attack. Some examples of 3747 widely differing problems we might like to present him with are: 3748 Stealing a shared secret from one of the parties, being present on 3749 the very first session and every subsequent session to carry out an 3750 active MITM attack, and solving the discrete log problem. We want to 3751 force the opponent to solve more than one of these problems to 3752 succeed. 3754 ZRTP can use different kinds of shared secrets. Each type of shared 3755 secret is determined by a different method. All of the shared 3756 secrets are hashed together to form a session key to encrypt the 3757 call. An attacker must defeat all of the methods in order to 3758 determine the session key. 3760 First, there is the shared secret determined entirely by a Diffie- 3761 Hellman key agreement. It changes with every call, based on random 3762 numbers. An attacker may attempt a classic DH MITM attack on this 3763 secret, but we can protect against this by displaying and reading 3764 aloud a SAS, combined with adding a hash commitment at the beginning 3765 of the DH exchange. 3767 Second, there is an evolving shared secret, or ongoing shared secret 3768 that is automatically changed and refreshed and cached with every new 3769 session. We will call this the cached shared secret, or sometimes 3770 the retained shared secret. Each new image of this ongoing secret is 3771 a non-invertable function of its previous value and the new secret 3772 derived by the new DH agreement. It's possible that no cached shared 3773 secret is available, because there were no previous sessions to 3774 inherit this value from, or because one side loses its cache. 3776 There are other approaches for key agreement for SRTP that compute a 3777 shared secret using information in the signaling. For example, 3778 [RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing) 3779 [RFC3830] payload in SDP [RFC4566]. Or RFC 4568 (SDES) [RFC4568] 3780 describes directly carrying SRTP keying and configuration information 3781 in SDP. ZRTP does not rely on the signaling to compute a shared 3782 secret, but If a client does produce a shared secret via the 3783 signaling, and makes it available to the ZRTP protocol, ZRTP can make 3784 use of this shared secret to augment the list of shared secrets that 3785 will be hashed together to form a session key. This way, any 3786 security weaknesses that might compromise the shared secret 3787 contributed by the signaling will not harm the final resulting 3788 session key. 3790 There may also be a static shared secret that the two parties agree 3791 on out-of-band in advance. A hashed passphrase would suffice. 3793 The shared secret provided by the signaling (if available), the 3794 shared secret computed by DH, and the cached shared secret are all 3795 hashed together to compute the session key for a call. If the cached 3796 shared secret is not available, it is omitted from the hash 3797 computation. If the signaling provides no shared secret, it is also 3798 omitted from the hash computation. 3800 No DH MITM attack can succeed if the ongoing shared secret is 3801 available to the two parties, but not to the attacker. This is 3802 because the attacker cannot compute a common session key with either 3803 party without knowing the cached secret component, even if he 3804 correctly executes a classic DH MITM attack. Mixing in the cached 3805 shared secret for the session key calculation allows it to act as an 3806 implicit authenticator to protect the DH exchange, without requiring 3807 additional explicit HMACs to be computed on the DH parameters. If 3808 the cached shared secret is available, a MITM attack would be 3809 instantly detected by the failure to achieve a shared session key, 3810 resulting in undecryptable packets. The protocol can easily detect 3811 this. It would be more accurate to say that the MITM attack is not 3812 merely detected, but thwarted. 3814 When adding the complexity of additional shared secrets beyond the 3815 familiar DH key agreement, we must make sure the lack of availability 3816 of the cached shared secret cannot prevent a call from going through, 3817 and we must also prevent false alarms that claim an attack was 3818 detected. 3820 An small added benefit of using these cached shared secrets to mix in 3821 with the session keys is that it augments the entropy of the session 3822 key. Even if limits on the size of the DH exchange produces a 3823 session key with less than 256 bits of real work factor, the added 3824 entropy from the cached shared secret can bring up all the subsequent 3825 session keys to the full 256-bit AES key strength, assuming no 3826 attacker was present in the first call. 3828 We could have authenticated the DH exchange the same way SSH does it, 3829 with digital signatures, caching public keys instead of shared 3830 secrets. But this approach with caching shared secrets seemed a bit 3831 simpler, requiring less CPU time for low-powered mobile platforms 3832 because it avoids an added digital signature step. 3834 The ZRTP SDP attributes convey information through the signaling that 3835 is already available in clear text through the media path. For 3836 example, the ZRTP flag is equivalent to sending a ZRTP Hello message. 3837 The SAS is calculated from a hash of material from ZRTP messages sent 3838 over the media path. As a result, none of the ZRTP SDP attributes 3839 require confidentiality from the signaling. 3841 The ZRTP SAS attributes can use the signaling channel as an out-of- 3842 band authentication mechanism. This authentication is only useful if 3843 the signaling channel has end-to-end integrity protection. Note that 3844 the SIP Identity header field [RFC4474] provides middle-to-end 3845 integrity protection across SDP message bodies which provides useful 3846 protection for ZRTP SAS attributes. 3848 16. Acknowledgments 3850 The authors would like to thank Bryce Wilcox-O'Hearn for his 3851 contributions to the design of this protocol, and to thank Jon 3852 Peterson, Colin Plumb, Hal Finney, Colin Perkins, and Dan Wing for 3853 their helpful comments and suggestions. Also thanks to David McGrew, 3854 Roni Even, Viktor Krikun, Werner Dittmann, Allen Pulsifer, Klaus 3855 Peters, and Abhishek Arya for their feedback and comments. 3857 The use of hash chains to key HMACs in ZRTP is similar to Adrian 3858 Perrig's TESLA protocol [TESLA]. 3860 17. References 3861 17.1. Normative References 3863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3864 Requirement Levels", BCP 14, RFC 2119, March 1997. 3866 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3867 Jacobson, "RTP: A Transport Protocol for Real-Time 3868 Applications", STD 64, RFC 3550, July 2003. 3870 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3871 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3872 RFC 3711, March 2004. 3874 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3875 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3876 RFC 3526, May 2003. 3878 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 3879 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 3880 September 2002. 3882 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 3883 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 3884 RFC 4231, December 2005. 3886 [SP800-90] 3887 Barker, E. and J. Kelsey, "Recommendation for Random 3888 Number Generation Using Deterministic Random Bit 3889 Generators", NIST Special Publication 800-90 (Revised) 3890 March 2007. 3892 [SP800-56A] 3893 Barker, E., Johnson, D., and M. Smid, "Recommendation for 3894 Pair-Wise Key Establishment Schemes Using Discrete 3895 Logarithm Cryptography", NIST Special Publication 800- 3896 56A Revision 1, March 2007. 3898 [FIPS-180-2] 3899 "Secure Hash Signature Standard (SHS)", NIST FIPS PUB 180- 3900 2 August 2002. 3902 [FIPS-198-1] 3903 "The Keyed-Hash Message Authentication Code (HMAC)", NIST 3904 FIPS PUB 198-1 July 2008. 3906 [NSA-Suite-B] 3907 "Fact Sheet NSA Suite B Cryptography", NSA Information 3908 Assurance Directorate Fact Sheet NSA Suite B. 3910 [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", 3911 RFC 4753, January 2007. 3913 [FIPS-186-3] 3914 "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3915 3 Draft, March 2006. 3917 [SP800-38A] 3918 Dworkin, M., "Recommendation for Block Cipher: Methods and 3919 Techniques", NIST Special Publication 800-38A 2001 3920 Edition. 3922 [z-base-32] 3923 Wilcox, B., "Human-oriented base-32 encoding", 3924 http://zooko.com/repos/z-base-32/base32/DESIGN . 3926 [pgpwordlist] 3927 "PGP Words", http://en.wikipedia.org/wiki/PGP_Words . 3929 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3930 Description Protocol", RFC 4566, July 2006. 3932 17.2. Informative References 3934 [I-D.ietf-sip-media-security-requirements] 3935 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 3936 "Requirements and Analysis of Media Security Management 3937 Protocols", draft-ietf-sip-media-security-requirements-07 3938 (work in progress), June 2008. 3940 [Ferguson] 3941 Ferguson, N. and B. Schneier, "Practical Cryptography", 3942 Wiley Publishing 2003. 3944 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3945 Requirements for Security", BCP 106, RFC 4086, June 2005. 3947 [Juola1] Juola, P. and P. Zimmermann, "Whole-Word Phonetic 3948 Distances and the PGPfone Alphabet", Proceedings of the 3949 International Conference of Spoken Language Processing 3950 (ICSLP-96) 1996. 3952 [Juola2] Juola, P., "Isolated Word Confusion Metrics and the 3953 PGPfone Alphabet", Proceedings of New Methods in Language 3954 Processing 1996. 3956 [pgpfone] Zimmermann, P., "PGPfone", 3957 http://philzimmermann.com/docs/pgpfone10b7.pdf . 3959 [zfone] Zimmermann, P., "Zfone", 3960 http://www.philzimmermann.com/zfone . 3962 [Byzantine] 3963 "The Two Generals' Problem", 3964 http://en.wikipedia.org/wiki/Two_Generals%27_Problem . 3966 [TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The 3967 TESLA Broadcast Authentication Protocol", http:// 3968 www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ 3969 tesla-cryptobytes.pdf . 3971 [SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer 3972 Security Resource Center Cryptographic Hash Project. 3974 [comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices 3975 Version 1.2", http://www.comsec.com/vp1-protocol.pdf . 3977 [cryptophone] 3978 "CryptoPhone", http://www.cryptophone.de/ . 3980 [Wright1] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. 3981 Masson, "Spot me if you can: Uncovering spoken phrases in 3982 encrypted VoIP conversations", Proceedings of the 2008 3983 IEEE Symposium on Security and Privacy 2008. 3985 [dsa-1571] 3986 "Debian Security Advisory - OpenSSL predictable random 3987 number generator", 3988 http://www.debian.org/security/2008/dsa-1571 . 3990 [I-D.ietf-avt-srtp-big-aes] 3991 McGrew, D., "The use of AES-192 and AES-256 in Secure 3992 RTP", http://www1.tools.ietf.org/html/ 3993 draft-ietf-avt-srtp-big-aes . 3995 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3996 A., Peterson, J., Sparks, R., Handley, M., and E. 3997 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3998 June 2002. 4000 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 4001 Protocol Architecture", RFC 4251, January 2006. 4003 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 4004 Description Protocol (SDP) Security Descriptions for Media 4005 Streams", RFC 4568, July 2006. 4007 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 4008 Carrara, "Key Management Extensions for Session 4009 Description Protocol (SDP) and Real Time Streaming 4010 Protocol (RTSP)", RFC 4567, July 2006. 4012 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 4013 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 4014 August 2004. 4016 [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", 4017 RFC 3514, April 1 2003. 4019 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 4020 Authenticated Identity Management in the Session 4021 Initiation Protocol (SIP)", RFC 4474, August 2006. 4023 [I-D.ietf-mmusic-ice] 4024 Rosenberg, J., "Interactive Connectivity Establishment 4025 (ICE): A Protocol for Network Address Translator (NAT) 4026 Traversal for Offer/Answer Protocols", 4027 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 4029 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 4030 (SIP) Call Control - Conferencing for User Agents", 4031 BCP 119, RFC 4579, August 2006. 4033 [I-D.wing-sip-identity-media] 4034 Wing, D. and H. Kaplan, "SIP Identity using Media Path", 4035 draft-wing-sip-identity-media-02 (work in progress), 4036 February 2008. 4038 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 4039 E.164 numbers with the Session Initiation Protocol (SIP)", 4040 RFC 3824, June 2004. 4042 [I-D.ietf-avt-dtls-srtp] 4043 McGrew, D. and E. Rescorla, "Datagram Transport Layer 4044 Security (DTLS) Extension to Establish Keys for Secure 4045 Real-time Transport Protocol (SRTP)", 4046 draft-ietf-avt-dtls-srtp-05 (work in progress), 4047 September 2008. 4049 Authors' Addresses 4051 Philip Zimmermann 4052 Zfone Project 4054 Email: prz@mit.edu 4056 Alan Johnston (editor) 4057 Avaya 4058 St. Louis, MO 63124 4060 Email: alan@sipstation.com 4062 Jon Callas 4063 PGP Corporation 4065 Email: jon@pgp.com 4067 Full Copyright Statement 4069 Copyright (C) The IETF Trust (2008). 4071 This document is subject to the rights, licenses and restrictions 4072 contained in BCP 78, and except as set forth therein, the authors 4073 retain all their rights. 4075 This document and the information contained herein are provided on an 4076 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4077 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4078 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4079 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4080 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4081 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4083 Intellectual Property 4085 The IETF takes no position regarding the validity or scope of any 4086 Intellectual Property Rights or other rights that might be claimed to 4087 pertain to the implementation or use of the technology described in 4088 this document or the extent to which any license under such rights 4089 might or might not be available; nor does it represent that it has 4090 made any independent effort to identify any such rights. Information 4091 on the procedures with respect to rights in RFC documents can be 4092 found in BCP 78 and BCP 79. 4094 Copies of IPR disclosures made to the IETF Secretariat and any 4095 assurances of licenses to be made available, or the result of an 4096 attempt made to obtain a general license or permission for the use of 4097 such proprietary rights by implementers or users of this 4098 specification can be obtained from the IETF on-line IPR repository at 4099 http://www.ietf.org/ipr. 4101 The IETF invites any interested party to bring to its attention any 4102 copyrights, patents or patent applications, or other proprietary 4103 rights that may cover technology that may be required to implement 4104 this standard. Please address the information to the IETF at 4105 ietf-ipr@ietf.org.