[Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 May 2017 20:25 UTC

Return-Path: <kaduk@mit.edu>
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 D8BD61293E3 for <curdle@ietfa.amsl.com>; Sun, 21 May 2017 13:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level:
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 b-MSu5WJHgPN for <curdle@ietfa.amsl.com>; Sun, 21 May 2017 13:25:58 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877571292AE for <curdle@ietf.org>; Sun, 21 May 2017 13:25:58 -0700 (PDT)
X-AuditID: 1209190c-b85ff70000007961-3d-5921f7d549cb
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.9D.31073.5D7F1295; Sun, 21 May 2017 16:25:57 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v4LKPuWN030306 for <curdle@ietf.org>; Sun, 21 May 2017 16:25:56 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4LKPrbt024409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <curdle@ietf.org>; Sun, 21 May 2017 16:25:56 -0400
Date: Sun, 21 May 2017 15:25:53 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: curdle@ietf.org
Message-ID: <20170521202553.GQ39245@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUixG6nonv1u2KkQcdNeYutC2cxOzB6LFny kymAMYrLJiU1J7MstUjfLoErY//kH+wF6wQqFh37yNbA2M/bxcjJISFgInHww262LkYuDiGB xUwSV58fYgRJCAkcZ5S4/t8Zwn7NJPG+xRHEZhFQlZj0dAsziM0moCLR0H0ZyObgEBEQluhZ IAkSFhYwk9h44TRYCS/Q/H8zrrBB2IISJ2c+YQGxmQW0JG78e8kE0sosIC2x/B8HSFhUQFni 7+F7LBMYeWch6ZiFpGMWQscCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsY QUHEKcmzg/HMG69DjAIcjEo8vA4LFCKFWBPLiitzDzFKcjApifK+mgkU4kvKT6nMSCzOiC8q zUktPsQowcGsJMK75apipBBvSmJlVWpRPkxKmoNFSZxXQqMxQkggPbEkNTs1tSC1CCYrw8Gh JMF7/RtQo2BRanpqRVpmTglCmomDE2Q4D9Bw9u8gw4sLEnOLM9Mh8qcYFaXEeX1BmgVAEhml eXC9oCiXyN5f84pRHOgVYd4UkCoeYIKA634FNJgJaLD1M3mQwSWJCCmpBsbkJ4rvVGK9IlTm aD+8dLjrR/B3eZmNCdsq73bmfc370rg7Of5xEstFE067KW+0ovZMK/aJEpdOMZ3xbxubmV5b xa2JPA8km7ner02XdD3Q++XLRvatgh2zW2WX/Ha26X4lNX1W69+3OvPKphX3c1Sc/Z9/vP/J 7prUM4JPczjc9XmmV/6Sd1BiKc5INNRiLipOBABJFip7zQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/srKGugz6t9pPOzM_EnyDMhLzKt8>
Subject: [Curdle] review of draft-ietf-curdle-gss-keyex-sha2-00
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: Sun, 21 May 2017 20:26:00 -0000

Generally, this document is in good shape, and I think we should move
it forward.

My main comment/objection is that the security considerations should
note that the combination of GSS key exchange, GSS delegated
credentials, and use of insecure DNS to modify the requested server
principal name result in a situation where an attacker can easily
obtain a valid TGT+key for the client principal.  Obviously, RFCs
4462, 4120, etc. all implore us to not use insecure DNS in such a
fashion, but nonetheless major Kerberos libraries continue to do so.
At MIT we have disabled GSS key exchange for ssh because we default
to GSS credential delegation.

Some other nit-level comments:

On page 8, in step 5 of the procedure, do we want to give a
reference or two for the shared-secret computation above the
existing prose?  (Also, is the d_U and q_V terminology standard from
some related document?  I did not see them in RFC 4462.)

Also on page 8, step 6 could further clarify that this only occurs
when the server's final call to GSS_Accept_sec_context() returns
GSS_S_COMPLETE; anything else is an error condition.  Relatedly, the
way the GSS context negotiation loop's exit conditions are split
between step 6 and step 2 confused me a little on first read, but it
seems correct, and along with the RFC 7546 reference I think readers
will be okay.

On page 11, the description of the HASH input has a couple of
inconsistencies -- in RFC 4462, V_S is the server's "version"
string, though here we have it as the server's "identification"
string.  I don't think that's a problem per se, but wanted to note
it just in case.  Also, V_S excludes CR and LF, but V_C excludes CR
and NL; we should probably be consistent about NL vs. LF.

In sections 5.2.2 and later we continue to include refeferences for
MD5, DER, and Base64; RFC 4462 only included those references in the
first corresponding subsection.  At this point, it's probably not
worth making any changes, though.


And one editorial note:

On page 6, "non- zero" should not have a space.


-Ben