[secdir] secdir review of draft-zimmermann-avt-zrtp-17

["Dan Harkins" <[e-mail]>]

  Hi,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft defines a Diffie-Hellman based key exchange to generate
a session key to use with SRTP. It prevents a man-in-the-middle attack
against the Diffie-Hellman key exchange without requiring traditional
authentication. It does not require use of a PKI.

  There are three things I think the ADs should take a look at: having
the protocol resist a small sub-group attack, use of the "auxsecret", and
the hashing mishmash. All are described below.

  The MitM attack is thwarted by using a short authentication string (SAS)
that is presented to users on each side of the ZRTP exchange to be read
and verbally compared.

  An immediate concern with such an approach is that it might enable a
small sub-group attack against the Diffie-Hellman exchange that would
be undetectable by verification of the SAS. An attacker could take an
element of small order, f, and create pvi' = pvi^f modp and
pvr' = pvr^f mod p and the shared secret, DHResult', would be confined to
the small group. The SAS would verbally verify and the two parties would
continue unaware of the attack. But the DH shared secret is subsequently
used (indirectly) in a hash which fixes it and exposes it to the MitM,
which can run through the values in the small sub-group to determine
DHResult' and then attack the SRTP connection.

  The draft specifies support for a Diffie-Hellman domain parameter set
using a safe prime (from RFC 3526) which would prevent such an attack
but it seems that the protocol should be secure in and of itself and not
rely on external safeguards. I recommend sections 4.4.1.2 and 4.4.1.3
define an additional processing step to ensure pvi and pvr are not in
a small sub-group. For a safe-prime this can be viewed as a "belt and
suspenders" approach, but I don't see why ZRTP couldn't be used in the
future with other domain parameter sets which may not be based on safe
primes and therefore such a check would be vital.

  The draft has a clever shared secret state matching algorithm to use
secrets from a cache of state associated with a peer. One of these is
called "auxsecret", as described in section 4.3.1:

   "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
   it may be a family key used by an institution that the two parties both
   belong to."

If one does not have an "auxsecret" configured a random value is used in
its field during the ZRTP exchange. If one does have an "auxsecret" though
it does not appear to change.

  Traffic analysis, therefore, would tell an attacker whether an
"auxsecret" is being used or not. If one is, an off-line dictionary attack
might be possible if the "auxsecret" is being used per section 4.3.1 (if
it is a "family key used by an institution" then every member of the
institution would use the same "auxsecret" and that could also be easily
detected).

  I recommend that the "auxsecret" be updated in the cache in section
4.6.1 so that it is different with a subsequent run of the protocol. If
that logistically isn't possible then perhaps hash rs1 or rs2 with it
in 4.3.1 to produce "auxsecretIDi" and "auxsecretIDr". Since there is a
matching algorithm for r1 and r2 then it might be necessary to have two
"auxsecretIDi" and two "auxsecretIDr", one hashed with r1 and one with
r2. The cost is a little extra space but the benefit seems worth it.

  There is a confusing mix of hashing, HMACing, and KDFing. In section
4.4.1.4 a secret value s0 is derived using the KDF technique from
SP800-56A, which is not of the keyed variety, it just uses a hash function
in counter mode. But if a preshared key is used then section 4.4.2.4
derives s0 with an HMAC-based KDF based on SP800-108. This value, s0,
is then used to derive the SRTP session key, the SAS, and various
encryption and integrity protection keys using the HMAC-based, SP800-108
version of a KDF. When a session is terminated all keys are destroyed
except ZRTPSess which is replace by a hash of itself. But it was
originally derived by a keyed KDF. This seems unnecessarily complex and
would make this protocol very difficult to analyze.

  There has been much discussion on the CFRG list about how the output
of a hash function is too structured to use the key to an HMAC (see
Hugo Krawczyk's HKDF draft). Whether the SP800-56A hash-style KDF is
good or whether the SP800-108 keyed HMAC-style KDF is good is a debate
for another forum but I think this draft should choose one and stick to
it. Keys derived from a hash function should not be used as keys to
an HMAC and keys derived from an HMAC-based KDF should not be replaced
with a simple hash of themselves.

  Editorial nits:

    * sections 4.4.1.1 and 4.4.1.2 mention the "width of the DH prime".
      How about "bit-length of the DH prime" instead?
    * section 4.4.1.1 mentions ECDH but then goes on to specify the
      finite field (MODP) version of the exchange. I suggest adding an
      example of ECDH in 4.4.1.1 and 4.4.1.2.

  regards,

  Dan.