idnits 2.17.1 draft-zimmermann-avt-zrtp-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2010) is 5114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 2334 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: October 28, 2010 Avaya 6 J. Callas 7 Apple, Inc. 8 April 26, 2010 10 ZRTP: Media Path Key Agreement for Unicast Secure RTP 11 draft-zimmermann-avt-zrtp-18 13 Abstract 15 This document defines ZRTP, a protocol for media path Diffie-Hellman 16 exchange to agree on a session key and parameters for establishing 17 unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP 18 applications. The ZRTP protocol is media path keying because it is 19 multiplexed on the same port as RTP and does not require support in 20 the signaling protocol. ZRTP does not assume a Public Key 21 Infrastructure (PKI) or require the complexity of certificates in end 22 devices. For the media session, ZRTP provides confidentiality, 23 protection against man-in-the-middle (MiTM) attacks, and, in cases 24 where the signaling protocol provides end-to-end integrity 25 protection, authentication. ZRTP can utilize a Session Description 26 Protocol (SDP) attribute to provide discovery and authentication 27 through the signaling channel. To provide best effort SRTP, ZRTP 28 utilizes normal RTP/AVP profiles. ZRTP secures media sessions which 29 include a voice media stream, and can also secure media sessions 30 which do not include voice by using an optional digital signature. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on October 28, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 8 88 3.1.1. Diffie-Hellman Mode Overview . . . . . . . . . . . . 8 89 3.1.2. Preshared Mode Overview . . . . . . . . . . . . . . . 10 90 3.1.3. Multistream Mode Overview . . . . . . . . . . . . . . 10 91 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 11 92 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 93 4.1.1. Protocol Version Negotiation . . . . . . . . . . . . 12 94 4.1.2. Algorithm Negotiation . . . . . . . . . . . . . . . . 14 95 4.2. Commit Contention . . . . . . . . . . . . . . . . . . . . 15 96 4.3. Matching Shared Secret Determination . . . . . . . . . . 16 97 4.3.1. Calculation and comparison of hashes of shared 98 secrets . . . . . . . . . . . . . . . . . . . . . . . 17 99 4.3.2. Handling a Shared Secret Cache Mismatch . . . . . . . 18 100 4.4. DH and non-DH key agreements . . . . . . . . . . . . . . 20 101 4.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 20 102 4.4.1.1. Hash Commitment in Diffie-Hellman Mode . . . . . 20 103 4.4.1.2. Responder Behavior in Diffie-Hellman Mode . . . . 21 104 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode . . . . 22 105 4.4.1.4. Shared Secret Calculation for DH Mode . . . . . . 22 106 4.4.2. Preshared Mode . . . . . . . . . . . . . . . . . . . 25 107 4.4.2.1. Commitment in Preshared Mode . . . . . . . . . . 25 108 4.4.2.2. Initiator Behavior in Preshared Mode . . . . . . 26 109 4.4.2.3. Responder Behavior in Preshared Mode . . . . . . 26 110 4.4.2.4. Shared Secret Calculation for Preshared Mode . . 27 111 4.4.3. Multistream Mode . . . . . . . . . . . . . . . . . . 28 112 4.4.3.1. Commitment in Multistream Mode . . . . . . . . . 29 113 4.4.3.2. Shared Secret Calculation for Multistream Mode . 30 114 4.5. Key Derivations . . . . . . . . . . . . . . . . . . . . . 31 115 4.5.1. The ZRTP Key Derivation Function . . . . . . . . . . 31 116 4.5.2. Deriving ZRTPSess Key and SAS in DH or Preshared 117 modes . . . . . . . . . . . . . . . . . . . . . . . . 32 118 4.5.3. Deriving the rest of the keys from s0 . . . . . . . . 33 119 4.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . 34 120 4.6.1. Updating the Cache of Shared Secrets . . . . . . . . 35 121 4.6.1.1. Cache Update Following a Cache Mismatch . . . . . 36 122 4.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 37 123 4.7.1. Termination via Error message . . . . . . . . . . . . 37 124 4.7.2. Termination via GoClear message . . . . . . . . . . . 37 125 4.7.2.1. Key Destruction for GoClear message . . . . . . . 38 126 4.7.3. Key Destruction at Termination . . . . . . . . . . . 39 127 4.8. Random Number Generation . . . . . . . . . . . . . . . . 39 128 4.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 40 129 4.9.1. Cacheless implementations . . . . . . . . . . . . . . 41 131 5. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 42 132 5.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . 43 133 5.1.1. Message Type Block . . . . . . . . . . . . . . . . . 44 134 5.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 45 135 5.1.2.1. Implicit Hash and HMAC algorithm . . . . . . . . 45 136 5.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 46 137 5.1.4. Auth Tag Type Block . . . . . . . . . . . . . . . . . 47 138 5.1.5. Key Agreement Type Block . . . . . . . . . . . . . . 48 139 5.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . 50 140 5.1.7. Signature Type Block . . . . . . . . . . . . . . . . 51 141 5.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 52 142 5.3. HelloACK message . . . . . . . . . . . . . . . . . . . . 54 143 5.4. Commit message . . . . . . . . . . . . . . . . . . . . . 54 144 5.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 57 145 5.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 59 146 5.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . 61 147 5.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . 63 148 5.9. Error message . . . . . . . . . . . . . . . . . . . . . . 64 149 5.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . 65 150 5.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 66 151 5.12. ClearACK message . . . . . . . . . . . . . . . . . . . . 66 152 5.13. SASrelay message . . . . . . . . . . . . . . . . . . . . 67 153 5.14. RelayACK message . . . . . . . . . . . . . . . . . . . . 69 154 5.15. Ping message . . . . . . . . . . . . . . . . . . . . . . 70 155 5.16. PingACK message . . . . . . . . . . . . . . . . . . . . . 71 156 6. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 72 157 7. Short Authentication String . . . . . . . . . . . . . . . . . 75 158 7.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 75 159 7.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 77 160 7.2.1. OpenPGP Signatures . . . . . . . . . . . . . . . . . 78 161 7.2.2. NSA Suite B Signatures with X.509v3 Certs . . . . . . 79 162 7.3. Relaying the SAS through a PBX . . . . . . . . . . . . . 80 163 7.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . 83 164 8. Signaling Interactions . . . . . . . . . . . . . . . . . . . 84 165 8.1. Binding the media stream to the signaling layer via 166 the Hello Hash . . . . . . . . . . . . . . . . . . . . . 86 167 8.1.1. Integrity-protected signaling enables 168 integrity-protected DH exchange . . . . . . . . . . . 87 169 8.2. Deriving the SRTP secret (srtps) from the signaling 170 layer . . . . . . . . . . . . . . . . . . . . . . . . . . 89 171 8.3. Codec Selection for Secure Media . . . . . . . . . . . . 89 172 9. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 90 173 10. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 92 174 11. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . 93 175 11.1. Guidelines on Proper Implementation of the Disclosure 176 Flag . . . . . . . . . . . . . . . . . . . . . . . . . . 95 177 12. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . 96 178 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 179 14. Appendix - Media Security Requirements . . . . . . . . . . . 97 180 15. Security Considerations . . . . . . . . . . . . . . . . . . . 99 181 15.1. Self-healing Key Continuity Feature . . . . . . . . . . . 103 182 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 104 183 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 184 17.1. Normative References . . . . . . . . . . . . . . . . . . 105 185 17.2. Informative References . . . . . . . . . . . . . . . . . 107 186 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 188 1. Introduction 190 ZRTP is a key agreement protocol which performs Diffie-Hellman key 191 exchange during call setup in the media path, and is transported over 192 the same port as the Real-time Transport Protocol (RTP) [RFC3550] 193 media stream which has been established using a signaling protocol 194 such as Session Initiation Protocol (SIP) [RFC3261]. This generates 195 a shared secret which is then used to generate keys and salt for a 196 Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone 197 [pgpfone]. A reference implementation of ZRTP is available as Zfone 198 [zfone]. 200 The ZRTP protocol has some nice cryptographic features lacking in 201 many other approaches to media session encryption. Although it uses 202 a public key algorithm, it does not rely on a public key 203 infrastructure (PKI). In fact, it does not use persistent public 204 keys at all. It uses ephemeral Diffie-Hellman (DH) with hash 205 commitment, and allows the detection of man-in-the-middle (MiTM) 206 attacks by displaying a short authentication string (SAS) for the 207 users to read and verbally compare over the phone. It has Perfect 208 Forward Secrecy, meaning the keys are destroyed at the end of the 209 call, which precludes retroactively compromising the call by future 210 disclosures of key material. But even if the users are too lazy to 211 bother with short authentication strings, we still get reasonable 212 authentication against a MiTM attack, based on a form of key 213 continuity. It does this by caching some key material to use in the 214 next call, to be mixed in with the next call's DH shared secret, 215 giving it key continuity properties analogous to SSH. All this is 216 done without reliance on a PKI, key certification, trust models, 217 certificate authorities, or key management complexity that bedevils 218 the email encryption world. It also does not rely on SIP signaling 219 for the key management, and in fact does not rely on any servers at 220 all. It performs its key agreements and key management in a purely 221 peer-to-peer manner over the RTP packet stream. 223 ZRTP can be used and discovered without being declared or indicated 224 in the signaling path. This provides a best effort SRTP capability. 225 Also, this reduces the complexity of implementations and minimizes 226 interdependency between the signaling and media layers. However, 227 when ZRTP is indicated in the signaling via the zrtp-hash SDP 228 attribute, ZRTP has additional useful properties. By sending a hash 229 of the ZRTP Hello message in the signaling, ZRTP provides a useful 230 binding between the signaling and media paths, which is explained in 231 Section 8.1. When this is done through a signaling path that has 232 end-to-end integrity protection, the DH exchange is automatically 233 protected from a MiTM attack, which is explained in Section 8.1.1. 235 ZRTP is designed for unicast media sessions in which there is a voice 236 media stream. For multiparty secure conferencing, separate ZRTP 237 sessions may be negotiated between each party and the conference 238 bridge. For sessions lacking a voice media stream, MiTM protection 239 may be provided by the mechanisms in Section 8.1.1 or Section 7.2. 241 2. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 In this document, a "call" is synonymous with a "session". 249 3. Overview 251 This section provides a description of how ZRTP works. This 252 description is non-normative in nature but is included to build 253 understanding of the protocol. 255 ZRTP is negotiated the same way a conventional RTP session is 256 negotiated in an offer/answer exchange using the standard RTP/AVP 257 profile. The ZRTP protocol begins after two endpoints have utilized 258 a signaling protocol such as SIP and are ready to exchange media. If 259 ICE [I-D.ietf-mmusic-ice] is being used, ZRTP begins after ICE has 260 completed its connectivity checks. 262 ZRTP is multiplexed on the same ports as RTP. It uses a unique 263 header that makes it clearly differentiable from RTP or STUN. 265 ZRTP support can be discovered in the signaling path by the presence 266 of a ZRTP SDP attribute. It can also be discovered by the receipt of 267 an RTP packet with a ZRTP header extension flag. However, even in 268 cases where neither of these are received, an endpoint can still send 269 ZRTP Hello messages to see if a response is received. If a response 270 is not received, no more ZRTP messages will be sent during this 271 session. This is safe because ZRTP has been designed to be clearly 272 different from RTP and have a similar structure to STUN packets 273 received (sometimes by non-supporting endpoints) during an ICE 274 exchange. 276 A ZRTP endpoint initiates the exchange by sending a ZRTP Hello 277 message to the other endpoint. The purpose of the Hello message is 278 to confirm the endpoint supports the protocol and to see what 279 algorithms the two ZRTP endpoints have in common. 281 The Hello message contains the SRTP configuration options, and the 282 ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID 283 that is generated once at installation time. ZIDs are discovered 284 during the Hello message exchange. The received ZID is used to look 285 up retained shared secrets from previous ZRTP sessions with the 286 endpoint. 288 A response to a ZRTP Hello message is a ZRTP HelloACK message. The 289 HelloACK message simply acknowledges receipt of the Hello. Since RTP 290 commonly uses best effort UDP transport, ZRTP has retransmission 291 timers in case of lost datagrams. There are two timers, both with 292 exponential backoff mechanisms. One timer is used for 293 retransmissions of Hello messages and the other is used for 294 retransmissions of all other messages after receipt of a HelloACK. 296 If an integrity protected signaling channel is available, a hash of 297 the Hello message can be sent. This allows rejection of false 298 injected ZRTP Hello messages by an attacker. 300 Hello and other ZRTP messages also contain a hash image that is used 301 to link the messages together. This allows rejection of false 302 injected ZRTP messages during an exchange. 304 3.1. Key Agreement Modes 306 After both endpoints exchange Hello and HelloACK messages, the key 307 agreement exchange can begin with the ZRTP Commit message. ZRTP 308 supports a number of key agreement modes including both Diffie- 309 Hellman and non-Diffie-Hellman modes as described in the following 310 sections. 312 The Commit message may be sent immediately after both endpoints have 313 completed the Hello/HelloACK discovery handshake. Or it may be 314 deferred until later in the call, after the participants engage in 315 some unencrypted conversation. The Commit message may be manually 316 activated by a user interface element, such as a GO SECURE button, 317 which becomes enabled after the Hello/HelloACK discovery phase. This 318 emulates the user experience of a number of secure phones in the PSTN 319 world [comsec]. However, it is expected that most simple ZRTP user 320 agents will omit such buttons and proceed directly to secure mode by 321 sending a Commit message immediately after the Hello/HelloACK 322 handshake. 324 3.1.1. Diffie-Hellman Mode Overview 326 An example ZRTP call flow is shown in Figure 1 below. Note that the 327 order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be 328 reversed. That is, either Alice or Bob might send the first Hello 329 message. Note that the endpoint which sends the Commit message is 330 considered the initiator of the ZRTP session and drives the key 331 agreement exchange. The Diffie-Hellman public values are exchanged 332 in the DHPart1 and DHPart2 messages. SRTP keys and salts are then 333 calculated. 335 Alice Bob 336 | | 337 | Alice and Bob establish a media session. | 338 | They initiate ZRTP on media ports | 339 | | 340 | F1 Hello (version, options, Alice's ZID) | 341 |-------------------------------------------------->| 342 | HelloACK F2 | 343 |<--------------------------------------------------| 344 | Hello (version, options, Bob's ZID) F3 | 345 |<--------------------------------------------------| 346 | F4 HelloACK | 347 |-------------------------------------------------->| 348 | | 349 | Bob acts as the initiator | 350 | | 351 | Commit (Bob's ZID, options, hash value) F5 | 352 |<--------------------------------------------------| 353 | F6 DHPart1 (pvr, shared secret hashes) | 354 |-------------------------------------------------->| 355 | DHPart2 (pvi, shared secret hashes) F7 | 356 |<--------------------------------------------------| 357 | | 358 | Alice and Bob generate SRTP session key. | 359 | | 360 | F8 Confirm1 (HMAC, D,A,V,E flags, sig) | 361 |-------------------------------------------------->| 362 | Confirm2 (HMAC, D,A,V,E flags, sig) F9 | 363 |<--------------------------------------------------| 364 | F10 Conf2ACK | 365 |-------------------------------------------------->| 366 | SRTP begins | 367 |<=================================================>| 368 | | 370 Figure 1: Establishment of an SRTP session using ZRTP 372 ZRTP authentication uses a Short Authentication String (SAS) which is 373 ideally displayed for the human user. Alternatively, the SAS can be 374 authenticated by exchanging an OPTIONAL digital signature (sig) over 375 the short authentication string in the Confirm1 or Confirm2 messages 376 (described in Section 7.2). 378 The ZRTP Confirm1 and Confirm2 messages are sent for a number of 379 reasons, not the least of which is they confirm that all the key 380 agreement calculations were successful and thus the encryption will 381 work. They also carry other information such as the Disclosure flag 382 (D), the Allow Clear flag (A), the SAS Verified flag (V), and the PBX 383 Enrollment flag (E). All flags are encrypted to shield them from a 384 passive observer. 386 3.1.2. Preshared Mode Overview 388 In the Preshared Mode, endpoints can skip the DH calculation if they 389 have a shared secret from a previous ZRTP session. Preshared mode is 390 indicated in the Commit message and results in the same call flow as 391 Multistream mode. The principal difference between Multistream mode 392 and Preshared mode is that Preshared mode uses a previously cached 393 shared secret, rs1, instead of an active ZRTP Session key as the 394 initial keying material. 396 This mode could be useful for slow processor endpoints so that a DH 397 calculation does not need to be performed every session. Or, this 398 mode could be used to rapidly re-establish an earlier session that 399 was recently torn down or interrupted without the need to perform 400 another DH calculation. 402 Preshared mode has forward secrecy properties. If a phone's cache is 403 captured by an opponent, the cached shared secrets cannot be used to 404 recover earlier encrypted calls, because the shared secrets are 405 replaced with new ones in each new call, as in DH mode. However, the 406 captured secrets can be used by a passive wiretapper in the media 407 path to decrypt the next call, if the next call is in Preshared mode. 408 This differs from DH mode, which requires an active MiTM wiretapper 409 to exploit captured secrets in the next call. However, if the next 410 call is missed by the wiretapper, he cannot wiretap any further 411 calls. It thus preserves most of the self-healing properties 412 (Section 15.1) of key continuity enjoyed by DH mode. 414 3.1.3. Multistream Mode Overview 416 Multistream mode is an alternative key agreement method when two 417 endpoints have an established SRTP media stream between them and 418 hence an active ZRTP Session key. ZRTP can derive multiple SRTP keys 419 from a single DH exchange. For example, an established secure voice 420 call that adds a video stream uses Multistream mode to quickly 421 initiate the video stream without a second DH exchange. 423 When Multistream mode is indicated in the Commit message, a call flow 424 similar to Figure 1 is used, but no DH calculation is performed by 425 either endpoint and the DHPart1 and DHPart2 messages are omitted. 427 The Confirm1, Confirm2, and Conf2ACK messages are still sent. Since 428 the cache is not affected during this mode, multiple Multistream ZRTP 429 exchanges can be performed in parallel between two endpoints. 431 When adding additional media streams to an existing call, only 432 Multistream mode is used. Only one DH operation is performed, just 433 for the first media stream. 435 4. Protocol Description 437 This section begins the normative description of the protocol. 439 ZRTP MUST be multiplexed on the same ports as the RTP media packets. 441 To support best effort encryption from the Media Security 442 Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media 443 lines in the initial offer/answer exchange. The ZRTP SDP attribute 444 a=zrtp-hash defined in Section 8 SHOULD be used in all offers and 445 answers to indicate support for the ZRTP protocol. 447 ZRTP can be utilized by endpoints that do not have a common 448 signaling protocol but both support SRTP and are relying on a 449 gateway for conversion. As such, it is not always possible for 450 the signaling protocol to relay the zrtp-hash as can be done using 451 SIP. 453 The Secure RTP/AVP (SAVP) profile MAY be used in subsequent offer/ 454 answer exchanges after a successful ZRTP exchange has resulted in an 455 SRTP session, or if it is known the other endpoint supports this 456 profile. Other profiles MAY also be used. 458 The use of the RTP/SAVP profile has caused failures in negotiating 459 best effort SRTP due to the limitations on negotiating profiles 460 using SDP. This is why ZRTP supports the RTP/AVP profile and 461 includes its own discovery mechanisms. 463 In all key agreement modes, the initiator SHOULD NOT send RTP media 464 after sending the Commit message, and MUST NOT send SRTP media before 465 receiving either the Conf2ACK or the first SRTP media (with a valid 466 SRTP auth tag) from the responder. The responder SHOULD NOT send RTP 467 media after receiving the Commit message, and MUST NOT send SRTP 468 media before receiving the Confirm2 message. 470 4.1. Discovery 472 During the ZRTP discovery phase, a ZRTP endpoint discovers if the 473 other endpoint supports ZRTP and the supported algorithms and 474 options. This information is transported in a Hello message, 475 described in Section 5.2. 477 ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers 478 and answers, as defined in Section 8. ZRTP SHOULD use an RTP 479 [RFC3550] extension field as a flag to indicate support for the ZRTP 480 protocol in RTP packets as described in Section 12. 482 The Hello message includes the ZRTP version, hash type, cipher type, 483 authentication method and tag length, key agreement type, and Short 484 Authentication String (SAS) algorithms that are supported. The Hello 485 message also includes a hash image as described in Section 9. In 486 addition, each endpoint sends and discovers ZIDs. The received ZID 487 is used later in the protocol as an index into a cache of shared 488 secrets that were previously negotiated and retained between the two 489 parties. 491 A Hello message can be sent at any time, but is usually sent at the 492 start of an RTP session to determine if the other endpoint supports 493 ZRTP, and also if the SRTP implementations are compatible. A Hello 494 message is retransmitted using timer T1 and an exponential backoff 495 mechanism detailed in Section 6 until the receipt of a HelloACK 496 message or a Commit message. 498 The use of the a=zrtp-hash SDP attribute to authenticate the Hello 499 message is described in Section 8.1. 501 4.1.1. Protocol Version Negotiation 503 This specification defines ZRTP version 1.10. Since new versions of 504 ZRTP may be developed in the future, this specification defines a 505 protocol version negotiation in this section. 507 Each party declares what version of the ZRTP protocol they support 508 via the version field in the Hello message (Section 5.2). If both 509 parties have the same version number in their Hello messages, they 510 can proceed with the rest of the protocol. To facilitate both 511 parties reaching this state of protocol version agreement in their 512 Hello messages, ZRTP should use information provided in the signaling 513 layer, if available. If a ZRTP endpoint supports more than one 514 version of the protocol, it SHOULD declare them all in a list of SIP 515 SDP a=zrtp-hash attributes (defined in Section 8), listing separate 516 hashes, with separate ZRTP version numbers in each item in the list. 518 Both parties should inspect the list of ZRTP version numbers supplied 519 by the other party in the SIP SDP a=zrtp-hash attributes. Both 520 parties should choose the highest version number that appear in both 521 parties' list of a=zrtp-hash version numbers, and use that version 522 for their Hello messages. If both parties use the SIP signaling in 523 this manner, their initial Hello messages will have the same ZRTP 524 version number, provided they both have at least one supported 525 protocol version in common. Before the ZRTP key agreement can 526 proceed, an endpoint MUST have sent and received Hellos with the same 527 protocol version. 529 It is best if the signaling layer is used to negotiate the protocol 530 version number. However, the a=zrtp-hash SDP attribute is not always 531 present in the SIP packet, as explained in Section 8.1. In the 532 absence of any guidance from the signaling layer, an endpoint MUST 533 send the highest supported version in initial Hello messages. If the 534 two parties send different protocol version numbers in their Hello 535 messages, they can reach agreement to use a common version, if one 536 exists. They iteratively apply the following rules until they both 537 have matching version fields in their Hello messages and the key 538 agreement can proceed: 540 o If an endpoint receives a Hello message with an unsupported 541 version number that is higher than the endpoint's current Hello 542 message version, the received Hello message MUST be ignored. The 543 endpoint continues to retransmit Hello messages on the standard 544 retry schedule (Section 6). 545 o If an endpoint receives a Hello message with a version number that 546 is lower than the endpoint's current Hello message, and the 547 endpoint supports a version that is less than or equal to the 548 received version number, the endpoint MUST stop retransmitting the 549 old version number and MUST start sending a Hello message with the 550 highest supported version number that is less than or equal to the 551 received version number. 552 o If an endpoint receives a Hello message with an unsupported 553 version number that is lower than the endpoint's current Hello 554 message, the endpoint MUST send an Error message (Section 5.9) 555 indicating failure to support this ZRTP version. 557 The above comparisons are iterated until the version numbers match, 558 or until it exits on a failure to match. 560 For example, assume that Alice supports protocol version 1.10 and 561 2.00, and Bob supports version 1.10 and 1.20. Alice initially 562 sends a Hello with version 2.00, and Bob initially sends a Hello 563 with version 1.20. Bob ignores Alice's 2.00 Hello and continues 564 to send his 1.20 Hello. Alice detects that Bob does not support 565 2.00 and she stops sending her 2.00 Hellos and starts sending a 566 stream of 1.10 Hellos. Bob sees the 1.10 Hello from Alice and 567 stops sending his 1.20 Hellos and switches to sending 1.10 Hellos. 568 At that point, they have converged on using version 1.10 and the 569 protocol proceeds on that basis. 571 When comparing protocol versions, a ZRTP endpoint MUST include only 572 the first three octets of the version field in the comparison. The 573 final octet is ignored, because it is not significant for 574 interoperability. For example, "1.1 ", "1.10", "1.11", or "1.1a" are 575 all regarded as a version match, because they would all be 576 interoperable versions. 578 Changes in protocol version numbers are expected to be infrequent 579 after version 1.10. Supporting multiple versions adds code 580 complexity and may introduce security weaknesses in the 581 implementation. The old adage about keeping it simple applies 582 especially to implementing security protocols. Endpoints SHOULD NOT 583 support protocol versions earlier than version 1.10. 585 4.1.2. Algorithm Negotiation 587 A method is provided to allow the two parties to mutually and 588 deterministically choose the same DH key size and algorithm before a 589 Commit message is sent. 591 Each Hello message lists the algorithms in the order of preference 592 for that ZRTP endpoint. Endpoints eliminate the non-intersecting 593 choices from each of their own lists, resulting in each endpoint 594 having a list of algorithms in common that might or might not be 595 ordered the same as the other endpoint's list. Each endpoint 596 compares the first item on their own list with the first item on the 597 other endpoint's list, and SHOULD choose the faster of the two 598 algorithms. For example: 600 o Alice's full list: DH2K, DH3K, EC25 601 o Bob's full list: EC38, EC25, DH3K 602 o Alice's intersecting list: DH3K, EC25 603 o Bob's intersecting list: EC25, DH3K 604 o Alice's first preference is DH3K, and Bob's first preference is 605 EC25. 606 o Thus, both parties choose EC25 (ECDH-256), because it's faster. 608 To decide which DH algorithm is faster, the following ranking is 609 defined: DH2K, EC25, DH3K, EC38, EC52. These are all drawn from the 610 table in Section 5.1.5. 612 If both endpoints follow this method, they may each start their DH 613 calculations as soon as they receive the Hello message, and there 614 will be no need for either endpoint to discard their DH calculation 615 if the other endpoint becomes the initiator. 617 This method is used only to negotiate DH key size. For the rest of 618 the algorithm choices, it's simply whatever the initiator selects 619 from the algorithms in common. Note that the DH key size influences 620 the hash type and the size of the symmetric cipher key, as explained 621 in Section 5.1.5. 623 Unfavorable choices will never be made by this method, because each 624 endpoint will omit from their respective lists choices that are too 625 slow or not secure enough to meet their security policy. 627 4.2. Commit Contention 629 After both parties have received compatible Hello messages, a Commit 630 message (Section 5.4) can be sent to begin the ZRTP key exchange. 631 The endpoint that sends the Commit is known as the initiator, while 632 the receiver of the Commit is known as the responder. 634 If both sides send Commit messages initiating a secure session at the 635 same time the following rules are used to break the tie: 637 o If one Commit is for a DH mode while the other is for Preshared 638 mode, then the Preshared Commit MUST be discarded and the DH 639 Commit proceeds. 640 o If the two Commits are both Preshared mode, and one party has set 641 the MiTM (M) flag in the Hello message and the other has not, the 642 Commit message from the party who set the (M) flag MUST be 643 discarded, and the one who has not set the (M) flag becomes the 644 initiator, regardless of the nonce values. In other words, for 645 Preshared mode, the phone is the initiator and the PBX is the 646 responder. 647 o If the two Commits are either both DH modes or both non-DH modes, 648 then the Commit message with the lowest hvi (hash value of 649 initiator) value (for DH Commits), or lowest nonce value (for 650 non-DH Commits), MUST be discarded and the other side is the 651 initiator, and the protocol proceeds with the initiator's Commit. 652 The two hvi or nonce values are compared as large unsigned 653 integers in network byte order. 655 If one Commit is for Multistream mode while the other is for non- 656 Multistream (DH or Preshared) mode, a software error has occurred and 657 the ZRTP negotiation should be terminated. This should never occur 658 because of the constraints on Multistream mode described in 659 Section 4.4.3. 661 In the event that Commit messages are sent by both ZRTP endpoints at 662 the same time, but are received in different media streams, the same 663 resolution rules apply as if they were received on the same stream. 664 The media stream in which the Commit was received or sent will 665 proceed through the ZRTP exchange while the media stream with the 666 discarded Commit must wait for the completion of the other ZRTP 667 exchange. 669 If a commit contention forces a DH Commit message to be discarded, 670 the responder's DH public value should only be discarded if it does 671 not match the initiator's DH key size. 673 4.3. Matching Shared Secret Determination 675 The following sections describe how ZRTP endpoints generate and/or 676 use the set of shared secrets s1, auxsecret, and pbxsecret through 677 the exchange of the DHPart1 and DHPart2 messages. This doesn't cover 678 the Diffie-Hellman calculations. It only covers the method whereby 679 the two parties determine if they already have shared secrets in 680 common in their caches. 682 Each ZRTP endpoint maintains a long-term cache of shared secrets that 683 it has previously negotiated with the other party. The ZID of the 684 other party, received in the other party's Hello message, is used as 685 an index into this cache to find the set of shared secrets, if any 686 exist. This cache entry may contain previously retained shared 687 secrets, rs1 and rs2, which give ZRTP its key continuity features. 688 If the other party is a PBX, the cache may also contain a trusted 689 MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1. 691 The DHPart1 and DHPart2 messages contain a list of hashes of these 692 shared secrets to allow the two endpoints to compare the hashes with 693 what they have in their caches to detect whether the two sides share 694 any secrets that can be used in the calculation of the session key. 695 The use of this shared secret cache is described in Section 4.9. 697 If no secret of a given type is available, a random value is 698 generated and used for that secret to ensure a mismatch in the hash 699 comparisons in the DHPart1 and DHPart2 messages. This prevents an 700 eavesdropper from knowing which types of shared secrets are available 701 between the endpoints. 703 Section 4.3.1 refers to the auxiliary shared secret auxsecret. The 704 auxsecret shared secret may be defined by the VoIP user agent out-of- 705 band from the ZRTP protocol. In some cases it may be provided by the 706 signaling layer as srtps, which is defined in Section 8.2. If it is 707 not provided by the signaling layer, the auxsecret shared secret may 708 be manually provisioned in other application-specific ways that are 709 out-of-band, such as computed from a hashed pass phrase by prior 710 agreement between the two parties, or supplied by a hardware token. 711 Or it may be a family key used by an institution that the two parties 712 both belong to. It is a generalized mechanism for providing a shared 713 secret that is agreed to between the two parties out of scope of the 714 ZRTP protocol. It is expected that most typical ZRTP endpoints will 715 rarely use auxsecret. 717 For both the initiator and the responder, the shared secrets s1, s2, 718 and s3 will be calculated so that they can all be used later to 719 calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are 720 calculated by both parties: 722 The shared secret s1 will be either the initiator's rs1 or the 723 initiator's rs2, depending on which of them can be found in the 724 responder's cache. If the initiator's rs1 matches the responder's 725 rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only 726 if that match fails, then if the initiator's rs2 matches the 727 responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. 728 If that match also fails, then s1 MUST be set to null. The 729 complexity of the s1 calculation is to recover from any loss of cache 730 sync from an earlier aborted session, due to the Two Generals' 731 Problem [Byzantine]. 733 The shared secret s2 MUST be set to the value of auxsecret if and 734 only if both parties have matching values for auxsecret, as 735 determined by comparing the hashes of auxsecret sent in the DH 736 messages. If they don't match, s2 MUST be set to null. 738 The shared secret s3 MUST be set to the value of pbxsecret if and 739 only if both parties have matching values for pbxsecret, as 740 determined by comparing the hashes of pbxsecret sent in the DH 741 messages. If they don't match, s3 MUST be set to null. 743 If s1, s2, or s3 have null values, they are assumed to have a zero 744 length for the purposes of hashing them later during the s0 745 calculation in Section 4.4.1.4. 747 The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is 748 described below in Section 4.3.1. 750 4.3.1. Calculation and comparison of hashes of shared secrets 752 Both parties calculate a set of keyed hashes (HMACs) of shared 753 secrets that may be present in each of their caches. These hashes 754 are truncated to the leftmost 64 bits: 756 rs1IDr = HMAC(rs1, "Responder") 757 rs2IDr = HMAC(rs2, "Responder") 758 auxsecretIDr = HMAC(auxsecret, Responder's H3) 759 pbxsecretIDr = HMAC(pbxsecret, "Responder") 760 rs1IDi = HMAC(rs1, "Initiator") 761 rs2IDi = HMAC(rs2, "Initiator") 762 auxsecretIDi = HMAC(auxsecret, Initiator's H3) 763 pbxsecretIDi = HMAC(pbxsecret, "Initiator") 765 The responder sends rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr in 766 the DHPart1 message. The initiator sends rs1IDi, rs2IDi, 767 auxsecretIDi, and pbxsecretIDi in the DHPart2 message. 769 The responder uses the locally computed rs1IDi, rs2IDi, auxsecretIDi, 770 and pbxsecretIDi to compare against the corresponding fields in the 771 received DHPart2 message. The initiator uses the locally computed 772 rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr to compare against the 773 corresponding fields in the received DHPart1 message. 775 From these comparisons, s1, s2, and s3 are calculated per the methods 776 described above in Section 4.3. The secrets corresponding to 777 matching HMACs are kept while the secrets corresponding to the non- 778 matching ones are replaced with a null, which is assumed to have a 779 zero length for the purposes of hashing them later. The resulting 780 s1, s2, and s3 values are used later to calculate s0 in 781 Section 4.4.1.4. 783 For example, consider two ZRTP endpoints who share secrets rs1 and 784 pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID 785 and pbxsecretID will match but auxsecretID will not. As a result, s1 786 = rs1, s2 will be null, and s3 = pbxsecret. 788 4.3.2. Handling a Shared Secret Cache Mismatch 790 A shared secret cache mismatch is defined to mean that we expected a 791 cache match because rs1 exists in our local cache, but we computed a 792 null value for s1 (per the method described in Section 4.3). 794 If one party has a cached shared secret and the other party does not, 795 this indicates one of two possible situations. Either there is a 796 man-in-the-middle (MiTM) attack, or one of the legitimate parties has 797 lost their cached shared secret by some mishap. Perhaps they 798 inadvertently deleted their cache, or their cache was lost or 799 disrupted due to restoring their disk from an earlier backup copy. 800 The party that has the surviving cache entry can easily detect that a 801 cache mismatch has occurred, because they expect their own cached 802 secret to match the other party's cached secret, but it does not 803 match. It is possible for both parties to detect this condition if 804 both parties have surviving cached secrets that have fallen out of 805 sync, due perhaps to one party restoring from a disk backup. 807 If either party discovers a cache mismatch, the user agent who makes 808 this discovery must treat this as a possible security event and MUST 809 alert their own user that there is a heightened risk of a MiTM 810 attack, and that the user should verbally compare the SAS with the 811 other party to ascertain that no MiTM attack has occurred. If a 812 cache mismatch is detected and it is not possible to compare the SAS, 813 either because the user interface does not support it or because one 814 or both endpoints are unmanned devices, and no other SAS comparison 815 mechanism is available, the session MAY be terminated. 817 The session need not be terminated on a cache mismatch event if: 819 o the mechanism described in Section 8.1.1 is available, which 820 allows authentication of the DH exchange without human assistance, 821 or 822 o any mechanism is available to determine if the SAS matches. This 823 would require either circumstances that allow human verbal 824 comparisons of the SAS, or by using the OPTIONAL digital signature 825 feature on the SAS hash, as described in Section 7.2. 827 Even if the user interface does not permit an SAS comparison, the 828 human user MUST be warned, and may elect to proceed with the call at 829 their own risk. 831 If and only if a cache mismatch event occurs, the cache update 832 mechanism in Section 4.6.1 is affected, requiring the user to verify 833 the SAS before the cache is updated. The user will thus be alerted 834 of this security condition on every call until the SAS is verified. 835 This is described in Section 4.6.1.1. 837 Here is a non-normative example of a cache-mismatch alert message 838 from a ZRTP user agent (specifically, Zfone [zfone]), designed for a 839 desktop PC graphical user interface environment. It is by no means 840 required that the alert be this detailed: 842 "We expected the other party to have a shared secret cached from a 843 previous call, but they don't have it. This may mean your partner 844 simply lost his cache of shared secrets, but it could also mean 845 someone is trying to wiretap you. To resolve this question you 846 must check the authentication string with your partner. If it 847 doesn't match, it indicates the presence of a wiretapper." 848 If the alert is rendered by a robot voice instead of a GUI, 849 brevity may be more important: "Something's wrong. You must check 850 the authentication string with your partner. If it doesn't match, 851 it indicates the presence of a wiretapper." 853 A mismatch of auxsecret is handled differently than a mismatch of 854 rs1. An auxsecret mismatch is defined to mean that auxsecret exists 855 locally, but we computed a null value for s2 (per the method 856 described in Section 4.3). This mismatch should be made visible to 857 whichever user has auxsecret defined. The mismatch should be made 858 visible to both users if they both have auxsecret defined but they 859 fail to match. The severity of the user notification is 860 implementation dependent. Aborting the session is not required. If 861 auxsecret matches, it should not excuse a mismatch of rs1, which 862 still requires a strong warning to the user. 864 4.4. DH and non-DH key agreements 866 The next step is the generation of a secret for deriving SRTP keying 867 material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, 868 described in the following sections. 870 4.4.1. Diffie-Hellman Mode 872 The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman 873 or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP 874 endpoints to generate a new shared secret, s0. In addition, the 875 endpoints discover if they have any cached or previously stored 876 shared secrets in common, and uses them as part of the calculation of 877 the session keys. 879 Because the DH exchange affects the state of the retained shared 880 secret cache, only one in-process ZRTP DH exchange may occur at a 881 time between two ZRTP endpoints. Otherwise, race conditions and 882 cache integrity problems will result. When multiple media streams 883 are established in parallel between the same pair of ZRTP endpoints 884 (determined by the ZIDs in the Hello Messages), only one can be 885 processed. Once that exchange completes with Confirm2 and Conf2ACK 886 messages, another ZRTP DH exchange can begin. This constraint does 887 not apply when Multistream mode key agreement is used since the 888 cached shared secrets are not affected. 890 4.4.1.1. Hash Commitment in Diffie-Hellman Mode 892 From the intersection of the algorithms in the sent and received 893 Hello messages, the initiator chooses a hash, cipher, auth tag, key 894 agreement type, and SAS type to be used. 896 A Diffie-Hellman mode is selected by setting the Key Agreement Type 897 in the Commit to one of the DH or ECDH values from the table in 898 Section 5.1.5. In this mode, the key agreement begins with the 899 initiator choosing a fresh random Diffie-Hellman (DH) secret value 900 (svi) based on the chosen key agreement type value, and computing the 901 public value. (Note that to speed up processing, this computation 902 can be done in advance.) For guidance on generating random numbers, 903 see Section 4.8. 905 For Finite Field Diffie-Hellman, the value for the DH generator g, 906 the DH prime p, and the length of the DH secret value, svi, are 907 defined in Section 5.1.5. 909 pvi = g^svi mod p 911 where g and p are determined by the key agreement type value. The 912 pvi value is formatted as a big-endian octet string, fixed to the 913 bit-length of the DH prime, and leading zeros MUST NOT be truncated. 915 For Elliptic Curve DH, pvi is calculated and formatted according to 916 the ECDH specification in Section 5.1.5, which refers in detail to 917 certain sections of NIST SP 800-56A. 919 The hash commitment is performed by the initiator of the ZRTP 920 exchange. The hash value of the initiator, hvi, includes a hash of 921 the entire DHPart2 message as shown in Figure 9 (which includes the 922 Diffie-Hellman public value, pvi), and the responder's Hello message 923 (where '||' means concatenation). The hvi hash is truncated to 256 924 bits: 926 hvi = hash(initiator's DHPart2 message || responder's Hello 927 message) 929 Note that the Hello message includes the fields shown in Figure 3. 931 The information from the responder's Hello message is included in the 932 hash calculation to prevent a bid-down attack by modification of the 933 responder's Hello message. 935 The initiator sends hvi in the Commit message. 937 The use of hash commitment in the DH exchange constrains the attacker 938 to only one guess to generate the correct short authentication string 939 (SAS) (Section 7) in his attack, which means the SAS can be quite 940 short. A 16-bit SAS, for example, provides the attacker only one 941 chance out of 65536 of not being detected. 943 4.4.1.2. Responder Behavior in Diffie-Hellman Mode 945 Upon receipt of the Commit message, the responder generates its own 946 fresh random DH secret value, svr, and computes the public value. 947 (Note that to speed up processing, this computation can be done in 948 advance.) For guidance on random number generation, see Section 4.8. 950 For Finite Field Diffie-Hellman, the value for the DH generator g, 951 the DH prime p, and the length of the DH secret value, svr, are 952 defined in Section 5.1.5. 954 pvr = g^svr mod p 956 The pvr value is formatted as a big-endian octet string, fixed to the 957 bit-length of the DH prime, and leading zeros MUST NOT be truncated. 959 For Elliptic Curve DH, pvr is calculated and formatted according to 960 the ECDH specification in Section 5.1.5, which refers in detail to 961 certain sections of NIST SP 800-56A. 963 Upon receipt of the DHPart2 message, the responder checks that the 964 initiator's public DH value is not equal to 1 or p-1. An attacker 965 might inject a false DHPart2 message with a value of 1 or p-1 for 966 g^svi mod p, which would cause a disastrously weak final DH result to 967 be computed. If pvi is 1 or p-1, the user should be alerted of the 968 attack and the protocol exchange MUST be terminated. Otherwise, the 969 responder computes its own value for the hash commitment using the 970 public DH value (pvi) received in the DHPart2 message and its Hello 971 message and compares the result with the hvi received in the Commit 972 message. If they are different, a MiTM attack is taking place and 973 the user is alerted and the protocol exchange terminated. 975 The responder then calculates the Diffie-Hellman result: 977 DHResult = pvi^svr mod p 979 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode 981 Upon receipt of the DHPart1 message, the initiator checks that the 982 responder's public DH value is not equal to 1 or p-1. An attacker 983 might inject a false DHPart1 message with a value of 1 or p-1 for 984 g^svr mod p, which would cause a disastrously weak final DH result to 985 be computed. If pvr is 1 or p-1, the user should be alerted of the 986 attack and the protocol exchange MUST be terminated. 988 The initiator then sends a DHPart2 message containing the initiator's 989 public DH value and the set of calculated shared secret IDs as 990 defined in Section 4.3.1. 992 The initiator calculates the same Diffie-Hellman result using: 994 DHResult = pvr^svi mod p 996 4.4.1.4. Shared Secret Calculation for DH Mode 998 A hash of the received and sent ZRTP messages in the current ZRTP 999 exchange in the following order is calculated by both parties: 1001 total_hash = hash(Hello of responder || Commit || DHPart1 || 1002 DHPart2) 1004 Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and 1005 Figure 9), not the entire ZRTP packets, are included in the 1006 total_hash. 1008 For both the initiator and responder, the DHResult is formatted as a 1009 big-endian octet string, fixed to the width of the DH prime, and 1010 leading zeros MUST NOT be truncated. For example, for a 3072-bit p, 1011 DHResult would be a 384 octet value, with the first octet the most 1012 significant. DHResult may also be the result of an ECDH calculation, 1013 which is discussed in Section 5.1.5. 1015 Key | Size of 1016 Agreement | DHResult 1017 ------------------------ 1018 DH-3072 | 384 octets 1019 ------------------------ 1020 DH-2048 | 256 octets 1021 ------------------------ 1022 ECDH P-256 | 32 octets 1023 ------------------------ 1024 ECDH P-384 | 48 octets 1025 ------------------------ 1027 The calculation of the final shared secret, s0, is in compliance with 1028 the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A 1029 [SP800-56A]. This is done by hashing a concatenation of a number of 1030 items, including the DHResult, the ZID's of the initiator (ZIDi) and 1031 the responder (ZIDr), the total_hash, and the set of non-null shared 1032 secrets as described in Section 4.3. 1034 In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires 1035 certain parameters to be hashed together in a particular order, which 1036 NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, 1037 SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult 1038 corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our 1039 ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash 1040 corresponds to SuppPubInfo, and the set of three shared secrets s1, 1041 s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit 1042 big-endian integer counter to be included in the hash each time the 1043 hash is computed, which we have set to the fixed value of 1, because 1044 we only compute the hash once. NIST refers to the final hash output 1045 as DerivedKeyingMaterial, which corresponds to our s0 in this 1046 calculation. 1048 s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi || ZIDr 1049 || total_hash || len(s1) || s1 || len(s2) || s2 || len(s3) || s3) 1051 Note that temporary values s1, s2, and s3 were calculated per the 1052 methods described above in Section 4.3. DHResult, s1, s2, and s3 1053 MUST all be erased from memory immediately after they are used to 1054 calculate s0. 1056 The length of the DHResult field was implicitly agreed to by the 1057 negotiated DH prime size. The length of total_hash is implicitly 1058 determined by the negotiated hash algorithm. All of the explicit 1059 length fields, len(), in the above hash are 32-bit big-endian 1060 integers, giving the length in octets of the field that follows. 1061 Some members of the set of shared secrets (s1, s2, and s3) may have 1062 lengths of zero if they are null (not shared), and are each preceded 1063 by a 4-octet length field. For example, if s2 is null, len(s2) is 1064 0x00000000, and s2 itself would be absent from the hash calculation, 1065 which means len(s3) would immediately follow len(s2). While 1066 inclusion of ZIDi and ZIDr may be redundant, because they are 1067 implicitly included in the total_hash, we explicitly include them 1068 here to follow NIST SP 800-56A. The fixed-length string "ZRTP-HMAC- 1069 KDF" (not null-terminated) identifies what purpose the resulting s0 1070 will be used for, which is to serve as the key derivation key for the 1071 ZRTP HMAC-based key derivation function (KDF) defined in 1072 Section 4.5.1 and used in Section 4.5.3. 1074 ZRTP DH mode is in full compliance with two relevant NIST documents 1075 that cover key derivations. First, section 5.8.1 of NIST SP 800-56A 1076 [SP800-56A] computes what NIST refers to as DerivedKeyingMaterial, 1077 which ZRTP refers to as s0. This s0 then serves as the key 1078 derivation key, which NIST refers to as KI in the key derivation 1079 function described in sections 5 and 5.1 of NIST SP 800-108 1080 [SP800-108], to derive all the rest of the subkeys needed by ZRTP. 1081 For ECDH mode, the s0 calculation is also in compliance with section 1082 3.1 of NSA's Suite B Implementer's Guide to NIST SP 800-56A 1083 [NSA-Suite-B-Guide-56A]. 1085 The ZRTP key derivation function (KDF) (Section 4.5.1) requires the 1086 use of a KDF Context field (per NIST SP 800-108 [SP800-108] 1087 guidelines) which should include the ZIDi, ZIDr, and a nonce value 1088 known to both parties. The total_hash qualifies as a nonce value, 1089 because its computation included nonce material from the initiator's 1090 Commit message and the responder's Hello message. 1092 KDF_Context = (ZIDi || ZIDr || total_hash) 1094 At this point in DH mode, the two endpoints proceed to the key 1095 derivations of ZRTPSess and the rest of the keys in Section 4.5.2, 1096 now that there is a defined s0. 1098 4.4.2. Preshared Mode 1100 The Preshared key agreement mode can be used to generate SRTP keys 1101 and salts without a DH calculation, instead relying on a shared 1102 secret from previous DH calculations between the endpoints. 1104 This key agreement mode is useful to rapidly re-establish a secure 1105 session between two parties who have recently started and ended a 1106 secure session that has already performed a DH key agreement, without 1107 performing another lengthy DH calculation, which may be desirable on 1108 slow processors in resource-limited environments. Preshared mode 1109 MUST NOT be used for adding additional media streams to an existing 1110 call. Multistream mode MUST be used for this purpose. 1112 In the most severe resource-limited environments, Preshared mode may 1113 be useful with processors that cannot perform a DH calculation in an 1114 ergonomically acceptable time limit. Shared key material may be 1115 manually provisioned between two such endpoints in advance and still 1116 allow a limited subset of functionality. Such a "better than 1117 nothing" implementation would have to be regarded as non-compliant 1118 with the ZRTP specification, but it could interoperate in Preshared 1119 (and if applicable, Multistream) mode with a compliant ZRTP endpoint. 1121 Because Preshared mode affects the state of the retained shared 1122 secret cache, only one in-process ZRTP Preshared exchange may occur 1123 at a time between two ZRTP endpoints. This rule is explained in more 1124 detail in Section 4.4.1, and applies for the same reasons as in DH 1125 mode. 1127 Preshared mode is only included in this specification to meet the 1128 R-REUSE requirement in the Media Security Requirements [RFC5479] 1129 document. A series of preshared-keyed calls between two ZRTP 1130 endpoints should use a DH key exchange periodically. Preshared mode 1131 is only used if a cached shared secret has been established in an 1132 earlier session by a DH exchange, as discussed in Section 4.9. 1134 4.4.2.1. Commitment in Preshared Mode 1136 Preshared mode is selected by setting the Key Agreement Type to 1137 Preshared in the Commit message. This results in the same call flow 1138 as Multistream mode. The principal difference between Multistream 1139 mode and Preshared mode is that Preshared mode uses a previously 1140 cached shared secret, rs1, instead of an active ZRTP Session key, 1141 ZRTPSess, as the initial keying material. 1143 Preshared mode depends on having a reliable shared secret in its 1144 cache. Before Preshared mode is used, the initial DH exchange that 1145 gave rise to the shared secret SHOULD have used at least one of these 1146 anti-MiTM mechanisms: 1) A verbal comparison of the SAS, evidenced by 1147 the SAS Verified flag, or 2) an end-to-end integrity-protected 1148 delivery of the a=zrtp-hash in the signaling (Section 8.1.1), or 3) a 1149 digital signature on the sashash (Section 7.2). 1151 4.4.2.2. Initiator Behavior in Preshared Mode 1153 The Commit message (Figure 7) is sent by the initiator of the ZRTP 1154 exchange. From the intersection of the algorithms in the sent and 1155 received Hello messages, the initiator chooses a hash, cipher, auth 1156 tag, key agreement type, and SAS type to be used. 1158 To assemble a Preshared commit, we must first construct a temporary 1159 preshared_key, which is constructed from one of several possible 1160 combinations of cached key material, depending on what is available 1161 in the shared secret cache. If rs1 is not available in the 1162 initiator's cache, then Preshared mode MUST NOT be used. 1164 preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || 1165 auxsecret || len(pbxsecret) || pbxsecret) 1167 All of the explicit length fields, len(), in the above hash are 32- 1168 bit big-endian integers, giving the length in octets of the field 1169 that follows. Some members of the set of shared secrets (rs1, 1170 auxsecret, and pbxsecret) may have lengths of zero if they are null 1171 (not available), and are each preceded by a 4-octet length field. 1172 For example, if auxsecret is null, len(auxsecret) is 0x00000000, and 1173 auxsecret itself would be absent from the hash calculation, which 1174 means len(pbxsecret) would immediately follow len(auxsecret). 1176 In place of hvi in the Commit message, two smaller fields are 1177 inserted by the initiator: 1179 - A random nonce of length 4-words (16 octets). 1180 - A keyID = HMAC(preshared_key, "Prsh") truncated to 64 bits. 1182 Note: Since the nonce is used to calculate different SRTP key and 1183 salt pairs for each session, a duplication will result in the same 1184 key and salt being generated for the two sessions, which would 1185 have disastrous security consequences. 1187 4.4.2.3. Responder Behavior in Preshared Mode 1189 The responder uses the received keyID to search for matching key 1190 material in its cache. It does this by computing a preshared_key 1191 value and keyID value using the same formula as the initiator, 1192 depending on what is available in the responder's local cache. If 1193 the locally computed keyID does not match the received keyID in the 1194 Commit, the responder recomputes a new preshared_key and keyID from a 1195 different subset of shared keys from the cache, dropping auxsecret or 1196 pbxsecret or both from the hash calculation, until a matching 1197 preshared_key is found or it runs out of possibilities. Note that 1198 rs2 is not included in the process. 1200 If it finds the appropriate matching shared key material, it is used 1201 to derive s0 and a new ZRTPSess key, as described in the next section 1202 on Shared Secret Calculation, Section 4.4.2.4. 1204 If the responder determines that it does not have a cached shared 1205 secret from a previous DH exchange, or it fails to match the keyID 1206 hash from the initiator with any combination of its shared keys, it 1207 SHOULD respond with its own DH Commit message. This would reverse 1208 the roles and the responder would become the initiator, because the 1209 DH Commit must always "trump" the Preshared Commit message as 1210 described in Section 4.2. The key exchange would then proceed using 1211 DH mode. However, if a severely resource-limited responder lacks the 1212 computing resources to respond in a reasonable time with a DH Commit, 1213 it MAY respond with a ZRTP Error message (Section 5.9) indicating 1214 that no shared secret is available. 1216 If both sides send Preshared Commit messages initiating a secure 1217 session at the same time, the contention is resolved and the 1218 initiator/responder roles are settled according to Section 4.2, and 1219 the protocol proceeds. 1221 In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. 1222 After receiving the Commit message from the initiator, the responder 1223 sends the Confirm1 message after calculating this stream's SRTP keys, 1224 as described below. 1226 4.4.2.4. Shared Secret Calculation for Preshared Mode 1228 Preshared mode requires that the s0 and ZRTPSess keys be derived from 1229 the preshared_key, and this must be done in a way that guarantees 1230 uniqueness for each session. This is done by using nonce material 1231 from both parties: the explicit nonce in the initiator's Preshared 1232 Commit message (Figure 7) and the H3 field in the responder's Hello 1233 message (Figure 3). Thus both parties force the resulting shared 1234 secret to be unique for each session. 1236 A hash of the received and sent ZRTP messages in the current ZRTP 1237 exchange for the current media stream is calculated: 1239 total_hash = hash(Hello of responder || Commit) 1241 Note that only the ZRTP messages (Figure 3 and Figure 7), not the 1242 entire ZRTP packets, are included in the total_hash. 1244 The ZRTP key derivation function (KDF) (Section 4.5.1) requires the 1245 use of a KDF Context field (per NIST SP 800-108 [SP800-108] 1246 guidelines) which should include the ZIDi, ZIDr, and a nonce value 1247 known to both parties. The total_hash qualifies as a nonce value, 1248 because its computation included nonce material from the initiator's 1249 Commit message and the responder's Hello message. 1251 KDF_Context = (ZIDi || ZIDr || total_hash) 1253 The s0 key is derived via the ZRTP key derivation function 1254 (Section 4.5.1) from preshared_key and the nonces implicitly included 1255 in the total_hash. The nonces also ensure KDF_Context is unique for 1256 each session, which is critical for security. 1258 s0 = KDF(preshared_key, "ZRTP PSK", KDF_Context, negotiated hash 1259 length) 1261 The preshared_key MUST be erased as soon as it has been used to 1262 calculate s0. 1264 At this point in Preshared mode, the two endpoints proceed to the key 1265 derivations of ZRTPSess and the rest of the keys in Section 4.5.2, 1266 now that there is a defined s0. 1268 4.4.3. Multistream Mode 1270 The Multistream key agreement mode can be used to generate SRTP keys 1271 and salts for additional media streams established between a pair of 1272 endpoints. Multistream mode cannot be used unless there is an active 1273 SRTP session established between the endpoints which means a ZRTP 1274 Session key is active. This ZRTP Session key can be used to generate 1275 keys and salts without performing another DH calculation. In this 1276 mode, the retained shared secret cache is not used or updated. As a 1277 result, multiple ZRTP Multistream mode exchanges can be processed in 1278 parallel between two endpoints. 1280 Multistream mode is also used to resume a secure call that has gone 1281 clear using a GoClear message as described in Section 4.7.2.1. 1283 When adding additional media streams to an existing call, Multistream 1284 mode MUST be used. The first media stream MUST use either DH mode or 1285 Preshared mode. Only one DH exchange or Preshared exchange is 1286 performed, just for the first media stream. The DH exchange or 1287 Preshared exchange MUST be completed for the first media stream 1288 before Multistream mode is used to add any other media streams. In a 1289 Multistream session, a ZRTP endpoint MUST use the same ZID for all 1290 media streams, matching the ZID used in the first media stream. 1292 4.4.3.1. Commitment in Multistream Mode 1294 Multistream mode is selected by the initiator setting the Key 1295 Agreement Type to "Mult" in the Commit message (Figure 6). The 1296 Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be 1297 set by the initiator to the same as the values as in the initial DH 1298 Mode Commit. The SAS Type is ignored as there is no SAS 1299 authentication in this mode. 1301 Note: This requirement is needed since some endpoints cannot 1302 support different SRTP algorithms for different media streams. 1303 However, in the case of Multistream mode being used to go secure 1304 after a GoClear, the requirement to use the same SRTP algorithms 1305 is relaxed if there are no other active SRTP sessions. 1307 In place of hvi in the Commit, a random nonce of length 4-words (16 1308 octets) is chosen. Its value MUST be unique for all nonce values 1309 chosen for active ZRTP sessions between a pair of endpoints. If a 1310 Commit is received with a reused nonce value, the ZRTP exchange MUST 1311 be immediately terminated. 1313 Note: Since the nonce is used to calculate different SRTP key and 1314 salt pairs for each media stream, a duplication will result in the 1315 same key and salt being generated for the two media streams, which 1316 would have disastrous security consequences. 1318 If a Commit is received selecting Multistream mode, but the responder 1319 does not have a ZRTP Session Key available, the exchange MUST be 1320 terminated. Otherwise, the responder proceeds to the next section on 1321 Shared Secret Calculation, Section 4.4.3.2. 1323 If both sides send Multistream Commit messages at the same time, the 1324 contention is resolved and the initiator/responder roles are settled 1325 according to Section 4.2, and the protocol proceeds. 1327 In Multistream mode, both the DHPart1 and DHPart2 messages are 1328 skipped. After receiving the Commit message from the initiator, the 1329 responder sends the Confirm1 message after calculating this stream's 1330 SRTP keys, as described below. 1332 4.4.3.2. Shared Secret Calculation for Multistream Mode 1334 In Multistream mode, each media stream requires that a set of keys be 1335 derived from the ZRTPSess key, and this must be done in a way that 1336 guarantees uniqueness for each media stream. This is done by using 1337 nonce material from both parties: the explicit nonce in the 1338 initiator's Multistream Commit message (Figure 6) and the H3 field in 1339 the responder's Hello message (Figure 3). Thus both parties force 1340 the resulting shared secret to be unique for each media stream. 1342 A hash of the received and sent ZRTP messages in the current ZRTP 1343 exchange for the current media stream is calculated: 1345 total_hash = hash(Hello of responder || Commit) 1347 This refers to the Hello and Commit messages for the current media 1348 stream which is using Multistream mode, not the original media stream 1349 that included a full DH key agreement. Note that only the ZRTP 1350 messages (Figure 3 and Figure 6), not the entire ZRTP packets, are 1351 included in the hash. 1353 The ZRTP key derivation function (KDF) (Section 4.5.1) requires the 1354 use of a KDF Context field (per NIST SP 800-108 [SP800-108] 1355 guidelines) which should include the ZIDi, ZIDr, and a nonce value 1356 known to both parties. The total_hash qualifies as a nonce value, 1357 because its computation included nonce material from the initiator's 1358 Commit message and the responder's Hello message. 1360 KDF_Context = (ZIDi || ZIDr || total_hash) 1362 The current stream's SRTP keys and salts for the initiator and 1363 responder are calculated using the ZRTP Session Key ZRTPSess and the 1364 nonces implicitly included in the total_hash. The nonces also ensure 1365 KDF_Context will be unique for each media stream, which is critical 1366 for security. For each additional media stream, a separate s0 is 1367 derived from ZRTPSess via the ZRTP key derivation function 1368 (Section 4.5.1): 1370 s0 = KDF(ZRTPSess, "ZRTP MSK", KDF_Context, negotiated hash 1371 length) 1373 Note that the ZRTPSess key was previously derived from material that 1374 also includes a different and more inclusive total_hash from the 1375 entire packet sequence that performed the original DH exchange for 1376 the first media stream in this ZRTP session. 1378 At this point in Multistream mode, the two endpoints begin key 1379 derivations in Section 4.5.3. 1381 4.5. Key Derivations 1383 4.5.1. The ZRTP Key Derivation Function 1385 To derive keys from a shared secret, ZRTP uses an HMAC-based key 1386 derivation function, or KDF. It is used throughout Section 4.5.3 and 1387 in other sections. The HMAC function for the KDF is based on the 1388 negotiated hash algorithm defined in Section 5.1.2. 1390 The ZRTP KDF is in full compliance with the recommendations in NIST 1391 SP 800-108 [SP800-108]. Section 7.5 of the NIST document describes 1392 "key separation", which is a security requirement for the 1393 cryptographic keys derived from the same key derivation key. The 1394 keys shall be separate in the sense that the compromise of some 1395 derived keys will not degrade the security strength of any of the 1396 other derived keys, or the security strength of the key derivation 1397 key. Strong preimage resistance is provided. 1399 The ZRTP KDF runs the NIST pseudorandom function (PRF) in counter 1400 mode, with only a single iteration of the counter. The NIST PRF is 1401 based on the HMAC function. The ZRTP KDF never has to generate more 1402 than 256 bits (or 384 bits for Suite B applications) of output key 1403 material, so only a single invocation of the HMAC function is needed. 1405 The ZRTP KDF is defined in this manner, per sections 5 and 5.1 of 1406 NIST SP 800-108 [SP800-108]: 1408 KDF(KI, Label, Context, L) = HMAC(KI, i || Label || 0x00 || 1409 Context || L) 1411 The HMAC in the KDF is keyed by KI, which is a secret key derivation 1412 key that is unknown to the wiretapper (for example, s0). The HMAC is 1413 computed on a concatenated set of nonsecret fields that are defined 1414 as follows. The first field is a 32-bit big-endian integer counter 1415 (i) required by NIST to be included in the HMAC each time the HMAC is 1416 computed, which we have set to the fixed value of 0x000001, because 1417 we only compute the HMAC once. Label is a string of nonzero octets 1418 that identifies the purpose for the derived keying material. The 1419 octet 0x00 is a delimiter required by NIST. The NIST KDF formula has 1420 a "Context" field which includes ZIDi, ZIDr, and some optional nonce 1421 material known to both parties. L is a 32-bit big-endian positive 1422 integer, not to exceed the length in bits of the output of the HMAC. 1423 The output of the KDF is truncated to the leftmost L bits. If SHA- 1424 384 is the negotiated hash algorithm, the HMAC would be HMAC-SHA-384, 1425 thus the maximum value of L would be 384, the negotiated hash length. 1427 The ZRTP KDF is not to be confused with the SRTP KDF defined in 1428 [RFC3711]. 1430 4.5.2. Deriving ZRTPSess Key and SAS in DH or Preshared modes 1432 Both DH mode and Preshared mode (but not Multistream mode) come to 1433 this common point in the protocol to derive ZRTPSess and the SAS from 1434 s0, via the ZRTP Key Derivation Function (Section 4.5.1). At this 1435 point, s0 has been calculated, as well as KDF_Context. These 1436 calculations are done only for the first media stream, not for 1437 Multistream mode. 1439 The ZRTPSess key is used only for these two purposes: 1) to generate 1440 the additional s0 keys (Section 4.4.3.2) for adding additional media 1441 streams to this session in Multistream mode, and 2) to generate the 1442 pbxsecret (Section 7.3.1) that may be cached for use in future 1443 sessions. The ZRTPSess key is kept for the duration of the call 1444 signaling session between the two ZRTP endpoints. That is, if there 1445 are two separate calls between the endpoints (in SIP terms, separate 1446 SIP dialogs), then a ZRTP Session Key MUST NOT be used across the two 1447 call signaling sessions. ZRTPSess MUST be destroyed no later than 1448 the end of the call signaling session. 1450 ZRTPSess = KDF(s0, "ZRTP Session Key", KDF_Context, negotiated 1451 hash length) 1453 Note that KDF_Context is unique for each media stream, but only the 1454 first media stream is permitted to calculate ZRTPSess. 1456 There is only one Short Authentication String (SAS) (Section 7) 1457 computed per call, which is applicable to all media streams derived 1458 from a single DH key agreement in a ZRTP session. KDF_Context is 1459 unique for each media stream, but only the first media stream is 1460 permitted to calculate sashash. 1462 sashash = KDF(s0, "SAS", KDF_Context, 256) 1463 sasvalue = sashash [truncated to leftmost 32 bits] 1465 Despite the exposure of the SAS to the two parties, the rest of the 1466 keying material is protected by the key separation properties of the 1467 KDF (Section 4.5.1). 1469 ZRTP-enabled VoIP clients may need to support additional forms of 1470 communication, such as text chat, instant messaging, or file 1471 transfers. These other forms of communication may need to be 1472 encrypted, and would benefit from leveraging the ZRTP key exchange 1473 used for the VoIP part of the call. In that case, more key material 1474 MAY be derived and "exported" from the ZRTP protocol and provided as 1475 a shared secret to the VoIP client for these non-VoIP purposes. The 1476 application can use this exported key in application-specific ways, 1477 outside the scope of the ZRTP protocol. 1479 ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash 1480 length) 1482 Only one ExportedKey is computed per call. KDF_Context is unique for 1483 each media stream, but only the first media stream is permitted to 1484 calculate ExportedKey. 1486 The application may use this exported key to derive other subkeys for 1487 various non-ZRTP purposes, via a KDF using separate KDF label strings 1488 defined by the application. This key or its derived subkeys can be 1489 used for encryption, or used to authenticate other key exchanges 1490 carried out by the application, protected by ZRTP's MiTM defense 1491 umbrella. The exported key and its descendants may be used for as 1492 long as needed by the application, maintained in a separate crypto 1493 context that may outlast the VoIP session. 1495 At this point in DH mode or Preshared mode, the two endpoints proceed 1496 on to the key derivations in Section 4.5.3, now that there is a 1497 defined s0 and ZRTPSess key. 1499 4.5.3. Deriving the rest of the keys from s0 1501 DH mode, Multistream mode, and Preshared mode all come to this common 1502 point in the protocol to derive a set of keys from s0. It can be 1503 assumed that s0 has been calculated, as well the ZRTPSess key and 1504 KDF_Context. A separate s0 key is associated with each media stream. 1506 Subkeys are not drawn directly from s0, as done in NIST SP 800-56A. 1507 To enhance key separation, ZRTP uses s0 to key a Key Derivation 1508 Function (Section 4.5.1) based on NIST SP 800-108 [SP800-108]. Since 1509 s0 already included total_hash in its derivation, it is redundant to 1510 use total_hash again in the KDF Context in all the invocations of the 1511 KDF keyed by s0. Nonetheless, NIST SP 800-108 always requires KDF 1512 Context to be defined for the KDF, and nonce material is required in 1513 some KDF invocations (especially for Multistream mode and Preshared 1514 mode), so total_hash is included as a nonce in the KDF Context. 1516 Separate SRTP master keys and master salts are derived for use in 1517 each direction for each media stream. Unless otherwise specified, 1518 ZRTP uses SRTP with no MKI, 32 bit authentication using HMAC-SHA1, 1519 AES-CM 128 or 256 bit key length, 112 bit session salt key length, 1520 2^48 key derivation rate, and SRTP prefix length 0. Secure RTCP 1521 (SRTCP) is also used, deriving the SRTCP keys from the same master 1522 keys and salts as SRTP, using the mechanisms specified in [RFC3711], 1523 without requiring a separate ZRTP negotiation for RTCP. 1525 The ZRTP initiator encrypts and the ZRTP responder decrypts packets 1526 by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts 1527 and the ZRTP initiator decrypts packets by using srtpkeyr and 1528 srtpsaltr. The SRTP key and salt values are truncated (taking the 1529 leftmost bits) to the length determined by the chosen SRTP profile. 1530 These are generated by: 1532 srtpkeyi = KDF(s0, "Initiator SRTP master key", KDF_Context, 1533 negotiated AES key length) 1534 srtpsalti = KDF(s0, "Initiator SRTP master salt", KDF_Context, 1535 112) 1536 srtpkeyr = KDF(s0, "Responder SRTP master key", KDF_Context, 1537 negotiated AES key length) 1538 srtpsaltr = KDF(s0, "Responder SRTP master salt", KDF_Context, 1539 112) 1541 The HMAC keys are the same length as the output of the underlying 1542 hash function in the KDF, and are thus generated without truncation. 1543 They are used only by ZRTP and not by SRTP. Different HMAC keys are 1544 needed for the initiator and the responder to ensure that GoClear 1545 messages in each direction are unique and can not be cached by an 1546 attacker and reflected back to the endpoint. 1548 hmackeyi = KDF(s0, "Initiator HMAC key", KDF_Context, negotiated 1549 hash length) 1550 hmackeyr = KDF(s0, "Responder HMAC key", KDF_Context, negotiated 1551 hash length) 1553 ZRTP keys are generated for the initiator and responder to use to 1554 encrypt the Confirm1 and Confirm2 messages. They are truncated to 1555 the same size as the negotiated SRTP key size. 1557 zrtpkeyi = KDF(s0, "Initiator ZRTP key", KDF_Context, negotiated 1558 AES key length) 1559 zrtpkeyr = KDF(s0, "Responder ZRTP key", KDF_Context, negotiated 1560 AES key length) 1562 All key material is destroyed as soon as it is no longer needed, no 1563 later than the end of the call. s0 is erased in Section 4.6.1, and 1564 the rest of the session key material is erased in Section 4.7.2.1 and 1565 Section 4.7.3. 1567 4.6. Confirmation 1569 The Confirm1 and Confirm2 messages (Figure 10) contain the cache 1570 expiration interval (defined in Section 4.9) for the newly generated 1571 retained shared secret. The flagoctet is an 8 bit unsigned integer 1572 made up of these flags: the PBX Enrollment flag (E) defined in 1573 Section 7.3.1, SAS Verified flag (V) defined in Section 7.1, Allow 1574 Clear flag (A) defined in Section 4.7.2, and Disclosure flag (D) 1575 defined in Section 11. 1577 flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) 1579 Part of the Confirm1 and Confirm2 messages are encrypted using full- 1580 block Cipher Feedback Mode, and contain a 128-bit random CFB 1581 Initialization Vector (IV). The Confirm1 and Confirm2 messages also 1582 contain an HMAC covering the encrypted part of the Confirm1 or 1583 Confirm2 message which includes a string of zeros, the signature 1584 length, flag octet, cache expiration interval, signature type block 1585 (if present) and signature (Section 7.2) (if present). For the 1586 responder: 1588 confirm_mac = HMAC(hmackeyr, encrypted part of Confirm1) 1590 For the initiator: 1592 confirm_mac = HMAC(hmackeyi, encrypted part of Confirm2) 1594 The hmackeyi and hmackeyr keys are computed in Section 4.5.3. 1596 The exchange is completed when the responder sends either the 1597 Conf2ACK message or the responder's first SRTP media packet (with a 1598 valid SRTP auth tag). The initiator MUST treat the first valid SRTP 1599 media from the responder as equivalent to receiving a Conf2ACK. The 1600 responder may respond to Confirm2 with either SRTP media or Conf2ACK, 1601 or both, in whichever order the responder chooses (or whichever order 1602 the "cloud" chooses to deliver them). 1604 4.6.1. Updating the Cache of Shared Secrets 1606 After receiving the Confirm messages, both parties must now update 1607 their retained shared secret rs1 in their respective caches, provided 1608 the following conditions hold: 1610 1) This key exchange is either DH or Preshared mode, not 1611 Multistream mode, which does not update the cache. 1612 2) Depending on the values of the cache expiration intervals that 1613 are received in the two Confirm messages, there are some scenarios 1614 that do not update the cache, as explained in Section 4.9. 1615 3) The responder MUST receive the initiator's Confirm2 message 1616 before updating the responder's cache. 1617 4) The initiator MUST receive either the responder's Conf2ACK 1618 message or the responder's SRTP media (with a valid SRTP auth tag) 1619 before updating the initiator's cache. 1621 The cache update may also be affected by a cache mismatch, according 1622 to Section 4.6.1.1. 1624 For DH mode only, before updating the retained shared secret rs1 in 1625 the cache, each party first discards their old rs2 and copies their 1626 old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of 1627 session interruption after one party has updated his own rs1 but 1628 before the other party has enough information to update her own rs1. 1629 If that happens, they may regain cache sync in the next session by 1630 using rs2 (per Section 4.3). This mitigates the well-known Two 1631 Generals' Problem [Byzantine]. The old rs1 value is not saved in 1632 Preshared mode. 1634 For DH mode and Preshared mode, both parties compute a new rs1 value 1635 from s0 via the ZRTP key derivation function (Section 4.5.1): 1637 rs1 = KDF(s0, "retained secret", KDF_Context, 256) 1639 Note that KDF_Context is unique for each media stream, but only the 1640 first media stream is permitted to update rs1. 1642 Each media stream has its own s0. At this point in the protocol for 1643 each media stream, the corresponding s0 MUST be erased. 1645 4.6.1.1. Cache Update Following a Cache Mismatch 1647 If a shared secret cache mismatch (as defined in Section 4.3.2) is 1648 detected in the current session, it indicates a possible MiTM attack. 1649 However, there may be evidence to the contrary, if either one of the 1650 following conditions are met: 1652 o Successful use of the mechanism described in Section 8.1.1, but 1653 only if fully supported by end-to-end integrity-protected delivery 1654 of the a=zrtp-hash in the signaling via SIP Identity (RFC 4474) 1655 [RFC4474] or better still, Dan Wing's SIP Identity using Media 1656 Path [I-D.wing-sip-identity-media]. This allows authentication of 1657 the DH exchange without human assistance. 1658 o A good signature is received and verified using the digital 1659 signature feature on the SAS hash, as described in Section 7.2, if 1660 this feature is supported. 1662 If there is a cache mismatch in the absence of the aforementioned 1663 mitigating evidence, the cache update MUST be delayed in the current 1664 session until the user verbally compares the SAS with his partner 1665 during the call and confirms a successful SAS verify via his user 1666 interface as described in Section 7.1. If the session ends before 1667 that happens, the cache update is not performed, leaving the rs1/rs2 1668 values unmodified in the cache. Regardless of whether a cache 1669 mismatch occurs, s0 must still be erased. 1671 If no cache entry exists, as is the case in the initial call, the 1672 cache update is handled in the normal fashion. 1674 4.7. Termination 1676 A ZRTP session is normally terminated at the end of a call, but it 1677 may be terminated early by either the Error message or the GoClear 1678 message. 1680 4.7.1. Termination via Error message 1682 The Error message (Section 5.9) is used to terminate an in-progress 1683 ZRTP exchange due to an error. The Error message contains an integer 1684 Error Code for debugging purposes. The termination of a ZRTP key 1685 agreement exchange results in no updates to the cached shared secrets 1686 and deletion of all crypto context for that media stream. The ZRTP 1687 Session key, ZRTPSess, is only deleted if all ZRTP media streams 1688 which are using it are terminated. 1690 Because no key agreement has been reached, the Error message cannot 1691 use the same HMAC protection as the GoClear message. A denial of 1692 service is possible by injecting fake Error messages. (However, even 1693 if the Error message were somehow designed with integrity protection, 1694 it would raise other questions. What would a badly formed Error 1695 message mean if it were sent to report a badly formed message? A 1696 good message?) 1698 4.7.2. Termination via GoClear message 1700 The GoClear message (Section 5.11) is used to switch from SRTP to 1701 RTP, usually because the user has chosen to do that by pressing a 1702 button. The GoClear uses an HMAC of the Message Type Block sent in 1703 the GoClear Message computed with the hmackey derived from the shared 1704 secret. This HMAC is truncated to the leftmost 64 bits. When sent 1705 by the initiator: 1707 clear_mac = HMAC(hmackeyi, "GoClear ") 1709 When sent by the responder: 1711 clear_mac = HMAC(hmackeyr, "GoClear ") 1713 A GoClear message which does not receive a ClearACK response must be 1714 resent. If a GoClear message is received with a bad HMAC, it must be 1715 ignored, and no ClearACK is sent. 1717 A ZRTP endpoint MAY choose to accept GoClear messages after the 1718 session has switched to SRTP, allowing the session to revert to RTP. 1719 This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by 1720 setting the Allow Clear flag (A). If an endpoint sets the Allow 1721 Clear (A) flag in their Confirm message, it indicates that they 1722 support receiving GoClear messages. 1724 A ZRTP endpoint that receives a GoClear MUST authenticate the message 1725 by checking the clear_mac. If the message authenticates, the 1726 endpoint stops sending SRTP packets, and generates a ClearACK in 1727 response. It MUST also delete all the crypto key material for all 1728 the SRTP media streams, as defined in Section 4.7.2.1. 1730 Until confirmation from the user is received (e.g. clicking a button, 1731 pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending 1732 RTP packets. The endpoint then renders to the user an indication 1733 that the media session has switched to clear mode, and waits for 1734 confirmation from the user. This blocks the flow of sensitive 1735 discourse until the user is forced to take notice that he's no longer 1736 protected by encryption. To prevent pinholes from closing or NAT 1737 bindings from expiring, the ClearACK message MAY be resent at regular 1738 intervals (e.g. every 5 seconds) while waiting for confirmation from 1739 the user. After confirmation of the notification is received from 1740 the user, the sending of RTP packets may begin. 1742 After sending a GoClear message, the ZRTP endpoint stops sending SRTP 1743 packets. When a ClearACK is received, the ZRTP endpoint deletes the 1744 crypto context for the SRTP session, as defined in Section 4.7.2.1, 1745 and may then resume sending RTP packets. 1747 In the event a ClearACK is not received before the retransmissions of 1748 GoClear are exhausted, the key material is deleted, as defined in 1749 Section 4.7.2.1. 1751 After the users have transitioned from SRTP media back to RTP media 1752 (clear mode), they may decide later to return to secure mode by 1753 manual activation, usually by pressing a GO SECURE button. In that 1754 case, a new secure session is initiated by the party that presses the 1755 button, by sending a new Commit message, leading to a new session key 1756 negotiation. It is not necessary to send another Hello message, as 1757 the two parties have already done that at the start of the call and 1758 thus have already discovered each other's ZRTP capabilities. It is 1759 possible for users to toggle back and forth between clear and secure 1760 modes multiple times in the same session, just as they could in the 1761 old days of secure PSTN phones. 1763 4.7.2.1. Key Destruction for GoClear message 1765 All SRTP session key material MUST be erased by the receiver of the 1766 GoClear message upon receiving a properly authenticated GoClear. The 1767 same key destruction MUST be done by the sender of GoClear message, 1768 upon receiving the ClearACK. This must be done for the key material 1769 for all of the media streams. 1771 All key material that would have been erased at the end of the SIP 1772 session MUST be erased, as described in Section 4.7.3, with the 1773 single exception of ZRTPSess. In this case, ZRTPSess is destroyed in 1774 a manner different from the other key material. Both parties replace 1775 ZRTPSess with a KDF-derived non-invertible function of itself: 1777 ZRTPSess = KDF(ZRTPSess, "New ZRTP Session", (ZIDi || ZIDr), 1778 negotiated hash length) 1780 ZRTPSess will be replaced twice if a session generates separate 1781 GoClear messages for both audio and video streams, and the two 1782 endpoints need not carry out the replacements in the same order. 1784 The destruction of key material meets the requirements of Perfect 1785 Forward Secrecy (PFS), but still preserves a new version of ZRTPSess, 1786 so that the user can later re-initiate secure mode during the same 1787 session without performing another Diffie-Hellman calculation using 1788 Multistream mode which requires and assumes the existence of ZRTPSess 1789 with the same value at both ZRTP endpoints. A new key negotiation 1790 after a GoClear SHOULD use a Multistream Commit message. 1792 Note: Multistream mode is preferred over a Diffie-Hellman mode 1793 since this does not require the generation of a new hash chain and 1794 a new signaling exchange to exchange new Hello Hash values. 1796 Later, at the end of the entire call, ZRTPSess is finally destroyed 1797 along with the other key material, as described in Section 4.7.3. 1799 4.7.3. Key Destruction at Termination 1801 All SRTP session key material MUST be erased by both parties at the 1802 end of the call. In particular, the destroyed key material includes 1803 the SRTP session keys and salts, SRTP master keys and salts, and all 1804 material sufficient to reconstruct the SRTP keys and salts, including 1805 ZRTPSess and s0 (although s0 should have been destroyed earlier, in 1806 Section 4.6.1). This must be done for the key material for all of 1807 the media streams. The only exceptions are the cached shared secrets 1808 needed for future sessions, including rs1, rs2, and pbxsecret. 1810 4.8. Random Number Generation 1812 The ZRTP protocol uses random numbers for cryptographic key material, 1813 notably for the DH secret exponents and nonces, which must be freshly 1814 generated with each session. Whenever a random number is needed, all 1815 of the following criteria must be satisfied: 1817 Random numbers MUST be freshly generated, meaning that it must not 1818 have been used in a previous calculation. 1820 When generating a random number k of L bits in length, k MUST be 1821 chosen with equal probability from the range of [1 < k < 2^L]. 1823 It MUST be derived from a physical entropy source, such as RF noise, 1824 acoustic noise, thermal noise, high resolution timings of 1825 environmental events, or other unpredictable physical sources of 1826 entropy. One possible source of entropy for a VoIP client would be 1827 microphone noise. For a detailed explanation of cryptographic grade 1828 random numbers and guidance for collecting suitable entropy, see RFC 1829 4086 [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. 1830 The raw entropy must be distilled and processed through a 1831 deterministic random bit generator (DRBG). Examples of DRBGs may be 1832 found in NIST SP 800-90 [SP800-90], and in [Ferguson]. Failure to 1833 use true entropy from the physical environment as a basis for 1834 generating random cryptographic key material would lead to a 1835 disastrous loss of security. 1837 4.9. ZID and Cache Operation 1839 Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that 1840 is generated once at installation time. It is used to look up 1841 retained shared secrets in a local cache. A single global ZID for a 1842 single installation is the simplest way to implement ZIDs. However, 1843 it is specifically not precluded for an implementation to use 1844 multiple ZIDs, up to the limit of a separate one per callee. This 1845 then turns it into a long-lived "association ID" that does not apply 1846 to any other associations between a different pair of parties. It is 1847 a goal of this protocol to permit both options to interoperate 1848 freely. A PBX acting as a trusted man in the middle will also 1849 generate a single ZID and use that ZID for all endpoints behind it, 1850 as described in Section 10. 1852 There is no protocol mechanism to invalidate a previously used ZID. 1853 An endpoint wishing to change ZID would simply generate a new one and 1854 begin using it. 1856 The ZID should not be hard coded or hard-defined in the firmware of a 1857 product. It should be randomly generated by the software and stored 1858 at installation or initialization time. It should be randomly 1859 generated rather than allocated from a preassigned range of ZID 1860 values, because 96 bits should be enough to avoid birthday collisions 1861 in realistic scenarios. 1863 Each time a new s0 is calculated, a new retained shared secret rs1 is 1864 generated and stored in the cache, indexed by the ZID of the other 1865 endpoint. This cache updating is described in Section 4.6.1. For 1866 the new retained shared secret, each endpoint chooses a cache 1867 expiration value which is an unsigned 32 bit integer of the number of 1868 seconds that this secret should be retained in the cache. The time 1869 interval is relative to when the Confirm1 message is sent or 1870 received. 1872 The cache intervals are exchanged in the Confirm1 and Confirm2 1873 messages (Figure 10). The actual cache interval used by both 1874 endpoints is the minimum of the values from the Confirm1 and Confirm2 1875 messages. A value of 0 seconds means the newly-computed shared 1876 secret SHOULD NOT be stored in the cache, and if a cache entry 1877 already exists from an earlier call, the stored cache interval should 1878 be set to 0. This means if either Confirm message contains a null 1879 cache expiration interval, and there is no cache entry already 1880 defined, no new cache entry is created. A value of 0xffffffff means 1881 the secret should be cached indefinitely and is the recommended 1882 value. If the ZRTP exchange is Multistream Mode, the field in the 1883 Confirm1 and Confirm2 is set to 0xffffffff and ignored, and the cache 1884 is not updated. 1886 The expiration interval need not be used to force the deletion of a 1887 shared secret from the cache when the interval has expired. It just 1888 means the shared secret MAY be deleted from that cache at any point 1889 after the interval has expired without causing the other party to 1890 note it as an unexpected security event when the next key negotiation 1891 occurs between the same two parties. This means there need not be 1892 perfectly synchronized deletion of expired secrets from the two 1893 caches, and makes it easy to avoid a race condition that might 1894 otherwise be caused by clock skew. 1896 If the expiration interval is not properly agreed to by both 1897 endpoints, it may later result in false alarms of MiTM attacks, due 1898 to apparent cache mismatches (Section 4.3.2). 1900 4.9.1. Cacheless implementations 1902 It is possible to implement a simplified but nonetheless useful (and 1903 still compliant) profile of the ZRTP protocol that does not support 1904 any caching of shared secrets. In this case the users would have to 1905 rely exclusively on the verbal SAS comparison for every call. That 1906 is, unless MiTM protection is provided by the mechanisms in 1907 Section 8.1.1 or Section 7.2, which introduce their own forms of 1908 complexity. 1910 If a ZRTP endpoint does not support caching of shared secrets, it 1911 MUST set the cache expiration interval to zero, and MUST set the SAS 1912 Verified (V) flag (Section 7.1) to false. In addition, because the 1913 ZID serves mainly as a cache index, the ZID would not be required to 1914 maintain the same value across separate SIP sessions, although there 1915 is no reason why it should not. 1917 Cacheless operation would sacrifice the key continuity (Section 15.1) 1918 features, as well as Preshared mode (Section 4.4.2). Further, if the 1919 pbxsecret is also not cached, there would be no PBX trusted MiTM 1920 (Section 7.3) features, including the PBX security enrollment 1921 (Section 7.3.1) mechanism. 1923 5. ZRTP Messages 1925 All ZRTP messages use the message format defined in Figure 2. All 1926 word lengths referenced in this specification are 32 bits or 4 1927 octets. All integer fields are carried in network byte order, that 1928 is, most significant byte (octet) first, commonly known as big- 1929 endian. 1931 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 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 |0 0 0 1|Not Used (set to zero) | Sequence Number | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | Magic Cookie 'ZRTP' (0x5a525450) | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | Source Identifier | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | | 1940 | ZRTP Message (length depends on Message Type) | 1941 | . . . | 1942 | | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | CRC (1 word) | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 Figure 2: ZRTP Packet Format 1949 The Sequence Number is a count that is incremented for each ZRTP 1950 packet sent. The count is initialized to a random value. This is 1951 useful in estimating ZRTP packet loss and also detecting when ZRTP 1952 packets arrive out of sequence. 1954 The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a 1955 ZRTP packet, and has the value 0x5a525450. 1957 Source Identifier is the SSRC number of the RTP stream that this ZRTP 1958 packet relates to. For cases of forking or forwarding, RTP and hence 1959 ZRTP may arrive at the same port from several different sources - 1960 each of these sources will have a different SSRC and may initiate an 1961 independent ZRTP protocol session. SSRC collisions would be 1962 disruptive to ZRTP. This may be avoided via the mechanisms in RFC 1963 3550, Section 8.2 [RFC3550]. 1965 This format is clearly identifiable as non-RTP due to the first two 1966 bits being zero which looks like RTP version 0, which is not a valid 1967 RTP version number. It is clearly distinguishable from STUN since 1968 the magic cookies are different. The 12 not used bits are set to 1969 zero and MUST be ignored when received. 1971 The ZRTP Messages are defined in Figure 3 to Figure 17 and are of 1972 variable length. 1974 The ZRTP protocol uses a 32 bit CRC as defined in RFC 4960, Appendix 1975 B [RFC4960] in each ZRTP packet to detect transmission errors. ZRTP 1976 packets are typically transported by UDP, which carries its own 1977 built-in 16-bit checksum for integrity, but ZRTP does not rely on it. 1978 This is because of the effect of an undetected transmission error in 1979 a ZRTP message. For example, an undetected error in the DH exchange 1980 could appear to be an active man-in-the-middle attack. A false 1981 announcement of this by ZRTP clients can be psychologically 1982 distressing. The probability of such a false alarm hinges on a mere 1983 16-bit checksum that usually protects UDP packets, so more error 1984 detection is needed. For these reasons, this belt-and-suspenders 1985 approach is used to minimize the chance of a transmission error 1986 affecting the ZRTP key agreement. 1988 The CRC is calculated across the entire ZRTP packet shown in 1989 Figure 2, including the ZRTP Header and the ZRTP Message, but not 1990 including the CRC field. If a ZRTP message fails the CRC check, it 1991 is silently discarded. 1993 5.1. ZRTP Message Formats 1995 ZRTP messages are designed to simplify endpoint parsing requirements 1996 and to reduce the opportunities for buffer overflow attacks (a good 1997 goal of any security extension should be to not introduce new attack 1998 vectors). 2000 ZRTP uses a block of 8 octets (2 words) to encode the Message Type. 4 2001 octets (1 word) blocks are used to encode Hash Type, Cipher Type, and 2002 Key Agreement Type, and Authentication Tag Type. The values in the 2003 blocks are ASCII strings which are extended with spaces (0x20) to 2004 make them the desired length. Currently defined block values are 2005 listed in Tables 1-6 below. 2007 Additional block values may be defined and used. 2009 ZRTP uses this ASCII encoding to simplify debugging and make it 2010 "Wireshark (Ethereal) friendly". 2012 5.1.1. Message Type Block 2014 Currently 16 Message Type Blocks are defined - they represent the set 2015 of ZRTP message primitives. ZRTP endpoints MUST support the Hello, 2016 HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, 2017 SASrelay, RelayACK, Error, ErrorACK, and PingACK message types. ZRTP 2018 endpoints MAY support the GoClear, ClearACK, and Ping messages. In 2019 order to generate a PingACK message, it is necessary to parse a Ping 2020 message. Additional messages may be defined in extensions to ZRTP. 2022 Message Type Block | Meaning 2023 --------------------------------------------------- 2024 "Hello " | Hello Message 2025 --------------------------------------------------- 2026 "HelloACK" | HelloACK Message 2027 --------------------------------------------------- 2028 "Commit " | Commit Message 2029 --------------------------------------------------- 2030 "DHPart1 " | DHPart1 Message 2031 --------------------------------------------------- 2032 "DHPart2 " | DHPart2 Message 2033 --------------------------------------------------- 2034 "Confirm1" | Confirm1 Message 2035 --------------------------------------------------- 2036 "Confirm2" | Confirm2 Message 2037 --------------------------------------------------- 2038 "Conf2ACK" | Conf2ACK Message 2039 --------------------------------------------------- 2040 "Error " | Error Message 2041 --------------------------------------------------- 2042 "ErrorACK" | ErrorACK Message 2043 --------------------------------------------------- 2044 "GoClear " | GoClear Message 2045 --------------------------------------------------- 2046 "ClearACK" | ClearACK Message 2047 --------------------------------------------------- 2048 "SASrelay" | SASrelay Message 2049 --------------------------------------------------- 2050 "RelayACK" | RelayACK Message 2051 --------------------------------------------------- 2052 "Ping " | Ping Message 2053 --------------------------------------------------- 2054 "PingACK " | PingACK Message 2055 --------------------------------------------------- 2056 Table 1. Message Type Block Values 2058 5.1.2. Hash Type Block 2060 All ZRTP endpoints MUST support a Hash Type of SHA-256 [FIPS-180-3]. 2061 SHA-384 SHOULD be supported, and MUST be supported if ECDH-384 is 2062 used. Additional Hash Types can be registered and used, such as the 2063 NIST SHA-3 hash [SHA-3] when it becomes available. Note that the 2064 Hash Type refers to the hash algorithm that will be used throughout 2065 the ZRTP key exchange, not the hash algorithm to be used in the SRTP 2066 Authentication Tag. 2068 ZRTP makes use of HMAC message authentication codes based on the 2069 negotiated Hash Type. The HMAC function is defined in [FIPS-198-1]. 2070 A discussion of the general security of the HMAC construction may be 2071 found in [RFC2104]. Test vectors for HMAC-SHA-256 and HMAC-SHA-384 2072 may be found in [RFC4231]. The HMAC function based on the negotiated 2073 Hash Type is also used in the ZRTP key derivation function 2074 (Section 4.5.1). 2076 The choice of the negotiated Hash Type is coupled to the Key 2077 Agreement type, as explained in Section 5.1.5. 2079 Hash Type Block | Meaning 2080 ------------------------------------------------------ 2081 "S256" | SHA-256 Hash defined in FIPS 180-3 2082 ------------------------------------------------------ 2083 "S384" | SHA-384 Hash defined in FIPS 180-3 2084 ------------------------------------------------------ 2086 Table 2. Hash Type Block Values 2088 The negotiated Hash Type does not apply to the hash used in the 2089 digital signature defined in Section 7.2. For example, even if the 2090 negotiated Hash Type is SHA-256, the digital signature may use SHA- 2091 384 if an ECDSA P-384 signature key is used. Digital signatures are 2092 optional in ZRTP. 2094 Except for the aforementioned digital signatures, and the special 2095 cases noted in Section 5.1.2.1, all the other hashes and HMACs used 2096 throughout the ZRTP protocol will use the negotiated Hash Type. 2098 5.1.2.1. Implicit Hash and HMAC algorithm 2100 While most of the HMACs used in ZRTP are defined by the negotiated 2101 Hash Type (Section 5.1.2), some hashes and HMACs must be precomputed 2102 prior to negotiations, and thus cannot have their algorithms 2103 negotiated during the ZRTP exchange. They are implicitly 2104 predetermined to use SHA-256 [FIPS-180-3] and HMAC-SHA-256. 2106 These are the hashes and HMACs that MUST use the Implicit hash and 2107 HMAC algorithm: 2109 The hash chain H0-H3 defined in Section 9. 2110 The HMACs that are keyed by this hash chain, as defined in 2111 Section 8.1.1. 2112 The Hello Hash in the a=zrtp-hash attribute defined in 2113 Section 8.1. 2115 ZRTP defines a method for negotiating different ZRTP protocol 2116 versions (Section 4.1.1). SHA-256 is the Implicit Hash for ZRTP 2117 protocol version 1.10. Future ZRTP protocol versions may, if 2118 appropriate, use another hash algorithm as the Implicit Hash, such as 2119 the NIST SHA-3 hash [SHA-3] when it becomes available. For example, 2120 a future SIP packet may list two a=zrtp-hash SDP attributes, one 2121 based on SHA-256 for ZRTP version 1.10, and another based on SHA-3 2122 for ZRTP version 2.00. 2124 5.1.3. Cipher Type Block 2126 All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- 2127 192 (AES2), AES-256 (AES3), or other Cipher Types. The Advanced 2128 Encryption Standard is defined in [FIPS-197]. 2130 The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- 2131 192 and AES-256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. 2132 The choice of the AES key length is coupled to the Key Agreement 2133 type, as explained in Section 5.1.5. 2135 ZRTP endpoints MAY support the TwoFish [TwoFish] block cipher or the 2136 Camellia [RFC3713] block cipher. If implemented, these ciphers may 2137 be used anywhere in ZRTP or SRTP in place of the AES, in the same 2138 modes of operation and key size. Notably, in counter mode to replace 2139 AES-CM in [RFC3711] and [I-D.ietf-avt-srtp-big-aes], as well as in 2140 CFB mode to encrypt a portion of the Confirm message (Figure 10). 2142 Cipher Type Block | Meaning 2143 ------------------------------------------------- 2144 "AES1" | AES with 128 bit keys 2145 ------------------------------------------------- 2146 "AES2" | AES with 192 bit keys 2147 ------------------------------------------------- 2148 "AES3" | AES with 256 bit keys 2149 ------------------------------------------------- 2150 "2FS1" | TwoFish with 128 bit keys 2151 ------------------------------------------------- 2152 "2FS2" | TwoFish with 192 bit keys 2153 ------------------------------------------------- 2154 "2FS3" | TwoFish with 256 bit keys 2155 ------------------------------------------------- 2156 "CAM1" | Camellia with 128 bit keys 2157 ------------------------------------------------- 2158 "CAM2" | Camellia with 192 bit keys 2159 ------------------------------------------------- 2160 "CAM3" | Camellia with 256 bit keys 2161 ------------------------------------------------- 2163 Table 3. Cipher Type Block Values 2165 5.1.4. Auth Tag Type Block 2167 All ZRTP endpoints MUST support HMAC-SHA1 authentication tags for 2168 SRTP, with both 32 bit and 80 bit length tags as defined in 2169 [RFC3711]. 2171 ZRTP endpoints MAY support 32 bit and 64 bit SRTP authentication tags 2172 based on the Skein hash function [Skein]. The Skein-512-MAC key 2173 length is fixed at 256 bits for this application, and the output 2174 length is adjustable. The Skein MAC is defined in sections 2.6 and 2175 4.3 of [Skein], and is not based on the HMAC construct. Reference 2176 implementations for Skein may be found at [Skein1]. A Skein-based 2177 MAC is significantly more efficient than HMAC-SHA1, especially for 2178 short SRTP payloads. 2180 The Skein MAC key is computed by the SRTP key derivation function, 2181 which is also referred to as the AES-CM PRF, or pseudorandom 2182 function. This is defined either in [RFC3711] or in 2183 [I-D.ietf-avt-srtp-big-aes], depending on the selected SRTP AES key 2184 length. To compute a Skein MAC key, the SRTP PRF output for the 2185 authentication key is left untruncated at 256 bits, instead of the 2186 usual truncated length of 160 bits (the key length used by HMAC- 2187 SHA1). 2189 Auth Tag Type Block | Meaning 2190 ---------------------------------------------------------- 2191 "HS32" | 32 bit authentication tag based on 2192 | HMAC-SHA1 as defined in RFC 3711 2193 ---------------------------------------------------------- 2194 "HS80" | 80 bit authentication tag based on 2195 | HMAC-SHA1 as defined in RFC 3711 2196 ---------------------------------------------------------- 2197 "SK32" | 32 bit authentication tag based on 2198 | Skein-512-MAC as defined in [Skein], 2199 | with 256 bit key, 32 bit MAC length. 2200 ---------------------------------------------------------- 2201 "SK64" | 64 bit authentication tag based on 2202 | Skein-512-MAC as defined in [Skein], 2203 | with 256 bit key, 64 bit MAC length. 2204 ---------------------------------------------------------- 2206 Table 4. Auth Tag Type Values 2208 5.1.5. Key Agreement Type Block 2210 All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and 2211 MAY support EC25, EC38, and DH2k. 2213 If a ZRTP endpoint supports multiple concurrent media streams, such 2214 as audio and video, it MUST support Multistream (Section 4.4.3) mode. 2215 Also, if a ZRTP endpoint supports the GoClear message 2216 (Section 4.7.2), it SHOULD support Multistream, to be used if the two 2217 parties choose to return to the secure state after going Clear (as 2218 explained in Section 4.7.2.1). 2220 For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH 2221 parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the 2222 3072-bit MODP group. DH2k uses the 2048-bit MODP group. The DH 2223 generator g is 2. The random Diffie-Hellman secret exponent SHOULD 2224 be twice as long as the AES key length. If AES-128 is used, the DH 2225 secret value SHOULD be 256 bits long. If AES-256 is used, the secret 2226 value SHOULD be 512 bits long. 2228 If Elliptic Curve DH is used, the ECDH algorithm and key generation 2229 is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA 2230 Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by 2231 FIPS 186-3 [FIPS-186-3], and can also be found in RFC 5114 [RFC5114], 2232 sections 2.6 through 2.8. ECDH test vectors may be found in RFC 5114 2233 [RFC5114], sections A.6 through A.8. The validation procedures are 2234 from NIST SP 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC 2235 Partial Validation. Both the X and Y coordinates of the point on the 2236 curve are sent, in the first and second half of the ECDH public 2237 value, respectively. The ECDH result returns only the X coordinate, 2238 as specified in SP 800-56A. Useful strategies for implementing ECC 2239 may be found in [I-D.mcgrew-fundamental-ecc]. 2241 The choice of the negotiated hash algorithm (Section 5.1.2) is 2242 coupled to the choice of key agreement type. If ECDH-384 (EC38) is 2243 chosen as the key agreement, the negotiated hash algorithm MUST be 2244 either SHA-384, or the corresponding SHA-3 successor. 2246 The choice of AES key length is coupled to the choice of key 2247 agreement type. If EC38 is chosen as the key agreement, AES-256 2248 (AES3) SHOULD be used but AES-192 MAY be used. If DH3K or EC25 is 2249 chosen, any AES key size MAY be used. Note that SRTP as defined in 2250 RFC 3711 [RFC3711] only supports AES-128. 2252 DH2k is intended for low power applications, or for applications that 2253 require fast key negotiations, and SHOULD use AES-128. DH2k is not 2254 recommended for high security applications. Its security can be 2255 augmented by implementing ZRTP's key continuity features 2256 (Section 15.1). 2258 EC52 (ECDH-521) SHOULD NOT be used, due to disruptive computational 2259 delays. These delays may lead to exhaustion of the retransmission 2260 schedule, unless both endpoints have very fast hardware. Note that 2261 ECDH-521 is not part of NSA Suite B. 2263 ZRTP also defines two non-DH modes, Multistream and Preshared, in 2264 which the SRTP key is derived from a shared secret and some nonce 2265 material. 2267 The table below lists the pv length in words and DHPart1 and DHPart2 2268 message length in words for each Key Agreement Type Block. 2270 Key Agreement | pv | message | Meaning 2271 Type Block | words | words | 2272 ----------------------------------------------------------- 2273 "DH3k" | 96 | 117 | DH mode with p=3072 bit prime 2274 | | | per RFC 3526, section 4. 2275 ----------------------------------------------------------- 2276 "DH2k" | 64 | 85 | DH mode with p=2048 bit prime 2277 | | | per RFC 3526, section 3. 2278 ----------------------------------------------------------- 2279 "EC25" | 16 | 37 | Elliptic Curve DH, P-256 2280 | | | per RFC 5114, section 2.6 2281 ----------------------------------------------------------- 2282 "EC38" | 24 | 45 | Elliptic Curve DH, P-384 2283 | | | per RFC 5114, section 2.7 2284 ----------------------------------------------------------- 2285 "EC52" | 33 | 54 | Elliptic Curve DH, P-521 2286 | | | per RFC 5114, section 2.8 2287 ----------------------------------------------------------- 2288 "Prsh" | - | - | Preshared Non-DH mode 2289 | | | 2290 ----------------------------------------------------------- 2291 "Mult" | - | - | Multistream Non-DH mode 2292 | | | 2293 ----------------------------------------------------------- 2295 Table 5. Key Agreement Type Block Values 2297 5.1.6. SAS Type Block 2299 The SAS Type determines how the SAS is rendered to the user so that 2300 the user may verbally compare it with his partner over the voice 2301 channel. This allows detection of a man-in-the-middle (MiTM) attack. 2303 All ZRTP endpoints MUST support the base32 and MAY support the 2304 base256 rendering schemes for the Short Authentication String, and 2305 other SAS rendering schemes. See Section 4.5.2 for how the sasvalue 2306 is computed and Section 7 for how the SAS is used. 2308 SAS Type Block | Meaning 2309 --------------------------------------------------- 2310 "B32 " | Short Authentication String using 2311 | base32 encoding 2312 --------------------------------------------------- 2313 "B256" | Short Authentication String using 2314 | base256 encoding (PGP Word List) 2315 --------------------------------------------------- 2317 Table 6. SAS Type Block Values 2318 For the SAS Type of "B256", the leftmost 16 bits of the 32-bit 2319 sasvalue are rendered using the PGP Word List [pgpwordlist] 2320 [Juola1][Juola2]. 2322 For the SAS Type of "B32 ", the leftmost 20 bits of the 32-bit 2323 sasvalue are rendered as a form of base32 encoding, designed to 2324 represent bit sequences in a form that is convenient for human users 2325 to manipulate. The choice of characters and unusually permuted 2326 ordering are explained in the source document for the encoding scheme 2327 [z-base-32], which differs from RFC 4648. The leftmost 20 bits of 2328 the sasvalue results in four base32 characters which are rendered to 2329 both ZRTP endpoints. Here is a normative pseudocode implementation 2330 of the base32 function: 2332 char[4] base32(uint32 bits) 2333 { int i, n, shift; 2334 char result[4]; 2335 for (i=0,shift=27; i!=4; ++i,shift-=5) 2336 { n = (bits>>shift) & 31; 2337 result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n]; 2338 } 2339 return result; 2340 } 2342 5.1.7. Signature Type Block 2344 The Signature Type Block specifies what signature algorithm is used 2345 to sign the SAS as discussed in Section 7.2. The 4-octet Signature 2346 Type Block, along with the accompanying signature block, are OPTIONAL 2347 and may be present in the Confirm message (Figure 10) or the SASrelay 2348 message (Figure 16). The signature types are given in the table 2349 below. 2351 Signature | Meaning 2352 Type Block | 2353 ------------------------------------------------ 2354 "PGP " | OpenPGP Signature, per RFC 4880 2355 | or I-D.jivsov-openpgp-ecc 2356 ------------------------------------------------ 2357 "X509" | Suite B ECDSA, with X.509v3 cert 2358 | per FIPS 186-3 2359 ------------------------------------------------ 2361 Table 7. Signature Type Block Values 2363 Additional details on the signature and signing key format may be 2364 found in Section 7.2. OpenPGP signatures (Signature Type "PGP ") are 2365 discussed in Section 7.2.1. X.509v3 Suite B Signatures (Signature 2366 Type "X509") are discussed in Section 7.2.2. 2368 Other signature types may be defined in a future document. 2370 5.2. Hello message 2372 The Hello message has the format shown in Figure 3. 2374 All ZRTP messages begin with the preamble value 0x505a, then a 16 bit 2375 length in 32 bit words. This length includes only the ZRTP message 2376 (including the preamble and the length) but not the ZRTP packet 2377 header or CRC. The 8-octet Message Type follows the length field. 2379 Next is a 4 character string containing the version (ver) of the ZRTP 2380 protocol which is "1.10" for this specification. Next is the Client 2381 Identifier string (cid) which is 4 words long and identifies the 2382 vendor and release of the ZRTP software. The 256-bit hash image H3 2383 is defined in Section 9. The next parameter is the ZID, the 96 bit 2384 long unique identifier for the ZRTP endpoint, defined in Section 4.9. 2386 The next four bits are flag bits. The Signature-capable flag (S) 2387 indicates this Hello message is sent from a ZRTP endpoint which is 2388 able to parse and verify digital signatures, as described in 2389 Section 7.2. If signatures are not supported, the (S) flag MUST be 2390 set to zero. The MiTM flag (M) is a Boolean that is set to true if 2391 and only if this Hello message is sent from a device, usually a PBX, 2392 that has the capability to send an SASrelay message (Section 5.13). 2393 The Passive flag (P) is a Boolean normally set to False. A ZRTP 2394 endpoint which is configured to never initiate secure sessions is 2395 regarded as passive, and would set the P bit to True. The next 8 2396 bits are unused and SHOULD be set to zero when sent and MUST be 2397 ignored on receipt. 2399 Next is a list of supported Hash algorithms, Cipher algorithms, SRTP 2400 Auth Tag types, Key Agreement types, and SAS types. The number of 2401 listed algorithms are listed for each type: hc=hash count, cc=cipher 2402 count, ac=auth tag count, kc=key agreement count, and sc=sas count. 2403 The values for these algorithms are defined in Tables 2, 3, 4, 5, and 2404 6. A count of zero means that only the mandatory to implement 2405 algorithms are supported. Mandatory algorithms MAY be included in 2406 the list. The order of the list indicates the preferences of the 2407 endpoint. If a mandatory algorithm is not included in the list, it 2408 is added to the end of the list for preference. 2410 The 64-bit HMAC at the end of the message is computed across the 2411 whole message, not including the HMAC. The HMAC key is the sender's 2412 H2 (defined in Section 9), and thus the HMAC cannot be checked by the 2413 receiving party until the sender's H2 value is known to the receiving 2414 party later in the protocol. 2416 0 1 2 3 2417 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 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | Message Type Block="Hello " (2 words) | 2422 | | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | version="1.10" (1 word) | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | | 2427 | Client Identifier (4 words) | 2428 | | 2429 | | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | | 2432 | Hash image H3 (8 words) | 2433 | . . . | 2434 | | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | | 2437 | ZID (3 words) | 2438 | | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 |0|S|M|P| unused (zeros)| hc | cc | ac | kc | sc | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | hash algorithms (0 to 7 values) | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | cipher algorthms (0 to 7 values) | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | auth tag types (0 to 7 values) | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | key agreement types (0 to 7 values) | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | SAS types (0 to 7 values) | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | HMAC (2 words) | 2453 | | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 Figure 3: Hello message format 2458 5.3. HelloACK message 2460 The HelloACK message is used to stop retransmissions of a Hello 2461 message. A HelloACK is sent regardless if the version number in the 2462 Hello is supported or the algorithm list supported. The receipt of a 2463 HelloACK stops retransmission of the Hello message. The format is 2464 shown in the Figure below. A Commit message may be sent in place of 2465 a HelloACK by an Initiator, if a Commit message is ready to be sent 2466 promptly. 2468 0 1 2 3 2469 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 2470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2471 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Message Type Block="HelloACK" (2 words) | 2474 | | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 Figure 4: HelloACK message format 2479 5.4. Commit message 2481 The Commit message is sent to initiate the key agreement process 2482 after both sides have received a Hello message, which means it can 2483 only be sent after receiving both a Hello message and a HelloACK 2484 message. There are three subtypes of Commit messages, whose formats 2485 are shown in Figure 5, Figure 6, and Figure 7. 2487 The Commit message contains the Message Type Block, then the 256-bit 2488 hash image H2 which is defined in Section 9. The next parameter is 2489 the initiator's ZID, the 96 bit long unique identifier for the ZRTP 2490 endpoint, which must have the same value as was used in the Hello 2491 message. 2493 Next is a list of algorithms selected by the initiator (hash, cipher, 2494 auth tag type, key agreement, sas type). For a DH Commit, the hash 2495 value hvi is a hash of the DHPart2 of the Initiator and the 2496 Responder's Hello message, as explained in Section 4.4.1.1. 2498 The 64-bit HMAC at the end of the message is computed across the 2499 whole message, not including the HMAC. The HMAC key is the sender's 2500 H1 (defined in Section 9), and thus the HMAC cannot be checked by the 2501 receiving party until the sender's H1 value is known to the receiving 2502 party later in the protocol. 2504 0 1 2 3 2505 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 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Message Type Block="Commit " (2 words) | 2510 | | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | | 2513 | Hash image H2 (8 words) | 2514 | . . . | 2515 | | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | | 2518 | ZID (3 words) | 2519 | | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | hash algorithm | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | cipher algorithm | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | auth tag type | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | key agreement type | 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | SAS type | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | | 2532 | hvi (8 words) | 2533 | . . . | 2534 | | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | HMAC (2 words) | 2537 | | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 Figure 5: DH Commit message format 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=25 words | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Message Type Block="Commit " (2 words) | 2548 | | 2549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 | | 2551 | Hash image H2 (8 words) | 2552 | . . . | 2553 | | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 | | 2556 | ZID (3 words) | 2557 | | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | hash algorithm | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | cipher algorithm | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | auth tag type | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | key agreement type = "Mult" | 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | SAS type | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 | | 2570 | nonce (4 words) | 2571 | . . . | 2572 | | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 | HMAC (2 words) | 2575 | | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 Figure 6: Multistream Commit message format 2580 0 1 2 3 2581 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 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words | 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Message Type Block="Commit " (2 words) | 2586 | | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 | | 2589 | Hash image H2 (8 words) | 2590 | . . . | 2591 | | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | | 2594 | ZID (3 words) | 2595 | | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | hash algorithm | 2598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2599 | cipher algorithm | 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | auth tag type | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | key agreement type = "Prsh" | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | SAS type | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | | 2608 | nonce (4 words) | 2609 | . . . | 2610 | | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | keyID (2 words) | 2613 | | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | HMAC (2 words) | 2616 | | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 Figure 7: Preshared Commit message format 2621 5.5. DHPart1 message 2623 The DHPart1 message begins the DH exchange. The format is shown in 2624 Figure 8 below. The DHPart1 message is sent by the Responder if a 2625 valid Commit message is received from the Initiator. The length of 2626 the pvr value and the length of the DHPart1 message depends on the 2627 Key Agreement Type chosen. This information is contained in the 2628 table in Section 5.1.5. Note that for both Multistream and Preshared 2629 modes, no DHPart1 or DHPart2 message will be sent. 2631 The 256-bit hash image H1 is defined in Section 9. 2633 The next four parameters are HMACs of potential shared secrets used 2634 in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are 2635 the HMACs of the responder's two retained shared secrets, truncated 2636 to 64 bits. Next is auxsecretIDr, the HMAC of the responder's 2637 auxsecret (defined in Section 4.3), truncated to 64 bits. The last 2638 parameter is the HMAC of the trusted MiTM PBX shared secret 2639 pbxsecret, defined in Section 7.3.1. The Message format for the 2640 DHPart1 message is shown in Figure 8. 2642 The 64-bit HMAC at the end of the message is computed across the 2643 whole message, not including the HMAC. The HMAC key is the sender's 2644 H0 (defined in Section 9), and thus the HMAC cannot be checked by the 2645 receiving party until the sender's H0 value is known to the receiving 2646 party later in the protocol. 2648 0 1 2 3 2649 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 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | Message Type Block="DHPart1 " (2 words) | 2654 | | 2655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 | | 2657 | Hash image H1 (8 words) | 2658 | . . . | 2659 | | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | rs1IDr (2 words) | 2662 | | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | rs2IDr (2 words) | 2665 | | 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2667 | auxsecretIDr (2 words) | 2668 | | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | pbxsecretIDr (2 words) | 2671 | | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | | 2674 | pvr (length depends on KA Type) | 2675 | . . . | 2676 | | 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | HMAC (2 words) | 2679 | | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 Figure 8: DHPart1 message format 2684 5.6. DHPart2 message 2686 The DHPart2 message completes the DH exchange. A DHPart2 message is 2687 sent by the Initiator if a valid DHPart1 message is received from the 2688 Responder. The length of the pvr value and the length of the DHPart2 2689 message depends on the Key Agreement Type chosen. This information 2690 is contained in the table in Section 5.1.5. Note that for both 2691 Multistream and Preshared modes, no DHPart1 or DHPart2 message will 2692 be sent. 2694 The 256-bit hash image H1 is defined in Section 9. 2696 The next four parameters are HMACs of potential shared secrets used 2697 in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are 2698 the HMACs of the initiator's two retained shared secrets, truncated 2699 to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's 2700 auxsecret (defined in Section 4.3), truncated to 64 bits. The last 2701 parameter is the HMAC of the trusted MiTM PBX shared secret 2702 pbxsecret, defined in Section 7.3.1. The message format for the 2703 DHPart2 message is shown in Figure 9. 2705 The 64-bit HMAC at the end of the message is computed across the 2706 whole message, not including the HMAC. The HMAC key is the sender's 2707 H0 (defined in Section 9), and thus the HMAC cannot be checked by the 2708 receiving party until the sender's H0 value is known to the receiving 2709 party later in the protocol. 2711 0 1 2 3 2712 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 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 | Message Type Block="DHPart2 " (2 words) | 2717 | | 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 | | 2720 | Hash image H1 (8 words) | 2721 | . . . | 2722 | | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | rs1IDi (2 words) | 2725 | | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | rs2IDi (2 words) | 2728 | | 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | auxsecretIDi (2 words) | 2731 | | 2732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2733 | pbxsecretIDi (2 words) | 2734 | | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | | 2737 | pvi (length depends on KA Type) | 2738 | . . . | 2739 | | 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | HMAC (2 words) | 2742 | | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 Figure 9: DHPart2 message format 2747 5.7. Confirm1 and Confirm2 messages 2749 The Confirm1 message is sent by the Responder in response to a valid 2750 DHPart2 message after the SRTP session key and parameters have been 2751 negotiated. The Confirm2 message is sent by the Initiator in 2752 response to a Confirm1 message. The format is shown in Figure 10 2753 below. The message contains the Message Type Block "Confirm1" or 2754 "Confirm2". Next is the confirm_mac, a keyed hash over the encrypted 2755 part of the message (shown enclosed by "====" in Figure 10). This 2756 confirm_mac is keyed and computed according to Section 4.6. The next 2757 16 octets contain the CFB Initialization Vector. The rest of the 2758 message is encrypted using CFB and protected by the confirm_mac. 2760 The first field inside the encrypted region is the hash preimage H0, 2761 which is defined in detail in Section 9. 2763 The next 15 bits are not used and SHOULD be set to zero when sent and 2764 MUST be ignored when received in Confirm1 or Confirm2 messages. 2766 The next 9 bits contain the signature length. If no SAS signature 2767 (described in Section 7.2) is present, all bits are set to zero. The 2768 signature length is in words and includes the signature type block. 2769 If the calculated signature octet count is not a multiple of 4, zeros 2770 are added to pad it out to a word boundary. If no signature is 2771 present, the overall length of the Confirm1 or Confirm2 Message will 2772 be set to 19 words. 2774 The next 8 bits are used for flags. Undefined flags are set to zero 2775 and ignored. Four flags are currently defined. The PBX Enrollment 2776 flag (E) is a Boolean bit defined in Section 7.3.1. The SAS Verified 2777 flag (V) is a Boolean bit defined in Section 7.1. The Allow Clear 2778 flag (A) is a Boolean bit defined in Section 4.7.2. The Disclosure 2779 Flag (D) is a Boolean bit defined in Section 11. The cache 2780 expiration interval is defined in Section 4.9. 2782 If the signature length (in words) is non-zero, a signature type 2783 block will be present along with a signature block. Next is the 2784 signature block. The signature block includes the signature and the 2785 key (or a link to the key) used to generate the signature 2786 (Section 7.2). 2788 CFB mode [SP800-38A] is applied with a feedback length of 128-bits, a 2789 full cipher block, and the final block is truncated to match the 2790 exact length of the encrypted data. The CFB Initialization Vector is 2791 a 128 bit random nonce. The block cipher algorithm and the key size 2792 is the same as what was negotiated for the media encryption. CFB is 2793 used to encrypt the part of the Confirm1 message beginning after the 2794 CFB IV to the end of the message (the encrypted region is enclosed by 2795 "====" in Figure 10). 2797 The responder uses the zrtpkeyr to encrypt the Confirm1 message. The 2798 initiator uses the zrtpkeyi to encrypt the Confirm2 message. 2800 0 1 2 3 2801 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 2802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2803 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2805 | Message Type Block="Confirm1" or "Confirm2" (2 words) | 2806 | | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | confirm_mac (2 words) | 2809 | | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 | | 2812 | CFB Initialization Vector (4 words) | 2813 | | 2814 | | 2815 +===============================================================+ 2816 | | 2817 | Hash preimage H0 (8 words) | 2818 | . . . | 2819 | | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D| 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | cache expiration interval (1 word) | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | optional signature type block (1 word if present) | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | | 2828 | optional signature block (variable length) | 2829 | . . . | 2830 | | 2831 | | 2832 +===============================================================+ 2834 Figure 10: Confirm1 and Confirm2 message format 2836 5.8. Conf2ACK message 2838 The Conf2ACK message is sent by the Responder in response to a valid 2839 Confirm2 message. The message format for the Conf2ACK is shown in 2840 the Figure below. The receipt of a Conf2ACK stops retransmission of 2841 the Confirm2 message. Note that the first SRTP media (with a valid 2842 SRTP auth tag) from the responder also stops retransmission of the 2843 Confirm2 message. 2845 0 1 2 3 2846 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 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | Message Type Block="Conf2ACK" (2 words) | 2851 | | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 Figure 11: Conf2ACK message format 2856 5.9. Error message 2858 The Error message is sent to terminate an in-process ZRTP key 2859 agreement exchange due to an error. The format is shown in the 2860 Figure below. The use of the Error message is described in 2861 Section 4.7.1. 2863 0 1 2 3 2864 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 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words | 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | Message Type Block="Error " (2 words) | 2869 | | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | Integer Error Code (1 word) | 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 Figure 12: Error message format 2876 Defined hexadecimal values for the Error Code are listed in the table 2877 below. 2879 Error Code | Meaning 2880 ----------------------------------------------------------- 2881 0x10 | Malformed packet (CRC OK, but wrong structure) 2882 ----------------------------------------------------------- 2883 0x20 | Critical software error 2884 ----------------------------------------------------------- 2885 0x30 | Unsupported ZRTP version 2886 ----------------------------------------------------------- 2887 0x40 | Hello components mismatch 2888 ----------------------------------------------------------- 2889 0x51 | Hash type not supported 2890 ----------------------------------------------------------- 2891 0x52 | Cipher type not supported 2892 ----------------------------------------------------------- 2893 0x53 | Public key exchange not supported 2894 ----------------------------------------------------------- 2895 0x54 | SRTP auth. tag not supported 2896 ----------------------------------------------------------- 2897 0x55 | SAS rendering scheme not supported 2898 ----------------------------------------------------------- 2899 0x56 | No shared secret available, DH mode required 2900 ----------------------------------------------------------- 2901 0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1) 2902 ----------------------------------------------------------- 2903 0x62 | DH Error: hvi != hashed data 2904 ----------------------------------------------------------- 2905 0x63 | Received relayed SAS from untrusted MiTM 2906 ----------------------------------------------------------- 2907 0x70 | Auth. Error: Bad Confirm pkt MAC 2908 ----------------------------------------------------------- 2909 0x80 | Nonce reuse 2910 ----------------------------------------------------------- 2911 0x90 | Equal ZIDs in Hello 2912 ----------------------------------------------------------- 2913 0xA0 | Service unavailable 2914 ----------------------------------------------------------- 2915 0xB0 | Protocol timeout error 2916 ----------------------------------------------------------- 2917 0x100 | GoClear message received, but not allowed 2918 ----------------------------------------------------------- 2920 Table 8. ZRTP Error Codes 2922 5.10. ErrorACK message 2924 The ErrorACK message is sent in response to an Error message. The 2925 receipt of an ErrorACK stops retransmission of the Error message. 2926 The format is shown in the Figure below. 2928 0 1 2 3 2929 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 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 | Message Type Block="ErrorACK" (2 words) | 2934 | | 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 Figure 13: ErrorACK message format 2939 5.11. GoClear message 2941 Support for the GoClear message is OPTIONAL in the protocol, and it 2942 is sent to switch from SRTP to RTP. The format is shown in the 2943 Figure below. The clear_mac is used to authenticate the GoClear 2944 message so that bogus GoClear messages introduced by an attacker can 2945 be detected and discarded. The use of GoClear is described in 2946 Section 4.7.2. 2948 0 1 2 3 2949 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 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | Message Type Block="GoClear " (2 words) | 2954 | | 2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 | clear_mac (2 words) | 2957 | | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 Figure 14: GoClear message format 2962 5.12. ClearACK message 2964 Support for the ClearACK message is OPTIONAL in the protocol, and it 2965 is sent to acknowledge receipt of a GoClear. A ClearACK is only sent 2966 if the clear_mac from the GoClear message is authenticated. 2967 Otherwise, no response is returned. The format is shown in the 2968 Figure below. 2970 0 1 2 3 2971 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 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2975 | Message Type Block="ClearACK" (2 words) | 2976 | | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 Figure 15: ClearACK message format 2981 5.13. SASrelay message 2983 The SASrelay message is sent by a trusted Man in The Middle (MiTM), 2984 most often a PBX. It is not sent as a response to a packet, but is 2985 sent as a self-initiated packet by the trusted MiTM. It can only be 2986 sent after the rest of the ZRTP key negotiations have completed, 2987 after the Confirm messages and their ACKs. It can only be sent after 2988 the trusted MiTM has finished key negotiations with the other party, 2989 because it is the other party's SAS that is being relayed. It is 2990 sent with retry logic until a RelayACK message (Section 5.14) is 2991 received or the retry schedule has been exhausted. 2993 If a device, usually a PBX, sends an SASrelay message, it MUST have 2994 previously declared itself as a MiTM device by setting the MiTM (M) 2995 flag in the Hello message (Section 5.2). If the receiver of the 2996 SASrelay message did not previously receive a Hello message with the 2997 MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A 2998 RelayACK is still sent, but no Error message is sent. 3000 The SASrelay message format is shown in Figure 16 below. The message 3001 contains the Message Type Block "SASrelay". Next is the HMAC, a 3002 keyed hash over encrypted part of the message (shown enclosed by 3003 "====" in Figure 16). This HMAC is keyed the same way as the 3004 confirm_mac in the Confirm messages (see Section 4.6). The next 16 3005 octets contain the CFB Initialization Vector. The rest of the 3006 message is encrypted using CFB and protected by the HMAC. 3008 The next 15 bits are not used and SHOULD be set to zero when sent and 3009 MUST be ignored when received in SASrelay messages. 3011 The next 9 bits contain the signature length. The trusted MiTM MAY 3012 compute a digital signature on the SAS hash, as described in 3013 Section 7.2, using a persistent signing key owned by the trusted 3014 MiTM. If no SAS signature is present, all bits are set to zero. The 3015 signature length is in words and includes the signature type block. 3016 If the calculated signature octet count is not a multiple of 4, zeros 3017 are added to pad it out to a word boundary. If no signature block is 3018 present, the overall length of the SASrelay Message will be set to 19 3019 words. 3021 The next 8 bits are used for flags. Undefined flags are set to zero 3022 and ignored. Three flags are currently defined. The Disclosure Flag 3023 (D) is a Boolean bit defined in Section 11. The Allow Clear flag (A) 3024 is a Boolean bit defined in Section 4.7.2. The SAS Verified flag (V) 3025 is a Boolean bit defined in Section 7.1. These flags are updated 3026 values to the same flags provided earlier in the Confirm message, but 3027 they are updated to reflect the new flag information relayed by the 3028 PBX from the other party. 3030 The next 32 bit word contains the SAS rendering scheme for the 3031 relayed sashash, which will be the same rendering scheme used by the 3032 other party on the other side of the trusted MiTM. Section 7.3 3033 describes how the PBX determines whether the ZRTP client regards the 3034 PBX as a trusted MiTM. If the PBX determines that the ZRTP client 3035 trusts the PBX, the next 8 words contain the sashash relayed from the 3036 other party. The first 32-bit word of the sashash contains the 3037 sasvalue, which may be rendered to the user using the specified SAS 3038 rendering scheme. If this SASrelay message is being sent to a ZRTP 3039 client that does not trust this MiTM, the sashash will be ignored by 3040 the recipient and should be set to zeros by the PBX. 3042 If the signature length (in words) is non-zero, a signature type 3043 block will be present along with a signature block. Next is the 3044 signature block. The signature block includes the signature and the 3045 key (or a link to the key) used to generate the signature 3046 (Section 7.2). 3048 CFB mode [SP800-38A] is applied with a feedback length of 128-bits, a 3049 full cipher block, and the final block is truncated to match the 3050 exact length of the encrypted data. The CFB Initialization Vector is 3051 a 128 bit random nonce. The block cipher algorithm and the key size 3052 is the same as what was negotiated for the media encryption. CFB is 3053 used to encrypt the part of the SASrelay message beginning after the 3054 CFB IV to the end of the message (the encrypted region is enclosed by 3055 "====" in Figure 16). 3057 Depending on whether the trusted MiTM had taken the role of the 3058 initiator or the responder during the ZRTP key negotiation, the 3059 SASrelay message is encrypted with zrtpkeyi or zrtpkeyr. 3061 0 1 2 3 3062 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 3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3064 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 | Message Type Block="SASrelay" (2 words) | 3067 | | 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 | HMAC (2 words) | 3070 | | 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 | | 3073 | CFB Initialization Vector (4 words) | 3074 | | 3075 | | 3076 +===============================================================+ 3077 | Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D| 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 | rendering scheme of relayed SAS (1 word) | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | | 3082 | Trusted MiTM relayed sashash (8 words) | 3083 | . . . | 3084 | | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | optional signature type block (1 word if present) | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | | 3089 | optional signature block (variable length) | 3090 | . . . | 3091 | | 3092 | | 3093 +===============================================================+ 3095 Figure 16: SASrelay message format 3097 5.14. RelayACK message 3099 The RelayACK message is sent in response to a valid SASrelay message. 3100 The message format for the RelayACK is shown in the Figure below. 3101 The receipt of a RelayACK stops retransmission of the SASrelay 3102 message. 3104 0 1 2 3 3105 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 3106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3107 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 3108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3109 | Message Type Block="RelayACK" (2 words) | 3110 | | 3111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3113 Figure 17: RelayACK message format 3115 5.15. Ping message 3117 The Ping and PingACK messages are unrelated to the rest of the ZRTP 3118 protocol. No ZRTP endpoint is required to generate a Ping message, 3119 but every ZRTP endpoint MUST respond to a Ping message with a PingACK 3120 message. 3122 Although Ping and PingACK messages have no effect on the rest of the 3123 ZRTP protocol, their inclusion in this specification simplifies the 3124 design of "bump-in-the-wire" ZRTP proxies (Section 10) (notably, 3125 Zfone [zfone]). It enables proxies to be designed that do not rely 3126 on assistance from the signaling layer to map out the associations 3127 between media streams and ZRTP endpoints. 3129 Before sending a ZRTP Hello message, a ZRTP proxy MAY send a Ping 3130 message as a means to sort out which RTP media streams are connected 3131 to particular ZRTP endpoints. Ping messages are generated only by 3132 ZRTP proxies. If neither party is a ZRTP proxy, no Ping messages 3133 will be encountered. Ping retransmission behavior is discussed in 3134 Section 6. 3136 The Ping message (Figure 18) contains an "EndpointHash", defined in 3137 Section 5.16. 3139 The Ping message contains a version number that defines what version 3140 of PingACK is requested. If that version number is supported by the 3141 Ping responder, a PingACK with a format that matches that version 3142 will be received. Otherwise, a PingACK with a lower version number 3143 may be received. 3145 0 1 2 3 3146 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 3147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=6 words | 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 | Message Type Block="Ping " (2 words) | 3151 | | 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | version="1.10" (1 word) | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | EndpointHash (2 words) | 3156 | | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 Figure 18: Ping message format 3161 5.16. PingACK message 3163 A PingACK message is sent only in response to a Ping. A ZRTP 3164 endpoint MUST respond to a Ping with a PingACK message. The version 3165 of PingACK requested is contained in the Ping message. If that 3166 version number is supported, a PingACK with a format that matches 3167 that version MUST be sent. Otherwise, if the version number of the 3168 Ping is not supported, a PingACK SHOULD be sent in the format of the 3169 highest supported version known to the Ping responder. Only version 3170 "1.10" is supported in this specification. 3172 The PingACK message carries its own 64-bit EndpointHash, distinct 3173 from the EndpointHash of the other party's Ping message. It is 3174 REQUIRED that it be highly improbable for two participants in a call 3175 to have the same EndpointHash, and that an EndpointHash maintains a 3176 persistent value between calls. For a normal ZRTP endpoint such as a 3177 ZRTP-enabled VoIP client, the EndpointHash can be just the truncated 3178 ZID. For a ZRTP endpoint such as a PBX that has multiple endpoints 3179 behind it, the EndpointHash must be a distinct value for each 3180 endpoint behind it. It is recommended that the EndpointHash be a 3181 truncated hash of the ZID of the ZRTP endpoint concatenated with 3182 something unique about the actual endpoint or phone behind the PBX. 3183 This may be the SIP URI of the phone, the PBX extension number, or 3184 the local IP address of the phone, whichever is more readily 3185 available in the application environment: 3187 o EndpointHash = hash(ZID || SIP URI of the endpoint) 3188 o EndpointHash = hash(ZID || PBX extension number of the endpoint) 3189 o EndpointHash = hash(ZID || local IP address of the endpoint) 3191 Any of these formulae confers uniqueness for the simple case of 3192 terminating the ZRTP connection at the VoIP client, or the more 3193 complex case of a PBX terminating the ZRTP connection for multiple 3194 VoIP phones in a conference call, all sharing the PBX's ZID, but with 3195 separate IP addresses behind the PBX. There is no requirement for 3196 the same hash function to be used by both parties. 3198 The PingACK message contains the EndpointHash of the sender of the 3199 PingACK as well as the EndpointHash of the sender of the Ping. The 3200 Source Identifier (SSRC) received in the ZRTP header from the Ping 3201 packet (Figure 2) is copied into the PingACK message body 3202 (Figure 19). This SSRC is not the SSRC of the sender of the PingACK. 3204 0 1 2 3 3205 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 3206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3207 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=9 words | 3208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3209 | Message Type Block="PingACK " (2 words) | 3210 | | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | version="1.10" (1 word) | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | EndpointHash of PingACK Sender (2 words) | 3215 | | 3216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 | EndpointHash of Received Ping (2 words) | 3218 | | 3219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3220 | Source Identifier (SSRC) of Received Ping (1 word) | 3221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3223 Figure 19: PingACK message format 3225 6. Retransmissions 3227 ZRTP uses two retransmission timers T1 and T2. T1 is used for 3228 retransmission of Hello messages, when the support of ZRTP by the 3229 other endpoint may not be known. T2 is used in retransmissions of 3230 all the other ZRTP messages. 3232 All message retransmissions MUST be identical to the initial message 3233 including nonces, public values, etc; otherwise, hashes of the 3234 message sequences may not agree. 3236 Practical experience has shown that RTP packet loss at the start of 3237 an RTP session can be extremely high. Since the entire ZRTP message 3238 exchange occurs during this period, the defined retransmission scheme 3239 is defined to be aggressive. Since ZRTP packets with the exception 3240 of the DHPart1 and DHPart2 messages are small, this should have 3241 minimal effect on overall bandwidth utilization of the media session. 3243 ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media 3244 session as determined by the offer/answer exchange in the signaling 3245 layer. 3247 The Ping message (Section 5.15) may follow the same retransmission 3248 schedule as the Hello message, but this is not required in this 3249 specification. Ping message retransmission is subject to 3250 application-specific ZRTP proxy heuristics. 3252 Hello ZRTP messages are retransmitted at an interval that starts at 3253 T1 seconds and doubles after every retransmission, capping at 200ms. 3254 T1 has a recommended initial value of 50 ms. A Hello message is 3255 retransmitted 20 times before giving up, which means the entire retry 3256 schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 3257 + 18*200 ms). Retransmission of a Hello ends upon receipt of a 3258 HelloACK or Commit message. 3260 The post-Hello ZRTP messages are retransmitted only by the session 3261 initiator - that is, only Commit, DHPart2, and Confirm2 are 3262 retransmitted if the corresponding message from the responder, 3263 DHPart1, Confirm1, and Conf2ACK, are not received. Note that the 3264 Confirm2 message retransmission can also be stopped by receiving the 3265 first SRTP media (with a valid SRTP auth tag) from the responder. 3267 The GoClear, Error, and SASrelay messages may be initiated and 3268 retransmitted by either party, and responded to by the other party, 3269 regardless of which party is the overall session initiator. They are 3270 retransmitted if the corresponding response message ClearACK, 3271 ErrorACK, and RelayACK, are not received. 3273 Non-Hello (and non-Ping) ZRTP messages are retransmitted at an 3274 interval that starts at T2 seconds and doubles after every 3275 retransmission, capping at 1200ms. T2 has a recommended initial 3276 value of 150 ms. Each non-Hello message is retransmitted 10 times 3277 before giving up, which means the entire retry schedule is exhausted 3278 after 9.45 seconds (150 + 300 + 600 + 7*1200 ms). Only the initiator 3279 performs retransmissions. Each message has a response message that 3280 stops retransmissions, as shown in the table below. The higher 3281 values of T2 means that retransmissions will likely occur only in the 3282 event of packet loss. 3284 Message Acknowledgement Message 3285 ------- ----------------------- 3286 Hello HelloACK or Commit 3287 Commit DHPart1 or Confirm1 3288 DHPart2 Confirm1 3289 Confirm2 Conf2ACK or SRTP media 3290 GoClear ClearACK 3291 Error ErrorACK 3292 SASrelay RelayACK 3293 Ping PingACK 3295 Table 9. Retransmitted ZRTP Messages and Responses 3297 The retry schedule must handle not only packet loss, but also slow or 3298 heavily loaded peers that need additional time to perform their DH 3299 calculations. The following mitigations are recommended: 3301 o Slow or heavily loaded ZRTP endpoints that are at risk of taking 3302 too long to perform their DH calculation SHOULD use a HelloACK 3303 message instead of a Commit message to reply to a Hello from the 3304 other party. 3305 o If a ZRTP endpoint has evidence that the other party is a ZRTP 3306 endpoint, by receiving a Hello message or a ZRTP flag in the RTP 3307 header extension (Section 12) for incoming media, it SHOULD extend 3308 its own Hello retry schedule to span at least 12 seconds of 3309 retries. If this extended Hello retry schedule is exhausted 3310 without receiving a HelloACK or Commit message, a late Commit 3311 message from the peer SHOULD still be accepted. 3313 These recommended retransmission intervals are designed for a typical 3314 broadband Internet connection. In some high latency communication 3315 channels, such as those provided by some mobile phone environments or 3316 geostationary satellites, a different retransmission schedule may be 3317 used. The initial value for the T1 or T2 retransmission timer should 3318 be increased to be no less than the round trip time provided by the 3319 communications channel. It should take into account the time 3320 required to transmit the entire message and the entire reply, as well 3321 as a reasonable time estimate to perform the DH calculation. 3323 ZRTP has its own retransmission schedule because it is carried along 3324 with RTP, usually over UDP. In unusual cases, RTP can run over a 3325 non-UDP transport, such as TCP or DCCP, which provides its own 3326 built-in retransmission mechanism. It may be hard for the ZRTP 3327 endpoint to detect that TCP is being used if media relays are 3328 involved. The ZRTP endpoint may be sending only UDP, but there may 3329 be a media relay along the media path that converts from UDP to TCP 3330 for part of the journey. Or, if the ZRTP endpoint is sending TCP, 3331 the media relay might be converting from TCP to UDP. In cases where 3332 TCP is used, ZRTP and TCP might together generate some extra 3333 retransmissions. To reduce this effect, the ZRTP retransmission 3334 intervals may be lengthened, if the endpoint is aware that TCP is 3335 being used. 3337 After receiving a Commit message, but before receiving a Confirm2 3338 message, if a ZRTP responder receives no ZRTP messages for more than 3339 10 seconds, the responder MAY send a protocol timeout Error message 3340 and terminate the ZRTP protocol. 3342 7. Short Authentication String 3344 This section will discuss the implementation of the Short 3345 Authentication String, or SAS in ZRTP. The SAS can be verbally 3346 compared by the human users reading the string aloud, or by 3347 validating an OPTIONAL digital signature (described in Section 7.2) 3348 exchanged in the Confirm1 or Confirm2 messages. 3350 The use of hash commitment in the DH exchange (Section 4.4.1.1) 3351 constrains the attacker to only one guess to generate the correct SAS 3352 in his attack, which means the SAS can be quite short. A 16-bit SAS, 3353 for example, provides the attacker only one chance out of 65536 of 3354 not being detected. 3356 There is only one SAS value computed per call. That is the SAS value 3357 for the first media stream established, which is calculated in 3358 Section 4.5.2. This SAS applies to all media streams for the same 3359 session. 3361 The SAS SHOULD be rendered to the user for authentication. The 3362 rendering of the SAS value through the user interface at both 3363 endpoints depends on the SAS Type agreed upon in the Commit message. 3364 See Section 5.1.6 for a description of how the SAS is rendered to the 3365 user. 3367 The SAS is not treated as a secret value, but it must be compared to 3368 see if it matches at both ends of the communications channel. The 3369 two users verbally compare it using their human voices, human ears, 3370 and human judgement. If it doesn't match, it indicates the presence 3371 of a man-in-the-middle (MiTM) attack. 3373 7.1. SAS Verified Flag 3375 The SAS Verified flag (V) is set based on the user indicating that 3376 SAS comparison has been successfully performed. The SAS Verified 3377 flag is exchanged securely in the Confirm1 and Confirm2 messages 3378 (Figure 10) of the next session. In other words, each party sends 3379 the SAS Verified flag from the previous session in the Confirm 3380 message of the current session. It is perfectly reasonable to have a 3381 ZRTP endpoint that never sets the SAS Verified flag, because it would 3382 require adding complexity to the user interface to allow the user to 3383 set it. The SAS Verified flag is not required to be set, but if it 3384 is available to the client software, it allows for the possibility 3385 that the client software could render to the user that the SAS verify 3386 procedure was carried out in a previous session. 3388 Regardless of whether there is a user interface element to allow the 3389 user to set the SAS Verified flag, it is worth caching a shared 3390 secret, because doing so reduces opportunities for an attacker in the 3391 next call. 3393 If at any time the users carry out the SAS comparison procedure, and 3394 it actually fails to match, then this means there is a very 3395 resourceful man-in-the-middle. If this is the first call, the MiTM 3396 was there on the first call, which is impressive enough. If it 3397 happens in a later call, it also means the MiTM must also know the 3398 cached shared secret, because you could not have carried out any 3399 voice traffic at all unless the session key was correctly computed 3400 and is also known to the attacker. This implies the MiTM must have 3401 been present in all the previous sessions, since the initial 3402 establishment of the first shared secret. This is indeed a 3403 resourceful attacker. It also means that if at any time he ceases 3404 his participation as a MiTM on one of your calls, the protocol will 3405 detect that the cached shared secret is no longer valid -- because it 3406 was really two different shared secrets all along, one of them 3407 between Alice and the attacker, and the other between the attacker 3408 and Bob. The continuity of the cached shared secrets make it possible 3409 for us to detect the MiTM when he inserts himself into the ongoing 3410 relationship, as well as when he leaves. Also, if the attacker tries 3411 to stay with a long lineage of calls, but fails to execute a DH MiTM 3412 attack for even one missed call, he is permanently excluded. He can 3413 no longer resynchronize with the chain of cached shared secrets. 3415 A user interface element (i.e. a checkbox or button) is needed to 3416 allow the user to tell the software the SAS verify was successful, 3417 causing the software to set the SAS Verified flag (V), which 3418 (together with our cached shared secret) obviates the need to perform 3419 the SAS procedure in the next call. An additional user interface 3420 element can be provided to let the user tell the software he detected 3421 an actual SAS mismatch, which indicates a MiTM attack. The software 3422 can then take appropriate action, clearing the SAS Verified flag, and 3423 erase the cached shared secret from this session. It is up to the 3424 implementer to decide if this added user interface complexity is 3425 warranted. 3427 If the SAS matches, it means there is no MiTM, which also implies it 3428 is now safe to trust a cached shared secret for later calls. If 3429 inattentive users don't bother to check the SAS, it means we don't 3430 know whether there is or is not a MiTM, so even if we do establish a 3431 new cached shared secret, there is a risk that our potential attacker 3432 may have a subsequent opportunity to continue inserting himself in 3433 the call, until we finally get around to checking the SAS. If the 3434 SAS matches, it means no attacker was present for any previous 3435 session since we started propagating cached shared secrets, because 3436 this session and all the previous sessions were also authenticated 3437 with a continuous lineage of shared secrets. 3439 7.2. Signing the SAS 3441 In most applications it is desirable to avoid the added complexity of 3442 a PKI-backed digital signature, which is why ZRTP is designed not to 3443 require it. Nonetheless, in some applications, it may be hard to 3444 arrange for two human users to verbally compare the SAS. Or an 3445 application may already be using an existing PKI and wants to use it 3446 to augment ZRTP. 3448 To handle these cases, ZRTP allows for an OPTIONAL signature feature, 3449 which allows the SAS to be checked without human participation. The 3450 SAS MAY be signed and the signature sent inside the Confirm1, 3451 Confirm2 (Figure 10), or SASrelay (Figure 16) messages. The 3452 signature type (Section 5.1.7), length of the signature and the key 3453 used to create the signature (or a link to it) are all sent along 3454 with the signature. The signature is calculated across the entire 3455 SAS hash result (sashash), from which the sasvalue was derived. The 3456 signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay 3457 messages MAY be used to authenticate the ZRTP exchange. A signature 3458 may be sent only in the initial media stream in a DH or ECDH ZRTP 3459 exchange, not in multistream mode. 3461 Although the signature is sent, the material that is signed, the 3462 sashash, is not sent with it in the Confirm message, since both 3463 parties have already independently calculated the sashash. That is 3464 not the case for the SASrelay message, which must relay the sashash. 3466 To avoid unnecessary signature calculations, a signature SHOULD NOT 3467 be sent if the other ZRTP endpoint did not set the (S) flag in the 3468 Hello message (Section 5.2). 3470 Note that the choice of hash algorithm used in the digital signature 3471 is independent of the hash used in the sashash. The sashash is 3472 determined by the negotiated Hash Type (Section 5.1.2), while the 3473 hash used by the digital signature is separately defined by the 3474 digital signature algorithm. For example, the sashash may be based 3475 on SHA-256, while the digital signature might use SHA-384, if an 3476 ECDSA P-384 key is used. 3478 If the ZRTP key exchange is ECDH, and the SAS is signed, then the 3479 signature SHOULD be ECDSA, using the same size curve as the ECDH 3480 exchange. NSA Suite B ECDSA algorithms may be used with either 3481 OpenPGP-formatted keys, or X.509v3 certificates. 3483 7.2.1. OpenPGP Signatures 3485 If the SAS Signature Type (Section 5.1.7) specifies an OpenPGP 3486 signature ("PGP "), the signature-related fields are arranged as 3487 follows. 3489 The first field after the 4-octet Signature Type Block is the OpenPGP 3490 signature. The format of this signature and the algorithms that 3491 create it are specified by [RFC4880] or [I-D.jivsov-openpgp-ecc]. 3492 The signature is comprised of a complete OpenPGP version 4 signature 3493 in binary form (not Radix-64), as specified in RFC 4880, section 3494 5.2.3, enclosed in the full OpenPGP packet syntax. The length of the 3495 OpenPGP signature is parseable from the signature, and depends on the 3496 type and length of the signing key. 3498 If OpenPGP signatures are supported, an implementation SHOULD NOT 3499 generate signatures using any other signature algorithm except DSA or 3500 ECDSA, but MAY accept other signature types from the other party. 3501 DSA signatures with keys shorter than 2048 bits or longer than 3072 3502 bits MUST NOT be generated. An implementation MUST use only NIST- 3503 approved hash algorithms in signatures, and MUST NOT use SHA1 in the 3504 signature. NIST-approved hash algorithms are found in [FIPS-180-3] 3505 or its SHA-3 successor. ECDSA OpenPGP signatures are specified in 3506 [I-D.jivsov-openpgp-ecc]. Signatures with ECDSA keys larger than 3507 P-384 or smaller than P-224 SHOULD NOT be generated. 3509 RFC 4880 section 5.2.3.18 specifies a way to embed, in an OpenPGP 3510 signature, a URI of the preferred key server. The URI should be 3511 fully specified to obtain the public key of the signing key that 3512 created the signature. This URI MUST be present. 3514 It is up to the recipient of the signature to obtain the public key 3515 of the signing key and determine its validity status using the 3516 OpenPGP trust model discussed in [RFC4880]. 3518 The contents of Figure 20 lie inside the encrypted region of the 3519 Confirm message (Figure 10) or the SASrelay message (Figure 16). 3521 The total length of all the material in Figure 20, including the key 3522 server URI, must not exceed 511 32-bit words (2044 octets). This 3523 length, in words, is stored in the signature length field in the 3524 Confirm or SASrelay message containing the signature. It is 3525 desirable to avoid UDP fragmentation, so the URI should be kept 3526 short. 3528 0 1 2 3 3529 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 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 | Signature Type Block = "PGP " (1 word) | 3532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3533 | | 3534 | OpenPGP signature | 3535 | (variable length) | 3536 | . . . | 3537 | | 3538 +===============================================================+ 3540 Figure 20: OpenPGP Signature format 3542 7.2.2. NSA Suite B Signatures with X.509v3 Certs 3544 If the SAS Signature Type (Section 5.1.7) is "X509", the NSA Suite B 3545 signature-related fields are arranged as follows. 3547 The first field after the 4-octet Signature Type Block is the DER 3548 encoded X.509v3 certificate (the signed public key) of the ECDSA 3549 signing key that created the signature. The format of this 3550 certificate is specified by the NSA's 3551 Suite B Base Certificate and CRL Profile [NSA-Suite-B-Cert]. 3553 Following the X.509v3 certificate at the next word boundary is the 3554 ECDSA signature itself. The size of this field depends on the size 3555 and type of the public key in the aforementioned certificate. The 3556 format of this signature and the algorithms that create it are 3557 specified by [FIPS-186-3]. The signature is comprised of the ECDSA 3558 signature output parameters (r, s) in binary form, concatenated, in 3559 network byte order, with no truncation of leading zeros. The first 3560 half of the signature is r and the second half is s. If ECDSA P-256 3561 is specified, the signature fills 16 words (64 octets), 32 octets 3562 each for r and s. If ECDSA P-384 is specified, the signature fills 3563 24 words (96 octets), 48 octets each for r and s. 3565 It is up to the recipient of the signature to use information in the 3566 certificate and path discovery mechanisms to trace the chain back to 3567 the root CA. It is recommended that end user certificates issued for 3568 secure telephony should contain appropriate path discovery links to 3569 facilitate this. 3571 Figure 21 shows a certificate and an NSA Suite B ECDSA signature. 3572 All this material lies inside the encrypted region of the Confirm 3573 message (Figure 10) or the SASrelay message (Figure 16). 3575 The total length of all the material in Figure 21, including the 3576 X.509v3 certificate, must not exceed 511 32-bit words (2044 octets). 3577 This length, in words, is stored in the signature length field in the 3578 Confirm or SASrelay message containing the signature. It is 3579 desirable to avoid UDP fragmentation, so the certificate material 3580 should be kept to a much smaller size than this. End user certs 3581 issued for this purpose should minimize the size of extraneous 3582 material such as legal notices. 3584 0 1 2 3 3585 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 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 | Signature Type Block = "X509" (1 word) | 3588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 | | 3590 | Signing key's X.509v3 certificate | 3591 | (variable length) | 3592 | . . . | 3593 | | 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 | | 3596 | ECDSA P-256 or P-384 signature | 3597 | (16 words or 24 words) | 3598 | . . . | 3599 | | 3600 +===============================================================+ 3602 Figure 21: X.509v3 NSA Suite B Signature format 3604 7.3. Relaying the SAS through a PBX 3606 ZRTP is designed to use end-to-end encryption. The two parties' 3607 verbal comparison of the short authentication string (SAS) depends on 3608 this assumption. But in some PBX environments, such as Asterisk, 3609 there are usage scenarios that have the PBX acting as a trusted man- 3610 in-the-middle (MiTM), which means there are two back-to-back ZRTP 3611 connections with separate session keys and separate SAS's. 3613 For example, imagine that Bob has a ZRTP-enabled VoIP phone that has 3614 been registered with his company's PBX, so that it is regarded as an 3615 extension of the PBX. Alice, whose phone is not associated with the 3616 PBX, might dial the PBX from the outside, and a ZRTP connection is 3617 negotiated between her phone and the PBX. She then selects Bob's 3618 extension from the company directory in the PBX. The PBX makes a 3619 call to Bob's phone (which might be offsite, many miles away from the 3620 PBX through the Internet) and a separate ZRTP connection is 3621 negotiated between the PBX and Bob's phone. The two ZRTP sessions 3622 have different session keys and different SAS's, which would render 3623 the SAS useless for verbal comparison between Alice and Bob. They 3624 might even mistakenly believe that a wiretapper is present because of 3625 the SAS mismatch, causing undue alarm. 3627 ZRTP has a mechanism for solving this problem by having the PBX relay 3628 the Alice/PBX SAS to Bob, sending it through to Bob in a special 3629 SASrelay message as defined in Section 5.13, which is sent after the 3630 PBX/Bob ZRTP negotiation is complete, after the Confirm messages. 3631 Only the PBX, acting as a special trusted MiTM (trusted by the 3632 recipient of the SASrelay message), will relay the SAS. The SASrelay 3633 message protects the relayed SAS from tampering via an included HMAC, 3634 similar to how the Confirm message is protected. Bob's ZRTP-enabled 3635 phone accepts the relayed SAS for rendering only because Bob's phone 3636 had previously been configured to trust the PBX. This special 3637 trusted relationship with the PBX can be established through a 3638 special security enrollment procedure. After that enrollment 3639 procedure, the PBX is treated by Bob as a special trusted MiTM. This 3640 results in Alice's SAS being rendered to Bob, so that Alice and Bob 3641 may verbally compare them and thus prevent a MiTM attack by any other 3642 untrusted MiTM. 3644 A real bad-guy MiTM cannot exploit this protocol feature to mount a 3645 MiTM attack and relay Alice's SAS to Bob, because Bob has not 3646 previously carried out a special registration ritual with the bad 3647 guy. The relayed SAS would not be rendered by Bob's phone, because 3648 it did not come from a trusted PBX. The recognition of the special 3649 trust relationship is achieved with the prior establishment of a 3650 special shared secret between Bob and his PBX, which is called 3651 pbxsecret (defined in Section 7.3.1), also known as the trusted MiTM 3652 key. 3654 The trusted MiTM key can be stored in a special cache at the time of 3655 the initial enrollment (which is carried out only once for Bob's 3656 phone), and Bob's phone associates this key with the ZID of the PBX, 3657 while the PBX associates it with the ZID of Bob's phone. After the 3658 enrollment has established and stored this trusted MiTM key, it can 3659 be detected during subsequent ZRTP session negotiations between the 3660 PBX and Bob's phone, because the PBX and the phone MUST pass the hash 3661 of the trusted MiTM key in the DH message. It is then used as part 3662 of the key agreement to calculate s0. 3664 The PBX can determine whether it is trusted by the ZRTP user agent of 3665 a phone. The presence of a shared trusted MiTM key in the key 3666 negotiation sequence indicates that the phone has been enrolled with 3667 this PBX and therefore trusts it to act as a trusted MiTM. During a 3668 key agreement with two other ZRTP endpoints, the PBX may have a 3669 shared trusted MiTM key with both endpoints, only one endpoint, or 3670 neither endpoint. If the PBX has a shared trusted MiTM key with 3671 neither endpoint, the PBX MUST NOT relay the SAS. If the PBX has a 3672 shared trusted MiTM key with only one endpoint, the PBX MUST relay 3673 the SAS from one party to the other by sending an SASrelay message to 3674 the endpoint with which it shares a trusted MiTM key. If the PBX has 3675 a shared trusted MiTM key with both endpoints, the PBX MUST relay the 3676 SAS to only one endpoint, not both endpoints. 3678 Note: In the case of sharing trusted MiTM key with both endpoints, 3679 it does not matter which endpoint receives the relayed SAS as long 3680 as only one endpoint receives it. 3682 The relayed SAS fields contain the SAS rendering type and the 3683 complete sashash. The receiver absolutely MUST NOT render the 3684 relayed SAS if it does not come from a specially trusted ZRTP 3685 endpoint. The security of the ZRTP protocol depends on not rendering 3686 a relayed SAS from an untrusted MiTM, because it may be relayed by a 3687 MiTM attacker. See the SASrelay message definition (Figure 16) for 3688 further details. 3690 To ensure that both Alice and Bob will use the same SAS rendering 3691 scheme after the keys are negotiated, the PBX also sends the SASrelay 3692 message to the unenrolled party (which does not regard this PBX as a 3693 trusted MiTM), conveying the SAS rendering scheme, but not the 3694 sashash, which it sets to zero. The unenrolled party will ignore the 3695 relayed SAS field, but will use the specified SAS rendering scheme. 3697 It is possible to route a call through two ZRTP-enabled PBXs using 3698 this scheme. Assume Alice is a ZRTP endpoint who trusts her local 3699 PBX in Atlanta, and Bob is a ZRTP endpoint who trusts his local PBX 3700 in Biloxi. The call is routed from Alice to the Atlanta PBX to the 3701 Biloxi PBX to Bob. Atlanta would relay the Atlanta-Biloxi SAS to 3702 Alice because Alice is enrolled with Atlanta, and Biloxi would relay 3703 the Atlanta-Biloxi SAS to Bob because Bob is enrolled with Biloxi. 3704 The two PBXs are not assumed to be enrolled with each other in this 3705 example. Both Alice and Bob would view and verbally compare the same 3706 relayed SAS, the Atlanta-Biloxi SAS. No more than two trusted MiTM 3707 nodes can be traversed with this relaying scheme. 3709 A ZRTP endpoint phone which trusts a PBX to act as a trusted MiTM is 3710 effectively delegating its own policy decisions of algorithm 3711 negotiation to the PBX. 3713 When a PBX is between two ZRTP endpoints and is terminating their 3714 media streams at the PBX, the PBX presents its own ZID to the two 3715 parties, eclipsing the ZIDs of the two parties from each other. For 3716 example, if several different calls are routed through such a PBX to 3717 several different ZRTP-enabled phones behind the PBX, only a single 3718 ZID is presented to the calling party in every case-- the ZID of the 3719 PBX itself. 3721 The next section describes the initial enrollment procedure that 3722 establishes a special shared secret, a trusted MiTM key, between a 3723 PBX and a phone, so that the phone will learn to recognize the PBX as 3724 a trusted MiTM. 3726 7.3.1. PBX Enrollment and the PBX Enrollment Flag 3728 Both the PBX and the endpoint need to know when enrollment is taking 3729 place. One way of doing this is to setup an enrollment extension on 3730 the PBX which a newly configured endpoint would call and establish a 3731 ZRTP session. The PBX would then play audio media that offers the 3732 user an opportunity to configure his phone to trust this PBX as a 3733 trusted MiTM. The PBX calculates and stores the trusted MiTM shared 3734 secret in its cache and associates it with this phone, indexed by the 3735 phone's ZID. The trusted MiTM PBX shared secret is derived from 3736 ZRTPSess via the ZRTP key derivation function (Section 4.5.1) in this 3737 manner: 3739 pbxsecret = KDF(ZRTPSess, "Trusted MiTM key", (ZIDi || ZIDr), 256) 3741 The pbxsecret is calculated for the whole ZRTP session, not for each 3742 stream within a session, thus the KDF Context field in this case does 3743 not include any stream-specific nonce material. 3745 The PBX signals the enrollment process by setting the PBX Enrollment 3746 flag (E) in the Confirm message (Figure 10). This flag is used to 3747 trigger the ZRTP endpoint's user interface to prompt the user if they 3748 want to trust this PBX and calculate and store the pbxsecret in the 3749 cache. If the user decides to respond by activating the appropriate 3750 user interface element (a menu item, checkbox, or button), his ZRTP 3751 user agent calculates pbxsecret using the same formula and saves it 3752 in a special cache entry associated with this PBX. 3754 During a PBX enrollment, the GoClear features are disabled. If the 3755 (E) flag is set by the PBX, the PBX MUST NOT set the Allow Clear (A) 3756 flag. Thus, (E) implies not (A). If a received Confirm message has 3757 the (E) flag set, the (A) flag MUST be disregarded and treated as 3758 false. 3760 If the user elects not to enroll, perhaps because he dialed a wrong 3761 number or does not yet feel comfortable with this PBX, he can simply 3762 hang up and not save the pbxsecret in his cache. The PBX will have 3763 it saved in the PBX cache, but that will do no harm. The SASrelay 3764 scheme does not depend on the PBX trusting the phone. It only 3765 depends on the phone trusting the PBX. It is the phone (the user) 3766 who is at risk if the PBX abuses its MiTM privileges. 3768 An endpoint MUST NOT store the pbxsecret in the cache without 3769 explicit user authorization. 3771 After this enrollment process, the PBX and the ZRTP-enabled phone 3772 both share a secret that enables the phone to recognize the PBX as a 3773 trusted MiTM in future calls. This means that when a future call 3774 from an outside ZRTP-enabled caller is relayed through the PBX to 3775 this phone, the phone will render a relayed SAS from the PBX. If the 3776 SASrelay message comes from a MiTM which does not know the pbxsecret, 3777 the phone treats it as a "bad guy" MiTM, and refuses to render the 3778 relayed SAS. Regardless of which party initiates any future phone 3779 calls through the PBX, the enrolled phone or the outside phone, the 3780 PBX will relay the SAS to the enrolled phone. 3782 There are other ways that ZRTP user agents can be configured to trust 3783 a PBX. Perhaps the pbxsecret can be configured into the phone by 3784 some automated provisioning process in large IT environments. This 3785 specification does not require that products be configured solely by 3786 this enrollment process. Any process that results in a pbxsecret to 3787 be computed and shared between the PBX and the phone will suffice. 3788 This is one such method that has been shown to work. 3790 8. Signaling Interactions 3792 This section discusses how ZRTP, SIP, and SDP work together. 3794 Note that ZRTP may be implemented without coupling with the SIP 3795 signaling. For example, ZRTP can be implemented as a "bump in the 3796 wire" or as a "bump in the stack" in which RTP sent by the SIP UA is 3797 converted to ZRTP. In these cases, the SIP UA will have no knowledge 3798 of ZRTP. As a result, the signaling path discovery mechanisms 3799 introduced in this section should not be definitive - they are a 3800 hint. Despite the absence of an indication of ZRTP support in an 3801 offer or answer, a ZRTP endpoint SHOULD still send Hello messages. 3803 ZRTP endpoints which have control over the signaling path include a 3804 ZRTP SDP attributes in their SDP offers and answers. The ZRTP 3805 attribute, a=zrtp-hash is used to indicate support for ZRTP and to 3806 convey a hash of the Hello message. The hash is computed according 3807 to Section 8.1. 3809 Aside from the advantages described in Section 8.1, there are a 3810 number of potential uses for this attribute. It is useful when 3811 signaling elements would like to know when ZRTP may be utilized by 3812 endpoints. It is also useful if endpoints support multiple methods 3813 of SRTP key management. The ZRTP attribute can be used to ensure 3814 that these key management approaches work together instead of against 3815 each other. For example, if only one endpoint supports ZRTP but both 3816 support another method to key SRTP, then the other method will be 3817 used instead. When used in parallel, an SRTP secret carried in an 3818 a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a 3819 shared secret for the srtps computation defined in Section 8.2. The 3820 ZRTP attribute is also used to signal to an intermediary ZRTP device 3821 not to act as a ZRTP endpoint, as discussed in Section 10. 3823 The a=zrtp-hash attribute can only be included in the SDP at the 3824 media level since Hello messages sent in different media streams will 3825 have unique hashes. 3827 The ABNF for the ZRTP attribute is as follows: 3829 zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value 3831 zrtp-version = token 3833 zrtp-hash-value = 1*(HEXDIG) 3835 Here's an example of the ZRTP attribute in an initial SDP offer or 3836 answer used at the media level, using the convention 3837 defined in RFC 4475, section 2.1 [RFC4475]: 3839 v=0 3840 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 3841 s= 3842 c=IN IP4 client.biloxi.example.com 3843 t=0 0 3844 m=audio 3456 RTP/AVP 97 33 3845 a=rtpmap:97 iLBC/8000 3846 a=rtpmap:33 no-op/8000 3847 3848 a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2 3849 df881ae642c371ba46df 3850 3852 A mechanism for carrying this same zrtp-hash information in the 3853 Jingle signaling protocol is defined in [XEP-0262]. 3855 It should be safe to send ZRTP messages even when there is no 3856 evidence in the signaling that the other party supports it, because 3857 ZRTP has been designed to be clearly different from RTP, having a 3858 similar structure to STUN packets sent during an ICE exchange. 3860 8.1. Binding the media stream to the signaling layer via the Hello Hash 3862 Tying the media stream to the signaling channel can help prevent a 3863 third party from inserting false media packets. If the signaling 3864 layer contains information that ties it to the media stream, false 3865 media streams can be rejected. 3867 To accomplish this, the entire Hello message (Figure 3) is hashed, 3868 using the hash algorithm defined in Section 5.1.2.1. The ZRTP packet 3869 framing from Figure 2 is not included in the hash. The resulting 3870 hash image is made available without truncation to the signaling 3871 layer, where it is transmitted as a hexadecimal value in the SIP 3872 channel using the SDP attribute a=zrtp-hash, defined in this 3873 specification. Assuming Section 5.1.2.1 defines a 256-bit hash 3874 length, the a=zrtp-hash field in the SDP attribute carries 64 3875 hexidecimal digits. Each media stream (audio or video) will have a 3876 separate Hello message, and thus will require a separate a=zrtp-hash 3877 in an SDP attribute. The recipient of the SIP/SDP message can then 3878 use this hash image to detect and reject false Hello messages in the 3879 media channel, as well as identify which media stream is associated 3880 with this SIP call. Each Hello message hashes uniquely, because it 3881 contains the H3 field derived from a random nonce, defined in 3882 Section 9. 3884 The Hello Hash as an SDP attribute is not a REQUIRED feature, because 3885 some ZRTP endpoints do not have the ability to add SDP attributes to 3886 the signaling. For example, if ZRTP is implemented in a hardware 3887 bump-in-the-wire device, it might only have the ability to modify the 3888 media packets, not the SIP packets, especially if the SIP packets are 3889 integrity protected and thus cannot be modified on the wire. If the 3890 SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP 3891 user agent cannot check it, and thus will not be able to reject Hello 3892 messages based on this hash. 3894 After the Hello Hash is used to properly identify the ZRTP Hello 3895 message as belonging to this particular SIP call, the rest of the 3896 ZRTP message sequence is protected from false packet injection by 3897 other protection mechanisms, such as the hash chaining mechanism 3898 defined in Section 9. 3900 An attacker who controls only the signaling layer, such as an 3901 uncooperative VoIP service provider, may be able to deny service by 3902 corrupting the hash of the Hello message in the SDP attribute, which 3903 would force ZRTP to reject perfectly good Hello messages. If there 3904 is reason to believe this is happening, the ZRTP endpoint MAY allow 3905 Hello messages to be accepted that do not match the hash image in the 3906 SDP attribute. 3908 Even in the absence of SIP integrity protection, the inclusion of the 3909 a=zrtp-hash SDP attribute, when coupled with the hash chaining 3910 mechanism defined in Section 9, meets the R-ASSOC requirement in the 3911 Media Security Requirements [RFC5479], which requires: 3913 "...a mechanism for associating key management messages with both 3914 the signaling traffic that initiated the session and with 3915 protected media traffic. Allowing such an association also allows 3916 the SDP offerer to avoid performing CPU-consuming operations 3917 (e.g., Diffie-Hellman or public key operations) with attackers 3918 that have not seen the signaling messages." 3920 The a=zrtp-hash SDP attribute becomes especially useful if the SDP is 3921 integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474] 3922 or better still, Dan Wing's SIP Identity using Media Path 3923 [I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM 3924 attacks independent of ZRTP's SAS mechanism, as explained in 3925 Section 8.1.1 below. 3927 8.1.1. Integrity-protected signaling enables integrity-protected DH 3928 exchange 3930 If and only if the signaling path and the SDP is protected by some 3931 form of end-to-end integrity protection, such as one of the 3932 abovementioned mechanisms, so that it can guarantee delivery of the 3933 a=zrtp-hash attribute without any tampering by a third party, and if 3934 there is good reason to trust the signaling layer to protect the 3935 interests of the end user, it is possible to authenticate the key 3936 exchange and prevent a MiTM attack. This can be done without 3937 requiring the users to verbally compare the SAS, by using the hash 3938 chaining mechanism defined in Section 9 to provide a series of HMAC 3939 keys that protect the entire ZRTP key exchange. Thus, an end-to-end 3940 integrity-protected signaling layer automatically enables an 3941 integrity-protected Diffie-Hellman exchange in ZRTP, which in turn 3942 means immunity from a MiTM attack. Here's how it works. 3944 The integrity-protected SIP SDP contains a hash commitment to the 3945 entire Hello message. The Hello message contains H3, which provides 3946 a hash commitment for the rest of the hash chain H0-H2 (Section 9). 3947 The Hello message is protected by a 64-bit HMAC, keyed by H2. The 3948 Commit message is protected by a 64-bit HMAC keyed by H1. The 3949 DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by 3950 H0. The HMAC protecting the Confirm messages are computed by a 3951 different HMAC key derived from the resulting key agreement. Each 3952 message's HMAC is checked when the HMAC key is received in the next 3953 message. If a bad HMAC is discovered, it MUST be treated as a 3954 security exception indicating a MiTM attack, perhaps by logging or 3955 alerting the user, and MUST NOT be treated as a random error. Random 3956 errors are already discovered and quietly rejected by bad CRCs 3957 (Figure 2). 3959 The Hello message must be assembled before any hash algorithms are 3960 negotiated, so an implicit predetermined hash algorithm and HMAC 3961 algorithm (both defined in Section 5.1.2.1) must be used. All of the 3962 aforementioned HMACs keyed by the hashes in the aforementioned hash 3963 chain MUST be computed with the HMAC algorithm defined in 3964 Section 5.1.2.1, with the HMAC truncated to 64 bits. 3966 The Media Security Requirements [RFC5479] R-EXISTING requirement can 3967 be fully met by leveraging a certificate-backed PKI in the signaling 3968 layer to integrity-protect the delivery of the a=zrtp-hash SDP 3969 attribute. This would thereby protect ZRTP against a MiTM attack, 3970 without requiring the user to check the SAS, without adding any 3971 explicit signatures or signature keys to the ZRTP key exchange, and 3972 without any extra public key operations or extra packets. 3974 Without an end-to-end integrity protection mechanism in the signaling 3975 layer to guarantee delivery of the a=zrtp-hash SDP attribute without 3976 modification by a third party, these HMACs alone will not prevent a 3977 MiTM attack. In that case, ZRTP's built-in SAS mechanism will still 3978 have to be used to authenticate the key exchange. At the time of 3979 this writing, very few deployed VoIP clients offer a fully 3980 implemented SIP stack that provides end-to-end integrity protection 3981 for the delivery of SDP attributes. Also, end-to-end signaling 3982 integrity becomes more problematic if E.164 numbers [RFC3824] are 3983 used in SIP. Thus, real-world implementations of ZRTP endpoints will 3984 continue to depend on SAS authentication for quite some time. Even 3985 after there is widespread availability of SIP user agents that offer 3986 integrity protected delivery of SDP attributes, many users will still 3987 be faced with the fact that the signaling path may be controlled by 3988 institutions that do not have the best interests of the end user in 3989 mind. In those cases, SAS authentication will remain the gold 3990 standard for the prudent user. 3992 Even without SIP integrity protection, the Media Security 3993 Requirements [RFC5479] R-ACT-ACT requirement can be met by ZRTP's SAS 3994 mechanism. Although ZRTP may benefit from an integrity-protected SIP 3995 layer, it is fortunate that ZRTP's self-contained MiTM defenses do 3996 not actually require an integrity-protected SIP layer. ZRTP can 3997 bypass the delays and problems that SIP integrity faces, such as 3998 E.164 number usage, and the complexity of building and maintaining a 3999 PKI. 4001 In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend 4002 heavily on end-to-end integrity protection in the SIP layer. 4003 Further, DTLS-SRTP must bear the additional cost of a signature 4004 calculation of its own, in addition to the signature calculation the 4005 SIP layer uses to achieve its integrity protection. ZRTP needs no 4006 signature calculation of its own to leverage the signature 4007 calculation carried out in the SIP layer. 4009 8.2. Deriving the SRTP secret (srtps) from the signaling layer 4011 The shared secret calculations defined in Section 4.3 make use of the 4012 SRTP secret (srtps), if it is provided by the signaling layer. 4014 It is desirable for only one SRTP key negotiation protocol to be 4015 used, and that protocol should be ZRTP. But in the event the 4016 signaling layer negotiates its own SRTP master key and salt, using 4017 the SDP Security Descriptions (SDES [RFC4568]) or [RFC4567], it can 4018 be passed from the signaling to the ZRTP layer and mixed into ZRTP's 4019 own shared secret calculations, without compromising security by 4020 creating a dependency on the signaling for media encryption. 4022 ZRTP computes srtps from the SRTP master key and salt parameters 4023 provided by the signaling layer in this manner, truncating the result 4024 to 256 bits: 4026 srtps = KDF(SRTP master key, "SRTP Secret", (ZIDi || ZIDr || SRTP 4027 master salt), 256) 4029 It is expected that the srtps parameter will be rarely computed or 4030 used in typical ZRTP endpoints, because it is likely and desirable 4031 that ZRTP will be the sole means of negotiating SRTP keys, needing no 4032 help from [RFC4568] or [RFC4567]. If srtps is computed, it will be 4033 stored in the auxiliary shared secret auxsecret, defined in 4034 Section 4.3, and used in Section 4.3.1. 4036 8.3. Codec Selection for Secure Media 4038 Codec selection is negotiated in the signaling layer. If the 4039 signaling layer determines that ZRTP is supported by both endpoints, 4040 this should provide guidance in codec selection to avoid variable 4041 bit-rate (VBR) codecs that leak information. 4043 When voice is compressed with a VBR codec, the packet lengths vary 4044 depending on the types of sounds being compressed. This leaks a lot 4045 of information about the content even if the packets are encrypted, 4046 regardless of what encryption protocol is used [Wright1]. It is 4047 RECOMMENDED that VBR codecs be avoided in encrypted calls. It is not 4048 a problem if the codec adapts the bit rate to the available channel 4049 bandwidth. The vulnerable codecs are the ones that change their bit 4050 rate depending on the type of sound being compressed. 4052 It also appears that voice activity detection (VAD) leaks information 4053 about the content of the conversation, but to a lesser extent than 4054 VBR. This effect can be mitigated by lengthening the VAD hangover 4055 time by a random amount between 1 to 2 seconds, if this is feasible 4056 in your application. Only short bursts of speech would benefit from 4057 lengthening the VAD hangover time. 4059 The security problems of VBR and VAD are addressed in detail by the 4060 guidelines in [I-D.perkins-avt-srtp-vbr-audio]. It is RECOMMENDED 4061 that ZRTP endpoints follow these guidelines. 4063 9. False ZRTP Packet Rejection 4065 An attacker who is not in the media path may attempt to inject false 4066 ZRTP protocol packets, possibly to effect a denial of service attack, 4067 or to inject his own media stream into the call. VoIP by its nature 4068 invites various forms of denial of service attacks and requires 4069 protocol features to reject such attacks. While bogus SRTP packets 4070 may be easily rejected via the SRTP auth tag field, that can only be 4071 applied after a key agreement is completed. During the ZRTP key 4072 negotiation phase, other false packet rejection mechanisms are 4073 needed. One such mechanism is the use of the total_hash in the final 4074 shared secret calculation, but that can only detect false packets 4075 after performing the computationally expensive Diffie-Hellman 4076 calculation. 4078 A lot of work has been done on the analysis of denial of service 4079 attacks, especially from attackers who are not in the media path. 4080 Such an attacker might inject false ZRTP packets to force a ZRTP 4081 endpoint to engage in an endless series of pointless and expensive DH 4082 calculations. To detect and reject false packets cheaply and rapidly 4083 as soon as they are received, ZRTP uses a hash chain, which is a 4084 series of successive hash images. Before each session, the following 4085 values are computed: 4087 H0 = 256-bit random nonce (different for each party) 4088 H1 = hash (H0) 4089 H2 = hash (H1) 4090 H3 = hash (H2) 4092 The hash chain MUST use the hash algorithm defined in 4093 Section 5.1.2.1, truncated to 256 bits. Each 256-bit hash image is 4094 the preimage of the next, and the sequence of images is sent in 4095 reverse order in the ZRTP packet sequence. The hash image H3 is sent 4096 in the Hello message, H2 is sent in the Commit message, H1 is sent in 4097 the DHPart1 or DHPart2 messages, and H0 is sent in the Confirm1 or 4098 Confirm2 messages. The initial random H0 nonces that each party 4099 generates MUST be unpredictable to an attacker and unique within a 4100 ZRTP session, which thereby forces the derived hash images H1-H3 to 4101 also be unique and unpredictable. 4103 The recipient checks if the packet has the correct hash preimage, by 4104 hashing it and comparing the result with the hash image for the 4105 preceding packet. Packets which contain an incorrect hash preimage 4106 MUST NOT be used by the recipient, but MAY be processed as security 4107 exceptions, perhaps by logging or alerting the user. As long as 4108 these bogus packets are not used, and correct packets are still being 4109 received, the protocol SHOULD be allowed to run to completion, 4110 thereby rendering ineffective this denial of service attack. 4112 Note that since H2 is sent in the Commit message, and the initiator 4113 does not receive a Commit message, the initiator computes the 4114 responder's missing H2 by hashing the responder's H1. An analogous 4115 interpolation is performed by both parties to handle the skipped 4116 DHPart1 and DHPart2 messages in Preshared (Section 3.1.2) or 4117 Multistream (Section 3.1.3) modes. 4119 Because these hash images alone do not protect the rest of the 4120 contents of the packet they reside in, this scheme assumes the 4121 attacker cannot modify the packet contents from a legitimate party, 4122 which is a reasonable assumption for an attacker who is not in the 4123 media path. This covers an important range of denial-of-service 4124 attacks. For dealing with the remaining set of attacks that involve 4125 packet modification, other mechanisms are used, such as the 4126 total_hash in the final shared secret calculation, and the hash 4127 commitment in the Commit message. 4129 Hello messages injected by an attacker may be detected and rejected 4130 by the inclusion of a hash of the Hello message in the signaling, as 4131 described in Section 8. This mechanism requires that each Hello 4132 message be unique, and the inclusion of the H3 hash image meets that 4133 requirement. 4135 If and only if an integrity-protected signaling channel is available, 4136 this hash chaining scheme can be used to key HMACs to authenticate 4137 the entire ZRTP key exchange, and thereby prevent a MiTM attack, 4138 without relying on the users verbally comparing the SAS. See 4139 Section 8.1.1 for details. 4141 Some ZRTP user agents allow the user to manually switch to clear mode 4142 (via the GoClear message) in the middle of a secure call, and then 4143 later initiate secure mode again. Many consumer client products will 4144 omit this feature, but those that allow it may return to secure mode 4145 again in the same media stream. Although the same chain of hash 4146 images will be re-used and thus rendered ineffective the second time, 4147 no real harm is done because the new SRTP session keys will be 4148 derived in part from a cached shared secret, which was safely 4149 protected from the MiTM in the previous DH exchange earlier in the 4150 same session. 4152 10. Intermediary ZRTP Devices 4154 This section discusses the operation of a ZRTP endpoint which is 4155 actually an intermediary. For example, consider a device which 4156 proxies both signaling and media between endpoints. There are three 4157 possible ways in which such a device could support ZRTP. 4159 An intermediary device can act transparently to the ZRTP protocol. 4160 To do this, a device MUST pass RTP header extensions and payloads (to 4161 allow the ZRTP Flag) and non-RTP protocols multiplexed on the same 4162 port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED 4163 behavior for intermediaries as ZRTP and SRTP are best when done end- 4164 to-end. 4166 An intermediary device could implement the ZRTP protocol and act as a 4167 ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary 4168 device. The intermediary could determine on a call-by-call basis 4169 whether the endpoint behind it supports ZRTP based on the presence or 4170 absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP 4171 endpoints, the intermediary device could act as the ZRTP endpoint 4172 using its own ZID and cache. This approach SHOULD only be used when 4173 there is some other security method protecting the confidentiality of 4174 the media between the intermediary and the inside endpoint, such as 4175 IPSec or physical security. 4177 The third mode, which is NOT RECOMMENDED, is for the intermediary 4178 device to attempt to back-to-back the ZRTP protocol. The only 4179 exception to this case is where the intermediary device is a trusted 4180 element providing services to one of the endpoints - e.g. a Private 4181 Branch Exchange or PBX. In this mode, the intermediary would attempt 4182 to act as a ZRTP endpoint towards both endpoints of the media 4183 session. This approach MUST NOT be used except as described in 4184 Section 7.3 as it will always result in a detected man-in-the-middle 4185 attack and will generate alarms on both endpoints and likely result 4186 in the immediate termination of the session. The PBX MUST uses a 4187 single ZID for all endpoints behind it. 4189 In cases where centralized media mixing is taking place, the SAS will 4190 not match when compared by the humans. This situation can sometimes 4191 be known in the SIP signaling by the presence of the isfocus feature 4192 tag [RFC4579]. As a result, when the isfocus feature tag is present, 4193 the DH exchange can be authenticated by the mechanism defined in 4194 Section 8.1.1 or by validating signatures (Section 7.2) in the 4195 Confirm or SASrelay messages. For example, consider an audio 4196 conference call with three participants Alice, Bob, and Carol hosted 4197 on a conference bridge in Dallas. There will be three ZRTP encrypted 4198 media streams, one encrypted stream between each participant and 4199 Dallas. Each will have a different SAS. Each participant will be 4200 able to validate their SAS with the conference bridge by using 4201 signatures optionally present in the Confirm messages (described in 4202 Section 7.2). Or, if the signaling path has end-to-end integrity 4203 protection, each DH exchange will have automatic MiTM protection by 4204 using the mechanism in Section 8.1.1. 4206 SIP feature tags can also be used to detect if a session is 4207 established with an automaton such as an IVR, voicemail system, or 4208 speech recognition system. The display of SAS strings to users 4209 should be disabled in these cases. 4211 It is possible that an intermediary device acting as a ZRTP endpoint 4212 might still receive ZRTP Hello and other messages from the inside 4213 endpoint. This could occur if there is another inline ZRTP device 4214 which does not include the ZRTP SDP attribute flag. An intermediary 4215 acting as a ZRTP endpoint receiving ZRTP Hello and other messages 4216 from the inside endpoint MUST NOT pass these ZRTP messages. 4218 11. The ZRTP Disclosure flag 4220 There are no back doors defined in the ZRTP protocol specification. 4221 The designers of ZRTP would like to discourage back doors in ZRTP- 4222 enabled products. However, despite the lack of back doors in the 4223 actual ZRTP protocol, it must be recognized that a ZRTP implementer 4224 might still deliberately create a rogue ZRTP-enabled product that 4225 implements a back door outside the scope of the ZRTP protocol. For 4226 example, they could create a product that discloses the SRTP session 4227 key generated using ZRTP out-of-band to a third party. They may even 4228 have a legitimate business reason to do this for some customers. 4230 For example, some environments have a need to monitor or record 4231 calls, such as stock brokerage houses who want to discourage insider 4232 trading, or special high security environments with special needs to 4233 monitor their own phone calls. We've all experienced automated 4234 messages telling us that "This call may be monitored for quality 4235 assurance". A ZRTP endpoint in such an environment might 4236 unilaterally disclose the session key to someone monitoring the call. 4237 ZRTP-enabled products that perform such out-of-band disclosures of 4238 the session key can undermine public confidence in the ZRTP protocol, 4239 unless we do everything we can in the protocol to alert the other 4240 user that this is happening. 4242 If one of the parties is using a product that is designed to disclose 4243 their session key, ZRTP requires them to confess this fact to the 4244 other party through a protocol message to the other party's ZRTP 4245 client, which can properly alert that user, perhaps by rendering it 4246 in a graphical user interface. The disclosing party does this by 4247 sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as 4248 described in Section 5.7. 4250 Note that the intention here is to have the Disclosure flag identify 4251 products that are designed to disclose their session keys, not to 4252 identify which particular calls are compromised on a call-by-call 4253 basis. This is an important legal distinction, because most 4254 government sanctioned wiretap regulations require a VoIP service 4255 provider to not reveal which particular calls are wiretapped. But 4256 there is nothing illegal about revealing that a product is designed 4257 to be wiretap-friendly. The ZRTP protocol mandates that such a 4258 product "out" itself. 4260 You might be using a ZRTP-enabled product with no back doors, but if 4261 your own graphical user interface tells you the call is (mostly) 4262 secure, except that the other party is using a product that is 4263 designed in such a way that it may have disclosed the session key for 4264 monitoring purposes, you might ask him what brand of secure telephone 4265 he is using, and make a mental note not to purchase that brand 4266 yourself. If we create a protocol environment that requires such 4267 back-doored phones to confess their nature, word will spread quickly, 4268 and the "invisible hand" of the free market will act. The free 4269 market has effectively dealt with this in the past. 4271 Of course, a ZRTP implementer can lie about his product having a back 4272 door, but the ZRTP standard mandates that ZRTP-compliant products 4273 MUST adhere to the requirement that a back door be confessed by 4274 sending the Disclosure flag to the other party. 4276 There will be inevitable comparisons to Steve Bellovin's 2003 April 4277 fool's joke, when he submitted RFC 3514 [RFC3514] which defined the 4278 "Evil bit" in the IPV4 header, for packets with "evil intent". But 4279 we submit that a similar idea can actually have some merit for 4280 securing VoIP. Sure, one can always imagine that some implementer 4281 will not be fazed by the rules and will lie, but they would have lied 4282 anyway even without the Disclosure flag. There are good reasons to 4283 believe that it will improve the overall percentage of 4284 implementations that at least tell us if they put a back door in 4285 their products, and may even get some of them to decide not to put in 4286 a back door at all. From a civic hygiene perspective, we are better 4287 off with having the Disclosure flag in the protocol. 4289 If an endpoint stores or logs SRTP keys or information that can be 4290 used to reconstruct or recover SRTP keys after they are no longer in 4291 use (i.e. the session is active), or otherwise discloses or passes 4292 SRTP keys or information that can be used to reconstruct or recover 4293 SRTP keys to another application or device, the Disclosure flag D 4294 MUST be set in the Confirm1 or Confirm2 message. 4296 11.1. Guidelines on Proper Implementation of the Disclosure Flag 4298 Some implementers have asked for guidance on implementing the 4299 Disclosure Flag. Some people have incorrectly thought that a 4300 connection secured with ZRTP cannot be used in a call center, with 4301 voluntary voice recording, or even with a voicemail system. 4302 Similarly, some potential users of ZRTP have over considered the 4303 protection that ZRTP can give them. These guidelines clarify both 4304 concerns. 4306 The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. 4307 It does not govern the underlying RTP media stream, nor the actual 4308 media itself. Consequently, a PBX that uses ZRTP may provide 4309 conference calls, call monitoring, call recording, voicemail, or 4310 other PBX features and still say that it does not disclose the ZRTP 4311 key material. A video system may provide DVR features and still say 4312 that it does not disclose the ZRTP key material. The ZRTP Disclosure 4313 Flag, when not set, means only that the ZRTP cryptographic key 4314 material stays within the bounds of the ZRTP subsystem. 4316 If an application has a need to disclose the ZRTP cryptographic key 4317 material, the easiest way to comply with the protocol is to set the 4318 flag to the proper value. The next easiest way is to overestimate 4319 disclosure. For example, a call center that commonly records calls 4320 might choose to set the disclosure flag even though all recording is 4321 an analog recording of a call (and thus outside the ZRTP scope) 4322 because it sets an expectation with clients that their calls might be 4323 recorded. 4325 Note also that the ZRTP Disclosure Flag does not require an 4326 implementation to preclude hacking or malware. Malware that leaks 4327 ZRTP cryptographic key material does not create a liability for the 4328 implementor from non-compliance with the ZRTP specification. 4330 A user of ZRTP should note that ZRTP is not a panacea against 4331 unauthorized recording. ZRTP does not and cannot protect against an 4332 untrustworthy partner who holds a microphone up to the speaker. It 4333 does not protect against someone else being in the room. It does not 4334 protect against analog wiretaps in the phone or in the room. It does 4335 not mean your partner has not been hacked with spyware. It does not 4336 mean that the software has no flaws. It means that the ZRTP 4337 subsystem is not knowingly leaking ZRTP cryptographic key material. 4339 12. RTP Header Extension Flag for ZRTP 4341 This specification defines a new RTP header extension used only for 4342 discovery of support for ZRTP. No ZRTP data is transported in the 4343 extension. When used, the X bit is set in the RTP header to indicate 4344 the presence of the RTP header extension. 4346 In RFC 3550, section 5.3.1 [RFC3550], the format of an RTP Header 4347 extension is defined. The Header extension is appended to the RTP 4348 header. The first 16 bits are an identifier for the header 4349 extension, and the following 16 bits are the length of the extension 4350 header in 32 bit words. The ZRTP flag RTP header extension has the 4351 value of 0x505A and a length of 0. The format of the header 4352 extension is as shown in the Figure below. 4354 0 1 2 3 4355 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 4356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4357 |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| 4358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4360 Figure 22: RTP Extension header format for ZRTP Flag 4362 ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at 4363 the start of a session, for at least the first 50 RTP packets sent. 4364 The inclusion of the flag MAY be ended if a ZRTP message (such as 4365 Hello) is received. 4367 In RFC 5285, section 5 [RFC5285], RTP Header extensions are declared 4368 in SDP fields in SIP packets before they can be used in the RTP media 4369 stream. ZRTP does not use this mechanism for two reasons. One 4370 reason is that the ZRTP usage of RTP header extensions predates RFC 4371 5285, using mechanisms permitted by RFC 3550. More significantly, 4372 ZRTP does not depend on any particular signaling protocol. It works 4373 equally well with SIP, Jingle, H.323, P2P-SIP, or any future 4374 signaling protocol. 4376 13. IANA Considerations 4378 This specification defines a new SDP [RFC4566] attribute in 4379 Section 8. 4381 Contact name: Philip Zimmermann 4383 Attribute name: "zrtp-hash". 4385 Type of attribute: Media level. 4387 Subject to charset: Not. 4389 Purpose of attribute: The 'zrtp-hash' indicates that a UA supports 4390 the ZRTP protocol and provides a hash of the 4391 ZRTP Hello message. The ZRTP protocol 4392 version number is also specified. 4394 Allowed attribute values: Hex. 4396 14. Appendix - Media Security Requirements 4398 This section discuses how ZRTP meets all RTP security requirements 4399 discussed in the Media Security Requirements [RFC5479] document 4400 without any dependencies on other protocols or extensions, unlike 4401 DTLS-SRTP [I-D.ietf-avt-dtls-srtp] which requires additional 4402 protocols and mechanisms. 4404 R-FORK-RETARGET is met since ZRTP is a media path key agreement 4405 protocol. 4407 R-DISTINCT is met since ZRTP uses ZIDs and allows multiple 4408 independent ZRTP exchanges to proceed. 4410 R-HERFP is met since ZRTP is a media path key agreement protocol. 4412 R-REUSE is met using the Multistream and Preshared modes. 4414 R-AVOID-CLIPPING is met since ZRTP is a media path key agreement 4415 protocol. 4417 R-RTP-CHECK is met since the ZRTP packet format does not pass the 4418 RTP validity check. 4420 R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and 4421 responses (Section 8.1). 4423 R-NEGOTIATE is met using the Commit message. 4425 R-PSTN is met since ZRTP can be implemented in Gateways. 4427 R-PFS is met using ZRTP Diffie-Hellman key agreement methods. 4429 R-COMPUTE is met using the Hello/Commit ZRTP exchange. 4431 R-CERTS is met using the verbal comparison of the SAS. 4433 R-FIPS is met since ZRTP uses only FIPS-approved algorithms in all 4434 relevant categories. To meet the FIPS-140 validation requirements 4435 set by NIST FIPS PUB 140-2 Annex A [FIPS-140-2-Annex-A] and NIST 4436 FIPS PUB 140-2 Annex D [FIPS-140-2-Annex-D], ZRTP is compliant 4437 with NIST SP 800-56A [SP800-56A], NIST SP 800-108 [SP800-108], 4438 NIST FIPS PUB 198-1 [FIPS-198-1], NIST FIPS PUB 180-3 4439 [FIPS-180-3], NIST SP 800-38A [SP800-38A], NIST FIPS PUB 197 4440 [FIPS-197], and NSA Suite B [NSA-Suite-B]. 4442 R-DOS is met since ZRTP does not introduce any new denial of 4443 service attacks. 4445 R-EXISTING is met since ZRTP can support the use of certificates 4446 or keys. 4448 R-AGILITY is met since the set of hash, cipher, authentication tag 4449 length, key agreement method, SAS type, and signature type can all 4450 be extended and negotiated. 4452 R-DOWNGRADE is met since ZRTP has protection against downgrade 4453 attacks. 4455 R-PASS-MEDIA is met since ZRTP prevents a passive adversary with 4456 access to the media path from gaining access to keying material 4457 used to protect SRTP media packets. 4459 R-PASS-SIG is met since ZRTP prevents a passive adversary with 4460 access to the signaling path from gaining access to keying 4461 material used to protect SRTP media packets. 4463 R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs 4464 and responses. 4466 R-ID-BINDING is met using the a=zrtp-hash SDP attribute 4467 (Section 8.1). 4469 R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs 4470 and responses. 4472 R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and 4473 hence best effort SRTP in every case. 4475 R-OTHER-SIGNALING is met since ZRTP can utilize modes in which 4476 there is no dependency on the signaling path. 4478 R-RECORDING is met using the ZRTP Disclosure flag. 4480 R-TRANSCODER is met if the transcoder operates as a trusted MitM 4481 (i.e. a PBX). 4483 R-ALLOW-RTP is met due to ZRTP's best effort encryption. 4485 15. Security Considerations 4487 This document is all about securely keying SRTP sessions. As such, 4488 security is discussed in every section. 4490 Most secure phones rely on a Diffie-Hellman exchange to agree on a 4491 common session key. But since DH is susceptible to a man-in-the- 4492 middle (MiTM) attack, it is common practice to provide a way to 4493 authenticate the DH exchange. In some military systems, this is done 4494 by depending on digital signatures backed by a centrally-managed PKI. 4495 A decade of industry experience has shown that deploying centrally 4496 managed PKIs can be a painful and often futile experience. PKIs are 4497 just too messy, and require too much activation energy to get them 4498 started. Setting up a PKI requires somebody to run it, which is not 4499 practical for an equipment provider. A service provider like a 4500 carrier might venture down this path, but even then you have to deal 4501 with cross-carrier authentication, certificate revocation lists, and 4502 other complexities. It is much simpler to avoid PKIs altogether, 4503 especially when developing secure commercial products. It is 4504 therefore more common for commercial secure phones in the PSTN world 4505 to augment the DH exchange with a Short Authentication String (SAS) 4506 combined with a hash commitment at the start of the key exchange, to 4507 shorten the length of SAS material that must be read aloud. No PKI 4508 is required for this approach to authenticating the DH exchange. The 4509 AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], PGPfone 4510 [pgpfone], and CryptoPhone [cryptophone] are all examples of products 4511 that took this simpler lightweight approach. The main problem with 4512 this approach is inattentive users who may not execute the voice 4513 authentication procedure. 4515 Some questions have been raised about voice spoofing during the SAS 4516 comparison. But it is a mistake to think this is simply an exercise 4517 in voice impersonation (perhaps this could be called the "Rich 4518 Little" attack). Although there are digital signal processing 4519 techniques for changing a person's voice, that does not mean a man- 4520 in-the-middle attacker can safely break into a phone conversation and 4521 inject his own short authentication string (SAS) at just the right 4522 moment. He doesn't know exactly when or in what manner the users 4523 will choose to read aloud the SAS, or in what context they will bring 4524 it up or say it, or even which of the two speakers will say it, or if 4525 indeed they both will say it. In addition, some methods of rendering 4526 the SAS involve using a list of words such as the PGP word 4527 list[Juola2], in a manner analogous to how pilots use the NATO 4528 phonetic alphabet to convey information. This can make it even more 4529 complicated for the attacker, because these words can be worked into 4530 the conversation in unpredictable ways. Remember that the attacker 4531 places a very high value on not being detected, and if he makes a 4532 mistake, he doesn't get to do it over. Some people have raised the 4533 question that even if the attacker lacks voice impersonation 4534 capabilities, it may be unsafe for people who don't know each other's 4535 voices to depend on the SAS procedure. This is not as much of a 4536 problem as it seems, because it isn't necessary that they recognize 4537 each other by their voice, it is only necessary that they detect that 4538 the voice used for the SAS procedure matches the voice in the rest of 4539 the phone conversation. 4541 Special consideration must be given to secure phone calls with 4542 automated systems that cannot perform a verbal SAS comparison between 4543 two humans. If a well functioning PKI is available to all parties, 4544 it is recommended that credentials be provisioned at the automated 4545 system sufficient to use one of the automatic MiTM detection 4546 mechanisms from Section 8.1.1 or Section 7.2. However, those 4547 optional PKI-dependent mechanisms may be avoided if the automated 4548 system (e.g. a voice mail system) is hosted in a PBX that has 4549 previously established a cached shared secret with the caller 4550 (pbxsecret or rs1 or both), backed by a human-executed SAS comparison 4551 during an initial call. In other words, a ZRTP endpoint that is 4552 manned during an initial session for the SAS compare, and unmanned in 4553 a subsequent voice mail session. Note that it is worse than useless 4554 and absolutely unsafe to rely on a robot voice from the remote 4555 endpoint to compare the SAS, because a robot voice can be easily 4556 forged by a MiTM. However, a robot voice may be safe to use strictly 4557 locally for a different purpose. A ZRTP user agent may render its 4558 locally-computed SAS to the local user via a robot voice if no visual 4559 display is available, provided the user can readily determine that 4560 the robot voice is generated locally, not from the remote endpoint. 4562 A popular and field-proven approach to MiTM protection is used by SSH 4563 (Secure Shell) [RFC4251], which Peter Gutmann likes to call the "baby 4564 duck" security model. SSH establishes a relationship by exchanging 4565 public keys in the initial session, when we assume no attacker is 4566 present, and this makes it possible to authenticate all subsequent 4567 sessions. A successful MiTM attacker has to have been present in all 4568 sessions all the way back to the first one, which is assumed to be 4569 difficult for the attacker. ZRTP's key continuity features are 4570 actually better than SSH, at least for VoIP, for reasons described in 4571 Section 15.1. All this is accomplished without resorting to a 4572 centrally-managed PKI. 4574 We use an analogous baby duck security model to authenticate the DH 4575 exchange in ZRTP. We don't need to exchange persistent public keys, 4576 we can simply cache a shared secret and re-use it to authenticate a 4577 long series of DH exchanges for secure phone calls over a long period 4578 of time. If we read aloud just one SAS, and then cache a shared 4579 secret for later calls to use for authentication, no new voice 4580 authentication rituals need to be executed. We just have to remember 4581 we did one already. 4583 If one party ever loses this cached shared secret, it is no longer 4584 available for authentication of DH exchanges. This cache mismatch 4585 situation is easy to detect by the party that still has a surviving 4586 shared secret cache entry. If it fails to match, either there is a 4587 MiTM attack or one side has lost their shared secret cache entry. 4588 The user agent that discovers the cache mismatch must alert the user 4589 that a cache mismatch has been detected, and that he must do a verbal 4590 comparison of the SAS to distinguish if the mismatch is because of a 4591 MiTM attack or because of the other party losing her cache (normative 4592 language is in Section 4.3.2). Voice confirmation is absolutely 4593 essential in this situation. From that point on, the two parties 4594 start over with a new cached shared secret. Then they can go back to 4595 omitting the voice authentication on later calls. 4597 A particularly compelling reason why this approach is attractive is 4598 that SAS is easiest to implement when a graphical user interface or 4599 some sort of display is available, which raises the question of what 4600 to do when a display is less conveniently available. For example, 4601 some devices that implement ZRTP might have a graphical user 4602 interface that is only visible through a web browser, such as a PBX 4603 or some other nearby device that implements ZRTP as a "bump-in-the- 4604 wire". If we take an approach that greatly reduces the need for a 4605 SAS in each and every call, we can operate in products without a 4606 graphical user interface with greater ease. Then the SAS can be 4607 compared less frequently through a web browser, or it might even be 4608 presented as needed to the local user through a locally generated 4609 voice prompt, which the local user hears and verbally repeats and 4610 compares with the remote party. Using a voice prompt in this way is 4611 purely for the local ZRTP user agent to render the SAS to the local 4612 user, and is not to be confused with the verbal comparison of the SAS 4613 between two human users. 4615 It is a good idea to force your opponent to have to solve multiple 4616 problems in order to mount a successful attack. Some examples of 4617 widely differing problems we might like to present him with are: 4618 Stealing a shared secret from one of the parties, being present on 4619 the very first session and every subsequent session to carry out an 4620 active MiTM attack, and solving the discrete log problem. We want to 4621 force the opponent to solve more than one of these problems to 4622 succeed. 4624 ZRTP can use different kinds of shared secrets. Each type of shared 4625 secret is determined by a different method. All of the shared 4626 secrets are hashed together to form a session key to encrypt the 4627 call. An attacker must defeat all of the methods in order to 4628 determine the session key. 4630 First, there is the shared secret determined entirely by a Diffie- 4631 Hellman key agreement. It changes with every call, based on random 4632 numbers. An attacker may attempt a classic DH MiTM attack on this 4633 secret, but we can protect against this by displaying and reading 4634 aloud an SAS, combined with adding a hash commitment at the beginning 4635 of the DH exchange. 4637 Second, there is an evolving shared secret, or ongoing shared secret 4638 that is automatically changed and refreshed and cached with every new 4639 session. We will call this the cached shared secret, or sometimes 4640 the retained shared secret. Each new image of this ongoing secret is 4641 a non-invertable function of its previous value and the new secret 4642 derived by the new DH agreement. It is possible that no cached 4643 shared secret is available, because there were no previous sessions 4644 to inherit this value from, or because one side loses its cache. 4646 There are other approaches for key agreement for SRTP that compute a 4647 shared secret using information in the signaling. For example, 4648 [RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing) 4649 [RFC3830] payload in SDP [RFC4566]. Or Session Description Protocol 4650 Security Descriptions (SDES [RFC4568]) describes directly carrying 4651 SRTP keying and configuration information in SDP. ZRTP does not rely 4652 on the signaling to compute a shared secret, but if a client does 4653 produce a shared secret via the signaling, and makes it available to 4654 the ZRTP protocol, ZRTP can make use of this shared secret to augment 4655 the list of shared secrets that will be hashed together to form a 4656 session key. This way, any security weaknesses that might compromise 4657 the shared secret contributed by the signaling will not harm the 4658 final resulting session key. 4660 The shared secret provided by the signaling (if available), the 4661 shared secret computed by DH, and the cached shared secret are all 4662 hashed together to compute the session key for a call. If the cached 4663 shared secret is not available, it is omitted from the hash 4664 computation. If the signaling provides no shared secret, it is also 4665 omitted from the hash computation. 4667 No DH MiTM attack can succeed if the ongoing shared secret is 4668 available to the two parties, but not to the attacker. This is 4669 because the attacker cannot compute a common session key with either 4670 party without knowing the cached secret component, even if he 4671 correctly executes a classic DH MiTM attack. 4673 15.1. Self-healing Key Continuity Feature 4675 The key continuity features of ZRTP are analogous to those provided 4676 by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH 4677 caches public signature keys that never change, and uses a permanent 4678 private signature key that must be guarded from disclosure. If 4679 someone steals your SSH private signature key, they can impersonate 4680 you in all future sessions and can mount a successful MiTM attack any 4681 time they want. 4683 ZRTP caches symmetric key material used to compute secret session 4684 keys, and these values change with each session. If someone steals 4685 your ZRTP shared secret cache, they only get one chance to mount a 4686 MiTM attack, in the very next session. If they miss that chance, the 4687 retained shared secret is refreshed with a new value, and the window 4688 of vulnerability heals itself, which means they are locked out of any 4689 future opportunities to mount a MiTM attack. This gives ZRTP a 4690 "self-healing" feature if any cached key material is compromised. 4692 A MiTM attacker must always be in the media path. This presents a 4693 significant operational burden for the attacker in many VoIP usage 4694 scenarios, because being in the media path for every call is often 4695 harder than being in the signaling path. This will likely create 4696 coverage gaps in the attacker's opportunities to mount a MiTM attack. 4697 ZRTP's self-healing key continuity features are better than SSH at 4698 exploiting any temporary gaps in MiTM attack opportunities. Thus, 4699 ZRTP quickly recovers from any disclosure of cached key material. 4701 In systems that use a persistant private signature key, such as SSH, 4702 the stored signature key is usually protected from disclosure by 4703 encryption that requires a user-supplied high-entropy passphrase. 4704 This arrangement may be acceptable for a diligent user with a desktop 4705 computer sitting in an office with a full ASCII keyboard. But it 4706 would be prohibitively inconvenient and unsafe to type a high-entropy 4707 passphrase on a mobile phone's numeric keypad while driving a car. 4708 Users will reject any scheme that requires the use of a passphrase on 4709 such a platform. Which means mobile phones carry an elevated risk of 4710 compromise of stored key material, and thus would especially benefit 4711 from the self-healing aspects of ZRTP's key continuity features. 4713 The infamous Debian OpenSSL weak key vulnerability [dsa-1571] 4714 (discovered and patched in May 2008) offers a real-world example of 4715 why ZRTP's self-healing scheme is a good way to do key continuity. 4716 The Debian bug resulted in the production of a lot of weak SSH (and 4717 TLS/SSL) keys, which continued to compromise security even after the 4718 bug had been patched. In contrast, ZRTP's key continuity scheme adds 4719 new entropy to the cached key material with every call, so old 4720 deficiencies in entropy are washed away with each new session. 4722 It should be noted that the addition of shared secret entropy from 4723 previous sessions can extend the strength of the new session key to 4724 AES-256 levels, even if the new session uses Diffie-Hellman keys no 4725 larger than DH-3072 or ECDH-256, provided the cached shared secrets 4726 were initially established when the wiretapper was not present. This 4727 is why AES-256 MAY be used with the smaller DH key sizes in 4728 Section 5.1.5, despite the key strength comparisons in Table 2 of 4729 [SP800-57-Part1]. 4731 Caching shared symmetric key material is also less CPU intensive 4732 compared with using digital signatures, which may be important for 4733 low-power mobile platforms. 4735 Unlike the long-lived non-updated key material used by SSH, the 4736 dynamically updated shared secrets of ZRTP may lose sync if 4737 traditional backup/restore mechanisms are used. This is mitigated by 4738 ZRTP's built-in cache backup logic. (Section 4.6.1) 4740 16. Acknowledgments 4742 The authors would like to thank Bryce "Zooko" Wilcox-O'Hearn and 4743 Colin Plumb for their contributions to the design of this protocol, 4744 and to thank Hal Finney, Viktor Krikun, Werner Dittmann, Dan Wing, 4745 Sagar Pai, Lily Chen, David McGrew, Colin Perkins, Dan Harkins, David 4746 Black, Richard Harris, Roni Even, Jon Peterson, and Robert Sparks for 4747 their helpful comments and suggestions. 4749 The use of hash chains to key HMACs in ZRTP is similar to Adrian 4750 Perrig's TESLA protocol [TESLA]. 4752 17. References 4753 17.1. Normative References 4755 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 4756 Hashing for Message Authentication", RFC 2104, 4757 February 1997. 4759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4760 Requirement Levels", BCP 14, RFC 2119, March 1997. 4762 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 4763 Diffie-Hellman groups for Internet Key Exchange (IKE)", 4764 RFC 3526, May 2003. 4766 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4767 Jacobson, "RTP: A Transport Protocol for Real-Time 4768 Applications", STD 64, RFC 3550, July 2003. 4770 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4771 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4772 RFC 3711, March 2004. 4774 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 4775 the Camellia Encryption Algorithm", RFC 3713, April 2004. 4777 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 4778 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 4779 RFC 4231, December 2005. 4781 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4782 Description Protocol", RFC 4566, July 2006. 4784 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 4785 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 4787 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 4788 RFC 4960, September 2007. 4790 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 4791 Groups for Use with IETF Standards", RFC 5114, 4792 January 2008. 4794 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 4795 "Requirements and Analysis of Media Security Management 4796 Protocols", RFC 5479, April 2009. 4798 [I-D.ietf-avt-srtp-big-aes] 4799 McGrew, D., "The use of AES-192 and AES-256 in Secure 4800 RTP", 4801 http://tools.ietf.org/html/draft-ietf-avt-srtp-big-aes . 4803 [I-D.jivsov-openpgp-ecc] 4804 Jivsov, A., "ECC in OpenPGP", 4805 http://tools.ietf.org/html/draft-jivsov-openpgp-ecc . 4807 [FIPS-140-2-Annex-A] 4808 "Annex A: Approved Security Functions for FIPS PUB 140-2", 4809 NIST FIPS PUB 140-2 Annex A October 2008. 4811 [FIPS-140-2-Annex-D] 4812 "Annex D: Approved Key Establishment Techniques for FIPS 4813 PUB 140-2", NIST FIPS PUB 140-2 Annex D January 2008. 4815 [FIPS-180-3] 4816 "Secure Hash Standard (SHS)", NIST FIPS PUB 180-3 October 4817 2008. 4819 [FIPS-186-3] 4820 "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 4821 3 June 2009. 4823 [FIPS-197] 4824 "Advanced Encryption Standard (AES)", NIST FIPS PUB 4825 197 November 2001. 4827 [FIPS-198-1] 4828 "The Keyed-Hash Message Authentication Code (HMAC)", NIST 4829 FIPS PUB 198-1 July 2008. 4831 [SP800-38A] 4832 Dworkin, M., "Recommendation for Block Cipher Modes of 4833 Operation", NIST Special Publication 800-38A 2001 Edition. 4835 [SP800-56A] 4836 Barker, E., Johnson, D., and M. Smid, "Recommendation for 4837 Pair-Wise Key Establishment Schemes Using Discrete 4838 Logarithm Cryptography", NIST Special Publication 800- 4839 56A Revision 1, March 2007. 4841 [SP800-90] 4842 Barker, E. and J. Kelsey, "Recommendation for Random 4843 Number Generation Using Deterministic Random Bit 4844 Generators", NIST Special Publication 800-90 (Revised) 4845 March 2007. 4847 [SP800-108] 4848 Chen, L., "Recommendation for Key Derivation Using 4849 Pseudorandom Functions", NIST Special Publication 800- 4850 108 October 2009. 4852 [NSA-Suite-B] 4853 "NSA Suite B Cryptography", NSA Information Assurance 4854 Directorate NSA Suite B Cryptography. 4856 [NSA-Suite-B-Cert] 4857 "Suite B Base Certificate and CRL Profile", 4858 Suite B Base Certificate and CRL Profile 27 May 2008. 4860 [NSA-Suite-B-Guide-56A] 4861 "Suite B Implementer's Guide to NIST SP 800-56A", Suite B 4862 Implementer's Guide to NIST SP 800-56A 28 July 2009. 4864 [XEP-0262] 4865 Saint-Andre, P., "Use of ZRTP in Jingle RTP Sessions", XSF 4866 XEP 0262, February 2009. 4868 [TwoFish] Schneier, B., Kelsey, J., Whiting, D., Hall, C., and N. 4869 Ferguson, "Twofish: A 128-Bit Block Cipher", 4870 http://www.schneier.com/paper-twofish-paper.html . 4872 [Skein] Ferguson, N., Lucks, S., Schneier, B., Whiting, D., 4873 Bellare, M., Kohno, T., Callas, J., and J. Walker, "The 4874 Skein Hash Function Family, Version 1.2 - 15 Sep 2009", ht 4875 tp://www.skein-hash.info/sites/default/files/ 4876 skein1.2.pdf . 4878 [pgpwordlist] 4879 "PGP Word List", 4880 http://philzimmermann.com/docs/PGP_word_list.pdf . 4882 17.2. Informative References 4884 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4885 A., Peterson, J., Sparks, R., Handley, M., and E. 4886 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4887 June 2002. 4889 [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", 4890 RFC 3514, April 1 2003. 4892 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 4893 E.164 numbers with the Session Initiation Protocol (SIP)", 4894 RFC 3824, June 2004. 4896 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 4898 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 4899 August 2004. 4901 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 4902 Requirements for Security", BCP 106, RFC 4086, June 2005. 4904 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 4905 Protocol Architecture", RFC 4251, January 2006. 4907 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 4908 Authenticated Identity Management in the Session 4909 Initiation Protocol (SIP)", RFC 4474, August 2006. 4911 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 4912 and H. Schulzrinne, "Session Initiation Protocol (SIP) 4913 Torture Test Messages", RFC 4475, May 2006. 4915 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 4916 Carrara, "Key Management Extensions for Session 4917 Description Protocol (SDP) and Real Time Streaming 4918 Protocol (RTSP)", RFC 4567, July 2006. 4920 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 4921 Description Protocol (SDP) Security Descriptions for Media 4922 Streams", RFC 4568, July 2006. 4924 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 4925 (SIP) Call Control - Conferencing for User Agents", 4926 BCP 119, RFC 4579, August 2006. 4928 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 4929 Header Extensions", RFC 5285, July 2008. 4931 [I-D.ietf-mmusic-ice] 4932 Rosenberg, J., "Interactive Connectivity Establishment 4933 (ICE): A Protocol for Network Address Translator (NAT) 4934 Traversal for Offer/Answer Protocols", 4935 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 4937 [I-D.ietf-avt-dtls-srtp] 4938 McGrew, D. and E. Rescorla, "Datagram Transport Layer 4939 Security (DTLS) Extension to Establish Keys for Secure 4940 Real-time Transport Protocol (SRTP)", 4941 draft-ietf-avt-dtls-srtp-07 (work in progress), 4942 February 2009. 4944 [I-D.perkins-avt-srtp-vbr-audio] 4945 Perkins, C. and J. Valin, "Guidelines for the use of 4946 Variable Bit Rate Audio with Secure RTP", http:// 4947 tools.ietf.org/html/draft-perkins-avt-srtp-vbr-audio . 4949 [I-D.wing-sip-identity-media] 4950 Wing, D. and H. Kaplan, "SIP Identity using Media Path", 4951 http://tools.ietf.org/html/draft-wing-sip-identity-media . 4953 [I-D.mcgrew-fundamental-ecc] 4954 McGrew, D., "Fundamental Elliptic Curve Cryptography 4955 Algorithms", 4956 http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc . 4958 [SP800-57-Part1] 4959 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 4960 "Recommendation for Key Management - Part 1: General 4961 (Revised)", NIST Special Publication 800-57 - Part 4962 1 Revised March 2007. 4964 [SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer 4965 Security Resource Center Cryptographic Hash Project. 4967 [Skein1] "The Skein Hash Function Family - Web site", 4968 http://www.skein-hash.info/ . 4970 [Ferguson] 4971 Ferguson, N. and B. Schneier, "Practical Cryptography", 4972 Wiley Publishing 2003. 4974 [Juola1] Juola, P. and P. Zimmermann, "Whole-Word Phonetic 4975 Distances and the PGPfone Alphabet", Proceedings of the 4976 International Conference of Spoken Language Processing 4977 (ICSLP-96) 1996. 4979 [Juola2] Juola, P., "Isolated Word Confusion Metrics and the 4980 PGPfone Alphabet", Proceedings of New Methods in Language 4981 Processing 1996. 4983 [pgpfone] Zimmermann, P., "PGPfone", 4984 http://philzimmermann.com/docs/pgpfone10b7.pdf . 4986 [zfone] Zimmermann, P., "Zfone", 4987 http://www.philzimmermann.com/zfone . 4989 [Byzantine] 4990 "The Two Generals' Problem", 4991 http://en.wikipedia.org/wiki/Two_Generals%27_Problem . 4993 [TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The 4994 TESLA Broadcast Authentication Protocol", http:// 4995 www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ 4996 tesla-cryptobytes.pdf . 4998 [z-base-32] 4999 Wilcox-O'Hearn, B., "Human-oriented base-32 encoding", htt 5000 p://philzimmermann.com/docs/ 5001 human-oriented-base-32-encoding.txt , November 2009. 5003 [comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices 5004 Version 1.2", http://www.comsec.com/vp1-protocol.pdf . 5006 [cryptophone] 5007 "CryptoPhone", http://www.cryptophone.de/ . 5009 [Wright1] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. 5010 Masson, "Spot me if you can: Uncovering spoken phrases in 5011 encrypted VoIP conversations", Proceedings of the 2008 5012 IEEE Symposium on Security and Privacy 2008. 5014 [dsa-1571] 5015 "Debian Security Advisory - OpenSSL predictable random 5016 number generator", 5017 http://www.debian.org/security/2008/dsa-1571 . 5019 Authors' Addresses 5021 Philip Zimmermann 5022 Zfone Project 5023 Santa Cruz, California 5025 Email: prz@mit.edu 5027 Alan Johnston (editor) 5028 Avaya 5029 St. Louis, MO 63124 5031 Email: alan.b.johnston@gmail.com 5033 Jon Callas 5034 Apple, Inc. 5036 Email: jon@callas.org