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

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

  Hi Phil,

  That makes sense. I guess that addresses the last of my comments
then (the previous ones were resolved over the phone). Thanks!

  Dan.

On Sat, April 24, 2010 2:22 pm, Philip Zimmermann wrote:
> Dan, thank you for reviewing our draft.  It's great to get comments from
> someone who understands hash functions so well.
>
> When we talked on the phone, I clarified the fact that we already use hash
> commits to address some of the concerns you raised below.
>
> I have adjusted our computations of srtps and ZRTPSess to use KDFs more
> effectively, because of our conversation.  This will be reflected in ZRTP
> draft 18.
>
> Your reference to Hugo's paper was most helpful.  Because of this, I read
> his paper, and called Lily Chen at NIST to discuss how NIST would use
> Hugo's ideas in the future.  She said NIST plans to update SP800-56A to
> address this.  As it stands, we are using the current version of SP800-56A
> to achieve strict NIST compliance to facilitate FIPS-140 validation
> testing.
>
> Regards,
> Phil
>
>
>
> On Mar 30, 2010, at 1:22 PM, Dan Harkins wrote:
>
>>
>>  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.
>>
>>
>
> ------------------------------------------------
> Philip R Zimmermann    [e-mail]
> (spelled with 2 n's)   http://philzimmermann.com
> tel [phone]    http://zfone.com
>
>
>
>
>