Re: [TLS] I-D: CipherSuites for Kerberos + DH

Benjamin Kaduk <bkaduk@akamai.com> Tue, 13 October 2015 14:44 UTC

Return-Path: <bkaduk@akamai.com>
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 625F81B44FA for <tls@ietfa.amsl.com>; Tue, 13 Oct 2015 07:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 v5q5kcteX1ZV for <tls@ietfa.amsl.com>; Tue, 13 Oct 2015 07:44:11 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id CF9FB1B44E8 for <tls@ietf.org>; Tue, 13 Oct 2015 07:44:05 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 750D84334ED; Tue, 13 Oct 2015 14:44:04 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5EF884334E7; Tue, 13 Oct 2015 14:44:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444747444; bh=ynS0EFKi34d9Z6l3gFzgwwyek/ZuqXHktBK0ajR2o+E=; l=1591; h=To:References:Cc:From:Date:In-Reply-To:From; b=DOcsY6EmL9/WTJ7AABXZ2B+xaLdWXhgrEdDMGDtCgjmKCQTGVi1tgAPFktQRIA1Qa fglJNdtCXFf9TeKqBt3r7wCaCpE9dsKUSNCNOWysqxBM9UA+RjLBJD3iLGWWWp5lGQ UflPl46LmuC1FjVXUi1Z4lS59T+h26TI368GGsLM=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 25DCC2027; Tue, 13 Oct 2015 14:44:04 +0000 (GMT)
To: Rick van Rein <rick@openfortress.nl>
References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0c=0dFpaRyiSsErVg_2cuco6M8mMgMS3YHLpxYEuH_82kw@mail.gmail.com> <561C39FB.6060206@akamai.com> <561C78D6.9030405@openfortress.nl>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <561D18B3.4020702@akamai.com>
Date: Tue, 13 Oct 2015 09:44:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <561C78D6.9030405@openfortress.nl>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/S2d1eBB7K4THDnEu3FSmz8NDnwc>
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 14:44:13 -0000

On 10/12/2015 10:21 PM, Rick van Rein wrote:
> 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.

There seems to be some miscommunication going on.  My comment was in
response to the proposal to "just use PSK" with the Kerberos session key
as the "pre-shared" secret -- that is, it would be "pre-shared"
immediately before initiating the TLS exchange.  That would require that
the application protocol send some Kerberos messages (so as to get both
peers the same session key) before starting up TLS and using a PSK mode
with that session key as the shared secret.  If the application protocol
is going to involve doing some "other stuff" before TLS, there's no
reason why that "other stuff" has to be limited to pure Kerberos;
multiple hops for a GSS-API exchange is fine for the "other stuff",
which is *not* part of the TLS exchange.

In your previous message, you (understandably) are resisting that, but I
just wanted to make clear that it's just as feasible to run GSS-API to
get a PSK to use for TLS as it is to run Kerberos to get a PSK, once the
restriction of being part of the TLS exchange is removed.

-Ben