Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

[Benjamin Kaduk <[e-mail]>]

On Sun, 15 Feb 2015, Nico Williams wrote:

>
> Please forgive me for being so late with these reviews.
>
> On Tue, Jan 20, 2015 at 06:02:24PM -0500, Benjamin Kaduk wrote:
>
> > http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01
>
> I've not reviewed the entirety of this document, just the docs from
> RFC5653 to rfc5653bis-02.
>
> Comments:
>
> My one comment on the changes is that having GSSException()
> constructors that take major and minor status code numbers seems...
> like a bad idea, particularly as to minor status codes.  HOWEVER,
> since some implementations may use an all-Java GSSException class even
> with a JNI bindings for the rest of the API (or for specific mechanism
> providers), it seems like a good idea for that purpose.  I don't think
> this is worth mentioning in the I-D; this is really just a comment for
> the mailing list archive.

Yeah, it's a bit late to try to not have minor codes in the constructor
argument list.


> > http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00
>
> Ditto here, I'm only reviewing the changes, not the entire I-D.
> Although I have one comment as to the original RFC:
>
>  - Should we take this opportunity to define an AD to carry the PKINIT
>    client cert and its validation cert chain (and trust anchor)?

That seems more like something I would want to put in a 4556bis than a
6112bis (though of course there is no rule preventing it from being done).
I'm inclined to not try to add such an AD in at this time.

> Regarding the change in section 4.2, the only reason for not reducing
> the MUST further to MAY is probably interoperability with TGSes that
> implemented the "MUST return a KRB-ERROR..." text that is being deleted.
> This seems to merit a mention, something like:
>
>    If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
>    one, the client SHOULD set the anonymous KDC option in the request
>    for interoperability with TGSes that insist on it.  The TGS SHOULD
>    ignore the presence/absence of the anonymous KDC option in the
>    request when the the ticket in the request is an anonymous ticket.

I think we should say something about "for interoperability with ..."
("insist on it" is probably too colloquial).  I had pondered saying
something about the TGS behavior when I reviewed this change as well, but
did not say anything about it in my review.  I don't see any harm in
spelling it out, though.

> (Do we need to be more careful about defining "anonymous ticket"?

You mean here in 4.2?  I don't think so; section 3 has an extensive
definition of what it means to be an anonymous ticket.

>  Clearly this refers to tickets whose cname is anonymous, but in the
>  user-to-user case the sname of the second ticket could be anonymous,
>  and when we add post-dating, one could even have a TGS-REQ where the
>  ticket has an anonymous sname.  Such a request is bound to fail, and
>  makes no sense anyways!  This is just a twisted case just to
>  demonstrate that it's the cname of a ticket that determines whether its
>  an anonymous one or not.  Just a curiosity.)

Oh, but maybe we should be more careful about "in the request", hmm.

-Ben