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

Simo Sorce <> Tue, 01 January 2019 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB43B130DBE; Tue, 1 Jan 2019 06:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dE675WscXbGU; Tue, 1 Jan 2019 06:06:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B08A12426A; Tue, 1 Jan 2019 06:06:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4709394D3F; Tue, 1 Jan 2019 14:06:24 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPS id 175261042557; Tue, 1 Jan 2019 14:06:23 +0000 (UTC)
Message-ID: <>
From: Simo Sorce <>
To: David Mandelberg <>,,,
Date: Tue, 01 Jan 2019 09:06:23 -0500
In-Reply-To: <>
References: <>
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
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Tue, 01 Jan 2019 14:06:24 +0000 (UTC)
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


> 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 Sorce
Sr. Principal Software Engineer
Red Hat, Inc