Skip to main content

Last Call Review of draft-ietf-curdle-gss-keyex-sha2-07
review-ietf-curdle-gss-keyex-sha2-07-secdir-lc-mandelberg-2019-01-03-00

Request Review of draft-ietf-curdle-gss-keyex-sha2
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-01-08
Requested 2018-12-25
Authors Simo Sorce , Hubert Kario
I-D last updated 2019-01-03
Completed reviews Secdir Last Call review of -07 by David Mandelberg (diff)
Genart Last Call review of -08 by Francis Dupont (diff)
Assignment Reviewer David Mandelberg
State Completed
Request Last Call review on draft-ietf-curdle-gss-keyex-sha2 by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has nits
Completed 2019-01-03
review-ietf-curdle-gss-keyex-sha2-07-secdir-lc-mandelberg-2019-01-03-00
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? 
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?

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.

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