Re: [kitten] Kerberos preauth negotiation techniques

Greg Hudson <> Mon, 23 February 2015 21:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 421131A6F01 for <>; Mon, 23 Feb 2015 13:24:40 -0800 (PST)
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 LdE7l0_6xgIj for <>; Mon, 23 Feb 2015 13:24:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F2D771A6F0E for <>; Mon, 23 Feb 2015 13:24:37 -0800 (PST)
X-AuditID: 12074422-f79d16d0000024cf-97-54eb9a953e41
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 D4.1B.09423.59A9BE45; Mon, 23 Feb 2015 16:24:37 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1NLOark022166; Mon, 23 Feb 2015 16:24:36 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (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: <>
Date: Mon, 23 Feb 2015 16:24:33 -0500
From: Greg Hudson <>
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 <>, Nico Williams <>
References: <> <> <> <20150218204339.GR5246@localhost> <>
In-Reply-To: <>
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: <>
Subject: Re: [kitten] Kerberos preauth negotiation techniques
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, 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
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.