Subject: [Curdle] new-AD review comments on draft-ietf-curdle-gss-keyex-sha2-08

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 May 2019 10:06:04 -0500

Hi all,

I'm almost ready to send draft-ietf-curdle-gss-keyex-sha2 to the IESG for
evaluation, but would like to see a new revision posted first, mostly for
the Abstract changes.  In addition to the changes mentioned below, please
also go ahead and make the editorial changes mentioned in the last
call/directorate reviews.

-Ben

Abstract

   This document specifies additions and amendments to RFC4462.  It
   defines a new key exchange method that uses SHA-2 for integrity and
   deprecates weak DH groups.  The purpose of this specification is to

I think we need to remove this statement about "deprecates weak DH groups";
I didn't see any further discussion of such deprecations in any revision of
the document.

Section 2

                                                           Following the
   rationale of [RFC8268] only SHA-256 and SHA-512 hashes are used for
   DH groups.  For NIST curves the same curve-to-hashing algorithm
   pairing used in [RFC5656] is adopted for consistency.

8268 doesn't provide a whole lot of rationale for using SHA-256, rather,
the closest thing to guidance would be in Section 1 where it cites the NSA
IAD FAQ that wants to *avoid* using SHA-256.  So perhaps it's better to say
that this just follows the practice of 8268, rather than the rationale from
it, especially since we are just using a "consistency" argument for the
NIST curves' hashes.

Section 3

RFC 8174 has an updated boilerplate text to use for the BCP 14 keywords.

Section 4

               The method name for each method is the concatenation of
   the family method name with the Base64 encoding of the MD5 hash
   [RFC1321] of the ASN.1 DER encoding [ISO-IEC-8825-1] of the
   underlying GSS-API mechanism's OID.  [...]

nit: I'd suggest using the "family name prefix" to match the table, rather
than "family method name".

Section 5

   In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve
   Cryptography are introduced.  We reuse much of section 4 to define
   GSS-API-authenticated ECDH Key Exchanges.

nit: I think this is intended to refer to Section 4 of RFC 5656, but the
current text reads like we are referring to Section 4 of the current
document.

Section 5.1

   For NIST Curves keys use uncompressed point representation and must

nit: "the"

   be converted using the algorithm in Section 2.3.4 of [SEC1v2].  If
   the conversion fails or the point is trasmitted using compressed

nit: "the"

   representation, the key exchange MUST fail.

   A GSS Context is established according to Section 4 of [RFC5656]; The
   client initiates the establishment using GSS_Init_sec_context() and
   the server completes it using GSS_Accept_sec_context().  For the

I'm not sure what this reference was intended to be; the current one
doesn't really seem right, though.

Also, in a fully general GSS negotiation loop, the server does not
necessarily make the last step, so "completes" may be slightly misleading.

                                                              This key
   exchange process will exchange only a single token once the context
   has been established, therefore the replay_det_req_flag and
   sequence_req_flag SHOULD be set to "false".

nit: "single message token", since we are not making a statement about
context establishment tokens, and the previous text was about the context
establishment process which might cause the reader to jump towards context
tokens here.

                 For curve25519 and curve448 the algorithm in Section 6
   of [RFC7748] is used instead.

nits: "algorithms", "are" (since there are different procedures in
subsections 6.1 and 6.2 for the two curves).

Section 6

It's not clear to me why the "Implementation Support" column is here -- it
duplicates content from tables elsewhere in the document, and does not seem
to be part of the registration template.

Section 7.3

   Some GSSAPI mechanisms can optionally delegate credentials to the
   target host by setting the deleg_ret_flag.  In this case extra care
   must be taken to ensure that the acceptor being authenticated matches
   the target the user intended.  [...]

This is a bit weird to read, since the setting of the deleg_ret_flag is not
what effectuates the delegation of credentials; that happens by virtue of
the exchange of context tokens.  (Also, RFC 2743 only lists a
deleg_req_flag; the acceptor-side state is passed in the deleg_state
boolean.)  A simple replacement with deleg_req_flag doesn't work, either,
as that's not something the mechanism does, but rather the GSSAPI consumer.
So I think we may need a broader change, like:

