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

"Dan Harkins" <dharkins@lounge.org> Mon, 26 April 2010 19:51 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550C43A69EE; Mon, 26 Apr 2010 12:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.596
X-Spam-Level:
X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8h9gYL7CL-s; Mon, 26 Apr 2010 12:51:03 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 397653A69C2; Mon, 26 Apr 2010 12:51:03 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 75E521022404C; Mon, 26 Apr 2010 12:50:51 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 26 Apr 2010 12:50:51 -0700 (PDT)
Message-ID: <6a634030770e19d07b9dd79ab408bd37.squirrel@www.trepanning.net>
In-Reply-To: <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu>
References: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net> <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu>
Date: Mon, 26 Apr 2010 12:50:51 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Philip Zimmermann" <prz@mit.edu>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: secdir@ietf.org, draft-zimmermann-avt-zrtp.all@tools.ietf.org, iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-zimmermann-avt-zrtp-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 19:51:05 -0000

  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    prz@mit.edu
> (spelled with 2 n's)   http://philzimmermann.com
> tel +1 831 425-7524    http://zfone.com
>
>
>
>
>