Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Jeffrey Altman <> Fri, 10 April 2015 01:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F5701A8F3D for <>; Thu, 9 Apr 2015 18:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QtOiyctEFy8s for <>; Thu, 9 Apr 2015 18:54:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7FF9D1A8F45 for <>; Thu, 9 Apr 2015 18:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; s=MDaemon; t=1428630875; x=1429235675; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=SPbugMnzSDCK/kQQVnYpJGs9E1NFQ6DbEC5apgQ 1baE=; b=n/ufPRb+/mYojKmgzm8p6ANgmkotOPO80efZPnII69qrbNfLKKpgSRr MMj3fSKsZRFDsQZDEamj72NETIbF3WV6wcpdpLFNDA5lMqmefzSXKUK1/KdLxDj5 l8TSltUUGUsyEJRo6qIyJm+6FuoNr8A4KZwHbLEfOgucTFTu8KWA=
X-MDAV-Result: clean
X-MDAV-Processed:, Thu, 09 Apr 2015 21:54:35 -0400
X-Spam-Processed:, Thu, 09 Apr 2015 21:54:35 -0400
Received: from [x.x.x.x] by (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000853745.msg for <>; Thu, 09 Apr 2015 21:54:34 -0400
VBR-Info:; mc=all;;
X-MDArrival-Date: Thu, 09 Apr 2015 21:54:34 -0400
Message-ID: <>
Date: Thu, 09 Apr 2015 21:54:27 -0400
From: Jeffrey Altman <>
Organization: Secure Endpoints Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@MIT.EDU>
References: <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010303070405080007030900"
Archived-At: <>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
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, 10 Apr 2015 01:54:59 -0000

On 4/9/2015 6:26 PM, Benjamin Kaduk wrote:
> Hi Jeffrey,
> On Thu, 9 Apr 2015, Jeffrey Altman wrote:
>> My personal opinion is that the last call should not complete
>> successfully if it is not possible to verify all of the test vectors.
>> It would also be my preference that there be two interoperable
>> implementations before the working group approves the document.
> The authors have used two independent implementations to verify the test
> vectors; I have done some additional verification and Greg has done some
> different verification as well.

I am glad to hear this.  Are there 3961 implementations available for
public review?

> The last I checked, two interoperable implementations was a requirement
> for full Internet Standard, and not required even for Proposed Standard
> documents, let alone the Information status this document claims to be
> targetting. Could you say a bit more about why you feel the situation is
> different here?

The requirements that you mention are lower bounds that apply to all
RFCs regardless of the IETF Area.  Kitten is not any working group.  It
is a security working group whose RFCs are implemented and deployed as
the basis for securing computer systems around the globe.  The last
"informational" Kerberos encryption type RC4-HMAC (RFC 4757) became one
of the most widely deployed enc-types used for Kerberos authentication.

Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die
the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption
types for RFC 3961 based protocols.  Regardless of what track this
document is placed on it is going to be widely and rapidly deployed.  As
a result it is important that the working group ensure that the
encryption type is correct and that independent implementations for the
most widely used Kerberos implementations are available and are
demonstrated to be interoperable.

Without interoperable implementations there is very little justification
in my opinion for publishing a security framework building block as an
RFC.  Its not as if the working group is going to come back and revise
the RFC once it is deployed.


Jeffrey Altman