Re: [kitten] Kerberos preauth negotiation techniques
Nathaniel McCallum <npmccallum@redhat.com> Wed, 18 February 2015 14:22 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 65F7C1A87E7 for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 06:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.912
X-Spam-Level:
X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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 fpkdHrbhdEY9 for <kitten@ietfa.amsl.com>; Wed, 18 Feb 2015 06:22:44 -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 BD4111A87A1 for <kitten@ietf.org>; Wed, 18 Feb 2015 06:22:44 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEMgpK019279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Feb 2015 09:22:43 -0500
Received: from vpn-49-134.rdu2.redhat.com (vpn-49-134.rdu2.redhat.com [10.10.49.134]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1IEMePZ030208 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Feb 2015 09:22:41 -0500
Message-ID: <1424269360.2547.6.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Simo Sorce <simo@redhat.com>
Date: Wed, 18 Feb 2015 09:22:40 -0500
In-Reply-To: <1424268216.6980.1.camel@willson.usersys.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> <1424268216.6980.1.camel@willson.usersys.redhat.com>
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.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/OznvgJ_mEd9V4COk656BHDwHyn0>
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:22:47 -0000
On Wed, 2015-02-18 at 09:03 -0500, Simo Sorce wrote: > 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. I'm not sure. I hash whatever is in krb5_kdc_req.client. > > 3. the server principal > > 4. all padata sent or received I forgot to mention: 5. The long term key used in the PAKE > > 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 > >
- [kitten] Kerberos preauth negotiation techniques Greg Hudson
- Re: [kitten] Kerberos preauth negotiation techniq… Simo Sorce
- Re: [kitten] Kerberos preauth negotiation techniq… Benjamin Kaduk
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Simo Sorce
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Simo Sorce
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Benjamin Kaduk
- Re: [kitten] Kerberos preauth negotiation techniq… Greg Hudson
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Greg Hudson
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams
- Re: [kitten] Kerberos preauth negotiation techniq… Nathaniel McCallum
- Re: [kitten] Kerberos preauth negotiation techniq… Nico Williams