Re: [kitten] SPAKE Preauth

Ken Hornstein <> Mon, 04 May 2015 15:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C3D91A8725 for <>; Mon, 4 May 2015 08:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OQO2_zqJsQUj for <>; Mon, 4 May 2015 08:53:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF1B61A1ACA for <>; Mon, 4 May 2015 08:53:40 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id B64174D682 for <>; Mon, 4 May 2015 11:53:38 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from:to :subject:in-reply-to:mime-version:content-type:date:message-id; s=sasl; bh=HvTmZawSvzEcqKQaLJte4mRA9Fs=; b=v6hTeGO0WdI1EuaGfOW4 SsxTR6XCCB7Lrl9w2XQ3725seMtUGtKpumE6MtmA/2q+StTfYhyQ6LUp4SRwzU/H Z8/9rlG2ja8i3dwkH7I8hH11HqxdSDxkPXiMVLmN0Tp7H8XqNLu15heLE9wFPm21 yrDmv9CUBNdasBM5lnAz9J4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from:to:subject :in-reply-to:mime-version:content-type:date:message-id; q=dns; s=sasl; b=X+XMqS24P9c0PoYhQ10RbbKuQPkJhT86difxVQVr0P5jy+aMVbg/m R0JB8LJ1xYHjOgvrBjpWQlC3bMrAWaHivjiqzLWcZXpccJtn3b5+BYNB3WLA+qwa aP5MGFgFdbbuiaH9imVzJ1u6Ns5yWjG544J75ykqKDxqCGH4tA8u4U=
Received: from (unknown []) by (Postfix) with ESMTP id AF0894D67D for <>; Mon, 4 May 2015 11:53:38 -0400 (EDT)
Received: from (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D8C334D67C for <>; Mon, 4 May 2015 11:53:37 -0400 (EDT)
From: Ken Hornstein <>
In-Reply-To: <>
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 04 May 2015 11:54:32 -0400
X-Pobox-Relay-ID: BA53FD00-F275-11E4-BC7E-83E09F42C9D4-90216062!
Message-Id: <>
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:53:42 -0000

>> 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?"
>I believe the tension you are seeing here is the result of
>commoditization of 2FA. Early on, 2FA systems were entirely parallel
>authentication stacks which authenticators would need to integrate
>with. As 2FA commoditized, we see open protocols which can be
>integrated into existing authentication stacks.

Well ... I understand why you'd say that, but I disagree.

We use the old, old SAM protocol with what you call a pre-commiditized
2FA system today.  So I was thinking of migrating that to FAST as part
of our long-overdue Kerberos upgrade.  But I hadn't really sat down and
understood FAST (I did try to start reading the RFC several times, but
man, it's pretty dense ... I mean, yeah, I understand it's a protocol
document so that's just a necessity, but if you want a broad overview
it's a tough read).  So now you spelled out, "Hey, you need ANOTHER key
to create the FAST channel" ... and that's really a non-starter for
our environment, because those keys don't exist for our users that
most need 2FA (and see previous discussion about the problems of requiring
anonymous pkinit).

>However, after 2FA commoditized the question becomes how can I augment
>my existing authentication stack (1FA Kerberos) with a 2FA method.
>This is what SPAKE Preauth provides.

Well ... again, I don't think that's really the "true" question that
gets asked.  I mean, the people who are pushing the use of 2FA are
generally not qualified to talk about Kerberos at a protocol level.
Really, the question is, "Are you using 2FA with Kerberos?".  Well,
actually, I doubt that the word "Kerberos" appears anywhere.  It's more
like there's a STIG or checklist somewhere that says, "2FA is required",
or maybe, "2FA is required when passwords are used".  As long as we
can legitimately assert that 2FA is in use, that's really all we care
about at a fundamental level; if it's "2FA + Kerberos password", that is
totally fine (that's what we have today).  Yes, I _personally_ care that
the crypto is the best that we can possibly do, but having something
that is deployable is more important.

>Now, I think your questions here raise an interesting point: can and
>should we require some standardization to use the 2FA feature of SPAKE
>preauth? I think the answer is no. And I've come to think that the
>SPAKESecondFactor type field should really be OBJECT IDENTIFIER.

I do not quite understand your point ... are you saying that your I-D
should completely specify how all 2FA systems work with SPAKE?  And
personally I'd vote to keeping SPAKESecondFactor an Int32 rather than
an OID.