Re: [kitten] Kerberos preauth negotiation techniques

Nico Williams <nico@cryptonector.com> Wed, 18 February 2015 20:43 UTC

Return-Path: <nico@cryptonector.com>
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 210071A1A5B for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 12:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 8n3Rl0O5Z9jg for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 12:43:45 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2E71A1A28 for <kitten@ietf.org>; Wed, 18 Feb 2015 12:43:45 -0800 (PST)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 38B80674070; Wed, 18 Feb 2015 12:43:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=jfzV2cQ+MWwjl8 xqAsQlYVEs+dk=; b=Mo2C3jFB2Y838rOU0h2mnBKHyRKXERHixGckkha7yljBQH PHI9gpI/ahApEIGwoo0lOOsV6O+GAzWewYZUqNKyyodrZKjnBWxn5qNlaKmVk3hP nouMLhHSAMQanJs5o89N843DSaN8uy9HuIrp1cCUHjIfg2jseeq2rRfAupjLw=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id CADFD674059; Wed, 18 Feb 2015 12:43:44 -0800 (PST)
Date: Wed, 18 Feb 2015 14:43:44 -0600
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20150218204339.GR5246@localhost>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54E4F31D.5080103@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/MOJjoasK0NYPt_x5xZEl9MzfxWY>
Cc: kitten@ietf.org
Subject: Re: [kitten] Kerberos preauth negotiation techniques
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: Wed, 18 Feb 2015 20:43:47 -0000

On Wed, Feb 18, 2015 at 03:16:29PM -0500, Greg Hudson wrote:
> On 02/17/2015 11:14 AM, Nathaniel McCallum wrote:
> > 1 and 3 are also compatible workflows. In 3, the first AS-REQ is 
> > exactly the same padata as the second AS-REQ in 1. That is to say, 3 
> > is an optimization of 1 where the first round-trip of 1, which 
> > includes no meaningful data, is simply not used. Put another way, 3 is 
> > just 1 with optimistic preauth.
> 
> That's an interesting way of looking at things.  It means we wouldn't
> have to amend RFC 6113, although we might be bending it a bit.  Here are
> some considerations, which all seem manageable:
> 
> * Traditionally, optimistic preauth is only done with some prior
> knowledge of what the KDC wants (see RFC 6113 section 2.3 paragraph 1).
>  To get down to two round trips in the common case, an AS client  needs
> to do optimistic PA-PAKE by default.

When the client has only one pre-auth it's willing to do then it can be
optimistic.  That doesn't seem terribly likely in many cases, but for
environments where 2fa is used for protecting some resources and not
others, then it could be clear at AS-REQ time that the client only wants
to do 2fa.

Clients can also tell -sometimes- when they have credentials for
PKINIT.  And they can learn and cache -or have configured- whether a
realm's KDCs support FAST for protecting PA-ENC-TIMESTAMP, and so on.
It may not be such a stretch that a client will have just one pre-auth
method that it's willing to use in some cases.

> * Of course PA-PAKE would need to be specified such that the first
> client message requires no knowledge from the KDC.  This is pretty
> simple; the first client message can be defined to contain only
> sub-negotiation parameters.

Yea, we're already there as to this proposal.

> * Most KDC implementations will ignore the client's PA-PAKE padata if
> they don't implement it, and respond with PREAUTH_REQUIRED with
> METHOD-DATA.  Some older KDCs (like MIT krb5 pre-1.7) will instead
> respond with PREAUTH_FAILED.  Clients already need to deal with this
> behavior if they implement RFC 6112 encrypted padata negotiation or any
> similar extension, so this is not really a concern.

Good point.

> * An optimistic PA-PAKE message should be cheap to compute (it's just
> parameters), but is still wasted bytes if the exchange winds up settling
> on a different mechanism or not using preauth at all.  The more
> compactly we can represent client parameters, the less bandwidth we will
> waste and the fewer problems we will have with AS-REQs exceeding UDP
> limitations.

We can greatly "compress" it by using bit sets (which could be
compressed if there are many contiguous zero bits in the bit string).

The trade-off is requiring a registry.  For PAKEs and groups, an OID
would do just fine, or we could use an existing (or upcoming) registry.

A middle of the road proposal would be to use a bit set for registered
PAKEs and groups and an optional set (sequence) of OIDs for all others.

But all this to save a bit of space?  Before we go there we should
determine that this really is a problem we need to address.

> * Can a client optimistically preauthenticate with multiple mechanisms?
>  RFC 6113 doesn't really say either way.  Without going into detail on
> the arguments pro and con:

A separate update to RFC6113 about this would be nice.

>   - If we assume no, then a client which does optimistic PA-PAKE by
> default can't do the same thing with any other mechanism.  This could be
> a reasonable choice; the client implementation could always choose to
> drop back to three round trips for PA-PAKE if it wants to do optimistic
> PA-FUTURE-AWESOME by default in the future.

Well...  See above.  Also, a client could be somewhat abusive and send N
single-preauth AS-REQs concurrently, hoping one of them will succeed.

>   - If we assume yes, then a client which does optimistic PA-PAKE is
> still privileging that mechanism by choosing to spend bandwith on it
> before it is negotiated.  But it wouldn't necessarily have to exclude
> other mechanisms from doing the same thing.

Yes, but hopefully the client knows from context that it will need this
PA method.