Re: [kitten] Input on Paul's concerns about aes-cbc

Luke Howard <lukeh@padl.com> Wed, 09 October 2013 02:34 UTC

Return-Path: <lukeh@padl.com>
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 75A0C21F995A for <kitten@ietfa.amsl.com>; Tue, 8 Oct 2013 19:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDYELnh3RnHH for <kitten@ietfa.amsl.com>; Tue, 8 Oct 2013 19:34:44 -0700 (PDT)
Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 03AFF21F9C68 for <kitten@ietf.org>; Tue, 8 Oct 2013 19:34:39 -0700 (PDT)
Received: by us.padl.com with ESMTP id r992YRKt029754; Tue, 8 Oct 2013 22:34:29 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp>
Date: Wed, 09 Oct 2013 13:34:26 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1237751-AD3C-4A09-93DF-8CE56B746499@padl.com>
References: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1510)
X-SMTP-Vilter-Version: 1.3.6
X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST
X-SMTP-Vilter-Spam-Backend: spamd
X-Spam-Threshold: 5.0
X-Spam-Probability: -20.5
Cc: "kitten@ietf.org" <kitten@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] Input on Paul's concerns about aes-cbc
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, 09 Oct 2013 02:34:49 -0000

> While I did write my code that calls SSPI's EncryptMessage() in 1999
> (during W2K beta), and don't exactly remeber which documentation
> I used,  The "MDSN Library October 2001 Platform SDK" contains
> a description titled "SSPI/Kerberos Interoperability with GSS-API
> with this code sample:

Because this sample was geared towards GSS-API interoperability (which was DES only at the time, hence required PKCS#7 padding), it's no surprise that it correctly uses SECBUFFER_PADDING.

That sample code works fine with both truncated token and padding buffers. Paul's point, I guess, is that not all applications follow this.
 
-- Luke