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