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

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 18 February 2015 03:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 65F001A893F for <>; Tue, 17 Feb 2015 19:45:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hhdyH2Jzydqg for <>; Tue, 17 Feb 2015 19:45:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E2C131A897F for <>; Tue, 17 Feb 2015 19:45:09 -0800 (PST)
X-AuditID: 12074422-f79d16d0000024cf-57-54e40ac5b84f
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id EC.D5.09423.5CA04E45; Tue, 17 Feb 2015 22:45:09 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1I3j8vM025506; Tue, 17 Feb 2015 22:45:09 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t1I3j5J0006481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2015 22:45:08 -0500
Received: (from kaduk@localhost) by ( id t1I3j50K015008; Tue, 17 Feb 2015 22:45:05 -0500 (EST)
Date: Tue, 17 Feb 2015 22:45:05 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <>
In-Reply-To: <20150216041027.GB5246@localhost>
Message-ID: <>
References: <> <20150216041027.GB5246@localhost>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrXuU60mIQd9eEYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY+/Icc8EayYpFcy+zNDD+Fe5i5OSQEDCR OPCmkwXCFpO4cG89G4gtJLCYSWL+RKA4F5C9kVHi37ab7BCJQ0wSU9rMIBINjBLb5j8B62YR 0Jb41z0NrIhNQEVi5puNYJNEBDQlrs9bCmYzCwhLrD83gxmkWVhgJqNE55lmJpAEp4CexPNJ HYwgNq+Ag8TSj5OBbA6gDckSCx4mgoRFBXQkVu+fwgJRIihxcibEXmYBLYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdU73czBK91JTSTYygQGV3UdrB+POg0iFG AQ5GJR7eDqYnIUKsiWXFlbmHGCU5mJREeZO+Pw4R4kvKT6nMSCzOiC8qzUktPsQowcGsJMKr dAIox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwRvDCbRHsCg1PbUi LTOnBCHNxMEJMpwHaLghSA1vcUFibnFmOkT+FKOilDivH0hCACSRUZoH1wtLJK8YxYFeEebl BKniASYhuO5XQIOZgAbP//MIZHBJIkJKqoExeKdyZ619mtMBy8tX43sDHpZ/8n4vuni2VDPX oiU/KirLqkUf8R+V6t3VtOASl8FTUSfvvfUvbj/crPhGa5032+vpScZRJ1O3Wp/Z5ZwUoeP4 +WiC6S7G23+ZPiazPFTXZF1gdLqVR2Lr/sj5b8rqFLbMsipqi5HZc128Kuicwjb+p3+tdaSU WIozEg21mIuKEwHuvfle/wIAAA==
Archived-At: <>
Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Feb 2015 03:45:22 -0000

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:
> >
> 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.

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