RFC 6189
ZRTP: Media Path Key Agreement for Unicast Secure RTP
Pages: 115
Informational
Informational
Part 2 of 5 – Pages 10 to 42
4. Protocol Description
This section begins the normative description of the protocol. ZRTP MUST be multiplexed on the same ports as the RTP media packets. To support best effort encryption from the Media Security Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media lines in the initial offer/answer exchange. The ZRTP SDP attribute a=zrtp-hash defined in Section 8 SHOULD be used in all offers and answers to indicate support for the ZRTP protocol. ZRTP can be utilized by endpoints that do not have a common signaling protocol but both support SRTP and are relying on a gateway for conversion. As such, it is not always possible for the signaling protocol to relay the zrtp-hash as can be done using SIP. The Secure RTP/AVP (SAVP) profile MAY be used in subsequent offer/ answer exchanges after a successful ZRTP exchange has resulted in an SRTP session, or if it is known that the other endpoint supports this profile. Other profiles MAY also be used. The use of the RTP/SAVP profile has caused failures in negotiating best effort SRTP due to the limitations on negotiating profiles using SDP. This is why ZRTP supports the RTP/AVP profile and includes its own discovery mechanisms. In all key agreement modes, the initiator SHOULD NOT send RTP media after sending the Commit message, and it MUST NOT send SRTP media before receiving either the Conf2ACK or the first SRTP media (with a valid SRTP auth tag) from the responder. The responder SHOULD NOT send RTP media after receiving the Commit message, and MUST NOT send SRTP media before receiving the Confirm2 message.4.1. Discovery
During the ZRTP discovery phase, a ZRTP endpoint discovers if the other endpoint supports ZRTP and the supported algorithms and options. This information is transported in a Hello message, which is described in Section 5.2. ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers and answers, as defined in Section 8.
The Hello message includes the ZRTP version, Hash Type, Cipher Type, SRTP authentication tag type, Key Agreement Type, and Short Authentication String (SAS) algorithms that are supported. The Hello message also includes a hash image as described in Section 9. In addition, each endpoint sends and discovers ZIDs. The received ZID is used later in the protocol as an index into a cache of shared secrets that were previously negotiated and retained between the two parties. A Hello message can be sent at any time, but it is usually sent at the start of an RTP session to determine if the other endpoint supports ZRTP and also if the SRTP implementations are compatible. A Hello message is retransmitted using timer T1 and an exponential backoff mechanism detailed in Section 6 until the receipt of a HelloACK message or a Commit message. The use of the a=zrtp-hash SDP attribute to authenticate the Hello message is described in Section 8.1. If a Hello message, or any other ZRTP message, indicates that there is a synchronization source (SSRC) collision, an Error message (Section 5.9) MUST be sent with the Error Code indicating SSRC collision, and the ZRTP negotiation MUST be terminated. The procedures of RFC 3550, Section 8.2 [RFC3550], SHOULD be followed by both endpoints to resolve this condition, and if it is resolved, a new ZRTP secure session SHOULD be negotiated.4.1.1. Protocol Version Negotiation
This specification defines ZRTP version 1.10. Since new versions of ZRTP may be developed in the future, this specification defines a protocol version negotiation in this section. Each party declares what version of the ZRTP protocol they support via the version field in the Hello message (Section 5.2). If both parties have the same version number in their Hello messages, they can proceed with the rest of the protocol. To facilitate both parties reaching this state of protocol version agreement in their Hello messages, ZRTP should use information provided in the signaling layer, if available. If a ZRTP endpoint supports more than one version of the protocol, it SHOULD declare them all in a list of SIP SDP a=zrtp-hash attributes (defined in Section 8), listing separate hashes, with separate ZRTP version numbers in each item in the list. Both parties should inspect the list of ZRTP version numbers supplied by the other party in the SIP SDP a=zrtp-hash attributes. Both parties SHOULD choose the highest version number that appears in both parties' list of a=zrtp-hash version numbers, and use that version
for their Hello messages. If both parties use the SIP signaling in this manner, their initial Hello messages will have the same ZRTP version number, provided they both have at least one supported protocol version in common. Before the ZRTP key agreement can proceed, an endpoint MUST have sent and received Hellos with the same protocol version. It is best if the signaling layer is used to negotiate the protocol version number. However, the a=zrtp-hash SDP attribute is not always present in the SIP packet, as explained in Section 8.1. In the absence of any guidance from the signaling layer, an endpoint MUST send the highest supported version in initial Hello messages. If the two parties send different protocol version numbers in their Hello messages, they can reach an agreement to use a common version, if one exists. They iteratively apply the following rules until they both have matching version fields in their Hello messages and the key agreement can proceed: o If an endpoint receives a Hello message with an unsupported version number that is higher than the endpoint's current Hello message version, the received Hello message MUST be ignored. The endpoint continues to retransmit Hello messages on the standard retry schedule (Section 6). o If an endpoint receives a Hello message with a version number that is lower than the endpoint's current Hello message, and the endpoint supports a version that is less than or equal to the received version number, the endpoint MUST stop retransmitting the old version number and MUST start sending a Hello message with the highest supported version number that is less than or equal to the received version number. o If an endpoint receives a Hello message with an unsupported version number that is lower than the endpoint's current Hello message, the endpoint MUST send an Error message (Section 5.9) indicating failure to support this ZRTP version. The above comparisons are iterated until the version numbers match, or until it exits on a failure to match. For example, assume that Alice supports protocol versions 1.10 and 2.00, and Bob supports versions 1.10 and 1.20. Alice initially sends a Hello with version 2.00, and Bob initially sends a Hello with version 1.20. Bob ignores Alice's 2.00 Hello and continues to send his 1.20 Hellos. Alice detects that Bob does not support 2.00 and she stops sending her 2.00 Hellos and starts sending a stream of 1.10 Hellos. Bob sees the 1.10 Hello from Alice and stops sending his 1.20 Hellos and switches to sending 1.10 Hellos.
At that point, they have converged on using version 1.10 and the
protocol proceeds on that basis.
When comparing protocol versions, a ZRTP endpoint MUST include only
the first three octets of the version field in the comparison. The
final octet is ignored, because it is not significant for
interoperability. For example, "1.1 ", "1.10", "1.11", or "1.1a" are
all regarded as a version match, because they would all be
interoperable versions.
Changes in protocol version numbers are expected to be infrequent
after version 1.10. Supporting multiple versions adds code
complexity and may introduce security weaknesses in the
implementation. The old adage about keeping it simple applies
especially to implementing security protocols. Endpoints SHOULD NOT
support protocol versions earlier than version 1.10.
4.1.2. Algorithm Negotiation
A method is provided to allow the two parties to mutually and
deterministically choose the same DH key size and algorithm before a
Commit message is sent.
Each Hello message lists the algorithms in the order of preference
for that ZRTP endpoint. Endpoints eliminate the non-intersecting
choices from each of their own lists, resulting in each endpoint
having a list of algorithms in common that might or might not be
ordered the same as the other endpoint's list. Each endpoint
compares the first item on their own list with the first item on the
other endpoint's list and SHOULD choose the faster of the two
algorithms. For example:
o Alice's full list: DH2k, DH3k, EC25
o Bob's full list: EC38, EC25, DH3k
o Alice's intersecting list: DH3k, EC25
o Bob's intersecting list: EC25, DH3k
o Alice's first choice is DH3k, and Bob's first choice is EC25.
o Thus, both parties choose EC25 (ECDH-256) because it's faster.
To decide which DH algorithm is faster, the following ranking, from
fastest to slowest is defined: DH-2048, ECDH-256, DH-3072, ECDH-384,
ECDH-521. These are all defined in Section 5.1.5.
If both endpoints follow this method, they may each start their DH calculations as soon as they receive the Hello message, and there will be no need for either endpoint to discard their DH calculation if the other endpoint becomes the initiator. This method is used only to negotiate DH key size. For the rest of the algorithm choices, it's simply whatever the initiator selects from the algorithms in common. Note that the DH key size influences the Hash Type and the size of the symmetric cipher key, as explained in Section 5.1.5. Unfavorable choices will never be made by this method, because each endpoint will omit from their respective lists choices that are too slow or not secure enough to meet their security policy.4.2. Commit Contention
After both parties have received compatible Hello messages, a Commit message (Section 5.4) can be sent to begin the ZRTP key exchange. The endpoint that sends the Commit is known as the initiator, while the receiver of the Commit is known as the responder. If both sides send Commit messages initiating a secure session at the same time, the following rules are used to break the tie: o If one Commit is for a DH mode while the other is for Preshared mode, then the Preshared Commit MUST be discarded and the DH Commit proceeds. o If the two Commits are both Preshared mode, and one party has set the MiTM (M) flag in the Hello message and the other has not, the Commit message from the party who set the (M) flag MUST be discarded, and the one who has not set the (M) flag becomes the initiator, regardless of the nonce values. In other words, for Preshared mode, the phone is the initiator and the PBX is the responder. o If the two Commits are either both DH modes or both non-DH modes, then the Commit message with the lowest hvi (hash value of initiator) value (for DH Commits), or lowest nonce value (for non-DH Commits), MUST be discarded and the other side is the initiator, and the protocol proceeds with the initiator's Commit. The two hvi or nonce values are compared as large unsigned integers in network byte order. If one Commit is for Multistream mode while the other is for non- Multistream (DH or Preshared) mode, a software error has occurred and the ZRTP negotiation should be terminated. This should never occur
because of the constraints on Multistream mode described in Section 4.4.3. In the event that Commit messages are sent by both ZRTP endpoints at the same time, but are received in different media streams, the same resolution rules apply as if they were received on the same stream. The media stream in which the Commit was received or sent will proceed through the ZRTP exchange while the media stream with the discarded Commit must wait for the completion of the other ZRTP exchange. If a commit contention forces a DH Commit message to be discarded, the responder's DH public value should only be discarded if it does not match the initiator's DH key size. This will not happen if both endpoints choose a common key size via the method described in Section 4.1.2.4.3. Matching Shared Secret Determination
The following sections describe how ZRTP endpoints generate and/or use the set of shared secrets s1, auxsecret, and pbxsecret through the exchange of the DHPart1 and DHPart2 messages. This doesn't cover the Diffie-Hellman calculations. It only covers the method whereby the two parties determine if they already have shared secrets in common in their caches. Each ZRTP endpoint maintains a long-term cache of shared secrets that it has previously negotiated with the other party. The ZID of the other party, received in the other party's Hello message, is used as an index into this cache to find the set of shared secrets, if any exist. This cache entry may contain previously retained shared secrets, rs1 and rs2, which give ZRTP its key continuity features. If the other party is a PBX, the cache may also contain a trusted MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1. The DHPart1 and DHPart2 messages contain a list of hashes of these shared secrets to allow the two endpoints to compare the hashes with what they have in their caches to detect whether the two sides share any secrets that can be used in the calculation of the session key. The use of this shared secret cache is described in Section 4.9. If no secret of a given type is available, a random value is generated and used for that secret to ensure a mismatch in the hash comparisons in the DHPart1 and DHPart2 messages. This prevents an eavesdropper from knowing which types of shared secrets are available between the endpoints.
Section 4.3.1 refers to the auxiliary shared secret auxsecret. The auxsecret shared secret may be defined by the VoIP user agent out-of- band from the ZRTP protocol. In some cases, it may be provided by the signaling layer as srtps, which is defined in Section 8.2. If it is not provided by the signaling layer, the auxsecret shared secret may be manually provisioned in other application-specific ways that are out of band, such as computed from a hashed pass phrase by prior agreement between the two parties or supplied by a hardware token. Or, it may be a family key used by an institution to which the two parties both belong. It is a generalized mechanism for providing a shared secret that is agreed to between the two parties out of scope of the ZRTP protocol. It is expected that most typical ZRTP endpoints will rarely use auxsecret. For both the initiator and the responder, the shared secrets s1, s2, and s3 will be calculated so that they can all be used later to calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are calculated by both parties. The shared secret s1 will be either the initiator's rs1 or the initiator's rs2, depending on which of them can be found in the responder's cache. If the initiator's rs1 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only if that match fails, then if the initiator's rs2 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. If that match also fails, then s1 MUST be set to null. The complexity of the s1 calculation is to recover from any loss of cache sync from an earlier aborted session, due to the Two Generals' Problem [Byzantine]. The shared secret s2 MUST be set to the value of auxsecret if and only if both parties have matching values for auxsecret, as determined by comparing the hashes of auxsecret sent in the DH messages. If they don't match, s2 MUST be set to null. The shared secret s3 MUST be set to the value of pbxsecret if and only if both parties have matching values for pbxsecret, as determined by comparing the hashes of pbxsecret sent in the DH messages. If they don't match, s3 MUST be set to null. If s1, s2, or s3 have null values, they are assumed to have a zero length for the purposes of hashing them later during the s0 calculation in Section 4.4.1.4. The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is described in Section 4.3.1.
4.3.1. Calculation and Comparison of Hashes of Shared Secrets
Both parties calculate a set of non-invertible hashes (implemented via the MAC defined in Section 5.1.2.1) of shared secrets that may be present in each of their caches. These hashes are truncated to the leftmost 64 bits: rs1IDr = MAC(rs1, "Responder") rs2IDr = MAC(rs2, "Responder") auxsecretIDr = MAC(auxsecret, Responder's H3) pbxsecretIDr = MAC(pbxsecret, "Responder") rs1IDi = MAC(rs1, "Initiator") rs2IDi = MAC(rs2, "Initiator") auxsecretIDi = MAC(auxsecret, Initiator's H3) pbxsecretIDi = MAC(pbxsecret, "Initiator") The responder sends rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr in the DHPart1 message. The initiator sends rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi in the DHPart2 message. The responder uses the locally computed rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi to compare against the corresponding fields in the received DHPart2 message. The initiator uses the locally computed rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr to compare against the corresponding fields in the received DHPart1 message. From these comparisons, s1, s2, and s3 are calculated per the methods described in Section 4.3. The secrets corresponding to matching hashes are kept while the secrets corresponding to the non-matching ones are replaced with a null, which is assumed to have a zero length for the purposes of hashing them later. The resulting s1, s2, and s3 values are used later to calculate s0 in Section 4.4.1.4. For example, consider two ZRTP endpoints who share secrets rs1 and pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID and pbxsecretID will match but auxsecretID will not. As a result, s1 = rs1, s2 will be null, and s3 = pbxsecret.
4.3.2. Handling a Shared Secret Cache Mismatch
A shared secret cache mismatch is defined to mean that we expected a cache match because rs1 exists in our local cache, but we computed a null value for s1 (per the method described in Section 4.3). If one party has a cached shared secret and the other party does not, this indicates one of two possible situations. Either there is a MiTM attack or one of the legitimate parties has lost their cached shared secret by some mishap. Perhaps they inadvertently deleted their cache or their cache was lost or disrupted due to restoring their disk from an earlier backup copy. The party that has the surviving cache entry can easily detect that a cache mismatch has occurred, because they expect their own cached secret to match the other party's cached secret, but it does not match. It is possible for both parties to detect this condition if both parties have surviving cached secrets that have fallen out of sync, due perhaps to one party restoring from a disk backup. If either party discovers a cache mismatch, the user agent who makes this discovery must treat this as a possible security event and MUST alert their own user that there is a heightened risk of a MiTM attack, and that the user should verbally compare the SAS with the other party to ascertain that no MiTM attack has occurred. If a cache mismatch is detected and it is not possible to compare the SAS, either because the user interface does not support it or because one or both endpoints are unmanned devices, and no other SAS comparison mechanism is available, the session MAY be terminated. The session need not be terminated on a cache mismatch event if: o the mechanism described in Section 8.1.1 is available, which allows authentication of the DH exchange without human assistance, or o any mechanism is available to determine if the SAS matches. This would require either circumstances that allow human verbal comparisons of the SAS or by use of the OPTIONAL digital signature feature on the SAS hash, as described in Section 7.2. Even if the user interface does not permit an SAS comparison, the human user MUST be warned and may elect to proceed with the call at their own risk. If and only if a cache mismatch event occurs, the cache update mechanism in Section 4.6.1 is affected, requiring the user to verify the SAS before the cache is updated. The user will thus be alerted of this security condition on every call until the SAS is verified.
This is described in Section 4.6.1.1. Here is a non-normative example of a cache-mismatch alert message from a ZRTP user agent (specifically, [Zfone]), designed for a desktop PC graphical user interface environment. It is by no means required that the alert be this detailed: We expected the other party to have a shared secret cached from a previous call, but they don't have it. This may mean your partner simply lost his cache of shared secrets, but it could also mean someone is trying to wiretap you. To resolve this question you must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper. If the alert is rendered by a robot voice instead of a GUI, brevity may be more important: Something's wrong. You must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper. A mismatch of auxsecret is handled differently than a mismatch of rs1. An auxsecret mismatch is defined to mean that auxsecret exists locally, but we computed a null value for s2 (per the method described in Section 4.3). This mismatch should be made visible to whichever user has auxsecret defined. The mismatch should be made visible to both users if they both have auxsecret defined but they fail to match. The severity of the user notification is implementation dependent. Aborting the session is not required. If auxsecret matches, it should not excuse a mismatch of rs1, which still requires a strong warning to the user.4.4. DH and Non-DH Key Agreements
The next step is the generation of a secret for deriving SRTP keying material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, described in the following subsections.4.4.1. Diffie-Hellman Mode
The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP endpoints to generate a new shared secret, s0. In addition, the endpoints discover if they have any cached or previously stored shared secrets in common, and it uses them as part of the calculation of the session keys.
Because the DH exchange affects the state of the retained shared secret cache, only one in-process ZRTP DH exchange may occur at a time between two ZRTP endpoints. Otherwise, race conditions and cache integrity problems will result. When multiple media streams are established in parallel between the same pair of ZRTP endpoints (determined by the ZIDs in the Hello messages), only one can be processed. Once that exchange completes with Confirm2 and Conf2ACK messages, another ZRTP DH exchange can begin. This constraint does not apply when Multistream mode key agreement is used since the cached shared secrets are not affected.4.4.1.1. Hash Commitment in Diffie-Hellman Mode
From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used. A Diffie-Hellman mode is selected by setting the Key Agreement Type in the Commit to one of the DH or Elliptic Curve Diffie-Hellman (ECDH) values from the table in Section 5.1.5. In this mode, the key agreement begins with the initiator choosing a fresh random Diffie- Hellman (DH) secret value (svi) based on the chosen Key Agreement Type value, and computing the public value. (Note that to speed up processing, this computation can be done in advance.) For guidance on generating random numbers, see Section 4.8. For Finite Field Diffie-Hellman, the value for the DH generator g, the DH prime p, and the length of the DH secret value, svi, are defined in Section 5.1.5. pvi = g^svi mod p where g and p are determined by the Key Agreement Type value. The DH public value pvi value is formatted as a big-endian octet string and fixed to the bit-length of the DH prime; leading zeros MUST NOT be truncated. For Elliptic Curve DH, pvi is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A [NIST-SP800-56A]. The hash commitment is performed by the initiator of the ZRTP exchange. The hash value of the initiator, hvi, includes a hash of the entire DHPart2 message as shown in Figure 9 (which includes the Diffie-Hellman public value, pvi), and the responder's Hello message (where '||' means concatenation). The hvi hash is truncated to 256 bits:
hvi = hash(initiator's DHPart2 message ||
responder's Hello message)
Note that the Hello message includes the fields shown in Figure 3.
The information from the responder's Hello message is included in the
hash calculation to prevent a bid-down attack by modification of the
responder's Hello message.
The initiator sends the hvi in the Commit message.
The use of hash commitment in the DH exchange constrains the attacker
to only one guess to generate the correct Short Authentication String
(SAS) (Section 7) in his attack, which means the SAS can be quite
short. A 16-bit SAS, for example, provides the attacker only one
chance out of 65536 of not being detected. Without this hash
commitment feature, a MiTM attacker would acquire both the pvi and
pvr public values from the two parties before having to choose his
own two DH public values for his MiTM attack. He could then use that
information to quickly perform a bunch of trial DH calculations for
both sides until he finds two with a matching SAS. To raise the cost
of this birthday attack, the SAS would have to be much longer. The
Short Authentication String would have to become a Long
Authentication String, which would be unacceptable to the user. A
hash commitment precludes this attack by forcing the MiTM to choose
his own two DH public values before learning the public values of
either of the two parties.
4.4.1.2. Responder Behavior in Diffie-Hellman Mode
Upon receipt of the Commit message, the responder generates its own
fresh random DH secret value, svr, and computes the public value.
(Note that to speed up processing, this computation can be done in
advance, with no need to discard this computation if both endpoints
chose the same algorithm via Section 4.1.2.) For guidance on random
number generation, see Section 4.8.
For Finite Field Diffie-Hellman, the value for the DH generator g,
the DH prime p, and the length of the DH secret value, svr, are
defined in Section 5.1.5.
pvr = g^svr mod p
The pvr value is formatted as a big-endian octet string, fixed to the
bit-length of the DH prime; leading zeros MUST NOT be truncated.
For Elliptic Curve DH, pvr is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A. Upon receipt of the DHPart2 message, the responder checks that the initiator's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart2 message with a value of 1 or p-1 for g^svi mod p, which would cause a disastrously weak final DH result to be computed. If pvi is 1 or p-1, the user SHOULD be alerted of the attack and the protocol exchange MUST be terminated. Otherwise, the responder computes its own value for the hash commitment using the DH public value (pvi) received in the DHPart2 message and its own Hello message and compares the result with the hvi received in the Commit message. If they are different, a MiTM attack is taking place and the user is alerted and the protocol exchange terminated. The responder then calculates the Diffie-Hellman result: DHResult = pvi^svr mod p4.4.1.3. Initiator Behavior in Diffie-Hellman Mode
Upon receipt of the DHPart1 message, the initiator checks that the responder's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart1 message with a value of 1 or p-1 for g^svr mod p, which would cause a disastrously weak final DH result to be computed. If pvr is 1 or p-1, the user should be alerted of the attack and the protocol exchange MUST be terminated. The initiator then sends a DHPart2 message containing the initiator's DH public value and the set of calculated shared secret IDs as defined in Section 4.3.1. The initiator calculates the same Diffie-Hellman result using: DHResult = pvr^svi mod p4.4.1.4. Shared Secret Calculation for DH Mode
A hash of the received and sent ZRTP messages in the current ZRTP exchange in the following order is calculated by both parties: total_hash = hash(Hello of responder || Commit || DHPart1 || DHPart2) Note that only the ZRTP messages (Figures 3, 5, 8, and 9), not the entire ZRTP packets, are included in the total_hash.
For both the initiator and responder, the DHResult is formatted as a big-endian octet string and fixed to the width of the DH prime; leading zeros MUST NOT be truncated. For example, for a 3072-bit p, DHResult would be a 384 octet value, with the first octet the most significant. DHResult may also be the result of an ECDH calculation, which is discussed in Section 5.1.5. Key | Size of Agreement | DHResult ------------------------ DH-3072 | 384 octets ------------------------ DH-2048 | 256 octets ------------------------ ECDH P-256 | 32 octets ------------------------ ECDH P-384 | 48 octets ------------------------ The authors believe the calculation of the final shared secret, s0, is in compliance with the recommendations in Sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A [NIST-SP800-56A]. This is done by hashing a concatenation of a number of items, including the DHResult, the ZID's of the initiator (ZIDi) and the responder (ZIDr), the total_hash, and the set of non-null shared secrets as described in Section 4.3. In Section 5.8.1 of [NIST-SP800-56A], NIST requires certain parameters to be hashed together in a particular order, which NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash corresponds to SuppPubInfo, and the set of three shared secrets s1, s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit big-endian integer counter to be included in the hash each time the hash is computed, which we have set to the fixed value of 1 because we only compute the hash once. NIST refers to the final hash output as DerivedKeyingMaterial, which corresponds to our s0 in this calculation. s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi || ZIDr || total_hash || len(s1) || s1 || len(s2) || s2 || len(s3) || s3)
Note that temporary values s1, s2, and s3 were calculated per the methods described in Section 4.3. DHResult, s1, s2, and s3 MUST all be erased from memory immediately after they are used to calculate s0. The length of the DHResult field was implicitly agreed to by the negotiated DH prime size. The length of total_hash is implicitly determined by the negotiated hash algorithm. All of the explicit length fields, len(), in the above hash are 32-bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (s1, s2, and s3) may have lengths of zero if they are null (not shared) and are each preceded by a 4-octet length field. For example, if s2 is null, len(s2) is 0x00000000, and s2 itself would be absent from the hash calculation, which means len(s3) would immediately follow len(s2). While inclusion of ZIDi and ZIDr may be redundant, because they are implicitly included in the total_hash, we explicitly include them here to follow NIST SP 800-56A. The fixed-length string "ZRTP-HMAC- KDF" (not null-terminated) identifies for what purpose the resulting s0 will be used, which is to serve as the key derivation key for the ZRTP HMAC-based key derivation function (KDF) defined in Section 4.5.1 and used in Section 4.5.3. The authors believe ZRTP DH mode is in full compliance with two relevant NIST documents that cover key derivations. First, Section 5.8.1 of [NIST-SP800-56A] computes what NIST refers to as DerivedKeyingMaterial, which ZRTP refers to as s0. This s0 then serves as the key derivation key, which NIST refers to as KI in the key derivation function described in Sections 5 and 5.1 of [NIST-SP800-108], to derive all the rest of the subkeys needed by ZRTP. For ECDH mode, the authors believe the s0 calculation is also in compliance with Section 3.1 of the National Security Agency's (NSA's) Suite B Implementer's Guide to NIST SP 800-56A [NSA-Suite-B-Guide-56A]. The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message. KDF_Context = (ZIDi || ZIDr || total_hash) At this point in DH mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.
4.4.2. Preshared Mode
The Preshared key agreement mode can be used to generate SRTP keys and salts without a DH calculation, instead relying on a shared secret from previous DH calculations between the endpoints. This key agreement mode is useful to rapidly re-establish a secure session between two parties who have recently started and ended a secure session that has already performed a DH key agreement, without performing another lengthy DH calculation, which may be desirable on slow processors in resource-limited environments. Preshared mode MUST NOT be used for adding additional media streams to an existing call. Multistream mode MUST be used for this purpose. In the most severe resource-limited environments, Preshared mode may be useful with processors that cannot perform a DH calculation in an ergonomically acceptable time limit. Shared key material may be manually provisioned between two such endpoints in advance and still allow a limited subset of functionality. Such a "better than nothing" implementation would have to be regarded as non-compliant with the ZRTP specification, but it could interoperate in Preshared (and if applicable, Multistream) mode with a compliant ZRTP endpoint. Because Preshared mode affects the state of the retained shared secret cache, only one in-process ZRTP Preshared exchange may occur at a time between two ZRTP endpoints. This rule is explained in more detail in Section 4.4.1, and applies for the same reasons as in DH mode. Preshared mode is only included in this specification to meet the R-REUSE requirement in the Media Security Requirements [RFC5479] document. A series of preshared-keyed calls between two ZRTP endpoints should use a DH key exchange periodically. Preshared mode is only used if a cached shared secret has been established in an earlier session by a DH exchange, as discussed in Section 4.9.4.4.2.1. Commitment in Preshared Mode
Preshared mode is selected by setting the Key Agreement Type to Preshared in the Commit message. This results in the same call flow as Multistream mode. The principal difference between Multistream mode and Preshared mode is that Preshared mode uses a previously cached shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess, as the initial keying material. Preshared mode depends on having a reliable shared secret in its cache. Before Preshared mode is used, the initial DH exchange that gave rise to the shared secret SHOULD have used at least one of these
anti-MiTM mechanisms: 1) A verbal comparison of the SAS, evidenced by the SAS Verified flag, or 2) an end-to-end integrity-protected delivery of the a=zrtp-hash in the signaling (Section 8.1.1), or 3) a digital signature on the sashash (Section 7.2).4.4.2.2. Initiator Behavior in Preshared Mode
The Commit message (Figure 7) is sent by the initiator of the ZRTP exchange. From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used. To assemble a Preshared commit, we must first construct a temporary preshared_key, which is constructed from one of several possible combinations of cached key material, depending on what is available in the shared secret cache. If rs1 is not available in the initiator's cache, then Preshared mode MUST NOT be used. preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || auxsecret || len(pbxsecret) || pbxsecret) All of the explicit length fields, len(), in the above hash are 32- bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (rs1, auxsecret, and pbxsecret) may have lengths of zero if they are null (not available), and are each preceded by a 4-octet length field. For example, if auxsecret is null, len(auxsecret) is 0x00000000, and auxsecret itself would be absent from the hash calculation, which means len(pbxsecret) would immediately follow len(auxsecret). In place of hvi in the Commit message, two smaller fields are inserted by the initiator: - A random nonce of length 4 words (16 octets). - A keyID = MAC(preshared_key, "Prsh") truncated to 64 bits. Note: Since the nonce is used to calculate different SRTP key and salt pairs for each session, a duplication will result in the same key and salt being generated for the two sessions, which would have disastrous security consequences.4.4.2.3. Responder Behavior in Preshared Mode
The responder uses the received keyID to search for matching key material in its cache. It does this by computing a preshared_key value and keyID value using the same formula as the initiator, depending on what is available in the responder's local cache. If
the locally computed keyID does not match the received keyID in the Commit, the responder recomputes a new preshared_key and keyID from a different subset of shared keys from the cache, dropping auxsecret, pbxsecret, or both from the hash calculation, until a matching preshared_key is found or it runs out of possibilities. Note that rs2 is not included in the process. If it finds the appropriate matching shared key material, it is used to derive s0 and a new ZRTPSess key, as described in the next section on shared secret calculation, Section 4.4.2.4. If the responder determines that it does not have a cached shared secret from a previous DH exchange, or it fails to match the keyID hash from the initiator with any combination of its shared keys, it SHOULD respond with its own DH Commit message. This would reverse the roles and the responder would become the initiator, because the DH Commit must always "trump" the Preshared Commit message as described in Section 4.2. The key exchange would then proceed using DH mode. However, if a severely resource-limited responder lacks the computing resources to respond in a reasonable time with a DH Commit, it MAY respond with a ZRTP Error message (Section 5.9) indicating that no shared secret is available. If both sides send Preshared Commit messages initiating a secure session at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds. In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.4.4.2.4. Shared Secret Calculation for Preshared Mode
Preshared mode requires that the s0 and ZRTPSess keys be derived from the preshared_key, and this must be done in a way that guarantees uniqueness for each session. This is done by using nonce material from both parties: the explicit nonce in the initiator's Preshared Commit message (Figure 7) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each session. A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated: total_hash = hash(Hello of responder || Commit)
Note that only the ZRTP messages (Figures 3 and 7), not the entire ZRTP packets, are included in the total_hash. The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message. KDF_Context = (ZIDi || ZIDr || total_hash) The s0 key is derived via the ZRTP key derivation function (Section 4.5.1) from preshared_key and the nonces implicitly included in the total_hash. The nonces also ensure KDF_Context is unique for each session, which is critical for security. s0 = KDF(preshared_key, "ZRTP PSK", KDF_Context, negotiated hash length) The preshared_key MUST be erased as soon as it has been used to calculate s0. At this point in Preshared mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.4.4.3. Multistream Mode
The Multistream key agreement mode can be used to generate SRTP keys and salts for additional media streams established between a pair of endpoints. Multistream mode cannot be used unless there is an active SRTP session established between the endpoints, which means a ZRTP Session key is active. This ZRTP Session key can be used to generate keys and salts without performing another DH calculation. In this mode, the retained shared secret cache is not used or updated. As a result, multiple ZRTP Multistream mode exchanges can be processed in parallel between two endpoints. Multistream mode is also used to resume a secure call that has gone clear using a GoClear message as described in Section 4.7.2.1. When adding additional media streams to an existing call, Multistream mode MUST be used. The first media stream MUST use either DH mode or Preshared mode. Only one DH exchange or Preshared exchange is performed, just for the first media stream. The DH exchange or Preshared exchange MUST be completed for the first media stream before Multistream mode is used to add any other media streams. In a
Multistream session, a ZRTP endpoint MUST use the same ZID for all media streams, matching the ZID used in the first media stream.4.4.3.1. Commitment in Multistream Mode
Multistream mode is selected by the initiator setting the Key Agreement Type to "Mult" in the Commit message (Figure 6). The Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be set by the initiator to the same as the values as in the initial DH Mode Commit. The SAS Type is ignored as there is no SAS authentication in this mode. Note: This requirement is needed since some endpoints cannot support different SRTP algorithms for different media streams. However, in the case of Multistream mode being used to go secure after a GoClear, the requirement to use the same SRTP algorithms is relaxed if there are no other active SRTP sessions. In place of hvi in the Commit, a random nonce of length 4 words (16 octets) is chosen. Its value MUST be unique for all nonce values chosen for active ZRTP sessions between a pair of endpoints. If a Commit is received with a reused nonce value, the ZRTP exchange MUST be immediately terminated. Note: Since the nonce is used to calculate different SRTP key and salt pairs for each media stream, a duplication will result in the same key and salt being generated for the two media streams, which would have disastrous security consequences. If a Commit is received selecting Multistream mode, but the responder does not have a ZRTP Session Key available, the exchange MUST be terminated. Otherwise, the responder proceeds to the next section on shared secret calculation, Section 4.4.3.2. If both sides send Multistream Commit messages at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds. In Multistream mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.4.4.3.2. Shared Secret Calculation for Multistream Mode
In Multistream mode, each media stream requires that a set of keys be derived from the ZRTPSess key, and this must be done in a way that guarantees uniqueness for each media stream. This is done by using
nonce material from both parties: the explicit nonce in the initiator's Multistream Commit message (Figure 6) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each media stream. A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated: total_hash = hash(Hello of responder || Commit) This refers to the Hello and Commit messages for the current media stream, which is using Multistream mode, not the original media stream that included a full DH key agreement. Note that only the ZRTP messages (Figures 3 and 6), not the entire ZRTP packets, are included in the hash. The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message. KDF_Context = (ZIDi || ZIDr || total_hash) The current stream's SRTP keys and salts for the initiator and responder are calculated using the ZRTP Session Key ZRTPSess and the nonces implicitly included in the total_hash. The nonces also ensure that KDF_Context will be unique for each media stream, which is critical for security. For each additional media stream, a separate s0 is derived from ZRTPSess via the ZRTP key derivation function (Section 4.5.1): s0 = KDF(ZRTPSess, "ZRTP MSK", KDF_Context, negotiated hash length) Note that the ZRTPSess key was previously derived from material that also includes a different and more inclusive total_hash from the entire packet sequence that performed the original DH exchange for the first media stream in this ZRTP session. At this point in Multistream mode, the two endpoints begin key derivations in Section 4.5.3.
4.5. Key Derivations
4.5.1. The ZRTP Key Derivation Function
To derive keys from a shared secret, ZRTP uses an HMAC-based key derivation function, or KDF. It is used throughout Section 4.5.3 and in other sections. The HMAC function for the KDF is based on the negotiated hash algorithm defined in Section 5.1.2. The authors believe the ZRTP KDF is in full compliance with the recommendations in NIST SP 800-108 [NIST-SP800-108]. Section 7.5 of the NIST document describes "key separation", which is a security requirement for the cryptographic keys derived from the same key derivation key. The keys shall be separate in the sense that the compromise of some derived keys will not degrade the security strength of any of the other derived keys or the security strength of the key derivation key. Strong preimage resistance is provided. The ZRTP KDF runs the NIST pseudorandom function (PRF) in counter mode, with only a single iteration of the counter. The NIST PRF is based on the HMAC function. The ZRTP KDF never has to generate more than 256 bits (or 384 bits for Suite B applications) of output key material, so only a single invocation of the HMAC function is needed. The ZRTP KDF is defined in this manner, per Sections 5 and 5.1 of [NIST-SP800-108]: KDF(KI, Label, Context, L) = HMAC(KI, i || Label || 0x00 || Context || L) The HMAC in the KDF is keyed by KI, which is a secret key derivation key that is unknown to the wiretapper (for example, s0). The HMAC is computed on a concatenated set of nonsecret fields that are defined as follows. The first field is a 32-bit big-endian integer counter (i) required by NIST to be included in the HMAC each time the HMAC is computed, which we have set to the fixed value of 0x000001 because we only compute the HMAC once. Label is a string of nonzero octets that identifies the purpose for the derived keying material. The octet 0x00 is a delimiter required by NIST. The NIST KDF formula has a "Context" field that includes ZIDi, ZIDr, and some optional nonce material known to both parties. L is a 32-bit big-endian positive integer, not to exceed the length in bits of the output of the HMAC. The output of the KDF is truncated to the leftmost L bits. If SHA- 384 is the negotiated hash algorithm, the HMAC would be HMAC-SHA-384; thus, the maximum value of L would be 384, the negotiated hash length.
The ZRTP KDF is not to be confused with the SRTP KDF defined in [RFC3711].4.5.2. Deriving ZRTPSess Key and SAS in DH or Preshared Modes
Both DH mode and Preshared mode (but not Multistream mode) come to this common point in the protocol to derive ZRTPSess and the SAS from s0, via the ZRTP Key Derivation Function (Section 4.5.1). At this point, s0 has been calculated, as well as KDF_Context. These calculations are done only for the first media stream, not for Multistream mode. The ZRTPSess key is used only for these two purposes: 1) to generate the additional s0 keys (Section 4.4.3.2) for adding additional media streams to this session in Multistream mode, and 2) to generate the pbxsecret (Section 7.3.1) that may be cached for use in future sessions. The ZRTPSess key is kept for the duration of the call signaling session between the two ZRTP endpoints. That is, if there are two separate calls between the endpoints (in SIP terms, separate SIP dialogs), then a ZRTP Session Key MUST NOT be used across the two call signaling sessions. ZRTPSess MUST be destroyed no later than the end of the call signaling session. ZRTPSess = KDF(s0, "ZRTP Session Key", KDF_Context, negotiated hash length) Note that KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate ZRTPSess. There is only one Short Authentication String (SAS) (Section 7) computed per call, which is applicable to all media streams derived from a single DH key agreement in a ZRTP session. KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate sashash. sashash = KDF(s0, "SAS", KDF_Context, 256) sasvalue = sashash [truncated to leftmost 32 bits] Despite the exposure of the SAS to the two parties, the rest of the keying material is protected by the key separation properties of the KDF (Section 4.5.1). ZRTP-enabled VoIP clients may need to support additional forms of communication, such as text chat, instant messaging, or file transfers. These other forms of communication may need to be encrypted, and would benefit from leveraging the ZRTP key exchange used for the VoIP part of the call. In that case, more key material
MAY be derived and "exported" from the ZRTP protocol and provided as
a shared secret to the VoIP client for these non-VoIP purposes. The
application can use this exported key in application-specific ways,
outside the scope of the ZRTP protocol.
ExportedKey = KDF(s0, "Exported key", KDF_Context,
negotiated hash length)
Only one ExportedKey is computed per call. KDF_Context is unique for
each media stream, but only the first media stream is permitted to
calculate ExportedKey.
The application may use this exported key to derive other subkeys for
various non-ZRTP purposes, via a KDF using separate KDF label strings
defined by the application. This key or its derived subkeys can be
used for encryption, or used to authenticate other key exchanges
carried out by the application, protected by ZRTP's MiTM defense
umbrella. The exported key and its descendants may be used for as
long as needed by the application, maintained in a separate crypto
context that may outlast the VoIP session.
At this point in DH mode or Preshared mode, the two endpoints proceed
on to the key derivations in Section 4.5.3, now that there is a
defined s0 and ZRTPSess key.
4.5.3. Deriving the Rest of the Keys from s0
DH mode, Multistream mode, and Preshared mode all come to this common
point in the protocol to derive a set of keys from s0. It can be
assumed that s0 has been calculated, as well the ZRTPSess key and
KDF_Context. A separate s0 key is associated with each media stream.
Subkeys are not drawn directly from s0, as done in NIST SP 800-56A.
To enhance key separation, ZRTP uses s0 to key a Key Derivation
Function (Section 4.5.1) based on [NIST-SP800-108]. Since s0 already
included total_hash in its derivation, it is redundant to use
total_hash again in the KDF Context in all the invocations of the KDF
keyed by s0. Nonetheless, NIST SP 800-108 always requires KDF
Context to be defined for the KDF, and nonce material is required in
some KDF invocations (especially for Multistream mode and Preshared
mode), so total_hash is included as a nonce in the KDF Context.
Separate SRTP master keys and master salts are derived for use in
each direction for each media stream. Unless otherwise specified,
ZRTP uses SRTP with no Master Key Identifier (MKI), 32-bit
authentication using HMAC-SHA1, AES-CM 128 or 256-bit key length,
112-bit session salt key length, 2^48 key derivation rate, and SRTP
prefix length 0. Secure RTCP (SRTCP) is also used, deriving the
SRTCP keys from the same master keys and salts as SRTP, using the mechanisms specified in [RFC3711], without requiring a separate ZRTP negotiation for RTCP. The ZRTP initiator encrypts and the ZRTP responder decrypts packets by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts and the ZRTP initiator decrypts packets by using srtpkeyr and srtpsaltr. The SRTP key and salt values are truncated (taking the leftmost bits) to the length determined by the chosen SRTP profile. These are generated by: srtpkeyi = KDF(s0, "Initiator SRTP master key", KDF_Context, negotiated AES key length) srtpsalti = KDF(s0, "Initiator SRTP master salt", KDF_Context, 112) srtpkeyr = KDF(s0, "Responder SRTP master key", KDF_Context, negotiated AES key length) srtpsaltr = KDF(s0, "Responder SRTP master salt", KDF_Context, 112) The MAC keys are the same length as the output of the underlying hash function in the KDF and are thus generated without truncation. They are used only by ZRTP and not by SRTP. Different MAC keys are needed for the initiator and the responder to ensure that GoClear messages in each direction are unique and can not be cached by an attacker and reflected back to the endpoint. mackeyi = KDF(s0, "Initiator HMAC key", KDF_Context, negotiated hash length) mackeyr = KDF(s0, "Responder HMAC key", KDF_Context, negotiated hash length) ZRTP keys are generated for the initiator and responder to use to encrypt the Confirm1 and Confirm2 messages. They are truncated to the same size as the negotiated SRTP key size. zrtpkeyi = KDF(s0, "Initiator ZRTP key", KDF_Context, negotiated AES key length) zrtpkeyr = KDF(s0, "Responder ZRTP key", KDF_Context, negotiated AES key length) All key material is destroyed as soon as it is no longer needed, no later than the end of the call. s0 is erased in Section 4.6.1, and the rest of the session key material is erased in Sections 4.7.2.1 and 4.7.3.
4.6. Confirmation
The Confirm1 and Confirm2 messages (Figure 10) contain the cache expiration interval (defined in Section 4.9) for the newly generated retained shared secret. The flagoctet is an 8-bit unsigned integer made up of these flags: the PBX Enrollment flag (E) defined in Section 7.3.1, the SAS Verified flag (V) defined in Section 7.1, the Allow Clear flag (A) defined in Section 4.7.2, and the Disclosure flag (D) defined in Section 11. flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0) Part of the Confirm1 and Confirm2 messages are encrypted using full- block Cipher Feedback Mode and contain a 128-bit random Cipher FeedBack (CFB) Initialization Vector (IV). The Confirm1 and Confirm2 messages also contain a MAC covering the encrypted part of the Confirm1 or Confirm2 message that includes a string of zeros, the signature length, flag octet, cache expiration interval, signature type block (if present), and signature (Section 7.2) (if present). For the responder: confirm_mac = MAC(mackeyr, encrypted part of Confirm1) For the initiator: confirm_mac = MAC(mackeyi, encrypted part of Confirm2) The mackeyi and mackeyr keys are computed in Section 4.5.3. The exchange is completed when the responder sends either the Conf2ACK message or the responder's first SRTP media packet (with a valid SRTP auth tag). The initiator MUST treat the first valid SRTP media from the responder as equivalent to receiving a Conf2ACK. The responder may respond to Confirm2 with either SRTP media, Conf2ACK, or both, in whichever order the responder chooses (or whichever order the "cloud" chooses to deliver them).4.6.1. Updating the Cache of Shared Secrets
After receiving the Confirm messages, both parties must now update their retained shared secret rs1 in their respective caches, provided the following conditions hold: (1) This key exchange is either DH or Preshared mode, not Multistream mode, which does not update the cache. (2) Depending on the values of the cache expiration intervals that are received in the two Confirm messages, there are some
scenarios that do not update the cache, as explained in
Section 4.9.
(3) The responder MUST receive the initiator's Confirm2 message
before updating the responder's cache.
(4) The initiator MUST receive either the responder's Conf2ACK
message or the responder's SRTP media (with a valid SRTP auth
tag) before updating the initiator's cache.
The cache update may also be affected by a cache mismatch, according
to Section 4.6.1.1.
For DH mode only, before updating the retained shared secret rs1 in
the cache, each party first discards their old rs2 and copies their
old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of
session interruption after one party has updated his own rs1 but
before the other party has enough information to update her own rs1.
If that happens, they may regain cache sync in the next session by
using rs2 (per Section 4.3). This mitigates the well-known Two
Generals' Problem [Byzantine]. The old rs1 value is not saved in
Preshared mode.
For DH mode and Preshared mode, both parties compute a new rs1 value
from s0 via the ZRTP key derivation function (Section 4.5.1):
rs1 = KDF(s0, "retained secret", KDF_Context, 256)
Note that KDF_Context is unique for each media stream, but only the
first media stream is permitted to update rs1.
Each media stream has its own s0. At this point in the protocol for
each media stream, the corresponding s0 MUST be erased.
4.6.1.1. Cache Update Following a Cache Mismatch
If a shared secret cache mismatch (as defined in Section 4.3.2) is
detected in the current session, it indicates a possible MiTM attack.
However, there may be evidence to the contrary, if either one of the
following conditions are met:
o Successful use of the mechanism described in Section 8.1.1, but
only if fully supported by end-to-end integrity-protected delivery
of the a=zrtp-hash in the signaling via SIP Identity [RFC4474] or
better still, Dan Wing's SIP Identity using Media Path
[SIP-IDENTITY]. This allows authentication of the DH exchange
without human assistance.
o A good signature is received and verified using the digital
signature feature on the SAS hash, as described in Section 7.2, if
this feature is supported.
If there is a cache mismatch in the absence of the aforementioned
mitigating evidence, the cache update MUST be delayed in the current
session until the user verbally compares the SAS with his partner
during the call and confirms a successful SAS verify via his user
interface as described in Section 7.1. If the session ends before
that happens, the cache update is not performed, leaving the rs1/rs2
values unmodified in the cache. Regardless of whether a cache
mismatch occurs, s0 must still be erased.
If no cache entry exists, as is the case in the initial call, the
cache update is handled in the normal fashion.
4.7. Termination
A ZRTP session is normally terminated at the end of a call, but it
may be terminated early by either the Error message or the GoClear
message.
4.7.1. Termination via Error Message
The Error message (Section 5.9) is used to terminate an in-progress
ZRTP exchange due to an error. The Error message contains an integer
Error Code for debugging purposes. The termination of a ZRTP key
agreement exchange results in no updates to the cached shared secrets
and deletion of all crypto context for that media stream. The ZRTP
Session key, ZRTPSess, is only deleted if all ZRTP media streams that
are using it are terminated.
Because no key agreement has been reached, the Error message cannot
use the same MAC protection as the GoClear message. A denial of
service is possible by injecting fake Error messages. (However, even
if the Error message were somehow designed with integrity protection,
it would raise other questions. What would a badly formed Error
message mean if it were sent to report a badly formed message? A
good message?)
4.7.2. Termination via GoClear Message
The GoClear message (Section 5.11) is used to switch from SRTP to
RTP, usually because the user has chosen to do that by pressing a
button. The GoClear uses a MAC of the Message Type Block sent in the
GoClear message computed with the mackey derived from the shared
secret. This MAC is truncated to the leftmost 64 bits. When sent by
the initiator:
clear_mac = MAC(mackeyi, "GoClear ")
When sent by the responder:
clear_mac = MAC(mackeyr, "GoClear ")
Both of these MACs are calculated across the 8-octet "GoClear "
Message Type Block, including the trailing space.
A GoClear message that does not receive a ClearACK response must be
resent. If a GoClear message is received with a bad MAC, ClearACK
MUST NOT be sent and the GoClear MUST NOT be acted on by the
recipient, but it MAY be processed as a security exception, perhaps
by logging or alerting the user.
A ZRTP endpoint MAY choose to accept GoClear messages after the
session has switched to SRTP, allowing the session to revert to RTP.
This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by
setting the Allow Clear flag (A). If an endpoint sets the Allow
Clear (A) flag in their Confirm message, it indicates that they
support receiving GoClear messages.
A ZRTP endpoint that receives a GoClear MUST authenticate the message
by checking the clear_mac. If the message authenticates, the
endpoint stops sending SRTP packets, and generates a ClearACK in
response. It MUST also delete all the crypto key material for all
the SRTP media streams, as defined in Section 4.7.2.1.
Until confirmation from the user is received (e.g., clicking a
button, pressing a dual-tone multi-frequency (DTMF) key, etc.), the
ZRTP endpoint MUST NOT resume sending RTP packets. The endpoint then
renders to the user an indication that the media session has switched
to clear mode and waits for confirmation from the user. This blocks
the flow of sensitive discourse until the user is forced to take
notice that he's no longer protected by encryption. To prevent
pinholes from closing or NAT bindings from expiring, the ClearACK
message MAY be resent at regular intervals (e.g., every 5 seconds)
while waiting for confirmation from the user. After confirmation of
the notification is received from the user, the sending of RTP
packets may begin.
After sending a GoClear message, the ZRTP endpoint stops sending SRTP
packets. When a ClearACK is received, the ZRTP endpoint deletes the
crypto context for the SRTP session, as defined in Section 4.7.2.1,
and may then resume sending RTP packets.
In the event a ClearACK is not received before the retransmissions of GoClear are exhausted, the key material is deleted, as defined in Section 4.7.2.1. After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit message, leading to a new session key negotiation. It is not necessary to send another Hello message, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same session, just as they could in the old days of secure PSTN phones.4.7.2.1. Key Destruction for GoClear Message
All SRTP session key material MUST be erased by the receiver of the GoClear message upon receiving a properly authenticated GoClear. The same key destruction MUST be done by the sender of GoClear message, upon receiving the ClearACK. This must be done for the key material for all of the media streams. All key material that would have been erased at the end of the SIP session MUST be erased, as described in Section 4.7.3, with the single exception of ZRTPSess. In this case, ZRTPSess is destroyed in a manner different from the other key material. Both parties replace ZRTPSess with a KDF-derived non-invertible function of itself: ZRTPSess = KDF(ZRTPSess, "New ZRTP Session", (ZIDi || ZIDr), negotiated hash length) ZRTPSess will be replaced twice if a session generates separate GoClear messages for both audio and video streams, and the two endpoints need not carry out the replacements in the same order. The destruction of key material meets the requirements of Perfect Forward Secrecy (PFS), but still preserves a new version of ZRTPSess, so that the user can later re-initiate secure mode during the same session without performing another Diffie-Hellman calculation using Multistream mode, which requires and assumes the existence of ZRTPSess with the same value at both ZRTP endpoints. A new key negotiation after a GoClear SHOULD use a Multistream Commit message. Note: Multistream mode is preferred over a Diffie-Hellman mode since this does not require the generation of a new hash chain and a new signaling exchange to exchange new Hello Hash values.
Later, at the end of the entire call, ZRTPSess is finally destroyed along with the other key material, as described in Section 4.7.3.4.7.3. Key Destruction at Termination
All SRTP session key material MUST be erased by both parties at the end of the call. In particular, the destroyed key material includes the SRTP session keys and salts, SRTP master keys and salts, and all material sufficient to reconstruct the SRTP keys and salts, including ZRTPSess and s0 (although s0 should have been destroyed earlier, in Section 4.6.1). This must be done for the key material for all of the media streams. The only exceptions are the cached shared secrets needed for future sessions, including rs1, rs2, and pbxsecret.4.8. Random Number Generation
The ZRTP protocol uses random numbers for cryptographic key material, notably for the DH secret exponents and nonces, which must be freshly generated with each session. Whenever a random number is needed, all of the following criteria must be satisfied: Random numbers MUST be freshly generated, meaning that they must not have been used in a previous calculation. When generating a random number k of L bits in length, k MUST be chosen with equal probability from the range of [1 < k < 2^L]. It MUST be derived from a physical entropy source, such as radio frequency (RF) noise, acoustic noise, thermal noise, high-resolution timings of environmental events, or other unpredictable physical sources of entropy. One possible source of entropy for a VoIP client would be microphone noise. For a detailed explanation of cryptographic grade random numbers and guidance for collecting suitable entropy, see [RFC4086] and Chapter 10 of "Practical Cryptography" [Ferguson]. The raw entropy must be distilled and processed through a deterministic random-bit generator (DRBG). Examples of DRBGs may be found in [NIST-SP800-90], in [Ferguson], and in [RFC5869]. Failure to use true entropy from the physical environment as a basis for generating random cryptographic key material would lead to a disastrous loss of security.
4.9. ZID and Cache Operation
Each instance of ZRTP has a unique 96-bit random ZRTP ID, or ZID, that is generated once at installation time. It is used to look up retained shared secrets in a local cache. A single global ZID for a single installation is the simplest way to implement ZIDs. However, it is specifically not precluded for an implementation to use multiple ZIDs, up to the limit of a separate one per callee. This then turns it into a long-lived "association ID" that does not apply to any other associations between a different pair of parties. It is a goal of this protocol to permit both options to interoperate freely. A PBX acting as a trusted man in the middle will also generate a single ZID and use that ZID for all endpoints behind it, as described in Section 10. There is no protocol mechanism to invalidate a previously used ZID. An endpoint wishing to change ZIDs would simply generate a new one and begin using it. The ZID should not be hard coded or hard defined in the firmware of a product. It should be randomly generated by the software and stored at installation or initialization time. It should be randomly generated rather than allocated from a preassigned range of ZID values, because 96 bits should be enough to avoid birthday collisions in realistic scenarios. Each time a new s0 is calculated, a new retained shared secret rs1 is generated and stored in the cache, indexed by the ZID of the other endpoint. This cache updating is described in Section 4.6.1. For the new retained shared secret, each endpoint chooses a cache expiration value that is an unsigned 32-bit integer of the number of seconds that this secret should be retained in the cache. The time interval is relative to when the Confirm1 message is sent or received. The cache intervals are exchanged in the Confirm1 and Confirm2 messages (Figure 10). The actual cache interval used by both endpoints is the minimum of the values from the Confirm1 and Confirm2 messages. A value of 0 seconds means the newly computed shared secret SHOULD NOT be stored in the cache, and if a cache entry already exists from an earlier call, the stored cache interval should be set to 0. This means if either Confirm message contains a null cache expiration interval, and there is no cache entry already defined, no new cache entry is created. A value of 0xffffffff means the secret should be cached indefinitely and is the recommended value. If the ZRTP exchange is Multistream mode, the field in the Confirm1 and Confirm2 is set to 0xffffffff and is ignored; the cache is not updated.
The expiration interval need not be used to force the deletion of a shared secret from the cache when the interval has expired. It just means the shared secret MAY be deleted from that cache at any point after the interval has expired without causing the other party to note it as an unexpected security event when the next key negotiation occurs between the same two parties. This means there need not be perfectly synchronized deletion of expired secrets from the two caches, and makes it easy to avoid a race condition that might otherwise be caused by clock skew. If the expiration interval is not properly agreed to by both endpoints, it may later result in false alarms of MiTM attacks, due to apparent cache mismatches (Section 4.3.2). The relationship between a ZID and a SIP AOR is explained in Section 12.4.9.1. Cacheless Implementations
It is possible to implement a simplified but nonetheless useful (and still compliant) profile of the ZRTP protocol that does not support any caching of shared secrets. In this case, the users would have to rely exclusively on the verbal SAS comparison for every call. That is, unless MiTM protection is provided by the mechanisms in Section 8.1.1 or 7.2, which introduce their own forms of complexity. If a ZRTP endpoint does not support the caching of shared secrets, it MUST set the cache expiration interval to zero, and MUST set the SAS Verified (V) flag (Section 7.1) to false. In addition, because the ZID serves mainly as a cache index, the ZID would not be required to maintain the same value across separate SIP sessions, although there is no reason why it should not. Cacheless operation would sacrifice the key continuity (Section 15.1) features, as well as Preshared mode (Section 4.4.2). Further, if the pbxsecret is also not cached, there would be no PBX trusted MiTM (Section 7.3) features, including the PBX security enrollment (Section 7.3.1) mechanism.
(page 42 continued on part 3)