Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05

denis bider <denisbider.ietf@gmail.com> Tue, 10 April 2018 08:02 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CCB126BF3 for <curdle@ietfa.amsl.com>; Tue, 10 Apr 2018 01:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pLOgUISQ67QK for <curdle@ietfa.amsl.com>; Tue, 10 Apr 2018 01:02:37 -0700 (PDT)
Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85C51271DF for <curdle@ietf.org>; Tue, 10 Apr 2018 01:02:36 -0700 (PDT)
Received: by mail-qk0-x242.google.com with SMTP id g7so12392463qkm.1 for <curdle@ietf.org>; Tue, 10 Apr 2018 01:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mF+xP/O0C5XeExev1CPHA7H6KfMsy3ew02b3A9f5tQw=; b=oSAg3nHs4na4KtjjZEVzLync5zRLmCyUD4fQLyHBpx/Dslf9u43YLdEIoPvMMEfjUQ 0t9vEaahenF4NjRjg174jeLC5v5cbwtzlVADq31r5w4zVnqYR2CJyIfy8tbtaLg+Z+SY YdGcsw+VwR6Axd3VzAuZUfXBLnLmhh+LpCVR+BdrJnv8B9ok7ror5rOZ6lliUd7JnWnU w+OF2YRlohDiZrhnXsX2AhniOhhw6hHHGyIGZ7qAJU6NuWs3RWV1/vmtAbC4gb9waI6F E4bQF11PFOFuDnuzGKRQkdVxRbeQ3F5C5Id+a7wgzuULf9lt7ZnrbqW7zhfE4f3uRj4K DJtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mF+xP/O0C5XeExev1CPHA7H6KfMsy3ew02b3A9f5tQw=; b=MHjAsLDYDx2MWJIz92OetGV/P1JB1eCI5NyYO3Iy7DZzLcF/xt3cy5IaoX/Bt0YnQ3 KtMocxlgX1VYdA6dMhhi8pk1pSqBl7TqNRPMNDNf393KHahFFJmeXtsmFrLCkLUM/lS2 iCUaX9ZxJTXs/IW0vEnHJ7wahwWW2oqDigk1B/7sEtH4eV7pjwjVUsgmpp0bCSHqKq69 Mm5eaz+YyFA5TvsFYzg3aRjNNHRRFjHZzLVvuKPFYjZ2Dr3ODMtAfpL+d2ALAUUBPBoM 3+jk9BzPRdIw0HKToj27lc7BqEQ8nCV1IA/CMj1NO/aO2L5enUkhwEL/h82KsXedYhFo S1Sw==
X-Gm-Message-State: ALQs6tA/pbWxdkFeg1QLiy2EqNr++G59iNgNW0QhwsStJZCy+zslbndM qB6hi1VW82dWDuk/2hM9sBKZRLn0emCXCHAu60E=
X-Google-Smtp-Source: AIpwx4/sUjlQPCaTZlzigOYmgerGwD4xF8m+kU8/KeFsM+5IBWP5OTOG2pl/YK/t4xl34zj/wZ+5zemSDnQjS2DKjVc=
X-Received: by 10.55.79.81 with SMTP id d78mr50838229qkb.20.1523347356075; Tue, 10 Apr 2018 01:02:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.158.146 with HTTP; Tue, 10 Apr 2018 01:02:35 -0700 (PDT)
In-Reply-To: <1523302318.10955.2.camel@redhat.com>
References: <CABcZeBNCUSpGihHz6bPBSALS4-34Tm7W36BCZ_Ev8OQz3KtVag@mail.gmail.com> <1523302318.10955.2.camel@redhat.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Tue, 10 Apr 2018 03:02:35 -0500
Message-ID: <CADPMZDDrqhH4U9=omaB98j-2VQys_ybwG+Hy1L194GMqTJ04Zw@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>
Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-curdle-gss-keyex-sha2@tools.ietf.org, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a758e074c63056979f2de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/h5WjIgQ0-DV9PQHlKRgnAlh-Ah4>
Subject: Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2018 08:02:40 -0000

> Krb5 which is de facto the only used GSSAPI mechanism for
> SHH GSS Key exchanges.

Just a side note: "de facto" are key words there. In practice Kerberos is
the most widely supported GSSAPI mechanism used in SSH. However, GSSAPI key
exchange works equally well with other mechanisms. For example, I believe
we've had someone (either on this list, or on the mostly-zombie SSH list)
mention that they use GSSAPI with X.509 (possibly?) as well as other
mechanisms.


On Mon, Apr 9, 2018 at 2:31 PM, Simo Sorce <simo@redhat.com> wrote:

