Re: [kitten] Kerberos preauth negotiation techniques

Nathaniel McCallum <npmccallum@redhat.com> Mon, 23 February 2015 21:40 UTC

Return-Path: <npmccallum@redhat.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 29B481A6F10 for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.911
X-Spam-Level:
X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 l1m000JVSpL3 for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:40:27 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EB71A3B9C for <kitten@ietf.org>; Mon, 23 Feb 2015 13:40:27 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLeQPP010872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Feb 2015 16:40:27 -0500
Received: from vpn-59-5.rdu2.redhat.com (vpn-59-5.rdu2.redhat.com [10.10.59.5]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1NLePiG004084 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Feb 2015 16:40:26 -0500
Message-ID: <1424727625.2604.84.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Date: Mon, 23 Feb 2015 16:40:25 -0500
In-Reply-To: <54EB9A91.6040007@mit.edu>
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> <54EB9A91.6040007@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/vE5F7zvJ3VTL_11JkcOWw7aqf1c>
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:40:30 -0000

On Mon, 2015-02-23 at 16:24 -0500, Greg Hudson wrote:
> 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.


Thanks for all the clarifications! I agree with all of them.