Re: [kitten] SPAKE Preauth

Greg Hudson <> Tue, 28 April 2015 15:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11BC51A876D for <>; Tue, 28 Apr 2015 08:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ivpqz48igJHc for <>; Tue, 28 Apr 2015 08:09:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F31A1A878E for <>; Tue, 28 Apr 2015 08:09:43 -0700 (PDT)
X-AuditID: 12074422-f79cb6d000000d7b-23-553fa2b60d65
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 4F.98.03451.6B2AF355; Tue, 28 Apr 2015 11:09:42 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3SF9gPS032675; Tue, 28 Apr 2015 11:09:42 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3SF9eRE025529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2015 11:09:41 -0400
Message-ID: <>
Date: Tue, 28 Apr 2015 11:09:39 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Nathaniel McCallum <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrLttkX2owefL1hZHN69isZj7dRar A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJXx44RiwVKRiks/fRsYDwp0MXJySAiYSEz7 cI0RwhaTuHBvPVsXIxeHkMBiJonjC8+yQDgbGSW+T5jECOEcYZJ48PgJE0gLr4CaxN97M8Ha WQRUJQ70HWYHsdkElCXW79/KAmKLCoRJTPv9nBWiXlDi5MwnYHERgRiJ28u3g8WFgerPvjoF 1iskYChxYO8SsDingJHEwgNzmEFsZgE9iR3Xf7FC2PISzVtnM09gFJiFZOwsJGWzkJQtYGRe xSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERSm7C5KOxh/HlQ6xCjAwajEw2tx 0y5UiDWxrLgy9xCjJAeTkihvX699qBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXqMJQDnelMTK qtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne1wuAGgWLUtNTK9Iyc0oQ0kwc nCDDeYCG9y8EGV5ckJhbnJkOkT/FqCglzisGkhAASWSU5sH1wtLIK0ZxoFeEeR1BqniAKQiu +xXQYCagwZUzbUAGlyQipKQaGKOmLKySVHzAxzldNrBpmf63uUlCi1pkSx84PndsfFi0bP3n 4k1X4pys/5mwKiaEzeHQnXpmYUfl1kBt8wcnBBY89Tg5w2ix47N+t2NrlILe3Nz6+PPPj/bz P5YarFLIdP9+XW5eV/BxmZLrspZiB4JmB5j4LtnCzKNbX5V1a812qZoC99Kv8UosxRmJhlrM RcWJAJLNkEL+AgAA
Archived-At: <>
Subject: Re: [kitten] SPAKE Preauth
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Apr 2015 15:09:55 -0000

On 04/27/2015 08:45 AM, Nathaniel McCallum wrote:
> I have finally finished the first edition of SPAKE Preauth. You can
> read it at this link:

I think this mechanism has a lot of potential, and I hope the kitten
working group will adopt this document.  There is a lot of work to be
done at the detail level, but I think the general shape of the mechanism
is about right.

I think this mechanism addresses three under-served scenarios:

1. A realm administrators are concerned (or ought to be concerned) about
the potential for offline dictionary attacks conducted by an adversary
using passive network surveillance.  The realm is using only passwords
for user authentication and does not have the resources to deploy a
second factor.  Encrypted timestamps are in use but do not protect
against a network listener.

There are several other ways to address this use case, including FAST.
But SPAKE preauth can be deployed more easily than FAST--perhaps even
turned on by default--and does not require as many changes to other
layers to make deployment easier.

2. A realm is using passwords for user authentication, and the
administrators want to add a traditional OTP second factor (like Yubikey
or RSA tokens) for some or all principals.  FAST-OTP is designed to
replace, rather than augment, the use of Kerberos long-term keys, and is
therefore not easy to apply to this situation.

In this use case, SPAKE preauth is used with a second-factor challenge
in the second pass, and the token value is transmitted inside the key
confirmation.  The KDC issues a ticket if key agreement succeeded and
the token value is valid, and responds with an error if either is wrong.
 If there are no side channels, an attacker can't tell which factor was
guessed incorrectly.

3. Same as (2), but the realm administrators want to add a Duo-style
second factor.  In this style, the password needs to be validated first,
and then the user is presented with a choice of options for the second
factor.  Depending on the choice, there may or may not be an OTP value
presented to the KDC for validation.

In this use case, SPAKE preauth is used without a second-factor
challenge in the second pass, but additional challenge/responses occur
after key agreement.  An attacker does get to make on-line guesses at
the password separately from the second factor, but is unable to cause
nuisance second-factor challenges (such as pushes to the user's mobile
device) without knowledge of the password.