IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 23 May 2014 02:18 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9731A02B7 for <kitten@ietfa.amsl.com>; Thu, 22 May 2014 19:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Q8koXapT44 for <kitten@ietfa.amsl.com>; Thu, 22 May 2014 19:18:15 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC341A0040 for <kitten@ietf.org>; Thu, 22 May 2014 19:18:14 -0700 (PDT)
X-AuditID: 1209190f-f790b6d000000c38-b3-537eafe4c0fc
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 23.F2.03128.4EFAE735; Thu, 22 May 2014 22:18:12 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s4N2IAT0010644; Thu, 22 May 2014 22:18:11 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4N2I6EU010469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 May 2014 22:18:10 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s4N2I6uH004664; Thu, 22 May 2014 22:18:06 -0400 (EDT)
Date: Thu, 22 May 2014 22:18:06 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Peck, Michael A" <mpeck@mitre.org>
In-Reply-To: <CFA4177F.E034%mpeck@mitre.org>
Message-ID: <alpine.GSO.1.10.1405222142410.25244@multics.mit.edu>
References: <52AE9A65.1010700@oracle.com> <53799133.70201@oracle.com> <alpine.GSO.1.10.1405221659110.25244@multics.mit.edu> <CFA4177F.E034%mpeck@mitre.org>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixG6nrvtkfV2wQccjLoujm1exWJy+9ZzZ gcljyZKfTB5vG66yBzBFcdmkpOZklqUW6dslcGXMPneeraBVpeLLzmdsDYwPZboYOTkkBEwk bi19zQphi0lcuLeerYuRi0NIYDaTRNP6K6wQzkZGiU+TnrBDOIeYJFom3oAqa2CU+PJ+LQtI P4uAtsSzDReZQWw2ARWJmW82soHYIgLqEn2He8BqmIHsb2feMILYwgIuEg92bwSzOQV0JCad nssOYvMKOEq0HL0PcwejxNLTHWAHigIVrd4/hQWiSFDi5MwnUEMtJc79uc42gVFwFpLULCSp BYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYLClVOSfwfjt4NKhxgFOBiV eHgtWOuChVgTy4orcw8xSnIwKYnySq4GCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh9QkFyvGm JFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHi/rgNqFCxKTU+tSMvMKUFI M3FwggznARreD1LDW1yQmFucmQ6RP8WoKCXO6wmSEABJZJTmwfXC0skrRnGgV4R5X4FU8QBT EVz3K6DBTECDXyysBRlckoiQkmpgFLWfvbZujkXizD2/9l/xP2n0/PKmie11ZrIvDigmiX+6 XN36mcG29MPHkgXL49Y/m31IcnW5bEJ9rt6rVb3TV69n1WV8pzf9b6TCjAsrD8zcvEE5rey3 iJy70azzAnsKzqxWZebtyRaeL7ulWdZ8K9e5SI81HywubVdeqCeUc3VCG+crNbUrK5VYijMS DbWYi4oTAe4HDyQCAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/WgMO_Myyh4Ccfc2vU8ghMZ0NFDo
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-02
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 23 May 2014 02:18:16 -0000

On Thu, 22 May 2014, Peck, Michael A wrote:

> Thanks for the comments, I'll fix those.

Thanks.

> Could you help me understand or give an example of what the pseudo-random
> function defined in the protocol parameters is used for?  I'm not quite
> following the RFC 3961 section 3 definition.

Sure.  Probably the easiest example to refer to that comes to mind is in 
the implementation of gss_pseudo_random() for the krb5 mech, RFC 4402.

The summary is that an RFC 3961 enctype is supposed to provide a 
deterministic way to turn a protocol key and some input string into 
pseudo-random bits, which are unpredictable to anyone who does not know 
the protocol key.  The output from this function is a fixed length per 
enctype, so consumers frequently end up defining a PRF+ function to get 
arbitrary-length output.

> We already separately define how a base-key is derived from a passphrase
> (in cases where a passphrase is used), and how the Kc, Ke, and Ki keys are
> derived from the base-key. What are the additional use cases for a generic
> PRF?

RFC 3961 sort of hints at this with the phrase "suitable for use in key 
generation".  I don't think I know of any uses of the prf other than for 
key generation.  This would basically always be key generation for some 
key to be used outside of kerberos, bootstrapping from (say) a kerberos 
session key and some other shared state between two parties.

gss_pseudo_random() is used in draft-wilkinson-afs3-rxgk; in implementing 
that protocol we actually discovered a couple of interoperability issues 
between Heimdal and MIT kerberos, partially because the prf functionality 
was not very well specified originally (which in turn is possibly because 
the original authors did not really have a concrete use in mind).

> Right now our pseudo-random function definition refers to KDF-HMAC-SHA2,
> which we define in section 3 but in the context of deriving the base-key,
> Kc, Ke, or Ki key (so that we get the right output length) rather than
> arbitrary keys, so we may need to clean up that language a bit.  Then
> you're right that it just says "HMAC" which would mean an output of 256 or
> 384 bits, which probably isn't right (RFC 3961 says the "pseudo-random
> function should generate an octet string of some size" - but how do we
> know what size is needed?).  Also, calling HMAC a second time rather than
> just passing the octet-string (and perhaps a desired output length?) into
> KDF-HMAC-SHA2 may be redundant.

That's a good point; it's not specified what the length of Kp is for the 
aes256-cts-hmac-sha384-192 variant.  It would seem that section 3 should 
cover the Kp case as well as Kc, Ke, Ki, and the base key.  (I just 
assumed that it was 192, when I was reading it.)

The introduction does say "the HMAC algorithm uses the SHA-256 or SHA-384 
hash algorithm", so I think that the bare usage of "HMAC" at the end of 
section 5 is reasonably well specified; it's only which variant of 
KDF-HMAC-SHA2 should be used that is particularly unclear.  We could 
"cheat" by changing the "prf" input to KDF-HMAC-SHA2 to instead be "prfU", 
since ASCII 'U' is 0x55 (and the 'ends in 0x55' case is already covered 
for Ki), but it's probably better to explicitly specify which form to use.
I don't think there's a need to specify a fully general KDF-HMAC-SHA2, 
since that's just an internal tool used in defining other quantities, and 
it is those output quantities which are actually parameters of the RFC 
3961 enctype.

There is some strong convention that the pseudo_random() output be a 
multiple of the message block size of the underlying cipher, but from 
memory I do not think that RFC 3961 imposes that as a hard constraint. 
There is not really any other restriction or condition on what size output 
it should produce; consumers are already using PRF+ constructs because of 
existing enctypes, so we just need to pick a length. (In any case, whether 
HMAC is SHA-256 or SHA-384, it is still a multiple of the 128-bit block 
size for AES, so "multiple of the block size" is a non-issue.)

I think that calling HMAC a second time is preferable to just passing the 
octet-string into KDF-HMAC-SHA2; it seems to be more in keeping with the 
other applications of KDF-HMAC-SHA2 in the specification.

I will note again for clarity that the output length of pseudo_random() is 
a protocol constant; the idea of a "desired output length" is not 
relevant, since the output length must always for any key of a given 
enctype.

Hope that helps.

-Ben

v2.23.0 | Report a Bug | By Email