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