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
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- [TLS] Negotiation in draft-santesson-tls-gssapi Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Bodo Moeller