From owner-ietf-sasl Tue Aug 5 14:13:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDSqt038633 for ; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75LDSbp038631 for ietf-sasl-bks; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDRqt038621 for ; Tue, 5 Aug 2003 14:13:27 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust32.tnt24.lnd4.gbr.da.uu.net [62.188.151.32]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h75LH5V21287; Tue, 5 Aug 2003 15:17:06 -0600 Message-ID: <3F300F66.5030301@isode.com> Date: Tue, 05 Aug 2003 21:11:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Draft minutes References: <20030725200648.282C4152496@konishi-polis.mit.edu> In-Reply-To: <20030725200648.282C4152496@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Very good notes indeed. Sam Hartman wrote: > Please send in comments or corrections by next Tuesday. I will send > in for proceedings shortly after that point. > > IETF SASL WG meeting Minutes > ========================== > > Tuesday 15 July 2003 > 3:45pm > chairs: Sam Hartman Kurt Zeilenga > > scribe: Luke Howard > > 2222bis > ======= > > - Alexei noted that he has published a subsequent revision of > 2222bis; minor editorial issues remain > - Clarification of empty authorization identities > - Alexei will do a final revision of the document in the first > week of August after which it can go to last call > As I haven't received any comments I haven't done any work ;-). Alexey From owner-ietf-sasl Tue Aug 19 12:35:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ5qt019879 for ; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZ5gP019878 for ietf-sasl-bks; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ4qt019873 for ; Tue, 19 Aug 2003 12:35:04 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03727; Tue, 19 Aug 2003 15:35:02 -0400 (EDT) Message-Id: <200308191935.PAA03727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-02.txt Date: Tue, 19 Aug 2003 15:35:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-02.txt Pages : 18 Date : 2003-8-19 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Aug 21 12:36:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJa0qt050273 for ; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LJa03n050272 for ietf-sasl-bks; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJZxqt050267 for ; Thu, 21 Aug 2003 12:35:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5EEF8151CEC; Thu, 21 Aug 2003 15:35:58 -0400 (EDT) To: ietf-sasl@imc.org Cc: nicolas.williams@sun.com Subject: GSSAPI and domain-based names Message-Id: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Date: Thu, 21 Aug 2003 15:35:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few months ago, there was a discussion on the krbdev@mit.edu mailing list about names for GSSAPI principals. One conclusion from that list is that we may have an incomplete handling of the issue in SASL. I'm going to present the issue and step back and let Nico actually argue about solutions. The problem is what GSSAPI name do you use for replicated GSSAPI services? For some services, particularly those running on a cluster of tightly connected machines, especially with aload balancer involved, you want to use the same GSSAPI name. But for other services, especially when an SRV record is used to find the specific machine, it seems like you want to avoid requiring the instances of the service to use the same GSSAPI name. This is particularly true for some GSSAPI mechanisms such as Kerberos that need to share a replay cache. Note that this issue is not unique to GSSAPI. Other mechanisms such as the digest-md5 mechanism specify mildly complicated naming rules, where the name the user typed in is combined with the the name from the DNS or other location service. Two questions: 1) Do we want to provide some better handling for this situation in the GSSAPI case? IT's clear we cannot get away with just using service@name_from_dns. We can either use service@name_typed_by_user, requiring any replicated service to just deal internally or we could use some new name type. 2) Do we want to say anything about this in the base spec? We aren't designing an API, but we may want to give general guidelines about what bits of information SASL mechanisms can assume they can get from an application, to prevent people designing mechanisms in the future that make unreasonable requirements of multi-mechanisms implementations. --Sam From owner-ietf-sasl Thu Aug 21 13:08:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8tqt053905 for ; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LK8tPY053904 for ietf-sasl-bks; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8sqt053884 for ; Thu, 21 Aug 2003 13:08:54 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7LK8p5q025575; Thu, 21 Aug 2003 13:08:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LK8ocm022476; Thu, 21 Aug 2003 14:08:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LK5MQx002929; Thu, 21 Aug 2003 13:05:22 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LK5LOw002928; Thu, 21 Aug 2003 13:05:21 -0700 (PDT) Date: Thu, 21 Aug 2003 13:05:21 -0700 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821200521.GP1319@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 03:35:58PM -0400, Sam Hartman wrote: > > > A few months ago, there was a discussion on the krbdev@mit.edu mailing > list about names for GSSAPI principals. > > One conclusion from that list is that we may have an incomplete > handling of the issue in SASL. I'm going to present the issue and > step back and let Nico actually argue about solutions. :) > The problem is what GSSAPI name do you use for replicated GSSAPI > services? For some services, particularly those running on a cluster > of tightly connected machines, especially with aload balancer > involved, you want to use the same GSSAPI name. So, the Kerberos TGS names are what I'd call domain-based service names - like host-based service names, but with a domain (realm) name instead of a hostname. I think the concept of domain/cluster-based service names needs to be generalized beyond the particular case of the Kerberos TGS. One way to do this would be to define a new GSS-API name type. Another would be to establish the convention of using domain names with the existing GSS-API host-based service name where domain-based services are needed. If we go the route of defining a new GSS-API name type we can actually do a very neat trick: we can have the name encode the service name, the domain name and, optionally, a hostname name (an instance of the domain- based service). This would avoid the replay caching issue. What's the difference between domain-based service names and host-based service names? With host-based service names, if a client has to lookup what servers are associated with a domain-wide infrastructure/cluster, the resulting principal names won't reflect the domain/cluster association, and if the lookup is not secure, well that's a problem. With domain-based names the client makes sure that the name of the domain/cluster it's interested in is part of the principal name and so binds the service principal name, no matter how the servers may be found, to that domain name. > But for other services, especially when an SRV record is used to find > the specific machine, it seems like you want to avoid requiring the > instances of the service to use the same GSSAPI name. This is > particularly true for some GSSAPI mechanisms such as Kerberos that > need to share a replay cache. Replay cache sharing is a related issue, but it's an implementation detail, a security consideration. Of course, shared replay caching is reasonably feasible for some cases, but it may not always be feasible though. I think that, for example, LDAP services ought to use domain-based service names, no matter how the servers are located. This means that the LDAP servers for any given domain have to share a replay cache OR that we really need a domain-based name type with host instances. > Note that this issue is not unique to GSSAPI. Other mechanisms such > as the digest-md5 mechanism specify mildly complicated naming rules, > where the name the user typed in is combined with the the name from > the DNS or other location service. > > Two questions: > > 1) Do we want to provide some better handling for this situation in > the GSSAPI case? IT's clear we cannot get away with just using > service@name_from_dns. We can either use > service@name_typed_by_user, requiring any replicated service to > just deal internally or we could use some new name type. In the case of LDAP the service name may often not be derived from any information typed in by the user (e.g., where LDAP is used by a name service switch). The domain name could come from local configuration or from user context (e.g., from a domain-qualified username). If we're using a domain-based name type with host instances the hostname can safely come from an SRV record. See above. > 2) Do we want to say anything about this in the base spec? We aren't > designing an API, but we may want to give general guidelines about > what bits of information SASL mechanisms can assume they can get > from an application, to prevent people designing mechanisms in the > future that make unreasonable requirements of multi-mechanisms > implementations. IMO it would be nice to specify a domain based name type for the GSS-API and the various existing GSS-API mechanisms. Then amend SASL to require support for domain-based naming where applications request it and where the SASL mechanisms support it. Cheers, Nico -- From owner-ietf-sasl Thu Aug 21 13:50:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoXqt056567 for ; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LKoXjB056566 for ietf-sasl-bks; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoWqt056561 for ; Thu, 21 Aug 2003 13:50:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8A95D151D10; Thu, 21 Aug 2003 16:50:34 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> From: Sam Hartman Date: Thu, 21 Aug 2003 16:50:34 -0400 In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> (Nicolas Williams's message of "Thu, 21 Aug 2003 13:05:21 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing I think I can do with my chair hat on is suggest what you'd need to do if you want to make a change to the SASL GSSAPI spec. Obviously you'd need to get consensus. But it seems that you would need to specify how the SASL GSSAPI spec should choose the GSSAPI name it uses, and how it works with GSSAPI mechanisms that do not support any new name types you introduce. Then you would need to fully describe interoperability considerations, looking at applications written to the old SASL GSSAPI mechanisms as well as old implementations of the SASL GSSAPI mechanisms. Then you need to convince people that your proposed changes are acceptable. From owner-ietf-sasl Thu Aug 21 15:18:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIxqt059983 for ; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMIwFi059982 for ietf-sasl-bks; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIvqt059975 for ; Thu, 21 Aug 2003 15:18:57 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7LMMgn23852; Thu, 21 Aug 2003 16:22:42 -0600 From: Steve Hole Date: Thu, 21 Aug 2003 16:22:42 -0700 To: Nicolas Williams Subject: Re: GSSAPI and domain-based names Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7LMIvqt059977 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams wrote: > If we go the route of defining a new GSS-API name type we can actually > do a very neat trick: we can have the name encode the service name, the > domain name and, optionally, a hostname name (an instance of the domain- > based service). This would avoid the replay caching issue. > > What's the difference between domain-based service names and host-based > service names? With host-based service names, if a client has to lookup > what servers are associated with a domain-wide infrastructure/cluster, > the resulting principal names won't reflect the domain/cluster > association, and if the lookup is not secure, well that's a problem. > With domain-based names the client makes sure that the name of the > domain/cluster it's interested in is part of the principal name and so > binds the service principal name, no matter how the servers may be > found, to that domain name. Could you please work up an example of this Nico -- say a three system load balanced HTTP cluster? I'm having a hard time understanding exactly when the name resolution is going to occur and what kerberos principals will be bound. Sorry for being thick )-: Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-sasl Thu Aug 21 15:28:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSwqt061282 for ; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMSvA4061279 for ietf-sasl-bks; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSvqt061272 for ; Thu, 21 Aug 2003 15:28:57 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7LMSsIh024890; Thu, 21 Aug 2003 16:28:59 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LMSrcm021901; Thu, 21 Aug 2003 16:28:54 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LMPOQx003053; Thu, 21 Aug 2003 15:25:25 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LMPOmc003052; Thu, 21 Aug 2003 15:25:24 -0700 (PDT) Date: Thu, 21 Aug 2003 15:25:24 -0700 From: Nicolas Williams To: Steve Hole Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > wrote: > > > If we go the route of defining a new GSS-API name type we can actually > > do a very neat trick: we can have the name encode the service name, the > > domain name and, optionally, a hostname name (an instance of the domain- > > based service). This would avoid the replay caching issue. > > > > What's the difference between domain-based service names and host-based > > service names? With host-based service names, if a client has to lookup > > what servers are associated with a domain-wide infrastructure/cluster, > > the resulting principal names won't reflect the domain/cluster > > association, and if the lookup is not secure, well that's a problem. > > With domain-based names the client makes sure that the name of the > > domain/cluster it's interested in is part of the principal name and so > > binds the service principal name, no matter how the servers may be > > found, to that domain name. > > > Could you please work up an example of this Nico -- say a three system > load balanced HTTP cluster? I'm having a hard time understanding exactly > when the name resolution is going to occur and what kerberos principals > will be bound. > > Sorry for being thick )-: NP :) For a load balanced system one would have to use a principal that is shared throughout the cluster (that means sharing the rcache too, for Kerberos). So the principal name would be just service@domain or service@clustername. For non-cluster domain-wide services the names might be of the form service@domain@host_instance. I.e., the syntax for domain-based names might be "@" [ "@" ] Where you can share a principal across multiple hosts you'd not use the optional hostname instance part. Cheers, Nico -- From owner-ietf-sasl Thu Aug 21 16:15:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFRqt064975 for ; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LNFRbu064974 for ietf-sasl-bks; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFPqt064946 for ; Thu, 21 Aug 2003 16:15:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:23 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Aug 2003 16:15:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:43 -0700 Content-class: urn:content-classes:message Subject: RE: GSSAPI and domain-based names MIME-Version: 1.0 Date: Thu, 21 Aug 2003 16:15:17 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C367FF.6934DF60" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE246044916D6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: GSSAPI and domain-based names thread-index: AcNoNtyiQi48x7mOQYKjJGm642xXPQAAHN8A From: "Paul Leach" To: "Nicolas Williams" , "Steve Hole" Cc: "Sam Hartman" , X-OriginalArrivalTime: 21 Aug 2003 23:15:43.0370 (UTC) FILETIME=[24F16EA0:01C3683A] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There is lots of implemented art here at MSFT on principal names for replicated services. I'll attempt a brief intro. We use "service-type/service-instance/service-name" as the principal name. The service type might (and is, for Active Directory) "ldap". The service instance is the host an instance is running on -- "ad1.microsoft.com" might the the host for one instance of AD. The service-name might be "microsoft.com" for the LDAP service for Microsoft. (Microsoft's is actually a hierarchy of LDAP naming contexts, but this might be a real enough example for a smaller company.) The overall service principal name (SPN) for this example would thus be: "ldap/ad1.microsoft.com/microsoft.com" -- this is what is in the "sname" field of the service ticket. In the case that a single host runs multiple instances of a service, the above is elaborated a little bit. The service-instance is "service-host:instance-within-host". The instance with a host could be the port number of the separate instance, or it could be anything the application protocol chooses. (In fact, the whole "service-instance" is just a convention of the application protocol -- a UUID would work just fine.) The way our clients of replicated services work is that they look up SRV records for "service-name" -- in the above example, they might have looked up _ldap._tcp.microsoft.com and gotten back "ad1.microsoft.com" and "ad2.microsoft.com" and picked the first one. Note that the lookup does not have to be secure -- a DNS spoofing attack that returned "ad3.microsoft.com" as a SRV record would not be backed up by an entry in the KDC account database with a key that the attacker knew unless the KDC administrator had entered it there, thus attesting to the fact that it was a legitimate LDAP server for the "microsoft.com" domain. (If no SRV records are found, then A records are looked up, and if found, the form "service-type/service-host" is used. Again, if multiple instances on a host are allowed, then "service-type/service-host:instance-within-host" will enable that.) We use this convention polymorphically across all our GSSAPI (aka SSPI) providers that do mutual authentication. Not all of them are full function, however. > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Nicolas Williams > Sent: Thursday, August 21, 2003 3:25 PM > To: Steve Hole > Cc: Sam Hartman; ietf-sasl@imc.org > Subject: Re: GSSAPI and domain-based names > > > On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > > wrote: > > > > > If we go the route of defining a new GSS-API name type we can > > > actually do a very neat trick: we can have the name encode the > > > service name, the domain name and, optionally, a hostname > name (an > > > instance of the domain- based service). This would avoid > the replay caching issue. > > > > > > What's the difference between domain-based service names and > > > host-based service names? With host-based service names, if a > > > client has to lookup what servers are associated with a > domain-wide > > > infrastructure/cluster, the resulting principal names > won't reflect > > > the domain/cluster association, and if the lookup is not > secure, well that's a problem. > > > With domain-based names the client makes sure that the > name of the > > > domain/cluster it's interested in is part of the > principal name and > > > so binds the service principal name, no matter how the > servers may > > > be found, to that domain name. > > > > > > Could you please work up an example of this Nico -- say a > three system > > load balanced HTTP cluster? I'm having a hard time > understanding exactly > > when the name resolution is going to occur and what kerberos > > principals will be bound. > > > > Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal > that is shared throughout the cluster (that means sharing the > rcache too, for Kerberos). So the principal name would be > just service@domain or service@clustername. > > For non-cluster domain-wide services the names might be of > the form service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd > not use the optional hostname instance part. > > Cheers, > > Nico > -- > > ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCh1jglcA AwAsWZEwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzA0MjgwOTMwMTBa Fw0wNDA0MjcwOTMwMTBaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK8q3dHN aRbyzj0hnINinZSuRGGEY0WpOUMpy0dgklY0FW913oCP62W2vgvmKcxbDqA5yPAKJod/TkbYRPlY FDtfnZdD9kc11+oxtd8zGMKGx8UV4Chyc9pfXBpwzrSblVEREQ3XrP4k5fUDNoYSzknxuiaA+avi hn2o3kBQzaeNAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEBMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFLbRfFiHr8C4PpvhKuqQTBEmysTEMB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAehivR7RM+wxHRKjow7JvhVuZ5Gcj7U0mCIZxjwYfpkvuwf2J AhHrDivfHJB1dc0ye3qL8iWU26BsvjCxGVnlireU/y51DreLtWY7744+zlXvTPqbmhkn9v+I3ROL NVTQDp0jr5F700gRXN5xuNoHxKCpXlaaHg6jbUF/VuroAzEwggbsMIIGVaADAgECAgpxnD1XAAMA LVX+MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwNTE0MTgwMTI3WhcN MDQwNTEzMTgwMTI3WjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1ZQ34QuiBnnKuzneDRusrIzDH kzkrFkBpCVq5Gv/CORZ80/TQ/PgekPMwb2xuIH9+ynLgONNX3QuP6qRQcezzfcvDsiqV9a8VXX9P sjWzjiItJpDcNCVRhAGnw500vi5GF7Iz3KsAm/XhTqXTV3De8vWi8I0Al99l4sfTRhJmpQIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQEwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFMGGfqHf0cheFty2yjOP5eYfSpYKMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAhsPDfvHwZ0VLtxIDCQFpyrbMoUsVAj7oeNco B+eHWkSWtUqWDR+QJdKfRSB/df6N8COrRS3qL35b5txq2Lf/WObF4Z/TOhou7ghxS7gSmZ9eyYIh vLXQ2FsIsQ6zdn4wx1gdHGfj0jXJYxl71UXBfmMfyYR2GapwUKQIBBw6K3swgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCh1jglcAAwAs WZEwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwODIxMjMxNTE3WjAjBgkqhkiG9w0BCQQxFgQUtWdaepSRBGVNM7y80TMHi7/z7BQwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MA0GCSqGSIb3DQEBAQUABIGAQVlVWSicsTDB jSdmqtaSsyTyjImZ8+KFfesQvaqZhQe1brj0ypVp8NlqVc6ASksaRfiVmObBFL0XTRYqXkN50baP ODp9hqCaVI4HWAkEiXqot48lO/S3W3ur+7SDznfAoMbDt2vJYfVXXSjLU75iVP/OqglubCmW7h7v njKHu/4AAAAAAAA= ------=_NextPart_000_0008_01C367FF.6934DF60-- From owner-ietf-sasl Thu Aug 21 18:38:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M1ctqt070876 for ; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M1ctTp070875 for ietf-sasl-bks; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7M1csqt070868 for ; Thu, 21 Aug 2003 18:38:54 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa19372; 21 Aug 2003 21:38 EDT Date: Thu, 21 Aug 2003 21:38:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <1022390000.1061516323@minbar.fac.cs.cmu.edu> In-Reply-To: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, August 21, 2003 15:25:24 -0700 Nicolas Williams wrote: >> Could you please work up an example of this Nico -- say a three system >> load balanced HTTP cluster? I'm having a hard time understanding >> exactly when the name resolution is going to occur and what kerberos >> principals will be bound. >> >> Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal that is > shared throughout the cluster (that means sharing the rcache too, for > Kerberos). So the principal name would be just service@domain or > service@clustername. > > For non-cluster domain-wide services the names might be of the form > service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd not use the > optional hostname instance part. Of course, this only describes the name syntax at the GSSAPI layer. In the case of the Kerberos mechansm, this would presumably map to principal names with more than one component, like http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach described. I'd be interested in hearing what sort of GSSAPI name types Microsoft is using that map to these principal names, if any. And I'd also like to hear whether these are truly three-component principal names, or single-component names with '/' embedded in the instance. In any case, I'm somewhat concerned as to whether defining a new GSSAPI name type is in scope for this working group. Actually, I'm more concerned that if this work happens here, we might inadvertently exclude folks who care about this issue but otherwise have no interest in SASL. As long as we make sure these folks have a chance to participate, I'm all in favor of doing this work here -- it's a real problem and I'd definitely like to see a solution. -- Jeff From owner-ietf-sasl Thu Aug 21 21:42:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077931 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4gemn077930 for ietf-sasl-bks; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077924 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4gb5q023783; Thu, 21 Aug 2003 21:42:37 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4gacm009185; Thu, 21 Aug 2003 22:42:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4d7Qx003219; Thu, 21 Aug 2003 21:39:07 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4d6ST003218; Thu, 21 Aug 2003 21:39:06 -0700 (PDT) Date: Thu, 21 Aug 2003 21:39:06 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030822043906.GW1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> <1022390000.1061516323@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022390000.1061516323@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 09:38:43PM -0400, Jeffrey Hutzelman wrote: > Of course, this only describes the name syntax at the GSSAPI layer. In the > case of the Kerberos mechansm, this would presumably map to principal names > with more than one component, like > http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach > described. Of course, I was only describing the proposed GSS-API name syntax. > I'd be interested in hearing what sort of GSSAPI name types Microsoft is > using that map to these principal names, if any. And I'd also like to hear > whether these are truly three-component principal names, or > single-component names with '/' embedded in the instance. Me too. > In any case, I'm somewhat concerned as to whether defining a new GSSAPI > name type is in scope for this working group. Actually, I'm more concerned > that if this work happens here, we might inadvertently exclude folks who > care about this issue but otherwise have no interest in SASL. As long as > we make sure these folks have a chance to participate, I'm all in favor of > doing this work here -- it's a real problem and I'd definitely like to see > a solution. No kidding. I think that given the lack of a CAT WG (or KITTEN, as you've suggested - no I haven't come up with something that it could be the acronym for) we can do GSS-API work elsewhere, but we ought to give other WGs heads ups, and even Last-Call in multiple WGs. E.g., the NFSv4 WG I-D on CCM - the Channel Conjunction Mechanism. Nico -- From owner-ietf-sasl Thu Aug 21 21:52:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078229 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4qgmj078228 for ietf-sasl-bks; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078223 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4qe5q028873; Thu, 21 Aug 2003 21:52:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4qebO006197; Thu, 21 Aug 2003 22:52:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4nBQx003229; Thu, 21 Aug 2003 21:49:11 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4nArN003228; Thu, 21 Aug 2003 23:49:10 -0500 (CDT) Date: Thu, 21 Aug 2003 23:49:10 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: SRP Mechanism & GSS-API domain-based names (was Re: GSSAPI and domain-based names) Message-ID: <20030822044910.GK19235@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SRP GSS-API mechanism that's been discussed here is one that could use domain-based names. As we've seen, though SRP itself provides for mutual authentication, the proposed mechanism does not deal with acceptor principal naming, therefore it can't be said to provide mutual authentication with any acceptor name other than the anonymous name. This can be addressed by salting the password/verifier with the name of the acceptor principal, but this would mean generating a verifier per-{user host} tuple, which does not scale well. So an SRP mechanism could benefit from domain-based names in environments where verifiers are generated per-{user service} or {user domain} tuples, or any such tuple that is less numerous than {user host} tuples are. That is, one could get away with fewer verifiers per-user by using domain-based names. This possibility complicates the way in which an application decides which name type to use for an acceptor, but not much. As I've said, I think LDAP ought to use domain-based names, but existing implementations may not, so for interop any implementation that supports domain-based names will also have to be configurable to use host-based names. Such a configuration parameter might be a per-mechanism parameter (and one might even have a per-domain configuration too). I hope this and my previous post answers Sam's question about when to use which name type. Cheers, Nico -- From owner-ietf-sasl Tue Aug 26 18:01:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Sgc096991 for ; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R11Srv096990 for ietf-sasl-bks; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Rgc096983 for ; Tue, 26 Aug 2003 18:01:27 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7R11NkU026558; Tue, 26 Aug 2003 21:01:24 -0400 (EDT) Message-ID: <3F4C02DE.5040400@oceana.com> Date: Tue, 26 Aug 2003 21:01:18 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP mailing list , SASL mailing list Subject: NTLM authentication documentation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Resurrecting a badly beaten horse... Is there any interest in having NTLM authentication (as a SASL mech and possibly as an HTTP mech) documented as an Informational RFC? I believe I have enough existing documentation (Eric Glass' http://davenport.sourceforge.net/ntlm.html being the best) and enough implementation experience writing the CMU SASL NTLM plugin to write a fairly complete document. I would probably use Eric's documentation of the message formats and the algorithms for the password hashes from Paul Leach's CIFS draft. I'm especially interested in hearing from the Microsoft folks w.r.t. any IPR problems. Since Paul has already made the algorithms available in an I-D, I guess the only outstanding issue would be the message formats. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Aug 27 15:40:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMehgc089461 for ; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RMeh12089460 for ietf-sasl-bks; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMeggc089450 for ; Wed, 27 Aug 2003 15:40:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7RMeeUk016536 for ; Wed, 27 Aug 2003 15:40:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RMeacm007676 for ; Wed, 27 Aug 2003 16:40:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7RMb3Qx007721 for ; Wed, 27 Aug 2003 15:37:03 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RMb2Ll007720 for ietf-sasl@imc.org; Wed, 27 Aug 2003 17:37:02 -0500 (CDT) Date: Wed, 27 Aug 2003 17:37:02 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: GSS-SPNEGO and relative mechanism strengths Message-ID: <20030827223702.GS19235@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL GSS-SPNEGO mechanism, on the client side, needs to know the mechlist that the client got from the server and the SSF values associated with each GSS-API mechanism available to decide which mechanisms to negotiate. (See section 4 of draft-ietf-cat-sasl-gssapi-05.txt.) How can a SASL GSS-SPNEGO mechanism client-side implementation determine the SSF values that would be associated with each GSS-API mechanism without hardcoding mechanism OIDs and SSF values? A GSS-API extension, GSS_Inquire_mech(), say, that allows applications to determine the set of features supported by a given mechanism would help. The relative strengths of GSS-API mechanisms that support confidentiality (SSF values > 1) can't really be determined statically, or even dynamically (it is not even possible to determine what QoPs will be available with what mech until a context is established), so ideally, if GSS_Inquire_mech() says anything about mechanism strength at all then that should be configurable. (And if GSS_Inquire_mech() has nothing at all to say about mech strength, then truly generic SASL GSS-SPNEGO mechanism client-side implementation might have to assume SSF values for mechs that provide confidentiality, perhaps a single value for all such GSS-API mechs.) Cheers, Nico -- From owner-ietf-sasl Fri Aug 29 07:06:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE67gc078952 for ; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TE67WV078951 for ietf-sasl-bks; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE65gc078926 for ; Fri, 29 Aug 2003 07:06:05 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7TE61X0024154 for ; Fri, 29 Aug 2003 10:06:01 -0400 (EDT) Message-ID: <3F4F5E46.5010101@oceana.com> Date: Fri, 29 Aug 2003 10:08:06 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just submitted the following document: ftp://ftp.oceana.com/pub/drafts/draft-murchison-sasl-login-00.txt This is an attempt to document the intended and currently deployed functionality of the obsolete LOGIN SASL mechanism. If anyone is aware of additional/different deployed behavior, we'd be interested in hearing about it. We are aware that some servers allow the username to be sent as an initial response (for those protocol that support it), but we haven't yet decided if we want to document that. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Tue Aug 5 14:13:28 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDSqt038633 for ; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75LDSbp038631 for ietf-sasl-bks; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDRqt038621 for ; Tue, 5 Aug 2003 14:13:27 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust32.tnt24.lnd4.gbr.da.uu.net [62.188.151.32]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h75LH5V21287; Tue, 5 Aug 2003 15:17:06 -0600 Message-ID: <3F300F66.5030301@isode.com> Date: Tue, 05 Aug 2003 21:11:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Draft minutes References: <20030725200648.282C4152496@konishi-polis.mit.edu> In-Reply-To: <20030725200648.282C4152496@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Very good notes indeed. Sam Hartman wrote: > Please send in comments or corrections by next Tuesday. I will send > in for proceedings shortly after that point. > > IETF SASL WG meeting Minutes > ========================== > > Tuesday 15 July 2003 > 3:45pm > chairs: Sam Hartman Kurt Zeilenga > > scribe: Luke Howard > > 2222bis > ======= > > - Alexei noted that he has published a subsequent revision of > 2222bis; minor editorial issues remain > - Clarification of empty authorization identities > - Alexei will do a final revision of the document in the first > week of August after which it can go to last call > As I haven't received any comments I haven't done any work ;-). Alexey From owner-ietf-sasl Tue Aug 19 12:35:05 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ5qt019879 for ; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZ5gP019878 for ietf-sasl-bks; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ4qt019873 for ; Tue, 19 Aug 2003 12:35:04 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03727; Tue, 19 Aug 2003 15:35:02 -0400 (EDT) Message-Id: <200308191935.PAA03727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-02.txt Date: Tue, 19 Aug 2003 15:35:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-02.txt Pages : 18 Date : 2003-8-19 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-sasl Thu Aug 21 12:36:00 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJa0qt050273 for ; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LJa03n050272 for ietf-sasl-bks; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJZxqt050267 for ; Thu, 21 Aug 2003 12:35:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5EEF8151CEC; Thu, 21 Aug 2003 15:35:58 -0400 (EDT) To: ietf-sasl@imc.org Cc: nicolas.williams@sun.com Subject: GSSAPI and domain-based names Message-Id: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Date: Thu, 21 Aug 2003 15:35:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few months ago, there was a discussion on the krbdev@mit.edu mailing list about names for GSSAPI principals. One conclusion from that list is that we may have an incomplete handling of the issue in SASL. I'm going to present the issue and step back and let Nico actually argue about solutions. The problem is what GSSAPI name do you use for replicated GSSAPI services? For some services, particularly those running on a cluster of tightly connected machines, especially with aload balancer involved, you want to use the same GSSAPI name. But for other services, especially when an SRV record is used to find the specific machine, it seems like you want to avoid requiring the instances of the service to use the same GSSAPI name. This is particularly true for some GSSAPI mechanisms such as Kerberos that need to share a replay cache. Note that this issue is not unique to GSSAPI. Other mechanisms such as the digest-md5 mechanism specify mildly complicated naming rules, where the name the user typed in is combined with the the name from the DNS or other location service. Two questions: 1) Do we want to provide some better handling for this situation in the GSSAPI case? IT's clear we cannot get away with just using service@name_from_dns. We can either use service@name_typed_by_user, requiring any replicated service to just deal internally or we could use some new name type. 2) Do we want to say anything about this in the base spec? We aren't designing an API, but we may want to give general guidelines about what bits of information SASL mechanisms can assume they can get from an application, to prevent people designing mechanisms in the future that make unreasonable requirements of multi-mechanisms implementations. --Sam From owner-ietf-sasl Thu Aug 21 13:08:55 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8tqt053905 for ; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LK8tPY053904 for ietf-sasl-bks; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8sqt053884 for ; Thu, 21 Aug 2003 13:08:54 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7LK8p5q025575; Thu, 21 Aug 2003 13:08:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LK8ocm022476; Thu, 21 Aug 2003 14:08:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LK5MQx002929; Thu, 21 Aug 2003 13:05:22 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LK5LOw002928; Thu, 21 Aug 2003 13:05:21 -0700 (PDT) Date: Thu, 21 Aug 2003 13:05:21 -0700 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821200521.GP1319@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 03:35:58PM -0400, Sam Hartman wrote: > > > A few months ago, there was a discussion on the krbdev@mit.edu mailing > list about names for GSSAPI principals. > > One conclusion from that list is that we may have an incomplete > handling of the issue in SASL. I'm going to present the issue and > step back and let Nico actually argue about solutions. :) > The problem is what GSSAPI name do you use for replicated GSSAPI > services? For some services, particularly those running on a cluster > of tightly connected machines, especially with aload balancer > involved, you want to use the same GSSAPI name. So, the Kerberos TGS names are what I'd call domain-based service names - like host-based service names, but with a domain (realm) name instead of a hostname. I think the concept of domain/cluster-based service names needs to be generalized beyond the particular case of the Kerberos TGS. One way to do this would be to define a new GSS-API name type. Another would be to establish the convention of using domain names with the existing GSS-API host-based service name where domain-based services are needed. If we go the route of defining a new GSS-API name type we can actually do a very neat trick: we can have the name encode the service name, the domain name and, optionally, a hostname name (an instance of the domain- based service). This would avoid the replay caching issue. What's the difference between domain-based service names and host-based service names? With host-based service names, if a client has to lookup what servers are associated with a domain-wide infrastructure/cluster, the resulting principal names won't reflect the domain/cluster association, and if the lookup is not secure, well that's a problem. With domain-based names the client makes sure that the name of the domain/cluster it's interested in is part of the principal name and so binds the service principal name, no matter how the servers may be found, to that domain name. > But for other services, especially when an SRV record is used to find > the specific machine, it seems like you want to avoid requiring the > instances of the service to use the same GSSAPI name. This is > particularly true for some GSSAPI mechanisms such as Kerberos that > need to share a replay cache. Replay cache sharing is a related issue, but it's an implementation detail, a security consideration. Of course, shared replay caching is reasonably feasible for some cases, but it may not always be feasible though. I think that, for example, LDAP services ought to use domain-based service names, no matter how the servers are located. This means that the LDAP servers for any given domain have to share a replay cache OR that we really need a domain-based name type with host instances. > Note that this issue is not unique to GSSAPI. Other mechanisms such > as the digest-md5 mechanism specify mildly complicated naming rules, > where the name the user typed in is combined with the the name from > the DNS or other location service. > > Two questions: > > 1) Do we want to provide some better handling for this situation in > the GSSAPI case? IT's clear we cannot get away with just using > service@name_from_dns. We can either use > service@name_typed_by_user, requiring any replicated service to > just deal internally or we could use some new name type. In the case of LDAP the service name may often not be derived from any information typed in by the user (e.g., where LDAP is used by a name service switch). The domain name could come from local configuration or from user context (e.g., from a domain-qualified username). If we're using a domain-based name type with host instances the hostname can safely come from an SRV record. See above. > 2) Do we want to say anything about this in the base spec? We aren't > designing an API, but we may want to give general guidelines about > what bits of information SASL mechanisms can assume they can get > from an application, to prevent people designing mechanisms in the > future that make unreasonable requirements of multi-mechanisms > implementations. IMO it would be nice to specify a domain based name type for the GSS-API and the various existing GSS-API mechanisms. Then amend SASL to require support for domain-based naming where applications request it and where the SASL mechanisms support it. Cheers, Nico -- From owner-ietf-sasl Thu Aug 21 13:50:33 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoXqt056567 for ; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LKoXjB056566 for ietf-sasl-bks; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoWqt056561 for ; Thu, 21 Aug 2003 13:50:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8A95D151D10; Thu, 21 Aug 2003 16:50:34 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> From: Sam Hartman Date: Thu, 21 Aug 2003 16:50:34 -0400 In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> (Nicolas Williams's message of "Thu, 21 Aug 2003 13:05:21 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing I think I can do with my chair hat on is suggest what you'd need to do if you want to make a change to the SASL GSSAPI spec. Obviously you'd need to get consensus. But it seems that you would need to specify how the SASL GSSAPI spec should choose the GSSAPI name it uses, and how it works with GSSAPI mechanisms that do not support any new name types you introduce. Then you would need to fully describe interoperability considerations, looking at applications written to the old SASL GSSAPI mechanisms as well as old implementations of the SASL GSSAPI mechanisms. Then you need to convince people that your proposed changes are acceptable. From owner-ietf-sasl Thu Aug 21 15:18:59 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIxqt059983 for ; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMIwFi059982 for ietf-sasl-bks; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIvqt059975 for ; Thu, 21 Aug 2003 15:18:57 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7LMMgn23852; Thu, 21 Aug 2003 16:22:42 -0600 From: Steve Hole Date: Thu, 21 Aug 2003 16:22:42 -0700 To: Nicolas Williams Subject: Re: GSSAPI and domain-based names Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7LMIvqt059977 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams wrote: > If we go the route of defining a new GSS-API name type we can actually > do a very neat trick: we can have the name encode the service name, the > domain name and, optionally, a hostname name (an instance of the domain- > based service). This would avoid the replay caching issue. > > What's the difference between domain-based service names and host-based > service names? With host-based service names, if a client has to lookup > what servers are associated with a domain-wide infrastructure/cluster, > the resulting principal names won't reflect the domain/cluster > association, and if the lookup is not secure, well that's a problem. > With domain-based names the client makes sure that the name of the > domain/cluster it's interested in is part of the principal name and so > binds the service principal name, no matter how the servers may be > found, to that domain name. Could you please work up an example of this Nico -- say a three system load balanced HTTP cluster? I'm having a hard time understanding exactly when the name resolution is going to occur and what kerberos principals will be bound. Sorry for being thick )-: Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 From owner-ietf-sasl Thu Aug 21 15:28:58 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSwqt061282 for ; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMSvA4061279 for ietf-sasl-bks; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSvqt061272 for ; Thu, 21 Aug 2003 15:28:57 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7LMSsIh024890; Thu, 21 Aug 2003 16:28:59 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LMSrcm021901; Thu, 21 Aug 2003 16:28:54 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LMPOQx003053; Thu, 21 Aug 2003 15:25:25 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LMPOmc003052; Thu, 21 Aug 2003 15:25:24 -0700 (PDT) Date: Thu, 21 Aug 2003 15:25:24 -0700 From: Nicolas Williams To: Steve Hole Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > wrote: > > > If we go the route of defining a new GSS-API name type we can actually > > do a very neat trick: we can have the name encode the service name, the > > domain name and, optionally, a hostname name (an instance of the domain- > > based service). This would avoid the replay caching issue. > > > > What's the difference between domain-based service names and host-based > > service names? With host-based service names, if a client has to lookup > > what servers are associated with a domain-wide infrastructure/cluster, > > the resulting principal names won't reflect the domain/cluster > > association, and if the lookup is not secure, well that's a problem. > > With domain-based names the client makes sure that the name of the > > domain/cluster it's interested in is part of the principal name and so > > binds the service principal name, no matter how the servers may be > > found, to that domain name. > > > Could you please work up an example of this Nico -- say a three system > load balanced HTTP cluster? I'm having a hard time understanding exactly > when the name resolution is going to occur and what kerberos principals > will be bound. > > Sorry for being thick )-: NP :) For a load balanced system one would have to use a principal that is shared throughout the cluster (that means sharing the rcache too, for Kerberos). So the principal name would be just service@domain or service@clustername. For non-cluster domain-wide services the names might be of the form service@domain@host_instance. I.e., the syntax for domain-based names might be "@" [ "@" ] Where you can share a principal across multiple hosts you'd not use the optional hostname instance part. Cheers, Nico -- From owner-ietf-sasl Thu Aug 21 16:15:27 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFRqt064975 for ; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LNFRbu064974 for ietf-sasl-bks; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFPqt064946 for ; Thu, 21 Aug 2003 16:15:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:23 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Aug 2003 16:15:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:43 -0700 Content-class: urn:content-classes:message Subject: RE: GSSAPI and domain-based names MIME-Version: 1.0 Date: Thu, 21 Aug 2003 16:15:17 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C367FF.6934DF60" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE246044916D6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: GSSAPI and domain-based names thread-index: AcNoNtyiQi48x7mOQYKjJGm642xXPQAAHN8A From: "Paul Leach" To: "Nicolas Williams" , "Steve Hole" Cc: "Sam Hartman" , X-OriginalArrivalTime: 21 Aug 2003 23:15:43.0370 (UTC) FILETIME=[24F16EA0:01C3683A] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There is lots of implemented art here at MSFT on principal names for replicated services. I'll attempt a brief intro. We use "service-type/service-instance/service-name" as the principal name. The service type might (and is, for Active Directory) "ldap". The service instance is the host an instance is running on -- "ad1.microsoft.com" might the the host for one instance of AD. The service-name might be "microsoft.com" for the LDAP service for Microsoft. (Microsoft's is actually a hierarchy of LDAP naming contexts, but this might be a real enough example for a smaller company.) The overall service principal name (SPN) for this example would thus be: "ldap/ad1.microsoft.com/microsoft.com" -- this is what is in the "sname" field of the service ticket. In the case that a single host runs multiple instances of a service, the above is elaborated a little bit. The service-instance is "service-host:instance-within-host". The instance with a host could be the port number of the separate instance, or it could be anything the application protocol chooses. (In fact, the whole "service-instance" is just a convention of the application protocol -- a UUID would work just fine.) The way our clients of replicated services work is that they look up SRV records for "service-name" -- in the above example, they might have looked up _ldap._tcp.microsoft.com and gotten back "ad1.microsoft.com" and "ad2.microsoft.com" and picked the first one. Note that the lookup does not have to be secure -- a DNS spoofing attack that returned "ad3.microsoft.com" as a SRV record would not be backed up by an entry in the KDC account database with a key that the attacker knew unless the KDC administrator had entered it there, thus attesting to the fact that it was a legitimate LDAP server for the "microsoft.com" domain. (If no SRV records are found, then A records are looked up, and if found, the form "service-type/service-host" is used. Again, if multiple instances on a host are allowed, then "service-type/service-host:instance-within-host" will enable that.) We use this convention polymorphically across all our GSSAPI (aka SSPI) providers that do mutual authentication. Not all of them are full function, however. > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Nicolas Williams > Sent: Thursday, August 21, 2003 3:25 PM > To: Steve Hole > Cc: Sam Hartman; ietf-sasl@imc.org > Subject: Re: GSSAPI and domain-based names > > > On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > > wrote: > > > > > If we go the route of defining a new GSS-API name type we can > > > actually do a very neat trick: we can have the name encode the > > > service name, the domain name and, optionally, a hostname > name (an > > > instance of the domain- based service). This would avoid > the replay caching issue. > > > > > > What's the difference between domain-based service names and > > > host-based service names? With host-based service names, if a > > > client has to lookup what servers are associated with a > domain-wide > > > infrastructure/cluster, the resulting principal names > won't reflect > > > the domain/cluster association, and if the lookup is not > secure, well that's a problem. > > > With domain-based names the client makes sure that the > name of the > > > domain/cluster it's interested in is part of the > principal name and > > > so binds the service principal name, no matter how the > servers may > > > be found, to that domain name. > > > > > > Could you please work up an example of this Nico -- say a > three system > > load balanced HTTP cluster? I'm having a hard time > understanding exactly > > when the name resolution is going to occur and what kerberos > > principals will be bound. > > > > Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal > that is shared throughout the cluster (that means sharing the > rcache too, for Kerberos). So the principal name would be > just service@domain or service@clustername. > > For non-cluster domain-wide services the names might be of > the form service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd > not use the optional hostname instance part. > > Cheers, > > Nico > -- > > ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCh1jglcA AwAsWZEwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzA0MjgwOTMwMTBa Fw0wNDA0MjcwOTMwMTBaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK8q3dHN aRbyzj0hnINinZSuRGGEY0WpOUMpy0dgklY0FW913oCP62W2vgvmKcxbDqA5yPAKJod/TkbYRPlY FDtfnZdD9kc11+oxtd8zGMKGx8UV4Chyc9pfXBpwzrSblVEREQ3XrP4k5fUDNoYSzknxuiaA+avi hn2o3kBQzaeNAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEBMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFLbRfFiHr8C4PpvhKuqQTBEmysTEMB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAehivR7RM+wxHRKjow7JvhVuZ5Gcj7U0mCIZxjwYfpkvuwf2J AhHrDivfHJB1dc0ye3qL8iWU26BsvjCxGVnlireU/y51DreLtWY7744+zlXvTPqbmhkn9v+I3ROL NVTQDp0jr5F700gRXN5xuNoHxKCpXlaaHg6jbUF/VuroAzEwggbsMIIGVaADAgECAgpxnD1XAAMA LVX+MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwNTE0MTgwMTI3WhcN MDQwNTEzMTgwMTI3WjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1ZQ34QuiBnnKuzneDRusrIzDH kzkrFkBpCVq5Gv/CORZ80/TQ/PgekPMwb2xuIH9+ynLgONNX3QuP6qRQcezzfcvDsiqV9a8VXX9P sjWzjiItJpDcNCVRhAGnw500vi5GF7Iz3KsAm/XhTqXTV3De8vWi8I0Al99l4sfTRhJmpQIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQEwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFMGGfqHf0cheFty2yjOP5eYfSpYKMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAhsPDfvHwZ0VLtxIDCQFpyrbMoUsVAj7oeNco B+eHWkSWtUqWDR+QJdKfRSB/df6N8COrRS3qL35b5txq2Lf/WObF4Z/TOhou7ghxS7gSmZ9eyYIh vLXQ2FsIsQ6zdn4wx1gdHGfj0jXJYxl71UXBfmMfyYR2GapwUKQIBBw6K3swgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCh1jglcAAwAs WZEwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwODIxMjMxNTE3WjAjBgkqhkiG9w0BCQQxFgQUtWdaepSRBGVNM7y80TMHi7/z7BQwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MA0GCSqGSIb3DQEBAQUABIGAQVlVWSicsTDB jSdmqtaSsyTyjImZ8+KFfesQvaqZhQe1brj0ypVp8NlqVc6ASksaRfiVmObBFL0XTRYqXkN50baP ODp9hqCaVI4HWAkEiXqot48lO/S3W3ur+7SDznfAoMbDt2vJYfVXXSjLU75iVP/OqglubCmW7h7v njKHu/4AAAAAAAA= ------=_NextPart_000_0008_01C367FF.6934DF60-- From owner-ietf-sasl Thu Aug 21 18:38:56 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M1ctqt070876 for ; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M1ctTp070875 for ietf-sasl-bks; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7M1csqt070868 for ; Thu, 21 Aug 2003 18:38:54 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa19372; 21 Aug 2003 21:38 EDT Date: Thu, 21 Aug 2003 21:38:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <1022390000.1061516323@minbar.fac.cs.cmu.edu> In-Reply-To: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, August 21, 2003 15:25:24 -0700 Nicolas Williams wrote: >> Could you please work up an example of this Nico -- say a three system >> load balanced HTTP cluster? I'm having a hard time understanding >> exactly when the name resolution is going to occur and what kerberos >> principals will be bound. >> >> Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal that is > shared throughout the cluster (that means sharing the rcache too, for > Kerberos). So the principal name would be just service@domain or > service@clustername. > > For non-cluster domain-wide services the names might be of the form > service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd not use the > optional hostname instance part. Of course, this only describes the name syntax at the GSSAPI layer. In the case of the Kerberos mechansm, this would presumably map to principal names with more than one component, like http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach described. I'd be interested in hearing what sort of GSSAPI name types Microsoft is using that map to these principal names, if any. And I'd also like to hear whether these are truly three-component principal names, or single-component names with '/' embedded in the instance. In any case, I'm somewhat concerned as to whether defining a new GSSAPI name type is in scope for this working group. Actually, I'm more concerned that if this work happens here, we might inadvertently exclude folks who care about this issue but otherwise have no interest in SASL. As long as we make sure these folks have a chance to participate, I'm all in favor of doing this work here -- it's a real problem and I'd definitely like to see a solution. -- Jeff From owner-ietf-sasl Thu Aug 21 21:42:40 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077931 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4gemn077930 for ietf-sasl-bks; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077924 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4gb5q023783; Thu, 21 Aug 2003 21:42:37 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4gacm009185; Thu, 21 Aug 2003 22:42:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4d7Qx003219; Thu, 21 Aug 2003 21:39:07 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4d6ST003218; Thu, 21 Aug 2003 21:39:06 -0700 (PDT) Date: Thu, 21 Aug 2003 21:39:06 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030822043906.GW1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> <1022390000.1061516323@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022390000.1061516323@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 09:38:43PM -0400, Jeffrey Hutzelman wrote: > Of course, this only describes the name syntax at the GSSAPI layer. In the > case of the Kerberos mechansm, this would presumably map to principal names > with more than one component, like > http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach > described. Of course, I was only describing the proposed GSS-API name syntax. > I'd be interested in hearing what sort of GSSAPI name types Microsoft is > using that map to these principal names, if any. And I'd also like to hear > whether these are truly three-component principal names, or > single-component names with '/' embedded in the instance. Me too. > In any case, I'm somewhat concerned as to whether defining a new GSSAPI > name type is in scope for this working group. Actually, I'm more concerned > that if this work happens here, we might inadvertently exclude folks who > care about this issue but otherwise have no interest in SASL. As long as > we make sure these folks have a chance to participate, I'm all in favor of > doing this work here -- it's a real problem and I'd definitely like to see > a solution. No kidding. I think that given the lack of a CAT WG (or KITTEN, as you've suggested - no I haven't come up with something that it could be the acronym for) we can do GSS-API work elsewhere, but we ought to give other WGs heads ups, and even Last-Call in multiple WGs. E.g., the NFSv4 WG I-D on CCM - the Channel Conjunction Mechanism. Nico -- From owner-ietf-sasl Thu Aug 21 21:52:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078229 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4qgmj078228 for ietf-sasl-bks; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078223 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4qe5q028873; Thu, 21 Aug 2003 21:52:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4qebO006197; Thu, 21 Aug 2003 22:52:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4nBQx003229; Thu, 21 Aug 2003 21:49:11 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4nArN003228; Thu, 21 Aug 2003 23:49:10 -0500 (CDT) Date: Thu, 21 Aug 2003 23:49:10 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: SRP Mechanism & GSS-API domain-based names (was Re: GSSAPI and domain-based names) Message-ID: <20030822044910.GK19235@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SRP GSS-API mechanism that's been discussed here is one that could use domain-based names. As we've seen, though SRP itself provides for mutual authentication, the proposed mechanism does not deal with acceptor principal naming, therefore it can't be said to provide mutual authentication with any acceptor name other than the anonymous name. This can be addressed by salting the password/verifier with the name of the acceptor principal, but this would mean generating a verifier per-{user host} tuple, which does not scale well. So an SRP mechanism could benefit from domain-based names in environments where verifiers are generated per-{user service} or {user domain} tuples, or any such tuple that is less numerous than {user host} tuples are. That is, one could get away with fewer verifiers per-user by using domain-based names. This possibility complicates the way in which an application decides which name type to use for an acceptor, but not much. As I've said, I think LDAP ought to use domain-based names, but existing implementations may not, so for interop any implementation that supports domain-based names will also have to be configurable to use host-based names. Such a configuration parameter might be a per-mechanism parameter (and one might even have a per-domain configuration too). I hope this and my previous post answers Sam's question about when to use which name type. Cheers, Nico -- From owner-ietf-sasl Tue Aug 26 18:01:29 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Sgc096991 for ; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R11Srv096990 for ietf-sasl-bks; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Rgc096983 for ; Tue, 26 Aug 2003 18:01:27 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7R11NkU026558; Tue, 26 Aug 2003 21:01:24 -0400 (EDT) Message-ID: <3F4C02DE.5040400@oceana.com> Date: Tue, 26 Aug 2003 21:01:18 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP mailing list , SASL mailing list Subject: NTLM authentication documentation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Resurrecting a badly beaten horse... Is there any interest in having NTLM authentication (as a SASL mech and possibly as an HTTP mech) documented as an Informational RFC? I believe I have enough existing documentation (Eric Glass' http://davenport.sourceforge.net/ntlm.html being the best) and enough implementation experience writing the CMU SASL NTLM plugin to write a fairly complete document. I would probably use Eric's documentation of the message formats and the algorithms for the password hashes from Paul Leach's CIFS draft. I'm especially interested in hearing from the Microsoft folks w.r.t. any IPR problems. Since Paul has already made the algorithms available in an I-D, I guess the only outstanding issue would be the message formats. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-ietf-sasl Wed Aug 27 15:40:43 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMehgc089461 for ; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RMeh12089460 for ietf-sasl-bks; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMeggc089450 for ; Wed, 27 Aug 2003 15:40:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7RMeeUk016536 for ; Wed, 27 Aug 2003 15:40:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RMeacm007676 for ; Wed, 27 Aug 2003 16:40:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7RMb3Qx007721 for ; Wed, 27 Aug 2003 15:37:03 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RMb2Ll007720 for ietf-sasl@imc.org; Wed, 27 Aug 2003 17:37:02 -0500 (CDT) Date: Wed, 27 Aug 2003 17:37:02 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: GSS-SPNEGO and relative mechanism strengths Message-ID: <20030827223702.GS19235@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL GSS-SPNEGO mechanism, on the client side, needs to know the mechlist that the client got from the server and the SSF values associated with each GSS-API mechanism available to decide which mechanisms to negotiate. (See section 4 of draft-ietf-cat-sasl-gssapi-05.txt.) How can a SASL GSS-SPNEGO mechanism client-side implementation determine the SSF values that would be associated with each GSS-API mechanism without hardcoding mechanism OIDs and SSF values? A GSS-API extension, GSS_Inquire_mech(), say, that allows applications to determine the set of features supported by a given mechanism would help. The relative strengths of GSS-API mechanisms that support confidentiality (SSF values > 1) can't really be determined statically, or even dynamically (it is not even possible to determine what QoPs will be available with what mech until a context is established), so ideally, if GSS_Inquire_mech() says anything about mechanism strength at all then that should be configurable. (And if GSS_Inquire_mech() has nothing at all to say about mech strength, then truly generic SASL GSS-SPNEGO mechanism client-side implementation might have to assume SSF values for mechs that provide confidentiality, perhaps a single value for all such GSS-API mechs.) Cheers, Nico -- From owner-ietf-sasl Fri Aug 29 07:06:07 2003 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE67gc078952 for ; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TE67WV078951 for ietf-sasl-bks; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE65gc078926 for ; Fri, 29 Aug 2003 07:06:05 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7TE61X0024154 for ; Fri, 29 Aug 2003 10:06:01 -0400 (EDT) Message-ID: <3F4F5E46.5010101@oceana.com> Date: Fri, 29 Aug 2003 10:08:06 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just submitted the following document: ftp://ftp.oceana.com/pub/drafts/draft-murchison-sasl-login-00.txt This is an attempt to document the intended and currently deployed functionality of the obsolete LOGIN SASL mechanism. If anyone is aware of additional/different deployed behavior, we'd be interested in hearing about it. We are aware that some servers allow the username to be sent as an initial response (for those protocol that support it), but we haven't yet decided if we want to document that. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE67gc078952 for ; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TE67WV078951 for ietf-sasl-bks; Fri, 29 Aug 2003 07:06:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TE65gc078926 for ; Fri, 29 Aug 2003 07:06:05 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7TE61X0024154 for ; Fri, 29 Aug 2003 10:06:01 -0400 (EDT) Message-ID: <3F4F5E46.5010101@oceana.com> Date: Fri, 29 Aug 2003 10:08:06 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: SASL mailing list Subject: draft-murchison-sasl-login-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just submitted the following document: ftp://ftp.oceana.com/pub/drafts/draft-murchison-sasl-login-00.txt This is an attempt to document the intended and currently deployed functionality of the obsolete LOGIN SASL mechanism. If anyone is aware of additional/different deployed behavior, we'd be interested in hearing about it. We are aware that some servers allow the username to be sent as an initial response (for those protocol that support it), but we haven't yet decided if we want to document that. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMehgc089461 for ; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RMeh12089460 for ietf-sasl-bks; Wed, 27 Aug 2003 15:40:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RMeggc089450 for ; Wed, 27 Aug 2003 15:40:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7RMeeUk016536 for ; Wed, 27 Aug 2003 15:40:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RMeacm007676 for ; Wed, 27 Aug 2003 16:40:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7RMb3Qx007721 for ; Wed, 27 Aug 2003 15:37:03 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RMb2Ll007720 for ietf-sasl@imc.org; Wed, 27 Aug 2003 17:37:02 -0500 (CDT) Date: Wed, 27 Aug 2003 17:37:02 -0500 From: Nicolas Williams To: ietf-sasl@imc.org Subject: GSS-SPNEGO and relative mechanism strengths Message-ID: <20030827223702.GS19235@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SASL GSS-SPNEGO mechanism, on the client side, needs to know the mechlist that the client got from the server and the SSF values associated with each GSS-API mechanism available to decide which mechanisms to negotiate. (See section 4 of draft-ietf-cat-sasl-gssapi-05.txt.) How can a SASL GSS-SPNEGO mechanism client-side implementation determine the SSF values that would be associated with each GSS-API mechanism without hardcoding mechanism OIDs and SSF values? A GSS-API extension, GSS_Inquire_mech(), say, that allows applications to determine the set of features supported by a given mechanism would help. The relative strengths of GSS-API mechanisms that support confidentiality (SSF values > 1) can't really be determined statically, or even dynamically (it is not even possible to determine what QoPs will be available with what mech until a context is established), so ideally, if GSS_Inquire_mech() says anything about mechanism strength at all then that should be configurable. (And if GSS_Inquire_mech() has nothing at all to say about mech strength, then truly generic SASL GSS-SPNEGO mechanism client-side implementation might have to assume SSF values for mechs that provide confidentiality, perhaps a single value for all such GSS-API mechs.) Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Sgc096991 for ; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R11Srv096990 for ietf-sasl-bks; Tue, 26 Aug 2003 18:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R11Rgc096983 for ; Tue, 26 Aug 2003 18:01:27 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (ny-kenton4a-a-83.buf.adelphia.net [24.51.28.83]) (authenticated bits=0) by eagle.oceana.com (8.12.10.Beta2/8.12.10.Beta2) with ESMTP id h7R11NkU026558; Tue, 26 Aug 2003 21:01:24 -0400 (EDT) Message-ID: <3F4C02DE.5040400@oceana.com> Date: Tue, 26 Aug 2003 21:01:18 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP mailing list , SASL mailing list Subject: NTLM authentication documentation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Resurrecting a badly beaten horse... Is there any interest in having NTLM authentication (as a SASL mech and possibly as an HTTP mech) documented as an Informational RFC? I believe I have enough existing documentation (Eric Glass' http://davenport.sourceforge.net/ntlm.html being the best) and enough implementation experience writing the CMU SASL NTLM plugin to write a fairly complete document. I would probably use Eric's documentation of the message formats and the algorithms for the password hashes from Paul Leach's CIFS draft. I'm especially interested in hearing from the Microsoft folks w.r.t. any IPR problems. Since Paul has already made the algorithms available in an I-D, I guess the only outstanding issue would be the message formats. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078229 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4qgmj078228 for ietf-sasl-bks; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4qgqt078223 for ; Thu, 21 Aug 2003 21:52:42 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4qe5q028873; Thu, 21 Aug 2003 21:52:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4qebO006197; Thu, 21 Aug 2003 22:52:40 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4nBQx003229; Thu, 21 Aug 2003 21:49:11 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4nArN003228; Thu, 21 Aug 2003 23:49:10 -0500 (CDT) Date: Thu, 21 Aug 2003 23:49:10 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: SRP Mechanism & GSS-API domain-based names (was Re: GSSAPI and domain-based names) Message-ID: <20030822044910.GK19235@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The SRP GSS-API mechanism that's been discussed here is one that could use domain-based names. As we've seen, though SRP itself provides for mutual authentication, the proposed mechanism does not deal with acceptor principal naming, therefore it can't be said to provide mutual authentication with any acceptor name other than the anonymous name. This can be addressed by salting the password/verifier with the name of the acceptor principal, but this would mean generating a verifier per-{user host} tuple, which does not scale well. So an SRP mechanism could benefit from domain-based names in environments where verifiers are generated per-{user service} or {user domain} tuples, or any such tuple that is less numerous than {user host} tuples are. That is, one could get away with fewer verifiers per-user by using domain-based names. This possibility complicates the way in which an application decides which name type to use for an acceptor, but not much. As I've said, I think LDAP ought to use domain-based names, but existing implementations may not, so for interop any implementation that supports domain-based names will also have to be configurable to use host-based names. Such a configuration parameter might be a per-mechanism parameter (and one might even have a per-domain configuration too). I hope this and my previous post answers Sam's question about when to use which name type. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077931 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M4gemn077930 for ietf-sasl-bks; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M4geqt077924 for ; Thu, 21 Aug 2003 21:42:40 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7M4gb5q023783; Thu, 21 Aug 2003 21:42:37 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7M4gacm009185; Thu, 21 Aug 2003 22:42:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7M4d7Qx003219; Thu, 21 Aug 2003 21:39:07 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7M4d6ST003218; Thu, 21 Aug 2003 21:39:06 -0700 (PDT) Date: Thu, 21 Aug 2003 21:39:06 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030822043906.GW1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> <1022390000.1061516323@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022390000.1061516323@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 09:38:43PM -0400, Jeffrey Hutzelman wrote: > Of course, this only describes the name syntax at the GSSAPI layer. In the > case of the Kerberos mechansm, this would presumably map to principal names > with more than one component, like > http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach > described. Of course, I was only describing the proposed GSS-API name syntax. > I'd be interested in hearing what sort of GSSAPI name types Microsoft is > using that map to these principal names, if any. And I'd also like to hear > whether these are truly three-component principal names, or > single-component names with '/' embedded in the instance. Me too. > In any case, I'm somewhat concerned as to whether defining a new GSSAPI > name type is in scope for this working group. Actually, I'm more concerned > that if this work happens here, we might inadvertently exclude folks who > care about this issue but otherwise have no interest in SASL. As long as > we make sure these folks have a chance to participate, I'm all in favor of > doing this work here -- it's a real problem and I'd definitely like to see > a solution. No kidding. I think that given the lack of a CAT WG (or KITTEN, as you've suggested - no I haven't come up with something that it could be the acronym for) we can do GSS-API work elsewhere, but we ought to give other WGs heads ups, and even Last-Call in multiple WGs. E.g., the NFSv4 WG I-D on CCM - the Channel Conjunction Mechanism. Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7M1ctqt070876 for ; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7M1ctTp070875 for ietf-sasl-bks; Thu, 21 Aug 2003 18:38:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7M1csqt070868 for ; Thu, 21 Aug 2003 18:38:54 -0700 (PDT) (envelope-from jhutz@cmu.edu) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa19372; 21 Aug 2003 21:38 EDT Date: Thu, 21 Aug 2003 21:38:43 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <1022390000.1061516323@minbar.fac.cs.cmu.edu> In-Reply-To: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821222524.GU1319@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thursday, August 21, 2003 15:25:24 -0700 Nicolas Williams wrote: >> Could you please work up an example of this Nico -- say a three system >> load balanced HTTP cluster? I'm having a hard time understanding >> exactly when the name resolution is going to occur and what kerberos >> principals will be bound. >> >> Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal that is > shared throughout the cluster (that means sharing the rcache too, for > Kerberos). So the principal name would be just service@domain or > service@clustername. > > For non-cluster domain-wide services the names might be of the form > service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd not use the > optional hostname instance part. Of course, this only describes the name syntax at the GSSAPI layer. In the case of the Kerberos mechansm, this would presumably map to principal names with more than one component, like http/fully.qualified.host.name/cluster.name@KERBEROS.REALM, as Paul Leach described. I'd be interested in hearing what sort of GSSAPI name types Microsoft is using that map to these principal names, if any. And I'd also like to hear whether these are truly three-component principal names, or single-component names with '/' embedded in the instance. In any case, I'm somewhat concerned as to whether defining a new GSSAPI name type is in scope for this working group. Actually, I'm more concerned that if this work happens here, we might inadvertently exclude folks who care about this issue but otherwise have no interest in SASL. As long as we make sure these folks have a chance to participate, I'm all in favor of doing this work here -- it's a real problem and I'd definitely like to see a solution. -- Jeff Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFRqt064975 for ; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LNFRbu064974 for ietf-sasl-bks; Thu, 21 Aug 2003 16:15:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LNFPqt064946 for ; Thu, 21 Aug 2003 16:15:25 -0700 (PDT) (envelope-from paulle@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:23 -0700 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Aug 2003 16:15:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:26 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Aug 2003 16:15:43 -0700 Content-class: urn:content-classes:message Subject: RE: GSSAPI and domain-based names MIME-Version: 1.0 Date: Thu, 21 Aug 2003 16:15:17 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C367FF.6934DF60" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE246044916D6@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: GSSAPI and domain-based names thread-index: AcNoNtyiQi48x7mOQYKjJGm642xXPQAAHN8A From: "Paul Leach" To: "Nicolas Williams" , "Steve Hole" Cc: "Sam Hartman" , X-OriginalArrivalTime: 21 Aug 2003 23:15:43.0370 (UTC) FILETIME=[24F16EA0:01C3683A] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There is lots of implemented art here at MSFT on principal names for replicated services. I'll attempt a brief intro. We use "service-type/service-instance/service-name" as the principal name. The service type might (and is, for Active Directory) "ldap". The service instance is the host an instance is running on -- "ad1.microsoft.com" might the the host for one instance of AD. The service-name might be "microsoft.com" for the LDAP service for Microsoft. (Microsoft's is actually a hierarchy of LDAP naming contexts, but this might be a real enough example for a smaller company.) The overall service principal name (SPN) for this example would thus be: "ldap/ad1.microsoft.com/microsoft.com" -- this is what is in the "sname" field of the service ticket. In the case that a single host runs multiple instances of a service, the above is elaborated a little bit. The service-instance is "service-host:instance-within-host". The instance with a host could be the port number of the separate instance, or it could be anything the application protocol chooses. (In fact, the whole "service-instance" is just a convention of the application protocol -- a UUID would work just fine.) The way our clients of replicated services work is that they look up SRV records for "service-name" -- in the above example, they might have looked up _ldap._tcp.microsoft.com and gotten back "ad1.microsoft.com" and "ad2.microsoft.com" and picked the first one. Note that the lookup does not have to be secure -- a DNS spoofing attack that returned "ad3.microsoft.com" as a SRV record would not be backed up by an entry in the KDC account database with a key that the attacker knew unless the KDC administrator had entered it there, thus attesting to the fact that it was a legitimate LDAP server for the "microsoft.com" domain. (If no SRV records are found, then A records are looked up, and if found, the form "service-type/service-host" is used. Again, if multiple instances on a host are allowed, then "service-type/service-host:instance-within-host" will enable that.) We use this convention polymorphically across all our GSSAPI (aka SSPI) providers that do mutual authentication. Not all of them are full function, however. > -----Original Message----- > From: owner-ietf-sasl@mail.imc.org > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Nicolas Williams > Sent: Thursday, August 21, 2003 3:25 PM > To: Steve Hole > Cc: Sam Hartman; ietf-sasl@imc.org > Subject: Re: GSSAPI and domain-based names > > > On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > > wrote: > > > > > If we go the route of defining a new GSS-API name type we can > > > actually do a very neat trick: we can have the name encode the > > > service name, the domain name and, optionally, a hostname > name (an > > > instance of the domain- based service). This would avoid > the replay caching issue. > > > > > > What's the difference between domain-based service names and > > > host-based service names? With host-based service names, if a > > > client has to lookup what servers are associated with a > domain-wide > > > infrastructure/cluster, the resulting principal names > won't reflect > > > the domain/cluster association, and if the lookup is not > secure, well that's a problem. > > > With domain-based names the client makes sure that the > name of the > > > domain/cluster it's interested in is part of the > principal name and > > > so binds the service principal name, no matter how the > servers may > > > be found, to that domain name. > > > > > > Could you please work up an example of this Nico -- say a > three system > > load balanced HTTP cluster? I'm having a hard time > understanding exactly > > when the name resolution is going to occur and what kerberos > > principals will be bound. > > > > Sorry for being thick )-: > > NP :) > > For a load balanced system one would have to use a principal > that is shared throughout the cluster (that means sharing the > rcache too, for Kerberos). So the principal name would be > just service@domain or service@clustername. > > For non-cluster domain-wide services the names might be of > the form service@domain@host_instance. > > I.e., the syntax for domain-based names might be > > "@" [ "@" ] > > Where you can share a principal across multiple hosts you'd > not use the optional hostname instance part. > > Cheers, > > Nico > -- > > ------=_NextPart_000_0008_01C367FF.6934DF60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIfBjCCA7Ew ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0 WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw 1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50 ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4 MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9 Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBqgwggYRoAMCAQICCh1jglcA AwAsWZEwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzA0MjgwOTMwMTBa Fw0wNDA0MjcwOTMwMTBaMIGwMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MRAw DgYDVQQLEwdJTS1TZWxmMRcwFQYDVQQLEw5MaWdodGx5TWFuYWdlZDERMA8GA1UECxMITG93VENP LUUxEzARBgNVBAMTClBhdWwgTGVhY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK8q3dHN aRbyzj0hnINinZSuRGGEY0WpOUMpy0dgklY0FW913oCP62W2vgvmKcxbDqA5yPAKJod/TkbYRPlY FDtfnZdD9kc11+oxtd8zGMKGx8UV4Chyc9pfXBpwzrSblVEREQ3XrP4k5fUDNoYSzknxuiaA+avi hn2o3kBQzaeNAgMBAAGjggQrMIIEJzALBgNVHQ8EBAMCB4AwPgYJKwYBBAGCNxUHBDEwLwYnKwYB BAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEBMBMGA1UdJQQMMAoGCCsG AQUFBwMEMC0GA1UdIAQmMCQwIgYgKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phUBgxEwGwYJ KwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcUAgOgHAwacGF1 bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29mdC5jb20wHQYD VR0OBBYEFLbRfFiHr8C4PpvhKuqQTBEmysTEMB8GA1UdIwQYMBaAFIvRzWHx6a+OvJHQQOopv+Yu hUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5UREVWJTIwSVNT VUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0 LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlz dHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20v TlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hpY2EzLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js MIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NOPU5UREVWJTIw SVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MHgGCCsG AQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xs L1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMlMjBDQSgzKS5j cnQwDQYJKoZIhvcNAQEFBQADgYEAehivR7RM+wxHRKjow7JvhVuZ5Gcj7U0mCIZxjwYfpkvuwf2J AhHrDivfHJB1dc0ye3qL8iWU26BsvjCxGVnlireU/y51DreLtWY7744+zlXvTPqbmhkn9v+I3ROL NVTQDp0jr5F700gRXN5xuNoHxKCpXlaaHg6jbUF/VuroAzEwggbsMIIGVaADAgECAgpxnD1XAAMA LVX+MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAM BgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0EwHhcNMDMwNTE0MTgwMTI3WhcN MDQwNTEzMTgwMTI3WjCB3TETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1p Y3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEQMA4G A1UECxMHSU0tU2VsZjEXMBUGA1UECxMOTGlnaHRseU1hbmFnZWQxETAPBgNVBAsTCExvd1RDTy1F MRMwEQYDVQQDEwpQYXVsIExlYWNoMSswKQYJKoZIhvcNAQkBFhxwYXVsbGVAd2luZG93cy5taWNy b3NvZnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1ZQ34QuiBnnKuzneDRusrIzDH kzkrFkBpCVq5Gv/CORZ80/TQ/PgekPMwb2xuIH9+ynLgONNX3QuP6qRQcezzfcvDsiqV9a8VXX9P sjWzjiItJpDcNCVRhAGnw500vi5GF7Iz3KsAm/XhTqXTV3De8vWi8I0Al99l4sfTRhJmpQIDAQAB o4IEQjCCBD4wCwYDVR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzA+BgkrBgEEAYI3FQcEMTAvBicrBgEE AYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFYenvuIJjrGt8U0CAXgCAQEwEwYDVR0lBAwwCgYIKwYB BQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDBTBgNVHREETDBKoCoGCisGAQQBgjcU AgOgHAwacGF1bGxlQG50ZGV2Lm1pY3Jvc29mdC5jb22BHHBhdWxsZUB3aW5kb3dzLm1pY3Jvc29m dC5jb20wHQYDVR0OBBYEFMGGfqHf0cheFty2yjOP5eYfSpYKMB8GA1UdIwQYMBaAFIvRzWHx6a+O vJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9sZGFwOi8vL0NOPU5U REVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9 bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRldi5jb3JwLm1pY3Jv c29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3JshkxodHRwOi8vd2hp Y2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSVNTVUUzJTIw Q0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKGgbhsZGFwOi8vL0NO PU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQs REM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D ZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBJU1NVRTMl MjBDQSgzKS5jcnQwDQYJKoZIhvcNAQEFBQADgYEAhsPDfvHwZ0VLtxIDCQFpyrbMoUsVAj7oeNco B+eHWkSWtUqWDR+QJdKfRSB/df6N8COrRS3qL35b5txq2Lf/WObF4Z/TOhou7ghxS7gSmZ9eyYIh vLXQ2FsIsQ6zdn4wx1gdHGfj0jXJYxl71UXBfmMfyYR2GapwUKQIBBw6K3swgggbMIIHA6ADAgEC AgooxudyAAEAAAA1MA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRkwFwYDVQQDExBOVERFViBTQSBSb290IENBMB4XDTAyMTAx MDE2MzMwMFoXDTA1MTAxMDE2NDMwMFowYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29m dDEOMAwGA1UECxMFTnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0 ZSBXaGljYTIwggG3MIIBKwYHKoZIzjgEATCCAR4CgYEA+hLPe7uYsHmuGUfkITkBqWsGXo22y369 ks09E+EjwAGs24cphaVHqFZ3+KQ/kgyANCvsNSkmut2/hnZPWkk9UQcjEK5rcdNf+j5dUZNld0G/ jH46Ecua3XUpxPL0H7S2mDemwkLib61o41pt37LD8QH0Cg+V0Z0egYEFIY50AuMCFQCYT5Q9snVa 1ekUrZTCYzob/OjrQwKBgGbKD33vFBA+cKvgitrGpSLmxdey9I++KbA79QQXEnACJZLw5S6e+eHs Z3T+xwPlg2RUCxtFgX5c2DJhUKxi6wLUsfwO+g7OrgfPyWD0r/aQDzS/ZKSvgMfUQUzYkbcn0dur frYOT2LxXocBkQD8/yQH38n5wjUuheVa1/Dm5oKYA4GFAAKBgQCiStJWJMhC3tkbRi2OvYYtxyrl tPMOyZR1E5DPWqL15vlw4hhrZheATpyZlMggU4vHps92BvBlICw58FCh9Cgsbe8l5BwawD++PvDO ObOVoiZiwEX05lEUqXsLev9MtKEdcFNAejXrNwIa4sJeFC86yuMmGUq+G9Hl8yY2k4riOaOCBFMw ggRPMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOK+A3DViyDSQURqr+bId3FaJQAfMAsGA1Ud DwQEAwIBhjASBgkrBgEEAYI3FQEEBQIDBAAFMCMGCSsGAQQBgjcVAgQWBBTWUig3WSHjbYXiEmot Y22qaLxrQDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBSIyc2cnDoigOrk LdoVRy/1+8S8mzCCAZkGA1UdHwSCAZAwggGMMIIBiKCCAYSgggGAhoHZbGRhcDovLy9DTj1OVERF ViUyMFNBJTIwUm9vdCUyMENBKDEpLENOPXdoaWNhc2Fyb290Y2EsQ049Q0RQLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9v YmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIZRaHR0cDovL3doaWNhd2ViLm50ZGV2LmNv cnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3Js hk9odHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW JTIwU0ElMjBSb290JTIwQ0EoMSkuY3JsMIIB6QYIKwYBBQUHAQEEggHbMIIB1zCByAYIKwYBBQUH MAKGgbtsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUy MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9 Y29ycCxEQz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIGEBggrBgEFBQcwAoZ4aHR0cDovL3doaWNhd2ViLm50ZGV2 LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5t aWNyb3NvZnQuY29tX05UREVWJTIwU0ElMjBSb290JTIwQ0EoMSkuY3J0MIGCBggrBgEFBQcwAoZ2 aHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC93aGljYXNh cm9vdGNhLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMFNBJTIwUm9vdCUyMENBKDEp LmNydDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQEFBQADggEBADTCZCUZvE/CF5YX7SiP y/WGMFtXXeCYEr/Y7LSrY5yAL+j4ZKQor7lLfrE7FO9UgGKjfs+LqO0kjxad47041wtArk0e5RXe P0UW0IzZOctur84ke76sqtggFFgCOffLqhY9plCcfVSDpBrngAISXVuhx8oEzptU2UkqcH5ZGmfB vgytdCKe+vStiuVgf5nvEQIej5on2qentxdfMQsXntj2oEFupjmR6J9YV9f43GEWlGuDC1Lou10g 84idAsbaQ+hjxBp8e9NIGPgi5LF1o353R32fU4Oc3ggpGFFiJVKnA/tqgusrcV6ViN0sQftdALar 5PjV25iA2FaXQOR/bpcxggKfMIICmwIBATBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNy b3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCh1jglcAAwAs WZEwCQYFKw4DAhoFAKCCAZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMwODIxMjMxNTE3WjAjBgkqhkiG9w0BCQQxFgQUtWdaepSRBGVNM7y80TMHi7/z7BQwZwYJ KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwaAYJKwYBBAGCNxAE MVswWTBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEY MBYGA1UEAxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MGoGCyqGSIb3DQEJEAILMVugWTBL MQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UE AxMPTlRERVYgSVNTVUUzIENBAgpxnD1XAAMALVX+MA0GCSqGSIb3DQEBAQUABIGAQVlVWSicsTDB jSdmqtaSsyTyjImZ8+KFfesQvaqZhQe1brj0ypVp8NlqVc6ASksaRfiVmObBFL0XTRYqXkN50baP ODp9hqCaVI4HWAkEiXqot48lO/S3W3ur+7SDznfAoMbDt2vJYfVXXSjLU75iVP/OqglubCmW7h7v njKHu/4AAAAAAAA= ------=_NextPart_000_0008_01C367FF.6934DF60-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSwqt061282 for ; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMSvA4061279 for ietf-sasl-bks; Thu, 21 Aug 2003 15:28:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMSvqt061272 for ; Thu, 21 Aug 2003 15:28:57 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7LMSsIh024890; Thu, 21 Aug 2003 16:28:59 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LMSrcm021901; Thu, 21 Aug 2003 16:28:54 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LMPOQx003053; Thu, 21 Aug 2003 15:25:25 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LMPOmc003052; Thu, 21 Aug 2003 15:25:24 -0700 (PDT) Date: Thu, 21 Aug 2003 15:25:24 -0700 From: Nicolas Williams To: Steve Hole Cc: Sam Hartman , ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821222524.GU1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 04:22:42PM -0700, Steve Hole wrote: > On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams > wrote: > > > If we go the route of defining a new GSS-API name type we can actually > > do a very neat trick: we can have the name encode the service name, the > > domain name and, optionally, a hostname name (an instance of the domain- > > based service). This would avoid the replay caching issue. > > > > What's the difference between domain-based service names and host-based > > service names? With host-based service names, if a client has to lookup > > what servers are associated with a domain-wide infrastructure/cluster, > > the resulting principal names won't reflect the domain/cluster > > association, and if the lookup is not secure, well that's a problem. > > With domain-based names the client makes sure that the name of the > > domain/cluster it's interested in is part of the principal name and so > > binds the service principal name, no matter how the servers may be > > found, to that domain name. > > > Could you please work up an example of this Nico -- say a three system > load balanced HTTP cluster? I'm having a hard time understanding exactly > when the name resolution is going to occur and what kerberos principals > will be bound. > > Sorry for being thick )-: NP :) For a load balanced system one would have to use a principal that is shared throughout the cluster (that means sharing the rcache too, for Kerberos). So the principal name would be just service@domain or service@clustername. For non-cluster domain-wide services the names might be of the form service@domain@host_instance. I.e., the syntax for domain-based names might be "@" [ "@" ] Where you can share a principal across multiple hosts you'd not use the optional hostname instance part. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIxqt059983 for ; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LMIwFi059982 for ietf-sasl-bks; Thu, 21 Aug 2003 15:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LMIvqt059975 for ; Thu, 21 Aug 2003 15:18:57 -0700 (PDT) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h7LMMgn23852; Thu, 21 Aug 2003 16:22:42 -0600 From: Steve Hole Date: Thu, 21 Aug 2003 16:22:42 -0700 To: Nicolas Williams Subject: Re: GSSAPI and domain-based names Cc: Sam Hartman , ietf-sasl@imc.org In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> References: <20030821200521.GP1319@binky.central.sun.com> <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Message-ID: X-Mailer: Execmail for Linux 6.0.0 alpha Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7LMIvqt059977 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 21 Aug 2003 13:05:21 -0700 Nicolas Williams wrote: > If we go the route of defining a new GSS-API name type we can actually > do a very neat trick: we can have the name encode the service name, the > domain name and, optionally, a hostname name (an instance of the domain- > based service). This would avoid the replay caching issue. > > What's the difference between domain-based service names and host-based > service names? With host-based service names, if a client has to lookup > what servers are associated with a domain-wide infrastructure/cluster, > the resulting principal names won't reflect the domain/cluster > association, and if the lookup is not secure, well that's a problem. > With domain-based names the client makes sure that the name of the > domain/cluster it's interested in is part of the principal name and so > binds the service principal name, no matter how the servers may be > found, to that domain name. Could you please work up an example of this Nico -- say a three system load balanced HTTP cluster? I'm having a hard time understanding exactly when the name resolution is going to occur and what kerberos principals will be bound. Sorry for being thick )-: Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoXqt056567 for ; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LKoXjB056566 for ietf-sasl-bks; Thu, 21 Aug 2003 13:50:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LKoWqt056561 for ; Thu, 21 Aug 2003 13:50:32 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 8A95D151D10; Thu, 21 Aug 2003 16:50:34 -0400 (EDT) To: Nicolas Williams Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> <20030821200521.GP1319@binky.central.sun.com> From: Sam Hartman Date: Thu, 21 Aug 2003 16:50:34 -0400 In-Reply-To: <20030821200521.GP1319@binky.central.sun.com> (Nicolas Williams's message of "Thu, 21 Aug 2003 13:05:21 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One thing I think I can do with my chair hat on is suggest what you'd need to do if you want to make a change to the SASL GSSAPI spec. Obviously you'd need to get consensus. But it seems that you would need to specify how the SASL GSSAPI spec should choose the GSSAPI name it uses, and how it works with GSSAPI mechanisms that do not support any new name types you introduce. Then you would need to fully describe interoperability considerations, looking at applications written to the old SASL GSSAPI mechanisms as well as old implementations of the SASL GSSAPI mechanisms. Then you need to convince people that your proposed changes are acceptable. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8tqt053905 for ; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LK8tPY053904 for ietf-sasl-bks; Thu, 21 Aug 2003 13:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LK8sqt053884 for ; Thu, 21 Aug 2003 13:08:54 -0700 (PDT) (envelope-from nw141292@binky.central.sun.com) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7LK8p5q025575; Thu, 21 Aug 2003 13:08:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LK8ocm022476; Thu, 21 Aug 2003 14:08:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h7LK5MQx002929; Thu, 21 Aug 2003 13:05:22 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7LK5LOw002928; Thu, 21 Aug 2003 13:05:21 -0700 (PDT) Date: Thu, 21 Aug 2003 13:05:21 -0700 From: Nicolas Williams To: Sam Hartman Cc: ietf-sasl@imc.org Subject: Re: GSSAPI and domain-based names Message-ID: <20030821200521.GP1319@binky.central.sun.com> References: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Aug 21, 2003 at 03:35:58PM -0400, Sam Hartman wrote: > > > A few months ago, there was a discussion on the krbdev@mit.edu mailing > list about names for GSSAPI principals. > > One conclusion from that list is that we may have an incomplete > handling of the issue in SASL. I'm going to present the issue and > step back and let Nico actually argue about solutions. :) > The problem is what GSSAPI name do you use for replicated GSSAPI > services? For some services, particularly those running on a cluster > of tightly connected machines, especially with aload balancer > involved, you want to use the same GSSAPI name. So, the Kerberos TGS names are what I'd call domain-based service names - like host-based service names, but with a domain (realm) name instead of a hostname. I think the concept of domain/cluster-based service names needs to be generalized beyond the particular case of the Kerberos TGS. One way to do this would be to define a new GSS-API name type. Another would be to establish the convention of using domain names with the existing GSS-API host-based service name where domain-based services are needed. If we go the route of defining a new GSS-API name type we can actually do a very neat trick: we can have the name encode the service name, the domain name and, optionally, a hostname name (an instance of the domain- based service). This would avoid the replay caching issue. What's the difference between domain-based service names and host-based service names? With host-based service names, if a client has to lookup what servers are associated with a domain-wide infrastructure/cluster, the resulting principal names won't reflect the domain/cluster association, and if the lookup is not secure, well that's a problem. With domain-based names the client makes sure that the name of the domain/cluster it's interested in is part of the principal name and so binds the service principal name, no matter how the servers may be found, to that domain name. > But for other services, especially when an SRV record is used to find > the specific machine, it seems like you want to avoid requiring the > instances of the service to use the same GSSAPI name. This is > particularly true for some GSSAPI mechanisms such as Kerberos that > need to share a replay cache. Replay cache sharing is a related issue, but it's an implementation detail, a security consideration. Of course, shared replay caching is reasonably feasible for some cases, but it may not always be feasible though. I think that, for example, LDAP services ought to use domain-based service names, no matter how the servers are located. This means that the LDAP servers for any given domain have to share a replay cache OR that we really need a domain-based name type with host instances. > Note that this issue is not unique to GSSAPI. Other mechanisms such > as the digest-md5 mechanism specify mildly complicated naming rules, > where the name the user typed in is combined with the the name from > the DNS or other location service. > > Two questions: > > 1) Do we want to provide some better handling for this situation in > the GSSAPI case? IT's clear we cannot get away with just using > service@name_from_dns. We can either use > service@name_typed_by_user, requiring any replicated service to > just deal internally or we could use some new name type. In the case of LDAP the service name may often not be derived from any information typed in by the user (e.g., where LDAP is used by a name service switch). The domain name could come from local configuration or from user context (e.g., from a domain-qualified username). If we're using a domain-based name type with host instances the hostname can safely come from an SRV record. See above. > 2) Do we want to say anything about this in the base spec? We aren't > designing an API, but we may want to give general guidelines about > what bits of information SASL mechanisms can assume they can get > from an application, to prevent people designing mechanisms in the > future that make unreasonable requirements of multi-mechanisms > implementations. IMO it would be nice to specify a domain based name type for the GSS-API and the various existing GSS-API mechanisms. Then amend SASL to require support for domain-based naming where applications request it and where the SASL mechanisms support it. Cheers, Nico -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJa0qt050273 for ; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7LJa03n050272 for ietf-sasl-bks; Thu, 21 Aug 2003 12:36:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU [18.187.6.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7LJZxqt050267 for ; Thu, 21 Aug 2003 12:35:59 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5EEF8151CEC; Thu, 21 Aug 2003 15:35:58 -0400 (EDT) To: ietf-sasl@imc.org Cc: nicolas.williams@sun.com Subject: GSSAPI and domain-based names Message-Id: <20030821193558.5EEF8151CEC@konishi-polis.mit.edu> Date: Thu, 21 Aug 2003 15:35:58 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A few months ago, there was a discussion on the krbdev@mit.edu mailing list about names for GSSAPI principals. One conclusion from that list is that we may have an incomplete handling of the issue in SASL. I'm going to present the issue and step back and let Nico actually argue about solutions. The problem is what GSSAPI name do you use for replicated GSSAPI services? For some services, particularly those running on a cluster of tightly connected machines, especially with aload balancer involved, you want to use the same GSSAPI name. But for other services, especially when an SRV record is used to find the specific machine, it seems like you want to avoid requiring the instances of the service to use the same GSSAPI name. This is particularly true for some GSSAPI mechanisms such as Kerberos that need to share a replay cache. Note that this issue is not unique to GSSAPI. Other mechanisms such as the digest-md5 mechanism specify mildly complicated naming rules, where the name the user typed in is combined with the the name from the DNS or other location service. Two questions: 1) Do we want to provide some better handling for this situation in the GSSAPI case? IT's clear we cannot get away with just using service@name_from_dns. We can either use service@name_typed_by_user, requiring any replicated service to just deal internally or we could use some new name type. 2) Do we want to say anything about this in the base spec? We aren't designing an API, but we may want to give general guidelines about what bits of information SASL mechanisms can assume they can get from an application, to prevent people designing mechanisms in the future that make unreasonable requirements of multi-mechanisms implementations. --Sam Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ5qt019879 for ; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JJZ5gP019878 for ietf-sasl-bks; Tue, 19 Aug 2003 12:35:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JJZ4qt019873 for ; Tue, 19 Aug 2003 12:35:04 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03727; Tue, 19 Aug 2003 15:35:02 -0400 (EDT) Message-Id: <200308191935.PAA03727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-02.txt Date: Tue, 19 Aug 2003 15:35:01 -0400 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF. Title : Simple Authentication and Security Layer (SASL) Author(s) : A. Melnikov Filename : draft-ietf-sasl-rfc2222bis-02.txt Pages : 18 Date : 2003-8-19 SASL provides a method for adding authentication support with an optional security layer to connection-based protocols. It also describes a structure for authentication mechanisms. The result is an abstraction layer between protocols and authentication mechanisms such that any SASL-compatible authentication mechanism can be used with any SASL-compatible protocol. This document describes how a SASL authentication mechanism is structured, how a protocol adds support for SASL, defines the protocol for carrying a security layer over a connection, and defines the EXTERNAL SASL authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sasl-rfc2222bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sasl-rfc2222bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19155101.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDSqt038633 for ; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) (envelope-from owner-ietf-sasl@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h75LDSbp038631 for ietf-sasl-bks; Tue, 5 Aug 2003 14:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-sasl@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h75LDRqt038621 for ; Tue, 5 Aug 2003 14:13:27 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust32.tnt24.lnd4.gbr.da.uu.net [62.188.151.32]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h75LH5V21287; Tue, 5 Aug 2003 15:17:06 -0600 Message-ID: <3F300F66.5030301@isode.com> Date: Tue, 05 Aug 2003 21:11:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: ietf-sasl@imc.org Subject: Re: Draft minutes References: <20030725200648.282C4152496@konishi-polis.mit.edu> In-Reply-To: <20030725200648.282C4152496@konishi-polis.mit.edu> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Very good notes indeed. Sam Hartman wrote: > Please send in comments or corrections by next Tuesday. I will send > in for proceedings shortly after that point. > > IETF SASL WG meeting Minutes > ========================== > > Tuesday 15 July 2003 > 3:45pm > chairs: Sam Hartman Kurt Zeilenga > > scribe: Luke Howard > > 2222bis > ======= > > - Alexei noted that he has published a subsequent revision of > 2222bis; minor editorial issues remain > - Clarification of empty authorization identities > - Alexei will do a final revision of the document in the first > week of August after which it can go to last call > As I haven't received any comments I haven't done any work ;-). Alexey