Re: [kitten] SPAKE Preauth

Greg Hudson <ghudson@mit.edu> Thu, 30 April 2015 16:08 UTC

Return-Path: <ghudson@mit.edu>
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 A4BEA1B2D3A for <kitten@ietfa.amsl.com>; Thu, 30 Apr 2015 09:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRwEOIZZ6-NQ for <kitten@ietfa.amsl.com>; Thu, 30 Apr 2015 09:07:59 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C641A88C6 for <kitten@ietf.org>; Thu, 30 Apr 2015 09:07:59 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-de-5542535e08cb
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FA.D2.03355.E5352455; Thu, 30 Apr 2015 12:07:58 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t3UG7vEO015498; Thu, 30 Apr 2015 12:07:58 -0400
Received: from [18.101.8.227] (vpn-18-101-8-227.mit.edu [18.101.8.227]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3UG7sHg012783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 12:07:56 -0400
Message-ID: <5542535A.4090804@mit.edu>
Date: Thu, 30 Apr 2015 12:07:54 -0400
From: Greg Hudson <ghudson@mit.edu>
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 <npmccallum@redhat.com>, Nico Williams <nico@cryptonector.com>
References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> <1430401789.5004.21.camel@redhat.com>
In-Reply-To: <1430401789.5004.21.camel@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT0Y0Ldgo1ONOoZXF08yoWi1PXjrBZ zP06i9WB2ePlqXOMHkuW/GTyeL/vKlsAcxSXTUpqTmZZapG+XQJXRlfjccaC96oVj99dZW5g 3CDXxcjBISFgIrH6amwXIyeQKSZx4d56ti5GLg4hgcVMEr+2f2UDSQgJbGSUuHKrAiJxhEli 94IDLCAJXgE1iT9r/7OC2CwCqhLr3q1gBrHZBJQl1u/fClYjKhAmMe33c1aIekGJkzOfgMVF BOIkHly9xwZyBLOAusTO3WCtwkCtZ1+dYofYWymxY/lGJhCbU8BIYseJ22BjmAX0JHZc/wVl y0s0b53NPIFRcBaSDbOQlM1CUraAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK 6SZGUEBzSvLtYPx6UOkQowAHoxIP74d2x1Ah1sSy4srcQ4ySHExKorw+gU6hQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4zRyBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIy HBxKEryZIEMFi1LTUyvSMnNKENJMHJwgw3mAhn8EqeEtLkjMLc5Mh8ifYlSUEuddBJIQAElk lObB9cISzitGcaBXhHnFgoCqeIDJCq77FdBgJqDB5285gAwuSURISTUwmpw82fVa4NP7+80b M9kfeWkuctxq0e1Ze2riJTnFl1O++n+RY40Rm8u6uON55EzHOwqfa168TJrxYJs9o+ePpu/t yyRXFTBVOtw+LrRPNGznnU9PJ+20KDp/q1nH6XNd0e/AJM4Y+6Lu3kVCZwuZMnhinU6uqrTy ME7O9bQ0sg7/31SeKdWvxFKckWioxVxUnAgA3NG1bBMDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/CSXJ9jwq3MF8TOI8ZVu4VrZBaE4>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] SPAKE Preauth
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, 30 Apr 2015 16:08:02 -0000

On 04/30/2015 09:49 AM, Nathaniel McCallum wrote:
>>    Pre-auth methods that don't depend on the client's clock are 
>> mostly
>>    an optimization.  They are less of an optimization when failures
>>    count towards locking a principal, but still an optimization 
>> (since
>>    one can account for clock skew by adding one to N-strikes-you're- 
>>    locked policies).
> 
> As I stated in the draft: "where a timestamp is used, time
> synchronization between the client and KDC becomes a point of
> fragility." I think your paragraph here proves this point. Where
> synchronization is off, extra messages are sent. I think this
> qualifies as fragility.

Hm, I would give a more nuanced description:

In a normal scenario, the client can get the KDC's timestamp from the
PREAUTH_REQUIRED error.  This timestamp is unauthenticated, so using it
pretty much defeats any freshness value the timestamp might add to the
preauthentication protocol.  Since there isn't much freshness value in
that timestamp (an active or passive attacker immediately gets a
ciphertext with which to conduct offline password dictionary attacks,
rendering password lockout moot), the MIT krb5 client does use that
timestamp for encrypted preauth, and no extra messages are sent even if
the client's clock is off.

When authenticating with a keytab, a client might choose to use
optimistic encrypted timestamp preauth to indicate which key the client
possesses.  (The MIT krb5 client does not do this, and the MIT krb5 KDC
does not use the result for key selection.  The latter should definitely
change and the former might change.)  If this is done, clock skew could
force a second exchange.

I also thought it was weird to lead with timestamp issues in the draft.
 I'm not sure I would mention them all in section 1.

>>  - Section 1.2, the claim about why FAST is difficult to deploy 
>> requires
>>    more evidence, and I believe it's wrong.  The problem with FAST is
>>    that it's difficult to make it a requirement for PA-ENC-TIMESTAMP
>>    because FAST is not universally available yet -- the tragedy of
>>    legacy forever.  Sure, one has to deploy trust anchors, but then
>>    again, one doesn't have to (leap of faith), and one can (for 
>> machines
>>    that have "joined" a realm or hierarchy of realms).

This is partly true.  Unauthenticated anonymous PKINIT plus encrypted
challenge would carry some of the advantages of SPAKE preauth.  But
there are a lot of missing pieces for clients without keytabs:

* The MIT krb5 client only supports KDC-authenticated anonymous PKINIT
at this time.  That could change, but it would carry risks by
complicating the client security model (e.g. we need to make sure not to
do FAST OTP over the resulting channel).

* The get_in_tkt stack would need to be augmented to try anonymous
PKINIT FAST automatically.  At the moment the user (or other external
machinery) has to manually obtain anonymous tickets and then use those
as armor.

* Administrators have to turn on anonymous PKINIT; it's not on by
default.  To turn it on you have to generate a KDC certificate, even if
the client won't verify it.

* Anonymous PKINIT in MIT krb5 is slow right now because it only
supports integer DH.  It also increases the attack surface on the KDC
significantly, because PKINIT is so complicated.

Other implementations are in different states (e.g. Heimdal has
supported ECDH PKINIT for many years), but I think have most of the same
those missing pieces and some additional ones as well.

SPAKE preauth doesn't currently exist, which is also a big missing
piece.  The advantages are that:

1. It's just a preauth mech.  It provides all of its advantages without
requiring any difficult changes to other parts of the stack.  (It does
require some non-difficult changes discussed in RFC 6113: supplying a
single ETYPE-INFO2 value, cookie support within the KDC preauth
framework, and MORE_PREAUTH_DATA_NEEDED support in the client and KDC.)
 If it performs well enough, it could become available and used by
default, supplanting encrypted timestamp.

2. It supports second factor features which aren't currently supported
by any standard.

> I do think this document needs to justify why we just shouldn't use
> FAST like how RFC 6560 does. This draft represents a departure from
> the recently established precedent of second factors. The reason why
> this departure is necessary is because of the above reasons.

Agreed.  RFC 6113 states that "Mechanism designers should design FAST
factors, instead of new pre-authentication mechanisms outside of FAST."
 We are going against that advice, and need to justify why.

(Of course nothing prevents SPAKE from being used as a FAST factor, and
it builds on RFC 6113 features.)