Re: [TLS] Design Alternatives for Kerberos + DH

Benjamin Kaduk <bkaduk@akamai.com> Sat, 17 October 2015 17:29 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 098241B2B44 for <tls@ietfa.amsl.com>; Sat, 17 Oct 2015 10:29:37 -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 bMi64Vdikgfm for <tls@ietfa.amsl.com>; Sat, 17 Oct 2015 10:29:35 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD861B2B43 for <tls@ietf.org>; Sat, 17 Oct 2015 10:29:35 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 447C6462FE2; Sat, 17 Oct 2015 17:29:34 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2EA2E462FDF; Sat, 17 Oct 2015 17:29:34 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445102974; bh=9nRqKmStnvjswjJAH1/iyx7/hbkBJfuZhXfoTuwIbic=; l=980; h=To:References:Cc:From:Date:In-Reply-To:From; b=h/PhbwHoj6hpbvwkikXS8EsuDwGIZhT04abHr07tJg76PPlO+EbZ8vVDWciWMLbLQ vmcWHV2kMiKgjAoHSW4YGw68ik6PRpLsykMgnjV2WfDCE8QZBYLuYt8Pmvqve/5+83 A22p186jM0ltltcFdYW3GNAe2Gm2mV+TM3G6nQ08=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E9CAC204E; Sat, 17 Oct 2015 17:29:33 +0000 (GMT)
To: Rick van Rein <rick@openfortress.nl>
References: <56212653.6050702@openfortress.nl> <1177744771.34157013.1445030003104.JavaMail.zimbra@redhat.com> <56216D37.1050701@akamai.com> <5621EF30.8040300@openfortress.nl>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <5622857D.90304@akamai.com>
Date: Sat, 17 Oct 2015 12:29:33 -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: <5621EF30.8040300@openfortress.nl>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gkK6smIEpNZsoZFjvV54CX46yaI>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Design Alternatives 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: Sat, 17 Oct 2015 17:29:37 -0000

On 10/17/2015 01:48 AM, Rick van Rein wrote:
> It still surprises me, but Kerberos is able to send a message one-way
> and achieve mutual authentication. The trick is of course that prior
> key exchanges have setup links that make

No, mutual authentication requires the client to receive a message from
the server.  This could be implicit as part of the first application
message, encrypted in a subsession key, but it does need to happen. 
(The krb5 GSSAPI mechanism sends a token from acceptor to initiator to
effect mutual authentication, in addition to the initial token from
initiator to acceptor.)  Without the additional return message, the
client has sent a message to some other party, and knows that that other
party cannot do something useful with that message unless it is the
party the client is intending to talk to, but the client could well have
been talking to an impostor that does not know the target service's
shared secret with the KDC.

-Ben