tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6189

 
 
 

ZRTP: Media Path Key Agreement for Unicast Secure RTP

Part 2 of 5, p. 10 to 42
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 10 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part