> Chiming in as one of the Authors, sorry for not responding earlier, I've
> bene
> busy and I will follow up with more answers later on as I ge tmore time to
> address them.
>
> On Fri, 2018-04-06 at 16:24 -0700, Eric Rescorla wrote:
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D4544
> >
> > This document has a huge amount of duplicated material which makes it
> > very hard to read. Please refactor so that the common material is in
> > one place.
>
> In general we strived to maintain the same structure as the docuemnt we are
> extending. This is why some sections seem repetitive. They are but they
> also
> are consistent with the previous document. We think this is more beneficial
> than trying to be more synthetic.
>
> >
> >
> >
> > COMMENTS
> > >      Due to security concerns with SHA-1 [RFC6194] and with MODP groups
> > >      with less than 2048 bits [NIST-SP-800-131Ar1]  we propose the use
> of
> > >      the SHA-2 based hashes with DH group14, group15, group16, group17
> and
> > >      group18 [RFC3526].  Additionally we add support for key exchange
> > >      based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and
> > >      P-521 as well as X25519 and X448 curves.  Following the rationale
> of
> >
> > "the X25519..."
>
> Does this imply it should also be "the NIST P-256, ..." ?
>
> >
> > >          +--------------------------+--------------------------------+
> > >          | Key Exchange Method Name | Implementation Recommendations |
> > >          +--------------------------+--------------------------------+
> > >          | gss-group14-sha256-*     | SHOULD/RECOMMENDED             |
> > >          | gss-group15-sha512-*     | MAY/OPTIONAL                   |
> > >          | gss-group16-sha512-*     | SHOULD/RECOMMENDED             |
> >
> > Why are you only specifying SHA-512 with 4096-bit groups. SHA-256 is
> > still reasonable at that size?
>
> I thik this has been sactisfactorily discussed later in the thread.
>
> >
> > >
> > >      Each of these methods specifies GSS-API-authenticated
> Diffie-Hellman
> > >      key exchange as described in Section 2.1 of [RFC4462]  with
> SHA-256
> > >      as HASH, and the group defined in Section 8.2 of [RFC4253] The
> method
> > >      name for each method is the concatenation of the string "gss-
> > >      group14-sha256-" with the Base64 encoding of the MD5 hash
> [RFC1321]
> >
> > Why is this MD5? Is there some legacy reason for this? It's not
> > necessarily bad but it's odd to modern eyes.
>
> Also discussed later, this is just an identifier, and we a re just being
> consistent with previous naming which can be hardcoded, no need to
> implement
> MD5.
>
> >
> > >      Each of these methods specifies GSS-API-authenticated
> Diffie-Hellman
> > >      key exchange as described in Section 2.1 of [RFC4462]  with
> SHA-512
> > >      as HASH, and the group defined in Section 7 of [RFC3526] The
> method
> > >      name for each method is the concatenation of the string "gss-
> > >      group18-sha512-" with the Base64 encoding of the MD5 hash of the
> > >      ASN.1 DER encoding of the underlying GSS-API mechanism's OID.
> >
> > These all seem to be boilerplate. is there a way to refactor into a
> > single paragraph with a table that describes the substitutions?
>
> See my explanantion above.
>
> >
> > >      ASN.1 DER encoding of the underlying GSS-API mechanism's OID.
> > >
> > >   5.  New Elliptic Curve Diffie-Hellman Key Exchange methods
> > >
> > >      In [RFC5656] new SSH key exchange algorithms based on Elliptic
> Curve
> > >      Cryptography are introduced.  We reuse much of section 4 to
> implement
> >
> > s/implement/define/
> >
> >
> > >      This section defers to [RFC7546] as the source of information on
> GSS-
> > >      API context establishment operations, Section 3 being the most
> > >      relevant.  All Security Considerations described in [RFC7546]
> apply
> > >      here too.
> > >
> > >      The Client:
> >
> > This section should be refactored to put all the EC mechanics (which
> > are symmetrical) in one place.
>
> Is there a reason? We wanted to give implementers a clear linear
> explanation
> without having to jump back and forth to reference what is happening at any
> given point.
>
> >
> > >            and then y coordinate.  The coordinate coversion MUST
> preserve
> > >            leading zero octets.  Thus for nistp521 curve the encoded x
> > >            coordinate will always have a length of 66 octets while the
> Q_C
> > >            representation will be 133 octets long.  This is the
> > >            uncompressed representation specified in Section 4.3.6 of
> > >            [ANSI-X9-62-2005].
> >
> > I have two questions about this:  1. Why are you specifying the
> > detailed computation of the public key? This seems like you could
> > defer it to another spec.
>
> I think this is because we did not have any good normative reference, but
> I'll
> let Hubert chime in.
>
> > 2. Why are you specifying uncompressed
> > representations for NIST curves?
>
> I may be wrong but some compression algorithms have had IPR issues, so
> this may
> derive from a willingness to avoid those, I'll let Hubert chime in here
> too.
>
> > We did this in TLS because people
> > already supported them, but in general they are worse. Is there a
> > reason here?
> >
> >
> > >            by 31 zero octets for curve255519 and as an octect of value
> > >            0x05 followed by 55 zero octets.
> > >
> > >            Calculating Q_C as the result of the call to X25519 or X448
> > >            function, respectively for curve25519 and curve448 key
> > >            exchange, with parameters d_C and g.
> >
> > This material all seems to be in RFC 7748 S 6.1 and 6.2.
>
> I think we wanted it explicitly here, to avoid too much referencing and
> risk of
> errors, but I guess we can reference if you feel strongly about this.
>
> > >
> > >         For NIST curves, the server verifies that the q_C is not a
> point
> > >         at infinity, that both coordinates are in the interval [0, p -
> 1],
> > >         where p is the prime associated with the curve of the selected
> key
> > >         exchange and that the point lies on the curve (satisfies the
> curve
> > >         equation).
> >
> > You should probably cite to the X9.62 or SP-800 for this procedure.
> >
> >
> > >         For curve25519, the server verifies that the the high-order
> bit of
> > >         the last octet is not set - this prevents distinguishing
> attacks
> > >         between implementations that use Montgomery ladder
> implementation
> > >         of the curve and ones that use generic elliptic-curve
> libraries.
> > >         If the bit is set, the key exchange SHOULD fail.  For curve448
> any
> > >         bit can be set.
> >
> > I'm not following what this is supposed to do. If you are worried
> > about this, why don't you just mask off the top bit.
> >
> >
> > >            For NIST curves, the peers perform point multiplication
> using
> > >            d_U and q_V to get point P.
> > >
> > >            For NIST curves, peers verify that P is not a point at
> > >            infinity.  If P is a point at infinity, the key exchange
> MUST
> > >            fail.
> >
> > Why is this text here? It describes the client's behavior.
> >
> >
> > >            and q_V.  The result of the function is the shared secret.
> > >
> > >            For curve25519 and curve448, if all the octets of the shared
> > >            secret are zero octets, the key exchange MUST fail.
> > >
> > >         H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).
> >
> > This kind of just comes out of nowhere. You probably want some
> > prefatory text.
> >
> >
> > >
> > >      7.  C verifies that the key Q_S is valid the same way it is done
> in
> > >      step 3.  If the key is not valid the key exchange MUST fail.
> > >
> > >      8.  C computes the shared secret K and H and verifies that it is
> > >      valid the same way it is done in step 5.  It then calls
> >
> > This check only applies to CFRG curves.
> >
> >
> > >          string    server public host key and certificates (K_S)
> > >
> > >      Since this key exchange method does not require the host key to be
> > >      used for any encryption operations, this message is OPTIONAL.  If
> the
> > >      "null" host key algorithm described in Section 5 of [RFC4462] is
> > >      used, this message MUST NOT be sent.
> >
> > I am assuming in this situation there is some other form of
> > authentication?
>
> As explained elswhere, GSS key exchange assumes GSSAPI authentication.
>
> >
> > >          string    I_C, payload of the client's SSH_MSG_KEXINIT
> > >          string    I_S, payload of the server's SSH_MSG_KEXINIT
> > >          string    K_S, server's public host key
> > >          string    Q_C, client's ephemeral public key octet string
> > >          string    Q_S, server's ephemeral public key octet string
> > >          mpint     K,   shared secret
> >
> > The actual equation is way up above this in the document, which is
> > presumably not great.
> >
> >
> > >      Each key exchange method is implicitly registered by this
> document.
> > >      The IESG is considered to be the owner of all these key exchange
> > >      methods; this does NOT imply that the IESG is considered to be the
> > >      owner of the underlying GSS-API mechanism.
> > >
> > >   5.2.1.  gss-nistp256-sha256-*
> >
> > Again, can you refactor this section so it's not so duplicative.
> >
> >
> > >      the target the user intended.  Some mechanisms implementations
> (like
> > >      commonly used krb5 libraries) may use insecure DNS resolution to
> > >      canonicalize the target name; in these cases spoofing a DNS
> response
> > >      that points to an attacker-controlled machine may results in the
> user
> > >      silently delegating credentials to the attacker, who can then
> > >      impersonate the user at will.
> >
> > Is this something new in this document?
>
> No, we just thought important to note, as it was missing in the original
> document but it is a know factor to be aware of when dealing with Krb5
> which is
> de facto the only used GSSAPI mechanism for SHH GSS Key exchanges.
>
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
>
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>