Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 17 February 2015 21:42 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615571A90E5 for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 13:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1DpsKw52PN2O for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 13:42:21 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 118EE1A90DA for <kitten@ietf.org>; Tue, 17 Feb 2015 13:41:58 -0800 (PST)
X-AuditID: 12074422-f79d16d0000024cf-28-54e3b5a6ec8f
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.05.09423.6A5B3E45; Tue, 17 Feb 2015 16:41:58 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t1HLfv13018963 for <kitten@ietf.org>; Tue, 17 Feb 2015 16:41:58 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1HLftL4014147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Tue, 17 Feb 2015 16:41:57 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t1HLftJq029537; Tue, 17 Feb 2015 16:41:55 -0500 (EST)
Date: Tue, 17 Feb 2015 16:41:55 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1502131327150.3953@multics.mit.edu>
References: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrbts6+MQg+dPpCyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF8Xl7IXbFCsuDPjGEsD4xGpLkZODgkBE4lDeyYyQdhiEhfu rWcDsYUEFjNJPG+z7mLkArKPM0rc3jifBcK5wSRx++MxNgingVHi5YxDjCAtLALaEid3NLOA 2GwCKhIz32wEGyUiICyxe+s7ZpAGYYGZjBKdZ5rB9nEKOEn0PWsEK+IVcJC4evIpO8RuR4lp l7aB2aICOhKr909hgagRlDg58wmYzSygJbF8+jaWCYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRrqpebWaKXmlK6iREUgOwuSjsYfx5UOsQowMGoxMM7YdKjECHWxLLiytxD jJIcTEqivDPmPA4R4kvKT6nMSCzOiC8qzUktPsQowcGsJMIblAKU401JrKxKLcqHSUlzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4GXbAtQoWJSanlqRlplTgpBm4uAEGc4DNFwfpIa3 uCAxtzgzHSJ/ilFRSpyXByQhAJLIKM2D64UliFeM4kCvCPOmgFTxAJMLXPcroMFMQIPn/3kE MrgkESEl1cCY/cDh1ITXCf/Ukjiuv7q+v2tRlU9Xu04TD9sSXpOf6fKxba6h+s/PaYjnJB2o VrrIs05igUxp8p6La9q4Y/zKVr1xZD6tWcww3cisyJ2VPdXQhtsq/+TCqHuR2XLVkYoWm3/y Gh7Y29nYZGf45pLuu9s/ZhTG5goUPTmiyu/xqE1WziRQVomlOCPRUIu5qDgRAO/7+GTrAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/j-rGMzIX5tZELt_2MCLs1DrZgwY>
Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2015 21:42:24 -0000

On Tue, 20 Jan 2015, Benjamin Kaduk wrote:

> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

I reviewed this one, and it seems fine.  A few minor (nonsubstantive)
issues below.


The new text says:

   In Section 7, pepper string 2 is corrected to comply with the string
 	   actually used by implementations.

However, the actual body text where the change to this string is made just
refers to it as "pepper2", so it might be better to be consistent and say
"the pepper2 string is corrected".


The introductory text in section 7 and the description of the attack read
almost as if they were originally written for a different context and just
dropped in place here; the terminology used does not match well with the
rest of the document.  For example, what are "channels"?  What does it
mean for a channel to have "a given name"?  The text here could probably
be drastically improved; perhaps we should take the time to do so since we
are already modifying the document.

I think that the attack could be expressed more cleanly, too -- "it is
desirable that neither the KDC nor the client unilaterally determine the
ticket session key" doesn't really say why.  What this extension is doing
is providing a binding between the party which generated the session key
and the DH exchange used to generate the reply key.  Supposing for the
sake of argument that the KDC picks the ticket session key as usual,
absent the use of PA-PKINIT-KX, the client and KDC would perform a DH key
exchange to determine a shared key, and that key would be used as the
reply key.  The KDC generates a ticket with session key as usual, and
encrypts the reply using the result of the DH agreement.  If there is a
MITM, the attacker can just decrypt the session key + ticket using the
DH key from the attacker<-->KDC DH exchange, and reencrypt it using the
key from the attacker<-->client DH exchange, keeping a copy of the session
key and ticket.  By requiring the session key to be a function of the
reply key in a way that can be verified by the client, this extension
binds the ticket to the DH exchange and prevents the MITM attack.



Some nits in the original RFC 6112 text:


In the introduction,

   [...] Note that
   the membership of a realm can imply a member of the community
   represented by the realm.

seems ungrammatical.


At the bottom of page 4, "For example, an anonymous principal that is
identifiable only within a particular group of users can be implemented
using authorization data and such authorization data, if included in the
anonymous ticket, would disclose the client's membership of that group."
is a bit awkward.  I would probably rephrase it as "For example, an
anonymous principal that is identifiable only as being one of a particular
group of users can be implemented using authorization data.  Such
authorization data, if included in the anonymous ticket, would disclose
that the client is a member of the group in question."


In section 4.1:

   The Kerberos client can use the client's long-term keys, the client's
   X.509 certificates [RFC4556], or any other pre-authentication data,
   to authenticate to the KDC and requests an anonymous ticket in an AS
   exchange where the client's identity is known to the KDC.

I think that the final 's' in "requests" is ungrammatical and should be
removed.


At the top of page 6, "According to [RFC4120]" could just as easily be "As
specified by [RFC4120]", since this is just repeating standard Kerberos
behavior.


Two paragraphs later, we could
s/AD-INITIAL-VERIFIED-CAS/AD_INITIAL_VERIFIED_CAS/ (twice), since the
ad-type assigned number uses the underscores and the ASN.1 type uses
hyphens.  (This also appears in section 4.2 on page 9.)


The final paragraph of section 4.1 starts with "The client can use the
client keys"; the phrase "client keys" does not appear anywhere else in
this document, or RFC 4120, or RFC 4556.  Perhaps the intent was "the
client's key" instead.


In the last sentence of page 7, I think that "Anonymity PKINIT" should be
"Anonymous PKINIT".



In section 4.2, there's a missing space in "the anonymous KDC optionSHOULD
be set in the request."


-Ben