Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text)

Watson Ladd <watsonbladd@gmail.com> Tue, 19 May 2015 19:09 UTC

Return-Path: <watsonbladd@gmail.com>
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 433D01AD0AC for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 12:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 eIj2uVE6-6pX for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 12:09:22 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4241AD0A6 for <kitten@ietf.org>; Tue, 19 May 2015 12:09:22 -0700 (PDT)
Received: by wgjc11 with SMTP id c11so28857694wgj.0 for <kitten@ietf.org>; Tue, 19 May 2015 12:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=db7V2D7fIpNPc410mAb6LQlIL5r7c13Rb4qFNzdyeWI=; b=feFW1jusWOjigY7wCtkGMjijsi5+lt8sNDDG/MhBRJLyMzavR7BxeMB5ipcwo4gyUJ +L0CYuhe/wA+BJ3CMKgwqHc1T671Qe5j5CLC4TwQTZj2xTIQr4V4QNNxTBz8PeohhbMs nwGShLf26SNWc5YOlaCUTRAejTiNvJKN7LWzBriNo30bUOsqG61SNeurDtZwt4E3hes2 nllcfxhIYrs8ARAXHnIgrcM5qF+QG/f79+xhTvO6qrNH38Go/pePB2/JkA+xFqBHRJWP dz0uXNEijcJJ2RJAbkR5v/cphT4HDE7a2FWeokVlhiX6G2+oHutec7PSModhoOUwddLU PnSQ==
MIME-Version: 1.0
X-Received: by 10.180.187.141 with SMTP id fs13mr34729786wic.26.1432062561044; Tue, 19 May 2015 12:09:21 -0700 (PDT)
Received: by 10.194.20.97 with HTTP; Tue, 19 May 2015 12:09:20 -0700 (PDT)
In-Reply-To: <555B6176.2000906@mit.edu>
References: <x7dk2wd6355.fsf@equal-rites.mit.edu> <555B6176.2000906@mit.edu>
Date: Tue, 19 May 2015 12:09:20 -0700
Message-ID: <CACsn0cm+6JisrBgR0-zbU86_6n_2p8DcWabWA7W1ZnX8=wuhgA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/gAn54ZrTAHz3e4RYHpuncVv2Alk>
Cc: kitten@ietf.org
Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text)
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: Tue, 19 May 2015 19:09:24 -0000

On Tue, May 19, 2015 at 9:14 AM, Greg Hudson <ghudson@mit.edu> wrote:
> Based on the results of this discussion, here is the wording I came up
> with for my pull request.  In the prerequisites section:
>
>    Both KDCs and clients MUST implement one or more groups for which the
>    discrete logarithm problem is hard, each with an corresponding object
>    identifer.  Group object identifiers MUST refer to one of the
>    following:
>
>    o  One of the eight elliptic curves specified in [SEC2] section 2,
>       using the corresponding object identifier from appendix A.2.1.
>
>    o  A group with an unambiguous specification for representing group
>       elements as octet strings, and an unambiguous specification for
>       converting an octet string of a specific length into an integer
>       for use as a scalar multiplier.

My draft does not have M and N for binary curves. There are only three
curves in my draft IIRC. My draft completely describes each parameter,
and gives it a name.

>
> and then in a new section titled "SPAKE Parameters and Conversions":
>
>    The SPAKE algorithm requires a shared secret input w to be used as a
>    scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2).  This value
>    MUST be produced from the client principal's long-term key as
>    follows:
>
>    1.  Determine a scalar octet string input length for the chosen
>        group.  For SEC 2 curves over a prime field F(p), this is
>        ceil(log2(p)/8).  For other groups, this length is specified by
>        the group.
>
>    2.  Produce an octet string of the above length with PRF+(K,
>        "SPAKEsecret"), where K is the long-term key and PRF+ is defined
>        in [RFC6113] section 5.1.
>
>    3.  If the chosen group is secp521r1, set the high seven bits of the
>        first byte to 0 so that there are at most 521 significant bits in
>        the octet string.
>
>    4.  For SEC 2 curves, decode the octet string as a big-endian
>        positive integer as specified in [SEC1] section 2.3.8.  For other
>        groups, decode the octet string as specified by the group.

I feel as though I should rework the draft to specify the length of an
octet string and how to treat it, but I think this was already done
elsewhere. (I.e. step 2 would need to be done, but all others in my
draft)

>
> Salient points:
>
> * SEC 2 curves over Fp (which include NIST P-256/P-384/P-521) get to use
> existing OIDs with conversions specified in this draft, using SEC 1
> encoding primitives.  Other groups need to use an OID which
> unambiguously specifies the needed conversions.  I expect the
> forthcoming CFRG curves to slot in here, although I'm not sure if they
> plan to designate OIDs for their curves.

OIDs are not unique per object.

>
> * Because the eight SEC 2 curves all have cofactor 1, we don't have to
> worry about cofactors in the conversions we specify.  Except for
> secp521r1, they all use primes close to a power of 2^8.
>
> * The w values won't be uniformly distributed even if the long-term key
> is.  But as Watson noted, SPAKE doesn't assume that w is uniformly
> distributed.
>
> * A small proportion of w values will be larger than the group order.
> Implementations need to be able to handle these values correctly and
> without side channels.  I will try to make a note of this in the
> security considerations, and will try to make sure that there are test
> vectors exercising this possibility.  OpenSSL contains P-256 and P-521
> implementations which are supposed to be constant-time if the input
> bignum doesn't contain more than 256 or 521 significant bits respectively.

The easy fix here is to truncate.
>
> * It's possible, though vanishingly unlikely, for w to be equal to 0 or
> to the group order.  I believe all of the computations should work in
> this case, so there is no need to reject those values.