Re: [kitten] Kerberos preauth negotiation techniques

Greg Hudson <ghudson@mit.edu> Mon, 23 February 2015 21:24 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 421131A6F01 for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:24:40 -0800 (PST)
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 LdE7l0_6xgIj for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:24:38 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id F2D771A6F0E for <kitten@ietf.org>; Mon, 23 Feb 2015 13:24:37 -0800 (PST)
X-AuditID: 12074422-f79d16d0000024cf-97-54eb9a953e41
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id D4.1B.09423.59A9BE45; Mon, 23 Feb 2015 16:24:37 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t1NLOark022166; Mon, 23 Feb 2015 16:24:36 -0500
Received: from [18.101.8.182] (vpn-18-101-8-182.mit.edu [18.101.8.182]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t1NLOXUf022273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Feb 2015 16:24:35 -0500
Message-ID: <54EB9A91.6040007@mit.edu>
Date: Mon, 23 Feb 2015 16:24:33 -0500
From: Greg Hudson <ghudson@mit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nathaniel McCallum <npmccallum@redhat.com>, Nico Williams <nico@cryptonector.com>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com>
In-Reply-To: <1424722422.2604.77.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT150663WIwf07QhZHN69isTh17Qib xdyvs1gdmD1enjrH6LFkyU8mj/f7rrIFMEdx2aSk5mSWpRbp2yVwZZx+OJW5YL5AxYOl85gb GD/wdDFyckgImEicWbaBCcIWk7hwbz1bFyMXh5DAYiaJxZv+MkE4GxklVux5yg7hHGGSmNm4 hhGkhVdATWLbs30sIDaLgKrEmcMnwGw2AWWJ9fu3gtmiAmES3zfvYIaoF5Q4OfMJWFxEIE7i wdV7bCA2s4CwxIXte1lBbGEBW4nJt78zQyzbwyhx9f1LsPs4BYwkth44AdWgLvFn3iVmCFte onnrbOYJjIKzkOyYhaRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3 MYID20VpB+PPg0qHGAU4GJV4eA2KXoUIsSaWFVfmHmKU5GBSEuU9Pvl1iBBfUn5KZUZicUZ8 UWlOavEhRgkOZiURXrF6oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgTvuxlAjYJFqempFWmZOSUIaSYOTpDhPEDDP4PU8BYXJOYWZ6ZD5E8xKkqJ8x4FSQiAJDJK 8+B6YYnnFaM40CvCvB4zgap4gEkLrvsV0GAmoMF7Hr8CGVySiJCSamC0SYyuOiz0uMrxiiVn W59Tka+ItqPAqZ8dkv93BYgtSpp47lhea6Xt7m/i9gn7/kx54PLw+ZLmqTyX+x51Kl/ynhDb Kjvht3eK0TazLpk+l/U5W+/+rJU9vbhZyDZX+p1TspvUjk/5j1eGeizb9Jdlo8TuwxMU5h+e ot81x319/jqdCVOZLSYrsRRnJBpqMRcVJwIAVbkHNBcDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/8vf8z1RvBtR5ElT6g9ISRT88w5I>
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: Mon, 23 Feb 2015 21:24:40 -0000

On 02/23/2015 03:13 PM, Nathaniel McCallum wrote:
> On the call last week there was a general consensus

Just to be clear on process, the call Nathaniel refers to here was not
an IETF conference call as described in
https://www.ietf.org/iesg/statement/interim-meetings.html
and did not establish a working group consensus.

> We also had a general consensus that there is no need to negotiate 
> hashes. There are three hash uses:
> 1. Transcript for message integrity
> 2. Key derivation
> 3. Key validation
> 
> For #1, we can just use the checksum method implicit in the enctype.

The idea here (as I remember it) is to make an RFC 3961 keyed checksum,
at each step of the exchange, over the padata message and the previous
checksum, using the original client long-term key as the checksum key.
The final checksum is included in the derivation of the reply key.

> For #2, we can just use a KDF.

Specifically (as I remember it), we can do PRF+ (from either RFC 6112 or
RFC 4402bis), using the original client long-term key and a text input
containing the final transcript checksum, the point negotiated by the
PAKE algorithm, and the client and server principals.  The PRF+ output
can then be fed to the RFC 3961 random-to-key operation to produce the
reply key.

> For #3, Greg had an idea, but I've since forgotten it and can't find 
> it in my email. Greg, perhaps you can remind me?

I believe #3 refers to the client's proof of reply key possession at the
end of the PAKE exchange.  My idea was just to encrypt an empty string
if we don't have a second factor value to send.  (Alternatively we could
encrypt a timestamp; that should not really be necessary, as the KDC
cookie should be protected with a timestamp.)

> We also discussed making group negotiation have a note in the RFC 
> about being careful regarding the number of groups exposed. I suspect 
> sensible defaults will be:
> * P-256
> * P-384
> * P-521
> * Curve25519

I would prefer an even more limited offering, but this decision can wait
until later.