[kitten] Review of draft-ietf-kitten-krb-auth-indicator-04

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Review of draft-ietf-kitten-krb-auth-indicator-04

Robert Sparks
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.

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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jari Arkko-2
Many thanks for the review, Robert. These reviews are much appreciated,
and at least from my perspective, improve the quality of the RFCs. Happy
to hear from Benjamin that he’s considering the editorial issues Robert
found in this case.

Jari


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (859 bytes) Download Attachment