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

From: Simo Sorce <[email-masked]>
Date: Tue, 01 Jan 2019 09:06:23 -0500

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

---

From: David Mandelberg <[email-masked]>
Date: Tue, 1 Jan 2019 15:33:31 -0500

> All else equal I think it would

Ok. I don't have any specific attacks in mind, but that seems like a 
potential weak point. This probably isn't the right document to change 
that in though.

> mediated exchange using only symmetric keys).

Sounds good, thanks for the explanation.

-- 
https://david.mandelberg.org/

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 1 Jan 2019 22:13:28 +0000

Actually, this is not an issue. The value H is the SSH exchange hash, which is a common element across all key exchange methods. It is discussed in detail on the following page, which I think makes it clear that the hash is over a concatenation of a number of items of type 'string', except for K, which is an mpint. These types and their representations are described in RFC4251 section 5. In particular, 'string' is a counted string, so no, the cases you describe do not result in the same value for H.

-- Jeff

________________________________
From: secdir <[email-masked]> on behalf of David Mandelberg <david=[email-masked]>
Sent: Tuesday, January 1, 2019 3:33 PM
To: Simo Sorce; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] secdir review of draft-ietf-curdle-gss-keyex-sha2-07

---

From: Simo Sorce <[email-masked]>
Date: Wed, 02 Jan 2019 11:02:16 -0500

Thank you Jeffrey,
I forgot it was a counted string!

Simo.

On Tue, 2019-01-01 at 22:13 +0000, Jeffrey Hutzelman wrote:
> Actually, this is not an issue. The value H is the SSH exchange hash,
> which is a common element across all key exchange methods. It is
> discussed in detail on the following page, which I think makes it
> clear that the hash is over a concatenation of a number of items of
> type 'string', except for K, which is an mpint. These types and their
> representations are described in RFC4251 section 5. In particular,
> 'string' is a counted string, so no, the cases you describe do not
> result in the same value for H.
> 
> 
> -- Jeff
> 
>

---

From: Hubert Kario <[email-masked]>
Date: Thu, 03 Jan 2019 13:34:55 +0100

> potential weak point. This probably isn't the right document to change

yes, we actually considered also making the key exchange secure against 
quantum computer attacks, but decided to favour ease of implementation as more 
important; thus the resulting minimal changes compared to RFC 4462

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic