Re: [TLS] I-D: CipherSuites for Kerberos + DH
Rick van Rein <rick@openfortress.nl> Tue, 13 October 2015 03:22 UTC
Return-Path: <rick@openfortress.nl>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299E31B3723 for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 20:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 czR7uMkzrwUu for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 20:22:03 -0700 (PDT)
Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2871B2F83 for <tls@ietf.org>; Mon, 12 Oct 2015 20:22:03 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id UTN01r00610HQrX01TN11A; Tue, 13 Oct 2015 05:22:01 +0200
Message-ID: <561C78D6.9030405@openfortress.nl>
Date: Tue, 13 Oct 2015 05:21:58 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Benjamin Kaduk <bkaduk@akamai.com>
References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0c=0dFpaRyiSsErVg_2cuco6M8mMgMS3YHLpxYEuH_82kw@mail.gmail.com> <561C39FB.6060206@akamai.com>
In-Reply-To: <561C39FB.6060206@akamai.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HDqojfb4ogzwrt_AKa1gNuNtBRE>
Cc: tls@ietf.org
Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 03:22:06 -0000
Hello Benjamin, > This would seem to require an application protocol doing some Kerberos > exchanges up front to establish the Kerberos session key before pivoting > into TLS-PSK in a STARTLS-esque fashion. If that's what the application > protocol would look like, it seems like there's no reason not to go > full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides. GSSAPI is too general IMHO; it specifies an unpredictable number of exchanges and TLS cannot carry that. An attempt for SASL-in-TLS was made in draft-williams-tls-app-sasl-opt, but it ends up piggybacking on TLS but continue afterwards -- loosing the cryptographic binding between auth from Kerberos with PFS from (EC)DH. > This proposal (as complicated as it is, and I'm not sure that I'm > entirely comfortable with it yet) has the comparative advantage that the > application speaks TLS from the start, with the Kerberos messages > included in the TLS CKE. In that sense, at least, it is elegant. Thanks. The proposed changes greatly simplify the spec, making all DH orthogonal to the spec. Watson convinced me and now I can pull a lot from the I-D, which is also more complex than I like. > This proposal also includes a generic mechanism for the server to > indicate what service type and hostname should be used in constructing > the host-based service principal name for Kerberos, which is useful -- > the convention for that would otherwise have to be baked into the > application protocol. > Actually, I did not specify such a mechanism. * Client and server assume that the application context knows what protocol it is using. AFAIK that always makes sense -- on top of TLS we're running something like imap, and imap knows that its tickets start with "imap/". * The hostname is known to the client too, it is usually included in the SNI extension, looked up in DNS, ... * However, the realm is "supposed to be derived independently" which can be done with the DNSSEC-assured _kerberos TXT that we discussed on Kitten. > The considerations around client anonymity and a > protocol for the server to convey its expectations are also interesting, > though I'm not sure I would have put it in the -00 if it was my own > document. OK :) but this was simpler than the loose end in predecessors -- sending no ticket and deciding how the server would respond to that. But it is a new idea, to have authenticated clients with unknown identities... > There are some nits in the Kerberos bits that I might mention over on > kitten. Great, thanks! -Rick
- [TLS] I-D: CipherSuites for Kerberos + DH Rick van Rein
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Ilari Liusvaara
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Watson Ladd
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Eric Rescorla
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Paul Wouters
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Hugo Krawczyk
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Rick van Rein
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Ilari Liusvaara
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Benjamin Kaduk
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Rick van Rein
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Rick van Rein
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Benjamin Kaduk
- Re: [TLS] I-D: CipherSuites for Kerberos + DH Watson Ladd