Re: [kitten] SPAKE Preauth

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 28 April 2015 21:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 594381A8025 for <>; Tue, 28 Apr 2015 14:53:11 -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 vcSmPTI7CktC for <>; Tue, 28 Apr 2015 14:53:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA1C91A8A0C for <>; Tue, 28 Apr 2015 14:53:05 -0700 (PDT)
X-AuditID: 12074424-f79f56d000000da5-99-55400140c519
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 64.97.03493.04100455; Tue, 28 Apr 2015 17:53:04 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3SLr3uS025994; Tue, 28 Apr 2015 17:53:04 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3SLr15j008030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2015 17:53:03 -0400
Received: (from kaduk@localhost) by ( id t3SLr12w006461; Tue, 28 Apr 2015 17:53:01 -0400 (EDT)
Date: Tue, 28 Apr 2015 17:53:01 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nathaniel McCallum <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrOvA6BBq0Ltaw+Lo5lUsFnO/zmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDJ2TXArmGhRcfjmebYGxlO6XYycHBICJhKb rq9mh7DFJC7cW88GYgsJLGaS+PXVo4uRC8jeyChx59BJFgjnEJPElK8rmSGcBkaJxR8ms4C0 sAhoS8yfOYEVxGYTUJGY+WYj2CgRAT2JZfsmMILYzALqEt/OvAGzhQWUJc6+OgW2mhMofnjn FDCbV8BRYtXzU8wQZ/hILFz5DmyOqICOxOr9U1ggagQlTs58wgIxU0ti+fRtLBMYBWchSc1C klrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjKFDZXVR2MDYfUjrEKMDB qMTDa3HTLlSINbGsuDL3EKMkB5OSKK8tg0OoEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe6+P2 oUK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8KiBDBYtS01Mr0jJz ShDSTBycIMN5gIaf+w8yvLggMbc4Mx0if4pRUUqc9zNIQgAkkVGaB9cLSySvGMWBXhHm1QZZ wQNMQnDdr4AGMwENrpxpAzK4JBEhJdXAaHqD5aj3vdzPm87+mGfUGL/GtHSiQ17816WmG2/N mdrao7BF1es6f1GqrKqbMec6z475zvt55jq8mndCWHGHSfuWcu0bK5K5vIU2TLuv0/hu25UT BU8LJll6ad4Pf1rx6v6fD+b6a4/c3TrpedND4/PHbP6se25tl5PuMPWfJFOYH4u/x/HZ25VY ijMSDbWYi4oTAcWMAPr/AgAA
Archived-At: <>
Cc: "" <>
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 21:53:11 -0000

On Tue, 28 Apr 2015, Greg Hudson wrote:

> 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 agree with this assessment, and hope that the document will move forward
through the working group.

> 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.

I think this point could be emphasized in section 1 -- the current text is
only "offline brute-force attack against the transferred packet", saying
nothing about passwords, let alone weak passwords.

> 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.

"can't tell which factor was guessed incorrectly" seems like a pretty
important property (I would be really excited to see a scheme with this
property get deployed!), but it does not seem to be mentioned in the
current section 1.2 text.  (It does talk about avoiding
ciphertexts^Wpackets which are vulnerable to offline brute-force attack,
but I don't see anything mentioning the online attack as well.)  Hmm, this
is mentioned in the security considerations, at least.  I think it should
be more prominent earlier in the document.

However, it seems like the text at the end of section 4.3 wherein "[i]f
validation of the second factor requires furthe round-trips, the KDC MUST
reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" loses
the indistinguishability property, as the encrypted SPAKESecondFactor
would not be generated if the long-term key (password) was incorrect.
This seems inherent to second factors which require multiple round trips
to validate, though, so maybe we have to make a choice of the tradeoff.

[case 3 trimmed]

Some additional comments:

The current version of 4.3 only allows for one second factor to be used.
Do we want to consider a design which permits multiple additional factors
to be used (maybe, phone and hardware token, or something like that)?

We talked about SPAKE on the MIT kerberos dev call today, and one of the
things mentioned is that the M and N values are specified per group in
draft-irtf-cfrg-spake2 (along with a procedure for selecting them for new
groups); we should explicitly note that their selection (and encoding?) is
delegated to the IRTF document.

Also covered on the MIT dev call, we should go into more detail about the
transcript hash (in a separate subsection?).  Apparently there is also a
discussion to have about the way the transcript includes the full exchange
of messages, i.e., whether it is okay to chain hashes or the full history
must be buffered.

With respect to the recommended groups in section 7, I believe that
interoperability concerns should drive us to pick at least one mandatory
to implement group.  The state of things elsewhere in the IETF and IRTF
seem to be leaning towards non-NIST curves as well; we should probably
consider if the CFRG curve recommendations to the TLS working group are
relevant for this case.

The IANA considerations are not considered complete by current standards;
see BCP 26 (i.e., RFC 5226 at present).  In particular, section 4.2
contains the list of what needs to be in a document which creates a


In 1.2, "attempting to encrypt this data using the long-term password"
implicitly assumes "using authenticated encryption (such as RFC 3961
crypto)", as I understand it.

1.2, second paragraph, first line, comma after "FAST".

Still 1.2, it's "certification authority", not "certificate authority".

Last sentence of 1.2, is "leveraged into" really correct?  I thought that
the long-term key and the 2FA data were mixed into the DHE in the same

In 1.3, first paragraph, penultemate sentence, "indistinguishable from
random" seems like an incomplete clause; maybe "random data" or "random

1.3, second paragraph, antepenultimate sentence, in "equivalent security",
as a reader I expect to see what it is equivalent to, i.e., "equivalent
security using standard DH-KE".

In 3.1, I think the text would read more naturally if consolidated into a
single sentence, viz. "a PA-ETYPE-INFO2 element with a single
ETYPE-INFO2-ENTRY containing the etype [...]".

Perhaps 3.3 should cite RFC 6113 for KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.

There are several places where the document indicates only the fields in
KDC-RE{Q,P}s which are specific to SPAKE, with no reference to the other
fields which will be included indicating support for other preauth
schemes, etc..  While this can be a valid style to use, I wonder if some
consideration should be given to some additional text about "in the set of
pre-authentication data in the KRB_ERROR message" for section 4.1, and
similarly elsewhere in the document.

Section 4.3 should forward-reference section 5.1 for key derivation.

In section 4.3, second paragraph, us a comma instead of a semicolon to
prefix "possibly using the challenge data for this second factor type",
since that is a dependent clause.

We should probably be a little more explicit about what key, usage, etc.
are going on for the EncryptedData encrypted/checksummed with the session
key derived from the SPAKE key; we covered this a little bit on the MIT
dev call today as well.

In 4.4, "second factor type specific" is a bit awkward; maybe "specific to
each type of second factor"?

In section 8, the integrity confirmation of the transcript messages occurs
when the SPAKEResponse is processed and validated, not when it is
transmitted, I think -- the KDC is the second party to compute the
transcript/key derivation, and the verification that the two parties'
transcripts agree occurs when the KDC compares its local copy to the one
it got from the network.