Re: [kitten] Kerberos preauth negotiation techniques

Simo Sorce <simo@redhat.com> Wed, 18 February 2015 14:03 UTC

Return-Path: <simo@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 40EBE1A890F for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 06:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5VgjSBpDb5ux for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 06:03:38 -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 DB2631A87E6 for <kitten@ietf.org>; Wed, 18 Feb 2015 06:03:38 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IE3b4n014826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:03:38 -0500
Received: from [10.3.113.54] (ovpn-113-54.phx2.redhat.com [10.3.113.54]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IE3bHb019541; Wed, 18 Feb 2015 09:03:37 -0500
Message-ID: <1424268216.6980.1.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Date: Wed, 18 Feb 2015 09:03:36 -0500
In-Reply-To: <1424209200.2645.54.camel@redhat.com>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com> <20150217195815.GJ5246@localhost> <1424209200.2645.54.camel@redhat.com>
Organization: Red Hat, Inc.
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.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/SYpIqlxbbdZQF4tE9crSW4wIlO0>
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 14:03:41 -0000

On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote:
> On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote:
> > On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum wrote:
> > > On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote:
> > > > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum 
> > > > wrote:
> > > > > I see 1 and 3 as the only good options. Having to register 
> > > > > group parameters instead of using OIDs is a deal-breaker in my 
> > > > > book.
> > > > 
> > > > I also prefer not to have to add registration of groups.  I'm 
> > > > not sure that I want to have any support for negotiable group 
> > > > parameters though, if that's what you meant.  I'd rather have 
> > > > well-known curves (groups) suitable for discrete codepoint 
> > > > assignments regardless of whether we have/need a registry.
> > > 
> > > That was not what I meant. I meant parameters of the exchange. 
> > > Current parameters are:
> > > * PAKE method (currently: SPAKE and JPAKE; needs registration)
> > > * Group (currently: only standardized elliptic curve groups)
> > > * Hash (currently: MD5, SHA1, SHA2-*)
> > 
> > [I covered that elsewhere.]  Assuming these are all orthogonal (they 
> > should be), then pseudo-enctypes work, but need a registry.  OIDs 
> > are much better (though larger) because we can then outsource the 
> > registry to CFRG and friends.
> 
> In the current code, the actual key is generated by a hash of:
> 1. the shared EC point: K
> 2. the client principal
I wonder ^^^ if this is problematic when canonicalization is requested ?

Simo.

> 3. the server principal
> 4. all padata sent or received
> 
> Currently, we do not truncate hashes to fit key size. So the hash 
> output must exactly match the expected size of the key. This is the 
> reason MD5 is enabled (to support 128bit keys). This is not a long 
> term plan. However, we should not allow, for instance, SHA1 to be used 
> to generate a 256bit key.
> 
> Given the above, hashes are supported per etype.
> 
> I currently do something similar for the groups. An elliptic curve 
> group can only be used for an etype if its field size is >=1.75x the 
> key size. For example, P-224 can be used for generating 128bit keys, 
> but not for 256bit keys.
> 
> Given the above, groups are supported per etype.
> 
> > > Currently, I advertise these as:
> > > 
> > > PAKEInfo ::= SEQUENCE {
> > >     ptypes SEQUENCE (SIZE(1..MAX)) OF Int32,
> > >     supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport,
> > >     ...
> > > }
> > > 
> > > PAKESupport ::= SEQUENCE {
> > >     etype Int32,
> > >     groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER,
> > >     hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER,
> > >     ...
> > > }
> > 
> > Why is etype not a sequence?
> 
> Because this contains the lists of supported groups and hashes for 
> that specific etype.
> 
> > > The drawback to this approach is that groups or hashes supported 
> > > by multiple enctypes get listed multiple times. However, this also 
> > > captures that some groups/hashes are only usable for some enctypes.
> > 
> > If all of these are orthogonal (they should be) then we should just 
> > send sequences (sets, really, but ASN.1 SEQUENCEs) of enctypes, 
> > PAKEs, groups (curves; we're not likely to bother with non-EC DH, 
> > right?), and hash functions (and/or KDF??).
> 
> We don't need to send enctypes. This is already sent in etypes.
> 
> Having them all be orthogonal is how I originally designed it. But I 
> changed it given the above considerations. Small hashes/ECs should not 
> be used to generate larger keys.
> 
> > > Generally this relates to key size and protects large keys from 
> > > being generated by small curves.
> > 
> > I don't see why that should be a problem.  It should be possible to 
> > generate a key for AES-256 from a 128-bit shared secret.  That's one 
> > reason for PRFs/KDFs: so we can resolve such impedance mismatches.
> 
> What we can do and what we should do are different things. We can make 
> large keys from small seeds. But I think allowing this makes for 
> unclear security situations. I would prefer limiting the parameters 
> for an etype to only those which do not degrade the security 
> expectations of that etype.
> 
> > > > On the whole I prefer (3).  I agree that it's an optimization 
> > > > that could come later though.  But it's also an optimization 
> > > > that clients could implement immediately (with the fallback 
> > > > penalty); it's only the AS where more work is needed.
> > > 
> > > Having implemented it, the AS side is easy. The client is harder. 
> > > That is at least the case on the MIT codebase. I suspect it is 
> > > true of all implementations.
> > 
> > Interesting.  All the better.  Let's go with (3), with the 
> > optimization being optional.  Some clients will do (1), and that's 
> > OK.
> 
> I think you mean 1 with the optimization (3) being optional. I only 
> wish to add that it should be optional for clients but required for 
> servers.
> 
> Nathaniel
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten


-- 
Simo Sorce * Red Hat, Inc * New York