Re: Review of draft-ietf-kitten-krb-auth-indicator-04
Benjamin Kaduk <kaduk@mit.edu> Sun, 25 December 2016 18:24 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0467B12953D; Sun, 25 Dec 2016 10:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.301
X-Spam-Level:
X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 8b1nABdJCe6c; Sun, 25 Dec 2016 10:24:37 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 2AEE41293DA; Sun, 25 Dec 2016 10:24:33 -0800 (PST)
X-AuditID: 12074423-137ff7000000405f-b4-58600ee07ce9
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id AD.22.16479.0EE00685; Sun, 25 Dec 2016 13:24:32 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uBPIOV4k008943; Sun, 25 Dec 2016 13:24:32 -0500
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 uBPIOR76026136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Dec 2016 13:24:30 -0500
Date: Sun, 25 Dec 2016 12:24:28 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Robert Sparks <rjsparks@nostrum.com>
Subject: Re: Review of draft-ietf-kitten-krb-auth-indicator-04
Message-ID: <20161225182404.GN8460@kduck.kaduk.org>
References: <148243567232.26011.10783984451734200377.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <148243567232.26011.10783984451734200377.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrvuALyHCYMYrS4u5Lb9ZLK6++sxi 8WzjfBaLo5tXsVhcm9PI5sDqsWTJTyaPWTufsAQwRXHZpKTmZJalFunbJXBlzGtYyFbQIVnR dm4KSwPjXJEuRk4OCQETiTO/pzOB2EICbUwS1/+ydTFyAdkbGSX2XJzLCOFcZZL4v2kTO0gV i4CqxO8XP9hAbDYBFYmG7svMILaIgIbEtSVLwGqYBQokuiZ/ZwGxhQXsJJ5OXwW2gVfAWOJA 7y4WiG1+Ei9mrGeGiAtKnJz5hAWiV0vixr+XQPUcQLa0xPJ/HCAmp4C/xMRZkiAVogLKEg0z HjBPYBSYhaR5FpLmWQjNCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgQH sIvyDsaXfd6HGAU4GJV4eCu4EyKEWBPLiitzDzFKcjApifKqbY6JEOJLyk+pzEgszogvKs1J LT7EKMHBrCTCG8IJVM6bklhZlVqUD5OS5mBREue9lOkeISSQnliSmp2aWpBaBJOV4eBQkuB1 5QVqFCxKTU+tSMvMKUFIM3FwggznARq+AKSGt7ggMbc4Mx0if4pRUUqct5AHKCEAksgozYPr BSUYiez9Na8YxYFeEeZdC9LOA0xOcN2vgAYzAQ3Wr48HGVySiJCSamDMNJa03BthfGf60+i4 5tuC//QWVrxheOXZJ3DzcO3TxwtE8rdeWtLmHz8tt4vj5fK1a2q4Xn4zdJ5b/ORIw+kzd6LV ua2LCu4Ze7Cq5Z/OXXZQp7OvetYDZ+ar7XOcwr0z99xYXig/4XBJ7/c7it52KWG7NsiePfHk 31bpiWuun43RDmfLiL6hxFKckWioxVxUnAgAfjrKBAsDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/15QxH-TGMsSjQEAd3o3ZJmN0NgA>
Cc: kitten@ietf.org, gen-art@ietf.org, draft-ietf-kitten-krb-auth-indicator.all@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Dec 2016 18:24:40 -0000
Hi Robert, Thanks for the review (I'm the shepherd, not the editor). On Thu, Dec 22, 2016 at 11:41:12AM -0800, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-kitten-krb-auth-indicator-?? > Reviewer: Robert Sparks > Review Date: 2016-12-22 > IETF LC End Date: 2017-01-06 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready for publication as Proposed Standard, but > with nits that should be considered before advancing > > Nits/editorial comments: > > Please remove the 2119 MUST from the Introduction - you already > have that requirement expressed in the last paragraph of > section 3. If the introduction needs to highlight that the > requirement exists, say something similar to "Section 3 > requires that elements of this type appear within an AD-CAMMAC > container." > > The 3rd paragraph in section 4 has a MAY in its first sentence > that is not an appropriate use of 2119. A lower case "may" is > fine here - you're not placing a requirement on implementation. Those first two comments look like good changes to me. > That whole 3rd paragraph looks like an attempt to acknowledge > a larger conversation without getting into the meat of that > conversation. Rather than make the readers re-discover the > problem on their own (right now they have to guess at what > the problem really is, with your suggested guidance being > the only hint), can you explicitly demonstrate the potential > problem? Perhaps pointing to existing discussion in another > document would be good? There's bound to be something in > our various policy framework documents that captures why > you need either only positive or only negative assertions > if you are going to be combining them. We ran into pretty > much this problem with presence - grep for "positive grants" > in RFC5025 for instance. I suspect there's a better reference > that I'm just not remembering at the moment. This is also a good point, but I'm not sure I have a good suggestion of a reference to insert. To give a more concrete example relevant to this document, at the moment, you can authenticate to kerberos in many ways, including with a password, using an OTP value (within a RFC 6113 FAST tunnel), and with PKINIT asymmetric crypto. One might be tempted to put in a value "without-password" to indicate that a password was not used, but when an application server goes to consume that authentication indicator, the assumption might be that without-password means PKINIT, which is arguably a stronger authentication than the OTP method. Thus, there is the possibility of the application server would make a bad decision based on the negative "without-password" indicator, in contrast to an explicit "pkinit" or "otp" indicator. -Ben
- Review of draft-ietf-kitten-krb-auth-indicator-04 Robert Sparks
- Re: Review of draft-ietf-kitten-krb-auth-indicato… Benjamin Kaduk
- Re: Review of draft-ietf-kitten-krb-auth-indicato… Jari Arkko