Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2.

Kelley Burgin <kwburgi@tycho.ncsc.mil> Wed, 13 February 2013 16:25 UTC

Return-Path: <kwburgi@tycho.ncsc.mil>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71DE21F84DF for <kitten@ietfa.amsl.com>; Wed, 13 Feb 2013 08:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnikDNgSuPhB for <kitten@ietfa.amsl.com>; Wed, 13 Feb 2013 08:25:31 -0800 (PST)
Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3759B21F8428 for <kitten@ietf.org>; Wed, 13 Feb 2013 08:25:30 -0800 (PST)
X-TM-IMSS-Message-ID: <33d1f3f10000d414@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 33d1f3f10000d414 ; Wed, 13 Feb 2013 11:25:57 -0500
Received: from [192.168.26.151] (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DGO422017516; Wed, 13 Feb 2013 11:25:22 -0500
Message-Id: <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil>
From: Kelley Burgin <kwburgi@tycho.ncsc.mil>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOiHH+MgVLYp_NLBufnGpdTSB3uLcpOnpS6W4xFoUtVSbw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 13 Feb 2013 11:28:05 -0500
References: <tsl1uckz4u6.fsf@mit.edu> <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> <CAK3OfOiHH+MgVLYp_NLBufnGpdTSB3uLcpOnpS6W4xFoUtVSbw@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: "kitten@ietf.org" <kitten@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2.
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 16:25:34 -0000

These enctypes are to support draft-burgin-kerberos-suiteb, so the  
move from SHA-1 was the major motivation. We switched to CTS in -02  
after the discussion on DCE/MS-RPC a year or two ago. The other major  
difference is we mac the ciphertext instead of the plaintext.

I didn't intend for the draft to be incomplete in the switch to CTS  
and would certainly appreciate more detailed comments on revisions  
needed.

Kelley

On Feb 13, 2013, at 10:57 AM, Nico Williams wrote:

> On Wed, Feb 13, 2013 at 9:22 AM, Love Hörnquist Åstrand <lha@kth.se>  
> wrote:
>> This dradt uses cbc. Is the considerations that made us use cts  
>> mode/padding no longer important (dce/ms-rpc) ?
>
> The -02 seems to have switched to CTS, but the edits for that change
> are incomplete.
>
> I assume that a -03 will complete the switch to CTS.
>
> No motivation is given for the new enctypes, but I assume it's the
> obvious motivation: to move away from SHA-1.
>
> As for CBC vs. CTS, we really want CTS for reasons having to do with
> the SSPI -- we want the only ciphertext expansion to be of static size
> and to result from a) the use of a confounder (this is done in
> RFC3961, so this I-D needn't mention confounders any more than
> RFC3962), and b) the authentication tag (the MAC).
>
> CTS does have its problems, namely that it's hard to implement in
> terms of CBC: it's difficult to implement CTS using cryptographic
> coprocessors.  The best one can do is use two (and sometimes three)
> AES-CBC cryptographic coprocessor operations  The AES-NI instructions
> make this less of a concern.
>
> Nico
> --