IETF Logo Mail Archive

Re: [TLS] the use cases for GSS-based TLS and the plea for

Nicolas Williams <Nicolas.Williams@sun.com> Sat, 21 July 2007 04:07 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 1IC6FP-0006Sn-5m; Sat, 21 Jul 2007 00:07:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC6FO-0006Sh-CC for tls@ietf.org; Sat, 21 Jul 2007 00:07:14 -0400
Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC6FI-0007nG-Oy for tls@ietf.org; Sat, 21 Jul 2007 00:07:14 -0400
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6L478s3003208 for <tls@ietf.org>; Sat, 21 Jul 2007 04:07:08 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6L477US001339 for <tls@ietf.org>; Fri, 20 Jul 2007 22:07:07 -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 l6L477Eg027215; Fri, 20 Jul 2007 23:07:07 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6L476RC027214; Fri, 20 Jul 2007 23:07:06 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 20 Jul 2007 23:07:06 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <Martin.Rex@sap.com>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
Message-ID: <20070721040705.GO26603@Sun.COM>
References: <46A12124.4020000@it.su.se> <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200707202225.l6KMP1ow027548@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
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

Martin, I definitely agree about islands of trust.

If servers/acceptors/responders should be able to have credentials for
multiple islands of trust[*] then we need to have them tell the
client/initiator what "islands"[*] of authentication, and what
mechanisms, they have credentials for.

It may be too late to work federation negotiation into SPNEGO, but it
makes plenty of sense to me that application protocols should handle
federation and mechanism negotiation rather than pseudo-mechanisms.

Here's our chance to get that right for TLS.

*  "worlds" or "federations" or whatever we should call it; in the
   Liberty, OpenID and other such communities the term used is
   'federation;, so I propose we use that.

Nico
-- 

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

v2.29.0 | Report a Bug | By Email | System Status