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
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 > > > > >
- [secdir] secdir review of draft-zimmermann-avt-zr… Dan Harkins
- Re: [secdir] secdir review of draft-zimmermann-av… Philip Zimmermann
- Re: [secdir] secdir review of draft-zimmermann-av… Dan Harkins