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> Fri, 13 February 2015 18:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6EB311A005F for <>; Fri, 13 Feb 2015 10:16:59 -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 g2oFP_J3mYCQ for <>; Fri, 13 Feb 2015 10:16:56 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 025BB1A00BD for <>; Fri, 13 Feb 2015 10:16:55 -0800 (PST)
X-AuditID: 12074425-f79846d0000054e1-16-54de3f9658ef
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 3D.36.21729.69F3ED45; Fri, 13 Feb 2015 13:16:54 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1DIGslu028230 for <>; Fri, 13 Feb 2015 13:16:54 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t1DIGq3f027155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Fri, 13 Feb 2015 13:16:53 -0500
Received: (from kaduk@localhost) by ( id t1DIGp11027091; Fri, 13 Feb 2015 13:16:51 -0500 (EST)
Date: Fri, 13 Feb 2015 13:16:51 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
In-Reply-To: <>
Message-ID: <>
References: <> <>
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+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrTvN/l6IwfNvJhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxutFPxkLzvJWrH3+grmB8TlXFyMnh4SAicSWnQdYIGwxiQv3 1rN1MXJxCAksZpJY9e0HM4RznFGi989CVgjnBpPE0de72SGcBkaJyyuXsIP0swhoS3xYOJMZ xGYTUJGY+WYjG4gtIiAssXvrO7BRwgIzGSU6zzQzgSQ4BdQlpt/YCbScg4NXwEFi+dU4kLCQ QIzE/vNzwGaKCuhIrN4/Bew+XgFBiZMzn4DZzAJaEsunb2OZwCgwC0lqFpLUAkamVYyyKblV urmJmTnFqcm6xcmJeXmpRboWermZJXqpKaWbGEEByO6iuoNxwiGlQ4wCHIxKPLwTfO6GCLEm lhVX5h5ilORgUhLlfW95L0SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO9CLaAcb0piZVVqUT5M SpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr7wdUKNgUWp6akVaZk4JQpqJgxNkOA/Q 8CSQGt7igsTc4sx0iPwpRkUpcV4DkIQASCKjNA+uF5YgXjGKA70izOsPUsUDTC5w3a+ABjMB DZ444zbI4JJEhJRUA6Nj4Ypnagy3GGbM/p7EnvSjfJ3z4nD9921ZR79nPJIq2vZbZbeOkuyM +CV9R165z5AqKNrZLP3/foKIkQA36w9jc5aTP0+lmF6qXCw2rVySe+X+62ZCmyY/O7q80czU zEQvWeB3Y9jkpJW3GGq26RW/CSkMOSS5dLVcUI1gh9LxVvsSdd05tUosxRmJhlrMRcWJAOCn Ln7rAgAA
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: Fri, 13 Feb 2015 18:16:59 -0000

On Sun, 1 Feb 2015, Greg Hudson wrote:

> On 01/20/2015 06:02 PM, Benjamin Kaduk wrote:
> >
> I reviewed this and did not find any problems with it.

I also did not find any substantive issues with it.  Some non-substantive
issues are noted below.

The reference for the Kerberos V GSS-API mechanism in section 1.1 seems to
have changed from RFC 4121 to RFC 1964; is this a correct change?

The RFC 2119 language conventions statement has been moved later in the
document, after at least the first occurrence of "MUST".  It would be nice
to have the RFC 2119 text before the first use of its keywords.

The original RFC 4402 security considerations include:

   [...] if an
   application can be tricked into providing very large input octet
   strings and requesting very long output octet strings, then that may
   constitute a denial of service attack on the application; therefore,
   applications SHOULD place appropriate limits on the size of any input
   octet strings received from their peers without integrity protection.

It is not clear to me that integrity protection is sufficient to alleviate
the denial of service attack, since verifying the message integrity may
itself consume a substantial amount of resources.

In the added text,

% This document obsoletes RFC 4402 and reclassifies that document as
% historic.  RFC 4402 starts the PRF+ counter at 1, however a number
% implementations starts the counter at 0.  As a result, the original

it should be "a number of implementations start" (add "of" and remove 's'
from "starts") to be grammatical.

Thanks again to Greg for supplying the test vectors.