idnits 2.17.1 draft-zimmermann-avt-zrtp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2402. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6263 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'SHA-256' on line 1069 == Unused Reference: '5' is defined on line 2269, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-mcgrew-srtp-big-aes-00 ** Obsolete normative reference: RFC 3309 (ref. '6') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 4566 (ref. '10') (Obsoleted by RFC 8866) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-05) exists of draft-wing-media-security-requirements-00 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '23') (Obsoleted by RFC 8224) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-13 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTPSEC P. Zimmermann 3 Internet-Draft Zfone Project 4 Intended status: Standards Track A. Johnston, Ed. 5 Expires: September 5, 2007 Avaya 6 J. Callas 7 PGP Corporation 8 March 4, 2007 10 ZRTP: Media Path Key Agreement for Secure RTP 11 draft-zimmermann-avt-zrtp-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 5, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document defines ZRTP, a protocol for media path Diffie-Hellman 45 exchange to agree on a session key and parameters for establishing 46 Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP 47 protocol is media path keying because it is multiplexed on the same 48 port as RTP and does not require support in the signaling protocol. 50 ZRTP does not assume a Public Key Infrastructure (PKI) infrastructure 51 or require the complexity of certificates in end devices. For the 52 media session, ZRTP provides confidentiality, protection against Man 53 in the Middle (MITM) attacks, and, in cases where a secret is 54 available from the signaling protocol, authentication. ZRTP can 55 utilize two Session Description Protocol (SDP) attributes to provide 56 discovery and authentication through the signaling channel. To 57 provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Media Security Requirements . . . . . . . . . . . . . . . . . 5 64 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Key Agreement Modes . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . 7 67 4.1.2. Preshared Mode . . . . . . . . . . . . . . . . . . . . 9 68 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. Commit Contention Resolution . . . . . . . . . . . . . . . 10 71 5.3. Shared Secret Determination . . . . . . . . . . . . . . . 11 72 5.3.1. Responder Behavior . . . . . . . . . . . . . . . . . . 11 73 5.3.2. Initiator Behavior . . . . . . . . . . . . . . . . . . 12 74 5.4. Diffie-Hellman Mode . . . . . . . . . . . . . . . . . . . 12 75 5.4.1. Hash Commitment . . . . . . . . . . . . . . . . . . . 13 76 5.4.2. Responder Behavior . . . . . . . . . . . . . . . . . . 13 77 5.4.3. Initiator Behavior . . . . . . . . . . . . . . . . . . 14 78 5.4.4. Shared Secret Calculation . . . . . . . . . . . . . . 14 79 5.5. Preshared Mode . . . . . . . . . . . . . . . . . . . . . . 15 80 5.5.1. Commit . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.5.2. Responder Behavior . . . . . . . . . . . . . . . . . . 16 82 5.5.3. Initiator Behavior . . . . . . . . . . . . . . . . . . 16 83 5.5.4. Shared Secret Calculation . . . . . . . . . . . . . . 16 84 5.6. Key Generation . . . . . . . . . . . . . . . . . . . . . . 17 85 5.7. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.8. Random Number Generation . . . . . . . . . . . . . . . . . 18 87 5.9. ZID and Cache Operation . . . . . . . . . . . . . . . . . 19 88 5.10. Terminating an SRTP Session or ZRTP Exchange . . . . . . . 20 89 6. ZRTP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21 90 6.1. ZRTP Message Formats . . . . . . . . . . . . . . . . . . . 22 91 6.1.1. Message Type Block . . . . . . . . . . . . . . . . . . 23 92 6.1.2. Hash Type Block . . . . . . . . . . . . . . . . . . . 24 93 6.1.3. Cipher Type Block . . . . . . . . . . . . . . . . . . 24 94 6.1.4. Auth Tag Block . . . . . . . . . . . . . . . . . . . . 24 95 6.1.5. Key Agreement Type Block . . . . . . . . . . . . . . . 25 96 6.1.6. SAS Type Block . . . . . . . . . . . . . . . . . . . . 25 97 6.1.7. Signature Block . . . . . . . . . . . . . . . . . . . 26 98 6.2. Hello message . . . . . . . . . . . . . . . . . . . . . . 26 99 6.3. HelloACK message . . . . . . . . . . . . . . . . . . . . . 27 100 6.4. Commit message . . . . . . . . . . . . . . . . . . . . . . 28 101 6.5. DHPart1 message . . . . . . . . . . . . . . . . . . . . . 29 102 6.6. DHPart2 message . . . . . . . . . . . . . . . . . . . . . 30 103 6.7. Confirm1 and Confirm2 messages . . . . . . . . . . . . . . 31 104 6.8. Conf2ACK message . . . . . . . . . . . . . . . . . . . . . 33 105 6.9. GoClear message . . . . . . . . . . . . . . . . . . . . . 34 106 6.10. ClearACK message . . . . . . . . . . . . . . . . . . . . . 34 107 7. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 35 108 8. Short Authentication String . . . . . . . . . . . . . . . . . 36 109 8.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 37 110 8.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 38 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 113 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 114 12. Appendix A - Signaling Interactions . . . . . . . . . . . . . 43 115 13. Appendix B - The ZRTP Disclosure flag . . . . . . . . . . . . 46 116 14. Appendix C - Intermediary ZRTP Devices . . . . . . . . . . . . 48 117 15. Appendix D - RTP Header Extension Flag for ZRTP . . . . . . . 49 118 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 119 16.1. Normative References . . . . . . . . . . . . . . . . . . . 50 120 16.2. Informative References . . . . . . . . . . . . . . . . . . 51 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 122 Intellectual Property and Copyright Statements . . . . . . . . . . 53 124 1. Introduction 126 ZRTP is a key agreement protocol which performs Diffie-Hellman key 127 exchange during call setup in the media path, and is transported over 128 the same port as the Real-time Transport Protocol (RTP) [2] media 129 stream which has been established using a signaling protocol such as 130 Session Initiation Protocol (SIP) [17]. This generates a shared 131 secret which is then used to generate keys and salt for a Secure RTP 132 (SRTP) [3] session. ZRTP borrows ideas from PGPfone [13]. A 133 reference implementation of ZRTP is available as Zfone [14]. 135 The ZRTP protocol has some nice cryptographic features lacking in 136 many other approaches to media session encryption. Although it uses 137 a public key algorithm, it does not rely on a public key 138 infrastructure (PKI). In fact, it does not use persistent public 139 keys at all. It uses ephemeral Diffie-Hellman (DH) with hash 140 commitment, and allows the detection of Man in the Middle (MITM) 141 attacks by displaying a short authentication string for the users to 142 read and compare over the phone. It has perfect forward secrecy, 143 meaning the keys are destroyed at the end of the call, which 144 precludes retroactively compromising the call by future disclosures 145 of key material. But even if the users are too lazy to bother with 146 short authentication strings, we still get reasonable authentication 147 against a MITM attack, based on a form of key continuity. It does 148 this by caching some key material to use in the next call, to be 149 mixed in with the next call's DH shared secret, giving it key 150 continuity properties analogous to SSH. All this is done without 151 reliance on a PKI, key certification, trust models, certificate 152 authorities, or key management complexity that bedevils the email 153 encryption world. It also does not rely on SIP signaling for the key 154 management, and in fact does not rely on any servers at all. It 155 performs its key agreements and key management in a purely peer-to- 156 peer manner over the RTP packet stream. 158 If the endpoints have a mechanism for knowing or retrieving the other 159 endpoint's signature key, the short authentication string can be 160 authenticated by exchanging a signature over the short authentication 161 string. 163 ZRTP can be used and discovered without being declared or indicated 164 in the signaling path. This provides the a best effort SRTP 165 capability. Also, this reduces the complexity of implementations and 166 minimizes interdependency between the signaling and media layers. 167 When ZRTP is indicated in the signaling and the SDP attribute 168 extensions are used, ZRTP has additional useful properties. When the 169 signaling path has end-to-end integrity protection, the short 170 authentication string can be compared automatically by the ZRTP 171 endpoints. By sending a unique ZRTP Identifier (ZID) in the 172 signaling, ZRTP provides a useful binding between the signaling and 173 media paths. 175 The following sections provide an overview of the ZRTP protocol, 176 describe the key agreement algorithm and RTP message formats. 178 2. Terminology 180 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 181 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 182 and "OPTIONAL" are to be interpreted as described in RFC 2119 and 183 indicate requirement levels for compliant implementations [1]. 185 3. Media Security Requirements 187 This section discuses how ZRTP meets all ten RTP security 188 requirements discussed in Section 4 of [12]. 190 Since ZRTP is a media path key agreement approach, it meets the 191 following requirements: 193 R1: Forking and retargeting MUST work with all end-points being SRTP. 195 R2: Forking and retargeting MUST allow establishing SRTP or RTP with 196 a mixture of SRTP- and RTP-capable targets. 198 R3: With forking, only the entity to which the call is finally 199 established, MUST get hold of the media encryption keys. 201 Note: R4 is not present in [12]. 203 R5: A solution SHOULD avoid clipping media before SDP answer without 204 additional signalling. 206 ZRTP's use of Diffie-Hellman key agreement allows it to meet these 207 requirements: 209 R6: A solution MUST provide protection against passive attacks. 211 R7: A solution MUST be able to support Perfect Forward Secrecy. 213 ZRTPs meet the following requirements with its handling of algorithm 214 lists: 216 R8: A solution MUST support algorithm negotiation without incurring 217 per-algorithm computational expense. 219 R9: A solution MUST support multiple cipher suites without additional 220 computational expense. 222 The use of the a=zrtp-zid allows ZRTP to meet this requirement: 224 R10: Endpoint identification when forking. 226 The use of the optional signature block in the Confirm1 and Confirm2 227 messages allows ZRTP to meet this requirement: 229 R11: A solution MUST NOT require 3rd-party certs. If two parties 230 share an auth infrastructure they should be able to use it. 232 4. Overview 234 This section provides a description of how ZRTP works. This 235 description is non-normative in nature but is included to build 236 understanding of the protocol. 238 ZRTP is negotiated the same way a conventional RTP session is 239 negotiated in an offer/answer exchange using the standard AVP/RTP 240 profile. The ZRTP protocol begins after two endpoints have utilized 241 a signaling protocol such as SIP and are ready to send. If ICE [24] 242 is being used, ZRTP begins after ICE has completed its connectivity 243 checks. 245 ZRTP is multiplexed on the same ports as RTP. It uses a unique 246 header that makes it clearly differentiable from RTP or STUN. 248 In environments in which sending ZRTP packets to non-ZRTP endpoints 249 might cause problems and signaling path discovery is not an option, 250 ZRTP endpoints can include the RTP header extension flag in normal 251 RTP packets sent at the start of a session as a probe to discover if 252 the other endpoint supports ZRTP. If the flag is received from the 253 other endpoint, ZRTP messages can then be exchanged. 255 A ZRTP endpoint initiates the exchange by sending a ZRTP Hello 256 message to the other endpoint. The purpose of the Hello message is 257 to confirm the endpoint supports the protocol and to see what 258 algorithms the two ZRTP endpoints have in common. 260 The Hello message contains the SRTP configuration options, and the 261 ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID 262 that is generated once at installation time. ZIDs are discovered 263 during the Hello message exchange. The received ZID is used to look 264 up retained shared secrets from previous ZRTP sessions with the 265 endpoint. 267 A response to a ZRTP Hello message is a ZRTP HelloACK message. The 268 HelloACK message simply acknowledges receipt of the Hello. Since RTP 269 commonly uses best effort UDP transport, ZRTP has retransmission 270 timers in case of lost datagrams. There are two timers, both with 271 exponential backoff mechanisms. One timer is used for 272 retransmissions of Hello messages and the other is used for 273 retransmissions of all other messages after receipt of a HelloACK. 275 4.1. Key Agreement Modes 277 After both endpoints exchange Hello and HelloACK messages, the key 278 agreement exchange can begin with the ZRTP Commit message. ZRTP 279 supports a number of key agreement modes including both Diffie- 280 Hellman and non-Diffie-Hellman modes as described in the following 281 sections. 283 4.1.1. Diffie-Hellman Mode 285 An example ZRTP call flow is shown in Figure 1 below. Note that the 286 order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be 287 reversed. That is, either Alice or Bob might send the first Hello 288 message. Also, an endpoint that receives a Hello message and wishes 289 to immediately begin the ZRTP key agreement can omit the HelloACK and 290 send the Commit instead. In Figure 1, this would result in messages 291 F2, F3, and F4 being omitted. Note that the endpoint which sends the 292 Commit message is considered the initiator of the ZRTP session and 293 drives the key agreement exchange. The Diffie-Hellman public values 294 are exchanged in the DHPart1 and DHPart2 messages. SRTP keys and 295 salts are then calculated. 297 Alice Bob 298 | | 299 | Alice and Bob establish a media session.| 300 | They initiate ZRTP on media ports | 301 | | 302 | Hello (version, options, Alice's ZID) F1| 303 |---------------------------------------->| 304 | HelloACK F2 | 305 |<----------------------------------------| 306 | Hello (version, options, Bob's ZID) F3 | 307 |<----------------------------------------| 308 | HelloACK F4 | 309 |---------------------------------------->| 310 | | 311 | Bob acts as the initiator | 312 | | 313 | Commit (Bob's ZID, options, hvi or nonce) F5 314 |<----------------------------------------| 315 | DHPart1 (pvr or nonce, shared secret hashes) F6 316 |---------------------------------------->| 317 | DHPart2 (pvi, shared secret hashes) F7 | 318 |<----------------------------------------| 319 | | 320 | Alice and Bob generate SRTP session key.| 321 | | 322 | SRTP begins | 323 |<=======================================>| 324 | | 325 | Confirm1 (HMAC, CFB IV, D,S,V flags, sig) F8 326 |---------------------------------------->| 327 | Confirm2 (HMAC, CFB IV, D,S,V flags, sig) F9 328 |<----------------------------------------| 329 | Confirm2AK F10 | 330 |---------------------------------------->| 332 Figure 1. Establishment of an SRTP session using ZRTP 334 ZRTP authentication uses a Short Authentication String (SAS) which is 335 ideally displayed for the human user. Alternatively, the SAS can be 336 transported over the signaling channel in the SDP and compared 337 automatically, provided the signaling has end-to-end integrity 338 protection. Or, the SAS can be authenticated by exchanging a digital 339 signature (sig) over the short authentication string in the Confirm1 340 or Confirm2 messages. 342 The ZRTP Confirm1 and Confirm2 messages are sent for a number of 343 reasons. First, they confirm that all the key agreement calculations 344 were successful and thus the encryption will work, and they enable 345 automatic detection of a DH MITM attack from a reckless attacker who 346 does not know the retained shared secret. Digital signatures over 347 the SAS can be exchanged to authenticate the exchange. And, they 348 enable ZRTP to transmit some parameters under cover of CFB 349 encryption, such as the Disclosure flag (D), the Allow Clear flag 350 (A), and most importantly the SAS Verified flag (V SAS Verified flag 351 (V), shielding it from a passive observer who would like to know if 352 the human users are in the habit of diligently verifying the SAS. 354 4.1.2. Preshared Mode 356 In the Preshared Mode, endpoints can skip the DH calculation if they 357 have a shared secret from a previous ZRTP session. Preshared mode is 358 indicated in the Commit message and results in the same call flow as 359 Figure 1. The DHPart1 and DHPart2 messages are exchanged so that the 360 set of shared secrets can be determined, but the pvr and pvi are 361 omitted and no DH calculation is performed. Instead nonces from the 362 Commit and DHPart1 are exchanged and used along with the retained 363 secrets to derive the key material. This mode could be useful for 364 slow processor endpoints so that a DH calculation does not need to be 365 performed every session. Or, this mode could be used to rapidly re- 366 establish an earlier session that was recently torn down or 367 interrupted without the need to perform another DH calculation. 368 Since the cache is not affected during this mode, multiple Preshared 369 mode exchanges can be processed at a time between two endpoints. 371 5. Protocol Description 373 ZRTP MUST be multiplexed on the same ports as the RTP media packets. 375 To support best effort encryption [12], ZRTP uses normal RTP/AVP 376 profile (AVP) media lines in the initial offer/answer exchange. The 377 ZRTP SDP attribute flag a=zrtp-id defined in Appendix A SHOULD be 378 used in all offers and answers to indicate support for the ZRTP 379 protocol. In subsequent offer/answer exchanges after a successful 380 ZRTP exchange has resulted in an SRTP session, the Secure RTP/AVP 381 (SAVP) profile MAY be used. 383 5.1. Discovery 385 During the ZRTP discovery phase, a ZRTP endpoint discovers if the 386 other endpoint supports ZRTP and the supported algorithms and 387 options. This information is transported in a Hello message. 389 ZRTP endpoints SHOULD include the SDP attribute a=zrtp-zid in offers 390 and answers, as defined in Appendix A. ZRTP MAY use an RTP [2] 391 extension field as a flag to indicate support for the ZRTP protocol 392 in RTP packets as described in Appendix D. 394 The Hello message includes the ZRTP version, hash, cipher, 395 authentication method and tag length, key agreement type, and Short 396 Authentication String (SAS) algorithms that are supported. In 397 addition, each endpoint sends and discovers ZIDs. The received ZID 398 is used to retrieve previous retained shared secrets, rs1 and rs2. 399 If the endpoint has other secrets, then they are also collected. 400 Details on how to derive the signaling secret, sigs, and SRTP secret, 401 srtps, are in Appendix A. 403 Additional shared secrets can be defined and used as other_secret. 404 If no secret of a given type is available, a random value is 405 generated and used for that secret to ensure a mismatch in the hash 406 comparisons in the DHPart1 and DHPart2 messages. This prevents an 407 eavesdropper from knowing how many shared secrets are available 408 between the endpoints. 410 A Hello message can be sent at any time, but is usually sent at the 411 start of an RTP session to determine if the other endpoint supports 412 ZRTP, and also if the SRTP implementations are compatible. A Hello 413 message is retransmitted using timer T1 and an exponential backoff 414 mechanism detailed in Section 7 until the receipt of a HelloACK 415 message or a Commit message. 417 5.2. Commit Contention Resolution 419 After receiving a Hello message from the other endpoint, a Commit 420 message can be sent to begin the ZRTP key exchange. The endpoint 421 that sends the Commit is known as the initiator, while the receiver 422 of the Commit is known as the responder. 424 If both sides send Commit messages initiating a secure session at the 425 same time, the Commit message with the lowest hvi value is discarded 426 and the other side is the initiator. This breaks the tie, allowing 427 the protocol to proceed from this point with a clear definition of 428 who is the initiator and who is the responder. 430 Because the DH exchange affects the state of the retained shared 431 secret cache, only one in-process ZRTP DH exchange may occur at a 432 time between two ZRTP endpoints. Otherwise, race conditions and 433 cache integrity problems will result. When multiple media streams 434 are established in parallel between the same pair of ZRTP endpoints 435 (determined by the ZIDs in the Hello Messages), only one can be 436 processed. Once that exchange completes with Confirm2 and Conf2ACK 437 messages, another ZRTP DH exchange can begin. In the event that 438 Commit messages are sent by both ZRTP endpoints at the same time, but 439 are received in different media streams, the same resolution rules 440 apply - the Commit message with the lowest hvi value is discarded and 441 the other side is the initiator. The media stream in which the 442 Commit was sent will proceed through the ZRTP exchange while the 443 media stream with the discarded Commit must wait for the completion 444 of the other ZRTP exchange. 446 5.3. Shared Secret Determination 448 The following sections describe how ZRTP endpoints generate the set 449 of shared secrets s1, s2, s3, s4, and s5 through the exchange of the 450 DHPart1 and DHPart2 messages. 452 5.3.1. Responder Behavior 454 The responder calculates an HMAC keyed hash using the first retained 455 shared secret, rs1, as the key on the string "Responder" which 456 generates a retained secret ID, rs1IDr, which is truncated to 64 457 bits. HMACs are calculated in a similar way for additional shared 458 secrets: 460 rs1IDr = HMAC(rs1, "Responder") 462 rs2IDr = HMAC(rs2, "Responder") 464 sigsIDr = HMAC(sigs, "Responder") 466 srtpsIDr = HMAC(srtps, "Responder") 468 other_secretIDr = HMAC(other_secret, "Responder") 470 The set of keyed hashes (HMACs) are included by the responder in the 471 DHPart1 message. 473 The HMACs of the possible shared secrets received in the DHPart2 can 474 be compared against the HMACs of the local set of possible shared 475 secrets. 477 The expected HMAC values of the shared secrets are calculated (using 478 the string "Initiator" instead of "Responder") as in Section 5.2.2 479 and compared to the HMACs received in the DHPart2 message. The 480 secrets corresponding to matching HMACs are kept while the secrets 481 corresponding to the non-matching ones are replaced with a null, 482 which is assumed to have a zero length for the purposes of hashing 483 them later. The set of up to five actual shared secrets are then s1, 484 s2, s3, s4, and s5 - the order is that chosen by the initiator. 486 5.3.2. Initiator Behavior 488 The initiator calculates an HMAC keyed hash using the first retained 489 shared secret, rs1, as the key on the string "Initiator" which 490 generates a retained secret ID, rs1IDi, which is truncated to 64 491 bits. HMACs are calculated in a similar way for additional shared 492 secrets: 494 rs1IDi = HMAC(rs1, "Initiator") 496 rs2IDi = HMAC(rs2, "Initiator") 498 sigsIDi = HMAC(sigs, "Initiator") 500 srtpsIDi = HMAC(srtps, "Initiator") 502 other_secretIDi = HMAC(other_secret, "Initiator") 504 These HMACs are included by the initiator in the DHPart2 message. 506 The initiator then calculates the set of secret IDs that are expected 507 to be received from the responder in the DHPart1 message by 508 substituting the string "Responder" instead of "Initiator" as in 509 Section 5.3.1. 511 The HMACs of the possible shared secrets received are compared 512 against the HMACs of the local set of possible shared secrets. 514 The secrets corresponding to matching HMACs are kept while the 515 secrets corresponding to the non-matching ones are replaced with a 516 null, which is assumed to have a zero length for the purposes of 517 hashing them later. The set of up to five actual shared secrets are 518 then s1, s2, s3, s4, and s5 - the order is that chosen by the 519 initiator. 521 For example, consider two ZRTP endpoints who share secrets rs1, rs2, 522 and a hash of a secret passphrase other_secret. During the 523 comparison, rs1ID, rs2ID, and other_secretID will match but sigsID 524 and srtpsID will not. As a result, s1 = rs1, s2 = rs2, s5 = 525 other_secret, while s3 and s4 will be nulls. 527 5.4. Diffie-Hellman Mode 529 The purpose of the Diffie-Hellman exchange is for the two ZRTP 530 endpoints to generate a new shared secret, s0. In addition, the 531 endpoints discover if they have any shared secrets in common. If 532 they do, this exchange allows them to discover how many and agree on 533 an ordering for them: s1, s2, etc. 535 5.4.1. Hash Commitment 537 From the intersection of the algorithms in the sent and received 538 Hello messages, the initiator chooses a hash, cipher, auth tag, key 539 agreement type, and SAS type to be used. 541 A Diffie-Hellman mode is selected by setting the Key Agreement Type 542 to DH4k or DH3k in the Commit. In this mode, the key agreement 543 begins with the initiator choosing a fresh random Diffie-Hellman (DH) 544 secret value (svi) based on the chosen key agreement type value, and 545 computing the public value. (Note that to speed up processing, this 546 computation can be done in advance.) For guidance on generating 547 random numbers, see the section on Random Number Generation. The 548 Diffie-Hellman secret value, svi, SHOULD be twice as long as the AES 549 key length. This means, if AES 128 is used, the DH secret value 550 SHOULD be 256 bits long. If AES 256 is used, the secret value SHOULD 551 be 512 bits long. 553 pvi = g^svi mod p 555 where g and p are determined by the key agreement type value. The 556 hash commitment is performed by the initiator of the ZRTP exchange. 557 The hash value of the initiator, hvi, includes a hash of the Diffie- 558 Hellman public value, pvi, and the responder's Hello message: 560 hvi=hash(pvi | responder's Hello message) 562 Note that the Hello message includes the fields shown in Figure 3. 564 The information from the responder's Hello message is included in the 565 hash calculation to prevent a bid-down attack by modification of the 566 responder's Hello message. 568 The initiator sends hvi in the Commit message. 570 5.4.2. Responder Behavior 572 Upon receipt of the Commit message, the responder generates its own 573 fresh random DH secret value, svr, and computes the public value. 574 (Note that to speed up processing, this computation can be done in 575 advance.) For guidance on random number generation, see the section 576 on Random Number Generation. The Diffie-Hellman secret value, svr, 577 SHOULD be twice as long as the AES key length. This means, if AES 578 128 is used, the DH secret value SHOULD be 256 bits long. If AES 256 579 is used, the secret value SHOULD be 512 bits long. 581 pvr = g^svr mod p 582 Upon receipt of the DHPart2 message, the responder checks that the 583 initiator's public DH value is not equal to 1 or p-1. An attacker 584 might inject a false DHPart2 packet with a value of 1 or p-1 for 585 g^svi mod p, which would cause a disastrously weak final DH result to 586 be computed. If pvi is 1 or p-1, the user should be alerted of the 587 attack and the protocol exchange must be terminated. Otherwise, the 588 responder computes its own value for the hash commitment using the 589 public DH value (pvi) received in the DHPart2 packet and its Hello 590 packet and compares the result with the hvi received in the Commit 591 packet. If they are different, a MITM attack is taking place and the 592 user is alerted and the protocol exchange terminated. 594 The responder then calculates the Diffie-Hellman result: 596 DHResult = pvi^svr mod p 598 5.4.3. Initiator Behavior 600 Upon receipt of the DHPart1 message, the initiator checks that the 601 responder's public DH value is not equal to 1 or p-1. An attacker 602 might inject a false DHPart1 packet with a value of 1 or p-1 for 603 g^svr mod p, which would cause a disastrously weak final DH result to 604 be computed. If pvr is 1 or p-1, the user should be alerted of the 605 attack and the protocol exchange must be terminated. 607 The initiator then sends a DHPart2 message containing the initiator's 608 public DH value and the set of calculated retained secret IDs as 609 described in 5.2.2. 611 The initiator calculates the same Diffie-Hellman result using: 613 DHResult = pvr^svi mod p 615 5.4.4. Shared Secret Calculation 617 The responder and initiator calculate the Diffie-Hellman shared 618 secret: 620 DHSS = hash(DHResult) 622 A hash of the received and sent ZRTP messages in the current ZRTP 623 exchange in the following order is calculated: 625 message_hash = hash (Hello of responder | Commit | DHPart1 | DHPart2 626 ) 628 Note that only the ZRTP message (Figures 3, 5, 6, and 7), not the 629 entire ZRTP packets are included in the hash. 631 The final shared secret, s0, is calculated by hashing the 632 concatenation of the DHSS and the set of non-null shared secrets as 633 described in 5.2 and the message hash. As a result, the null secrets 634 have no effect on the concatenation operation: 636 s0 = hash(DHSS | s1 | s2 | s3 | s4 | s5 | message_hash) 638 A new rs1 is calculated from s0: 640 rs1 = HMAC (s0, "retained secret") 642 After a successful exchange of Confirm1 and Confirm2 messaged 643 described in Section 5.6, both sides now discard the rs2 value and 644 store rs1 as rs2. 646 5.5. Preshared Mode 648 The Preshared key agreement mode can be used to generate SRTP keys 649 and salts without a DH calculation, instead relying on one or more 650 shared secrets from previous DH calculations between the endpoints. 652 This key agreement mode is useful for efficiently adding another 653 media stream to an existing secure session, such as adding video to a 654 session that already has performed a DH key agreement for the audio 655 stream. It can also be used to rapidly re-establish a secure session 656 between two parties who have recently started and ended a secure 657 session that has already performed a DH key agreement, without 658 performing another lengthy DH calculation, which may be desirable on 659 slow processors in resource-limited environments. 661 5.5.1. Commit 663 This mode is selected by setting the Key Agreement Type to Preshared 664 in the Commit message. From the intersection of the algorithms in 665 the sent and received Hello messages, the initiator chooses a hash, 666 cipher, auth tag, key agreement type, and SAS type to be used. In 667 place of hvi in the Commit, a random number, nonce, 32 octets long is 668 chosen. Its value MUST be unique for all nonce values chosen for all 669 ZRTP sessions between a pair of endpoints since the last DH exchange. 670 If a Commit is received with a reused nonce value, the ZRTP exchange 671 SHOULD be immediately terminated. (We would say MUST be terminated, 672 but we recognize it may be hard to determine if the nonce was never 673 used before. In practical terms, a random nonce of this length has 674 effectively no chance of repeating by accident.) 676 Note: Since nonces are used to calculate different SRTP key and salt 677 pairs for each media session, a reuse of a nonce may result in the 678 same key and salt being generated for multiple streams which would 679 introduce a major security weakness. 681 The DHPart1 and DHPart2 messages are exchanged in this mode so that 682 the shared secrets can be determined. If it is determined that the 683 endpoints have no shared DH secrets (i.e. either rs1 or rs2) the 684 exchange MUST be terminated. It is RECOMMENDED that Preshared mode 685 only be used when the SAS Verified flag is set. 687 5.5.2. Responder Behavior 689 In in place of pvr in the DHPart1, a random number, noncer, 32 octets 690 long is chosen. Its value MUST be unique for all nonce values chosen 691 for all ZRTP sessions between a pair of endpoints since the last DH 692 exchange. If a DHPart1 is received with a reused nonce value, the 693 ZRTP exchange SHOULD be immediately terminated. (We would say MUST 694 be terminated, but we recognize it may be hard to determine if the 695 nonce was never used before. In practical terms, a random nonce of 696 this length has effectively no chance of repeating by accident.) 698 5.5.3. Initiator Behavior 700 Since no DH calculation is performed, no pvr is sent in the DHPart2 701 messages. 703 5.5.4. Shared Secret Calculation 705 A hash of the received and sent ZRTP messages in the current ZRTP 706 exchange in the following order is calculated: 708 message_hash = hash (Hello of responder | Commit | DHPart1 | DHPart2 709 ) 711 Note that only the ZRTP message (Figures 3, 5, 6, and 7), not the 712 entire ZRTP packets are included in the hash. 714 The final shared secret, s0, is calculated by hashing the 715 concatenation of the set of non-null shared secrets as described in 716 5.3, and the message_hash. 718 s0 = hash(s1 | s2 | s3 | s4 | s5 | message_hash ) 720 The noncei and noncer are implicitly included in the hash because 721 they were included in the message hash. 723 No new retained shared secret is derived, and the values of rs1 and 724 rs2 are unchanged during this mode. 726 5.6. Key Generation 728 The SRTP master key and master salt are then generated using the 729 shared secret. Separate SRTP keys and salts are used in each 730 direction for each media stream. Unless otherwise specified, ZRTP 731 uses SRTP with no MKI, 32 bit authentication using HMAC-SHA1, AES-CM 732 128 or 256 bit key length, 112 bit session salt key length, 2^48 key 733 derivation rate, and SRTP prefix length 0. 735 The ZRTP initiator encrypts and the ZRTP responder decrypts packets 736 by using srtpkeyi and srtpsalti, which are generated by: 738 srtpkeyi = HMAC(s0,"Initiator SRTP master key") 740 srtpsalti = HMAC(s0,"Initiator SRTP master salt") 742 The key and salt values are truncated to the length determined by the 743 chosen SRTP algorithm. The ZRTP responder encrypts and the ZRTP 744 initiator decrypts packets by using srtpkeyr and srtpsaltr, which are 745 generated by: 747 srtpkeyr = HMAC(s0,"Responder SRTP master key") 749 srtpsaltr = HMAC(s0,"Responder SRTP master salt") 751 The HMAC keys are generated by: 753 hmackeyi = HMAC(s0,"Initiator HMAC key") 755 hmackeyr = HMAC(s0,"Responder HMAC key") 757 Note that these HMAC keys are used only by ZRTP and not by SRTP. 759 Note: Different HMAC keys are needed for the initiator and the 760 responder to ensure that GoClear messages in each direction are 761 unique and can not be cached by an attacker and reflected back to the 762 endpoint. 764 ZRTP keys are generated for the initiator and responder to use to 765 encrypt the Confirm1 and Confirm2 messages. 767 zrtpkeyi = HMAC(s0,"Initiator ZRTP key") 769 srtpkeyr = HMAC(s0,"Responder ZRTP key") 771 The Short Authentication String (SAS) value is calculated as the hash 772 of the ZRTP messages exchanged during the session: Hello from the 773 responder, Commit, DHPart1, and DHPart2: 775 sasvalue = last 64 bits of message_hash 777 Note: The SAS calculated this way provides both protection against a 778 bid down attack (modification of the Hello messages) or an active 779 MiTM attack. Either attack will result in each endpoint calculating 780 different sasvalues. 782 5.7. Confirmation 784 The Confirm1 and Confirm2 messages contain the cache expiration 785 interval for the newly generated retained shared secret. The 786 flagoctet is an 8 bit unsigned integer made up of the Disclosure flag 787 (D), Allow clear flag (A), SAS Verified flag (V): 789 flagoctet = V * 2^2 + A * 2^1 + D * 2^0 791 Part of the Confirm1 and Confirm2 messages are encrypted using full- 792 block Cipher Feedback Mode, and contain a 128-bit random CFB 793 Initialization Vector (IV). The Confirm1 and Confirm2 messages also 794 contain an HMAC covering the encrypted part of the Confirm1 or 795 Confirm2 message which includes a string of zeros, the signature 796 length, flag octet, cache expiration interval, signature type block 797 (if present) and signature block (if present). For the responder 799 hmac = HMAC(hmackeyr, encrypted part of Confirm1) 801 For the initiator: 803 hmac = HMAC(hmackeyi, encrypted part of Confirm2 message) 805 The Conf2ACK message sent by the responder completes the exchange. 807 5.8. Random Number Generation 809 The ZRTP protocol uses random numbers for cryptographic key material, 810 notably for the DH secret exponents and nonces, which must be freshly 811 generated with each session. Whenever a random number is needed, all 812 of the following criteria must be satisfied: 814 It MUST be derived from a physical entropy source, such as RF noise, 815 acoustic noise, thermal noise, high resolution timings of 816 environmental events, or other unpredictable physical sources of 817 entropy. Chapter 10 of [7] gives a detailed explanation of 818 cryptographic grade random numbers and provides guidance for 819 collecting suitable entropy. The raw entropy must be distilled and 820 processed through a deterministic random bit generator (DRBG). 821 Examples of DRBGs may be found in NIST SP 800-90 [8], and in [7]. 823 It MUST be freshly generated, meaning that it must not have been used 824 in a previous calculation. 826 It MUST be greater than or equal to two, and less than or equal to 827 2^L - 1, where L is the number of random bits required. 829 It MUST be chosen with equal probability from the entire available 830 number space, e.g., [2, 2^L - 1]. 832 5.9. ZID and Cache Operation 834 Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that 835 is generated once at installation time. It is used to look up 836 retained shared secrets in a local cache. A single global ZID for a 837 single installation is the simplest way to implement ZIDs. However, 838 it is specifically not precluded for an implementation to use 839 multiple ZIDs, up to the limit of a separate one per callee. This 840 then turns it into a long-lived "association ID" that does not apply 841 to any other associations between a different pair of parties. It is 842 a goal of this protocol to permit both options to interoperate 843 freely. 845 Each time a new s0 is calculated, a new retained shared secret rs1 is 846 generated and stored in the cache, indexed by the ZID of the other 847 endpoint. The previous retained shared secret is then renamed rs2 848 and also stored in the cache. For the new retained shared secret, 849 each endpoint chooses a cache expiration value which is an unsigned 850 32 bit integer of the number of seconds that this secret should be 851 retained in the cache. The time interval is relative to when the 852 Confirm1 message is sent or received. 854 The cache intervals are exchanged in the Confirm1 and Confirm2 855 messages. The actual cache interval used by both endpoints is the 856 minimum of the values from the Confirm1 and Confirm2 messages. A 857 value of 0 seconds means the secret should not be cached and the 858 current values of rs1 and rs2 MUST be maintained. A value of 859 0xFFFFFFFF means the secret should be cached indefinitely and is the 860 recommended value. If the ZRTP exchange results in no new shared 861 secret generation (i.e. Preshared Mode), the field in the Confirm1 862 and Confirm2 is set to 0xFFFFFFFF and ignored, and the cache is not 863 updated. 865 The expiration interval need not be used to force the deletion of a 866 shared secret from the cache when the interval has expired. It just 867 means the shared secret MAY be deleted from that cache at any point 868 after the interval has expired without causing the other party to 869 note it as an unexpected security event when the next key negotiation 870 occurs between the same two parties. This means there need not be 871 perfectly synchronized deletion of expired secrets from the two 872 caches, and makes it easy to avoid a race condition that might 873 otherwise be caused by clock skew. 875 5.10. Terminating an SRTP Session or ZRTP Exchange 877 The GoClear message is used to switch from SRTP to RTP or to 878 terminate an in-progress ZRTP exchange. The GoClear message contains 879 a reason string for human purposes and a clear_hmac field. 881 When used to switch from SRTP to RTP, ZRTP uses an HMAC of the exact 882 4 octet Reason String sent in the GoGlear Message computed with the 883 hmackey derived from the shared secret. When sent by the initiator: 885 clear_hmac = HMAC(hmackeyi, Reason String) 887 When sent by the responder: 889 clear_hmac = HMAC(hmackeyr, Reason String) 891 A GoClear message which does not receive a ClearACK response 892 indicates that the GoClear has failed authentication (the clear_hmac 893 does not validate) and that the session must stay in secure mode. 895 When terminating an in-progress ZRTP exchange, no secret hmackey is 896 available, so the clear_hmac field is set to all zeros and ignored. 897 The reason string SHOULD indicate the reason for the failure (e.g. 898 "No Session Key", "Nonce Reuse", "Invalid DH Value"). The 899 termination of a ZRTP key agreement exchange results in no updates to 900 the cached shared secrets and deletion of all crypto context. 902 A ZRTP endpoint that receives a GoClear authenticates the message by 903 checking the clear_hmac. If the message authenticates, the endpoint 904 stops sending SRTP packets, generates a ClearACK in response, and 905 deletes the crypto context for the SRTP session. Until confirmation 906 from the user is received (e.g. clicking a button, pressing a DTMF 907 key, etc.), the ZRTP endpoint MUST NOT resume sending RTP packets. 908 The endpoint then renders the Reason String (after making sure only 909 valid ASCII characters are present) and an indication that the media 910 session has switched to clear mode to the user and waits for 911 confirmation from the user. To prevent pinholes from closing or NAT 912 bindings from expiring, the ClearACK message MAY be resent at regular 913 intervals (e.g. every 5 seconds) while waiting for confirmation from 914 the user. After confirmation of the notification is received from 915 the user, the sending of RTP packets may begin. 917 After sending a GoClear message, the ZRTP endpoint stops sending SRTP 918 packets. When a ClearACK is received, the ZRTP endpoint deletes the 919 crypto context for the SRTP session and may then resume sending RTP 920 packets. However, the ZRTP Session key is not deleted unless the 921 signaling session is terminated as well. 923 A ZRTP endpoint MAY choose to accept GoClear messages after the 924 session has switched to SRTP, allowing the session to revert to RTP. 925 This is indicated in the Confirm1 or Confirm2 messages by setting the 926 Allow Clear flag (A). If the other endpoint set the Allow Clear (A) 927 flag in their confirm message, GoClear messages MAY be sent after the 928 session has gone secure. 930 Note: GoClear messages can always be sent prior to session going 931 secure if the ZRTP exchange is terminated. 933 6. ZRTP Messages 935 All ZRTP messages use the message format defined in Figure 2. All 936 word lengths referenced in this specification are 32 bits or 4 937 octets. All integer fields are carried in network byte order, that 938 is, most significant byte (octet) first, commonly known as big- 939 endian. 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |0 0 0 1|Not Used (set to zero) | Sequence Number | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | ZRTP Magic Cookie (0x5a525450) | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Source Identifier | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | | 950 | ZRTP Message (length depends on Message Type) | 951 | . . . | 952 | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | CRC (1 word) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Figure 2. ZRTP Packet Format 959 The Sequence Number is a count that is incremented for each ZRTP 960 packet sent. The count is initialized to a random value. This is 961 useful in estimating ZRTP packet loss and also detecting when ZRTP 962 packets arrive out of sequence. 964 The ZRTP Magic Cookie is a 32 bit string that uniquely identifies a 965 ZRTP packet, and has the value 0x5a525450. 967 Source Identifier is the SSRC number of the RTP stream that this ZRTP 968 packet relates to. For cases of forking or forwarding, RTP and hence 969 ZRTP may arrive at the same port from several different sources - 970 each of these sources will have a different SSRC and may initiate an 971 independent ZRTP protocol session. 973 This format is clearly identifiable as non-RTP due to the first two 974 bits being zero which looks like RTP version 0, which is not a valid 975 RTP version number. It is clearly distinguishable from STUN since 976 the magic cookies are different. The 12 not used bits are set to 977 zero and MUST be ignored when received. 979 The ZRTP Messages are defined in Figures 3 to 11 and are of variable 980 length. 982 The ZRTP protocol uses a 32 bit CRC checksum in each ZRTP packet as 983 defined in RFC 3309 [6] to detect transmission errors. ZRTP packets 984 are typically transported by UDP, which carries its own built-in 16- 985 bit checksum for integrity, but ZRTP does not rely on it. This is 986 because of the effect of an undetected transmission error in a ZRTP 987 message. For example, an undetected error in the DH exchange could 988 appear to be an active man-in-the-middle attack. The psychological 989 effects of a false announcement of this by ZTRP clients can not be 990 overstated. The probability of such a false alarm hinges on a mere 991 16-bit checksum that usually protects UDP packets, so more error 992 detection is needed. For these reasons, this belt-and-suspenders 993 approach is used to minimize the chance of a transmission error 994 affecting the ZRTP key agreement. 996 The CRC is calculated across the entire ZRTP packet shown in Figure 997 2, including the ZRTP Header and the ZRTP Message, but not including 998 the CRC field. If a ZRTP message fails the CRC check, it is silently 999 discarded. 1001 6.1. ZRTP Message Formats 1003 ZRTP messages are designed to simplify endpoint parsing requirements 1004 and to reduce the opportunities for buffer overflow attacks (a good 1005 goal of any security extension should be to not introduce new attack 1006 vectors...) 1008 ZRTP uses 8 octets (2 words) blocks to encode Message Type. 4 octets 1009 (1 word) blocks are used to encode Hash Type, Cipher Type, and Key 1010 Agreement Type, and Authentication Tag. The values in the blocks are 1011 ASCII strings which are extended with spaces (0x20) to make them the 1012 desired length. Currently defined block values are listed in Tables 1013 1-6 below. 1015 Additional block values may be defined and used. 1017 ZRTP uses this ASCII encoding to simplify debugging and make it 1018 "ethereal friendly". 1020 6.1.1. Message Type Block 1022 Currently ten Message Type Blocks are defined - they represent the 1023 set of ZRTP message primitives. ZRTP endpoints MUST support the 1024 Hello, HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, 1025 Conf2ACK, GoClear and ClearACK block types. 1027 Message Type Block | Meaning 1028 --------------------------------------------------- 1029 "Hello " | Hello Message 1030 | defined in Section 6.2 1031 --------------------------------------------------- 1032 "HelloACK" | HelloACK Message 1033 | defined in Section 6.3 1034 --------------------------------------------------- 1035 "Commit " | Commit Message 1036 | defined in Section 6.4 1037 --------------------------------------------------- 1038 "DHPart1 " | DHPart1 Message 1039 | defined in Section 6.5 1040 --------------------------------------------------- 1041 "DHPart2 " | DHPart2 Message 1042 | defined in Section 6.6 1043 --------------------------------------------------- 1044 "Confirm1" | Confirm1 Message 1045 | defined in Section 6.7 1046 --------------------------------------------------- 1047 "Confirm2" | Confirm2 Message 1048 | defined in Section 6.8 1049 --------------------------------------------------- 1050 "Conf2ACK" | Conf2ACK Message 1051 | defined in Section 6.9 1052 --------------------------------------------------- 1053 "GoClear " | GoClear Message 1054 | defined in Section 6.10 1055 --------------------------------------------------- 1056 "ClearACK" | ClearACK Message 1057 | defined in Section 6.11 1058 --------------------------------------------------- 1059 Table 1. Message Block Type Values 1061 6.1.2. Hash Type Block 1063 Only one Hash Type is currently defined, SHA256, and all ZRTP 1064 endpoints MUST support this hash. Additional Hash Types can be 1065 registered and used. 1067 Hash Type Block | Meaning 1068 --------------------------------------------------- 1069 "S256" | SHA-256 Hash defined in [SHA-256] 1070 --------------------------------------------------- 1072 Table 2. Hash Block Type Values 1074 6.1.3. Cipher Type Block 1076 All ZRTP endpoints MUST support AES128 and MAY support AES256 [4]. or 1077 other Cipher Types. Also, if AES 128 is used, DH3k should be used. 1078 If AES 256 is used, DH4k should be used. 1080 Note: DH4k may be deprecated in the future in favor of elliptic curve 1081 algorithms. 1083 Cipher Type Block | Meaning 1084 --------------------------------------------------- 1085 "AES1" | AES-CM with 128 bit keys 1086 | as defined in RFC 3711 1087 --------------------------------------------------- 1088 "AES2" | AES-CM with 256 bit keys 1089 | as defined in RFC 3711 1090 --------------------------------------------------- 1092 Table 3. Cipher Block Type Values 1094 6.1.4. Auth Tag Block 1096 All ZRTP endpoints MUST support HMAC-SHA1 authentication, 32 bit and 1097 80 bit length tags as defined in RFC 3711. 1099 Auth Tag Block | Meaning 1100 --------------------------------------------------- 1101 "HS32" | HMAC-SHA1 32 bit authentication 1102 | tag as defined in RFC 3711 1103 --------------------------------------------------- 1104 "HS80" | HMAC-SHA1 80 bit authentication 1105 | tag as defined in RFC 3711 1106 --------------------------------------------------- 1108 Table 4. Auth Tag Values 1110 6.1.5. Key Agreement Type Block 1112 All ZRTP endpoints MUST support DH3k and MAY support DH4k. ZRTP 1113 endpoints MUST use the DH generator function g=2. The choice of AES 1114 key length is coupled to the choice of key agreement type. If AES 1115 128 is chosen, DH3k SHOULD be used. If AES 256 is chosen, DH4k 1116 SHOULD be used. ZRTP also defines a non-DH mode, Preshared, which 1117 SHOULD be supported. In Preshared mode, the SRTP key is derived from 1118 the set of shared secrets and a pair of nonces. 1120 Note: DH4k may be deprecated in the future in favor of elliptic curve 1121 algorithms. 1123 Key Agreement Type Block | Meaning 1124 --------------------------------------------------- 1125 "DH3k" | DH mode with p=3072 bit prime 1126 | as defined in RFC 3526 1127 --------------------------------------------------- 1128 "DH4k" | DH mode with p=4096 bit prime 1129 | as defined in RFC 3526 1130 --------------------------------------------------- 1131 "Prsh" | Preshared Non-DH mode 1132 | uses shared secrets. 1133 --------------------------------------------------- 1135 Table 5. Key Agreement Block Type Values 1137 6.1.6. SAS Type Block 1139 All ZRTP endpoints MUST support the base32 and MAY support base256 1140 Short Authentication String scheme, and other SAS rendering schemes. 1141 The ZRTP SAS is described in Section 7. 1143 SAS Type Block | Meaning 1144 --------------------------------------------------- 1145 "B32 " | Short Authentication String using 1146 | base32 encoding defined in Section 8. 1147 --------------------------------------------------- 1148 "B256" | Short Authentication String using 1149 | base256 encoding defined in Section 8. 1150 --------------------------------------------------- 1152 Table 6. SAS Block Type Values 1154 The SAS Type determines how the SAS is rendered to the user so that 1155 the user may compare it with his partner over the voice channel. 1156 This allows detection of a man-in-the-middle (MITM) attack. 1158 6.1.7. Signature Block 1160 The signature type block is a 4 octet (1 word) block used to 1161 represent the signature algorithm. Suggested signature algorithms 1162 and key lengths are a future subject of standardization. 1164 6.2. Hello message 1166 The Hello message has the format shown in Figure 3. The Hello ZRTP 1167 message begins with the preamble value 0x505a then a 16 bit length in 1168 32 bit words. This length includes only the ZRTP message (including 1169 the preamble and the length) but not the ZRTP header or CRC. Next is 1170 the Message Type Block and a 4 character string containing the 1171 version (ver) of ZRTP, currently "0.05". Next is the Client 1172 Identifier string (cid) which is 3 words long and identifies the 1173 vendor and release of the ZRTP software. The next parameter is the 1174 ZID, the 96 bit long unique identifier for the ZRTP endpoint. The 1175 next four bits contains flag bits. The only defined flag is the 1176 Passive bit (P), a Boolean normally set to False. A ZRTP endpoint 1177 which is configured to never initiate secure sessions is regarded as 1178 passive, and would set the P bit to True. The next 8 bits are 1179 unused. They should be set to zero when sent and ignored on receipt. 1180 Next is a list of supported Hash Types, Cipher Types, Auth Tag, Key 1181 Agreement Types, and SAS Type. The number of listed algorithms are 1182 listed for each type: hc=hash count, cc=cipher count, ac=auth tag 1183 count, kc=key agreement count, and sc=sas count. The values for 1184 these algorithms are defined in Tables 2, 3, 4, 5, and 6. A count of 1185 zero means that only the mandatory to implement algorithms are 1186 supported. Mandatory algorithms MAY be included in the list. The 1187 order of the list indicates the preferences of the endpoint. If a 1188 mandatory algorithm is not included in the list, it is added to the 1189 end of the list for preference. 1191 Note: Implementers are encouraged to keep these algorithm lists small 1192 - the list does not need to include every cipher and hash supported, 1193 just the ones the endpoint would prefer to use for this ZRTP 1194 exchange. 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Message Type Block="Hello " (2 words) | 1202 | | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | version (1 word) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | 1207 | Client Identifier (3 words) | 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | | 1211 | ZID (3 words) | 1212 | | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 |0 0 0|P| unused (zeros)| hc | cc | ac | kc | sc | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | hash (0 to 7 values) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | cipher (0 to 7 values) | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | at (0 to 7 values) | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | keya (0 to 7 values) | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | sas (0 to 7 values) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Figure 3. Hello message format 1229 6.3. HelloACK message 1231 The HelloACK message is used to stop retransmissions of a Hello 1232 message. A HelloACK is sent regardless if the version number in the 1233 Hello is supported or the algorithm list supported. The receipt of a 1234 HelloACK stops retransmission of the Hello message. The format is 1235 shown in Figure 4 below. Note that a Commit message can be sent in 1236 place of a HelloACK by an initiator. 1238 0 1 2 3 1239 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 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Message Type Block="HelloACK" (2 words) | 1244 | | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Figure 4. HelloACK message format 1249 6.4. Commit message 1251 The Commit message is sent to initiate the key agreement process 1252 after receiving a Hello message. The Commit message contains the 1253 initiator's ZID and a list of selected algorithms (hash, cipher, atl, 1254 keya, sas), the ZRTP mode, and hvi, a hash of the public DH value of 1255 the initiator and the algorithm list from the responder's Hello 1256 message. If a non-DH mode is used, hvi is replaced by a random 1257 number, noncei. The Commit Message format is shown in Figure 5. 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=19 words | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Message Type Block="Commit " (2 words) | 1265 | | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | | 1268 | ZID (3 words) | 1269 | | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | hash | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | cipher | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | at | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | keya | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | SAS Type | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | | 1282 | hvi or noncei (8 words) | 1283 | . . . | 1284 | | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 Figure 5. Commit message format 1289 6.5. DHPart1 message 1291 The DHPart1 message begins the DH exchange. The format is shown in 1292 Figure 5 below. The DHPart1 message is sent if a valid Commit 1293 message is received. The length of the pvr value depends on the Key 1294 Agreement Type chosen. If DH4k is used, the pvr will be 128 words 1295 (512 octets) and the length of this message will be 141 words. If 1296 DH3k is used, it is 96 words (384 octets) and the length of this 1297 message will be 109 words. If the Key Agreement Type is Preshared, 1298 then pvr is replaced by an 8 word noncer from the responder and the 1299 length of this message will be 21 words. 1301 The next five parameters are HMACs of potential shared secrets used 1302 in generating the ZRTP secret. The first two, rs1IDr and rs2IDr, are 1303 the HMACs of the responder's two retained shared secrets, truncated 1304 to 64 bits. Next is sigsIDr, the HMAC of the responder's signaling 1305 secret, truncated to 64 bits. Next is srtpsIDr, the HMAC of the 1306 responder's SRTP secret, truncated to 64 bits. The last parameter is 1307 the HMAC of an additional shared secret. For example, if multiple 1308 SRTP secrets are available or some other secret is used, it can be 1309 used as the other_secret. The Message format for the DHPart1 message 1310 is shown in Figure 6. 1312 0 1 2 3 1313 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 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Message Type Block="DHPart1 " (2 words) | 1318 | | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | | 1321 | pvr (length depends on KA Type) or noncer (8 words) | 1322 | . . . | 1323 | | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | rs1IDr (2 words) | 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | rs2IDr (2 words) | 1329 | | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | sigsIDr (2 words) | 1332 | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | srtpsIDr (2 words) | 1335 | | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | other_secretIDr (2 words) | 1338 | | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Figure 6. DHPart1 message format 1343 6.6. DHPart2 message 1345 The DHPart2 message completes the DH exchange. A DHPart2 message is 1346 sent if a valid DHPart1 message is received. The length of the pvi 1347 value depends on the Key Agreement Type chosen. If DH4k is used, the 1348 pvi will be 128 words (512 octets) and the length of this message 1349 will be 141 words. If DH3k is used, it is 96 words (384 octets) and 1350 the length of this message will be 109 words. If the Key Agreement 1351 Type is Preshared, then pvi is omitted (0 octets) and the length of 1352 this message will be 13 words. 1354 The next five parameters are HMACs of potential shared secrets used 1355 in generating the ZRTP secret. The first two, rs1IDi and rs2IDi, are 1356 the HMACs of the initiator's two retained shared secrets, truncated 1357 to 64 bits. Next is sigsIDi, the HMAC of the initiator's signaling 1358 secret, truncated to 64 bits. Next is srtpsIDi, the HMAC of the 1359 initiator's SRTP secret, truncated to 64 bits. The last parameter is 1360 the HMAC of an additional shared secret. For example, if multiple 1361 SRTP secrets are available or some other secret is used, it can be 1362 included. The message format for the DHPart2 message is shown in 1363 Figure 7. 1365 0 1 2 3 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Message Type Block="DHPart2 " (2 words) | 1371 | | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | | 1374 | pvi (length depends on KA Type) | 1375 | . . . | 1376 | | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | rs1IDi (2 words) | 1379 | | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | rs2IDi (2 words) | 1382 | | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | sigsIDi (2 words) | 1385 | | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | srtpsIDi (2 words) | 1388 | | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | other_secretIDi (2 words) | 1391 | | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Figure 7. DHPart2 message format 1396 6.7. Confirm1 and Confirm2 messages 1398 The Confirm1 message is sent in response to a valid DHPart2 message 1399 after the SRTP session key and parameters have been negotiated. The 1400 Confirm2 message is sent in response to a Confirm1 message. The 1401 format is shown in Figure 8 below. The message contains the Message 1402 Type Block "Confirm1" or "Confirm2". Next is the HMAC, a keyed hash 1403 over encrypted part of the message (shown enclosed by "===" in Figure 1404 8.) The next 16 octets contain the CFB Initialization Vector. The 1405 rest of the message is encrypted using CFB and protected by the HMAC. 1407 The next 16 bits are not used. They SHOULD be set to zero and MUST 1408 be ignored in received Confirm1 messages. 1410 The next 8 bits contain the signature length. If no SAS signature 1411 (described in Section 8.3) is present, all bits are set to zero. The 1412 signature length is in words and includes the signature type block. 1413 If the calculated signature octet count is not a multiple of 4, zeros 1414 are added to pad it out to a word boundary. If no signature block is 1415 present, the overall length of the Confirm1 or Confirm2 Message will 1416 be set to 11 words. 1418 The next 8 bits are used for flags. Undefined flags are set to zero 1419 and ignored. Three flags are currently defined. The Disclosure Flag 1420 (D) is a Boolean bit defined in Appendix B. The Allow Clear flag (A) 1421 is a Boolean bit defined in Section 5.6. The SAS Verified flag (V) 1422 is a Boolean bit defined in Section 8. The cache expiration interval 1423 is an unsigned 32 bit integer of the number of seconds that the newly 1424 generated cached shared secret, rs1, should be stored. 1426 If the signature length (in words) is non-zero, a signature type 1427 block will be present along with a signature block. Next is the 1428 signature block. 1430 CFB [11] mode is applied with a feedback length of 128-bits, a full 1431 cipher block, and the final block is truncated to match the exact 1432 length of the encrypted data. The CFB Initialization Vector is a 128 1433 bit random nonce. The block cipher algorithm and the key size is the 1434 same as what was negotiated for the media encryption. CFB is used to 1435 encrypt the part of the Confirm1 message beginning after the CFB IV 1436 to the end of the message (the encrypted region is enclosed by 1437 "======" in Figure 8). 1439 The responder uses the zrtpkeyr to encrypt the Confirm1 message. The 1440 initiator uses the zrtpkeyi to encrypt the Confirm2 message. 1442 0 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Message Type Block="Confirm1" or "Confirm2" (2 words) | 1448 | | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | hmac (2 words) | 1451 | | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | | 1454 | CFB Initialization Vector (4 words) | 1455 | | 1456 | | 1457 +===============================================================+ 1458 | Unused (Set to zero, ignored) | sig length |0 0 0 0 0|V|A|D| 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | cache expiration interval (1 word) | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | optional signature type block (1 word if present) | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | | 1465 | optional signature block (variable length) | 1466 | . . . | 1467 | | 1468 | | 1469 +===============================================================+ 1471 Figure 8. Confirm1 and Confirm2 message format 1473 6.8. Conf2ACK message 1475 The Conf2ACK message is sent in response to a valid Confirm2 message. 1476 The message format for the Conf2ACK is shown in Figure 9. The 1477 receipt of a Conf2ACK stops retransmission of the Confirm2 message. 1479 0 1 2 3 1480 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 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Message Type Block="Conf2ACK" (2 words) | 1485 | | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 Figure 9. Conf2ACK message format 1490 6.9. GoClear message 1492 The GoClear message is sent to terminate an in-process ZRTP key 1493 agreement exchange or optionally to switch from SRTP to RTP. The 1494 format is shown in Figure 10 below. The Reason String is a 16 1495 character string which contains the reason for the switch to clear. 1496 If the GoClear is sent due to a protocol error, the reason phrase is 1497 generated to describe the reason. The Reason String can be logged or 1498 rendered for human consumption. If the GoClear is sent due to a user 1499 interface selection, the reason is "User Request". 1501 If the GoClear is sent to switch from SRTP back to RTP, the The 1502 clear_hmac is used to authenticate the GoClear message so that bogus 1503 GoClear messages introduced by an attacker can be detected and 1504 discarded. 1506 0 1 2 3 1507 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 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=15 words | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Message Type Block="GoClear " (2 words) | 1512 | | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | | 1515 | Reason String (4 words) | 1516 | | 1517 | | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | | 1520 | clear_hmac (8 words) | 1521 | . . . | 1522 | | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 Figure 10. GoClear message format 1527 6.10. ClearACK message 1529 The ClearACK message is sent to acknowledge receipt of a GoClear. A 1530 ClearACK is only sent if the clear_hmac from the GoClear message is 1531 authenticated. Otherwise, no response is returned. The format is 1532 shown in Figure 11. 1534 0 1 2 3 1535 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 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 |0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Message Type Block="ClearACK" (2 words) | 1540 | | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 Figure 11. ClearACK message format 1545 7. Retransmissions 1547 ZRTP uses two retransmission timers T1 and T2. T1 is used for 1548 retransmission of Hello messages, when the support of ZRTP by the 1549 other endpoint may not be known. T2 is used in retransmissions of 1550 all the other ZRTP messages with the exception of GoClear. 1552 All message retransmissions MUST be identical to the initial message 1553 including nonces, public values, etc; otherwise, hashes of the 1554 message sequences may not agree. 1556 Practical experience has shown that RTP packet loss at the start of 1557 an RTP session can be extremely high. Since the entire ZRTP message 1558 exchange occurs during this period, the defined retransmission scheme 1559 is defined to be aggressive. Since ZRTP packets with the exception 1560 of the DHPart1 and DHPart2 messages are small, this should have 1561 minimal effect on overall bandwidth utilization of the media session. 1563 Hello ZRTP requests are retransmitted at an interval that starts at 1564 T1 seconds and doubles after every retransmission, capping at 200ms. 1565 A Hello message is retransmitted 20 times before giving up. T1 has a 1566 recommended value of 50 ms. Retransmission of a Hello ends upon 1567 receipt of a HelloACK or Commit message. 1569 Non-Hello ZRTP requests are retransmitted only by the initiator - 1570 that is, only Commit, DHPart2, and Confirm2 are retransmitted if the 1571 corresponding message from the responder, DHPart1, Confirm1, and 1572 Conf2ACK, are not received. Non-Hello ZRTP messages are 1573 retransmitted at an interval that starts at T2 seconds and doubles 1574 after every retransmission, capping at 600ms. Only the ZRTP 1575 initiator performs retransmissions. Each message is retransmitted 10 1576 times before giving up and resuming a normal RTP session. T2 has a 1577 default value of 150ms. Each message has a response message that 1578 stops retransmissions, as shown in Table 7. The high value of T2 1579 means that retransmissions will likely only occur with packet loss. 1581 A GoClear message is retransmitted at 500ms intervals until a 1582 ClearACK message is received. 1584 Message Acknowledgement Message 1585 ------- ----------------------- 1586 Hello HelloACK or Commit 1587 Commit DHPart1 or Confirm1 1588 DHPart2 Confirm1 1589 Confirm1 Confirm2 1590 Confirm2 Conf2ACK 1591 GoClear ClearACK 1593 Table 7. Retransmitted ZRTP Messages and Responses 1595 8. Short Authentication String 1597 This section will discuss the implementation of the Short 1598 Authentication String, or SAS in ZRTP. The SAS can be verified by 1599 the human users reading the string aloud, exchanging and comparing 1600 over an integrity-protected signaling channel using the a=zrtp-sas 1601 attribute, or validating a digital signature exchanged in the 1602 Confirm1 or Confirm2 messages. 1604 The rendering of the SAS value to the user depends on the SAS Type 1605 agreed upon in the Commit message. For the SAS Type of base32, the 1606 last 20 bits of the sasvalue are rendered as a form of base32 1607 encoding known as libbase32 [9]. The purpose of base32 is to 1608 represent arbitrary sequences of octets in a form that is as 1609 convenient as possible for human users to manipulate. As a result, 1610 the choice of characters is slightly different from base32 as defined 1611 in RFC 3548. The last 20 bits of the sasvalue results in four base32 1612 characters which are rendered to both ZRTP endpoints. Other SAS 1613 Types may be defined to render the SAS value in other ways. 1615 The SAS SHOULD be rendered to the user for authentication. In 1616 addition, the SAS SHOULD be sent in a subsequent offer/answer 1617 exchange (a re-INVITE in SIP) after the completion of ZRTP exchange 1618 using the ZRTP SAS SDP attributes defined in Appendix A. 1620 The SAS is not a secret value, but it must be compared to see if it 1621 matches at both ends of the communications channel. The two users 1622 read it aloud to their partners to see if it matches. This allows 1623 detection of a man-in-the-middle (MITM) attack. 1625 8.1. SAS Verified Flag 1627 The SAS Verified flag (V) is set based on the user indicating that 1628 SAS comparison has been successfully performed. The SAS Verified 1629 flag is exchanged securely in the Confirm1 and Confirm2 messages of 1630 the next session. In other words, each party sends the SAS Verified 1631 flag from the previous session in the Confirm message of the current 1632 session. It is perfectly reasonable to have a ZRTP endpoint that 1633 never sets the SAS Verified flag, because it would require adding 1634 complexity to the user interface to allow the user to set it. The 1635 SAS Verified flag is not required to be set, but if it is available 1636 to the client software, it allows for the possibility that the client 1637 software could render to the user that the SAS verify procedure was 1638 carried out in a previous session. 1640 Regardless of whether there is a user interface element to allow the 1641 user to set the SAS Verified flag, it is worth caching a shared 1642 secret, because doing so reduces opportunities for an attacker in the 1643 next call. 1645 If at any time the users carry out the SAS comparison procedure, and 1646 it actually fails to match, then this means there is a very 1647 resourceful man in the middle. If this is the first call, the MITM 1648 was there on the first call, which is impressive enough. If it 1649 happens in a later call, it also means the MITM must also know the 1650 cached shared secret, because you could not have carried out any 1651 voice traffic at all unless the session key was correctly computed 1652 and is also known to the attacker. This implies the MITM must have 1653 been present in all the previous sessions, since the initial 1654 establishment of the first shared secret. This is indeed a 1655 resourceful attacker. It also means that if at any time he ceases 1656 his participation as a MITM on one of your calls, the protocol will 1657 detect that the cached shared secret is no longer valid -- because it 1658 was really two different shared secrets all along, one of them 1659 between Alice and the attacker, and the other between the attacker 1660 and Bob. The continuity of the cached shared secrets make it possible 1661 for us to detect the MITM when he inserts himself into the ongoing 1662 relationship, as well as when he leaves. Also, if the attacker tries 1663 to stay with a long lineage of calls, but fails to execute a DH MITM 1664 attack for even one missed call, he is permanently excluded. He can 1665 no longer resynchronize with the chain of cached shared secrets. 1667 Some sort of user interface element (maybe a checkbox) is needed to 1668 allow the user to tell the software the SAS verify was successful, 1669 causing the software to set the SAS Verified flag (V), which 1670 (together with our cached shared secret) obviates the need to perform 1671 the SAS procedure in the next call. An additional user interface 1672 element can be provided to let the user tell the software he detected 1673 an actual SAS mismatch, which indicates a MITM attack. The software 1674 can then take appropriate action, clearing the SAS Verified flag, and 1675 erase the cached shared secret from this session. It is up to the 1676 implementer to decide if this added user interface complexity is 1677 warranted. 1679 If the SAS matches, it means there is no MITM, which also implies it 1680 is now safe to trust a cached shared secret for later calls. If 1681 inattentive users don't bother to check the SAS, it means we don't 1682 know whether there is or is not a MITM, so even if we do establish a 1683 new cached shared secret, there is a risk that our potential attacker 1684 may have a subsequent opportunity to continue inserting himself in 1685 the call, until we finally get around to checking the SAS. If the 1686 SAS matches, it means no attacker was present for any previous 1687 session since we started propagating cached shared secrets, because 1688 this session and all the previous sessions were also authenticated 1689 with a continuous lineage of shared secrets. 1691 8.2. Signing the SAS 1693 The SAS MAY be signed and the signature sent using the Confirm1 or 1694 Confirm2 messages. The signature algorithm is also sent in the 1695 Confirm1 or Confirm2 message, along with the length of the signature. 1696 The key types and signature algorithms are for future study. The 1697 signature is calculated over the 64 bit sasvalue. The signatures 1698 exchanged in the encrypted Confirm1 or Confirm2 messages MAY be used 1699 to authenticate the ZRTP exchange. 1701 9. IANA Considerations 1703 This specification defines two new SDP [10] attributes in Appendix A. 1704 The IANA registration of ZRTP SDP attribute: 1706 Contact name: Phil Zimmermann 1708 Attribute name: "zrtp-zid". 1710 Type of attribute: Session level or Media level. 1712 Subject to charset: Not. 1714 Purpose of attribute: The 'zrtp-zid' indicates that a UA supports the 1715 ZRTP protocol and provides the ZID of the UA. 1717 Allowed attribute values: Hex. 1719 IANA registration of the ZRTP SAS SDP attribute: 1721 Contact name: Phil Zimmermann 1723 Attribute name: "zrtp-sas". 1725 Type of attribute: Media level. 1727 Subject to charset: Yes. 1729 Purpose of attribute: The 'zrtp-sas' is used to convey the ZRTP SAS 1730 string and value. The string is identical to that 1731 rendered to the users. The value is the 64 bit SAS 1732 encoded as hex. 1734 Allowed attribute values: String and Hex. 1736 10. Security Considerations 1738 This document is all about securely keying SRTP sessions. As such, 1739 security is discussed in every section. 1741 Most secure phones rely on a Diffie-Hellman exchange to agree on a 1742 common session key. But since DH is susceptible to a man-in-the- 1743 middle (MITM) attack, it is common practice to provide a way to 1744 authenticate the DH exchange. In some military systems, this is done 1745 by depending on digital signatures backed by a centrally-managed PKI. 1746 A decade of industry experience has shown that deploying centrally 1747 managed PKIs can be a painful and often futile experience. PKIs are 1748 just too messy, and require too much activation energy to get them 1749 started. Setting up a PKI requires somebody to run it, which is not 1750 practical for an equipment provider. A service provider like a 1751 carrier might venture down this path, but even then you have to deal 1752 with cross-carrier authentication, certificate revocation lists, and 1753 other complexities. It is much simpler to avoid PKIs altogether, 1754 especially when developing secure commercial products. It is 1755 therefore more common for commercial secure phones in the PSTN world 1756 to augment the DH exchange with a Short Authentication String (SAS) 1757 combined with a hash commitment at the start of the key exchange, to 1758 shorten the length of SAS material that must be read aloud. No PKI 1759 is required for this approach to authenticating the DH exchange. The 1760 AT&T TSD 3600, Eric Blossom's COMSEC secure phones [15], PGPfone 1761 [13], and CryptoPhone [16] are all examples of products that took 1762 this simpler lightweight approach. 1764 The main problem with this approach is inattentive users who may not 1765 execute the voice authentication procedure, or unattended secure 1766 phone calls to answering machines that cannot execute it. 1768 Additionally, some people worry about voice spoofing. But it is a 1769 mistake to think this is simply an exercise in voice impersonation 1770 (perhaps this could be called the "Rich Little" attack). Although 1771 there are digital signal processing techniques for changing a 1772 person's voice, that does not mean a man-in-the-middle attacker can 1773 safely break into a phone conversation and inject his own short 1774 authentication string (SAS) at just the right moment. He doesn't 1775 know exactly when or in what manner the users will choose to read 1776 aloud the SAS, or in what context they will bring it up or say it, or 1777 even which of the two speakers will say it, or if indeed they both 1778 will say it. In addition, some methods of rendering the SAS involve 1779 using a list of words such as the PGP word list, in a manner 1780 analogous to how pilots use the NATO phonetic alphabet to convey 1781 information. This can make it even more complicated for the 1782 attacker, because these words can be worked into the conversation in 1783 unpredictable ways. Remember that the attacker places a very high 1784 value on not being detected, and if he makes a mistake, he doesn't 1785 get to do it over. Some people have raised the question that even if 1786 the attacker lacks voice impersonation capabilities, it may be unsafe 1787 for people who don't know each other's voices to depend on the SAS 1788 procedure. This is not as much of a problem as it seems, because it 1789 isn't necessary that they recognize each other by their voice, it's 1790 only necessary that they detect that the voice used for the SAS 1791 procedure matches the voice in the rest of the phone conversation. 1793 A popular and field-proven approach is used by SSH (Secure Shell) 1794 [18], which Peter Gutmann likes to call the "baby duck" security 1795 model. SSH establishes a relationship by exchanging public keys in 1796 the initial session, when we assume no attacker is present, and this 1797 makes it possible to authenticate all subsequent sessions. A 1798 successful MITM attacker has to have been present in all sessions all 1799 the way back to the first one, which is assumed to be difficult for 1800 the attacker. All this is accomplished without resorting to a 1801 centrally-managed PKI. 1803 We use an analogous baby duck security model to authenticate the DH 1804 exchange in ZRTP. We don't need to exchange persistent public keys, 1805 we can simply cache a shared secret and re-use it to authenticate a 1806 long series of DH exchanges for secure phone calls over a long period 1807 of time. If we read aloud just one SAS, and then cache a shared 1808 secret for later calls to use for authentication, no new voice 1809 authentication rituals need to be executed. We just have to remember 1810 we did one already. 1812 If we ever lose this cached shared secret, it is no longer available 1813 for authentication of DH exchanges, so we would have to do a new SAS 1814 procedure and start over with a new cached shared secret. Then we 1815 could go back to omitting the voice authentication on later calls. 1817 A particularly compelling reason why this approach is attractive is 1818 that SAS is easiest to implement when a GUI or some sort of display 1819 is available, which raises the question of what to do when no display 1820 is available. We envision some products that implement secure VoIP 1821 via a local network proxy, which lacks a display in many cases. If 1822 we take an approach that greatly reduces the need for a SAS in each 1823 and every call, we can operate in GUI-less products with greater 1824 ease. 1826 It's a good idea to force your opponent to have to solve multiple 1827 problems in order to mount a successful attack. Some examples of 1828 widely differing problems we might like to present him with are: 1829 Stealing a shared secret from one of the parties, being present on 1830 the very first session and every subsequent session to carry out an 1831 active MITM attack, and solving the discrete log problem. We want to 1832 force the opponent to solve more than one of these problems to 1833 succeed. 1835 ZRTP can use different kinds of shared secrets. Each type of shared 1836 secret is determined by a different method. All of the shared 1837 secrets are hashed together to form a session key to encrypt the 1838 call. An attacker must defeat all of the methods in order to 1839 determine the session key. 1841 First, there is the shared secret determined entirely by a Diffie- 1842 Hellman key agreement. It changes with every call, based on random 1843 numbers. An attacker may attempt a classic DH MITM attack on this 1844 secret, but we can protect against this by displaying and reading 1845 aloud a SAS, combined with adding a hash commitment at the beginning 1846 of the DH exchange. 1848 Second, there is an evolving shared secret, or ongoing shared secret 1849 that is automatically changed and refreshed and cached with every new 1850 session. We will call this the cached shared secret, or sometimes 1851 the retained shared secret. Each new image of this ongoing secret is 1852 a non-invertable function of its previous value and the new secret 1853 derived by the new DH agreement. It's possible that no cached shared 1854 secret is available, because there were no previous sessions to 1855 inherit this value from, or because one side loses its cache. 1857 There are other approaches for key agreement for SRTP that compute a 1858 shared secret using information in the signaling. For example, [20] 1859 describes how to carry a MIKEY (Multimedia Internet KEYing) [21] 1860 payload in SDP [10]. Or [19] describes directly carrying SRTP keying 1861 and configuration information in SDP. ZRTP does not rely on the 1862 signaling to compute a shared secret, but If a client does produce a 1863 shared secret via the signaling, and makes it available to the ZRTP 1864 protocol, ZRTP can make use of this shared secret to augment the list 1865 of shared secrets that will be hashed together to form a session key. 1866 This way, any security weaknesses that might compromise the shared 1867 secret contributed by the signaling will not harm the final resulting 1868 session key. 1870 There may also be a static shared secret that the two parties agree 1871 on out-of-band in advance. A hashed passphrase would suffice. 1873 The shared secret provided by the signaling (if available), the 1874 shared secret computed by DH, and the cached shared secret are all 1875 hashed together to compute the session key for a call. If the cached 1876 shared secret is not available, it is omitted from the hash 1877 computation. If the signaling provides no shared secret, it is also 1878 omitted from the hash computation. 1880 No DH MITM attack can succeed if the ongoing shared secret is 1881 available to the two parties, but not to the attacker. This is 1882 because the attacker cannot compute a common session key with either 1883 party without knowing the cached secret component, even if he 1884 correctly executes a classic DH MITM attack. Mixing in the cached 1885 shared secret for the session key calculation allows it to act as an 1886 implicit authenticator to protect the DH exchange, without requiring 1887 additional explicit HMACs to be computed on the DH parameters. If 1888 the cached shared secret is available, a MITM attack would be 1889 instantly detected by the failure to achieve a shared session key, 1890 resulting in undecryptable packets. The protocol can easily detect 1891 this. It would be more accurate to say that the MITM attack is not 1892 merely detected, but thwarted. 1894 When adding the complexity of additional shared secrets beyond the 1895 familiar DH key agreement, we must make sure the lack of availability 1896 of the cached shared secret cannot prevent a call from going through, 1897 and we must also prevent false alarms that claim an attack was 1898 detected. 1900 An small added benefit of using these cached shared secrets to mix in 1901 with the session keys is that it augments the entropy of the session 1902 key. Even if limits on the size of the DH exchange produces a 1903 session key with less than 256 bits of real work factor, the added 1904 entropy from the cached shared secret can bring up all the subsequent 1905 session keys to the full 256-bit AES key strength, assuming no 1906 attacker was present in the first call. 1908 We could have authenticated the DH exchange the same way SSH does it, 1909 with digital signatures, caching public keys instead of shared 1910 secrets. But this approach with caching shared secrets seemed a bit 1911 simpler, requiring less CPU time for low-powered mobile platforms 1912 because it avoids an added digital signature step. 1914 The ZRTP SDP attributes convey information through the signaling that 1915 is already available in clear text through the media path. For 1916 example, the ZRTP flag is equivalent to sending a ZRTP Hello message. 1917 The SAS is calculated from a hash of material from ZRTP messages sent 1918 over the media path. As a result, none of the ZRTP SDP attributes 1919 require confidentiality from the signaling. 1921 The ZRTP SAS attributes can use the signaling channel as an out-of- 1922 band authentication mechanism. This authentication is only useful if 1923 the signaling channel has end-to-end integrity protection. Note that 1924 the SIP Identity header field [23] provides middle-to-end integrity 1925 protection across SDP message bodies which provides useful protection 1926 for ZRTP SAS attributes. 1928 11. Acknowledgments 1930 The authors would like to thank Bryce Wilcox-O'Hearn for his 1931 contributions to the design of this protocol, and to thank Jon 1932 Peterson, Colin Plumb, Hal Finney, Colin Perkins, and Dan Wing for 1933 their helpful comments and suggestions. Also thanks to David McGrew, 1934 Roni Even, Viktor Krikun, Werner Dittmann, Allen Pulsifer, Klaus 1935 Peters, and Abhishek Arya for their feedback and comments. 1937 12. Appendix A - Signaling Interactions 1939 This section discusses how ZRTP, SIP, and SDP work together. 1941 The signaling secret (sigs) can be derived from SIP signaling and 1942 passed from the signaling protocol used to establish the RTP session 1943 to ZRTP. Its the dialog identifier of a Secure SIP (sips) session: a 1944 string composed of Call-ID and the local and remote tags. It can be 1945 considered a secret because it is always transported using TLS and is 1946 randomly generated for each SIP call. The local and remote tags are 1947 sorted in ascending order in the hash. From the definitions in RFC 1948 3261 [17]: 1950 sigs = hash(call-id | tag1 | tag2) 1952 Note: the dialog identifier of a non-secure SIP session should not be 1953 considered a signaling secret as it has no confidentiality 1954 protection. 1956 Note: The signaling secret secret may not be regarded as having 1957 adequate entropy for cryptographic protection without augmentation by 1958 key material from other sources. 1960 For the SRTP secret (srtps), it is the SRTP master key and salt. 1961 This information may have been passed in the signaling using [20] or 1962 [19], for example: 1964 srtps = hash(SRTP master key | SRTP master salt) 1966 Note that ZRTP may be implemented without coupling with the SIP 1967 signaling. For example, ZRTP can be implemented as a "bump in the 1968 wire" or as a "bump in the stack" in which RTP sent by the SIP UA is 1969 converted to ZRTP. In these cases, the SIP UA will have no knowledge 1970 of ZRTP. As a result, the signaling path discovery mechanisms 1971 introduced in this section should not be definitive - they are a 1972 hint. Despite the absence of an indication of ZRTP support in an 1973 offer or answer, a ZRTP endpoint SHOULD still send Hello messages. 1975 ZRTP endpoints which have control over the signaling path include a 1976 ZRTP SDP attributes in their SDP offers and answers. The ZRTP 1977 attribute, a=zrtp-id is a flag to indicate support for ZRTP. There 1978 are a number of potential uses for this attribute. It is useful when 1979 signaling elements would like to know when ZRTP may be utilized by 1980 endpoints. It is also useful if endpoints support multiple methods 1981 of SRTP key management. The ZRTP attribute can be used to ensure 1982 that these key management approaches work together instead of against 1983 each other. For example, if only one endpoint supports ZRTP but both 1984 support another method to key SRTP, then the other method will be 1985 used instead. When used in parallel, an SRTP secret carried in an 1986 a=keymgt [20] or a=crypto [19] attribute can be used as a shared 1987 secret for the srtp_secret. The ZRTP attribute is also used to 1988 signal to an intermediary ZRTP device not to act as a ZRTP endpoint, 1989 as discussed in Appendix C. 1991 The a=zrtp-zid attribute can be included at a media level or at the 1992 session level. It indicates support of ZRTP and provides the ZID 1993 encoded in hex of the endpoint. When used at the media level, it 1994 indicates that ZRTP is supported on this media stream. When used at 1995 the session level, it indicates that ZRTP is supported in all media 1996 streams in the session described by the offer or answer and that the 1997 same ZID will be used for both streams. 1999 In some scenarios, it is desirable for a signaling intermediary to be 2000 able to validate the SAS on behalf of the user. This could be due to 2001 an endpoint which has a user interface unable to render the SAS. Or, 2002 this could be a protection by an organization against lazy users who 2003 never check the SAS. Using either the ZRTP SAS or ZRTP SASvalue 2004 attribute, the SAS check can be performed without requiring the human 2005 users to speak the SAS. Note that this check can only be relied on 2006 if the signaling path has end-to-end integrity protection. 2008 The ZRTP SAS attribute a=zrtp-sas is a Media level SDP attribute that 2009 can be used to carry the SAS string and value. The string is 2010 identical to that rendered to the user while contents of the string 2011 passed depends on the negotiated SAS Type. The value is the 64 bit 2012 SAS value encoded as hex. Since the SAS is not known at the start of 2013 a session, the a=zrtp-sas attribute will never be present in the 2014 initial offer/answer exchange. After the ZRTP exchange has 2015 completed, the SAS is known and can be exchanged over the signaling 2016 using a second offer/answer exchange (a re-INVITE in SIP terms). 2017 Note that the SAS is not a secret and as such does not need 2018 confidentiality protection when sent over the signaling path. 2020 The ABNF for the ZRTP attribute is as follows: 2022 zrtp-attribute = "a=zrtp-zid:" zid-value 2024 zid-value = 1*(HEXDIG) 2026 The ABNF for the ZRTP SAS attribute is as follows: 2028 zrtp-sas-attribute = "a=zrtp-sas:" sas-string sas-value 2030 sas-string = non-ws-string 2032 non-ws-string = 1*(VCHAR/%x80-FF) 2033 ;string of visible characters 2035 sas-value = 1*(HEXDIG) 2037 Example of the ZRTP attribute in an initial SDP offer or answer used 2038 at the session level: 2040 v=0 2041 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com 2042 s= 2043 c=IN IP4 client.biloxi.example.com 2044 a=zrtp-zid:4cc3ffe30efd02423cb054e5 2045 t=0 0 2046 m=audio 3456 RTP/AVP 97 33 2047 a=rtpmap:97 iLBC/8000 2048 a=rtpmap:33 no-op/8000 2050 Example of the ZRTP SAS and SASvalue attribute in a subsequent SDP 2051 offer or answer used at the media level. Note that the a=zrtp-id 2052 attribute doesn't provide any additional information when used with 2053 the SAS and SASvalue attributes but does not do any harm: 2055 v=0 2056 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 2057 s= 2058 c=IN IP4 client.biloxi.example.com 2059 a=zrtp-zid:4cc3ffe30efd02423cb054e5 2060 t=0 0 2061 m=audio 3456 RTP/AVP 97 33 2062 a=rtpmap:97 iLBC/8000 2063 a=rtpmap:33 no-op/8000 2064 a=zrtp-sas: opzf 5e017f3a6563876a 2066 Another example showing a second media stream being added to the 2067 session. A second DH exchange is performed (instead of using the 2068 Preshared mode) resulting in a second set of ZRTP SAS and SASvalue 2069 attributes. 2071 v=0 2072 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com 2073 s= 2074 c=IN IP4 client.biloxi.example.com 2075 a=zrtp-zid:4cc3ffe30efd02423cb054e5 2076 t=0 0 2077 m=audio 3456 RTP/AVP 97 33 2078 a=rtpmap:97 iLBC/8000 2079 a=rtpmap:33 no-op/8000 2080 a=zrtp-sas: opzf 5e017f3a6563876a 2081 m=video 51372 RTP/AVP 31 33 2082 a=rtpmap:31 H261/90000 2083 a=rtpmap:33 no-op/8000 2084 a=zrtp-sas: gwif e1027fa9f865221c 2086 13. Appendix B - The ZRTP Disclosure flag 2088 There are no back doors defined in the ZRTP protocol specification. 2089 The designers of ZRTP would like to discourage back doors in ZRTP- 2090 enabled products. However, despite the lack of back doors in the 2091 actual ZRTP protocol, it must be recognized that a ZRTP implementer 2092 might still deliberately create a rogue ZRTP-enabled product that 2093 implements a back door outside the scope of the ZRTP protocol. For 2094 example, they could create a product that discloses the SRTP session 2095 key generated using ZRTP out-of-band to a third party. They may even 2096 have a legitimate business reason to do this for some customers. 2098 For example, some environments have a need to monitor or record 2099 calls, such as stock brokerage houses who want to discourage insider 2100 trading, or special high security environments with special needs to 2101 monitor their own phone calls. We've all experienced automated 2102 messages telling us that "This call may be monitored for quality 2103 assurance". A ZRTP endpoint in such an environment might 2104 unilaterally disclose the session key to someone monitoring the call. 2105 ZRTP-enabled products that perform such out-of-band disclosures of 2106 the session key can undermine public confidence in the ZRTP protocol, 2107 unless we do everything we can in the protocol to alert the other 2108 user that this is happening. 2110 If one of the parties is using a product that is designed to disclose 2111 their session key, ZRTP requires them to confess this fact to the 2112 other party through a protocol message to the other party's ZRTP 2113 client, which can properly alert that user, perhaps by rendering it 2114 in a GUI. The disclosing party does this by sending a Disclosure 2115 flag (D) in Confirm1 and Confirm2 messages as described in Sections 2116 6.7 and 6.8. 2118 Note that the intention here is to have the Disclosure flag identify 2119 products that are designed to disclose their session keys, not to 2120 identify which particular calls are compromised on a call-by-call 2121 basis. This is an important legal distinction, because most 2122 government sanctioned wiretap regulations require a VoIP service 2123 provider to not reveal which particular calls are wiretapped. But 2124 there is nothing illegal about revealing that a product is designed 2125 to be wiretap-friendly. The ZRTP protocol mandates that such a 2126 product "out" itself. 2128 You might be using a ZRTP-enabled product with no back doors, but if 2129 your own GUI tells you the call is (mostly) secure, except that the 2130 other party is using a product that is designed in such a way that it 2131 may have disclosed the session key for monitoring purposes, you might 2132 ask him what brand of secure telephone he is using, and make a mental 2133 note not to purchase that brand yourself. If we create a protocol 2134 environment that requires such back-doored phones to confess their 2135 nature, word will spread quickly, and the "unseen hand" of the free 2136 market will act. The free market has effectively dealt with this in 2137 the past. 2139 Of course, a ZRTP implementer can lie about his product having a back 2140 door, but the ZRTP standard mandates that ZRTP-compliant products 2141 MUST adhere to the requirement that a back door be confessed by 2142 sending the Disclosure flag to the other party. 2144 There will be inevitable comparisons to Steve Bellovin's 2003 April 2145 fool's joke, when he submitted RFC 3514 [22] which defined the "Evil 2146 bit" in the IPV4 header, for packets with "evil intent". But we 2147 submit that a similar idea can actually have some merit for securing 2148 VoIP. Sure, one can always imagine that some implementer will not be 2149 fazed by the rules and will lie, but they would have lied anyway even 2150 without the Disclosure flag. There are good reasons to believe that 2151 it will improve the overall percentage of implementations that at 2152 least tell us if they put a back door in their products, and may even 2153 get some of them to decide not to put in a back door at all. From a 2154 civic hygiene perspective, we are better off with having the 2155 Disclosure flag in the protocol. 2157 If an endpoint stores or logs SRTP keys or information that can be 2158 used to reconstruct or recover SRTP keys after they are no longer in 2159 use (i.e. the session is active), or otherwise discloses or passes 2160 SRTP keys or information that can be used to reconstruct or recover 2161 SRTP keys to another application or device, the Disclosure flag D 2162 MUST be set in the Confirm1 or Confirm2 message. 2164 14. Appendix C - Intermediary ZRTP Devices 2166 This section discusses the operation of a ZRTP endpoint which is 2167 actually an intermediary. For example, consider a device which 2168 proxies both signaling and media between endpoints. There are three 2169 possible ways in which such a device could support ZRTP. 2171 An intermediary device can act transparently to the ZRTP protocol. 2172 To do this, a device MUST pass RTP header extensions and payloads (to 2173 allow the ZRTP Flag) and non-RTP protocols multiplexed on the same 2174 port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED 2175 behavior for intermediaries as ZRTP and SRTP are best when done end- 2176 to-end. 2178 An intermediary device could implement the ZRTP protocol and act as a 2179 ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary 2180 device. The intermediary could determine on a call-by-call basis 2181 whether the endpoint behind it supports ZRTP based on the presence or 2182 absence of the ZRTP SDP attribute flag (a=zrtp-id). For non-ZRTP 2183 endpoints, the intermediary device could act as the ZRTP endpoint 2184 using its own ZID and cache. This approach MUST only be used when 2185 there is some other security method protecting the confidentiality of 2186 the media between the intermediary and the inside endpoint, such as 2187 IPSec or physical security. 2189 The third mode, which is NOT RECOMMENDED, is for the intermediary 2190 device to attempt to back-to-back the ZRTP protocol. In this mode, 2191 the intermediary would attempt to act as a ZRTP endpoint towards both 2192 endpoints of the media session. This approach MUST NOT be used as it 2193 will always result in a detected Man-in-the-Middle attack and will 2194 generate alarms on both endpoints and likely result in the immediate 2195 termination of the session. It cannot be stated strongly enough that 2196 there are no usable back-to-back uses for the ZRTP protocol. 2198 In cases where centralized media mixing is taking place, the SAS will 2199 not match when compared by the humans. However, this situation is 2200 known in the SIP signaling by the presence of the isfocus feature tag 2201 [25]. As a result, when the isfocus feature tag is present, the SAS 2202 can only be verified by comparison in the signaling or by validating 2203 signatures in the Confirm. For example, consider a audio conference 2204 call with three participants Alice, Bob, and Carol hosted on a 2205 conference bridge in Dallas. There will be three ZRTP encrypted 2206 media streams between each participant and Dallas. Each will have a 2207 different SAS. Each participant will be able to validates their SAS 2208 with the conference bridge using a=zrtp-sas or Confirm messages 2209 containing signatures. 2211 SIP feature tags can also be used to detect if a session is 2212 established with an automaton such as an IVR, voicemail system, or 2213 speech recognition system. The display of SAS strings to users 2214 should be disabled in these cases. 2216 It is possible that an intermediary device acting as a ZRTP endpoint 2217 might still receive ZRTP Hello and other messages from the inside 2218 endpoint. This could occur if there is another inline ZRTP device 2219 which does not include the ZRTP SDP attribute flag. If this occurs, 2220 the intermediary MUST NOT pass these ZRTP messages if it is acting as 2221 the ZRTP endpoint. 2223 15. Appendix D - RTP Header Extension Flag for ZRTP 2225 This specification defines a new RTP header extension used only for 2226 discovery of support for ZRTP. No ZRTP data is transported in the 2227 extension. When used, the X bit is set in the RTP header to indicate 2228 the presence of the RTP header extension. 2230 Section 5.3.1 in RFC 3550 defines the format of an RTP Header 2231 extension. The Header extension is appended to the RTP header. The 2232 first 16 bits are an identifier for the header extension, and the 2233 following 16 bits are length of the extension header in 32 bit words. 2234 The ZRTP flag RTP header extension has the value of 0x505A and a 2235 length of 0. The format of the header extension is as shown in 2236 Figure 12. 2238 0 1 2 3 2239 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 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 |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| 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Figure 12. RTP Extension header format for ZRTP Flag 2246 ZRTP endpoints SHOULD include the ZRTP Flag in RTP packets sent at 2247 the start of a session. For example, including the flag in the first 2248 1 second of RTP packets sent. The inclusion of the flag MAY be ended 2249 if a ZRTP message (such as Hello) is received. 2251 16. References 2253 16.1. Normative References 2255 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2256 Levels", BCP 14, RFC 2119, March 1997. 2258 [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 2259 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 2260 RFC 3550, July 2003. 2262 [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2263 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2264 RFC 3711, March 2004. 2266 [4] McGrew, D., "The use of AES-192 and AES-256 in Secure RTP", 2267 draft-mcgrew-srtp-big-aes-00 (work in progress), April 2006. 2269 [5] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 2270 Diffie-Hellman groups for Internet Key Exchange (IKE)", 2271 RFC 3526, May 2003. 2273 [6] Stone, J., Stewart, R., and D. Otis, "Stream Control 2274 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 2275 September 2002. 2277 [7] Ferguson, N. and B. Schneier, "Practical Cryptography", Wiley 2278 Publishing 2003. 2280 [8] Barker, E. and J. Kelsey, "Recommendation for Random Number 2281 Generation Using Deterministic Random Bit Generators", NIST 2282 Special Publication 800-90 DRAFT (December 2005). 2284 [9] Wilcox, B., "Human-oriented base-32 encoding", http:// 2285 cvs.sourceforge.net/viewcvs.py/libbase32/libbase32/ 2286 DESIGN?rev=HEAD . 2288 [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2289 Description Protocol", RFC 4566, July 2006. 2291 [11] Dworkin, M., "Recommendation for Block Cipher: Methods and 2292 Techniques", NIST Special Publication 800-38A 2001 Edition. 2294 16.2. Informative References 2296 [12] Wing, D., "Media Security Requirements", 2297 draft-wing-media-security-requirements-00 (work in progress), 2298 October 2006. 2300 [13] Zimmermann, P., "PGPfone", 2301 http://www.pgpi.org/products/pgpfone/ . 2303 [14] Zimmermann, P., "Zfone", http://www.philzimmermann.com/zfone . 2305 [15] Blossom, E., "The VP1 Protocol for Voice Privacy Devices 2306 Version 1.2", http://www.comsec.com/vp1-protocol.pdf . 2308 [16] "CryptoPhone", http://www.cryptophone.de/ . 2310 [17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2311 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2312 Session Initiation Protocol", RFC 3261, June 2002. 2314 [18] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol 2315 Architecture", RFC 4251, January 2006. 2317 [19] Andreasen, F., Baugher, M., and D. Wing, "Session Description 2318 Protocol (SDP) Security Descriptions for Media Streams", 2319 RFC 4568, July 2006. 2321 [20] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 2322 Carrara, "Key Management Extensions for Session Description 2323 Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 2324 RFC 4567, July 2006. 2326 [21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 2327 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 2328 August 2004. 2330 [22] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, 2331 April 1 2003. 2333 [23] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2334 Identity Management in the Session Initiation Protocol (SIP)", 2335 RFC 4474, August 2006. 2337 [24] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 2338 Methodology for Network Address Translator (NAT) Traversal for 2339 Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in 2340 progress), January 2007. 2342 [25] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 2343 Call Control - Conferencing for User Agents", BCP 119, 2344 RFC 4579, August 2006. 2346 Authors' Addresses 2348 Philip Zimmermann 2349 Zfone Project 2351 Email: prz@mit.edu 2353 Alan Johnston (editor) 2354 Avaya 2355 St. Louis, MO 63124 2357 Email: alan@sipstation.com 2359 Jon Callas 2360 PGP Corporation 2362 Email: jon@pgp.com 2364 Full Copyright Statement 2366 Copyright (C) The IETF Trust (2007). 2368 This document is subject to the rights, licenses and restrictions 2369 contained in BCP 78, and except as set forth therein, the authors 2370 retain all their rights. 2372 This document and the information contained herein are provided on an 2373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2375 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2376 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2377 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2380 Intellectual Property 2382 The IETF takes no position regarding the validity or scope of any 2383 Intellectual Property Rights or other rights that might be claimed to 2384 pertain to the implementation or use of the technology described in 2385 this document or the extent to which any license under such rights 2386 might or might not be available; nor does it represent that it has 2387 made any independent effort to identify any such rights. Information 2388 on the procedures with respect to rights in RFC documents can be 2389 found in BCP 78 and BCP 79. 2391 Copies of IPR disclosures made to the IETF Secretariat and any 2392 assurances of licenses to be made available, or the result of an 2393 attempt made to obtain a general license or permission for the use of 2394 such proprietary rights by implementers or users of this 2395 specification can be obtained from the IETF on-line IPR repository at 2396 http://www.ietf.org/ipr. 2398 The IETF invites any interested party to bring to its attention any 2399 copyrights, patents or patent applications, or other proprietary 2400 rights that may cover technology that may be required to implement 2401 this standard. Please address the information to the IETF at 2402 ietf-ipr@ietf.org. 2404 Acknowledgment 2406 Funding for the RFC Editor function is provided by the IETF 2407 Administrative Support Activity (IASA).