% Some GSSAPI mechanisms can act on a request to delegate credentials to
% the target host when the deleg_req_flag is set.  In this case, extra care
% must be taken to ensure that the acceptor being authenticated matches the
% target the user intended.  [...]

(And yes, I know that I'm basically responsible for this text being
present; it may well have been my error originally.)

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 8 May 2019 08:42:27 -0700

Hi Ben,

In RFC 8268, I tried (and apparently failed) to say that the NSA IAD
appears to prefer the use of SHA2-384 for TOP SECRET documents, but that
the SHA2-256, SHA2-384, and SHA2-512 hashing functions are all NIST
approved for FIPS 140-2 Implementation Guidance.

The rationale for SHA2-384 being 'better' for TOP SECRET is apparently
that there are 1024 bits in the internal state of the hashing algorithm,
so 640 bits are kept private while for SHA2-256 there are 512 bits in
the internal state, half of which are public and half of which are
private.

The only weak DH group which should be deprecated is the
diffie-hellman-group1-sha1 and that mostly because of logjam
(https://en.wikipedia.org/wiki/Logjam_(computer_security).

I have been remiss in addressing the AD comments and submitting an
updated draft of draft-ietf-curdle-ssh-curves (Secure Shell (SSH) Key
Exchange Method using Curve25519 and Curve448), so there is no RFC
listing for those key exchange methods in the IANA repository (URL:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml ).

I have not yet compared RFC7748 to the implementations of Curve25519
that exist in many SSH implementations which is one of the reasons that
draft-ietf-curdle-ssh-curves has not been updated. The draft was trying
to document a well deployed [email-masked] to ensure
interoperability.

	-- Mark

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 May 2019 10:52:09 -0500

Hi Mark,

> approved for FIPS 140-2 Implementation Guidance.

Given that 8268 still uses SHA-256 it is clearly not forbidden to do so; my
comment here was mostly of an editorial nature, that the word "rationale"
does not seem to match up well with the reference.  I don't think we need
to change what we're doing in this document; we just may want to change how
we talk about what we're doing.

> (https://en.wikipedia.org/wiki/Logjam_(computer_security).

I'm not opposed to adding that in to this document (instead of removing the
bit from the abstract), but it might require another IETF LC if we choose
to go that route.

> to document a well deployed [email-masked] to ensure

Thanks for the extra background; let's hope that we can both find some
time to work on our respective backlogs :)

-Ben

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 May 2019 12:34:40 +0200

> I didn't see any further discussion of such deprecations in any revision of

we've done that by not listing them, would you prefer to list them explicitly 
in section 6 and Section 4 with a "MUST NOT" in "Implementation Support" and 
"Implementation Recommendations"?
 
> it, especially since we are just using a "consistency" argument for the

yes, "practice" would work better in this context

-- 
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

---

From: Simo Sorce <[email-masked]>
Date: Fri, 10 May 2019 10:02:36 -0400

Answers inline.

> I didn't see any further discussion of such deprecations in any revision of

See Hubert's question

> it, especially since we are just using a "consistency" argument for the

Fixed, replaced "rationale" with "practice"

> RFC 8174 has an updated boilerplate text to use for the BCP 14 keywords.

Fixed

> than "family method name".

Fixed

> current text reads like we are referring to Section 4 of the current

Fixed

>    the conversion fails or the point is trasmitted using compressed

both nits Fixed

> necessarily make the last step, so "completes" may be slightly misleading.

Would it be ok to replace "completes" with "responds to" ?

> establishment process which might cause the reader to jump towards context

I am not sure what you are suggesting/requesting here, can you clarify?

> subsections 6.1 and 6.2 for the two curves).

Fixed

> to be part of the registration template.

Ok, I'll drop the column.

> present; it may well have been my error originally.)

I like your wording better too, and nice catch on the flag name typo.

Once I get answers on the remaining open questions I will include the
results of the discussion in the document[1] and issue a new draft.

Thanks,
Simo.

[1] https://github.com/simo5/ietf/blob/master/draft-ietf-curdle-gss-keyex-sha2.xml

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