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