[kitten] RFC 3961 key-derivation operation

Greg Hudson <ghudson@mit.edu> Sun, 03 May 2015 15:16 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0B4121A6EF9 for <kitten@ietfa.amsl.com>; Sun, 3 May 2015 08:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 03P2zraJeQxY for <kitten@ietfa.amsl.com>; Sun, 3 May 2015 08:16:53 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF611A6EF4 for <kitten@ietf.org>; Sun, 3 May 2015 08:16:52 -0700 (PDT)
X-AuditID: 1209190f-f79d16d000000d3d-8c-55463be3e49e
Received: from mailhub-auth-2.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7D.AA.03389.3EB36455; Sun, 3 May 2015 11:16:51 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t43FGojM005172 for <kitten@ietf.org>; Sun, 3 May 2015 11:16:51 -0400
Received: from localhost (equal-rites.mit.edu []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t43FGn1I023414 for <kitten@ietf.org>; Sun, 3 May 2015 11:16:50 -0400
From: Greg Hudson <ghudson@mit.edu>
To: kitten@ietf.org
Date: Sun, 03 May 2015 11:16:49 -0400
Message-ID: <x7dr3qx668u.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6novvY2i3U4P08CYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY0HXZqaCiWIV05ZsY2xgbBLqYuTkkBAwkdj44wg7hC0mceHe erYuRi4OIYHFTBKHOmezQjjHGCUOHPjCBOG0M0k0HD3ABtLCJqAssX7/VhYQW0RAWGL31nfM ILawgJbE4wXTwGpYBFQl+hqfAtkcHLwChhI7V9qDhHkFBCVOznwC1sosICFx8MUL5gmMPLOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRFByckvw7GL8dVDrE KMDBqMTD+yPWNVSINbGsuDL3EKMkB5OSKG/iIqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV4V HbdQId6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCV5nYBQICRalpqdW pGXmlCCkmTg4QYbzAA3XB6nhLS5IzC3OTIfIn2JUlBLnTQVJCIAkMkrz4Hph0fuKURzoFWHe jVZAVTzAyIfrfgU0mAlo8IF6F5DBJYkIKakGRhu++ldSzJr5Uap/fh18uVD75euaaUJOdQf6 HGx+z3Up95+waKXg/jaPWYeMN0yf4qonrzrxMKO3i5+ioMCKS5mpfed3iW6/N8XT0KnjM9Nd IWud8HSRms5p53/16nW5NDiZ3DPJlKpr//sosSnrzKY9H284Gf2Tm7l92Zfzk20jXLez/bj6 Q4mlOCPRUIu5qDgRAAMRwSK5AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ut3ef5ipydbHaWsxObIw2JOjbUs>
Subject: [kitten] RFC 3961 key-derivation operation
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: Sun, 03 May 2015 15:16:55 -0000

RFC 3961 defines an abstract interface for an encryption algorithm
profile (colloquially known as an enctype) and a checksum algorithm
profile.  It also defines a "simplified profile," which can be used to
construct an enctype from a block cipher and hash, and several specific
enctypes and checksum profiles.  The operations specified in sections 3
and 4 are visible to consumers such as RFC 4120 and AFS, while other
sections define internal details of specific enctypes and cksumtypes.

I was recently surprised to notice that section 3 includes a
key-derivation operation, (protocol-key, integer)->(specific-key).  I
had previously assumed that key derivation was an internal detail of
enctypes, aside from the requirement that consumers provide a key usage
number for each encryption and checksum operation.

The presence of a key-derivation operation in section 3 suggests that a
consumer could invoke the key-derivation operation explicitly.  I don't
think any Kerberos specification does this.  I'm not sure there is any
reason to do so other than to directly use the bits of the specific-key,
and the PRF operation is probably more suited to that kind of use.

Things only get more confusing as one looks into this further:

* Section 2 says "The specific key should not be explicitly referenced
  outside of this document."  So why does a public enctype operation
  produce a specific-key output?

* Section 5.3, which defines the transformation from simplified profile
  to enctype, specifies a key-derivation function which does not meet
  the abstract form of the key-derivation.  It picks a byte depending on
  whether Kc, Ke, or Ki is being derived.  Note that section 3 states
  "no additional or implicit inputs... are permitted."

* RFC 4757 does not explicitly define a key-derivation operation,
  although it of course uses key derivation internally.

* RFC 6803 mirrors RFC 3961 section 5.3 in defining a key-derivation
  function which does not fit the form of RFC 3961 section 3.

MIT krb5 does not provide a public interface for key derivation.
Heimdal provides a krb5_derive_key() function which accepts a
byte-string input instead of an integer, and implements the
simplified-profile key derivation function; it appears to return an
error for a key of any enctype other than DES3 or the AES-SHA1s.

I think the best conclusion is that RFC 3961 section 3 was mistaken to
include a key-derivation operation, and that future enctype
specifications should not that operation as part of their enctype
profiles.  They should, of course, continue to use key derivation
internally, using the consumer-provided key usage number.

Do others agree?  Should we file an erratum?  This has an impact on
the aes-sha2 spec (as a matter of form, not function, of course).