Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07

Simo Sorce <simo@redhat.com> Tue, 01 January 2019 14:06 UTC

Return-Path: <simo@redhat.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB43B130DBE; Tue, 1 Jan 2019 06:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE675WscXbGU; Tue, 1 Jan 2019 06:06:25 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B08A12426A; Tue, 1 Jan 2019 06:06:25 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4709394D3F; Tue, 1 Jan 2019 14:06:24 +0000 (UTC)
Received: from ovpn-116-112.phx2.redhat.com (ovpn-116-112.phx2.redhat.com [10.3.116.112]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 175261042557; Tue, 1 Jan 2019 14:06:23 +0000 (UTC)
Message-ID: <c2b59fec7c229f5ee1dc5297b1b4a92a5f0d7c17.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: David Mandelberg <david@mandelberg.org>, draft-ietf-curdle-gss-keyex-sha2.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Date: Tue, 01 Jan 2019 09:06:23 -0500
In-Reply-To: <d27185fb-17ea-f84b-4c33-ea2ba2f50637@mandelberg.org>
References: <d27185fb-17ea-f84b-4c33-ea2ba2f50637@mandelberg.org>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 01 Jan 2019 14:06:24 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/iqVlh_Q7YmV6c_i23TdNEXSS5as>
Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 01 Jan 2019 14:06:27 -0000

On Mon, 2018-12-31 at 14:57 -0500, David Mandelberg wrote:
> 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.
> 
> The summary of the review is Ready with nits. I have a few questions 
> below about the security of this document, but each area I have a 
> question about seems to be mostly copied from an established RFC rather 
> than new to this draft.
> 
> Sections 4 and 5.2: Are you relying on MD5 for any security properties? 

No, it was used just to generate a unique name.

> Can anything bad happen if an attacker finds a collision?

No

> Section 5.1: When calculating H, are the boundaries between each 
> concatenated thing clear? E.g., would V_C = "1.21" V_S = "0.1" and V_C = 
> "1.2" V_S = "10.1" result in the same value for H?

All else equal I think it would

> Section 5.1: I assume H or mic_token is used elsewhere to thwart an 
> active MITM? From what I see here, everything hashed into H other than K 
> is public, so an active MITM could generate different H values for 
> different K values for the two sides.

the MIC around H is used to assure no tampering of messages happened.
Anti-MITM properties are conferred by the GSSAPI exchange which is
mutually authenticated.
In order to perform a MITM an attacker need to get hold of both parties
keys (a GSSAPI exchange does not use public/private or DH, it is a KDC
mediated exchange using only symmetric keys).

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc