Subject: Gen-art LC review: draft-ietf-kitten-rfc6112bis-02

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Oct 2016 10:44:13 -0500

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-kitten-rfc6112bis-02
Reviewer: Robert Sparks
Review Date: 21 Oct 2016
IETF LC End Date: 2 Nov 2016
IESG Telechat date: Not yet scheduled on a telechat

Summary: Ready with nits

Nits/editorial comments:

Shouldn't the IANA considerations instruct IANA to update the registries 
at 
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml 
to update the three rows that currently point to 6112 to point to this 
document instead (or at least in addition to 6112)?

Micro-nit: There is a 2119 MUST carried forward from RFC6112 that could 
be improved if the group is willing. "Care MUST be taken by the TGS to 
not reveal". I would suggest "The TGS MUST NOT reveal...". If you need 
to further highlight care, add a sentence that says "Implementers need 
to be particularly careful when addressing this requirement." It is a 
very small nit - please feel free to ignore it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 23 Oct 2016 14:22:11 -0400 (EDT)

On Fri, 21 Oct 2016, Robert Sparks wrote:

> Shouldn't the IANA considerations instruct IANA to update the registries at

Yes, thanks for spotting that.

> Micro-nit: There is a 2119 MUST carried forward from RFC6112 that could be
> improved if the group is willing. "Care MUST be taken by the TGS to not
> reveal". I would suggest "The TGS MUST NOT reveal...". If you need to further
> highlight care, add a sentence that says "Implementers need to be particularly
> careful when addressing this requirement." It is a very small nit - please
> feel free to ignore it.

That looks like a good change to me.  Folks on kitten@, does anyone think
otherwise?  If we do not get any objections, I think we can include that
in an RFC Editor Note.

-Ben

---

From: Shawn M Emery <[email-masked]>
Date: Mon, 24 Oct 2016 15:12:25 -0600

> Yes, thanks for spotting that.

Yes, thank you for your review.

> otherwise?  If we do not get any objections, I think we can include that

Agreed, however I noticed another area that could use better 2119 
language in regards to this.  Here are the proposed updates:

OLD:
Care MUST be taken by the KDC not to reveal the client's identity in the 
authorization data of the returned ticket when populating the 
authorization data in a returned anonymous ticket.
NEW:
The KDC MUST NOT reveal the client's identity in the authorization data 
of the returned ticket when populating the authorization data in a 
returned anonymous ticket.

OLD:
Care MUST be taken by the TGS not to reveal the client's identity in the 
authorization data of the returned ticket.
NEW:
The TGS MUST NOT reveal the client's identity in the authorization data 
of the returned ticket.

I have the following RFC Editor notes to date (including the above):

Section: 9.  Acknowledgements
-----------------------------------------
OLD:
9.  Acknowledgements
NEW:
9.  Acknowledgments

Greg Hudson and Robert Sparks had provided helpful text in the bis 
version of the draft.

Section: 10.  IANA Considerations:
---------------------------------------------
<Note to IANA>

         Please update the following Kerberos Parameters registries:

         Well-Known Kerberos Principal Names
         Well-Known Kerberos Realm Names
         Pre-authentication and Typed Data

         to reference this RFC instead of RFC6112.

Shawn.
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Oct 2016 21:51:39 -0400 (EDT)

On Mon, 24 Oct 2016, Shawn M Emery wrote:

>
> Agreed, however I noticed another area that could use better 2119 language in
> regards to this.  Here are the proposed updates:
>
> OLD:
> authorization data of the returned ticket when populating the authorization
> data in a returned anonymous ticket.
> NEW:
> The KDC MUST NOT reveal the client's identity in the authorization data of the
> returned ticket when populating the authorization data in a returned anonymous
> ticket.
>
> OLD:
> The TGS MUST NOT reveal the client's identity in the authorization data of the
> returned ticket.

Those do look like parallel constructions that should get the same
treatment.  Thanks for spotting it.

-Ben