Re: [TLS] Negotiation in draft-santesson-tls-gssapi

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 19 July 2007 23:28 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfQR-00052i-8Q; Thu, 19 Jul 2007 19:28:51 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfQP-00052Z-8B for tls@ietf.org; Thu, 19 Jul 2007 19:28:49 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBfQO-0008MK-ND for tls@ietf.org; Thu, 19 Jul 2007 19:28:49 -0400
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6JNSjbT026499 for <tls@ietf.org>; Thu, 19 Jul 2007 23:28:45 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6JNSj7m008728 for <tls@ietf.org>; Thu, 19 Jul 2007 17:28:45 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6JNSjib026103; Thu, 19 Jul 2007 18:28:45 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6JNSjDU026102; Thu, 19 Jul 2007 18:28:45 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 19 Jul 2007 18:28:45 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <Martin.Rex@sap.com>
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Message-ID: <20070719232844.GB25464@Sun.COM>
References: <20070718225633.GR24645@Sun.COM> <200707190035.l6J0ZgoV001472@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200707190035.l6J0ZgoV001472@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Thu, Jul 19, 2007 at 02:35:42AM +0200, Martin Rex wrote:
> While thinking a little longer about SPNEGO a number of problems
> come to mind.
> 
> A common mechanism OID between initiator and acceptor only means
> that they will be able to parse each other GSS-API tokens,
> it does by no way mean that authentication will work.
> 
> How common is it that companies (ultimately two rival companies)
> have mutual trust configured between their company-internal
> Kerberos realms and maintain each others Kerberos principals names
> on their ACLs?

Funny, I sent an e-mail to Sam last night proposing that we talk
tomorrow (we'll be in the same city) about the identity selection
problem.

I think it'd be nice to have a way to negotiate which "federation" (to
borrow a suitable term from the world of Liberty and other identity
schemes) to use.  I picture a (forgive me) stackable pseudo-mechanism by
which the client and server can agree on a federation.  In general it
should be sufficient, and better, for the server to tell the client what
the federations are that it participates in, ASAP, so that in protocols
where there's a chance to do that before the GSS context establishment
starts then no round-trip penalty is incurred.

However, there are issues to think about.  Protecting the negotiation is
an obvious one.  Privacy protection of the client's identity(ies) is
another.

One thing that seems nice is that "federation" names can be independent
of authentication mechanisms.  A PKI, Kerberos and or Liberty federation
would be a world of domains/realms where entities (such as users and
servers) should be able to authenticate each other provided that they
have valid credentials).

Federated world negotiation is part of the identity selection problem.
Of course, the identity selection problem is still non-trivial to solve
even if we solve the federated world negotiation problem.

Nico
-- 

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls