[kitten] SPAKE preauth: deriving RFC3961 encryption keys

Greg Hudson <ghudson@mit.edu> Fri, 12 June 2015 17:06 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188141ACD5B for <kitten@ietfa.amsl.com>; Fri, 12 Jun 2015 10:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGZfNMAgKga2 for <kitten@ietfa.amsl.com>; Fri, 12 Jun 2015 10:06:32 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21921ACD47 for <kitten@ietf.org>; Fri, 12 Jun 2015 10:06:31 -0700 (PDT)
X-AuditID: 12074424-f79b06d000000cfd-4f-557b1196b450
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D4.85.03325.6911B755; Fri, 12 Jun 2015 13:06:30 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5CH6TL8025551 for <kitten@ietf.org>; Fri, 12 Jun 2015 13:06:30 -0400
Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5CH6SsV021622 for <kitten@ietf.org>; Fri, 12 Jun 2015 13:06:29 -0400
From: Greg Hudson <ghudson@mit.edu>
To: kitten@ietf.org
Date: Fri, 12 Jun 2015 13:06:28 -0400
Message-ID: <x7dtwuc5017.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixG6nojtNsDrU4PkqCYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro3VtM2PBd/GKvdsOMzUw7hPuYuTkkBAwkVg2ZxY7hC0mceHe erYuRi4OIYHFTBLPOy8xQzjHGSU2XbkJlelgktj+ZRYLSAubgLLE+v1bwWwRAWGJ3VvfMYPY wgIWEttbm8HGsgioSkxd0MMEYvMKGEos6VnEBmELSpyc+QSsl1lAQuLgixfMExh5ZiFJzUKS WsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4PFxUdjA2H1I6xCjAwajE w5ugVRUqxJpYVlyZe4hRkoNJSZS3hq86VIgvKT+lMiOxOCO+qDQntfgQowQHs5IIrywjUI43 JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYLXSgCoUbAoNT21Ii0zpwQh zcTBCTKcB2j4apAa3uKCxNzizHSI/ClGRSlxXnOQhABIIqM0D64XFr+vGMWBXhHmNQOp4gHG Plz3K6DBTECD23uqQAaXJCKkpBoYtXbNSJWql55w9Ohx83PnmgItddN3ZYk9Ob6s/l9pi6uu 45Lc+Lda06feFtU05VWqjVo8oVk8jYWJ973gxEDeqN2cx6QqP3FWZfguM1nQlRlwyG4Vm+iX GO6Nkhc65ef+O9IXOSuxvK5xMoOTxj3jZPnKud/2xG6+NvfEk+OTNS5oL6lcwsenxFKckWio xVxUnAgAGx2DZLoCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/_Te6eb83kgMLVHyQhMTiGtrZaaE>
Subject: [kitten] SPAKE preauth: deriving RFC3961 encryption keys
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, 12 Jun 2015 17:06:36 -0000

In the current design of the SPAKE preauth mechanism, once the client
generates its public value, the client and KDC need to derive a series
of RFC 3961 encryption keys K'[n].  Keys in this series are used for
confirmation in the SPAKEResponse, to encrypt any subsequent
second-factor challenges and responses, and finally for the reply key.
The basic inputs for this derivation are the computed shared value K,
the transcript checksum, and the encoded KDC-REQ-BODY for the request
being sent or processed.  The initial reply key (typically the client
principal long-term key) can also be used as an input, although it was
already used as an input to the SPAKE negotiation.

The current draft in github [1] specifies, basically, that K'[n] is
random-to-key(PRF+(initial-reply-key, "SPAKEKey"||K||cksum||body||n)).
This method is convenient in that it uses only RFC 3961 operations.  But
it relies on the security properties of the PRF in a weird way; the
assumed high-entropy information (K) is in the PRF input string, while
the PRF key is assumed to be low-entropy.

Let's call that alternative 1.  Here are two other alternatives:

2. Each group profile [2] designates an unkeyed hash function H (e.g.
SHA-256).  Following a similar method to RFC 4556, we derive K'[n] as
follows:

  H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...)
  K'[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen)

3. As in (2), with the additional step of combining the result with the
additional reply key using KRB-FX-CF2:

  H+(x, k) = k-truncate(H(1||x) || H(2||x) || ...)
  Ki[n] = random-to-key(H+(n||"SPAKEKey"||K||cksum||body), seedlen)
  K'[n] = KRB-FX-CF2(initial-reply-key, Ki[n], "pepper1", "pepper2")

I don't believe this additional step is necessary, because K is already
derived from the initial reply key via the SPAKE algorithm.  But
depending on how one reads the language of RFC 6113 section 3.2, that
step might be required in order to say that we implement the
"strengthening reply key" facility.  That section begins:

   Particularly when dealing with keys based on passwords, it is
   desirable to increase the strength of the key by adding additional
   secrets to it.  Examples of sources of additional secrets include the
   results of a Diffie-Hellman key exchange or key bits from the output
   of a smart card [KRB-WG.SAM].  Typically, these additional secrets
   can be first combined with the existing reply key and then converted
   to a protocol key using tools defined in Section 5.1.

Section 5.1 defines KRB-FX-CF1() (which combines two passphrases),
KRB-FX-CF2(), and PRF+ as an intermediate step of defining
KRB-FX-CF2().

Do people have opinions on which option is best?  Have I missed anything
else?

[1] https://github.com/npmccallum/ietf

[2] Group profiles don't exist in the current draft, but we are planning
to shift to numbered, registered group profiles in order to avoid
interop issues with calculating M and N, representing points and
producing scalars, etc.