Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6189

ZRTP: Media Path Key Agreement for Unicast Secure RTP

Pages: 115
Informational
Part 2 of 5 – Pages 10 to 42
First   Prev   Next

Top   ToC   RFC6189 - Page 10   prevText

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.
Top   ToC   RFC6189 - Page 11
   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
Top   ToC   RFC6189 - Page 12
   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.
Top   ToC   RFC6189 - Page 13
      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.
Top   ToC   RFC6189 - Page 14
   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
Top   ToC   RFC6189 - Page 15
   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.
Top   ToC   RFC6189 - Page 16
   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.
Top   ToC   RFC6189 - Page 17

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.
Top   ToC   RFC6189 - Page 18

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.
Top   ToC   RFC6189 - Page 19
   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.
Top   ToC   RFC6189 - Page 20
   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:
Top   ToC   RFC6189 - Page 21
       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.
Top   ToC   RFC6189 - Page 22
   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 p

4.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 p
4.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.
Top   ToC   RFC6189 - Page 23
   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)
Top   ToC   RFC6189 - Page 24
   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.
Top   ToC   RFC6189 - Page 25

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
Top   ToC   RFC6189 - Page 26
   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
Top   ToC   RFC6189 - Page 27
   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)
Top   ToC   RFC6189 - Page 28
   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
Top   ToC   RFC6189 - Page 29
   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
Top   ToC   RFC6189 - Page 30
   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.
Top   ToC   RFC6189 - Page 31

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.
Top   ToC   RFC6189 - Page 32
   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
Top   ToC   RFC6189 - Page 33
   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
Top   ToC   RFC6189 - Page 34
   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.
Top   ToC   RFC6189 - Page 35

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
Top   ToC   RFC6189 - Page 36
        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.
Top   ToC   RFC6189 - Page 37
   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:
Top   ToC   RFC6189 - Page 38
      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.
Top   ToC   RFC6189 - Page 39
   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.
Top   ToC   RFC6189 - Page 40
   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.
Top   ToC   RFC6189 - Page 41

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.
Top   ToC   RFC6189 - Page 42
   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)

Next Section