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

Philip Zimmermann <prz@mit.edu> Sat, 24 April 2010 21:23 UTC

Return-Path: <prz@mit.edu>
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 7D3C33A66B4; Sat, 24 Apr 2010 14:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.597
X-Spam-Level: *
X-Spam-Status: No, score=1.597 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_31=0.6, RDNS_DYNAMIC=0.1]
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 QZ4xpggxwEMM; Sat, 24 Apr 2010 14:22:59 -0700 (PDT)
Received: from mail.philzimmermann.com (adsl-99-107-86-52.dsl.pltn13.sbcglobal.net [99.107.86.52]) by core3.amsl.com (Postfix) with ESMTP id E666C3A691D; Sat, 24 Apr 2010 14:22:54 -0700 (PDT)
Received: from [10.0.1.218] ([10.0.1.1]) (authenticated bits=0) by mail.philzimmermann.com (8.14.3/8.14.3) with ESMTP id o3OLMcGm069920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 24 Apr 2010 14:22:41 -0700 (PDT) (envelope-from prz@mit.edu)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Philip Zimmermann <prz@mit.edu>
X-Priority: 3 (Normal)
In-Reply-To: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net>
Date: Sat, 24 Apr 2010 14:22:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <69BB892A-4D41-4B39-8641-4CEEA19F9F1B@mit.edu>
References: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net>
To: Dan Harkins <dharkins@lounge.org>
X-Mailer: Apple Mail (2.1078)
X-Mailman-Approved-At: Sat, 24 Apr 2010 14:32:56 -0700
Cc: draft-zimmermann-avt-zrtp.all@tools.ietf.org, iesg@ietf.org, secdir@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: Sat, 24 Apr 2010 21:23:01 -0000

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