Re: [kitten] SPAKE Preauth

Greg Hudson <> Mon, 04 May 2015 15:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0AB421A7022 for <>; Mon, 4 May 2015 08:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B7GfL79WgLxw for <>; Mon, 4 May 2015 08:31:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7408A1A1B9A for <>; Mon, 4 May 2015 08:31:23 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-68-554790c95105
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 B1.2F.03355.AC097455; Mon, 4 May 2015 11:31:22 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t44FVLr4027634; Mon, 4 May 2015 11:31:21 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t44FVJf8025905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 May 2015 11:31:20 -0400
Message-ID: <>
Date: Mon, 04 May 2015 11:31:19 -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: Ken Hornstein <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrHtqgnuowbF3nBb9TcdZLI5uXsXi wOSxZMlPJo+Ll5QDmKK4bFJSczLLUov07RK4Mn71vmQreMBXsb8proHxI3cXIyeHhICJxMQ7 M9khbDGJC/fWs3UxcnEICSxmktjyYAIrhLOBUWJN/2dWkCohgQNMEh/n8YHYvAIqEj3vVzGC 2CwCqhIzLt0Es9kElCXW79/KAmKLCoRJTPv9nBWiXlDi5MwnQHEODhEBY4nfc8HGCAOVn311 ih1ivJXE1IUXwVo5Bawl9k/eCWYzC+hJ7Lj+ixXClpdo3jqbeQKjwCwkU2chKZuFpGwBI/Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M4BCV5NvB+PWg0iFGAQ5GJR7eE6vc QoVYE8uKK3MPMUpyMCmJ8lqkuIcK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHlaAHK8aYkVlal FuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8Nr3ATUKFqWmp1akZeaUIKSZODhB hvMADZ/eDzK8uCAxtzgzHSJ/ilFRSpzXDyQhAJLIKM2D64WlkFeM4kCvCPMeA6niAaYfuO5X QIOZgAYfqHcBGVySiJCSamAUOsg8h6F6nXVD/92/DTqmjNLvjs6a+MBkm/P5sz/f9S725p8k 3HHo/7EcywlsLxnsypo+T3hw96L/a981UTuWLA3+Gsl1dX3+78safT/+9HPs13DpFhXd9NPG 7ccVxyCPD5t9bhocOrIiNlNLU8rqj+/bSNvILcLOssGfBC5q106Wls9ayXFXiaU4I9FQi7mo OBEAz186JvwCAAA=
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: Mon, 04 May 2015 15:31:26 -0000

On 05/04/2015 10:40 AM, Ken Hornstein wrote:
>> Essentially, the answer is different whether OTP is supposed to be the
>> first (and only) authentication factor, or a second factor to be used in
>> conjunction with a password.

> See, I think you've got the question all wrong.  My question is NOT,
> "Is OTP supposed to be the only authentication factor?", it's, "Which
> protocol is it actually possible for me to deploy successfully?"

Deployability is a big motivator for SPAKE preauth.

I wasn't involved in the early stages of FAST OTP, but I believe it was
primarily trying to solve the problem of bridging between an OTP master
authentication server and the Kerberos protocol.  In a deployment where
the KDC has no user-specific shared secrets with the client, there needs
to be some way of establishing a confidential, server-authenticated
channel from the client to the KDC, so that the client can send the
PIN+OTP value to the KDC for verification against the OTP back end.
FAST allows that channel to be created using either a host keytab or an
X.509 KDC certificate (using anonymous PKINIT).

The big challenges of deploying FAST OTP as I see it are threefold:

* It is designed to replace rather than augment Kerberos long-term keys.

* At least in MIT krb5, we haven't added enough FAST support to the
upper layers of the get-init-creds stack to make it easy to deploy.

* Unless you can assume host keytabs on all of the clients, there's no
good way around the requirement to put an X.509 certificate on the KDC
and configuring all of the clients to trust its CA.

SPAKE preauth doesn't have these problems, but it does require you to
start with traditional Kerberos back-end database containing
string2key'd user passwords.  If you don't have that, and instead have
an OTP server with PINs, then FAST OTP may still be a better answer.