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

Nico Williams <> Mon, 16 February 2015 04:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8546B1A8732 for <>; Sun, 15 Feb 2015 20:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tcwFnYB5iORC for <>; Sun, 15 Feb 2015 20:10:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 299171A19E4 for <>; Sun, 15 Feb 2015 20:10:30 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id D5E752005693E; Sun, 15 Feb 2015 20:10:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=nt4kWzlZtGU60P NCsyPtQmC9+Q4=; b=BREtFZgKmVFTDcMq3FFzMMJBDKhB/aghkQJx/7EcESz628 FPULBkrBmFlGIZWKCW8B2WADuujJLQZqxoP8vT6nAzl4+rylkn99W9gvwq4/n+Zz xLKhIkrtQljv8gcsRZhyCBUdF0mfuPQACmqtvVkMi43+zs4KtGzuRfuU5B3Iw=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 84C2A20060013; Sun, 15 Feb 2015 20:10:29 -0800 (PST)
Date: Sun, 15 Feb 2015 22:10:28 -0600
From: Nico Williams <>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20150216041027.GB5246@localhost>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Mon, 16 Feb 2015 04:10:33 -0000

Please forgive me for being so late with these reviews.

On Tue, Jan 20, 2015 at 06:02:24PM -0500, Benjamin Kaduk wrote:

FWIW, my only comment as to rfc4402bis is that rfc4402 wasn't "my" RFC,
just an Internet RFC that I authored.  Not sure if that's even a nit.


I've not reviewed the entirety of this document, just the docs from
RFC5653 to rfc5653bis-02.


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.


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)?

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.

(Do we need to be more careful about defining "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.)