Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input

Watson Ladd <watsonbladd@gmail.com> Thu, 14 May 2015 15:54 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 330B91A872C for <kitten@ietfa.amsl.com>; Thu, 14 May 2015 08:54:42 -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 DCVgxUkqAXEX for <kitten@ietfa.amsl.com>; Thu, 14 May 2015 08:54:40 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 75D611A872D for <kitten@ietf.org>; Thu, 14 May 2015 08:54:40 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so22393642wic.0 for <kitten@ietf.org>; Thu, 14 May 2015 08:54:39 -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=u2V/g5rGZ/km+bUout26ywD2OlLjoaABF30Ozkzh9sI=; b=WNiJZ3PzWJHCYJmFKCuVR4yCmbsk+SwyQ6PnhszQK+lH/sgur7xZu06YUel6ZSxmxe P3q+fT9mVsj3rTMYbEyLmXps6mc4AgUb702UCxrsPt0a93If0sLVrviSj68ZJDC8eRuN wFqgBz1r3Y2he5oSZibfhORFnVhIyR0OWpGY900ejWuOgZe3QCxhxTNc4OboFkitjdSZ OWEBtBa+ABEQWNuAwkCTDERbGUZkSjJqSn36s+jvKv3fxlKTVW1DxQSd0Z6Qy3EVWBFe +cPq/yfK4YfEt3hj3kjhMxG7T/znEMsiM3ww9uOpb7iNc3QdbE5/v8xVfmQso0B2KfnG E0kw==
MIME-Version: 1.0
X-Received: by 10.194.123.4 with SMTP id lw4mr780000wjb.94.1431618879193; Thu, 14 May 2015 08:54:39 -0700 (PDT)
Received: by 10.194.20.97 with HTTP; Thu, 14 May 2015 08:54:39 -0700 (PDT)
In-Reply-To: <alpine.GSO.1.10.1505141027470.22210@multics.mit.edu>
References: <x7dk2wd6355.fsf@equal-rites.mit.edu> <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <CACsn0cm9AEG+oi8S+trhvyHpFFLF=-tG4Qazp5e6SgnS037K+Q@mail.gmail.com> <20150513160549.GV7287@localhost> <CACsn0cnO0To1a77x0Tp+Qk414Zv_yqnoC-wuS4vgJbQN+mV+7Q@mail.gmail.com> <alpine.GSO.1.10.1505140017320.22210@multics.mit.edu> <alpine.GSO.1.10.1505141027470.22210@multics.mit.edu>
Date: Thu, 14 May 2015 08:54:39 -0700
Message-ID: <CACsn0ckNMva3JU=6pi0CX7KUh-3bqpvSr_Zpx2XLvxVsUL3b_Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/PayXVFVuOrfTzBpFGkEk_1yf2Ww>
Cc: kitten@ietf.org
Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input
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: Thu, 14 May 2015 15:54:42 -0000

On Thu, May 14, 2015 at 7:39 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Thu, 14 May 2015, Benjamin Kaduk wrote:
>
>> On Thu, 14 May 2015, Watson Ladd wrote:
>>
>> > On May 13, 2015 9:05 AM, "Nico Williams" <nico@cryptonector.com> wrote:
>> > >
>> > >
>> > > That depends on how its salted.  For our purposes, in practice it's not.
>> >
>> > Not true: w comes from a much smaller list of values. If it was
>> > uniformly distributed over a wide range, we could use it as a key
>> > directly.
>>
>> In the scheme kitten is considering, w is an existing kerberos long-term
>> (password-derived) key, so at least 128 bits and with no clear structure.
>
> Now that I am awake (i.e., not falling asleep), I should clarify that w is
> planned to be the output of a KDF or PRF construction keyed on the
> kerberos long-term key I mentioned, not the key itself.  (I don't think
> this was very clear in the -00, though, and we discussed it on the list a
> fair amount.)
>
> To give something of a summary of the propsal with background from
> kerberos:
>
> In kerberos, we have password-derived keys that are used for initial user
> authentication; the KDC ends up sending a response with session key,
> encrypted in the long-term password-derived key.  (Sometimes the user
> sends a timestamp encrypted in that key as "pre-authentication".)
> Regardless, an attacker can easily get a ciphertext in this
> password-derived key, and since some users will always pick weak
> passwords, some of this traffic will succumb to a brute-force guessing
> attack.

Yes, which implies that it is not uniformly distributed over the whole
domain of strings of the length of w. Uniform distribution means
uniform: if it only ever takes on values in some subset, it isn't
uniform. The fact that guessing attacks are possible demonstrates,
that after conditioning on public values, it isn't uniform over the
entire range.

>
> The proposal in draft-mccallum-kitten-krb-spake-preauth is to use SPAKE(2)
> as a zero-knowledge proof, not of the password itself, but rather of the
> password-derived kerberos key, so that existing kerberos deployments can
> seamlessly be upgraded to use this new preauthentication scheme which does
> not expose ciphertexts in the password-derived key to an attacker.  As an
> additional feature, it allows for a second factor to be included in the
> key exchange in a fashion such that an attacker trying online guessing
> cannot tell which of the password or second factor was incorrect.  So, the
> "password" input to spake is not the user's actual password, but rather
> this kerberos long-term password-derived key, which has already been
> through a salted PBKDF2 (or similar, for older enctypes).  As is normal
> for use of long-term kerberos keys, it will go through a key-derivation
> step before being used.
>
> Hopefully that gives some background to the questions we were asking for
> input on.
>
> -Ben



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.