Re: [Gen-art] Review of draft-ietf-kitten-krb-auth-indicator-04

[Benjamin Kaduk <[e-mail]>]

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