idnits 2.17.1 draft-zimmermann-avt-zrtp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3717. 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 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2008) is 5806 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SHA-256' is mentioned on line 1576, but not defined ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4753 (Obsoleted by RFC 5903) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-sip-media-security-requirements-07 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-02 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Zimmermann 3 Internet-Draft Zfone Project 4 Intended status: Informational A. Johnston, Ed. 5 Expires: December 5, 2008 Avaya 6 J. Callas 7 PGP Corporation 8 June 3, 2008 10 ZRTP: Media Path Key Agreement for Secure RTP 11 draft-zimmermann-avt-zrtp-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 5, 2008. 38 Abstract 40 This document defines ZRTP, a protocol for media path Diffie-Hellman 41 exchange to agree on a session key and parameters for establishing 42 Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP 43 protocol is media path keying because it is multiplexed on the same 44 port as RTP and does not require support in the signaling protocol. 45 ZRTP does not assume a Public Key Infrastructure (PKI) or require the 46 complexity of certificates in end devices. For the media session, 47 ZRTP provides confidentiality, protection against man-in-the-middle 48 (MITM) attacks, and, in cases where a secret is available from the 49 signaling protocol, authentication. ZRTP can utilize a Session 50 Description Protocol (SDP) attribute to provide discovery and 51 authentication through the signaling channel. To provide best effort 52 SRTP, ZRTP utilizes normal RTP/AVP profiles. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Media Security Requirements . . . . . . . . . . . . . . . . . 5 59 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 8 61 4.1.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 8 62 4.1.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 10 63 4.1.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 10 64 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11 65 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.2. Commit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.3. Shared Secret Determination . . . . . . . . . . . . . . . 13 68 5.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 14 69 5.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 15 70 5.3.3. Handling a Shared Secret Cache Mismatch . . . . . . . 15 71 5.4. Secret Generation . . . . . . . . . . . . . . . . . . . . 17 72 5.4.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 17 73 5.4.2. Multistream Mode . . . . . . . . . . . . . . . . . . . 21 74 5.4.3. Preshared Mode . . . . . . . . . . . . . . . . . . . . 22 75 5.5. Key Generation . . . . . . . . . . . . . . . . . . . . . . 25 76 5.6. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 26 77 5.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 27 78 5.7.1. Termination via Error message . . . . . . . . . . . . 27 79 5.7.2. Termination via GoClear message . . . . . . . . . . . 27 80 5.8. Random Number Generation . . . . . . . . . . . . . . . . . 29 81 5.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 29 82 5.9.1. Self-healing Key Continuity Feature . . . . . . . . . 30 83 6. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31 84 6.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 32 85 6.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 33 86 6.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 35 87 6.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 35 88 6.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 35 89 6.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 36 90 6.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 37 91 6.1.7. Signature Type Block . . . . . . . . . . . . . . . . . 38 92 6.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 38 93 6.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 40 94 6.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 40 95 6.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 43 96 6.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 45 97 6.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 47 98 6.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 49 99 6.9. Error message . . . . . . . . . . . . . . . . . . . . . . 50 100 6.10. ErrorACK message . . . . . . . . . . . . . . . . . . . . . 51 101 6.11. GoClear message . . . . . . . . . . . . . . . . . . . . . 52 102 6.12. ClearACK message . . . . . . . . . . . . . . . . . . . . . 52 103 6.13. SASrelay message . . . . . . . . . . . . . . . . . . . . . 53 104 6.14. RelayACK message . . . . . . . . . . . . . . . . . . . . . 55 105 7. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 56 106 8. Short Authentication String . . . . . . . . . . . . . . . . . 57 107 8.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 58 108 8.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 59 109 8.3. Relaying the SAS through a PBX . . . . . . . . . . . . . . 59 110 8.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . . 61 111 9. Signaling Interactions . . . . . . . . . . . . . . . . . . . . 62 112 9.1. Binding the media stream to the signaling layer via 113 the Hello Hash . . . . . . . . . . . . . . . . . . . . . . 63 114 9.1.1. Integrity-protected signaling enables 115 integrity-protected DH exchange . . . . . . . . . . . 65 116 9.2. Deriving the SRTP secret (srtps) from the signaling 117 layer . . . . . . . . . . . . . . . . . . . . . . . . . . 66 118 10. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 67 119 11. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 69 120 12. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . . 70 121 12.1. Guidelines on Proper Implementation of the Disclosure 122 Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 123 13. RTP Header Extension Flag for ZRTP . . . . . . . . . . . . . . 72 124 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 125 15. Security Considerations . . . . . . . . . . . . . . . . . . . 74 126 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 127 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 128 17.1. Normative References . . . . . . . . . . . . . . . . . . . 78 129 17.2. Informative References . . . . . . . . . . . . . . . . . . 79 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 131 Intellectual Property and Copyright Statements . . . . . . . . . . 83 133 1. Introduction 135 ZRTP is a key agreement protocol which performs Diffie-Hellman key 136 exchange during call setup in the media path, and is transported over 137 the same port as the Real-time Transport Protocol (RTP) [RFC3550] 138 media stream which has been established using a signaling protocol 139 such as Session Initiation Protocol (SIP) [RFC3261]. This generates 140 a shared secret which is then used to generate keys and salt for a 141 Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from PGPfone 142 [pgpfone]. A reference implementation of ZRTP is available as Zfone 143 [zfone]. 145 The ZRTP protocol has some nice cryptographic features lacking in 146 many other approaches to media session encryption. Although it uses 147 a public key algorithm, it does not rely on a public key 148 infrastructure (PKI). In fact, it does not use persistent public 149 keys at all. It uses ephemeral Diffie-Hellman (DH) with hash 150 commitment, and allows the detection of man-in-the-middle (MITM) 151 attacks by displaying a short authentication string for the users to 152 read and compare over the phone. It has Perfect Forward Secrecy, 153 meaning the keys are destroyed at the end of the call, which 154 precludes retroactively compromising the call by future disclosures 155 of key material. But even if the users are too lazy to bother with 156 short authentication strings, we still get reasonable authentication 157 against a MITM attack, based on a form of key continuity. It does 158 this by caching some key material to use in the next call, to be 159 mixed in with the next call's DH shared secret, giving it key 160 continuity properties analogous to SSH. All this is done without 161 reliance on a PKI, key certification, trust models, certificate 162 authorities, or key management complexity that bedevils the email 163 encryption world. It also does not rely on SIP signaling for the key 164 management, and in fact does not rely on any servers at all. It 165 performs its key agreements and key management in a purely peer-to- 166 peer manner over the RTP packet stream. 168 If the endpoints have a mechanism for knowing or retrieving the other 169 endpoint's signature key, the short authentication string can be 170 authenticated by exchanging a signature over the short authentication 171 string. 173 ZRTP can be used and discovered without being declared or indicated 174 in the signaling path. This provides a best effort SRTP capability. 175 Also, this reduces the complexity of implementations and minimizes 176 interdependency between the signaling and media layers. However, 177 when ZRTP is indicated in the signaling via the zrtp-hash SDP 178 attribute, ZRTP has additional useful properties. By sending a hash 179 of the ZRTP Hello message in the signaling, ZRTP provides a useful 180 binding between the signaling and media paths, which is explained in 181 Section 9.1. When this is done through a signaling path that has 182 end-to-end integrity protection, the DH exchange is automatically 183 protected from a MiTM attack, which is explained in Section 9.1.1. 185 The next section discusses how ZRTP meets every requirement for media 186 security protocols documented in the IETF. Following sections 187 provide an overview of the ZRTP protocol, describe the key agreement 188 algorithm and RTP message formats. 190 2. Terminology 192 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 193 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 194 and "OPTIONAL" are to be interpreted as described in RFC 2119 and 195 indicate requirement levels for compliant implementations [RFC2119]. 197 3. Media Security Requirements 199 This section discuses how ZRTP meets all RTP security requirements 200 discussed in the SIP Working Group's Media Security Requirements 201 [I-D.ietf-sip-media-security-requirements] document without any 202 dependencies on other protocols or extensions. 204 R-FORK-RETARGET is met since ZRTP is a media path key agreement 205 protocol. 207 R-DISTINCT is met since ZRTP uses ZIDs and allows multiple 208 independent ZRTP exchanges to proceed. 210 R-REUSE is met using the Multistream and Preshared modes. 212 R-AVOID-CLIPPING is met since ZRTP is a media path key agreement 213 protocol 215 R-RTP-VALID is met since the ZRTP packet format does not pass the 216 RTP validity check 218 R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and 219 responses. 221 R-NEGOTIATE is met using the Commit message. 223 R-PSTN is met since ZRTP can be implemented in Gateways. 225 R-PFS is met using ZRTP Diffie-Hellman key agreement methods. 227 R-COMPUTE is met using the Hello/Commit ZRTP exchange. 229 R-CERTS is met using the optional signature field in ZRTP Confirm 230 messages. 232 R-FIPS is met since ZRTP uses algorithms that allow FIPS 233 certification. 235 R-DOS is met since ZRTP does not introduce any new denial of 236 service attacks. 238 R-EXISTING is met since ZRTP can support the use of certificates 239 or keys. 241 R-AGILITY is met since the set of hash, cipher, authentication tag 242 length, key agreement method, SAS type, and signature type can all 243 be extended and negotiated. 245 R-DOWNGRADE is met since ZRTP has protection against downgrade 246 attacks. 248 R-PASS-MEDIA is met since ZRTP prevents a passive adversary with 249 access to the media path from gaining access to keying material 250 used to protect SRTP media packets. 252 R-PASS-SIG is met since ZRTP prevents a passive adversary with 253 access to the signaling path from gaining access to keying 254 material used to protect SRTP media packets. 256 R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs 257 and responses. 259 R-ID-BINDING is met using the a=zrtp-hash SDP attribute. 261 R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs 262 and responses. 264 R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and 265 hence best effort SRTP in every case. 267 R-OTHER-SIGNALING is met since ZRTP can utilize modes in which 268 there is no dependency on the signaling path. 270 R-RECORDING is met using the ZRTP Disclosure flag. 272 R-TRANSCODER is met if the transcoder operates as a trusted MitM 273 (i.e. a PBX). 275 4. Overview 277 This section provides a description of how ZRTP works. This 278 description is non-normative in nature but is included to build 279 understanding of the protocol. 281 ZRTP is negotiated the same way a conventional RTP session is 282 negotiated in an offer/answer exchange using the standard AVP/RTP 283 profile. The ZRTP protocol begins after two endpoints have utilized 284 a signaling protocol such as SIP and are ready to exchange media. If 285 ICE [I-D.ietf-mmusic-ice] is being used, ZRTP begins after ICE has 286 completed its connectivity checks. 288 ZRTP is multiplexed on the same ports as RTP. It uses a unique 289 header that makes it clearly differentiable from RTP or STUN. 291 In environments in which sending ZRTP packets to non-ZRTP endpoints 292 might cause problems and signaling path discovery is not an option, 293 ZRTP endpoints can include the RTP header extension flag for ZRTP in 294 normal RTP packets sent at the start of a session as a probe to 295 discover if the other endpoint supports ZRTP. If the flag is 296 received from the other endpoint, ZRTP messages can then be 297 exchanged. 299 A ZRTP endpoint initiates the exchange by sending a ZRTP Hello 300 message to the other endpoint. The purpose of the Hello message is 301 to confirm the endpoint supports the protocol and to see what 302 algorithms the two ZRTP endpoints have in common. 304 The Hello message contains the SRTP configuration options, and the 305 ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID 306 that is generated once at installation time. ZIDs are discovered 307 during the Hello message exchange. The received ZID is used to look 308 up retained shared secrets from previous ZRTP sessions with the 309 endpoint. 311 A response to a ZRTP Hello message is a ZRTP HelloACK message. The 312 HelloACK message simply acknowledges receipt of the Hello. Since RTP 313 commonly uses best effort UDP transport, ZRTP has retransmission 314 timers in case of lost datagrams. There are two timers, both with 315 exponential backoff mechanisms. One timer is used for 316 retransmissions of Hello messages and the other is used for 317 retransmissions of all other messages after receipt of a HelloACK. 319 If an integrity protected signaling channel is available, a hash of 320 the Hello message can be sent. This allows rejection of false 321 injected ZRTP Hello messages by an attacker. 323 Hello and other ZRTP messages also contain a hash image that is used 324 to link the messages together. This allows rejection of false 325 injected ZRTP messages during an exchange. 327 4.1. Key Agreement Modes 329 After both endpoints exchange Hello and HelloACK messages, the key 330 agreement exchange can begin with the ZRTP Commit message. ZRTP 331 supports a number of key agreement modes including both Diffie- 332 Hellman and non-Diffie-Hellman modes as described in the following 333 sections. 335 The Commit message may be sent immediately after both endpoints have 336 completed the Hello/HelloAck discovery handshake. Or it may be 337 deferred until later in the call, after the participants engage in 338 some unencrypted conversation. The Commit message may be manually 339 activated by a user interface element, such as a GO SECURE button, 340 which becomes enabled after the Hello/HelloAck discovery phase. This 341 emulates the user experience of a number of secure phones in the PSTN 342 world [comsec]. However, it is expected that most simple ZRTP user 343 agents will omit such buttons and proceed directly to secure mode by 344 sending a Commit message immediately after the Hello/HelloAck 345 handshake. 347 In all key agreement modes, the initiator SHOULD NOT send RTP media 348 after sending the Commit message, and MUST NOT send SRTP media before 349 receiving the Conf2Ack. The responder SHOULD NOT send RTP media after 350 receiving the Commit message, and MUST NOT send SRTP media before 351 receiving the Confirm2 message. 353 4.1.1. Diffie-Hellman Mode 355 An example ZRTP call flow is shown in Figure 1 below. Note that the 356 order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be 357 reversed. That is, either Alice or Bob might send the first Hello 358 message. Note that the endpoint which sends the Commit message is 359 considered the initiator of the ZRTP session and drives the key 360 agreement exchange. The Diffie-Hellman public values are exchanged 361 in the DHPart1 and DHPart2 messages. SRTP keys and salts are then 362 calculated. 364 Alice Bob 365 | | 366 | Alice and Bob establish a media session. | 367 | They initiate ZRTP on media ports | 368 | | 369 | F1 Hello (version, options, Alice's ZID) | 370 |-------------------------------------------------->| 371 | HelloACK F2 | 372 |<--------------------------------------------------| 373 | Hello (version, options, Bob's ZID) F3 | 374 |<--------------------------------------------------| 375 | F4 HelloACK | 376 |-------------------------------------------------->| 377 | | 378 | Bob acts as the initiator | 379 | | 380 | Commit (Bob's ZID, options, hvi) F5 | 381 |<--------------------------------------------------| 382 | F6 DHPart1 (pvr, shared secret hashes) | 383 |-------------------------------------------------->| 384 | DHPart2 (pvi, shared secret hashes) F7 | 385 |<--------------------------------------------------| 386 | | 387 | Alice and Bob generate SRTP session key. | 388 | | 389 | F8 Confirm1 (HMAC, D,A,V,E flags, sig) | 390 |-------------------------------------------------->| 391 | Confirm2 (HMAC, D,A,V,E flags, sig) F9 | 392 |<--------------------------------------------------| 393 | F10 Conf2ACK | 394 |-------------------------------------------------->| 395 | SRTP begins | 396 |<=================================================>| 397 | | 399 Figure 1: Establishment of an SRTP session using ZRTP 401 ZRTP authentication uses a Short Authentication String (SAS) which is 402 ideally displayed for the human user. Alternatively, the SAS can be 403 transported over the signaling channel in the SDP and compared 404 automatically, provided the signaling has end-to-end integrity 405 protection. Or, the SAS can be authenticated by exchanging an 406 OPTIONAL digital signature (sig) over the short authentication string 407 in the Confirm1 or Confirm2 messages. 409 The ZRTP Confirm1 and Confirm2 messages are sent for a number of 410 reasons, not the least of which is they confirm that all the key 411 agreement calculations were successful and thus the encryption will 412 work. They also carry other information such as the Disclosure flag 413 (D), the Allow Clear flag (A), the SAS Verified flag (V), and the PBX 414 Enrollment flag (E). All flags are encrypted to shield them from a 415 passive observer. 417 4.1.2. Multistream Mode 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 could use 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, Multistream 434 mode MUST be used. Only one DH operation should be performed, just 435 for the first media stream. The DH exchange must be completed for 436 the first media stream before Multistream mode is used to add any 437 other media streams. 439 4.1.3. Preshared Mode 441 In the Preshared Mode, endpoints can skip the DH calculation if they 442 have a shared secret from a previous ZRTP session. Preshared mode is 443 indicated in the Commit message and results in the same call flow as 444 Multistream mode. The principal difference between Multistream mode 445 and Preshared mode is that Preshared mode uses a previously cached 446 shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess, 447 as the initial keying material. 449 This mode could be useful for slow processor endpoints so that a DH 450 calculation does not need to be performed every session. Or, this 451 mode could be used to rapidly re-establish an earlier session that 452 was recently torn down or interrupted without the need to perform 453 another DH calculation. Since the cache is not affected during this 454 mode, multiple Preshared mode exchanges can be processed at a time 455 between two endpoints. 457 A major drawback to Preshared mode is that it lacks Perfect Forward 458 Secrecy (PFS). For this reason, Preshared mode MUST NOT be used for 459 establishing a second media stream. Multistream mode is designed for 460 that role, without sacrificing PFS. 462 Because of the loss of PFS, Preshared mode should be used sparingly, 463 if used at all. Preshared mode is only included in this 464 specification to meet the R-REUSE requirement in the Media Security 465 Requirements [I-D.ietf-sip-media-security-requirements] document. A 466 series of preshared-keyed calls between two ZRTP endpoints should use 467 a DH key exchange periodically to replace the cached key material, to 468 limit the interval of exposure from no PFS. 470 5. Protocol Description 472 ZRTP MUST be multiplexed on the same ports as the RTP media packets. 474 To support best effort encryption from the Media Security 475 Requirements [I-D.ietf-sip-media-security-requirements], ZRTP uses 476 normal RTP/AVP profile (AVP) media lines in the initial offer/answer 477 exchange. The ZRTP SDP attribute flag a=zrtp-hash defined in 478 Section 9 SHOULD be used in all offers and answers to indicate 479 support for the ZRTP protocol. The Secure RTP/AVP (SAVP) profile MAY 480 be used in subsequent offer/answer exchanges after a successful ZRTP 481 exchange has resulted in an SRTP session, or if it is known the other 482 endpoint supports this profile. 484 The use of the RTP/SAVP profile has caused failures in negotiating 485 best effort SRTP due to the limitations on negotiating profiles 486 using SDP. This is why ZRTP supports the RTP/AVP profile and 487 includes its own discovery mechanisms. 489 5.1. Discovery 491 During the ZRTP discovery phase, a ZRTP endpoint discovers if the 492 other endpoint supports ZRTP and the supported algorithms and 493 options. This information is transported in a Hello message. 495 ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers 496 and answers, as defined in Section 9. ZRTP MAY use an RTP [RFC3550] 497 extension field as a flag to indicate support for the ZRTP protocol 498 in RTP packets as described in Section 13. 500 The Hello message includes the ZRTP version, hash type, cipher type, 501 authentication method and tag length, key agreement type, and Short 502 Authentication String (SAS) algorithms that are supported. The Hello 503 message also includes a hash image as described in Section 10. In 504 addition, each endpoint sends and discovers ZIDs. The received ZID 505 is used later in the protocol as an index into a cache of shared 506 secrets that were previously negotiated and retained between the two 507 parties. 509 A Hello message can be sent at any time, but is usually sent at the 510 start of an RTP session to determine if the other endpoint supports 511 ZRTP, and also if the SRTP implementations are compatible. A Hello 512 message is retransmitted using timer T1 and an exponential backoff 513 mechanism detailed in Section 7 until the receipt of a HelloACK 514 message or a Commit message. 516 The use of the a=zrtp-hash SDP attribute to authenticate the Hello 517 message is described in Section 9.1. 519 5.2. Commit 521 After both parties have received Hello messages, a Commit message can 522 be sent to begin the ZRTP key exchange. The endpoint that sends the 523 Commit is known as the initiator, while the receiver of the Commit is 524 known as the responder. 526 If both sides send Commit messages initiating a secure session at the 527 same time the following rules are used to break the tie. If one 528 Commit is for a DH mode while the other is for a non-DH mode, then 529 the non-DH Commit is discarded and the DH Commit proceeds. If the 530 Commits are either both DH modes or both non-DH modes, then the 531 Commit message with the lowest hvi value is discarded and the other 532 side is the initiator. 534 Because the DH exchange affects the state of the retained shared 535 secret cache, only one in-process ZRTP DH exchange may occur at a 536 time between two ZRTP endpoints. Otherwise, race conditions and 537 cache integrity problems will result. When multiple media streams 538 are established in parallel between the same pair of ZRTP endpoints 539 (determined by the ZIDs in the Hello Messages), only one can be 540 processed. Once that exchange completes with Confirm2 and Conf2ACK 541 messages, another ZRTP DH exchange can begin. This constraint does 542 not apply when Multistream mode key agreement is used since the 543 cached shared secrets are not affected. 545 In the event that Commit messages are sent by both ZRTP endpoints at 546 the same time, but are received in different media streams, the same 547 resolution rules apply as if they were received on the same stream. 548 The media stream in which the Commit will proceed through the ZRTP 549 exchange while the media stream with the discarded Commit must wait 550 for the completion of the other ZRTP exchange. 552 5.3. Shared Secret Determination 554 The following sections describe how ZRTP endpoints generate and/or 555 use the set of shared secrets s1, auxsecret, and pbxsecret through 556 the exchange of the DHPart1 and DHPart2 messages. 558 Each ZRTP endpoint maintains a long-term cache of shared secrets that 559 it has previously negotiated with the other party. The ZID of the 560 other party, received in the other party's Hello message, is used as 561 an index into this cache to find the set of shared secrets, if any 562 exist. This cache entry may contain previously retained shared 563 secrets, rs1 and rs2, which give ZRTP its key continuity features. 564 If the other party is a PBX, the cache may also contain a trusted 565 MiTM PBX shared secret, called pbxsecret, defined in Section 8.3.1. 567 The DHPart1 and DHPart2 messages contain a list of hashes of these 568 shared secrets to allow the two endpoints to compare the hashes with 569 what they have in their caches to detect whether the two sides share 570 any secrets that can be used in the calculation of the session key. 571 The use of this shared secret cache is described in Section 5.9. 573 If no secret of a given type is available, a random value is 574 generated and used for that secret to ensure a mismatch in the hash 575 comparisons in the DHPart1 and DHPart2 messages. This prevents an 576 eavesdropper from knowing which types of shared secrets are available 577 between the endpoints. 579 Section 5.3.1 and Section 5.3.2 both refer to the auxiliary shared 580 secret auxsecret. The auxsecret shared secret may be defined by the 581 VoIP user agent out-of-band from the ZRTP protocol. In some cases it 582 may be provided by the signaling layer as srtps, which is defined in 583 Section 9.2. If it's not provided by the signaling layer, the 584 auxsecret shared secret may be manually provisioned in other 585 application-specific ways that are out-of-band, such as computed from 586 a hashed pass phrase by prior agreement between the two parties. Or 587 it may be a family key used by an institution that the two parties 588 both belong to. It is a generalized mechanism for providing a shared 589 secret that is agreed to between the two parties out of scope of the 590 ZRTP protocol. It is expected that most typical ZRTP endpoints will 591 rarely use auxsecret. 593 For both the initiator and the responder, the shared secrets s1, s2, 594 and s3 will be calculated so that they can all be used later to 595 calculate s0 in Section 5.4.1.4. Here is how s1, s2, and s3 are 596 calculated: 598 The shared secret s1 will be either the initiator's rs1 or the 599 initiator's rs2, depending on which of them can be found in the 600 responder's cache. If the initiator's rs1 matches the responder's 601 rs1 or rs2, then s1 = the initiator's rs1. If and only if that match 602 fails, then if the initiator's rs2 matches the responder's rs1 or 603 rs2, then s1 = the initiator's rs2. If that match also fails, then 604 s1 is set to null. The complexity of the this s1 calculation is to 605 recover from any loss of cache sync from an earlier aborted session, 606 due to the Byzantine Generals' Problem [Byzantine]. 608 The shared secret s2 will be set to the value of auxsecret if and 609 only if both parties have matching values for auxsecret, as 610 determined by comparing the hashes of auxsecret sent in the DH 611 messages. If they don't match, s2 is set to null. 613 The shared secret s3 will be set to the value of pbxsecret if and 614 only if both parties have matching values for pbxsecret, as 615 determined by comparing the hashes of pbxsecret sent in the DH 616 messages. If they don't match, s3 is set to null. 618 If s1, s2, or s3 have null values, they are assumed to have a zero 619 length for the purposes of hashing them later during the s0 620 calculation. 622 The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is 623 described in the next sections. 625 5.3.1. Responder Behavior 627 The responder calculates an HMAC keyed hash using the first retained 628 shared secret, rs1, as the key on the string "Responder" which 629 generates a retained secret ID, rs1IDr, which is truncated to the 630 leftmost 64 bits. HMACs are calculated in a similar way for 631 additional shared secrets: 633 rs1IDr = HMAC(rs1, "Responder") 634 rs2IDr = HMAC(rs2, "Responder") 635 auxsecretIDr = HMAC(auxsecret, "Responder") 636 pbxsecretIDr = HMAC(pbxsecret, "Responder") 638 The set of keyed hashes (HMACs) of shared secrets are included by the 639 responder in the DHPart1 message. 641 The HMACs of the possible shared secrets received in the DHPart2 can 642 be compared against the HMACs of the local set of possible shared 643 secrets. From these comparisons, s1, s2, and s3 are calculated per 644 the methods described above in Section 5.3. The expected HMAC values 645 of the shared secrets are calculated (using the string "Initiator" 646 instead of "Responder") as in Section 5.3.2 and compared to the HMACs 647 received in the DHPart2 message. The secrets corresponding to 648 matching HMACs are kept while the secrets corresponding to the non- 649 matching ones are replaced with a null, which is assumed to have a 650 zero length for the purposes of hashing them later. The resulting 651 s1, s2, and s3 values are used later to calculate s0 in 652 Section 5.4.1.4. 654 5.3.2. Initiator Behavior 656 The initiator calculates an HMAC keyed hash using the first retained 657 shared secret, rs1, as the key on the string "Initiator" which 658 generates a retained secret ID, rs1IDi, which is truncated to the 659 leftmost 64 bits. HMACs are calculated in a similar way for 660 additional shared secrets: 662 rs1IDi = HMAC(rs1, "Initiator") 663 rs2IDi = HMAC(rs2, "Initiator") 664 auxsecretIDi = HMAC(auxsecret, "Initiator") 665 pbxsecretIDi = HMAC(pbxsecret, "Initiator") 667 These HMACs of shared secrets are included by the initiator in the 668 DHPart2 message. 670 The initiator then calculates the set of secret IDs that are expected 671 to be received from the responder in the DHPart1 message by 672 substituting the string "Responder" instead of "Initiator" as in 673 Section 5.3.1. 675 The HMACs of the possible shared secrets received are compared 676 against the HMACs of the local set of possible shared secrets. From 677 these comparisons, s1, s2, and s3 are calculated per the methods 678 described above in Section 5.3. The secrets corresponding to 679 matching HMACs are kept while the secrets corresponding to the non- 680 matching ones are replaced with a null, which is assumed to have a 681 zero length for the purposes of hashing them later. The resulting 682 s1, s2, and s3 values are used later to calculate s0 in 683 Section 5.4.1.4. 685 For example, consider two ZRTP endpoints who share secrets rs1 and 686 pbxsecret (defined in Section 8.3.1). During the comparison, rs1ID 687 and pbxsecretID will match but auxsecretID will not. As a result, s1 688 = rs1, s2 will be null, and s3 = pbxsecret. 690 5.3.3. Handling a Shared Secret Cache Mismatch 692 A shared secret cache mismatch is defined to mean that we expected a 693 cache match because rs1 exists in our local cache, but we computed a 694 null value for s1 (per the method described in Section 5.3). 696 If one party has a cached shared secret and the other party does not, 697 this indicates one of two possible situations. Either there is a 698 man-in-the-middle (MiTM) attack, or one of the legitimate parties has 699 lost their cached shared secret by some mishap. Perhaps they 700 inadvertently deleted their cache, or their cache was lost or 701 disrupted due to restoring their disk from an earlier backup copy. 702 The party that has the surviving cache entry can easily detect that a 703 cache mismatch has occurred, because they expect their own cached 704 secret to match the other party's cached secret, but it does not 705 match. It is possible for both parties to detect this condition if 706 both parties have surviving cached secrets that have fallen out of 707 sync, due perhaps to one party restoring from a disk backup. 709 If either party discovers a cache mismatch, the user agent who makes 710 this discovery must treat this as a possible security event and MUST 711 alert their own user that there is a heightened risk of a MiTM 712 attack, and that the user should verbally compare the SAS with the 713 other party to ascertain that no MiTM attack has occurred. If a 714 cache mismatch is detected and it is not possible to compare the SAS, 715 either because the user interface does not support it or because one 716 or both endpoints are unmanned devices, and no other SAS comparison 717 mechanism is available, the session MAY be terminated. 719 The session need not be terminated on a cache mismatch event if the 720 mechanism described in Section 9.1.1 is available, which allows 721 authentication of the DH exchange without human assistance. Or if 722 any mechanism is available to determine if the SAS matches. This 723 would require either circumstances that allow human verbal 724 comparisons of the SAS, or by using the OPTIONAL digital signature 725 feature on the SAS hash, as described in Section 8.2. Even if the 726 user interface does not permit an SAS compare, the human user MUST be 727 warned, and may elect to proceed with the call at their own risk. 729 Here is a non-normative example of a cache-mismatch alert message 730 from a ZRTP user agent (specifically, Zfone [zfone]), designed for a 731 desktop PC graphical user interface environment. It is by no means 732 required that the alert be this detailed: 734 "We expected the other party to have a shared secret cached from a 735 previous call, but they don't have it. This may mean your partner 736 simply lost his cache of shared secrets, but it could also mean 737 someone is trying to wiretap you. To resolve this question you 738 must check the authentication string with your partner. If it 739 doesn't match, it indicates the presence of a wiretapper." 741 5.4. Secret Generation 743 The next step is the generation of a secret for deriving SRTP keying 744 material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, 745 described in the following sections. 747 5.4.1. Diffie-Hellman Mode 749 The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman 750 or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP 751 endpoints to generate a new shared secret, s0. In addition, the 752 endpoints discover if they have any cached or previously stored 753 shared secrets in common, and uses them as part of the calculation of 754 the session keys. 756 5.4.1.1. Hash Commitment 758 From the intersection of the algorithms in the sent and received 759 Hello messages, the initiator chooses a hash, cipher, auth tag, key 760 agreement type, and SAS type to be used. 762 A Diffie-Hellman mode is selected by setting the Key Agreement Type 763 to one of the DH or ECDH values in Table 5 in the Commit. In this 764 mode, the key agreement begins with the initiator choosing a fresh 765 random Diffie-Hellman (DH) secret value (svi) based on the chosen key 766 agreement type value, and computing the public value. (Note that to 767 speed up processing, this computation can be done in advance.) For 768 guidance on generating random numbers, see Section 5.8. The value 769 for the DH generator g, the DH prime p, and the length of the DH 770 secret value, svi, are defined in Section 6.1.5. 772 pvi = g^svi mod p 774 where g and p are determined by the key agreement type value. The 775 pvi value is formatted as a big-endian octet string, fixed to the 776 width of the DH prime, and leading zeros MUST NOT be truncated. 778 The hash commitment is performed by the initiator of the ZRTP 779 exchange. The hash value of the initiator, hvi, includes a hash of 780 the entire DHPart2 message as shown in Figure 9 (which includes the 781 Diffie-Hellman public value, pvi), and the responder's Hello message: 783 hvi = hash(initiator's DHPart2 message | responder's Hello 784 message) 786 Note that the Hello message includes the fields shown in Figure 3. 788 The information from the responder's Hello message is included in the 789 hash calculation to prevent a bid-down attack by modification of the 790 responder's Hello message. 792 The initiator sends hvi in the Commit message. 794 5.4.1.2. Responder Behavior 796 Upon receipt of the Commit message, the responder generates its own 797 fresh random DH secret value, svr, and computes the public value. 798 (Note that to speed up processing, this computation can be done in 799 advance.) For guidance on random number generation, see Section 5.8. 800 The value for the DH generator g, the DH prime p, and the length of 801 the DH secret value, svr, are defined in Section 6.1.5. 803 pvr = g^svr mod p 805 The pvr value is formatted as a big-endian octet string, fixed to the 806 width of the DH prime, and leading zeros MUST NOT be truncated. 808 Upon receipt of the DHPart2 message, the responder checks that the 809 initiator's public DH value is not equal to 1 or p-1. An attacker 810 might inject a false DHPart2 packet with a value of 1 or p-1 for 811 g^svi mod p, which would cause a disastrously weak final DH result to 812 be computed. If pvi is 1 or p-1, the user should be alerted of the 813 attack and the protocol exchange MUST be terminated. Otherwise, the 814 responder computes its own value for the hash commitment using the 815 public DH value (pvi) received in the DHPart2 packet and its Hello 816 packet and compares the result with the hvi received in the Commit 817 packet. If they are different, a MITM attack is taking place and the 818 user is alerted and the protocol exchange terminated. 820 The responder then calculates the Diffie-Hellman result: 822 DHResult = pvi^svr mod p 824 5.4.1.3. Initiator Behavior 826 Upon receipt of the DHPart1 message, the initiator checks that the 827 responder's public DH value is not equal to 1 or p-1. An attacker 828 might inject a false DHPart1 packet with a value of 1 or p-1 for 829 g^svr mod p, which would cause a disastrously weak final DH result to 830 be computed. If pvr is 1 or p-1, the user should be alerted of the 831 attack and the protocol exchange MUST be terminated. 833 The initiator then sends a DHPart2 message containing the initiator's 834 public DH value and the set of calculated shared secret IDs as 835 defined in Section 5.3.2. 837 The initiator calculates the same Diffie-Hellman result using: 839 DHResult = pvr^svi mod p 841 5.4.1.4. Shared Secret Calculation for DH Mode 843 A hash of the received and sent ZRTP messages in the current ZRTP 844 exchange in the following order is calculated by both parties: 846 total_hash = hash(Hello of responder | Commit | DHPart1 | DHPart2) 848 Note that only the ZRTP messages (Figure 3, Figure 5, Figure 8, and 849 Figure 9), not the entire ZRTP packets, are included in the 850 total_hash. 852 For both the initiator and responder, the DHResult is formatted as a 853 big-endian octet string, fixed to the width of the DH prime, and 854 leading zeros MUST NOT be truncated. For example, for a 3072-bit p, 855 DHResult would be a 384 octet value, with the first octet the most 856 significant. 858 The calculation of the final shared secret, s0, is in compliance with 859 the recommendations in sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A 860 [SP800-56A]. This is done by hashing a concatenation of a number of 861 items, including the DHResult, the ZID's of the initiator (ZIDi) and 862 the responder (ZIDr), the total_hash, and the set of non-null shared 863 secrets as described in 5.2. 865 In section 5.8.1 of NIST SP 800-56A [SP800-56A], NIST requires 866 certain parameters to be hashed together in a particular order, which 867 NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, 868 SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult 869 corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our 870 ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash 871 corresponds to SuppPubInfo, and the set of three shared secrets s1, 872 s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit 873 big-endian integer counter to be included in the hash each time the 874 hash is computed, which we have set to the fixed value of 1, because 875 we only compute the hash once. 877 s0 = hash( counter | DHResult | "ZRTP-HMAC-KDF" | ZIDi | ZIDr | 878 total_hash | len(s1) | s1 | len(s2) | s2 | len(s3) | s3 ) 880 Note that temporary values s1, s2, and s3 were calculated per the 881 methods described above in Section 5.3, and they are erased from 882 memory immediately after they are used to calculate s0. 884 The length of the DHResult field was implicitly agreed to by the 885 negotiated DH prime size. The length of total_hash is implicitly 886 determined by the negotiated hash algorithm. All of the explicit 887 length fields, len(), in the above hash are 32-bit big-endian 888 integers, giving the length in octets of the field that follows. 889 Some members of the set of shared secrets (s1, s2, and s3) may have 890 lengths of zero if they are null (not shared), and are each preceded 891 by a 4-octet length field. For example, if s2 is null, len(s2) is 892 0x00000000, and s2 itself would be absent from the hash calculation, 893 which means len(s3) would immediately follow len(s2). While 894 inclusion of ZIDi and ZIDr may be redundant, because they are 895 implicitly included in the total_hash, we explicitly include them 896 here to follow NIST SP800-56A. The string "ZRTP-HMAC-KDF" (not null- 897 terminated) identifies what purpose the resulting s0 will be used 898 for, which is to serve as the master key for the ZRTP HMAC-based key 899 derivation function defined in Section 5.5. 901 Both parties must now update their retained shared secret rs1 in the 902 cache. But first they discard their old rs2 and copy their old rs1 903 to rs2. Then they compute a new rs1 value from s0 this way: 905 rs1 = HMAC(s0,"retained secret") 907 The old rs1 was saved to rs2 because of the risk of session 908 interruption after one party has updated his own rs1 but before the 909 other party has enough information to update her own rs1. If that 910 happens, they may regain cache sync in the next session by using rs2 911 (per Section 5.3). This mitigates the well-known Byzantine Generals' 912 Problem [Byzantine]. 914 A ZRTP Session Key is generated which then allows the ZRTP 915 Multistream mode to be used to generate SRTP key and salt pairs for 916 additional concurrent media streams between this pair of ZRTP 917 endpoints. If a ZRTP Session Key has already been generated between 918 this pair of endpoints and is available, no new ZRTP Session Key is 919 calculated. 921 ZRTPSess = HMAC(s0,"ZRTP Session Key") 923 The ZRTPSess key is kept for the duration of the call signaling 924 session between the two ZRTP endpoints. That is, if there are two 925 separate calls between the endpoints (in SIP terms, separate SIP 926 dialogs), then a ZRTP Session Key MUST NOT be used across the two 927 call signaling sessions. ZRTPSess MUST be destroyed no later than 928 the end of the call signaling session. 930 5.4.2. Multistream Mode 932 The Multistream key agreement mode can be used to generate SRTP keys 933 and salts for additional media streams established between a pair of 934 endpoints. Multistream mode cannot be used unless there is an active 935 SRTP session established between the endpoints which means a ZRTP 936 Session key is active. This ZRTP Session key can be used to generate 937 keys and salts without performing another DH calculation. In this 938 mode, the retained shared secret cache is not used or updated. As a 939 result, multiple ZRTP Multistream mode exchanges can be processed in 940 parallel between two endpoints. 942 Multistream mode is selected by the initiator setting the Key 943 Agreement Type to "Mult" in the Commit message. The Cipher Type and 944 Auth Tag Length in Multistream mode MUST be set by the initiator to 945 the same as the values as in the initial DH Mode Commit. These 946 values in the Multistream commit packet SHOULD be ignored by the 947 responder, and SHOULD be assumed to be the same as the values in the 948 previous DH commit message. The SAS Type is ignored as there is no 949 SAS authentication in this mode. 951 In place of hvi in the Commit, a random nonce of length 4-words (16 952 octets) is chosen. Its value MUST be unique for all nonce values 953 chosen for active ZRTP sessions between a pair of endpoints. If a 954 Commit is received with a reused nonce value, the ZRTP exchange MUST 955 be immediately terminated. 957 Note: Since the nonce is used to calculate different SRTP key and 958 salt pairs for each media stream, a duplication will result in the 959 same key and salt being generated for the two media streams, which 960 would have disastrous security consequences. 962 If a Commit is received selecting Multistream mode, but the responder 963 does not have a ZRTP Session Key available, the exchange MUST be 964 terminated. Otherwise, the responder proceeds to the next section on 965 Shared Secret Calculation, Section 5.4.2.1 967 In Multistream mode, both the DHPart1 and DHPart2 messages are not 968 sent. After receiving the Commit message from the initiator, the 969 responder sends the Confirm1 message after calculating this stream's 970 SRTP keys, as described below. 972 5.4.2.1. Shared Secret Calculation for Multistream Mode 974 A hash of the received and sent ZRTP messages in the current ZRTP 975 exchange for the current media stream is calculated: 977 total_hash = hash(Hello of responder | Commit ) 979 This refers to the Hello and Commit messages for the current media 980 stream which is using Multistream mode, not the original media stream 981 that included a full DH key agreement. Note that only the ZRTP 982 messages (Figure 3 and Figure 6), not the entire ZRTP packets, are 983 included in the hash. 985 The SRTP keys and salts for the initiator and responder are 986 calculated using the ZRTP Session Key ZRTPSess and the nonce from the 987 Commit message. The nonce from the Commit message is implicitly 988 included in the total_hash, which hashed the entire Commit message 989 and the other party's Hello message. For the nth media stream: 991 s0n = HMAC(ZRTPSess, total_hash) 993 Note that the responder's Hello message, included in the total_hash, 994 includes some unique nonce-derived material of its own (the H3 hash 995 image), thereby ensuring that each of the two parties can 996 unilaterally force the resulting s0n shared secret to be unique for 997 each media stream, even if one party by some error fails to produce a 998 unique nonce. Note also that the ZRTPSess key is derived from 999 material that also includes a different and more inclusive total_hash 1000 from the entire packet sequence that performed the original DH 1001 exchange for the first media stream in this ZRTP session. 1003 At this point in Multistream mode, the two endpoints begin key 1004 generation as described in Section 5.5 using s0n in place of s0 in 1005 the key generation formulas for this media stream. 1007 5.4.3. Preshared Mode 1009 The Preshared key agreement mode can be used to generate SRTP keys 1010 and salts without a DH calculation, instead relying on a shared 1011 secret from previous DH calculations between the endpoints. 1013 This key agreement mode is useful to rapidly re-establish a secure 1014 session between two parties who have recently started and ended a 1015 secure session that has already performed a DH key agreement, without 1016 performing another lengthy DH calculation, which may be desirable on 1017 slow processors in resource-limited environments. Preshared mode 1018 MUST NOT be used for adding additional media streams to an existing 1019 call. Multistream mode MUST be used for this purpose, since it is 1020 designed for that role, without sacrificing PFS. 1022 In the most severe resource-limited environments, Preshared mode may 1023 be useful with processors that cannot perform a DH calculation in an 1024 ergonomically acceptable time limit. Shared key material may be 1025 manually provisioned between two such endpoints in advance and still 1026 allow a limited subset of functionality. Such a "better than 1027 nothing" implementation would have to be regarded as non-compliant 1028 with the ZRTP specification, but it could interoperate in Preshared 1029 (and if applicable, Multistream) mode with a compliant ZRTP endpoint. 1031 5.4.3.1. Commitment in Preshared Mode 1033 Preshared mode is selected by setting the Key Agreement Type to 1034 Preshared in the Commit message. This results in the same call flow 1035 as Multistream mode. The principal difference between Multistream 1036 mode and Preshared mode is that Preshared mode uses a previously 1037 cached shared secret, rs1, instead of an active ZRTP Session key, 1038 ZRTPSess, as the initial keying material. 1040 The Commit message (Figure 7) is sent by the initiator of the ZRTP 1041 exchange. From the intersection of the algorithms in the sent and 1042 received Hello messages, the initiator chooses a hash, cipher, auth 1043 tag, key agreement type, and SAS type to be used. 1045 In place of hvi in the Commit, two smaller fields are inserted by the 1046 initiator: 1048 - A random nonce of length 4-words (16 octets). 1049 - A keyID = HMAC(key, "Prsh") truncated to 64 bits. 1051 The above HMAC key is the cached shared secret rs1, if one is 1052 available or alternatively it could be the trusted MiTM PBX shared 1053 secret pbxsecret, defined in Section 8.3.1. Or it may be manually 1054 provisioned as the auxiliary shared secret auxsecret. If no such 1055 shared key is available in the cache, Preshared mode cannot be used. 1057 The responder uses the received keyID to search for matching key 1058 material in its cache, comparing it with hashes of rs1, rs2, 1059 auxsecret, or pbxsecret. 1061 When it finds the appropriate shared key, it is used to derive s0 and 1062 a new ZRTPSess key, as described in the next section on Shared Secret 1063 Calculation, Section 5.4.3.2. 1065 If the responder determines that it does not have a cached shared 1066 secret from a previous DH exchange, it SHOULD respond with its own DH 1067 Commit message. This would reverse the roles and the responder would 1068 become the initiator, because the DH Commit must always "trump" the 1069 Preshared Commit message as described in Section 5.2. The key 1070 exchange would then proceeds using DH mode. However, if a severely 1071 resource-limited responder lacks the computing resources to respond 1072 in a reasonable time with a DH Commit, it MAY respond with a ZRTP 1073 Error message (Section 6.9) indicating that no shared secret is 1074 available. 1076 Because Preshared mode depends on having a reliable shared secret in 1077 its cache, it is RECOMMENDED that Preshared mode only be used when 1078 the SAS Verified flag has been previously set. 1080 If both sides send Preshared Commit messages initiating a secure 1081 session at the same time, the Commit message with the lowest nonce 1082 value is discarded and the other side is the initiator. This breaks 1083 the tie, allowing the protocol to proceed from this point with a 1084 clear definition of who is the initiator and who is the responder. 1086 5.4.3.2. Shared Secret Calculation for Preshared Mode 1088 A hash of the received and sent ZRTP messages in the current ZRTP 1089 exchange for the current media stream is calculated: 1091 total_hash = hash(Hello of responder | Commit ) 1093 Note that only the ZRTP messages (Figure 3 and Figure 7), not the 1094 entire ZRTP packets, are included in the hash. The nonce from the 1095 Commit message is implicitly included in the total_hash, which hashed 1096 the entire Commit message and the other party's Hello message. 1098 s0 = HMAC(rs1, total_hash) [use whatever keyID matches: rs1, rs2, 1099 auxsecret, or pbxsecret] 1100 ZRTPSess = HMAC(s0,"ZRTP Session Key") 1102 Note that the responder's Hello message, included in the total_hash, 1103 includes some unique nonce-derived material of its own (the H3 hash 1104 image), thereby ensuring that each of the two parties can 1105 unilaterally force the resulting s0 shared secret to be unique for 1106 each media stream, even if one party by some error fails to produce a 1107 unique nonce. 1109 Note: Since the nonce is used to calculate different SRTP key and 1110 salt pairs for each media stream, a duplication will result in the 1111 same key and salt being generated for the two media streams, which 1112 would have disastrous security consequences. 1114 At this point in Preshared mode, the two endpoints begin key 1115 generation as described in Section 5.5, now that there is a defined 1116 s0 and ZRTPSess key. The ZRTPSess key allows the later use of 1117 Multistream mode for adding additional media streams. 1119 5.5. Key Generation 1121 The following calculations derive a set of keys from s0. For the 1122 original media stream that calculated s0 from the DH exchange, s0 1123 means the original s0. For any additional media streams that were 1124 activated in Multistream mode, s0 means s0n, for the n-th media 1125 stream. 1127 Various keys, such as those used by SRTP, must be derived from the 1128 shared secret s0. To do this, ZRTP uses an HMAC-based key derivation 1129 function, keyed by s0, instead of simply drawing subkey material 1130 directly from s0, as defined in NIST SP800-56A. The possibly greater 1131 noninvertability of HMAC may add an extra measure of isolation for 1132 the derived keys. 1134 The SRTP master key and master salt are derived from s0. Separate 1135 SRTP keys and salts are used in each direction for each media stream. 1136 Unless otherwise specified, ZRTP uses SRTP with no MKI, 32 bit 1137 authentication using HMAC-SHA1, AES-CM 128 or 256 bit key length, 112 1138 bit session salt key length, 2^48 key derivation rate, and SRTP 1139 prefix length 0. 1141 The ZRTP initiator encrypts and the ZRTP responder decrypts packets 1142 by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts 1143 and the ZRTP initiator decrypts packets by using srtpkeyr and 1144 srtpsaltr. These are generated by: 1146 srtpkeyi = HMAC(s0,"Initiator SRTP master key") 1147 srtpsalti = HMAC(s0,"Initiator SRTP master salt") 1148 srtpkeyr = HMAC(s0,"Responder SRTP master key") 1149 srtpsaltr = HMAC(s0,"Responder SRTP master salt") 1151 The SRTP key and salt values are truncated (taking the leftmost bits) 1152 to the length determined by the chosen SRTP algorithm. 1154 The HMAC keys are the same length as the output of the underlying 1155 hash function, and are thus generated without truncation by: 1157 hmackeyi = HMAC(s0,"Initiator HMAC key") 1158 hmackeyr = HMAC(s0,"Responder HMAC key") 1160 Note that these HMAC keys are used only by ZRTP and not by SRTP. 1162 Note: Different HMAC keys are needed for the initiator and the 1163 responder to ensure that GoClear messages in each direction are 1164 unique and can not be cached by an attacker and reflected back to the 1165 endpoint. 1167 ZRTP keys are generated for the initiator and responder to use to 1168 encrypt the Confirm1 and Confirm2 messages. They are truncated to 1169 the same size as the negotiated SRTP key size. 1171 zrtpkeyi = HMAC(s0,"Initiator ZRTP key") 1172 zrtpkeyr = HMAC(s0,"Responder ZRTP key") 1174 As soon as s0 has been used to calculate all the subkeys that are 1175 derived from it, it MUST be erased from memory. All other key 1176 material, especially the SRTP keys and salts, and any material 1177 sufficient to derive the SRTP keys and salts, MUST also be erased 1178 from memory when they are no longer used, no later than the end of 1179 the call. That includes ZRTPSess. The only exceptions are the 1180 retained shared secrets, or other cached secrets needed for future 1181 calls. 1183 The Short Authentication String (SAS) value is calculated from the 1184 HMAC of a fixed string, keyed with the ZRTPSess key derived from the 1185 DH key agreement. This means the same SAS is used for all media 1186 streams which are derived from a single DH key agreement in a ZRTP 1187 session. 1189 sashash = HMAC(ZRTPSess,"SAS") 1190 sasvalue = sashash [truncated to leftmost 32 bits] 1192 5.6. Confirmation 1194 The Confirm1 and Confirm2 messages contain the cache expiration 1195 interval (defined in Section 5.9) for the newly generated retained 1196 shared secret. The flagoctet is an 8 bit unsigned integer made up of 1197 these flags: the PBX Enrollment flag (E) defined in Section 8.3, SAS 1198 Verified flag (V) defined in Section 8.1, Allow Clear flag (A) 1199 defined in Section 5.7.2, and Disclosure flag (D) defined in 1200 Section 12. 1202 flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) 1204 Part of the Confirm1 and Confirm2 messages are encrypted using full- 1205 block Cipher Feedback Mode, and contain a 128-bit random CFB 1206 Initialization Vector (IV). The Confirm1 and Confirm2 messages also 1207 contain an HMAC covering the encrypted part of the Confirm1 or 1208 Confirm2 message which includes a string of zeros, the signature 1209 length, flag octet, cache expiration interval, signature type block 1210 (if present) and signature block (if present). For the responder 1212 hmac = HMAC(hmackeyr, encrypted part of Confirm1) 1214 For the initiator: 1216 hmac = HMAC(hmackeyi, encrypted part of Confirm2) 1218 The Conf2ACK message sent by the responder completes the exchange. 1220 5.7. Termination 1222 A ZRTP session is normally terminated at the end of a call, but it 1223 may be terminated early by either the Error message or the GoClear 1224 message. 1226 5.7.1. Termination via Error message 1228 The Error message (Section 6.9) is used to terminate an in-progress 1229 ZRTP exchange due to an error. The Error message contains an integer 1230 Error Code for debugging purposes. The termination of a ZRTP key 1231 agreement exchange results in no updates to the cached shared secrets 1232 and deletion of all crypto context. 1234 The ZRTP Session key, ZRTPSess, is only deleted if the ZRTP session 1235 in which it was generated and all ZRTP sessions which are using it 1236 are terminated. 1238 5.7.2. Termination via GoClear message 1240 The GoClear message (Section 6.11) is used to switch from SRTP to 1241 RTP, usually because the user has chosen to do that by pressing a 1242 button. The GoClear uses an HMAC of the Message Type Block sent in 1243 the GoClear Message computed with the hmackey derived from the shared 1244 secret. This HMAC is truncated to the leftmost 64 bits. When sent 1245 by the initiator: 1247 clear_hmac = HMAC(hmackeyi, "GoClear ") 1249 When sent by the responder: 1251 clear_hmac = HMAC(hmackeyr, "GoClear ") 1253 A GoClear message which does not receive a ClearACK response must be 1254 resent. If a GoClear message is received with a bad HMAC, it must be 1255 ignored, and no ClearACK is sent. 1257 A ZRTP endpoint MAY choose to accept GoClear messages after the 1258 session has switched to SRTP, allowing the session to revert to RTP. 1259 This is indicated in the Confirm1 or Confirm2 messages by setting the 1260 Allow Clear flag (A). If both endpoints set the Allow Clear (A) flag 1261 in their Confirm message, GoClear messages MAY be sent. 1263 A ZRTP endpoint that receives a GoClear authenticates the message by 1264 checking the clear_hmac. If the message authenticates, the endpoint 1265 stops sending SRTP packets, and generates a ClearACK in response. It 1266 MUST also delete all the crypto key material for all the SRTP media 1267 streams, as defined in Section 5.7.2.1. 1269 Until confirmation from the user is received (e.g. clicking a button, 1270 pressing a DTMF key, etc.), the ZRTP endpoint MUST NOT resume sending 1271 RTP packets. The endpoint then renders to the user an indication 1272 that the media session has switched to clear mode, and waits for 1273 confirmation from the user. To prevent pinholes from closing or NAT 1274 bindings from expiring, the ClearACK message MAY be resent at regular 1275 intervals (e.g. every 5 seconds) while waiting for confirmation from 1276 the user. After confirmation of the notification is received from 1277 the user, the sending of RTP packets may begin. 1279 After sending a GoClear message, the ZRTP endpoint stops sending SRTP 1280 packets. When a ClearACK is received, the ZRTP endpoint deletes the 1281 crypto context for the SRTP session, as defined in Section 5.7.2.1, 1282 and may then resume sending RTP packets. 1284 In the event a ClearACK is not received before the retransmissions of 1285 GoClear are exhausted, the key material is deleted, as defined in 1286 Section 5.7.2.1. 1288 After the users have transitioned from SRTP media back to RTP media 1289 (clear mode), they may decide later to return to secure mode by 1290 manual activation, usually by pressing a GO SECURE button. In that 1291 case, a new secure session is initiated by the party that presses the 1292 button, by sending a new Commit packet, leadng to a new session key 1293 negotiation. It is not necessary to send another Hello packet, as 1294 the two parties have already done that at the start of the call and 1295 thus have already discovered each other's ZRTP capabilities. It is 1296 possible for users to toggle back and forth between clear and secure 1297 modes multiple times in the same call, just as they could in the old 1298 days of secure PSTN phones. 1300 5.7.2.1. Key Destruction for GoClear message 1302 All SRTP session key material MUST be erased by the receiver of the 1303 GoClear message upon receiving a properly authenticated GoClear. The 1304 same key destruction MUST be done by the sender of GoClear message, 1305 upon receiving the ClearACK. 1307 In particular, the destroyed key material includes the SRTP session 1308 keys and salts, SRTP master keys and salts, and all material 1309 sufficient to reconstruct the SRTP keys and salts, including ZRTPSess 1310 (s0 should have been destroyed earlier). All key material that would 1311 have been erased at the end of the SIP session MUST be erased. 1313 However, ZRTPSess is destroyed in a manner different from the other 1314 key material. Both parties replace ZRTPSess with a hash of itself, 1315 without truncation: 1317 ZRTPSess = hash(ZRTPSess) 1319 This meets the requirements of Perfect Forward Secrecy, but preserves 1320 a new version of ZRTPSess, so that if the user later re-initiates 1321 secure mode during the same call, the new key negotiation can (and 1322 SHOULD) use a Multistream Commit message, which requires and assumes 1323 the existence of ZRTPSess with the same value at both ZRTP endpoints. 1324 Later, at the end of the entire call, ZRTPSess is finally destroyed 1325 along with the other key material. 1327 5.8. Random Number Generation 1329 The ZRTP protocol uses random numbers for cryptographic key material, 1330 notably for the DH secret exponents and nonces, which must be freshly 1331 generated with each session. Whenever a random number is needed, all 1332 of the following criteria must be satisfied: 1334 It MUST be freshly generated, meaning that it must not have been used 1335 in a previous calculation. 1337 When generating a random number k of L bits in length, k MUST be 1338 chosen with equal probability from the range of [1 < k < 2^L]. 1340 It MUST be derived from a physical entropy source, such as RF noise, 1341 acoustic noise, thermal noise, high resolution timings of 1342 environmental events, or other unpredictable physical sources of 1343 entropy. For a detailed explanation of cryptographic grade random 1344 numbers and guidance for collecting suitable entropy, see RFC 4086 1345 [RFC4086] and Chapter 10 of Practical Cryptography [Ferguson]. The 1346 raw entropy must be distilled and processed through a deterministic 1347 random bit generator (DRBG). Examples of DRBGs may be found in NIST 1348 SP 800-90 [SP800-90], and in [Ferguson]. Failure to use true entropy 1349 from the physical environment as a basis for generating random 1350 cryptographic key material would lead to a disastrous loss of 1351 security. 1353 5.9. ZID and Cache Operation 1355 Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that 1356 is generated once at installation time. It is used to look up 1357 retained shared secrets in a local cache. A single global ZID for a 1358 single installation is the simplest way to implement ZIDs. However, 1359 it is specifically not precluded for an implementation to use 1360 multiple ZIDs, up to the limit of a separate one per callee. This 1361 then turns it into a long-lived "association ID" that does not apply 1362 to any other associations between a different pair of parties. It is 1363 a goal of this protocol to permit both options to interoperate 1364 freely. 1366 Each time a new s0 is calculated, a new retained shared secret rs1 is 1367 generated and stored in the cache, indexed by the ZID of the other 1368 endpoint. But first the previous rs1 is copied to rs2 and also 1369 stored in the cache. For the new retained shared secret, each 1370 endpoint chooses a cache expiration value which is an unsigned 32 bit 1371 integer of the number of seconds that this secret should be retained 1372 in the cache. The time interval is relative to when the Confirm1 1373 message is sent or received. 1375 The cache intervals are exchanged in the Confirm1 and Confirm2 1376 messages. The actual cache interval used by both endpoints is the 1377 minimum of the values from the Confirm1 and Confirm2 messages. A 1378 value of 0 seconds means the newly-computed shared secret SHOULD NOT 1379 be stored in the cache, and if a cache entry already exists from an 1380 earlier call, the stored cache interval should be set to 0. A value 1381 of 0xffffffff means the secret should be cached indefinitely and is 1382 the recommended value. If the ZRTP exchange results in no new shared 1383 secret generation (i.e. Multistream or Preshared Modes), the field 1384 in the Confirm1 and Confirm2 is set to 0xffffffff and ignored, and 1385 the cache is not updated. 1387 The expiration interval need not be used to force the deletion of a 1388 shared secret from the cache when the interval has expired. It just 1389 means the shared secret MAY be deleted from that cache at any point 1390 after the interval has expired without causing the other party to 1391 note it as an unexpected security event when the next key negotiation 1392 occurs between the same two parties. This means there need not be 1393 perfectly synchronized deletion of expired secrets from the two 1394 caches, and makes it easy to avoid a race condition that might 1395 otherwise be caused by clock skew. 1397 5.9.1. Self-healing Key Continuity Feature 1399 The key continuity features of ZRTP are analogous to those provided 1400 by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH 1401 caches public signature keys that do not change, and uses a private 1402 signature key that also never changes and must be forever guarded 1403 from disclosure. ZRTP caches symmetric key material used to compute 1404 secret session keys, and these values change with each session. If 1405 someone steals your SSH private signature key, they can impersonate 1406 you in all future sessions and mount a successful MiTM attack any 1407 time they want. But if someone steals your ZRTP shared secret cache, 1408 they only get one chance to mount a MiTM attack, in the very next 1409 session. If they miss that chance, the retained shared secret is 1410 refreshed with a new value, and the window of vulnerability heals 1411 itself, which means they are locked out of any future opportunities 1412 to mount a MiTM attack. This gives ZRTP a "self-healing" feature if 1413 any key material is compromised. ZRTP operates entirely in the media 1414 path, so a MiTM attacker must always be in the media path. This 1415 presents operational difficulties for the attacker in many VoIP usage 1416 scenarios, because being in the media path is often harder than being 1417 in the signaling path. This means the attacker may often miss MiTM 1418 attack opportunities. ZRTP's self-healing key continuity features 1419 are better than SSH at exploiting the MiTM attacker's missed 1420 opportunities. Thus, ZRTP quickly recovers from any disclosure of 1421 cached key material. 1423 6. ZRTP Messages 1425 All ZRTP messages use the message format defined in Figure 2. All 1426 word lengths referenced in this specification are 32 bits or 4 1427 octets. All integer fields are carried in network byte order, that 1428 is, most significant byte (octet) first, commonly known as big- 1429 endian. 1431 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 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 |0 0 0 1|Not Used (set to zero) | Sequence Number | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | ZRTP Magic Cookie (0x5a525450) | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Source Identifier | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | | 1440 | ZRTP Message (length depends on Message Type) | 1441 | . . . | 1442 | | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | CRC (1 word) | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 ZRTP Packet Format 1449 Figure 2: ZRTP Packet Format 1451 The Sequence Number is a count that is incremented for each ZRTP 1452 packet sent. The count is initialized to a random value. This is 1453 useful in estimating ZRTP packet loss and also detecting when ZRTP 1454 packets arrive out of sequence. 1456 The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a 1457 ZRTP packet, and has the value 0x5a525450. 1459 Source Identifier is the SSRC number of the RTP stream that this ZRTP 1460 packet relates to. For cases of forking or forwarding, RTP and hence 1461 ZRTP may arrive at the same port from several different sources - 1462 each of these sources will have a different SSRC and may initiate an 1463 independent ZRTP protocol session. 1465 This format is clearly identifiable as non-RTP due to the first two 1466 bits being zero which looks like RTP version 0, which is not a valid 1467 RTP version number. It is clearly distinguishable from STUN since 1468 the magic cookies are different. The 12 not used bits are set to 1469 zero and MUST be ignored when received. 1471 The ZRTP Messages are defined in Figure 3 to Figure 17 and are of 1472 variable length. 1474 The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as 1475 defined in RFC 3309 [RFC3309] to detect transmission errors. ZRTP 1476 packets are typically transported by UDP, which carries its own 1477 built-in 16-bit checksum for integrity, but ZRTP does not rely on it. 1478 This is because of the effect of an undetected transmission error in 1479 a ZRTP message. For example, an undetected error in the DH exchange 1480 could appear to be an active man-in-the-middle attack. The 1481 psychological effects of a false announcement of this by ZTRP clients 1482 can not be overstated. The probability of such a false alarm hinges 1483 on a mere 16-bit checksum that usually protects UDP packets, so more 1484 error detection is needed. For these reasons, this belt-and- 1485 suspenders approach is used to minimize the chance of a transmission 1486 error affecting the ZRTP key agreement. 1488 The CRC is calculated across the entire ZRTP packet shown in 1489 Figure 2, including the ZRTP Header and the ZRTP Message, but not 1490 including the CRC field. If a ZRTP message fails the CRC check, it 1491 is silently discarded. 1493 6.1. ZRTP Message Formats 1495 ZRTP messages are designed to simplify endpoint parsing requirements 1496 and to reduce the opportunities for buffer overflow attacks (a good 1497 goal of any security extension should be to not introduce new attack 1498 vectors). 1500 ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets 1501 (1 word) blocks are used to encode Hash Type, Cipher Type, and Key 1502 Agreement Type, and Authentication Tag. The values in the blocks are 1503 ASCII strings which are extended with spaces (0x20) to make them the 1504 desired length. Currently defined block values are listed in Tables 1505 1-6 below. 1507 Additional block values may be defined and used. 1509 ZRTP uses this ASCII encoding to simplify debugging and make it 1510 "Wireshark (Ethereal) friendly". 1512 6.1.1. Message Type Block 1514 Currently 14 Message Type Blocks are defined - they represent the set 1515 of ZRTP message primitives. ZRTP endpoints MUST support the Hello, 1516 HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, 1517 SASrelay, RelayACK, Error and ErrorACK block types. ZRTP endpoints 1518 MAY support the GoClear and ClearACK messages. Additional messages 1519 may be defined in extensions to ZRTP. 1521 Message Type Block | Meaning 1522 --------------------------------------------------- 1523 "Hello " | Hello Message 1524 | defined in Section 6.2 1525 --------------------------------------------------- 1526 "HelloACK" | HelloACK Message 1527 | defined in Section 6.3 1528 --------------------------------------------------- 1529 "Commit " | Commit Message 1530 | defined in Section 6.4 1531 --------------------------------------------------- 1532 "DHPart1 " | DHPart1 Message 1533 | defined in Section 6.5 1534 --------------------------------------------------- 1535 "DHPart2 " | DHPart2 Message 1536 | defined in Section 6.6 1537 --------------------------------------------------- 1538 "Confirm1" | Confirm1 Message 1539 | defined in Section 6.7 1540 --------------------------------------------------- 1541 "Confirm2" | Confirm2 Message 1542 | defined in Section 6.7 1543 --------------------------------------------------- 1544 "Conf2ACK" | Conf2ACK Message 1545 | defined in Section 6.8 1546 --------------------------------------------------- 1547 "Error " | Error Message 1548 | defined in Section 6.9 1549 --------------------------------------------------- 1550 "ErrorACK" | ErrorACK Message 1551 | defined in Section 6.10 1552 --------------------------------------------------- 1553 "GoClear " | GoClear Message 1554 | defined in Section 6.11 1555 --------------------------------------------------- 1556 "ClearACK" | ClearACK Message 1557 | defined in Section 6.12 1558 --------------------------------------------------- 1559 "SASrelay" | SASrelay Message 1560 | defined in Section 6.13 1561 --------------------------------------------------- 1562 "RelayACK" | RelayACK Message 1563 | defined in Section 6.14 1564 --------------------------------------------------- 1566 Table 1. Message Block Type Values 1568 6.1.2. Hash Type Block 1570 Only one Hash Type is currently defined, SHA256, and all ZRTP 1571 endpoints MUST support this hash. Additional Hash Types can be 1572 registered and used. 1574 Hash Type Block | Meaning 1575 --------------------------------------------------- 1576 "S256" | SHA-256 Hash defined in [SHA-256] 1577 --------------------------------------------------- 1579 Table 2. Hash Block Type Values 1581 6.1.3. Cipher Type Block 1583 All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES- 1584 256 (AES3). or other Cipher Types. The choice of the AES key length 1585 is coupled to the Key Agreement type, as explained in Section 6.1.5. 1587 The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES- 1588 256 in SRTP is defined by [I-D.ietf-avt-srtp-big-aes]. 1590 Cipher Type Block | Meaning 1591 --------------------------------------------------- 1592 "AES1" | AES-CM with 128 bit keys 1593 | as defined in RFC 3711 1594 --------------------------------------------------- 1595 "AES3" | AES-CM with 256 bit keys 1596 | 1597 --------------------------------------------------- 1599 Table 3. Cipher Block Type Values 1601 6.1.4. Auth Tag Block 1603 All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and 1604 80 bit length tags as defined in [RFC3711]. 1606 Auth Tag Block | Meaning 1607 --------------------------------------------------- 1608 "HS32" | HMAC-SHA1 32 bit authentication 1609 | tag as defined in RFC 3711 1610 --------------------------------------------------- 1611 "HS80" | HMAC-SHA1 80 bit authentication 1612 | tag as defined in RFC 3711 1613 --------------------------------------------------- 1615 Table 4. Auth Tag Values 1617 6.1.5. Key Agreement Type Block 1619 All ZRTP endpoints MUST support DH3k and Multistream, SHOULD support 1620 Preshared, and MAY support EC25, EC38, and EC52. 1622 For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH 1623 parameters defined in RFC 3526 [RFC3526], as follows. DH3k uses the 1624 3072-bit MODP group. The DH generator g is 2. The random Diffie- 1625 Hellman secret exponent SHOULD be twice as long as the AES key 1626 length. If AES-128 is used, the DH secret value SHOULD be 256 bits 1627 long. If AES-256 is used, the secret value SHOULD be 512 bits long. 1629 If Elliptic Curve DH is used, the ECDH algorithm and key generation 1630 is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA 1631 Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by 1632 FIPS 186-3 [FIPS-186-3], and can also be found in RFC 4753 [RFC4753], 1633 sections 3.1 through 3.3. The validation procedures are from NIST SP 1634 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC Partial 1635 Validation. Both the X and Y coordinates of the point on the curve 1636 are sent, in the first and second half of the ECDH public value, 1637 respectively. 1639 The choice of AES key length is coupled to the choice of key 1640 agreement type. If AES-128 is chosen, DH3k SHOULD be used, or EC25 1641 if supported. If AES-256 is chosen, either EC38 or EC52 SHOULD be 1642 used. 1644 ZRTP also defines two non-DH modes, Multistream and Preshared, in 1645 which the SRTP key is derived from a shared secret and some nonce 1646 material. 1648 Table 5 lists the pv length in words and DHPart1 and DHPart2 message 1649 length in words for each Key Agreement Type Block. 1651 Key Agreement | pv | message | Meaning 1652 Type Block | words | words | 1653 --------------------------------------------------- 1654 "DH3k" | 96 | 117 | DH mode with p=3072 bit prime 1655 | | | as defined in RFC 3526 1656 --------------------------------------------------- 1657 "Prsh" | - | - | Preshared Non-DH mode 1658 | | | 1659 --------------------------------------------------- 1660 "Mult" | - | - | Multistream Non-DH mode 1661 | | | 1662 --------------------------------------------------- 1663 "EC25" | 16 | 37 | Elliptic Curve DH, P-256 1664 | | | per RFC 4753, section 3.1 1665 --------------------------------------------------- 1666 "EC38" | 24 | 45 | Elliptic Curve DH, P-384 1667 | | | per RFC 4753, section 3.2 1668 --------------------------------------------------- 1669 "EC52" | 33 | 54 | Elliptic Curve DH, P-521 1670 | | | per RFC 4753, section 3.3 1671 --------------------------------------------------- 1673 Table 5. Key Agreement Block Type Values 1675 6.1.6. SAS Type Block 1677 All ZRTP endpoints MUST support the base32 and MAY support base256 1678 Short Authentication String scheme, and other SAS rendering schemes. 1679 The ZRTP SAS is described in Section 8. 1681 SAS Type Block | Meaning 1682 --------------------------------------------------- 1683 "B32 " | Short Authentication String using 1684 | base32 encoding defined in Section 8. 1685 --------------------------------------------------- 1686 "B256" | Short Authentication String using 1687 | base256 encoding defined in Section 8. 1688 --------------------------------------------------- 1690 Table 6. SAS Block Type Values 1692 The SAS Type determines how the SAS is rendered to the user so that 1693 the user may compare it with his partner over the voice channel. 1694 This allows detection of a man-in-the-middle (MITM) attack. 1696 6.1.7. Signature Type Block 1698 The signature type block is a 4 octet (1 word) block used to 1699 represent the signature algorithm. Suggested signature algorithms 1700 and key lengths are a future subject of standardization. 1702 6.2. Hello message 1704 The Hello message has the format shown in Figure 3. The Hello ZRTP 1705 message begins with the preamble value 0x505a then a 16 bit length in 1706 32 bit words. This length includes only the ZRTP message (including 1707 the preamble and the length) but not the ZRTP header or CRC. 1709 Next is the Message Type Block and a 4 character string containing 1710 the version (ver) of the ZRTP protocol, currently "0.85" (when this 1711 specification reaches RFC status, the protocol version will become 1712 "1.00"). Next is the Client Identifier string (cid) which is 4 words 1713 long and identifies the vendor and release of the ZRTP software. The 1714 256-bit hash image H3 is defined in Section 10. The next parameter 1715 is the ZID, the 96 bit long unique identifier for the ZRTP endpoint. 1717 The next four bits contains flag bits. The Passive flag (P) is a 1718 Boolean normally set to False. A ZRTP endpoint which is configured 1719 to never initiate secure sessions is regarded as passive, and would 1720 set the P bit to True. The next 8 bits are unused. They should be 1721 set to zero when sent and ignored on receipt. 1723 Next is a list of supported Hash algorthms, Cipher algorithms, SRTP 1724 Auth Tag types, Key Agreement types, and SAS types. The number of 1725 listed algorithms are listed for each type: hc=hash count, cc=cipher 1726 count, ac=auth tag count, kc=key agreement count, and sc=sas count. 1727 The values for these algorithms are defined in Tables 2, 3, 4, 5, and 1728 6. A count of zero means that only the mandatory to implement 1729 algorithms are supported. Mandatory algorithms MAY be included in 1730 the list. The order of the list indicates the preferences of the 1731 endpoint. If a mandatory algorithm is not included in the list, it 1732 is added to the end of the list for preference. 1734 Note: Implementers are encouraged to keep these algorithm lists small 1735 - the list does not need to include every cipher and hash supported, 1736 just the ones the endpoint would prefer to use for this ZRTP 1737 exchange. 1739 The 64-bit HMAC at the end of the message is computed across the 1740 whole message, not including the HMAC, of course. The HMAC key is 1741 the sender's H2 (defined in Section 10), and thus cannot be checked 1742 by the receiving party until the sender's H2 value is known to the 1743 receiving party later in the protocol. 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Message Type Block="Hello " (2 words) | 1751 | | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | version="0.85" (1 word) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | | 1756 | Client Identifier (4 words) | 1757 | | 1758 | | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | | 1761 | Hash image H3 (8 words) | 1762 | . . . | 1763 | | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | | 1766 | ZID (3 words) | 1767 | | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 |0|0|0|P| unused (zeros)| hc | cc | ac | kc | sc | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | hash algorthms (0 to 7 values) | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | cipher algorthms (0 to 7 values) | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | auth tag types (0 to 7 values) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | key agreement types (0 to 7 values) | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | SAS types (0 to 7 values) | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | HMAC (2 words) | 1782 | | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 Hello message format 1787 Figure 3: Hello message format 1789 6.3. HelloACK message 1791 The HelloACK message is used to stop retransmissions of a Hello 1792 message. A HelloACK is sent regardless if the version number in the 1793 Hello is supported or the algorithm list supported. The receipt of a 1794 HelloACK stops retransmission of the Hello message. The format is 1795 shown in the Figure below. Note that a Commit message can be sent in 1796 place of a HelloACK by an Initiator. 1798 0 1 2 3 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Message Type Block="HelloACK" (2 words) | 1804 | | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 HelloACK message format 1809 Figure 4: HelloACK message format 1811 6.4. Commit message 1813 The Commit message is sent to initiate the key agreement process 1814 after both sides have received a Hello message, which means it can 1815 only be sent after receiving both a Hello message and a HelloACK 1816 message. The Commit message contains the Initiator's ZID and a list 1817 of selected algorithms (hash, cipher, auth tag type, key agreement, 1818 sas type), and hvi, which is a hash of the DHPart2 of the Initiator 1819 and the Responder's Hello message, as explained in Section 5.4.1.1. 1820 The hash image H2 is defined in Section 10. The Commit Message 1821 formats are shown in Figure 5, Figure 6, and Figure 7. 1823 The 64-bit HMAC at the end of the message is computed across the 1824 whole message, not including the HMAC, of course. The HMAC key is 1825 the sender's H1 (defined in Section 10), and thus cannot be checked 1826 by the receiving party until the sender's H1 value is known to the 1827 receiving party later in the protocol. 1829 0 1 2 3 1830 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 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Message Type Block="Commit " (2 words) | 1835 | | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | | 1838 | Hash image H2 (8 words) | 1839 | . . . | 1840 | | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | | 1843 | ZID (3 words) | 1844 | | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | hash algorihm | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | cipher algorihm | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | auth tag type | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | key agreement type | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | SAS type | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | | 1857 | hvi (8 words) | 1858 | . . . | 1859 | | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | HMAC (2 words) | 1862 | | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 DH Commit message format 1867 Figure 5: DH Commit message format 1869 0 1 2 3 1870 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 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | Message Type Block="Commit " (2 words) | 1875 | | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | | 1878 | Hash image H2 (8 words) | 1879 | . . . | 1880 | | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | | 1883 | ZID (3 words) | 1884 | | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | hash algorihm | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | cipher algorihm | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | auth tag type | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | key agreement type = "Mult" | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | SAS type | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | | 1897 | nonce (4 words) | 1898 | . . . | 1899 | | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | HMAC (2 words) | 1902 | | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 Multistream Commit message format 1907 Figure 6: Multistream Commit message format 1909 0 1 2 3 1910 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 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 | Message Type Block="Commit " (2 words) | 1915 | | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | | 1918 | Hash image H2 (8 words) | 1919 | . . . | 1920 | | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | | 1923 | ZID (3 words) | 1924 | | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | hash algorihm | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | cipher algorihm | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | auth tag type | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | key agreement type = "Prsh" | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | SAS type | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | | 1937 | nonce (4 words) | 1938 | . . . | 1939 | | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | keyID (2 words) | 1942 | | 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | HMAC (2 words) | 1945 | | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 Preshared Commit message format 1950 Figure 7: Preshared Commit message format 1952 6.5. DHPart1 message 1954 The DHPart1 message begins the DH exchange. The format is shown in 1955 Figure 8 below. The DHPart1 message is sent by the Responder if a 1956 valid Commit message is received from the Initiator. The length of 1957 the pvr value and the length of the DHPart1 message depends on the 1958 Key Agreement Type chosen. This information is contained in Table 5. 1959 Note that for both Multistream and Preshared modes, no DHPart1 or 1960 DHPart2 message will be sent. 1962 The 256-bit hash image H1 is defined in Section 10. 1964 The next four parameters are HMACs of potential shared secrets used 1965 in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are 1966 the HMACs of the responder's two retained shared secrets, truncated 1967 to 64 bits. Next is auxsecretIDr, the HMAC of the responder's 1968 auxsecret (defined in Section 5.3), truncated to 64 bits. The last 1969 parameter is the HMAC of the trusted MiTM PBX shared secret 1970 pbxsecret, defined in Section 8.3.1. The Message format for the 1971 DHPart1 message is shown in Figure 8. 1973 The 64-bit HMAC at the end of the message is computed across the 1974 whole message, not including the HMAC, of course. The HMAC key is 1975 the sender's H0 (defined in Section 10), and thus cannot be checked 1976 by the receiving party until the sender's H0 value is known to the 1977 receiving party later in the protocol. 1979 0 1 2 3 1980 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 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | Message Type Block="DHPart1 " (2 words) | 1985 | | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | | 1988 | Hash image H1 (8 words) | 1989 | . . . | 1990 | | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | rs1IDr (2 words) | 1993 | | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | rs2IDr (2 words) | 1996 | | 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | auxsecretIDr (2 words) | 1999 | | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | pbxsecretIDr (2 words) | 2002 | | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | | 2005 | pvr (length depends on KA Type) | 2006 | . . . | 2007 | | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | HMAC (2 words) | 2010 | | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 DHPart1 message format 2015 Figure 8: DH Part1 message format 2017 6.6. DHPart2 message 2019 The DHPart2 message completes the DH exchange. A DHPart2 message is 2020 sent by the Initiator if a valid DHPart1 message is received from the 2021 Responder. The length of the pvr value and the length of the DHPart2 2022 message depends on the Key Agreement Type chosen. This information 2023 is contained in Table 5. Note that for both Multistream and 2024 Preshared modes, no DHPart1 or DHPart2 message will be sent. 2026 The 256-bit hash image H1 is defined in Section 10. 2028 The next four parameters are HMACs of potential shared secrets used 2029 in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are 2030 the HMACs of the initiator's two retained shared secrets, truncated 2031 to 64 bits. Next is auxsecretIDi, the HMAC of the initiator's 2032 auxsecret (defined in Section 5.3), truncated to 64 bits. The last 2033 parameter is the HMAC of the trusted MiTM PBX shared secret 2034 pbxsecret, defined in Section 8.3.1. The message format for the 2035 DHPart2 message is shown in Figure 9. 2037 The 64-bit HMAC at the end of the message is computed across the 2038 whole message, not including the HMAC, of course. The HMAC key is 2039 the sender's H0 (defined in Section 10), and thus cannot be checked 2040 by the receiving party until the sender's H0 value is known to the 2041 receiving party later in the protocol. 2043 0 1 2 3 2044 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 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Message Type Block="DHPart2 " (2 words) | 2049 | | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | | 2052 | Hash image H1 (8 words) | 2053 | . . . | 2054 | | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | rs1IDi (2 words) | 2057 | | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | rs2IDi (2 words) | 2060 | | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | auxsecretIDi (2 words) | 2063 | | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | pbxsecretIDi (2 words) | 2066 | | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | | 2069 | pvi (length depends on KA Type) | 2070 | . . . | 2071 | | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | HMAC (2 words) | 2074 | | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 DHPart2 message format 2079 Figure 9: DH Part2 message format 2081 6.7. Confirm1 and Confirm2 messages 2083 The Confirm1 message is sent by the Responder in response to a valid 2084 DHPart2 message after the SRTP session key and parameters have been 2085 negotiated. The Confirm2 message is sent by the Initiator in 2086 response to a Confirm1 message. The format is shown in Figure 10 2087 below. The message contains the Message Type Block "Confirm1" or 2088 "Confirm2". Next is the HMAC, a keyed hash over encrypted part of 2089 the message (shown enclosed by "===" in Figure 10.) The next 16 2090 octets contain the CFB Initialization Vector. The rest of the 2091 message is encrypted using CFB and protected by the HMAC. 2093 The first field inside the encrypted region is the hash pre-image H0, 2094 which is defined in detail in Section 10. 2096 The next 16 bits are not used. They SHOULD be set to zero and MUST 2097 be ignored in received Confirm1 or Confirm2 messages. 2099 The next 8 bits contain the signature length. If no SAS signature 2100 (described in Section 8.2) is present, all bits are set to zero. The 2101 signature length is in words and includes the signature type block. 2102 If the calculated signature octet count is not a multiple of 4, zeros 2103 are added to pad it out to a word boundary. If no signature block is 2104 present, the overall length of the Confirm1 or Confirm2 Message will 2105 be set to 19 words. 2107 The next 8 bits are used for flags. Undefined flags are set to zero 2108 and ignored. Four flags are currently defined. The PBX Enrollment 2109 flag (E) is a Boolean bit defined in Section 8.3. The SAS Verified 2110 flag (V) is a Boolean bit defined in Section 8.1. The Allow Clear 2111 flag (A) is a Boolean bit defined in Section 5.7.2. The Disclosure 2112 Flag (D) is a Boolean bit defined in Section 12. The cache 2113 expiration interval is defined in Section 5.9. 2115 If the signature length (in words) is non-zero, a signature type 2116 block will be present along with a signature block. Next is the 2117 signature block. The signature block includes the key used to 2118 generate the signature. 2120 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2121 full cipher block, and the final block is truncated to match the 2122 exact length of the encrypted data. The CFB Initialization Vector is 2123 a 128 bit random nonce. The block cipher algorithm and the key size 2124 is the same as what was negotiated for the media encryption. CFB is 2125 used to encrypt the part of the Confirm1 message beginning after the 2126 CFB IV to the end of the message (the encrypted region is enclosed by 2127 "======" in Figure 10). 2129 The responder uses the zrtpkeyr to encrypt the Confirm1 message. The 2130 initiator uses the zrtpkeyi to encrypt the Confirm2 message. 2132 0 1 2 3 2133 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 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Message Type Block="Confirm1" or "Confirm2" (2 words) | 2138 | | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | HMAC (2 words) | 2141 | | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | | 2144 | CFB Initialization Vector (4 words) | 2145 | | 2146 | | 2147 +===============================================================+ 2148 | | 2149 | Hash pre-image H0 (8 words) | 2150 | . . . | 2151 | | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 | Unused (Set to zero, ignored) | sig length |0 0 0 0|E|V|A|D| 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | cache expiration interval (1 word) | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | optional signature type block (1 word if present) | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 | | 2160 | optional signature block (variable length) | 2161 | . . . | 2162 | | 2163 | | 2164 +===============================================================+ 2166 Confirm1 and Confirm2 message format 2168 Figure 10: Confirm1 and Confirm2 message format 2170 6.8. Conf2ACK message 2172 The Conf2ACK message is sent by the Responder in response to a valid 2173 Confirm2 message. The message format for the Conf2ACK is shown in 2174 the Figure below. The receipt of a Conf2ACK stops retransmission of 2175 the Confirm2 message. 2177 0 1 2 3 2178 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 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2182 | Message Type Block="Conf2ACK" (2 words) | 2183 | | 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 Conf2ACK message format 2188 Figure 11: Conf2ACK message format 2190 6.9. Error message 2192 The Error message is sent to terminate an in-process ZRTP key 2193 agreement exchange due to an error. The format is shown in the 2194 Figure below. The use of the Error message is described in 2195 Section 5.7.1. 2197 0 1 2 3 2198 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 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | Message Type Block="Error " (2 words) | 2203 | | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2205 | Integer Error Code (1 word) | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 Error message format 2210 Figure 12: Error message format 2212 Defined hexadecimal values for the Error Code are listed in Table 7. 2214 Error Code | Meaning 2215 ----------------------------------------------------------- 2216 0x10 | Malformed packet (CRC OK, but wrong structure) 2217 ----------------------------------------------------------- 2218 0x20 | Critical software error 2219 ----------------------------------------------------------- 2220 0x30 | Unsupported ZRTP version 2221 ----------------------------------------------------------- 2222 0x40 | Hello components mismatch 2223 ----------------------------------------------------------- 2224 0x51 | Hash type not supported 2225 ----------------------------------------------------------- 2226 0x52 | Cipher type not supported 2227 ----------------------------------------------------------- 2228 0x53 | Public key exchange not supported 2229 ----------------------------------------------------------- 2230 0x54 | SRTP auth. tag not supported 2231 ----------------------------------------------------------- 2232 0x55 | SAS scheme not supported 2233 ----------------------------------------------------------- 2234 0x56 | No shared secret available, DH mode required 2235 ----------------------------------------------------------- 2236 0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1) 2237 ----------------------------------------------------------- 2238 0x62 | DH Error: hvi != hashed data 2239 ----------------------------------------------------------- 2240 0x63 | Received relayed SAS from untrusted MiTM 2241 ----------------------------------------------------------- 2242 0x70 | Auth. Error: Bad Confirm pkt HMAC 2243 ----------------------------------------------------------- 2244 0x80 | Nonce reuse 2245 ----------------------------------------------------------- 2246 0x90 | Equal ZIDs in Hello 2247 ----------------------------------------------------------- 2248 0x100 | GoClear packet received, but not allowed 2249 ----------------------------------------------------------- 2251 Table 7. ZRTP Error Codes 2253 6.10. ErrorACK message 2255 The ErrorACK message is sent in response to an Error message. The 2256 format is shown in the Figure below. 2258 0 1 2 3 2259 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 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Message Type Block="ErrorACK" (2 words) | 2264 | | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 ErrorACK message format 2269 Figure 13: ErrorAck message format 2271 6.11. GoClear message 2273 Support for the GoClear message is OPTIONAL in the protocol, and it 2274 is sent to switch from SRTP to RTP. The format is shown in the 2275 Figure below. The clear_hmac is used to authenticate the GoClear 2276 message so that bogus GoClear messages introduced by an attacker can 2277 be detected and discarded. The use of GoClear is described in 2278 Section 5.7.2. 2280 0 1 2 3 2281 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 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | Message Type Block="GoClear " (2 words) | 2286 | | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | clear_hmac (2 words) | 2289 | | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 GoClear message format 2294 Figure 14: GoClear message format 2296 6.12. ClearACK message 2298 Support for the ClearACK message is OPTIONAL in the protocol, and it 2299 is sent to acknowledge receipt of a GoClear. A ClearACK is only sent 2300 if the clear_hmac from the GoClear message is authenticated. 2301 Otherwise, no response is returned. The format is shown in the 2302 Figure below. 2304 0 1 2 3 2305 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 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 | Message Type Block="ClearACK" (2 words) | 2310 | | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 ClearACK message format 2315 Figure 15: ClearAck message format 2317 6.13. SASrelay message 2319 The SASrelay message is sent by a trusted Man in The Middle (MiTM), 2320 most often a PBX. It is not sent as a response to a packet, but is 2321 sent as a self-initiated packet by the trusted MiTM. It can only be 2322 sent after the rest of the ZRTP key negotiations have completed, 2323 after the Confirm packets and their ACKs. It can only be sent after 2324 the trusted MiTM has finished key negotiations with the other party, 2325 because it is the other party's SAS that is being relayed. It is 2326 sent with retry logic until a RelayACK message (Section 6.14) is 2327 received or the retry schedule has been exhausted. The SASrelay 2328 message format is shown in Figure 16 below. The message contains the 2329 Message Type Block "SASrelay". Next is the HMAC, a keyed hash over 2330 encrypted part of the message (shown enclosed by "===" in Figure 16.) 2331 The next 16 octets contain the CFB Initialization Vector. The rest 2332 of the message is encrypted using CFB and protected by the HMAC. 2334 The next 16 bits are not used. They SHOULD be set to zero and MUST 2335 be ignored in received SASrelay messages. 2337 The next 8 bits contain the signature length. The trusted MiTM MAY 2338 compute a digital signature on the SAS hash, as described in 2339 Section 8.2, using a persistant signing key owned by the trusted 2340 MiTM. If no SAS signature is present, all bits are set to zero. The 2341 signature length is in words and includes the signature type block. 2342 If the calculated signature octet count is not a multiple of 4, zeros 2343 are added to pad it out to a word boundary. If no signature block is 2344 present, the overall length of the SASrelay Message will be set to 12 2345 words. 2347 The next 8 bits are used for flags. Undefined flags are set to zero 2348 and ignored. Three flags are currently defined. The Disclosure Flag 2349 (D) is a Boolean bit defined in Section 12. The Allow Clear flag (A) 2350 is a Boolean bit defined in Section 5.7.2. The SAS Verified flag (V) 2351 is a Boolean bit defined in Section 8.1. These flags are updated 2352 values to the same flags provided earlier in the Confirm packet, but 2353 they are updated to reflect the new flag information relayed by the 2354 PBX from the other party. 2356 The next 32 bit word contains the rendering scheme for the relayed 2357 sasvalue, which will be the same rendering scheme used by the other 2358 party on the other side of the trusted MiTM. Section 8.3 describes 2359 how the PBX determines whether the ZRTP client regards the PBX as a 2360 trusted MiTM. If the PBX determines that the ZRTP client trusts the 2361 PBX, the next 32 bit word contains the binary sasvalue relayed from 2362 the other party. If this SASRelay packet is being sent to a ZRTP 2363 client that does not trust this MiTM, the next 32 bit word will be 2364 ignored by the recipient and should be set to zero by the PBX. 2366 If the signature length (in words) is non-zero, a signature type 2367 block will be present along with a signature block. Next is the 2368 signature block. The signature block includes the key used to 2369 generate the signature. 2371 CFB [SP800-38A] mode is applied with a feedback length of 128-bits, a 2372 full cipher block, and the final block is truncated to match the 2373 exact length of the encrypted data. The CFB Initialization Vector is 2374 a 128 bit random nonce. The block cipher algorithm and the key size 2375 is the same as what was negotiated for the media encryption. CFB is 2376 used to encrypt the part of the SASrelay message beginning after the 2377 CFB IV to the end of the message (the encrypted region is enclosed by 2378 "======" in Figure 16). 2380 Depending on whether the trusted MiTM had taken the role of the 2381 initiator or the responder during the ZRTP key negotiation, the 2382 SASrelay message is encrypted with zrtpkeyi or zrtpkeyr. 2384 0 1 2 3 2385 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 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Message Type Block="SASrelay" (2 words) | 2390 | | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | HMAC (2 words) | 2393 | | 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | | 2396 | CFB Initialization Vector (4 words) | 2397 | | 2398 | | 2399 +===============================================================+ 2400 | Unused (Set to zero, ignored) | sig length |0 0 0 0|0|V|A|D| 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | rendering scheme of relayed sasvalue (1 word) | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | Trusted MITM relayed sasvalue (1 word) | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 | optional signature type block (1 word if present) | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | | 2409 | optional signature block (variable length) | 2410 | . . . | 2411 | | 2412 | | 2413 +===============================================================+ 2415 SASrelay message format 2417 Figure 16: SASrelay message format 2419 6.14. RelayACK message 2421 The RelayACK message is sent in response to a valid SASrelay message. 2422 The message format for the RelayACK is shown in the Figure below. 2423 The receipt of a RelayACK stops retransmission of the SASrelay 2424 message. 2426 0 1 2 3 2427 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 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | Message Type Block="RelayACK" (2 words) | 2432 | | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 RelayACK message format 2437 Figure 17: RelayACK message format 2439 7. Retransmissions 2441 ZRTP uses two retransmission timers T1 and T2. T1 is used for 2442 retransmission of Hello messages, when the support of ZRTP by the 2443 other endpoint may not be known. T2 is used in retransmissions of 2444 all the other ZRTP messages. 2446 All message retransmissions MUST be identical to the initial message 2447 including nonces, public values, etc; otherwise, hashes of the 2448 message sequences may not agree. 2450 Practical experience has shown that RTP packet loss at the start of 2451 an RTP session can be extremely high. Since the entire ZRTP message 2452 exchange occurs during this period, the defined retransmission scheme 2453 is defined to be aggressive. Since ZRTP packets with the exception 2454 of the DHPart1 and DHPart2 messages are small, this should have 2455 minimal effect on overall bandwidth utilization of the media session. 2457 ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media 2458 session as determined by the offer/answer exchange in the signaling 2459 layer. 2461 Hello ZRTP requests are retransmitted at an interval that starts at 2462 T1 seconds and doubles after every retransmission, capping at 200ms. 2463 A Hello message is retransmitted 20 times before giving up. T1 has a 2464 recommended initial value of 50 ms. Retransmission of a Hello ends 2465 upon receipt of a HelloACK or Commit message. 2467 Non-Hello ZRTP requests are retransmitted only by the initiator - 2468 that is, only Commit, DHPart2, Confirm2, and GoClear are 2469 retransmitted if the corresponding message from the responder, 2470 DHPart1, Confirm1, Conf2ACK, and ClearACK, are not received. Non- 2471 Hello ZRTP messages are retransmitted at an interval that starts at 2472 T2 seconds and doubles after every retransmission, capping at 600ms. 2474 Only the ZRTP initiator performs retransmissions. Each message is 2475 retransmitted 10 times before giving up and resuming a normal RTP 2476 session. T2 has a recommended initial value of 150ms. Each message 2477 has a response message that stops retransmissions, as shown in Table 2478 8. The high value of T2 means that retransmissions will likely only 2479 occur with packet loss. 2481 Message Acknowledgement Message 2482 ------- ----------------------- 2483 Hello HelloACK or Commit 2484 Commit DHPart1 or Confirm1 2485 DHPart2 Confirm1 2486 Confirm1 Confirm2 2487 Confirm2 Conf2ACK 2488 GoClear ClearACK 2489 Error ErrorACK 2490 SASrelay RelayACK 2492 Table 8. Retransmitted ZRTP Messages and Responses 2494 8. Short Authentication String 2496 This section will discuss the implementation of the Short 2497 Authentication String, or SAS in ZRTP. The SAS can be verbally 2498 verified by the human users reading the string aloud, or by 2499 validating a digital signature exchanged in the Confirm1 or Confirm2 2500 messages. 2502 The rendering of the SAS value to the user depends on the SAS Type 2503 agreed upon in the Commit message. For the SAS Type of base32, the 2504 leftmost 20 bits of the 32-bit sasvalue are rendered as a form of 2505 base32 encoding known as z-base-32 [z-base-32]. The purpose of 2506 z-base-32 is to represent arbitrary sequences of octets in a form 2507 that is as convenient as possible for human users to manipulate. As 2508 a result, the choice of characters is slightly different from base32 2509 as defined in RFC 3548. The leftmost 20 bits of the sasvalue results 2510 in four base32 characters which are rendered to both ZRTP endpoints. 2511 For the SAS Type of base256, the leftmost 16 bits of the 32-bit 2512 sasvalue are rendered using the PGP Wordlist [base256], 2513 [pgpwordlist]. Other SAS Types may be defined to render the SAS 2514 value in other ways. 2516 The SAS SHOULD be rendered to the user for authentication. In 2517 addition, the SAS SHOULD be sent in a subsequent offer/answer 2518 exchange (a re-INVITE in SIP) after the completion of ZRTP exchange 2519 using the ZRTP SAS SDP attributes defined in Section 9. 2521 The SAS is not treated as a secret value, but it must be compared to 2522 see if it matches at both ends of the communications channel. The 2523 two users read it aloud to their partners to see if it matches. This 2524 allows detection of a man-in-the-middle (MITM) attack. 2526 There is only one SAS value computed per call. That is the SAS value 2527 for the first media stream established, which computes the ZRTPSess 2528 key, using DH mode. The ZRTPSess key is used to compute the SAS, as 2529 well as the SRTP session keys for each additional media stream in 2530 Multistream mode. This SAS applies to all media streams for the same 2531 call. 2533 8.1. SAS Verified Flag 2535 The SAS Verified flag (V) is set based on the user indicating that 2536 SAS comparison has been successfully performed. The SAS Verified 2537 flag is exchanged securely in the Confirm1 and Confirm2 messages of 2538 the next session. In other words, each party sends the SAS Verified 2539 flag from the previous session in the Confirm message of the current 2540 session. It is perfectly reasonable to have a ZRTP endpoint that 2541 never sets the SAS Verified flag, because it would require adding 2542 complexity to the user interface to allow the user to set it. The 2543 SAS Verified flag is not required to be set, but if it is available 2544 to the client software, it allows for the possibility that the client 2545 software could render to the user that the SAS verify procedure was 2546 carried out in a previous session. 2548 Regardless of whether there is a user interface element to allow the 2549 user to set the SAS Verified flag, it is worth caching a shared 2550 secret, because doing so reduces opportunities for an attacker in the 2551 next call. 2553 If at any time the users carry out the SAS comparison procedure, and 2554 it actually fails to match, then this means there is a very 2555 resourceful man-in-the-middle. If this is the first call, the MITM 2556 was there on the first call, which is impressive enough. If it 2557 happens in a later call, it also means the MITM must also know the 2558 cached shared secret, because you could not have carried out any 2559 voice traffic at all unless the session key was correctly computed 2560 and is also known to the attacker. This implies the MITM must have 2561 been present in all the previous sessions, since the initial 2562 establishment of the first shared secret. This is indeed a 2563 resourceful attacker. It also means that if at any time he ceases 2564 his participation as a MITM on one of your calls, the protocol will 2565 detect that the cached shared secret is no longer valid -- because it 2566 was really two different shared secrets all along, one of them 2567 between Alice and the attacker, and the other between the attacker 2568 and Bob. The continuity of the cached shared secrets make it possible 2569 for us to detect the MITM when he inserts himself into the ongoing 2570 relationship, as well as when he leaves. Also, if the attacker tries 2571 to stay with a long lineage of calls, but fails to execute a DH MITM 2572 attack for even one missed call, he is permanently excluded. He can 2573 no longer resynchronize with the chain of cached shared secrets. 2575 Some sort of user interface element (maybe a checkbox) is needed to 2576 allow the user to tell the software the SAS verify was successful, 2577 causing the software to set the SAS Verified flag (V), which 2578 (together with our cached shared secret) obviates the need to perform 2579 the SAS procedure in the next call. An additional user interface 2580 element can be provided to let the user tell the software he detected 2581 an actual SAS mismatch, which indicates a MITM attack. The software 2582 can then take appropriate action, clearing the SAS Verified flag, and 2583 erase the cached shared secret from this session. It is up to the 2584 implementer to decide if this added user interface complexity is 2585 warranted. 2587 If the SAS matches, it means there is no MITM, which also implies it 2588 is now safe to trust a cached shared secret for later calls. If 2589 inattentive users don't bother to check the SAS, it means we don't 2590 know whether there is or is not a MITM, so even if we do establish a 2591 new cached shared secret, there is a risk that our potential attacker 2592 may have a subsequent opportunity to continue inserting himself in 2593 the call, until we finally get around to checking the SAS. If the 2594 SAS matches, it means no attacker was present for any previous 2595 session since we started propagating cached shared secrets, because 2596 this session and all the previous sessions were also authenticated 2597 with a continuous lineage of shared secrets. 2599 8.2. Signing the SAS 2601 The SAS MAY be signed and the signature sent using the Confirm1, 2602 Confirm2, or SASrelay messages. The signature algorithm is also sent 2603 in the Confirm1, Confirm2, or SASrelay message, along with the length 2604 of the signature. The key types and signature algorithms are for 2605 future study. The signature is calculated over the entire SAS hash 2606 result (sashash) that was truncated down to derive the sasvalue. The 2607 signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay 2608 messages MAY be used to authenticate the ZRTP exchange. 2610 8.3. Relaying the SAS through a PBX 2612 ZRTP is designed to use end-to-end encryption. The two parties' 2613 verbal comparison of the short authentication string (SAS) depends on 2614 this assumption. But in some PBX environments, such as Asterisk, 2615 there are usage scenarios that have the PBX acting as a trusted man- 2616 in-the-middle (MiTM), which means there are two back-to-back ZRTP 2617 connections with separate session keys and separate SAS's. 2619 For example, imagine that Bob has a ZRTP-enabled VoIP phone that has 2620 been registered with his company's PBX, so that it is regarded as an 2621 extension of the PBX. Alice, whose phone is not associated with the 2622 PBX, might dial the PBX from the outside, and a ZRTP connection is 2623 negotiated between her phone and the PBX. She then selects Bob's 2624 extension from the company directory in the PBX. The PBX makes a 2625 call to Bob's phone (which might be offsite, many miles away from the 2626 PBX through the Internet) and a separate ZRTP connection is 2627 negotiated between the PBX and Bob's phone. The two ZRTP sessions 2628 have different session keys and different SAS's, which would render 2629 the SAS useless for verbal comparison between Alice and Bob. They 2630 might even mistakenly believe that a wiretapper is present because of 2631 the SAS mismatch, causing undue alarm. 2633 ZRTP has a mechanism for solving this problem by having the PBX relay 2634 the Alice/PBX SAS to Bob, sending it through to Bob in a special 2635 SASrelay packet as defined in Section 6.13, which is sent after the 2636 PBX/Bob ZRTP negotiation is complete, after the Confirm packets. 2637 Only the PBX, acting as a special trusted MiTM (trusted by the 2638 recipient of the SAS relay packet), will relay the SAS. The SASrelay 2639 packet protects the relayed SAS from tampering via an included HMAC, 2640 similar to how the Confirm packet is protected. Bob's ZRTP-enabled 2641 phone accepts the relayed SAS for rendering only because Bob's phone 2642 had previously been configured to trust the PBX. This special 2643 trusted relationship with the PBX can be established through a 2644 special security enrollment procedure. After that enrollment 2645 procedure, the PBX is treated by Bob as a special trusted MiTM. This 2646 results in Alice's SAS being rendered to Bob, so that Alice and Bob 2647 may verbally compare them and thus prevent a MiTM attack by any other 2648 untrusted MiTM. 2650 A real bad-guy MiTM cannot exploit this protocol feature to mount a 2651 MiTM attack and relay Alice's SAS to Bob, because Bob has not 2652 previously carried out a special registration ritual with the bad 2653 guy. The relayed SAS would not be rendered by Bob's phone, because 2654 it did not come from a trusted PBX. The recognition of the special 2655 trust relationship is achieved with the prior establishment of a 2656 special shared secret between Bob and his PBX, which is called the 2657 trusted MiTM key. 2659 The trusted MiTM key can be stored in a special cache at the time of 2660 the initial enrollment (which is carried out only once for Bob's 2661 phone), and Bob's phone associates this key with the ZID of the PBX, 2662 while the PBX associates it with the ZID of Bob's phone. After the 2663 enrollment has established and stored this trusted MiTM key, it can 2664 be detected during subsequent ZRTP call negotiations between the PBX 2665 and Bob's phone, because the PBX and the phone MUST pass the hash of 2666 the trusted MiTM key in the DH packet. It is then used as part of 2667 the key agreement to calculate s0. 2669 The PBX can determine whether it is trusted by the ZRTP user agent of 2670 the caller or callee. The presence of a shared trusted MiTM key in 2671 the key negotiation sequence indicates that the phone has been 2672 enrolled with this PBX and therefore trusts it to act as a trusted 2673 MiTM. The PBX SHOULD relay the SAS from the other party in this 2674 case. 2676 The relayed SAS fields contain the SAS rendering type and the binary 2677 32-bit sasvalue. The receiver absolutely MUST NOT render the relayed 2678 SAS if it does not come from a specially trusted ZRTP endpoint. The 2679 security of the ZRTP protocol depends on not rendering a relayed SAS 2680 from an untrusted MiTM, because it may be relayed by a MiTM attacker. 2681 See the SASrelay packet definition (Figure 16) for further details. 2683 To ensure that both Alice and Bob will use to the same SAS rendering 2684 scheme after the keys are negotiated, the PBX also sends the SASrelay 2685 message to the unenrolled party (which does not regard this PBX as a 2686 trusted MiTM), conveying the SAS rendering scheme, but not the SAS 2687 value, which it sets to zero. The unenrolled party will ignore the 2688 relayed SAS field, but will use the specified SAS rendering scheme. 2690 The next section describes the initial enrollment procedure that 2691 establishes a special shared secret between the PBX and Bob's phone, 2692 a trusted MiTM key, so that the phone will learn to recognize the PBX 2693 as a trusted MiTM. 2695 8.3.1. PBX Enrollment and the PBX Enrollment Flag 2697 Both the PBX and the endpoint need to know when enrollment is taking 2698 place. One way of doing this is to setup an enrollment extension on 2699 the PBX which a newly configured endpoint would call and establish a 2700 ZRTP session. The PBX would then play audio media that offers the 2701 user an opportunity to configure his phone to trust this PBX as a 2702 trusted MiTM. The PBX calculates and stores the trusted MiTM shared 2703 secret in its cache and associates it with this phone, indexed by the 2704 phone's ZID. The trusted MiTM PBX shared secret is calculated this 2705 way: 2707 pbxsecret = HMAC(ZRTPSess,"Trusted MiTM key") 2709 The PBX signals the enrollment process by setting the PBX Enrollment 2710 flag (E) in the Confirm message. This flag is used to trigger the 2711 ZRTP endpoint's user interface to prompt the user if they want to 2712 trust this PBX and calculate and store the pbxsecret in the cache. 2714 If the user decides to respond by activating the appropriate user 2715 interface element (a menu item, checkbox, or button), his ZRTP user 2716 agent calculates pbxsecret using the same formula and saves it in a 2717 special cache entry associated with this PBX. 2719 If the user elects not to enroll, perhaps because he dialed a wrong 2720 number or does not yet feel comfortable with this PBX, he can simply 2721 hang up and not save the pbxsecret in his cache. The PBX will have 2722 it saved in the PBX cache, but that will do no harm. The SASrelay 2723 scheme does not depend on the PBX trusting the phone. It only 2724 depends on the phone trusting the PBX. It is the phone (the user) 2725 who is at risk if the PBX abuses its MiTM privileges. 2727 After this enrollment process, the PBX and the ZRTP-enabled phone 2728 both share a secret that enables the phone to recognize the PBX as a 2729 trusted MiTM in future calls. This means that when a future call 2730 from an outside ZRTP-enabled caller is relayed through the PBX to 2731 this phone, the phone will render a relayed SAS from the PBX. If the 2732 SASrelay packet comes from a MiTM which does not know the pbxsecret, 2733 the phone treats it as a "bad guy" MiTM, and refuses to render the 2734 relayed SAS. Regardless of which party initiates any future phone 2735 calls through the PBX, the enrolled phone or the outside phone, the 2736 PBX will relay the SAS to the enrolled phone. 2738 There are other ways that ZRTP user agents can be configured to trust 2739 a PBX. Perhaps the pbxsecret can be configured into the phone by 2740 some automated provisioning process in large IT environments. This 2741 specification does not require that products be configured solely by 2742 this enrollment process. Any process that results in a pbxsecret to 2743 be computed and shared between the PBX and the phone will suffice. 2744 This is one such method that has been shown to work. 2746 9. Signaling Interactions 2748 This section discusses how ZRTP, SIP, and SDP work together. 2750 Note that ZRTP may be implemented without coupling with the SIP 2751 signaling. For example, ZRTP can be implemented as a "bump in the 2752 wire" or as a "bump in the stack" in which RTP sent by the SIP UA is 2753 converted to ZRTP. In these cases, the SIP UA will have no knowledge 2754 of ZRTP. As a result, the signaling path discovery mechanisms 2755 introduced in this section should not be definitive - they are a 2756 hint. Despite the absence of an indication of ZRTP support in an 2757 offer or answer, a ZRTP endpoint SHOULD still send Hello messages. 2759 ZRTP endpoints which have control over the signaling path include a 2760 ZRTP SDP attributes in their SDP offers and answers. The ZRTP 2761 attribute, a=zrtp-hash is used to indicate support for ZRTP and to 2762 convey a hash of the Hello message. There are a number of potential 2763 uses for this attribute. It is useful when signaling elements would 2764 like to know when ZRTP may be utilized by endpoints. It is also 2765 useful if endpoints support multiple methods of SRTP key management. 2766 The ZRTP attribute can be used to ensure that these key management 2767 approaches work together instead of against each other. For example, 2768 if only one endpoint supports ZRTP but both support another method to 2769 key SRTP, then the other method will be used instead. When used in 2770 parallel, an SRTP secret carried in an a=keymgt [RFC4567] or a=crypto 2771 [RFC4568] attribute can be used as a shared secret for the 2772 srtp_secret. The ZRTP attribute is also used to signal to an 2773 intermediary ZRTP device not to act as a ZRTP endpoint, as discussed 2774 in Section 11. 2776 The a=zrtp-hash attribute can only be included at a media level since 2777 Hello messages sent in different media streams will have unique 2778 hashes. 2780 The ABNF for the ZRTP attribute is as follows: 2782 zrtp-attribute = "a=zrtp-hash:" zrtp-hash-value 2784 zrtp-hash-value = 1*(HEXDIG) 2786 Example of the ZRTP attribute in an initial SDP offer or answer used 2787 at the session level: 2789 v=0 2790 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 2791 s= 2792 c=IN IP4 client.biloxi.example.com 2793 t=0 0 2794 m=audio 3456 RTP/AVP 97 33 2795 a=rtpmap:97 iLBC/8000 2796 a=rtpmap:33 no-op/8000 2797 a=zrtp-hash:fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df 2799 9.1. Binding the media stream to the signaling layer via the Hello Hash 2801 It is desirable to tie the media stream to the signaling channel to 2802 prevent a third party from inserting false media packets. If the 2803 signaling layer contains information that ties it to the media 2804 stream, false media streams can be rejected. 2806 To accomplish this, a SHA-256 hash is computed across the entire ZRTP 2807 Hello message (as shown in Figure 3). This hash image is made 2808 available to the signaling layer, where it is transmitted as a 2809 hexadecimal value in the SIP channel using the SDP attribute, a=zrtp- 2810 hash defined in this specification. Each media stream (audio or 2811 video) will have a separate Hello packet, and thus will require a 2812 separate a=zrtp-hash in an SDP attribute. The recipient of the SIP/ 2813 SDP message can then use this hash image to detect and reject false 2814 Hello packets in the media channel, as well as identify which media 2815 stream is associated with this SIP call. Each Hello packet hashes 2816 uniquely, because it contains the H3 field derived from a random 2817 nonce, defined in Section 10. 2819 The Hello Hash as an SDP attribute is an OPTIONAL feature, because 2820 some ZRTP endpoints do not have the ability to add SDP attributes to 2821 the signaling. For example, if ZRTP is implemented in a hardware 2822 bump-in-the-wire device, it might only have the ability to modify the 2823 media packets, not the SIP packets, especially if the SIP packets are 2824 integrity protected and thus cannot be modified on the wire. If the 2825 SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP 2826 user agent cannot check it, and thus will not be able to reject Hello 2827 messages based on this hash. 2829 After the Hello Hash is used to properly identify the ZRTP Hello 2830 message as belonging to this particular SIP call, the rest of the 2831 ZRTP message sequence is protected from false packet injection by 2832 other protection mechanisms. For example, the use of the total_hash 2833 in the shared secret calculation, and also the hash chaining 2834 mechanism defined in Section 10. 2836 An attacker who controls only the signaling layer, such as an 2837 uncooperative VoIP service provider, may be able to deny service by 2838 corrupting the hash of the Hello message in the SDP attribute, which 2839 would force ZRTP to reject perfectly good Hello messages. If there 2840 is reason to believe this is happening, the ZRTP endpoint MAY allow 2841 Hello messages to be accepted that do not match the hash image in the 2842 SDP attribute. 2844 Even in the absence of SIP integrity protection, the inclusion of the 2845 a=zrtp-hash SDP attribute, when coupled with the hash chaining 2846 mechanism defined in Section 10, meets the R-ASSOC requirement in the 2847 Media Security Requirements 2848 [I-D.ietf-sip-media-security-requirements], which requires: 2850 "...a mechanism for associating key management messages with both 2851 the signaling traffic that initiated the session and with 2852 protected media traffic. Allowing such an association also allows 2853 the SDP offerer to avoid performing CPU-consuming operations 2854 (e.g., Diffie-Hellman or public key operations) with attackers 2855 that have not seen the signaling messages." 2857 The a=zrtp-hash SDP attribute becomes especially useful if the SDP is 2858 integrity-protected end-to-end by SIP Identity (RFC 4474) [RFC4474] 2859 or better still, Dan Wing's SIP Identity using Media Path 2860 [I-D.wing-sip-identity-media]. This leads to an ability to stop MiTM 2861 attacks independent of ZRTP's SAS mechanism, as explained in 2862 Section 9.1.1 below. 2864 9.1.1. Integrity-protected signaling enables integrity-protected DH 2865 exchange 2867 If and only if the signaling path and the SDP is protected by some 2868 form of end-to-end integrity protection, such as one of the 2869 abovementioned mechanisms, so that it can guarantee delivery of the 2870 a=zrtp-hash attribute without any tampering by a third party, and if 2871 there is good reason to trust the signaling layer to protect the 2872 interests of the end user, it is possible to authenticate the key 2873 exchange and prevent a MiTM attack. This can be done without 2874 requiring the users to verbally compare the SAS, by using the hash 2875 chaining mechanism defined in Section 10 to provide a series of HMAC 2876 keys that protect the entire ZRTP key exchange. Thus, an end-to-end 2877 integrity-protected signaling layer automatically enables an 2878 integrity-protected Diffie-Hellman exchange in ZRTP, which in turn 2879 means immunity from a MiTM attack. Here's how it works. 2881 The integrity-protected SIP SDP contains a hash commitment to the 2882 entire Hello message. The Hello message contains H3, which provides 2883 a hash commitment for the rest of the hash chain H0-H2 (Section 10). 2884 The Hello message is protected by a 64-bit HMAC, keyed by H2. The 2885 Commit message is protected by a 64-bit HMAC keyed by H1. The 2886 DHPart1 or DHPart2 messages are protected by a 64-bit HMAC keyed by 2887 H0. The HMAC protecting the Confirm messages are computed by a 2888 different HMAC key derived from the resulting key agreement. Each 2889 message's HMAC is checked when the HMAC key is received in the next 2890 message. If a bad HMAC is discovered, it MUST be treated as a 2891 security exception indicating a MiTM attack, perhaps by logging or 2892 alerting the user. It MUST NOT be treated as a random error. Random 2893 errors are already discovered and quietly rejected by bad CRCs 2894 (Figure 2). 2896 The Media Security Requirements 2897 [I-D.ietf-sip-media-security-requirements] R-EXISTING requirement can 2898 be fully met by leveraging a certificate-backed PKI in the signaling 2899 layer to integrity-protect the delivery of the a=zrtp-hash SDP 2900 attribute. This would thereby protect ZRTP against a MiTM attack, 2901 without requiring the user to check the SAS, without adding any 2902 explicit signatures or signature keys to the ZRTP key exchange, and 2903 without any extra public key operations or extra packets. 2905 Without an end-to-end integrity protection mechanism in the signaling 2906 layer to guarantee delivery of the a=zrtp-hash SDP attribute without 2907 modification by a third party, these HMACs alone will not prevent a 2908 MiTM attack. In that case, ZRTP's built-in SAS mechanism will still 2909 have to be used to authenticate the key exchange. At the time of 2910 this writing, very few deployed VoIP clients offer a fully 2911 implemented SIP stack that provides end-to-end integrity protection 2912 for the delivery of SDP attributes. Also, end-to-end signaling 2913 integrity becomes more problematic if E.164 numbers [RFC3824] are 2914 used in SIP. Thus, real-world implementations of ZRTP endpoints will 2915 continue to depend on SAS authentication for quite some time. Even 2916 after there is widespread availability of SIP user agents that offer 2917 integrity protected delivery of SDP attributes, many users will still 2918 be faced with the fact that the signaling path may be controlled by 2919 institutions that do not have the best interests of the end user in 2920 mind. In those cases, SAS authentication will remain the gold 2921 standard for the prudent user. 2923 Even without SIP integrity protection, the Media Security 2924 Requirements [I-D.ietf-sip-media-security-requirements] R-ACT-ACT 2925 requirement can be met by ZRTP's SAS mechanism. Although ZRTP may 2926 benefit from an integrity-protected SIP layer, it is fortunate that 2927 ZRTP's self-contained MiTM defenses do not actually require an 2928 integrity-protected SIP layer. ZRTP can bypass the delays and 2929 problems that SIP integrity faces, such as E.164 number usage, and 2930 the complexity of building and maintaining a PKI. 2932 In contrast, DTLS-SRTP [I-D.ietf-avt-dtls-srtp] appears to depend 2933 heavily on end-to-end integrity protection in the SIP layer. 2934 Further, DTLS-SRTP must bear the additional cost of a signature 2935 calculation of its own, in addition to the signature calculation the 2936 SIP layer uses to achieve its integrity protection. ZRTP needs no 2937 signature calculation of its own to leverage the signature 2938 calculation carried out in the SIP layer. 2940 9.2. Deriving the SRTP secret (srtps) from the signaling layer 2942 The shared secret calculations defined in Section 5.3 make use of the 2943 SRTP secret (srtps), if it is provided by the signaling layer. 2945 It is desirable for only one SRTP key negotiation protocol to be 2946 used, and that protocol should be ZRTP. But in the event the 2947 signaling layer negotiates its own SRTP master key and salt, using 2948 the SDES [RFC4568] or [RFC4567], it can be passed from the signaling 2949 to the ZRTP layer and mixed into ZRTP's own shared secret 2950 calculations, without compromising security by creating a dependency 2951 on the signaling for media encryption. 2953 ZRTP computes srtps from the SRTP master key and salt parameters 2954 provided by the signaling layer in this manner: 2956 srtps = hash(SRTP master key | SRTP master salt) 2958 It is expected that the srtps parameter will be rarely computed or 2959 used in typical ZRTP endpoints, because it is likely and desirable 2960 that ZRTP will be the sole means of negotiating SRTP keys, needing no 2961 help from SDES [RFC4568] or [RFC4567]. If srtps is computed, it will 2962 be stored in the auxiliary shared secret auxsecret, defined in 2963 Section 5.3, and used in Section 5.3.1 and Section 5.3.2. 2965 10. False ZRTP Packet Rejection 2967 An attacker who is not in the media path may attempt to inject false 2968 ZRTP protocol packets, possibly to effect a denial of service attack, 2969 or to inject his own media stream into the call. VoIP by its nature 2970 invites various forms of denial of service attacks and requires 2971 protocol features to reject such attacks. While bogus SRTP packets 2972 may be easily rejected via the SRTP auth tag field, that can only be 2973 applied after a key agreement is completed. During the ZRTP key 2974 negotiation phase, other false packet rejection mechanisms are 2975 needed. One such mechanism is the use of the total_hash in the final 2976 shared secret calculation, but that can only detect false packets 2977 after performing the computationally expensive Diffie-Hellman 2978 calculation. 2980 The VoIP developer community expects to see a lot of denial of 2981 service attacks, especially from attackers who are not in the media 2982 path. Such an attacker might inject false ZRTP packets to force a 2983 ZRTP endpoint to engage in an endless series of pointless and 2984 expensive DH calculations. To detect and reject false packets 2985 cheaply and rapidly as soon as they are received, ZRTP uses a hash 2986 chain, which is a series of successive hash images. Before each 2987 session, the following values are computed: 2989 H0 = 256-bit random nonce (different for each party) 2990 H1 = hash (H0) 2991 H2 = hash (H1) 2992 H3 = hash (H2) 2994 The hash function is defined to be SHA-256. Each 256-bit hash image 2995 is the pre-image of the next, and the sequence of images is sent in 2996 reverse order in the ZRTP packet sequence. The hash image H3 is sent 2997 in the Hello packet, H2 is sent in the Commit packet, H1 is sent in 2998 the DHPart1 or DHPart2 packets, and H0 is sent in the Confirm1 or 2999 Confirm2 packets. The initial random H0 nonces that each party 3000 generates MUST be unpredictable to an attacker and unique within a 3001 ZRTP call, which thereby forces the derived hash images H1-H3 to also 3002 be unique and unpredictable. 3004 The recipient checks if the packet has the correct hash pre-image, by 3005 hashing it and comparing the result with the hash image for the 3006 preceding packet. Packets which contain an incorrect hash pre-image 3007 MUST NOT be used by the recipient, but MAY be processed as security 3008 exceptions, perhaps by logging or alerting the user. As long as 3009 these bogus packets are not used, and correct packets are still being 3010 received, the protocol SHOULD be allowed to run to completion, 3011 thereby rendering ineffective this denial of service attack. 3013 Because these hash images alone do not protect the rest of the 3014 contents of the packet they reside in, this scheme assumes the 3015 attacker cannot modify the packet contents from a legitimate party, 3016 which is a reasonable assumption for an attacker who is not in the 3017 media path. This covers an important range of denial-of-service 3018 attacks. For dealing with the remaining set of attacks that involve 3019 packet modification, other mechanisms are used, such as the 3020 total_hash in the final shared secret calculation, and the hash 3021 commitment in the Commit packet. 3023 False Hello packets may be detected and rejected by the mechanism 3024 defined in Section 9.1. This mechanism requires that each Hello 3025 packet be unique, and the inclusion of the H3 hash image meets that 3026 requirement. 3028 If and only if an integrity-protected signaling channel is available, 3029 this hash chaining scheme can be used to key HMACs to authenticate 3030 the entire ZRTP key exchange, and thereby prevent a MiTM attack, 3031 without relying on the users verbally comparing the SAS. See 3032 Section 9.1.1 for details. 3034 Some ZRTP user agents allow the user to manually switch to clear mode 3035 (via the GoClear packet) in the middle of a secure call, and then 3036 later initiate secure mode again. Many consumer client products will 3037 omit this feature, but those that allow it may return to secure mode 3038 again in the same media stream. Although the same chain of hash 3039 images will be re-used and thus rendered ineffective the second time, 3040 no real harm is done because the new SRTP session keys will be 3041 derived in part from a cached shared secret, which was safely 3042 protected from the MiTM in the previous DH exchange earlier in the 3043 same call. 3045 11. Intermediary ZRTP Devices 3047 This section discusses the operation of a ZRTP endpoint which is 3048 actually an intermediary. For example, consider a device which 3049 proxies both signaling and media between endpoints. There are three 3050 possible ways in which such a device could support ZRTP. 3052 An intermediary device can act transparently to the ZRTP protocol. 3053 To do this, a device MUST pass RTP header extensions and payloads (to 3054 allow the ZRTP Flag) and non-RTP protocols multiplexed on the same 3055 port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED 3056 behavior for intermediaries as ZRTP and SRTP are best when done end- 3057 to-end. 3059 An intermediary device could implement the ZRTP protocol and act as a 3060 ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary 3061 device. The intermediary could determine on a call-by-call basis 3062 whether the endpoint behind it supports ZRTP based on the presence or 3063 absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP 3064 endpoints, the intermediary device could act as the ZRTP endpoint 3065 using its own ZID and cache. This approach MUST only be used when 3066 there is some other security method protecting the confidentiality of 3067 the media between the intermediary and the inside endpoint, such as 3068 IPSec or physical security. 3070 The third mode, which is NOT RECOMMENDED, is for the intermediary 3071 device to attempt to back-to-back the ZRTP protocol. The only 3072 exception to this case is where the intermediary device is a trusted 3073 element providing services to one of the endpoints - e.g. a Private 3074 Branch Exchange or PBX. In this mode, the intermediary would attempt 3075 to act as a ZRTP endpoint towards both endpoints of the media 3076 session. This approach MUST NOT be used except as described in 3077 Section 8.3 as it will always result in a detected man-in-the-middle 3078 attack and will generate alarms on both endpoints and likely result 3079 in the immediate termination of the session. 3081 In cases where centralized media mixing is taking place, the SAS will 3082 not match when compared by the humans. However, this situation is 3083 known in the SIP signaling by the presence of the isfocus feature tag 3084 [RFC4579]. As a result, when the isfocus feature tag is present, the 3085 DH exchange can be authenticated by the mechanism defined in 3086 Section 9.1.1 or by validating signatures in the Confirm or SASrelay 3087 messages. For example, consider a audio conference call with three 3088 participants Alice, Bob, and Carol hosted on a conference bridge in 3089 Dallas. There will be three ZRTP encrypted media streams, one 3090 encrypted stream between each participant and Dallas. Each will have 3091 a different SAS. Each participant will be able to validate their SAS 3092 with the conference bridge by using signatures in the Confirm 3093 messages. Or, if the signaling path has end-to-end integrity 3094 protection, each DH exchange will have automatic MiTM protection by 3095 using the mechanism in Section 9.1.1. 3097 SIP feature tags can also be used to detect if a session is 3098 established with an automaton such as an IVR, voicemail system, or 3099 speech recognition system. The display of SAS strings to users 3100 should be disabled in these cases. 3102 It is possible that an intermediary device acting as a ZRTP endpoint 3103 might still receive ZRTP Hello and other messages from the inside 3104 endpoint. This could occur if there is another inline ZRTP device 3105 which does not include the ZRTP SDP attribute flag. If this occurs, 3106 the intermediary MUST NOT pass these ZRTP messages if it is acting as 3107 the ZRTP endpoint. 3109 12. The ZRTP Disclosure flag 3111 There are no back doors defined in the ZRTP protocol specification. 3112 The designers of ZRTP would like to discourage back doors in ZRTP- 3113 enabled products. However, despite the lack of back doors in the 3114 actual ZRTP protocol, it must be recognized that a ZRTP implementer 3115 might still deliberately create a rogue ZRTP-enabled product that 3116 implements a back door outside the scope of the ZRTP protocol. For 3117 example, they could create a product that discloses the SRTP session 3118 key generated using ZRTP out-of-band to a third party. They may even 3119 have a legitimate business reason to do this for some customers. 3121 For example, some environments have a need to monitor or record 3122 calls, such as stock brokerage houses who want to discourage insider 3123 trading, or special high security environments with special needs to 3124 monitor their own phone calls. We've all experienced automated 3125 messages telling us that "This call may be monitored for quality 3126 assurance". A ZRTP endpoint in such an environment might 3127 unilaterally disclose the session key to someone monitoring the call. 3128 ZRTP-enabled products that perform such out-of-band disclosures of 3129 the session key can undermine public confidence in the ZRTP protocol, 3130 unless we do everything we can in the protocol to alert the other 3131 user that this is happening. 3133 If one of the parties is using a product that is designed to disclose 3134 their session key, ZRTP requires them to confess this fact to the 3135 other party through a protocol message to the other party's ZRTP 3136 client, which can properly alert that user, perhaps by rendering it 3137 in a graphical user interface. The disclosing party does this by 3138 sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as 3139 described in Section 6.7. 3141 Note that the intention here is to have the Disclosure flag identify 3142 products that are designed to disclose their session keys, not to 3143 identify which particular calls are compromised on a call-by-call 3144 basis. This is an important legal distinction, because most 3145 government sanctioned wiretap regulations require a VoIP service 3146 provider to not reveal which particular calls are wiretapped. But 3147 there is nothing illegal about revealing that a product is designed 3148 to be wiretap-friendly. The ZRTP protocol mandates that such a 3149 product "out" itself. 3151 You might be using a ZRTP-enabled product with no back doors, but if 3152 your own graphical user interface tells you the call is (mostly) 3153 secure, except that the other party is using a product that is 3154 designed in such a way that it may have disclosed the session key for 3155 monitoring purposes, you might ask him what brand of secure telephone 3156 he is using, and make a mental note not to purchase that brand 3157 yourself. If we create a protocol environment that requires such 3158 back-doored phones to confess their nature, word will spread quickly, 3159 and the "invisible hand" of the free market will act. The free 3160 market has effectively dealt with this in the past. 3162 Of course, a ZRTP implementer can lie about his product having a back 3163 door, but the ZRTP standard mandates that ZRTP-compliant products 3164 MUST adhere to the requirement that a back door be confessed by 3165 sending the Disclosure flag to the other party. 3167 There will be inevitable comparisons to Steve Bellovin's 2003 April 3168 fool's joke, when he submitted RFC 3514 [RFC3514] which defined the 3169 "Evil bit" in the IPV4 header, for packets with "evil intent". But 3170 we submit that a similar idea can actually have some merit for 3171 securing VoIP. Sure, one can always imagine that some implementer 3172 will not be fazed by the rules and will lie, but they would have lied 3173 anyway even without the Disclosure flag. There are good reasons to 3174 believe that it will improve the overall percentage of 3175 implementations that at least tell us if they put a back door in 3176 their products, and may even get some of them to decide not to put in 3177 a back door at all. From a civic hygiene perspective, we are better 3178 off with having the Disclosure flag in the protocol. 3180 If an endpoint stores or logs SRTP keys or information that can be 3181 used to reconstruct or recover SRTP keys after they are no longer in 3182 use (i.e. the session is active), or otherwise discloses or passes 3183 SRTP keys or information that can be used to reconstruct or recover 3184 SRTP keys to another application or device, the Disclosure flag D 3185 MUST be set in the Confirm1 or Confirm2 message. 3187 12.1. Guidelines on Proper Implementation of the Disclosure Flag 3189 Some implementers have asked for guidance on implementing the 3190 Disclosure Flag. Some people have incorrectly thought that a 3191 connection secured with ZRTP cannot be used in a call center, with 3192 voluntary voice recording, or even with a voicemail system. 3193 Similarly, some potential users of ZRTP have overconsidered the 3194 protection that ZRTP can give them. These guidelines clarify both 3195 concerns. 3197 The ZRTP Disclosure Flag only governs the ZRTP/SRTP stream itself. 3198 It does not govern the underlying RTP media stream, nor the actual 3199 media itself. Consequently, a PBX that uses ZRTP may provide 3200 conference calls, call monitoring, call recording, voicemail, or 3201 other PBX features and still say that it does not disclose the ZRTP 3202 key material. A video system may provide DVR features and still say 3203 that it does not disclose the ZRTP key material. The ZRTP Disclosure 3204 Flag, when not set, means only that the ZRTP cryptographic key 3205 material stays within the bounds of the ZRTP subsystem. 3207 If an application has a need to disclose the ZRTP cryptographic key 3208 material, the easiest way to comply with the protocol is to set the 3209 flag to the proper value. The next easiest way is to overestimate 3210 disclosure. For example, a call center that commonly records calls 3211 might choose to set the disclosure flag even though all recording is 3212 an analog recording of a call (and thus outside the ZRTP scope) 3213 because it sets an expectation with clients that their calls might be 3214 recorded. 3216 Note also that the ZRTP Disclosure Flag does not require an 3217 implementation to preclude hacking or malware. Malware that leaks 3218 ZRTP cryptographic key material does not create a liability for the 3219 implementor from non-compliance with the ZRTP specification. 3221 A user of ZRTP should note that ZRTP is not a panacea against 3222 unauthorized recording. ZRTP does not and cannot protect against an 3223 untrustworthy partner who holds a microphone up to the speaker. It 3224 does not protect against someone else being in the room. It does not 3225 protect against analog wiretaps in the phone or in the room. It does 3226 not mean your partner has not been hacked with spyware. It does not 3227 mean that the software has no flaws. It means that the ZRTP 3228 subsystem is not knowingly leaking ZRTP cryptographic key material. 3230 13. RTP Header Extension Flag for ZRTP 3232 This specification defines a new RTP header extension used only for 3233 discovery of support for ZRTP. No ZRTP data is transported in the 3234 extension. When used, the X bit is set in the RTP header to indicate 3235 the presence of the RTP header extension. 3237 Section 5.3.1 in RFC 3550 defines the format of an RTP Header 3238 extension. The Header extension is appended to the RTP header. The 3239 first 16 bits are an identifier for the header extension, and the 3240 following 16 bits are length of the extension header in 32 bit words. 3241 The ZRTP flag RTP header extension has the value of 0x505A and a 3242 length of 0. The format of the header extension is as shown in the 3243 Figure below. 3245 0 1 2 3 3246 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 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 |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| 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3251 RTP Extension header format for ZRTP Flag 3253 RTP Extension header format for ZRTP Flag 3255 ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at 3256 the start of a session. For example, and endpoint may decide to 3257 include the flag in the first 1 second of RTP packets sent. The 3258 inclusion of the flag MAY be ended if a ZRTP message (such as Hello) 3259 is received. 3261 14. IANA Considerations 3263 This specification defines a new SDP [RFC4566] attribute in 3264 Section 9. 3266 Contact name: Philip Zimmermann 3268 Attribute name: "zrtp-hash". 3270 Type of attribute: Media level. 3272 Subject to charset: Not. 3274 Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the 3275 ZRTP protocol and provides a hash of the ZRTP Hello 3276 message. 3278 Allowed attribute values: Hex. 3280 15. Security Considerations 3282 This document is all about securely keying SRTP sessions. As such, 3283 security is discussed in every section. 3285 Most secure phones rely on a Diffie-Hellman exchange to agree on a 3286 common session key. But since DH is susceptible to a man-in-the- 3287 middle (MITM) attack, it is common practice to provide a way to 3288 authenticate the DH exchange. In some military systems, this is done 3289 by depending on digital signatures backed by a centrally-managed PKI. 3290 A decade of industry experience has shown that deploying centrally 3291 managed PKIs can be a painful and often futile experience. PKIs are 3292 just too messy, and require too much activation energy to get them 3293 started. Setting up a PKI requires somebody to run it, which is not 3294 practical for an equipment provider. A service provider like a 3295 carrier might venture down this path, but even then you have to deal 3296 with cross-carrier authentication, certificate revocation lists, and 3297 other complexities. It is much simpler to avoid PKIs altogether, 3298 especially when developing secure commercial products. It is 3299 therefore more common for commercial secure phones in the PSTN world 3300 to augment the DH exchange with a Short Authentication String (SAS) 3301 combined with a hash commitment at the start of the key exchange, to 3302 shorten the length of SAS material that must be read aloud. No PKI 3303 is required for this approach to authenticating the DH exchange. The 3304 AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], PGPfone 3305 [pgpfone], and CryptoPhone [cryptophone] are all examples of products 3306 that took this simpler lightweight approach. 3308 The main problem with this approach is inattentive users who may not 3309 execute the voice authentication procedure, or unattended secure 3310 phone calls to answering machines that cannot execute it. 3312 Additionally, some people worry about voice spoofing. But it is a 3313 mistake to think this is simply an exercise in voice impersonation 3314 (perhaps this could be called the "Rich Little" attack). Although 3315 there are digital signal processing techniques for changing a 3316 person's voice, that does not mean a man-in-the-middle attacker can 3317 safely break into a phone conversation and inject his own short 3318 authentication string (SAS) at just the right moment. He doesn't 3319 know exactly when or in what manner the users will choose to read 3320 aloud the SAS, or in what context they will bring it up or say it, or 3321 even which of the two speakers will say it, or if indeed they both 3322 will say it. In addition, some methods of rendering the SAS involve 3323 using a list of words such as the PGP word list, in a manner 3324 analogous to how pilots use the NATO phonetic alphabet to convey 3325 information. This can make it even more complicated for the 3326 attacker, because these words can be worked into the conversation in 3327 unpredictable ways. Remember that the attacker places a very high 3328 value on not being detected, and if he makes a mistake, he doesn't 3329 get to do it over. Some people have raised the question that even if 3330 the attacker lacks voice impersonation capabilities, it may be unsafe 3331 for people who don't know each other's voices to depend on the SAS 3332 procedure. This is not as much of a problem as it seems, because it 3333 isn't necessary that they recognize each other by their voice, it's 3334 only necessary that they detect that the voice used for the SAS 3335 procedure matches the voice in the rest of the phone conversation. 3337 A popular and field-proven approach is used by SSH (Secure Shell) 3338 [RFC4251], which Peter Gutmann likes to call the "baby duck" security 3339 model. SSH establishes a relationship by exchanging public keys in 3340 the initial session, when we assume no attacker is present, and this 3341 makes it possible to authenticate all subsequent sessions. A 3342 successful MITM attacker has to have been present in all sessions all 3343 the way back to the first one, which is assumed to be difficult for 3344 the attacker. ZRTP's key continuity features are actually better 3345 than SSH, for reasons described in Section 5.9.1. All this is 3346 accomplished without resorting to a centrally-managed PKI. 3348 We use an analogous baby duck security model to authenticate the DH 3349 exchange in ZRTP. We don't need to exchange persistent public keys, 3350 we can simply cache a shared secret and re-use it to authenticate a 3351 long series of DH exchanges for secure phone calls over a long period 3352 of time. If we read aloud just one SAS, and then cache a shared 3353 secret for later calls to use for authentication, no new voice 3354 authentication rituals need to be executed. We just have to remember 3355 we did one already. 3357 If one party ever loses this cached shared secret, it is no longer 3358 available for authentication of DH exchanges. This cache mismatch 3359 situation is easy to detect by the party that still has a surviving 3360 shared secret cache entry. If it fails to match, either there is a 3361 MiTM attack or one side has lost their shared secret cache entry. 3362 The user agent that discovers the cache mismatch MUST alert the user 3363 that a cache mismatch has been detected, and that he must do a verbal 3364 comparison of the SAS to distinguish if the mismatch is because of a 3365 MiTM attack or because of the other party losing her cache. From 3366 that point on, the two parties start over with a new cached shared 3367 secret. Then they can go back to omitting the voice authentication 3368 on later calls. 3370 A particularly compelling reason why this approach is attractive is 3371 that SAS is easiest to implement when a graphical user interface or 3372 some sort of display is available, which raises the question of what 3373 to do when a display is less conveniently available. For example, 3374 some devices that implement ZRTP might have a graphical user 3375 interface that is only visible through a web browser, such as a PBX 3376 or some other nearby device that implements ZRTP as a "bump-in-the- 3377 wire". If we take an approach that greatly reduces the need for a 3378 SAS in each and every call, we can operate in products without a 3379 graphical user interface with greater ease. Then the SAS can be 3380 compared less frequently through a web browser, or it might even be 3381 presented as needed to the local user through a locally generated 3382 voice prompt, which the local user hears and verbally repeats and 3383 compares with the remote party. 3385 It's a good idea to force your opponent to have to solve multiple 3386 problems in order to mount a successful attack. Some examples of 3387 widely differing problems we might like to present him with are: 3388 Stealing a shared secret from one of the parties, being present on 3389 the very first session and every subsequent session to carry out an 3390 active MITM attack, and solving the discrete log problem. We want to 3391 force the opponent to solve more than one of these problems to 3392 succeed. 3394 ZRTP can use different kinds of shared secrets. Each type of shared 3395 secret is determined by a different method. All of the shared 3396 secrets are hashed together to form a session key to encrypt the 3397 call. An attacker must defeat all of the methods in order to 3398 determine the session key. 3400 First, there is the shared secret determined entirely by a Diffie- 3401 Hellman key agreement. It changes with every call, based on random 3402 numbers. An attacker may attempt a classic DH MITM attack on this 3403 secret, but we can protect against this by displaying and reading 3404 aloud a SAS, combined with adding a hash commitment at the beginning 3405 of the DH exchange. 3407 Second, there is an evolving shared secret, or ongoing shared secret 3408 that is automatically changed and refreshed and cached with every new 3409 session. We will call this the cached shared secret, or sometimes 3410 the retained shared secret. Each new image of this ongoing secret is 3411 a non-invertable function of its previous value and the new secret 3412 derived by the new DH agreement. It's possible that no cached shared 3413 secret is available, because there were no previous sessions to 3414 inherit this value from, or because one side loses its cache. 3416 There are other approaches for key agreement for SRTP that compute a 3417 shared secret using information in the signaling. For example, 3418 [RFC4567] describes how to carry a MIKEY (Multimedia Internet KEYing) 3419 [RFC3830] payload in SDP [RFC4566]. Or RFC 4568 (SDES) [RFC4568] 3420 describes directly carrying SRTP keying and configuration information 3421 in SDP. ZRTP does not rely on the signaling to compute a shared 3422 secret, but If a client does produce a shared secret via the 3423 signaling, and makes it available to the ZRTP protocol, ZRTP can make 3424 use of this shared secret to augment the list of shared secrets that 3425 will be hashed together to form a session key. This way, any 3426 security weaknesses that might compromise the shared secret 3427 contributed by the signaling will not harm the final resulting 3428 session key. 3430 There may also be a static shared secret that the two parties agree 3431 on out-of-band in advance. A hashed passphrase would suffice. 3433 The shared secret provided by the signaling (if available), the 3434 shared secret computed by DH, and the cached shared secret are all 3435 hashed together to compute the session key for a call. If the cached 3436 shared secret is not available, it is omitted from the hash 3437 computation. If the signaling provides no shared secret, it is also 3438 omitted from the hash computation. 3440 No DH MITM attack can succeed if the ongoing shared secret is 3441 available to the two parties, but not to the attacker. This is 3442 because the attacker cannot compute a common session key with either 3443 party without knowing the cached secret component, even if he 3444 correctly executes a classic DH MITM attack. Mixing in the cached 3445 shared secret for the session key calculation allows it to act as an 3446 implicit authenticator to protect the DH exchange, without requiring 3447 additional explicit HMACs to be computed on the DH parameters. If 3448 the cached shared secret is available, a MITM attack would be 3449 instantly detected by the failure to achieve a shared session key, 3450 resulting in undecryptable packets. The protocol can easily detect 3451 this. It would be more accurate to say that the MITM attack is not 3452 merely detected, but thwarted. 3454 When adding the complexity of additional shared secrets beyond the 3455 familiar DH key agreement, we must make sure the lack of availability 3456 of the cached shared secret cannot prevent a call from going through, 3457 and we must also prevent false alarms that claim an attack was 3458 detected. 3460 An small added benefit of using these cached shared secrets to mix in 3461 with the session keys is that it augments the entropy of the session 3462 key. Even if limits on the size of the DH exchange produces a 3463 session key with less than 256 bits of real work factor, the added 3464 entropy from the cached shared secret can bring up all the subsequent 3465 session keys to the full 256-bit AES key strength, assuming no 3466 attacker was present in the first call. 3468 We could have authenticated the DH exchange the same way SSH does it, 3469 with digital signatures, caching public keys instead of shared 3470 secrets. But this approach with caching shared secrets seemed a bit 3471 simpler, requiring less CPU time for low-powered mobile platforms 3472 because it avoids an added digital signature step. 3474 The ZRTP SDP attributes convey information through the signaling that 3475 is already available in clear text through the media path. For 3476 example, the ZRTP flag is equivalent to sending a ZRTP Hello message. 3477 The SAS is calculated from a hash of material from ZRTP messages sent 3478 over the media path. As a result, none of the ZRTP SDP attributes 3479 require confidentiality from the signaling. 3481 The ZRTP SAS attributes can use the signaling channel as an out-of- 3482 band authentication mechanism. This authentication is only useful if 3483 the signaling channel has end-to-end integrity protection. Note that 3484 the SIP Identity header field [RFC4474] provides middle-to-end 3485 integrity protection across SDP message bodies which provides useful 3486 protection for ZRTP SAS attributes. 3488 16. Acknowledgments 3490 The authors would like to thank Bryce Wilcox-O'Hearn for his 3491 contributions to the design of this protocol, and to thank Jon 3492 Peterson, Colin Plumb, Hal Finney, Colin Perkins, and Dan Wing for 3493 their helpful comments and suggestions. Also thanks to David McGrew, 3494 Roni Even, Viktor Krikun, Werner Dittmann, Allen Pulsifer, Klaus 3495 Peters, and Abhishek Arya for their feedback and comments. 3497 The use of hash chains to key HMACs in ZRTP is similar to Adrian 3498 Perrig's TESLA protocol [TESLA]. 3500 17. References 3502 17.1. Normative References 3504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3505 Requirement Levels", BCP 14, RFC 2119, March 1997. 3507 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3508 Jacobson, "RTP: A Transport Protocol for Real-Time 3509 Applications", STD 64, RFC 3550, July 2003. 3511 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 3512 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 3513 RFC 3711, March 2004. 3515 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 3516 Diffie-Hellman groups for Internet Key Exchange (IKE)", 3517 RFC 3526, May 2003. 3519 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 3520 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 3521 September 2002. 3523 [SP800-90] 3524 Barker, E. and J. Kelsey, "Recommendation for Random 3525 Number Generation Using Deterministic Random Bit 3526 Generators", NIST Special Publication 800-90 (Revised) 3527 March 2007. 3529 [SP800-56A] 3530 Barker, E., Johnson, D., and M. Smid, "Recommendation for 3531 Pair-Wise Key Establishment Schemes Using Discrete 3532 Logarithm Cryptography", NIST Special Publication 800- 3533 56A Revision 1, March 2007. 3535 [NSA-Suite-B] 3536 "Fact Sheet NSA Suite B Cryptography", NSA Information 3537 Assurance Directorate Fact Sheet NSA Suite B. 3539 [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", 3540 RFC 4753, January 2007. 3542 [FIPS-186-3] 3543 "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3544 3 Draft, March 2006. 3546 [SP800-38A] 3547 Dworkin, M., "Recommendation for Block Cipher: Methods and 3548 Techniques", NIST Special Publication 800-38A 2001 3549 Edition. 3551 [z-base-32] 3552 Wilcox, B., "Human-oriented base-32 encoding", 3553 http://zooko.com/repos/z-base-32/base32/DESIGN . 3555 [pgpwordlist] 3556 "PGP Words", http://en.wikipedia.org/wiki/PGP_Words . 3558 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3559 Description Protocol", RFC 4566, July 2006. 3561 17.2. Informative References 3563 [I-D.ietf-sip-media-security-requirements] 3564 Wing, D., Fries, S., Tschofenig, H., and F. Audet, 3565 "Requirements and Analysis of Media Security Management 3566 Protocols", draft-ietf-sip-media-security-requirements-07 3567 (work in progress), June 2008. 3569 [Ferguson] 3570 Ferguson, N. and B. Schneier, "Practical Cryptography", 3571 Wiley Publishing 2003. 3573 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3574 Requirements for Security", BCP 106, RFC 4086, June 2005. 3576 [base256] Juola, P. and P. Zimmermann, "Whole-Word Phonetic 3577 Distances and the PGPfone Alphabet", Proceedings of the 3578 International Conference of Spoken Language Processing 3579 (ICSLP-96) . 3581 [pgpfone] Zimmermann, P., "PGPfone", 3582 http://philzimmermann.com/docs/pgpfone10b7.pdf . 3584 [zfone] Zimmermann, P., "Zfone", 3585 http://www.philzimmermann.com/zfone . 3587 [Byzantine] 3588 "The Two Generals' Problem", 3589 http://en.wikipedia.org/wiki/Two_Generals%27_Problem . 3591 [TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The 3592 TESLA Broadcast Authentication Protocol", http:// 3593 www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ 3594 tesla-cryptobytes.pdf . 3596 [comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices 3597 Version 1.2", http://www.comsec.com/vp1-protocol.pdf . 3599 [cryptophone] 3600 "CryptoPhone", http://www.cryptophone.de/ . 3602 [I-D.ietf-avt-srtp-big-aes] 3603 McGrew, D., "The use of AES-192 and AES-256 in Secure 3604 RTP", http://www1.tools.ietf.org/html/ 3605 draft-ietf-avt-srtp-big-aes . 3607 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3608 A., Peterson, J., Sparks, R., Handley, M., and E. 3609 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3610 June 2002. 3612 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 3613 Protocol Architecture", RFC 4251, January 2006. 3615 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3616 Description Protocol (SDP) Security Descriptions for Media 3617 Streams", RFC 4568, July 2006. 3619 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 3620 Carrara, "Key Management Extensions for Session 3621 Description Protocol (SDP) and Real Time Streaming 3622 Protocol (RTSP)", RFC 4567, July 2006. 3624 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 3625 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 3626 August 2004. 3628 [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", 3629 RFC 3514, April 1 2003. 3631 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 3632 Authenticated Identity Management in the Session 3633 Initiation Protocol (SIP)", RFC 4474, August 2006. 3635 [I-D.ietf-mmusic-ice] 3636 Rosenberg, J., "Interactive Connectivity Establishment 3637 (ICE): A Protocol for Network Address Translator (NAT) 3638 Traversal for Offer/Answer Protocols", 3639 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 3641 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 3642 (SIP) Call Control - Conferencing for User Agents", 3643 BCP 119, RFC 4579, August 2006. 3645 [I-D.wing-sip-identity-media] 3646 Wing, D. and H. Kaplan, "SIP Identity using Media Path", 3647 draft-wing-sip-identity-media-02 (work in progress), 3648 February 2008. 3650 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 3651 E.164 numbers with the Session Initiation Protocol (SIP)", 3652 RFC 3824, June 2004. 3654 [I-D.ietf-avt-dtls-srtp] 3655 McGrew, D. and E. Rescorla, "Datagram Transport Layer 3656 Security (DTLS) Extension to Establish Keys for Secure 3657 Real-time Transport Protocol (SRTP)", 3658 draft-ietf-avt-dtls-srtp-02 (work in progress), 3659 February 2008. 3661 Authors' Addresses 3663 Philip Zimmermann 3664 Zfone Project 3666 Email: prz@mit.edu 3668 Alan Johnston (editor) 3669 Avaya 3670 St. Louis, MO 63124 3672 Email: alan@sipstation.com 3674 Jon Callas 3675 PGP Corporation 3677 Email: jon@pgp.com 3679 Full Copyright Statement 3681 Copyright (C) The IETF Trust (2008). 3683 This document is subject to the rights, licenses and restrictions 3684 contained in BCP 78, and except as set forth therein, the authors 3685 retain all their rights. 3687 This document and the information contained herein are provided on an 3688 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3689 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3690 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3691 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3692 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3693 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3695 Intellectual Property 3697 The IETF takes no position regarding the validity or scope of any 3698 Intellectual Property Rights or other rights that might be claimed to 3699 pertain to the implementation or use of the technology described in 3700 this document or the extent to which any license under such rights 3701 might or might not be available; nor does it represent that it has 3702 made any independent effort to identify any such rights. Information 3703 on the procedures with respect to rights in RFC documents can be 3704 found in BCP 78 and BCP 79. 3706 Copies of IPR disclosures made to the IETF Secretariat and any 3707 assurances of licenses to be made available, or the result of an 3708 attempt made to obtain a general license or permission for the use of 3709 such proprietary rights by implementers or users of this 3710 specification can be obtained from the IETF on-line IPR repository at 3711 http://www.ietf.org/ipr. 3713 The IETF invites any interested party to bring to its attention any 3714 copyrights, patents or patent applications, or other proprietary 3715 rights that may cover technology that may be required to implement 3716 this standard. Please address the information to the IETF at 3717 ietf-ipr@ietf.org.