From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 1 13:58:08 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01365 for ; Mon, 1 May 2000 13:58:06 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA04982 for ietf-cat-wg-out720680; Mon, 1 May 2000 10:26:11 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA04972 for ; Mon, 1 May 2000 10:26:07 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id NAA15892; Mon, 1 May 2000 13:26:04 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma015829; Mon, 1 May 2000 13:25:47 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA26624; Mon, 1 May 2000 13:29:24 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA00222; Mon, 1 May 2000 13:25:44 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA01358; Mon, 1 May 2000 13:22:33 -0400 (EDT) Date: Mon, 1 May 2000 13:22:33 -0400 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000501132231.A1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200004190431.VAA10992@cayman-islands.isi.edu> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I think that authorization data in Kerberos tickets actually fixes a real problem elegantly. As such I think it's worth keeping the idea, and standardizing a universal, extensible format for the authorization data. If there is no user identification data in Kerberos tickets then the name service in use must allow anonymous (or nearly-anonymous) lookups of user information from any server which a user might access. With user identification/authorization/profile data in Kerberos tickets this problem is resolved. It also represents an optimization: the name service lookups of user information need only be made at TGT-granting time. I find this idea to be very elegant. The problem is that Microsoft's approach is very platform-specific. That and Microsoft is not seeking to make their approach an open standard. So, if the alternative is between officially making Microsoft's approach a violation of the standard or standardizing a better design then the answer seems clear to me. After all, I think it more likely that Microsoft would adopt a better standard than that they would drop their PAC-in-the-ticket system altogether. All we need is a general standard for encoding of name-type-length-data fields and then a standard for naming the fields and types. The kinds of data that should be included in Kerberos tickets, IMNSHO, are: - POSIX system IDs (UID, primary GID, supplementary GIDs) - Windows system IDs (domain SID, user RID, primary group RID, supplementary group RIDs, other group SID/RIDs) - home directory server and share information - maybe some other items, such as policy group memberships (think netgroups) - a ticket or PAC signature: a checksum encrypted with the key of a host-specific service principal that should be used on each host to validate the signature - a ticket or PAC signature signed with the key of the target service Nico On Tue, 18 Apr 2000, Clifford Neuman wrote: > > One of the few remaining issues to be resolved before Kerberos > revisions goes to last call is the final disposition of the ticket > extensions field. > > Such a field was not present in RFC1510, but it is present in the current > draft Kerberos revisions. Whether this field remains is a contentious > issue. The argument for the field are that it allows additional > information logically associated with the ticket to be carried with the > ticket. One example of such an extension is used in the latest version of > the PK-CROSS protocol. Another is the use of external (integrity but not > confidentiality protected) authorization data. > > The arguments against such a field center on backwards compatibility when > new fields are added in ASN.1 encodings of messages, and the danger that > the field might be misused for extensions that detract from > interoperability across implementations. > > I would like to initiate discussion on the list in hopes of bringing this > discussion to resolution. This message is intended to solicit discussion > on both sides of the issues. > > Clifford Neuman > > -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 1 14:11:51 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01696 for ; Mon, 1 May 2000 14:11:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA06005 for ietf-cat-wg-out720680; Mon, 1 May 2000 10:42:16 -0700 (PDT) Received: from venera.isi.edu (venera.isi.edu [128.9.176.32]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA05982 for ; Mon, 1 May 2000 10:42:10 -0700 (PDT) Received: from bcn (ras34.isi.edu [128.9.176.134]) by venera.isi.edu (8.9.3/8.9.3) with SMTP id KAA06138; Mon, 1 May 2000 10:39:17 -0700 (PDT) From: "Clifford Neuman" To: "Nicolas Williams" , , Subject: RE: Ticket extensions in Kerberos revisions Date: Mon, 1 May 2000 10:35:28 -0700 Message-ID: <000001bfb393$a4127260$45e2fea9@bcn.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <20000501132231.A1094@sm2p1386swk.wdr.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I agree that it is time for a standard for encoding this information in the authorization data field, and I'm planning to define the structure of the authorization data element to encode just the items you listed in the Kerberos revisions. I wasn't planning to do this as part of the revisions originally, but given the onerous licensing language in Microsoft's publication of their spec, I think its time. Of course, this would mean that if I include it in the spec, that Microsofts authorization extensions would no longer be compatible. If this is of concern to them, then if they would free up the IP they claim on their formatting of their field (which I don't consider to be particularly innovative - having originated in earlier works and in krb-protocol discusions), then I'd certainly consider describing the authorization element in a separate spec instead. Clifford Neuman > -----Original Message----- > From: Nicolas Williams [mailto:willian@ubsw.com] > Sent: Monday, May 01, 2000 10:23 AM > To: ietf-cat-wg@lists.stanford.edu; krb-protocol@mit.edu > Subject: Re: Ticket extensions in Kerberos revisions > > > > I think that authorization data in Kerberos tickets actually fixes a > real problem elegantly. As such I think it's worth keeping the idea, > and standardizing a universal, extensible format for the authorization > data. > > If there is no user identification data in Kerberos tickets then the > name service in use must allow anonymous (or nearly-anonymous) lookups > of user information from any server which a user might access. > > With user identification/authorization/profile data in Kerberos tickets > this problem is resolved. It also represents an optimization: the name > service lookups of user information need only be made at TGT-granting > time. I find this idea to be very elegant. > > The problem is that Microsoft's approach is very platform-specific. > That and Microsoft is not seeking to make their approach an open > standard. > > So, if the alternative is between officially making Microsoft's approach > a violation of the standard or standardizing a better design then the > answer seems clear to me. After all, I think it more likely that > Microsoft would adopt a better standard than that they would drop their > PAC-in-the-ticket system altogether. > > All we need is a general standard for encoding of name-type-length-data > fields and then a standard for naming the fields and types. The kinds of > data that should be included in Kerberos tickets, IMNSHO, are: > > - POSIX system IDs (UID, primary GID, supplementary GIDs) > - Windows system IDs (domain SID, user RID, primary group RID, > supplementary group RIDs, other group SID/RIDs) > - home directory server and share information > - maybe some other items, such as policy group memberships (think > netgroups) > - a ticket or PAC signature: a checksum encrypted with the key of a > host-specific service principal that should be used on each host to > validate the signature > - a ticket or PAC signature signed with the key of the target service > > Nico -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 1 14:32:36 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02023 for ; Mon, 1 May 2000 14:32:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA06828 for ietf-cat-wg-out720680; Mon, 1 May 2000 11:00:05 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA06823 for ; Mon, 1 May 2000 11:00:03 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA25005; Mon, 1 May 2000 14:00:01 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma024835; Mon, 1 May 2000 13:59:28 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA28602; Mon, 1 May 2000 14:03:04 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA08796; Mon, 1 May 2000 13:59:24 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA01531; Mon, 1 May 2000 13:56:13 -0400 (EDT) Date: Mon, 1 May 2000 13:56:13 -0400 From: Nicolas Williams To: Clifford Neuman Cc: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000501135611.B1094@sm2p1386swk.wdr.com> References: <20000501132231.A1094@sm2p1386swk.wdr.com> <000001bfb393$a4127260$45e2fea9@bcn.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <000001bfb393$a4127260$45e2fea9@bcn.isi.edu>; from bcn@ISI.EDU on Mon, May 01, 2000 at 10:35:28AM -0700 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Mon, May 01, 2000 at 10:35:28AM -0700, Clifford Neuman wrote: > I agree that it is time for a standard for encoding this information in the > authorization data field, and I'm planning to define the structure of the > authorization data element to encode just the items you listed in the > Kerberos revisions. I wasn't planning to do this as part of the revisions > originally, but given the onerous licensing language in Microsoft's > publication of their spec, I think its time. Yes, it's hard to believe that one could publish a trade secret and still claim it to be a secret. I believe that their publication of their spec in EXE format is designed to trigger protections in the DMCA for access control devices. Thus I feel quite uneasy discussing details of their spec (would that be akin to breaking a non-disclosure agreement under the DMCA?). I'm also unwilling to discuss the security of MS's design; why be so generous? > Of course, this would mean that if I include it in the spec, that Microsofts > authorization extensions would no longer be compatible. If this is of > concern to them, then if they would free up the IP they claim on their > formatting of their field (which I don't consider to be particularly > innovative - having originated in earlier works and in krb-protocol > discusions), then I'd certainly consider describing the authorization > element in a separate spec instead. Or they could adopt the new standard. Anyways, MS says that they are considering opening their spec altogether. I don't blame them for hesitating: when the government is prosecuting you on anti-trust charges every weapon can be useful... [rhetorical -- no need to answer] > Clifford Neuman Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 03:17:08 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25573 for ; Tue, 2 May 2000 03:17:07 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA22222 for ietf-cat-wg-out720680; Mon, 1 May 2000 23:25:06 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.12.23]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id XAA22217 for ; Mon, 1 May 2000 23:25:04 -0700 (PDT) Received: (qmail 14553 invoked by uid 50); 2 May 2000 06:25:03 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <20000501132231.A1094@sm2p1386swk.wdr.com> In-Reply-To: Nicolas Williams's message of "Mon, 1 May 2000 13:22:33 -0400" From: Russ Allbery Organization: The Eyrie Date: 01 May 2000 23:25:03 -0700 Message-ID: Lines: 37 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Nicolas Williams writes: > I think that authorization data in Kerberos tickets actually fixes a > real problem elegantly. As such I think it's worth keeping the idea, and > standardizing a universal, extensible format for the authorization data. I've never seen the intermingling of an authorization system with an authentication system cause anything other than severe pain. cf DCE. > If there is no user identification data in Kerberos tickets then the > name service in use must allow anonymous (or nearly-anonymous) lookups > of user information from any server which a user might access. Why would this require authorization rather than just authentication? Kerberos tickets have authentication information: principal and realm. > - POSIX system IDs (UID, primary GID, supplementary GIDs) > - Windows system IDs (domain SID, user RID, primary group RID, > supplementary group RIDs, other group SID/RIDs) > - home directory server and share information > - maybe some other items, such as policy group memberships (think > netgroups) All you need for this sort of thing is an authorization system that can be queried in a secure fashion using the server's Kerberos principal for authentication and takes a Kerberos principal as a key. Sounds like an excellent application for LDAP to me, using Kerberos to authenticate the query. We're currently using straight NIS for this because the above isn't particularly sensitive information, but for additional security and reliability, LDAP would be the first place I'd look. It seems to be the place Microsoft looked too, with Active Directory. They just didn't clean up the separation and play well with the rest of the world. -- Russ Allbery (rra@stanford.edu) -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 08:07:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28353 for ; Tue, 2 May 2000 08:07:11 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id EAA01521 for ietf-cat-wg-out720680; Tue, 2 May 2000 04:18:23 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id EAA01512 for ; Tue, 2 May 2000 04:18:19 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA02989; Tue, 2 May 00 07:20:22 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id NAA24732; Tue, 2 May 2000 13:15:15 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [155.56.94.51]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id NAA17962; Tue, 2 May 2000 13:13:28 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id NAA24383; Tue, 2 May 2000 13:13:28 +0200 (METDST) From: Martin Rex Message-Id: <200005021113.NAA24383@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: jaltman@columbia.edu Date: Tue, 2 May 2000 13:13:28 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 28, 0 03:37:39 pm Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Jeffrey Altman wrote: > > > Your posistion: > > applications should enforce architecture and policies on sysadmins > > and gssapi mechanisms by requiring hostbased services names to work. > > > > My posistion: > > gssapi mechanisms should be configurable for sharing credentials > > of services, and applications should be configurable for credentials > > and target names, so that the sysadmin and the users may freely > > choose among available gssapi mechanisms and determine their own > > policies (on sharing certain services credentials). > > You are making a very bad assumption. That GSSAPI is the only > authentication mechanism available to the application. Its not. > The application very frequently does have knowledge of policy that the > underlying authentication mechansims do not have. Huh? I didn't make assumptions. I clearly stated that it should be up to the sysadmin and user who installs gssapi with a particular application to provide installation-specific policies and mapping. In contrast, you want to put it into the application protocol spec, and you want to force your own configuration onto every other installation and environment by putting your own assumptions into the application protocol spec. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 10:36:24 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02109 for ; Tue, 2 May 2000 10:36:23 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id GAA03200 for ietf-cat-wg-out720680; Tue, 2 May 2000 06:57:45 -0700 (PDT) Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id GAA03195 for ; Tue, 2 May 2000 06:57:43 -0700 (PDT) Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 6BAC915533; Tue, 2 May 2000 09:57:11 -0400 (EDT) Received: by haggis.ma.certco.com (Postfix, from userid 1079) id CCEA87C0E8; Tue, 2 May 2000 09:57:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id C076F744C6; Tue, 2 May 2000 09:57:11 -0400 (EDT) Date: Tue, 2 May 2000 09:57:11 -0400 (EDT) From: Rich Salz To: Russ Allbery Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Why would this require authorization rather than just authentication? > Kerberos tickets have authentication information: principal and realm. You're drawing a distinction between authn and authz that I don't understand. How is "use KRB authn info to query ldap" any different from authorization where the principal (and perhaps realm) name are used as the credentials? (In fact, I thought the phrase name-based authorization came from KRB, not DCE.) /r$ -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 12:15:51 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04208 for ; Tue, 2 May 2000 12:15:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA06245 for ietf-cat-wg-out720680; Tue, 2 May 2000 08:38:28 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA06231 for ; Tue, 2 May 2000 08:38:25 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA23291; Tue, 2 May 00 11:40:21 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id RAA22334; Tue, 2 May 2000 17:35:08 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [155.56.94.51]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id RAA00504; Tue, 2 May 2000 17:34:24 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id RAA25823; Tue, 2 May 2000 17:34:24 +0200 (METDST) From: Martin Rex Message-Id: <200005021534.RAA25823@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: tytso@valinux.com (Theodore Ts'o) Date: Tue, 2 May 2000 17:34:24 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004290637.CAA05660@rsts-11.su.valinux.com> from "Theodore Ts'o" at Apr 29, 0 02:37:45 am Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Theodore Ts'o wrote: > > Well, my position is this: host-based service names should work so that > the mapping between host/service pairs and mechanism names is done in > one place --- at the mechanism layer, utilizing some kind of > implementation specific database mapping layer which can be configurable > by users and sysadmins for their particular site. That's almost what I've been asking for all the time. However instead of leaving everything to the implementors, there should be at least some guidance how to do this mapping in the gssapi mechanism spec. Some participants of the discussion only seem to care about the configuration of their simple client apps. I'm worring about the configuration of our large distributed apps, where I think that it is very valuable being able to replace a particular Kerberos 5 library with another one without having to worry about the 10000+ entries in the ACLs of the application. The only thing that you should have to worry about is the exact procedure of making credentials available to your application. Given a clean mechanism spec, it doesn't matter whether whether the new library is from a different vendor or simply an update from the same vendor. We have distributed applications running instances of the same service on a large variety of platforms and we share the ACLs across all of the hosts. Sometimes you may not be able to get a particular gssapi mechanism for all of your platforms from the same supplier. I know that there are vendors out there that like to tie you to their products as much as possible, but IETF standards are traditionally oriented towards interoperability. > > This is absolutely necessary for simple GSSPAI mechanism negotiation to > work, as I mentioned earlier. It also concentrates the work necessary > at the low-level mechanism level, so it only needs to be implemented > once per mechanism, instead once for every GSSAPI application. I consider the gssapi mechanism negotiation a different rathole. Personally, I doubt that applications will in general not be prepared to deal with mechanisms that do not share a unified namespace. i.e. for applications, none of these three names are the same: "mrex@WDF.SAP-AG.DE" "mrex@TEST.SAP-AG.DE" "CN=Martin Rex, O=SAP-AG, C=DE" If individual names should refer to the same identity, then the gssapi mechanism should provide the unified namespace, or once again one will have to do it seperately for each application instead of once per gssapi mechanism. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 12:24:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04403 for ; Tue, 2 May 2000 12:24:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA06362 for ietf-cat-wg-out720680; Tue, 2 May 2000 08:40:01 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA06351 for ; Tue, 2 May 2000 08:39:57 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e42FdnZ15431; Tue, 2 May 2000 08:39:49 -0700 (PDT) Date: Tue, 2 May 2000 08:39:49 -0700 (PDT) From: "Booker C. Bense" To: Rich Salz cc: Russ Allbery , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 2 May 2000, Rich Salz wrote: > > Why would this require authorization rather than just authentication? > > Kerberos tickets have authentication information: principal and realm. > > You're drawing a distinction between authn and authz that I don't understand. - Nobody does. I have yet to meet a vendor that grasps the idea that they should be seperate services. Who you are doesn't change, but what you can do often needs to change very quickly. Embedding that info in a static ticket seems to cut off alot of the possible uses of authorization. > How is "use KRB authn info to query ldap" any different from authorization > where the principal (and perhaps realm) name are used as the credentials? - Because one works fairly well and the other is an abysmal failure. Putting authorization into the authentication protocol only works if you have a clear underlying model for HOW you are going to do authorization now, next week and for the forseeable future. - Frankly, I would rather see the auth pack data removed from the protocol entirely unless it's going to be fully supported via a standardized API and data model. One of the great benefits of putting authorization data in LDAP is that you have to sit down and plan out the schema in advance. - The schema I've seen so far ( basically Groups ) is just a extension of answering the question "Who are you?". If you are going to truly answer the question "What can you do?" that auth pack is going to have to be fairly large since it has to contain ALL of your permissions apriori. In this area, an incomplete inflexible solution is worse than no solution at all. - Kerberos should stick to authentication, which it does quite well and leave authorization to another service. I don't think LDAP is the final word in this debate, but it's a good first step. Seperating authentication and authorization creates a very powerful and flexible environment. Joining them hasn't been successful in the past and I don't know why that should change in the future. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 12:46:55 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04928 for ; Tue, 2 May 2000 12:46:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA08009 for ietf-cat-wg-out720680; Tue, 2 May 2000 09:08:33 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA08000 for ; Tue, 2 May 2000 09:08:29 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA05052; Tue, 2 May 00 12:08:19 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id SAA04317; Tue, 2 May 2000 18:05:06 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [155.56.94.51]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id SAA02550; Tue, 2 May 2000 18:07:05 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id SAA25992; Tue, 2 May 2000 18:07:05 +0200 (METDST) From: Martin Rex Message-Id: <200005021607.SAA25992@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: mre@Eng.Sun.COM Date: Tue, 2 May 2000 18:07:05 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 28, 0 08:50:29 am Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Mike Eisler wrote: > > > After Ted's hint about what else is written in section 4.1 of rfc2743, > > I realize that this section is breaching the GSS-API abstraction itself, > > because it suggest to make assumptions that every gssapi mechanism > > in the world and of the future can be assumed to look like the > > Kerberos of today. > > I don't see the violation. "host" is just a string. RFC 2743 could > have selected any arbitrary string. All it is saying is that there is > well known target name that an application *may* use. nfs doesn't > use it it, ftp does, etc. "host" is not just a string. It is a particular notion of sharing credentials on a host by services that traditionally run under the root account of Unix machines. For MIT Kerberos, the default acceptor credentials resolve to "host/f.q.d.n". (btw. rfc1964bis could also give some guidance on default acceptor credential resolution). Just as each of the protocols rlogin,rexec,telnet as well as ftp,nfs,ssh are assigned distinct well-known TCP-ports, they should be assigned distinct well-known hostbased service names. Just because different application protocols offer essentially the same service doesn't mean that we should discriminate against gssapi mechanisms that do not offer to share credentials across processes. I think that requiring nfs@hostname for NFSv4 is the way every application should do it. Again, I strongly suggest that Kerberos gssapi mechanism should be permitted to map "nfs@hostname" to the "host/f.q.d.n" principal when the sysadmin wants this. > > > - SPKM and LIPKEY lack the definition of a mechanism specific > > nametype. > > For SPKM this has caused all independent implementations to > > create non-interoperable nametypes (I've seen 5 independent > > mechanisms so far). I have no reason to believe that LIPKEY > > will improve the situation. I strongly encourage the > > document authors to propose a mechanism specific nametype, > > discuss it here and nail it down. Since existing implementations > > are non-interoperable, we can only make things better. > > NFSv4 since is specified to use LIPKEY. If NFSv4 is successful. i.e. there are > at least two independent interoperable implementations that fully conform to > all mandatory features of the protocol, including LIPKEY and SPKM-3, then > there will be two LIPKEY/SPKM-3 mechanisms that interoperate. At which time, > the specifications can be tightened. Oh, that sounds interesting: How do you verify that an implementation of LIPKEY and SPKM-3 conforms to the mandatory feature "all generic nametypes of rfc2078", when this part is not actually specified? -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 12:51:04 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05030 for ; Tue, 2 May 2000 12:51:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA08517 for ietf-cat-wg-out720680; Tue, 2 May 2000 09:16:17 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA08512 for ; Tue, 2 May 2000 09:16:15 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id MAA22321; Tue, 2 May 2000 12:15:19 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xma021986; Tue, 2 May 2000 12:14:20 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA18597; Tue, 2 May 2000 12:16:08 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA06122; Tue, 2 May 2000 12:14:16 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA05480; Tue, 2 May 2000 12:11:03 -0400 (EDT) Date: Tue, 2 May 2000 12:11:03 -0400 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000502121102.I1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On 01 May 2000, Russ Allbery wrote: > Nicolas Williams writes: > > > I think that authorization data in Kerberos tickets actually fixes a > > real problem elegantly. As such I think it's worth keeping the idea, and > > standardizing a universal, extensible format for the authorization data. > > I've never seen the intermingling of an authorization system with an > authentication system cause anything other than severe pain. cf DCE. But it's a reality with Windows 2000. I think Windows 2000 is here to stay. Oh, and I have had no experience with DCE, so it's hard for me to decide wether to agree with you or not. > > If there is no user identification data in Kerberos tickets then the > > name service in use must allow anonymous (or nearly-anonymous) lookups > > of user information from any server which a user might access. > > Why would this require authorization rather than just authentication? > Kerberos tickets have authentication information: principal and realm. Because, see, if you don't put this information in the ticket, then every server a user could log into must be able to look up that user's login info. But this means, in practice, that any user can lookup up any other user's login info (oh, you can make it really hard for this to happen, but still). This is what I meant by semi-anonymous, because with such a scheme you can never tell the identity of the user on whose behalf a service is performing the lookup. I think MS has taken quite a bit of heat over the fact that anonymous users can enumerate NT4 SAM databases. With Windows 2000 and Active Directory this is need no longer be the case: it's up to the administrators and how they setup the relevant ACLs in AD. The only ways that I can see to achieve this effect are: 1) put the login info in the tickets; or 2) forward a proxied ticket to the service that a user is connecting to that would allow the service to lookup the user's login info on the user's behalf. Microsoft chose the former. Note also that with the former the lookup for the login info need only be done ONCE, when the user logs in (i.e., when the system she logs into requests a TGT for the user). I find this to be elegant. And I can't see how it causes headaches, though I can see that once a TGT has been issued to a user then the associated login info cannot be changed for that session, nor can the ticket be revoked, but that is a feature of Kerberos, so the situation is not worsened by putting login info in the tickets. I think that there is some confusion between "authorization data", which is what we've been calling the MS PAC, and what it really is: system credential information associated with the Kerberos principal + some satellite data. I wouldn't call a POSIX UID "authorization data": it's just a system credential. Once one has made this distinction between authorization data and system credentials then perhaps the concept should not sound so scary. I believe system credential information should be distributed with tickets, but only minimal authorization information should be included. E.g., no info related to which servers a user can access belongs in TGTs, but policy group membership information for the user _does_. > > - POSIX system IDs (UID, primary GID, supplementary GIDs) > > - Windows system IDs (domain SID, user RID, primary group RID, > > supplementary group RIDs, other group SID/RIDs) > > - home directory server and share information > > - maybe some other items, such as policy group memberships (think > > netgroups) > > All you need for this sort of thing is an authorization system that can be > queried in a secure fashion using the server's Kerberos principal for > authentication and takes a Kerberos principal as a key. Sounds like an > excellent application for LDAP to me, using Kerberos to authenticate the > query. See above. BTW, this is the approach that Sun is using; checkout the man pages for gssd(1M) via http://www.docs.sun.com/. > We're currently using straight NIS for this because the above isn't > particularly sensitive information, but for additional security and > reliability, LDAP would be the first place I'd look. It seems to be the > place Microsoft looked too, with Active Directory. They just didn't clean > up the separation and play well with the rest of the world. Well, I think that MS indeed didn't play nice, but the concept they chose is superior to the one that you're peddling, IMNSHO :) I wasn't particularly interested in Kerberos at the time that MS started considering their PAC-in-the-ticket approach, so I don't really know what happened. Perhaps someone else can tell us if it was MS that didn't play nice or the standards community or both. Or perhaps we can drop the finger pointing, make up a new standard we can all live with and move on. > -- > Russ Allbery (rra@stanford.edu) Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 12:52:19 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05073 for ; Tue, 2 May 2000 12:52:18 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA08593 for ietf-cat-wg-out720680; Tue, 2 May 2000 09:17:58 -0700 (PDT) Received: from coserver2.CoManagecorp.com (srv2.comanagecorp.com [209.195.154.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA08582 for ; Tue, 2 May 2000 09:17:52 -0700 (PDT) From: BenC@CoManage.net Received: by srv2.comanagecorp.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 12:14:38 -0400 Message-ID: <10F8EB7E5319D31195CF0090277AF2374F800C@srv2.comanagecorp.com> To: bbense@networking.stanford.edu, salzr@certco.com Cc: rra@stanford.edu, ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 2 May 2000 12:14:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Booker C. Bense wrote: > - The schema I've seen so far ( basically Groups ) is just a extension > of answering the question "Who are you?". If you are going to truly See "groups", think "roles". > answer the question "What can you do?" that auth pack is going to have > to be fairly large since it has to contain ALL of your permissions > apriori. In this area, an incomplete inflexible solution is worse than > no solution at all. Embedding ALL permissions in a PAC is a Bad Idea. (As a simple example: What happens when you add a new securable object to the system? Oops!) I have yet to be convinced that embedding role information in a PAC is a bad idea. The only drawback I've seen to it is that the information can't change as frequently as you might like it to. To me, that seems a reasonable tradeoff for the benefit of servers not needing to contact an online authorization service to find out the info in realtime every time a client's credentials are presented. -- Ben -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 13:40:18 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06044 for ; Tue, 2 May 2000 13:40:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA12021 for ietf-cat-wg-out720680; Tue, 2 May 2000 10:04:42 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA12016 for ; Tue, 2 May 2000 10:04:40 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e42H4Uj15640; Tue, 2 May 2000 10:04:30 -0700 (PDT) Date: Tue, 2 May 2000 10:04:30 -0700 (PDT) From: "Booker C. Bense" To: BenC@CoManage.net cc: salzr@certco.com, rra@stanford.edu, ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions In-Reply-To: <10F8EB7E5319D31195CF0090277AF2374F800C@srv2.comanagecorp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 2 May 2000 BenC@CoManage.net wrote: > Booker C. Bense wrote: > > - The schema I've seen so far ( basically Groups ) is just a extension > > of answering the question "Who are you?". If you are going to truly > > See "groups", think "roles". - Groups, roles, grandfallons... It doesn't matter what you call it, it's still the same idea. The difference is fine, but there is one between these two : Hi, I'm Booker Bense and I'm in grandfallon Beta... Hello Booker Bense, wait moment while I check if you're in grandfallon Beta... - I wish I could explain it better, but it's taken me 5 years of work to really grok the difference and I haven't found a good way to explain it. Perhaps the best way is the one scales to any size, and the first can only get so big before it becomes unwieldy. > > > answer the question "What can you do?" that auth pack is going to have > > to be fairly large since it has to contain ALL of your permissions > > apriori. In this area, an incomplete inflexible solution is worse than > > no solution at all. > > Embedding ALL permissions in a PAC is a Bad Idea. (As a simple example: > What happens when you add a new securable object to the system? Oops!) > - How do you pick and choose then? I'd object less if I saw a more concrete answer to this question. > I have yet to be convinced that embedding role information in a PAC is a bad > idea. The only drawback I've seen to it is that the information can't > change as frequently as you might like it to. To me, that seems a > reasonable tradeoff for the benefit of servers not needing to contact an > online authorization service to find out the info in realtime every time a > client's credentials are presented. > - This is a false optimization. Solving only part of the problem actually causes more work in the long run. How does this data get into the kerberos PAC in the first place? If you can't solve all your authorization needs with it, you'll need a second system. How do you keep the data in sync? - Clearly you can solve some of these problems by having the kdc query the authz service and imbed that in the PAC, but what's the point? What's the advantage of the KDC doing a static fixed query that won't provide a complete solution? Seperating these functions has so many advantages, whereas joining them doesn't seem to present any clear advantages to me and the disadvantages are obvious. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 13:43:54 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06093 for ; Tue, 2 May 2000 13:43:53 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA12217 for ietf-cat-wg-out720680; Tue, 2 May 2000 10:08:10 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id KAA12212 for ; Tue, 2 May 2000 10:08:07 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA27416; Tue, 2 May 00 13:08:03 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA24380; Tue, 2 May 2000 19:05:04 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [155.56.94.51]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id TAA04610; Tue, 2 May 2000 19:03:07 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA26287; Tue, 2 May 2000 19:03:07 +0200 (METDST) From: Martin Rex Message-Id: <200005021703.TAA26287@hw1464.wdf.sap-ag.de> Subject: Re: Ticket extensions in Kerberos revisions To: willian@ubsw.com (Nicolas Williams) Date: Tue, 2 May 2000 19:03:06 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <20000501132231.A1094@sm2p1386swk.wdr.com> from "Nicolas Williams" at May 1, 0 01:22:33 pm Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > The problem is that Microsoft's approach is very platform-specific. > That and Microsoft is not seeking to make their approach an open > standard. > > So, if the alternative is between officially making Microsoft's approach > a violation of the standard or standardizing a better design then the > answer seems clear to me. After all, I think it more likely that > Microsoft would adopt a better standard than that they would drop their > PAC-in-the-ticket system altogether. > > All we need is a general standard for encoding of name-type-length-data > fields and then a standard for naming the fields and types. The kinds of > data that should be included in Kerberos tickets, IMNSHO, are: > > - POSIX system IDs (UID, primary GID, supplementary GIDs) > - Windows system IDs (domain SID, user RID, primary group RID, > supplementary group RIDs, other group SID/RIDs) > - home directory server and share information > - maybe some other items, such as policy group memberships (think > netgroups) > - a ticket or PAC signature: a checksum encrypted with the key of a > host-specific service principal that should be used on each host to > validate the signature > - a ticket or PAC signature signed with the key of the target service I haven't seen Microsoft's spec for the authorization data, but I think it is not so easy to get it right and I'm wondering whether Microsoft got it right in their design. The only reason why systems like to carry around a POSIX-style userid and group memberships is so that the authorization checks can be performed by the trusted computing base (TCB) on the server side. In order for the TCB to perform ACL checks for the clients privileges, the server needs to "run in the context of the client" somehow. In the Microsoft world, this is called "impersonation". On W2K, the LSA performs the client authentication, retrieves the PAC from inside the service ticket, verifies the signature on the PAC somehow and then creates an access token that is made available to the server process. The server process can switch between its own access token an the access token of the impersonated client whenever it likes to. Remember that with Kerberos, service tickets are (a) cached and therefore reused, (b) have a limited lifetime, and (b) can be "forged" by the service itself when it knows its own key (which is usually the case). Now the questions that come to my mind: (1) is the lifetime of the PAC limited in the same fashion as the service ticket. It may be a security problem if a service can open incoming service tickets and save away PACs for unlimited future use in forged service tickets? (2) is the PAC tied to the particular service/target, or could an arbitrary service use the PAC in a forged ticket to have an access token created? (3) is the PAC limited to a particular target host, or can the PAC be reused in a forged ticket on a different host? Keep in mind that impersonation is the default with Microsoft's SSPI, so whenever a domain admin touches Microsoft services on a remote machine in the domain, his PAC will be unconditionally handed to this machine. Therefore if you have accidental or intentional admin access on one machine of the domain you may be able to collect PACs and eventually use them on other machines of the domain where you have access, but no admin access yet... So whatever you plan to do in the authorization are, be very careful of the security implications. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 14:10:09 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06449 for ; Tue, 2 May 2000 14:10:08 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA14953 for ietf-cat-wg-out720680; Tue, 2 May 2000 10:40:40 -0700 (PDT) Received: from coserver2.CoManagecorp.com (srv2.comanagecorp.com [209.195.154.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA14948 for ; Tue, 2 May 2000 10:40:37 -0700 (PDT) From: BenC@CoManage.net Received: by srv2.comanagecorp.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 13:37:20 -0400 Message-ID: <10F8EB7E5319D31195CF0090277AF2374F8047@srv2.comanagecorp.com> To: bbense@networking.stanford.edu Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 2 May 2000 13:37:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > - Groups, roles, grandfallons... It doesn't matter what you call it, > it's still the same idea. The difference is fine, but there is one > between these two : > > Hi, I'm Booker Bense and I'm in grandfallon Beta... I think you mean "Hi, I'm Booker Bense and here's a blob of data sealed by somebody we both trust that should prove to you that I'm in grandfallon Beta." > Hello Booker Bense, wait moment while I check if you're in > grandfallon Beta... > > - I wish I could explain it better, but it's taken me 5 years of work > to really grok the difference and I haven't found a good way to > explain it. Perhaps the best way is the one scales to any size, > and the first can only get so big before it becomes unwieldy. I hope you're not suggesting that it's more scalable to have servers do online checks at each credential presentation than it is to have the info stuffed into a PAC at the beginning of a user's session. The PAC option only becomes unwieldy when you (1) make the decision of what groups/roles to include in the PAC without respect to the actual end use of the PAC, and (2) tie it so tightly with authentication that the info has to go even to services that won't use it. (1) can be solved by having the client drive the PAC contents in its request, and (2) can be solved by separating the PAC and the TGT (clients present the PAC only to servers that will use it). > > Embedding ALL permissions in a PAC is a Bad Idea. (As a simple example: > > What happens when you add a new securable object to the system? Oops!) > > - How do you pick and choose then? I'd object less if I saw a more > concrete answer to this question. You pick and choose by having no permissions in a PAC, just role (/group) info. > - Clearly you can solve some of these problems by having the kdc > query the authz service and imbed that in the PAC, but what's the > point? What's the advantage of the KDC doing a static fixed query > that won't provide a complete solution? Seperating these functions > has so many advantages, whereas joining them doesn't seem > to present any clear advantages to me and the disadvantages are > obvious. I don't intend to get into a long discussion about these sorts of issues, but DCE solved it the other way around: the client contacts the authz service (PTGS) and requests a PTGT (privilege TGT); the PTGS constructs a PAC and gets a TGT for itself with the relevant PAC attached (not embedded) in it, and hands this proxied TGT back to the client as a PTGT. There are some bad things about the DCE (one immediate one that comes to mind is that there was no way to separate the TGS, the PTGS and the security database, so you couldn't let the PTGS use an MIT KDC for tickets and LDAP for account info, for example), but IMnsHO, the PAC system wasn't one of them. (Note that I am not defending Microsoft's choice to embed the PAC in the TGT; I am only defending the abstract notion of a PAC.) -- Ben -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 14:47:24 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07108 for ; Tue, 2 May 2000 14:47:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA17089 for ietf-cat-wg-out720680; Tue, 2 May 2000 11:12:04 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA17081 for ; Tue, 2 May 2000 11:12:00 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA13479; Tue, 2 May 2000 14:11:35 -0400 (EDT) Message-Id: <200005021811.OAA13479@ginger.cmf.nrl.navy.mil> To: "Booker C. Bense" cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "Tue, 02 May 2000 10:04:30 PDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 02 May 2000 14:11:34 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >- Clearly you can solve some of these problems by having the kdc >query the authz service and imbed that in the PAC, but what's the >point? What's the advantage of the KDC doing a static fixed query >that won't provide a complete solution? Seperating these functions >has so many advantages, whereas joining them doesn't seem >to present any clear advantages to me and the disadvantages are >obvious. There _is_ one advantage to including the authorization into the ticket - applications aren't required to do any (extra) work to make authorization decisions. Since they've already got the ticket, they can simply look inside of it to find out the authorization information without having to contact another service (this presumes that the information in the ticket is complete enough to not require lookup in _another_ directory service). This is, in my mind, a incredibly seductive reason to want to do it; you get to save a _whole_ lot of complexity in your application servers, and you don't have to invent a new protocol (okay, you could use LDAP, but you'd still need to put that in your application server). However ... even given all that, I'm not sure that's the right way to go. As people have pointed out, "what you can do" generally changes a _lot_ more often than "who are you", and using the model that Kerberos uses for authorization may not make sense. However, don't ask me what the _right_ thing to do is - I'm not sure. Though in defense of DCE, I don't believe the PAC stuff that DCE used was really all that bad. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:07:33 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07400 for ; Tue, 2 May 2000 15:07:32 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA19710 for ietf-cat-wg-out720680; Tue, 2 May 2000 11:40:43 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA19703 for ; Tue, 2 May 2000 11:40:41 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e42IeYa15972; Tue, 2 May 2000 11:40:34 -0700 (PDT) Date: Tue, 2 May 2000 11:40:34 -0700 (PDT) From: "Booker C. Bense" To: BenC@CoManage.net cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions In-Reply-To: <10F8EB7E5319D31195CF0090277AF2374F8047@srv2.comanagecorp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 2 May 2000 BenC@CoManage.net wrote: > > - Groups, roles, grandfallons... It doesn't matter what you call it, > > it's still the same idea. The difference is fine, but there is one > > between these two : > > > > Hi, I'm Booker Bense and I'm in grandfallon Beta... > > I think you mean "Hi, I'm Booker Bense and here's a blob of data sealed by > somebody we both trust that should prove to you that I'm in grandfallon > Beta." > > > Hello Booker Bense, wait moment while I check if you're in > > grandfallon Beta... > > > > - I wish I could explain it better, but it's taken me 5 years of work > > to really grok the difference and I haven't found a good way to > > explain it. Perhaps the best way is the one scales to any size, > > and the first can only get so big before it becomes unwieldy. > > I hope you're not suggesting that it's more scalable to have servers do > online checks at each credential presentation than it is to have the info > stuffed into a PAC at the beginning of a user's session. - Yes it is. We've been using such a system for years and it works just fine... Everyone has this fixed notion that it "just can't work". I know I did when we started, but in practice it works. It's scalable in terms of people and sysadmin time. It's infinitely more scalable in terms of programmer time. These are our limited resources, CPU and bandwidth are trivally cheap in comparision. People get more expensive and computers get cheaper everyday. > > The PAC option only becomes unwieldy when you (1) make the decision of what > groups/roles to include in the PAC without respect to the actual end use of > the PAC, and (2) tie it so tightly with authentication that the info has to > go even to services that won't use it. > > (1) can be solved by having the client drive the PAC contents in its > request, and (2) can be solved by separating the PAC and the TGT (clients > present the PAC only to servers that will use it). - You're talking about imbedding a real authorization service inside the kerberos protocol. How does the client know what authorization data to request in each service ticket? Why should it even HAVE to know? > > > > Embedding ALL permissions in a PAC is a Bad Idea. (As a simple example: > > > What happens when you add a new securable object to the system? Oops!) > > > > - How do you pick and choose then? I'd object less if I saw a more > > concrete answer to this question. > > You pick and choose by having no permissions in a PAC, just role (/group) > info. - Okay, which roles go in the PAC ? I guess I'm not being clear, I wasn't suggesting that you had to put explict ACL's in a PAC, even just putting all the groups in a PAC is problematic. [stuff about how DCE works deleted] > > There are some bad things about the DCE (one immediate one that comes to > mind is that there was no way to separate the TGS, the PTGS and the security > database, so you couldn't let the PTGS use an MIT KDC for tickets and LDAP > for account info, for example), but IMnsHO, the PAC system wasn't one of > them. > > (Note that I am not defending Microsoft's choice to embed the PAC in the > TGT; I am only defending the abstract notion of a PAC.) - I simply don't agree. There are some advantages of a PAC in a fixed monolithic environment such as DCE or Win2k, but in a more general open environment, I think it causes more problems that it solves. To my mind a PAC doesn't answer the question "What can you do?", it's a more elaborate answer to the question "Who are you?". To my mind, kerberos does this quite well already. - Since the available resources to work on this stuff are so limited I would rather see them focused on a more complete solution to the authorization problem. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:16:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07485 for ; Tue, 2 May 2000 15:16:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA19213 for ietf-cat-wg-out720680; Tue, 2 May 2000 11:35:09 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id LAA19205 for ; Tue, 2 May 2000 11:35:05 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA25518; Tue, 2 May 00 14:16:45 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA21297; Tue, 2 May 2000 14:14:23 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xma021233; Tue, 2 May 2000 14:14:01 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA27970; Tue, 2 May 2000 14:15:49 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA10994; Tue, 2 May 2000 14:13:56 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA06003; Tue, 2 May 2000 14:10:44 -0400 (EDT) Date: Tue, 2 May 2000 14:10:43 -0400 From: Nicolas Williams To: mrex@sap-ag.de Cc: Nicolas Williams , cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000502141042.J1094@sm2p1386swk.wdr.com> References: <20000501132231.A1094@sm2p1386swk.wdr.com> <200005021703.TAA26287@hw1464.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005021703.TAA26287@hw1464.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Tue, May 02, 2000 at 07:03:06PM +0200 X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, May 02, 2000 at 07:03:06PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > I haven't seen Microsoft's spec for the authorization data, > but I think it is not so easy to get it right and I'm wondering > whether Microsoft got it right in their design. Good question. I have seen the spec, but have not read it too thouroughly. See below. > The only reason why systems like to carry around a POSIX-style userid > and group memberships is so that the authorization checks can be > performed by the trusted computing base (TCB) on the server side. Agreed. > In order for the TCB to perform ACL checks for the clients privileges, > the server needs to "run in the context of the client" somehow. > In the Microsoft world, this is called "impersonation". Yup. > On W2K, the LSA performs the client authentication, retrieves the > PAC from inside the service ticket, verifies the signature on the PAC > somehow and then creates an access token that is made available to > the server process. The server process can switch between its own > access token an the access token of the impersonated client whenever > it likes to. The KDC signature is only verified when the service that is trying to impersonate the remote user is NOT a system service. In Unix-speak a system service is akin to a daemon that runs as root. System services obviously can impersonate [locally] any user they know about. The service signature is to be verified by each service. I remember seeing a public MS doc (from Usenix?) that explains that the KDC signature is validated through a NetLogon MSRPC call. I would think that if the signature were made with the LSA host service principal's key then there would be no need for the NetLogon validation call. [All of the above can be derived from various public MS docs on this topic.] > Remember that with Kerberos, service tickets are (a) cached and therefore > reused, (b) have a limited lifetime, and (b) can be "forged" by the service > itself when it knows its own key (which is usually the case). Agreed. > Now the questions that come to my mind: > > (1) is the lifetime of the PAC limited in the same fashion as the > service ticket. It may be a security problem if a service can open > incoming service tickets and save away PACs for unlimited future use > in forged service tickets? Good question. I should probably consult with a lawyer before publically discussing MS's spec, as the onerous language under which it is licensed might make me liable for civil penalties should I reveal any of its contents publically. ;^) Oh, and, I'm not sure I want to contribute to a free-of-charge analysis of a spec so licensed. > (2) is the PAC tied to the particular service/target, or could an > arbitrary service use the PAC in a forged ticket to have an > access token created? Same answer as (1). > (3) is the PAC limited to a particular target host, or can the PAC > be reused in a forged ticket on a different host? Same answer as (1). > Keep in mind that impersonation is the default with Microsoft's SSPI, > so whenever a domain admin touches Microsoft services on a remote > machine in the domain, his PAC will be unconditionally handed to > this machine. Therefore if you have accidental or intentional > admin access on one machine of the domain you may be able to > collect PACs and eventually use them on other machines of the > domain where you have access, but no admin access yet... > > So whatever you plan to do in the authorization are, be very careful > of the security implications. Indeed. > > -Martin Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:35:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07830 for ; Tue, 2 May 2000 15:35:38 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id LAA21069 for ietf-cat-wg-out720680; Tue, 2 May 2000 11:51:48 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA21035 for ; Tue, 2 May 2000 11:51:43 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA14046; Tue, 2 May 2000 14:51:36 -0400 (EDT) Message-Id: <200005021851.OAA14046@ginger.cmf.nrl.navy.mil> To: "Booker C. Bense" cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "Tue, 02 May 2000 11:40:34 PDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 02 May 2000 14:51:35 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >- Yes it is. We've been using such a system for years and it works >just fine... Everyone has this fixed notion that it "just can't work". Well, crack out the source code, then! :-) >- You're talking about imbedding a real authorization service inside >the kerberos protocol. How does the client know what authorization >data to request in each service ticket? Why should it even HAVE to >know? (Playing devil's advocate) - certainly the KDC could figure out what needs to go in every ticket. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:38:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07849 for ; Tue, 2 May 2000 15:38:23 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22766 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:08:50 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA22754 for ; Tue, 2 May 2000 12:08:47 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e42J8jk16159; Tue, 2 May 2000 12:08:45 -0700 (PDT) Date: Tue, 2 May 2000 12:08:45 -0700 (PDT) From: "Booker C. Bense" To: Ken Hornstein cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: <200005021811.OAA13479@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 2 May 2000, Ken Hornstein wrote: > >- Clearly you can solve some of these problems by having the kdc > >query the authz service and imbed that in the PAC, but what's the > >point? What's the advantage of the KDC doing a static fixed query > >that won't provide a complete solution? Separating these functions > >has so many advantages, whereas joining them doesn't seem > >to present any clear advantages to me and the disadvantages are > >obvious. > > There _is_ one advantage to including the authorization into the ticket - > applications aren't required to do any (extra) work to make authorization > decisions. Since they've already got the ticket, they can simply > look inside of it to find out the authorization information without > having to contact another service (this presumes that the information > in the ticket is complete enough to not require lookup in _another_ > directory service). This is, in my mind, a incredibly seductive reason > to want to do it; you get to save a _whole_ lot of complexity in your > application servers, and you don't have to invent a new protocol (okay, > you could use LDAP, but you'd still need to put that in your application > server). - This is only an advantage if you have a pretty firm grasp on what's in that bit of authorization info. Unless everybody is playing on the same field it becomes a quagmire pretty quickly. It's always tempting to grasp at the quick & cheap solution, but you pay for it in the long run[1]. Of course I fully expect that my track record in these matters will continue ( I've been 100% on the losing side of every protocol debate I've ever bothered with. ) > > However ... even given all that, I'm not sure that's the right way > to go. As people have pointed out, "what you can do" generally changes > a _lot_ more often than "who are you", and using the model that > Kerberos uses for authorization may not make sense. However, don't > ask me what the _right_ thing to do is - I'm not sure. > > - Well, I'm not sure what the answer is either. In fact, in classic fashion I think we've gotten totally sidetracked from the real question. How do we close the loophole MS has used in the kerberos protocol? - As I see it there are only two choices: A. Declare the auth dat field null and void. B. Write a complete specification of the data and use of it. MS will ignore both since it's already deployed, in fact I'm not sure we can do B legally given the "license" agreement of MS's protocol specification. - Booker C. Bense [1] - See the long tortured history of the http protocol. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:45:16 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07910 for ; Tue, 2 May 2000 15:45:15 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA23080 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:14:14 -0700 (PDT) Received: from perq.cac.washington.edu (perq.cac.washington.edu [140.142.110.198]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA23074 for ; Tue, 2 May 2000 12:14:12 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id MAA06414; Tue, 2 May 2000 12:13:47 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Tue, 2 May 2000 12:13:46 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: BenC@CoManage.net cc: IETF CAT Working Group , krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions In-Reply-To: <10F8EB7E5319D31195CF0090277AF2374F8047@srv2.comanagecorp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 2 May 2000 BenC@CoManage.net wrote: > I hope you're not suggesting that it's more scalable to have servers > do online checks at each credential presentation than it is to have > the info stuffed into a PAC at the beginning of a user's session. > > The PAC option only becomes unwieldy when you (1) make the decision of > what groups/roles to include in the PAC without respect to the actual > end use of the PAC, and (2) tie it so tightly with authentication that > the info has to go even to services that won't use it. > > (1) can be solved by having the client drive the PAC contents in its > request, So, the client has to know which of its many privilege attributes to put into the PAC that it sends to a particular service. This would require the client to know the contents of ACLs on resources managed by that service, since those ACLs might contain references to groups that the user is in (and group membership is mostly what's in the PAC). How can this possibly work? In practice, to my knowledge, systems that use PACs send all the user's privilege attributes in a lump when initiating a session to any service. If there's a system that works otherwise (maybe SESAME) I'd be fascinated to learn how the client decides which attributes to send. So, in practice, every server finds out all details about every user, which is a privacy problem, as well as a scaling problem as group membership increases (not to mention the nested-groups problem). I think that work on PKI-based attribute cert schemes (eg KeyNote, SPKI) has led in the direction of negotiation between client and server about which attributes the server needs to make an access control decision, but this is still very much in the research stage as far as I know. - RL "Bob" -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:47:56 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07929 for ; Tue, 2 May 2000 15:47:55 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA23459 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:19:21 -0700 (PDT) Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA23453 for ; Tue, 2 May 2000 12:19:18 -0700 (PDT) Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 1AED315533; Tue, 2 May 2000 15:18:47 -0400 (EDT) Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 4F3CB7C0E8; Tue, 2 May 2000 15:18:47 -0400 (EDT) Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <2YFW3V6M>; Tue, 2 May 2000 15:20:46 -0400 Message-ID: From: "Salz, Rich" To: "'Ken Hornstein'" , "Booker C. Bense" Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 2 May 2000 15:20:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Since the KRB spec has always said that that TGT pacdata is always copied over to tickets, then clearly the dog feels authz data should be bundled. :) DCE actually followed the letter and spirit: the authentication server was separate from the privilege server. They were just bundled into a single executable for efficiency. Do a klist on a DCE system some time (if you can find one :). As Ken pointed out, it is significant to save apps the extra work, the extra tickets (why should a server ever have to "log in" -- get a TGT?), etc. More importantly, it makes sense. It seems arbitrary to me that a ticket conveys just a stringname. My "identity" is not only my name, but the groups and realms I belong to, etc. The problem becomes obvious when you want to do this in a heterogeneous world, but it was always there. Just now, you're requiring everyone to map to/from Posix (sic) identities, not just stringnames to account names (rsalz@osf.org vs Twenex "dcb.tech" vs VMS salzr, etc), it becomes obvious that things are ugly. There are many aspects to authorization, beyond securely knowing the client identity. Knowing that "Jill Salz, BofA Teller" is who she says she is, says nothing about whether she can cash a $100K check. Those things will always very. Who I am -- who you are -- hardly varies. And certainly it rarely changes within a ticket lifetime. /r$ -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 15:59:44 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07982 for ; Tue, 2 May 2000 15:59:43 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA23989 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:28:29 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA23974 for ; Tue, 2 May 2000 12:28:25 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id PAA08947; Tue, 2 May 2000 15:28:15 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xmaa08780; Tue, 2 May 2000 15:27:35 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA03584; Tue, 2 May 2000 15:29:24 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id PAA02724; Tue, 2 May 2000 15:27:31 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id PAA06400; Tue, 2 May 2000 15:24:19 -0400 (EDT) Date: Tue, 2 May 2000 15:24:18 -0400 From: Nicolas Williams To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000502152417.L1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005021851.OAA14046@ginger.cmf.nrl.navy.mil> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, 02 May 2000, Ken Hornstein wrote: > >- Yes it is. We've been using such a system for years and it works > >just fine... Everyone has this fixed notion that it "just can't work". > > Well, crack out the source code, then! :-) > > >- You're talking about imbedding a real authorization service inside > >the kerberos protocol. How does the client know what authorization > >data to request in each service ticket? Why should it even HAVE to > >know? > > (Playing devil's advocate) - certainly the KDC could figure out what needs > to go in every ticket. Indeed! If the KDC knows what kind of service the target service of an AS_REQ or TGS_REQ is, then it can put whatever data is appropriate in the ticket. This just moves around responsibility, but if you're looking to protect the database that holds that data from anonymous or nearly-anonymous lookups, then this is the best way to accomplish that. Note that the KDC could either embed the user login data in the ticket, or it could embed a token in the ticket that the service can use to lookup the data on its own. The token could simply be a ticket for that service to access the database records in question on behalf of the user. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 16:06:33 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08111 for ; Tue, 2 May 2000 16:06:32 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA24754 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:40:52 -0700 (PDT) Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA24748 for ; Tue, 2 May 2000 12:40:49 -0700 (PDT) Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id ADD6715533; Tue, 2 May 2000 15:40:18 -0400 (EDT) Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 612D07C0E8; Tue, 2 May 2000 15:40:18 -0400 (EDT) Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <2YFW3V7C>; Tue, 2 May 2000 15:42:17 -0400 Message-ID: From: "Salz, Rich" To: "'RL 'Bob' Morgan'" , BenC@CoManage.net Cc: IETF CAT Working Group , krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 2 May 2000 15:42:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk It's hard to see how delegation and "least privilege" can be implemented without putting the credentials into the ticket. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 16:17:54 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08180 for ; Tue, 2 May 2000 16:17:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA24794 for ietf-cat-wg-out720680; Tue, 2 May 2000 12:41:25 -0700 (PDT) Received: from coserver2.CoManagecorp.com (srv2.comanagecorp.com [209.195.154.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA24782 for ; Tue, 2 May 2000 12:41:20 -0700 (PDT) From: BenC@CoManage.net Received: by srv2.comanagecorp.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 15:38:04 -0400 Message-ID: <10F8EB7E5319D31195CF0090277AF2374F80E9@srv2.comanagecorp.com> To: rlmorgan@washington.edu Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 2 May 2000 15:37:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk RL "Bob" Morgan writes: > So, the client has to know which of its many privilege > attributes to put into the PAC that it sends to a > particular service. This would require the client to > know the contents of ACLs on resources managed by that > service, since those ACLs might contain references to > groups that the user is in (and group membership is > mostly what's in the PAC). How can this possibly work? Or the client and the server could negotiate, or a client designed to work with a particular service could know a set of predefined roles for that service, or it could be in configuration info available to clients of that service (say, maybe co-located with the information that the client used to find the service to start with!). -- Ben -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 16:28:18 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08305 for ; Tue, 2 May 2000 16:28:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA26106 for ietf-cat-wg-out720680; Tue, 2 May 2000 13:00:21 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA26096 for ; Tue, 2 May 2000 13:00:18 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA27415; Tue, 2 May 00 15:35:22 EDT Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id PAA14581; Tue, 2 May 2000 15:31:19 -0400 (EDT) Message-Id: <200005021931.PAA14581@ginger.cmf.nrl.navy.mil> To: Nicolas Williams Cc: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Tue, 02 May 2000 14:10:43 EDT." <20000502141042.J1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 02 May 2000 15:31:18 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >The KDC signature is only verified when the service that is trying to >impersonate the remote user is NOT a system service. In Unix-speak a >system service is akin to a daemon that runs as root. System services >obviously can impersonate [locally] any user they know about. > >The service signature is to be verified by each service. > >I remember seeing a public MS doc (from Usenix?) that explains that the >KDC signature is validated through a NetLogon MSRPC call. I would think >that if the signature were made with the LSA host service principal's >key then there would be no need for the NetLogon validation call. Hm, okay, I think I see the confusion here. ISTR that the way this is going to be handled is by the use of the new AD-KDCIssued authorization data typed. This is protected by a keyed checksum (the same key used to protect the rest of the ticket). I _thought_ that the only verification of the authorization ticket done was verifying that this checksum is correct. But given that you're going to do _that_, I believe there is a valid trust chain between the KDC and server, so no additional verification would be needed. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 17:13:17 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08988 for ; Tue, 2 May 2000 17:13:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA00591 for ietf-cat-wg-out720680; Tue, 2 May 2000 13:35:22 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA00586 for ; Tue, 2 May 2000 13:35:19 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA13161; Tue, 2 May 00 16:15:26 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id QAA22181; Tue, 2 May 2000 16:13:02 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma022140; Tue, 2 May 2000 16:12:36 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA07437; Tue, 2 May 2000 16:16:12 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA21305; Tue, 2 May 2000 16:12:32 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id QAA06695; Tue, 2 May 2000 16:09:20 -0400 (EDT) Date: Tue, 2 May 2000 16:09:20 -0400 From: Nicolas Williams To: Ken Hornstein Cc: Nicolas Williams , cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000502160918.M1094@sm2p1386swk.wdr.com> References: <20000502141042.J1094@sm2p1386swk.wdr.com> <200005021931.PAA14581@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005021931.PAA14581@ginger.cmf.nrl.navy.mil>; from kenh@cmf.nrl.navy.mil on Tue, May 02, 2000 at 03:31:18PM -0400 X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, May 02, 2000 at 03:31:18PM -0400, Ken Hornstein wrote: > >The KDC signature is only verified when the service that is trying to > >impersonate the remote user is NOT a system service. In Unix-speak a > >system service is akin to a daemon that runs as root. System services > >obviously can impersonate [locally] any user they know about. > > > >The service signature is to be verified by each service. > > > >I remember seeing a public MS doc (from Usenix?) that explains that the > >KDC signature is validated through a NetLogon MSRPC call. I would think > >that if the signature were made with the LSA host service principal's > >key then there would be no need for the NetLogon validation call. > > Hm, okay, I think I see the confusion here. > > ISTR that the way this is going to be handled is by the use of the new > AD-KDCIssued authorization data typed. This is protected by a keyed > checksum (the same key used to protect the rest of the ticket). I > _thought_ that the only verification of the authorization ticket done > was verifying that this checksum is correct. But given that you're > going to do _that_, I believe there is a valid trust chain between > the KDC and server, so no additional verification would be needed. The second signature, the one signed with the KDC's key, is there so that non-system services (services that don't have local priviledges to start with, i.e., services which "don't run as root") can ask the OS to let them assume the credentials of the remote user. In such cases the OS has to check a PAC signature that the service itself couldn't fake. This is the reason for the second signature. I think this problem could be handled differently, as I've said before, which would not require that NetLogon RPC call. But I do think that the second signature is indeed needed. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 19:15:15 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10225 for ; Tue, 2 May 2000 19:15:13 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA08564 for ietf-cat-wg-out720680; Tue, 2 May 2000 15:20:23 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.12.23]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id PAA08553 for ; Tue, 2 May 2000 15:20:20 -0700 (PDT) Received: (qmail 18046 invoked by uid 50); 2 May 2000 22:20:20 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <20000502121102.I1094@sm2p1386swk.wdr.com> In-Reply-To: Nicolas Williams's message of "Tue, 2 May 2000 12:11:03 -0400" From: Russ Allbery Organization: The Eyrie Date: 02 May 2000 15:20:19 -0700 Message-ID: Lines: 152 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Nicolas Williams writes: > On 01 May 2000, Russ Allbery wrote: >> I've never seen the intermingling of an authorization system with an >> authentication system cause anything other than severe pain. cf DCE. > But it's a reality with Windows 2000. I think Windows 2000 is here to > stay. That's what people said about DCE too. And we're hardly the only site that tried to go to DCE and then decided that was a really bad idea and changed *back*. Admittedly, Microsoft has a lot of marketing muscle, but under the hood it looks like the same bad ideas. >> Why would this require authorization rather than just authentication? >> Kerberos tickets have authentication information: principal and realm. > Because, see, if you don't put this information in the ticket, then > every server a user could log into must be able to look up that user's > login info. I have a few reactions to that. First of all, login information is not historically secret, and I'm not sure how much you're actually gaining except in some specific circumstances by making it so. But it does fall under the category of something that you don't necessarily have to allow, so for paranoia's sake it may be better to cut off access to it. Second, while it may be difficult to do so, it's quite *possible* to require that the user give you permission to look up their login data before you can do so. This could require some thought as to how to integrate this with how Kerberos functions, and it could be difficult to do so cleanly. On the other hand, the same thing applies to embedding authorization data in the ticket. I would *much* rather see general support for external authorization systems using Kerberos than see Kerberos be turned into an all-signing, all-dancing protocol that attempts to do everything. To me, this is basic system design; do what you know how to do well and rather than try to do other things that you don't know how to do well, provide a well-defined way to plug in another system that does only that other thing. Monolithic systems are inherently bad. Booker's point is key here: The lifetime of authorization data and the lifetime of authentication data are frequently *completely* different. Kerberos answers the question "who are you?". It was not designed to answer the question "what can you do?", and that's a *completely* different question. It's also not designed to be a generic network database of information about a user, which is what doing things like embedding home directory information and the like into the ticket would try to turn it into. Basically, what I'm hearing is a proposal to turn Kerberos into essentially a "super NIS." I think this is a very bad idea. One of the strengths of Kerberos is that it's exclusively an authentication protocol and leaves network distribution of account attributes and authorization information up to other protocols, thus allowing it to be easily used with NIS, Hesiod, LDAP, and other protocols that were *designed* to be the network accessible database that Kerberos isn't. > But this means, in practice, that any user can lookup up any other > user's login info (oh, you can make it really hard for this to happen, > but still). This is what I meant by semi-anonymous, because with such a > scheme you can never tell the identity of the user on whose behalf a > service is performing the lookup. So do you not believe this to be a fixable problem? Let's take a step back. What is the problem that we're trying to solve? It seems to me that what people want is a database which maps the pair (server identity, user identity) to a set of data about the user, possibly including authorization information. Different server identities may be able to get different amounts of information. We've already implemented precisely this at Stanford, and I know other people have done the same thing elsewhere. We used LDAP. A server identity queries an LDAP server for entries matching a user identity and gets back various information about their account, including in some cases authorization information. What we haven't done, and what you seem to be wanting, is a way to prevent an authorized server identity from enumerating the user space. While I'm iffy as to how serious of a security risk that really is, I can understand that desire. Rather than try to solve this problem by mushing together two separate systems, how can we provide the authorization service sufficient information to implement that security policy? I think that would be a much more productive question to answer, and would lead to a better overall design. > The only ways that I can see to achieve this effect are: > 1) put the login info in the tickets; > or > 2) forward a proxied ticket to the service that a user is connecting to > that would allow the service to lookup the user's login info on the > user's behalf. > Microsoft chose the former. Note also that with the former the lookup > for the login info need only be done ONCE, when the user logs in (i.e., > when the system she logs into requests a TGT for the user). > I find this to be elegant. I have the exact opposite position; I find the second to be more elegant, if complex. (I don't really find either to be truly elegant.) Although proxy tickets aren't the entire solution to the problem; the key point is that the server's authentication to the authorization service is the *combination* of the server and user identity. The first solution is pure brute force. In essence, it's solving the problem of defining a clean API by combining two separate systems so as to try to avoid needing an API. What you end up with as a result is an ungodly incestuous mess where both parts of the system know way too much about the internals of the other, and down the road when you want to do authorization via some completely separate database, you have to figure out how to integrate that database into Kerberos and deal with all the interaction issues. > And I can't see how it causes headaches, though I can see that once a > TGT has been issued to a user then the associated login info cannot be > changed for that session, This is a problem. > nor can the ticket be revoked, but that is a feature of Kerberos, so the > situation is not worsened by putting login info in the tickets. No, you're missing the fundamental shift in how everything works once you go beyond an authentication system into an authorization system. Kerberos establishes your *identity*. In that realm, it makes sense to not worry too much about your identity changing, because your identity will very rarely ever change. If I want to stop you from doing something, say creating a new user principal, I remove you from the ACL (the authorization service) and that change takes place immediately. I don't have to revoke your identity and wait for your active tickets to expire. If you embed that authorization data into the ticket, I can't just remove you from the ACL. I have to tell Kerberos to not generate a ticket that says "this user can create new users," and then I have to wait for all of your existing tickets to expire. This is a serious problem. Privileges need to be revocable on a faster time scale than ticket expiration. By tying authorization to authentication, you force people to revoke someone's *identity* to revoke their *privileges*, which is a fundamentally broken model. -- Russ Allbery (rra@stanford.edu) -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 19:47:44 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10489 for ; Tue, 2 May 2000 19:47:44 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA11702 for ietf-cat-wg-out720680; Tue, 2 May 2000 16:08:01 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA11694 for ; Tue, 2 May 2000 16:07:59 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e42N7o419776; Tue, 2 May 2000 16:07:50 -0700 (PDT) Date: Tue, 2 May 2000 16:07:50 -0700 (PDT) From: "Booker C. Bense" To: "Salz, Rich" cc: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk - Well, from my point of view everything in this message supports my point. If it's answering the question "Who are you?" it's not authorization. On Tue, 2 May 2000, Salz, Rich wrote: > Since the KRB spec has always said that that TGT pacdata is always copied > over to tickets, then clearly the dog feels authz data should be bundled. :) > - I think the whole point of this debate is that the spec is insufficient defined at this point to do anything with authorization data. The question is do we define it or just throw it out? > DCE actually followed the letter and spirit: the authentication server was > separate from the privilege server. They were just bundled into a single > executable for efficiency. Do a klist on a DCE system some time (if you can > find one :). > > As Ken pointed out, it is significant to save apps the extra work, the extra > tickets (why should a server ever have to "log in" -- get > a TGT?), etc. - Because it's secure and extensible and a much better model? - When this model was first suggested at Stanford I was a dubious as anybody. I was definitely in the "why should a server ever have to log in " camp, but after a few years of writing code and running applications it's entirely clear to me that this is a MUCH better model. > > More importantly, it makes sense. It seems arbitrary to me that > a ticket conveys just a stringname. My "identity" is not only my > name, but the groups and realms I belong to, etc. The problem becomes > obvious when you want to do this in a heterogeneous world, but it was > always there. Just now, you're requiring everyone to map to/from Posix (sic) > identities, not just stringnames to account names (rsalz@osf.org vs Twenex > "dcb.tech" vs VMS salzr, etc), it becomes obvious that things are ugly. > - The krbname makes a great opaque key, I think you make my point with this paragraph. How can we possibly come up with anything that makes sense to put in a PAC in a heterogenous environment? > There are many aspects to authorization, beyond securely knowing the client > identity. Knowing that "Jill Salz, BofA Teller" is who she says she is, says > nothing about whether she can cash a $100K check. > > Those things will always very. Who I am -- who you are -- hardly varies. > And certainly it rarely changes within a ticket lifetime. - I think this is exactly my point. At best a PAC answers "who are you?" it can never provide a good solution to the question "what can you do?". I am totally convinced that the more you pull these two questions apart the better system you can build. The tighter you bundle them the sooner you run into roadblocks. All I want kerberos to give me is a secure unique identifier. Putting anything else in the protocol is just so much useless baggage. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 20:10:31 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10694 for ; Tue, 2 May 2000 20:10:30 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA13327 for ietf-cat-wg-out720680; Tue, 2 May 2000 16:26:46 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA13313 for ; Tue, 2 May 2000 16:26:42 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id TAA04903; Tue, 2 May 2000 19:24:28 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma004689; Tue, 2 May 2000 19:23:42 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id TAA19960; Tue, 2 May 2000 19:27:18 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id TAA14835; Tue, 2 May 2000 19:23:34 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id TAA07582; Tue, 2 May 2000 19:20:21 -0400 (EDT) Date: Tue, 2 May 2000 19:20:21 -0400 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Cc: Russ Allbery Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000502192020.P1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On 02 May 2000, Russ Allbery wrote: > Nicolas Williams writes: > > On 01 May 2000, Russ Allbery wrote: > > >> I've never seen the intermingling of an authorization system with an > >> authentication system cause anything other than severe pain. cf DCE. > > > But it's a reality with Windows 2000. I think Windows 2000 is here to > > stay. > > That's what people said about DCE too. And we're hardly the only site > that tried to go to DCE and then decided that was a really bad idea and > changed *back*. Admittedly, Microsoft has a lot of marketing muscle, but > under the hood it looks like the same bad ideas. Marketing and the like make a big difference. > >> Why would this require authorization rather than just authentication? > >> Kerberos tickets have authentication information: principal and realm. > > > Because, see, if you don't put this information in the ticket, then > > every server a user could log into must be able to look up that user's > > login info. > > I have a few reactions to that. > > First of all, login information is not historically secret, and I'm not > sure how much you're actually gaining except in some specific > circumstances by making it so. But it does fall under the category of > something that you don't necessarily have to allow, so for paranoia's sake > it may be better to cut off access to it. > > Second, while it may be difficult to do so, it's quite *possible* to > require that the user give you permission to look up their login data > before you can do so. This could require some thought as to how to > integrate this with how Kerberos functions, and it could be difficult to > do so cleanly. On the other hand, the same thing applies to embedding > authorization data in the ticket. Yes. This was my thought as to a possible alternative to the DCE/MS approach. > I would *much* rather see general support for external authorization > systems using Kerberos than see Kerberos be turned into an all-signing, > all-dancing protocol that attempts to do everything. To me, this is basic > system design; do what you know how to do well and rather than try to do > other things that you don't know how to do well, provide a well-defined > way to plug in another system that does only that other thing. Monolithic > systems are inherently bad. > > Booker's point is key here: The lifetime of authorization data and the > lifetime of authentication data are frequently *completely* different. > Kerberos answers the question "who are you?". Agreed. But it doesn't answer that question very well. You still need to map the Kerberos principals to platform-specific usernames, where possible. > It was not designed to > answer the question "what can you do?", and that's a *completely* > different question. It's also not designed to be a generic network > database of information about a user, which is what doing things like > embedding home directory information and the like into the ticket would > try to turn it into. No, I don't want Kerberos to answer "what can you do?". > Basically, what I'm hearing is a proposal to turn Kerberos into > essentially a "super NIS." I think this is a very bad idea. One of the > strengths of Kerberos is that it's exclusively an authentication protocol > and leaves network distribution of account attributes and authorization > information up to other protocols, thus allowing it to be easily used with > NIS, Hesiod, LDAP, and other protocols that were *designed* to be the > network accessible database that Kerberos isn't. Ok. > > But this means, in practice, that any user can lookup up any other > > user's login info (oh, you can make it really hard for this to happen, > > but still). This is what I meant by semi-anonymous, because with such a > > scheme you can never tell the identity of the user on whose behalf a > > service is performing the lookup. > > So do you not believe this to be a fixable problem? Not unless one of the two approaches I suggested below is used. > Let's take a step back. What is the problem that we're trying to solve? > It seems to me that what people want is a database which maps the pair > (server identity, user identity) to a set of data about the user, possibly > including authorization information. Different server identities may be > able to get different amounts of information. Ok. > We've already implemented precisely this at Stanford, and I know other > people have done the same thing elsewhere. We used LDAP. A server > identity queries an LDAP server for entries matching a user identity and > gets back various information about their account, including in some cases > authorization information. > > What we haven't done, and what you seem to be wanting, is a way to prevent > an authorized server identity from enumerating the user space. While I'm > iffy as to how serious of a security risk that really is, I can understand > that desire. Rather than try to solve this problem by mushing together > two separate systems, how can we provide the authorization service > sufficient information to implement that security policy? Right. As I said, I think MS chose to consider anonymous lookups of login info to be a problem because it got a lot of heat about it. For a recent reference, see Luke Kenneth Casson Leighton's book on reverse engineering the MS Windows NT domain protocols. Actually, I'm speculating as to why MS chose this approach, but I can see no other reason, and after reading various parts of the Windows 2000 server resource kit where the point is emphasized that with AD you can disallow anonymous enumeration of you user info, I am very certain that this was at least one of MS's motivations for pursuing the PAC-in-the-ticket approach. > I think that would be a much more productive question to answer, and would > lead to a better overall design. > > > The only ways that I can see to achieve this effect are: > > > 1) put the login info in the tickets; > > > or > > > 2) forward a proxied ticket to the service that a user is connecting to > > that would allow the service to lookup the user's login info on the > > user's behalf. > > > Microsoft chose the former. Note also that with the former the lookup > > for the login info need only be done ONCE, when the user logs in (i.e., > > when the system she logs into requests a TGT for the user). > > > I find this to be elegant. > > I have the exact opposite position; I find the second to be more elegant, > if complex. (I don't really find either to be truly elegant.) Although > proxy tickets aren't the entire solution to the problem; the key point is > that the server's authentication to the authorization service is the > *combination* of the server and user identity. Yes. I agree about the latter and I think that the second approach I suggested is a very general and open approach. (1) could be as well, if standardized and desgined well. (1) allows the lookup to be done once, (2) scales better (because the ticket size stays constant, regardless of the amount of data that would otherwise be associated with a ticket under (1)). It's a tradeoff. I'd be glad with either. > The first solution is pure brute force. In essence, it's solving the > problem of defining a clean API by combining two separate systems so as to > try to avoid needing an API. What you end up with as a result is an > ungodly incestuous mess where both parts of the system know way too much > about the internals of the other, and down the road when you want to do > authorization via some completely separate database, you have to figure > out how to integrate that database into Kerberos and deal with all the > interaction issues. I suggested a clean approach, not the current mess MS chose to foist on the world. > > And I can't see how it causes headaches, though I can see that once a > > TGT has been issued to a user then the associated login info cannot be > > changed for that session, > > This is a problem. So? Whenever you add a user to a group that she needed to be a member of you have to tell the user that they must log out and then log in again for the change to become effective. This is true of Windows and Unix platforms in general TODAY. Thus this problem is not new and will likely never go away. So adding system credential information to Kerberos tickets does not make the current situation _any worse_. > > nor can the ticket be revoked, but that is a feature of Kerberos, so the > > situation is not worsened by putting login info in the tickets. > > No, you're missing the fundamental shift in how everything works once you > go beyond an authentication system into an authorization system. Kerberos > establishes your *identity*. In that realm, it makes sense to not worry > too much about your identity changing, because your identity will very > rarely ever change. If I want to stop you from doinneed to be revocable on a faster > time scale than ticket expiration. By tying authorization to > authentication, you force people to revoke someone's *identity* to revoke > their *privileges*, which is a fundamentally broken model. No. I'm not missing the point. I'm only arguing for the presence of platform-specific system credential information in Kerberos tickets, encoded in a general, open, extensible, sensible way and with verifiable ticket signatures to prevent forging. And I'm arguing, in general, for (1) or (2) primarily because something must be done about Microsoft's extensions without forcing MS to allow anonymous lookups of their directory, otherwise the chances of MS going along with the new standard will be very small, nill even. Moreover, I still think that either (1) or (2) would be an improvement over what we have now. If we give proprietary vendors an open solution that fulfills their needs then we're giving them an incentive to implement the open standard. > -- > Russ Allbery (rra@stanford.edu) Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 2 20:45:55 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11051 for ; Tue, 2 May 2000 20:45:55 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA15270 for ietf-cat-wg-out720680; Tue, 2 May 2000 16:55:47 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.12.23]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA15265 for ; Tue, 2 May 2000 16:55:44 -0700 (PDT) Received: (qmail 18417 invoked by uid 50); 2 May 2000 23:55:43 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <20000502192020.P1094@sm2p1386swk.wdr.com> In-Reply-To: Nicolas Williams's message of "Tue, 2 May 2000 19:20:21 -0400" From: Russ Allbery Organization: The Eyrie Date: 02 May 2000 16:55:43 -0700 Message-ID: Lines: 89 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Nicolas Williams writes: > No. I'm not missing the point. I'm only arguing for the presence of > platform-specific system credential information in Kerberos tickets, > encoded in a general, open, extensible, sensible way and with verifiable > ticket signatures to prevent forging. Right, I think I'm following better now. Thanks for the clarifications. I think part of the question we're debating is what constitutes an identity and how much application-specific information about an identity should Kerberos be tasked with providing. Currently, Kerberos provides just a principal and realm, and leaves derivation of any further identity information to the application. I'm pretty strongly of the opinion that the groups or roles that a person has are authorization information, fundamentally, and not identity information, but then I have a pretty strict notion of what I consider to be identity information. To me, an identity is fundamentally a one-to-one mapping, not a one-to-many mapping; in other words, you act as only one identity at any given time, which is fundamentally incompatible with having group membership be considered identity information. The reason for this stance, at least for me, comes from how people use groups and roles once they exist. If you provide group information, that information is used as-is for authorization purposes, even if it wasn't intended to be used that way. We have enough problems dealing with applications that use the mere existence of a Kerberos identity for authorization purposes, and in an ideal world all of those would also go away. If you have a role group, such as "humanities and sciences" to pick an example relevant to our particular situation, and incorporate that information in Kerberos tickets, I guarantee that the first thing that someone who is trying to restrict logins on a server to just H&S affiliates will do is allow logins for anyone who has that group membership in their ticket. Instantly, this information that may have originally been perceived as identity information has become authorization information, with all of the lifetime problems inherent in that. Those of you who have been here can predict what happens next. Some H&S student abuses the system, or just shouldn't have access to it for some reason, and the authorization model for logins to that system is now tightly coupled with this identity information. So the H&S folks ask the Kerberos folks to remove this person from the H&S group so that they can't log on to that server. And now you've got a collision between identity information and authorization information (the person *is* affiliated with H&S), plus you're now making changes to the authentication database to effect authorization changes. I argue that this is the place you don't want to be. Once you've ended up here, you have fundamental design problems with your authorization model that will be painful to work around and painful to fix. > And I'm arguing, in general, for (1) or (2) primarily because something > must be done about Microsoft's extensions without forcing MS to allow > anonymous lookups of their directory, otherwise the chances of MS going > along with the new standard will be very small, nill even. The chances of MS going along with anything that provides open standards for something that they're attempting to market as a special feature of their particular environment seem slim to me. I don't have any good solutions here either, but it seriously galls me to be considering moving towards a model not really on the grounds that it's a superior solution but on the grounds that MS will force it on us with marketing. > Moreover, I still think that either (1) or (2) would be an improvement > over what we have now. If we give proprietary vendors an open solution > that fulfills their needs then we're giving them an incentive to > implement the open standard. Doing the authorization queries against an external database using the Kerberos identity information as the key works. We've widely deployed it and related systems at Stanford for a variety of different applications, and in fact using LDAP for this seems to scale even better than a standard Kerberos server setup. LDAP has real-time replication, something akin to commits and rollbacks, changelogs that can be replayed, and lots of other protocol infrastructure aimed at solving the distribution, scaling, and replication problems even better than Kerberos's support for multiple authentication servers. Unsurprisingly, I agree strongly with Booker: having the server obtain its own identity and query an external server using that identity works fairly reliably, is fairly easy to maintain, reduces the burden on the Kerberos administrators significantly, and just doesn't involve that much processing time for the servers. -- Russ Allbery (rra@stanford.edu) -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 11:25:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04270 for ; Wed, 3 May 2000 11:25:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA19896 for ietf-cat-wg-out720680; Wed, 3 May 2000 07:37:11 -0700 (PDT) Received: from small-gods.mit.edu (SMALL-GODS.MIT.EDU [18.177.0.248]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id HAA19891 for ; Wed, 3 May 2000 07:37:09 -0700 (PDT) Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id KAA11415; Wed, 3 May 2000 10:36:49 -0400 (EDT) Message-Id: <200005031436.KAA11415@small-gods.mit.edu> To: "Booker C. Bense" cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Tue, 02 May 2000 16:07:50 PDT." Date: Wed, 03 May 2000 10:36:49 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> As Ken pointed out, it is significant to save apps the extra work, >> the extra tickets (why should a server ever have to "log in" -- get >> a TGT?), etc. > - Because it's secure and extensible and a much better model? Separating out authorization database from the KDC database does not implicitly require the servers (other than the authorization server) to "log in." Here is an example: 1. User gets TGT (containing no auth data) 2. User contacts authorization server and presents a ticket and authenticator, and asks for authorization data for "fooservice". 3. Authorization server gets credentials for "fooservice". 4. Authorization server sends to user its ticket (not the session key, of course) and sends the authorization data sealed using its session key. 5. User contacts "fooservice" and presents its normal ticket and authenticator, plus the bundle it got from the authorization server. The server can now verify the authorization data using the session key located in the authorization server's ticket. No need for the server to go off and check. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 12:01:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05074 for ; Wed, 3 May 2000 12:01:23 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id IAA22681 for ietf-cat-wg-out720680; Wed, 3 May 2000 08:28:47 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA22669 for ; Wed, 3 May 2000 08:28:42 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA28567; Wed, 3 May 2000 11:28:40 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma028404; Wed, 3 May 2000 11:28:14 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA13587; Wed, 3 May 2000 11:31:49 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA18467; Wed, 3 May 2000 11:28:10 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA09264; Wed, 3 May 2000 11:24:57 -0400 (EDT) Date: Wed, 3 May 2000 11:24:56 -0400 From: Nicolas Williams To: "Booker C. Bense" Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503112455.Q1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031436.KAA11415@small-gods.mit.edu> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 03 May 2000, Greg Hudson wrote: > >> As Ken pointed out, it is significant to save apps the extra work, > >> the extra tickets (why should a server ever have to "log in" -- get > >> a TGT?), etc. > > > - Because it's secure and extensible and a much better model? > > Separating out authorization database from the KDC database does not > implicitly require the servers (other than the authorization server) > to "log in." > > Here is an example: > > 1. User gets TGT (containing no auth data) > 2. User contacts authorization server and presents a ticket > and authenticator, and asks for authorization data for > "fooservice". > 3. Authorization server gets credentials for "fooservice". > 4. Authorization server sends to user its ticket (not the > session key, of course) and sends the authorization data > sealed using its session key. > 5. User contacts "fooservice" and presents its normal > ticket and authenticator, plus the bundle it got from the > authorization server. > > The server can now verify the authorization data using the session key > located in the authorization server's ticket. No need for the server > to go off and check. Hey, that's pretty good. This would solve the problem of anonymous user login info lookups as well. So if such a system could be standardized then we can get rid of the Kerberos extensions altogether. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 12:33:32 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05705 for ; Wed, 3 May 2000 12:33:31 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA24045 for ietf-cat-wg-out720680; Wed, 3 May 2000 08:51:03 -0700 (PDT) Received: from coserver2.CoManagecorp.com (srv2.comanagecorp.com [209.195.154.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA24038 for ; Wed, 3 May 2000 08:50:59 -0700 (PDT) From: BenC@CoManage.net Received: by srv2.comanagecorp.com with Internet Mail Service (5.5.2448.0) id ; Wed, 3 May 2000 11:47:47 -0400 Message-ID: <10F8EB7E5319D31195CF0090277AF2374F82AF@srv2.comanagecorp.com> To: willian@ubsw.com, bbense@networking.stanford.edu Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Wed, 3 May 2000 11:47:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is within INCHES of how DCE does it. The difference is that the "bundle" is a proxied TGT with attached authz data. Now, if we could only invent some sort of device that we could attach to vehicles that would allow them to be conveyed smoothly along roads, we'd be in business! :/ -- Ben > -----Original Message----- > From: Nicolas Williams [mailto:willian@ubsw.com] > Sent: Wednesday, May 03, 2000 11:25 AM > To: Booker C. Bense > Cc: ietf-cat-wg@lists.Stanford.EDU; krb-protocol@MIT.EDU > Subject: Re: Ticket extensions in Kerberos revisions > > [snip] > > Here is an example: > > > > 1. User gets TGT (containing no auth data) > > 2. User contacts authorization server and presents a ticket > > and authenticator, and asks for authorization data for > > "fooservice". > > 3. Authorization server gets credentials for "fooservice". > > 4. Authorization server sends to user its ticket (not the > > session key, of course) and sends the authorization data > > sealed using its session key. > > 5. User contacts "fooservice" and presents its normal > > ticket and authenticator, plus the bundle it got from the > > authorization server. > > > > The server can now verify the authorization data using the session key > > located in the authorization server's ticket. No need for the server > > to go off and check. > > Hey, that's pretty good. This would solve the problem of anonymous user > login info lookups as well. So if such a system could be standardized > then we can get rid of the Kerberos extensions altogether. > > Nico > -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 12:44:26 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05899 for ; Wed, 3 May 2000 12:44:25 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA25049 for ietf-cat-wg-out720680; Wed, 3 May 2000 09:07:58 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA25044 for ; Wed, 3 May 2000 09:07:55 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id JAA07947; Wed, 3 May 2000 09:07:53 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id <205GXH9W>; Wed, 3 May 2000 09:07:53 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC0336F641@pikachu.wrq.com> From: Joe Salowey To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Wed, 3 May 2000 09:07:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk There is also a better chance that using this method a client would know what task it wants to perform and the authorization server know what privileges the task requires. The client can request to be authorized for the task and the authorization server then can assign the least privilege in the authorization ticket to perform the task. This requires the authorization server to know the policy for particular applications and a common way to represent that policy and the associated privileges. Joe > -----Original Message----- > From: Nicolas Williams [mailto:willian@ubsw.com] > Sent: Wednesday, May 03, 2000 8:25 AM > To: Booker C. Bense > Cc: ietf-cat-wg@lists.Stanford.EDU; krb-protocol@mit.edu > Subject: Re: Ticket extensions in Kerberos revisions > > > > On Wed, 03 May 2000, Greg Hudson wrote: > > >> As Ken pointed out, it is significant to save apps the > extra work, > > >> the extra tickets (why should a server ever have to "log > in" -- get > > >> a TGT?), etc. > > > > > - Because it's secure and extensible and a much better model? > > > > Separating out authorization database from the KDC database does not > > implicitly require the servers (other than the authorization server) > > to "log in." > > > > Here is an example: > > > > 1. User gets TGT (containing no auth data) > > 2. User contacts authorization server and presents a ticket > > and authenticator, and asks for authorization data for > > "fooservice". > > 3. Authorization server gets credentials for "fooservice". > > 4. Authorization server sends to user its ticket (not the > > session key, of course) and sends the authorization data > > sealed using its session key. > > 5. User contacts "fooservice" and presents its normal > > ticket and authenticator, plus the bundle it got from the > > authorization server. > > > > The server can now verify the authorization data using the > session key > > located in the authorization server's ticket. No need for > the server > > to go off and check. > > Hey, that's pretty good. This would solve the problem of > anonymous user > login info lookups as well. So if such a system could be standardized > then we can get rid of the Kerberos extensions altogether. > > Nico > -- > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 12:52:45 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06037 for ; Wed, 3 May 2000 12:52:44 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA25968 for ietf-cat-wg-out720680; Wed, 3 May 2000 09:23:36 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA25963 for ; Wed, 3 May 2000 09:23:34 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id MAA24460; Wed, 3 May 2000 12:23:30 -0400 (EDT) Message-Id: <200005031623.MAA24460@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "Wed, 03 May 2000 10:36:49 EDT." <200005031436.KAA11415@small-gods.mit.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 12:23:29 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Separating out authorization database from the KDC database does not >implicitly require the servers (other than the authorization server) >to "log in." > >Here is an example: >[...] My problem with this scheme is that it requires a significant protocol change. Clients have to be made aware that there's this new authorization server, have to get auth tickets from it, application protocols may have to be changed to accomodate these extra auth tickets, etc etc. It should really be all or nothing - either you include authorization in the ticket, or have the server do everything. Either way the clients don't have to change (and since the servers need to change no matter _what_ you do, if we can just get away with changing those, it would be ideal). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 12:56:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06173 for ; Wed, 3 May 2000 12:56:57 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA26148 for ietf-cat-wg-out720680; Wed, 3 May 2000 09:26:10 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA26136 for ; Wed, 3 May 2000 09:26:07 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e43GPtD21274; Wed, 3 May 2000 09:25:55 -0700 (PDT) Date: Wed, 3 May 2000 09:25:54 -0700 (PDT) From: "Booker C. Bense" To: Nicolas Williams cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: <20000503112455.Q1094@sm2p1386swk.wdr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 3 May 2000, Nicolas Williams wrote: > > On Wed, 03 May 2000, Greg Hudson wrote: > > >> As Ken pointed out, it is significant to save apps the extra work, > > >> the extra tickets (why should a server ever have to "log in" -- get > > >> a TGT?), etc. > > > > > - Because it's secure and extensible and a much better model? > > > > Separating out authorization database from the KDC database does not > > implicitly require the servers (other than the authorization server) > > to "log in." > > > > Here is an example: > > > > 1. User gets TGT (containing no auth data) > > 2. User contacts authorization server and presents a ticket > > and authenticator, and asks for authorization data for > > "fooservice". > > 3. Authorization server gets credentials for "fooservice". > > 4. Authorization server sends to user its ticket (not the > > session key, of course) and sends the authorization data > > sealed using its session key. > > 5. User contacts "fooservice" and presents its normal > > ticket and authenticator, plus the bundle it got from the > > authorization server. > > > > The server can now verify the authorization data using the session key > > located in the authorization server's ticket. No need for the server > > to go off and check. > > Hey, that's pretty good. This would solve the problem of anonymous user > login info lookups as well. So if such a system could be standardized > then we can get rid of the Kerberos extensions altogether. > - I think it's a mistake to put the authorization lookup in the client. This scheme is workable, but the chances of it ever getting deployed are minimal at best. As other's have said it's pretty much DCE and one of the big reasons DCE was a failure was that it required the client to have all this extra code. Anything that requires extra code in the client is pretty much a non-starter. It's taken YEARS to even get vendors thinking about putting modular authentication in their clients. Mention authorization and they start talking about database ACL's, they just don't get it. - Despite your belief otherwise, it is possible to have an server based authorization system with some level of privacy. It does require extra configuration and there is a bit of a chicken and egg problem in that how you authorize the servers to read the authorization data. - I think you're taking unix account logins as a model application, IMHO this problem is already solved well enough and doesn't really have a wide enough application to expend much effort on it. The model application I'm thinking of is not the problem of mapping krbnames to local usernames, but web based access to various resources. This is where we have used our model of using LDAP as an authorization server to great success. This does have the advantage of a high ratio of servers to clients and our setup has a very centralized set of servers. - The problem is really caused by the split of the data needed to make an authorization decision. Groups/roles/Grandfallons live on the central server, while the ACLS are kept locally. It's up to the server software to compare the two and make a decision. - It would be possible to totally preserve the privacy of user data if you put both the role and acl info in the server. Under this scheme the service would present a triple of username,servicename,action to the authz service and it would return a yes/no answer. I have seem some preliminary work in this area, but the reference escapes me at the moment. The hard part here is figuring out how to manage the ACL's and roles. It has to be remotely manageable and dead easy to configure if it is to gain acceptance. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 13:13:18 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06705 for ; Wed, 3 May 2000 13:13:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA27596 for ietf-cat-wg-out720680; Wed, 3 May 2000 09:44:31 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA27591 for ; Wed, 3 May 2000 09:44:27 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id MAA22864; Wed, 3 May 2000 12:44:25 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma022784; Wed, 3 May 2000 12:43:58 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA21263; Wed, 3 May 2000 12:47:33 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA28117; Wed, 3 May 2000 12:43:52 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA09753; Wed, 3 May 2000 12:40:39 -0400 (EDT) Date: Wed, 3 May 2000 12:40:38 -0400 From: Nicolas Williams To: "Booker C. Bense" Cc: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503124037.R1094@sm2p1386swk.wdr.com> References: <20000503112455.Q1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from bbense@networking.stanford.edu on Wed, May 03, 2000 at 09:25:54AM -0700 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, May 03, 2000 at 09:25:54AM -0700, Booker C. Bense wrote: > On Wed, 3 May 2000, Nicolas Williams wrote: > > Hey, that's pretty good. This would solve the problem of anonymous user > > login info lookups as well. So if such a system could be standardized > > then we can get rid of the Kerberos extensions altogether. > > > > - I think it's a mistake to put the authorization lookup in the > client. This scheme is workable, but the chances of it ever getting > deployed are minimal at best. As other's have said it's pretty much > DCE and one of the big reasons DCE was a failure was that it required > the client to have all this extra code. Anything that requires extra > code in the client is pretty much a non-starter. It's taken YEARS > to even get vendors thinking about putting modular authentication > in their clients. Mention authorization and they start talking about > database ACL's, they just don't get it. Well, then this leaves the second approach I suggested several posts back, namely that, instead of including the system credential data in a PAC in Kerberos ticket, a token should be included in every service ticket that allows the service to lookup the user's login data. This token can be nothing more complicated that a Kerberos ticket for the service to access the name service as well as the key(s) being authorized for lookup against the name service. I think it gets a bit more complicated, but not much more. This scales well because the ticket sizes are only pretty much doubled from the current ticket sizes independent of how much system credential data there is to associate with any given user. > - Despite your belief otherwise, it is possible to have an server > based authorization system with some level of privacy. It does > require extra configuration and there is a bit of a chicken and egg > problem in that how you authorize the servers to read the > authorization data. This can always be abused, and, at any rate, I don't mind nearly-anonymous user login lookups. I'm speculating that MS does and that any alternative that we propose to their spec needs to take this into consideration, otherwise how can we entice MS to use the open standard? (No, I won't endorse anti-trust actions/remedies, though some of you may see them as another alternative). [...] > - The problem is really caused by the split of the data needed to > make an authorization decision. Groups/roles/Grandfallons live on > the central server, while the ACLS are kept locally. It's up to > the server software to compare the two and make a decision. I agree fully. There is no argument here. > - It would be possible to totally preserve the privacy of user data if > you put both the role and acl info in the server. Under this scheme > the service would present a triple of > > username,servicename,action > > to the authz service and it would return a yes/no answer. I have seem > some preliminary work in this area, but the reference escapes me at > the moment. The hard part here is figuring out how to manage the > ACL's and roles. It has to be remotely manageable and dead easy to > configure if it is to gain acceptance. This won't do as a replacement of file ACLs. > - Booker C. Bense > Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 13:34:57 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07159 for ; Wed, 3 May 2000 13:34:56 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA29100 for ietf-cat-wg-out720680; Wed, 3 May 2000 10:04:46 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA29079 for ; Wed, 3 May 2000 10:04:37 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id NAA28214; Wed, 3 May 2000 13:04:15 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma028141; Wed, 3 May 2000 13:03:47 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA22998; Wed, 3 May 2000 13:07:23 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA04217; Wed, 3 May 2000 13:03:43 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA10184; Wed, 3 May 2000 13:00:29 -0400 (EDT) Date: Wed, 3 May 2000 13:00:29 -0400 From: Nicolas Williams To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503130028.S1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031623.MAA24460@ginger.cmf.nrl.navy.mil> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Wed, 03 May 2000 12:23:29 -0400 From: Ken Hornstein On Wed, 03 May 2000, Ken Hornstein : > >Separating out authorization database from the KDC database does not > >implicitly require the servers (other than the authorization server) > >to "log in." > > > >Here is an example: > >[...] > > My problem with this scheme is that it requires a significant protocol > change. Clients have to be made aware that there's this new authorization > server, have to get auth tickets from it, application protocols may have > to be changed to accomodate these extra auth tickets, etc etc. > > It should really be all or nothing - either you include authorization > in the ticket, or have the server do everything. Either way the clients > don't have to change (and since the servers need to change no matter > _what_ you do, if we can just get away with changing those, it would > be ideal). At the risk of repeating myself :) there is one more alternative: include a token that in the ticket that the target service can use to perform the user login info lookup. This way clients need no changes and yet there is no need to include users' complete system profile in the tickets. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 13:37:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07223 for ; Wed, 3 May 2000 13:37:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA29215 for ietf-cat-wg-out720680; Wed, 3 May 2000 10:05:57 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA29207 for ; Wed, 3 May 2000 10:05:55 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e43H5mi21497; Wed, 3 May 2000 10:05:52 -0700 (PDT) Date: Wed, 3 May 2000 10:05:48 -0700 (PDT) From: "Booker C. Bense" To: Nicolas Williams cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: <20000503124037.R1094@sm2p1386swk.wdr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 3 May 2000, Nicolas Williams wrote: > > > - Despite your belief otherwise, it is possible to have an server > > based authorization system with some level of privacy. It does > > require extra configuration and there is a bit of a chicken and egg > > problem in that how you authorize the servers to read the > > authorization data. > > This can always be abused, and, at any rate, I don't mind > nearly-anonymous user login lookups. I'm speculating that MS does and > that any alternative that we propose to their spec needs to take this > into consideration, otherwise how can we entice MS to use the open > standard? (No, I won't endorse anti-trust actions/remedies, though some > of you may see them as another alternative). - It's pointless to design a protocol for MS to adopt. It just isn't going to happen. That horse has already left the barn, MS has made it abundantly clear that you are always going to have to use MS servers to support MS clients regardless of the protocols they claim to support. - We should design something that solves our problems well and let the justice department and the marketplace deal with MS. > > [...] > > > - The problem is really caused by the split of the data needed to > > make an authorization decision. Groups/roles/Grandfallons live on > > the central server, while the ACLS are kept locally. It's up to > > the server software to compare the two and make a decision. > > I agree fully. There is no argument here. > > > - It would be possible to totally preserve the privacy of user data if > > you put both the role and acl info in the server. Under this scheme > > the service would present a triple of > > > > username,servicename,action > > > > to the authz service and it would return a yes/no answer. I have seem > > some preliminary work in this area, but the reference escapes me at > > the moment. The hard part here is figuring out how to manage the > > ACL's and roles. It has to be remotely manageable and dead easy to > > configure if it is to gain acceptance. > > This won't do as a replacement of file ACLs. > - sure it will, I just wasn't clear that action includes an object (in the grammatical sense ) as well as a verb. i.e. READ /etc/passwd would be a perfectly acceptable action. Or you could even send something like READ /etc/passwd -r--r--r-- root sys - In effect keeping the ACL locally and passing it up to the server to make the decision. Hmm, I like that idea even better, but it could get unwieldy pretty fast. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 13:57:43 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07555 for ; Wed, 3 May 2000 13:57:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA00428 for ietf-cat-wg-out720680; Wed, 3 May 2000 10:21:07 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA00423 for ; Wed, 3 May 2000 10:21:04 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id NAA01912; Wed, 3 May 2000 13:21:02 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xma001829; Wed, 3 May 2000 13:20:47 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA24926; Wed, 3 May 2000 13:22:35 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA08555; Wed, 3 May 2000 13:20:43 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA10411; Wed, 3 May 2000 13:17:29 -0400 (EDT) Date: Wed, 3 May 2000 13:17:29 -0400 From: Nicolas Williams To: "Booker C. Bense" Cc: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503131728.T1094@sm2p1386swk.wdr.com> References: <20000503124037.R1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from bbense@networking.stanford.edu on Wed, May 03, 2000 at 10:05:48AM -0700 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, May 03, 2000 at 10:05:48AM -0700, Booker C. Bense wrote: > On Wed, 3 May 2000, Nicolas Williams wrote: > > > > > > - Despite your belief otherwise, it is possible to have an server > > > based authorization system with some level of privacy. It does > > > require extra configuration and there is a bit of a chicken and egg > > > problem in that how you authorize the servers to read the > > > authorization data. > > > > This can always be abused, and, at any rate, I don't mind > > nearly-anonymous user login lookups. I'm speculating that MS does and > > that any alternative that we propose to their spec needs to take this > > into consideration, otherwise how can we entice MS to use the open > > standard? (No, I won't endorse anti-trust actions/remedies, though some > > of you may see them as another alternative). > > - It's pointless to design a protocol for MS to adopt. It just isn't > going to happen. That horse has already left the barn, MS has made it > abundantly clear that you are always going to have to use MS servers > to support MS clients regardless of the protocols they claim to > support. I'm not so sure. At any rate, it won't be long before there are products available to can support the Windows 2000 extensions _only in tickets for win2k services that expect them_. Or something like that. > - We should design something that solves our problems well and > let the justice department and the marketplace deal with MS. I think it's very hard to predict what may happen in a situation that involves appeals all the way to the Supreme Court, politics (will the next President's Justice Dept. drop the matter?), the markets in general and so much more. Heck, Even if MS loses all the way, the end result might still be that MS is allowed to continue their use of their Kerberos extensions; then what? And it's hard to predict the markets as well. I wouldn't endorse the anti-trust actions against MS anyways, so I wouldn't rely on any possible outcome where MS loses. This is a wholly personal opinion, but I think it's still rather dangerous to rely on any particular outcome of the case, regardless of what your personal views of the case might be. > > > - It would be possible to totally preserve the privacy of user data if > > > you put both the role and acl info in the server. Under this scheme > > > the service would present a triple of > > > > > > username,servicename,action > > > > > > to the authz service and it would return a yes/no answer. I have seem > > > some preliminary work in this area, but the reference escapes me at > > > the moment. The hard part here is figuring out how to manage the > > > ACL's and roles. It has to be remotely manageable and dead easy to > > > configure if it is to gain acceptance. > > > > This won't do as a replacement of file ACLs. > > > > - sure it will, I just wasn't clear that action includes an object > (in the grammatical sense ) as well as a verb. i.e. > > READ /etc/passwd > > would be a perfectly acceptable action. Or you could even send > something like > > READ /etc/passwd -r--r--r-- root sys > > - In effect keeping the ACL locally and passing it up to the server > to make the decision. Hmm, I like that idea even better, but it could > get unwieldy pretty fast. I think such a scheme would, indeed, "get unwieldy pretty fast". Each service needs to evaluate locally stored ACLs locally. All that's needed is to make all the necessary user system credential information available to the services that need it. > - Booker C. Bense Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 14:52:43 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08976 for ; Wed, 3 May 2000 14:52:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA06490 for ietf-cat-wg-out720680; Wed, 3 May 2000 11:16:30 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA06468 for ; Wed, 3 May 2000 11:16:24 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA25934; Wed, 3 May 2000 14:16:21 -0400 (EDT) Message-Id: <200005031816.OAA25934@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "Wed, 03 May 2000 09:25:54 PDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 14:16:19 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >- I think you're taking unix account logins as a model application, >IMHO this problem is already solved well enough and doesn't really >have a wide enough application to expend much effort on it. The model >application I'm thinking of is not the problem of mapping krbnames to >local usernames, but web based access to various resources. This is >where we have used our model of using LDAP as an authorization server >to great success. This does have the advantage of a high ratio of >servers to clients and our setup has a very centralized set of >servers. This sounds interesting; two questions: - Is access to the LDAP directory authenticated? - Where is the source code? :-) --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 14:55:49 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09014 for ; Wed, 3 May 2000 14:55:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA06760 for ietf-cat-wg-out720680; Wed, 3 May 2000 11:19:07 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA06747 for ; Wed, 3 May 2000 11:19:02 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA25955; Wed, 3 May 2000 14:18:59 -0400 (EDT) Message-Id: <200005031818.OAA25955@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "Wed, 03 May 2000 13:00:29 EDT." <20000503130028.S1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 14:18:57 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >At the risk of repeating myself :) there is one more alternative: >include a token that in the ticket that the target service can use to >perform the user login info lookup. This way clients need no changes and >yet there is no need to include users' complete system profile in the >tickets. This token already exists - it's called "the client principal". You shouldn't need anything else. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 15:14:15 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09323 for ; Wed, 3 May 2000 15:14:14 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id LAA09748 for ietf-cat-wg-out720680; Wed, 3 May 2000 11:47:15 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA09743 for ; Wed, 3 May 2000 11:47:12 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA28067; Wed, 3 May 2000 14:47:11 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma027935; Wed, 3 May 2000 14:46:54 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA02171; Wed, 3 May 2000 14:50:29 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA08409; Wed, 3 May 2000 14:46:49 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA11490; Wed, 3 May 2000 14:43:35 -0400 (EDT) Date: Wed, 3 May 2000 14:43:33 -0400 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Cc: Ken Hornstein Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503144331.X1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031818.OAA25955@ginger.cmf.nrl.navy.mil> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 03 May 2000, Ken Hornstein wrote: > >At the risk of repeating myself :) there is one more alternative: > >include a token that in the ticket that the target service can use to > >perform the user login info lookup. This way clients need no changes and > >yet there is no need to include users' complete system profile in the > >tickets. > > This token already exists - it's called "the client principal". You > shouldn't need anything else. > > --Ken For that to be enough you must allow all servers to lookup any user's login data. I'm postulating that MS wanted to avoid this. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 15:15:20 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09342 for ; Wed, 3 May 2000 15:15:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA09824 for ietf-cat-wg-out720680; Wed, 3 May 2000 11:47:50 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA09801 for ; Wed, 3 May 2000 11:47:41 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA28158; Wed, 3 May 2000 14:47:41 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma028091; Wed, 3 May 2000 14:47:15 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA02195; Wed, 3 May 2000 14:50:51 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA08550; Wed, 3 May 2000 14:47:12 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA11545; Wed, 3 May 2000 14:43:58 -0400 (EDT) Date: Wed, 3 May 2000 14:43:58 -0400 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Cc: Ken Hornstein Subject: Re: Ticket extensions in Kerberos revisions Message-ID: <20000503144356.Y1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031818.OAA25955@ginger.cmf.nrl.navy.mil> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 03 May 2000, Ken Hornstein wrote: > >At the risk of repeating myself :) there is one more alternative: > >include a token that in the ticket that the target service can use to > >perform the user login info lookup. This way clients need no changes and > >yet there is no need to include users' complete system profile in the > >tickets. > > This token already exists - it's called "the client principal". You > shouldn't need anything else. > > --Ken For that to be enough you must allow all servers to lookup any user's login data. I'm postulating that MS wanted to avoid this. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 15:16:32 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09410 for ; Wed, 3 May 2000 15:16:31 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA10130 for ietf-cat-wg-out720680; Wed, 3 May 2000 11:51:49 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id LAA10125 for ; Wed, 3 May 2000 11:51:45 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA28806; Wed, 3 May 00 14:34:07 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA23599; Wed, 3 May 2000 14:30:06 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xma023533; Wed, 3 May 2000 14:29:37 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA01664; Wed, 3 May 2000 14:31:24 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA02928; Wed, 3 May 2000 14:29:30 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA11023; Wed, 3 May 2000 14:26:16 -0400 (EDT) Date: Wed, 3 May 2000 14:26:16 -0400 From: Nicolas Williams To: Ken Hornstein Cc: Nicolas Williams , cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000503142614.V1094@sm2p1386swk.wdr.com> References: <20000502160918.M1094@sm2p1386swk.wdr.com> <200005031814.OAA25915@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031814.OAA25915@ginger.cmf.nrl.navy.mil>; from kenh@cmf.nrl.navy.mil on Wed, May 03, 2000 at 02:14:40PM -0400 X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, May 03, 2000 at 02:14:40PM -0400, Ken Hornstein wrote: > >The second signature, the one signed with the KDC's key, is there so > >that non-system services (services that don't have local priviledges to > >start with, i.e., services which "don't run as root") can ask the OS to > >let them assume the credentials of the remote user. In such cases the OS > >has to check a PAC signature that the service itself couldn't fake. > > Maybe this is a MS thing - but explain to me again why the non-system service > needs the ability to become the remote user? So that you can install and run third party software without full priviledges but which can nevertheless obtain priviledges properly delegated to it. Or so I figure. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 15:43:01 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09824 for ; Wed, 3 May 2000 15:43:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA12439 for ietf-cat-wg-out720680; Wed, 3 May 2000 12:15:52 -0700 (PDT) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA12431 for ; Wed, 3 May 2000 12:15:50 -0700 (PDT) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.10.0/8.10.0.PreAlpha1) with ESMTP id e43JFmW22335; Wed, 3 May 2000 12:15:48 -0700 (PDT) Date: Wed, 3 May 2000 12:15:48 -0700 (PDT) From: "Booker C. Bense" To: Ken Hornstein cc: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: <200005031816.OAA25934@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, 3 May 2000, Ken Hornstein wrote: > >- I think you're taking unix account logins as a model application, > >IMHO this problem is already solved well enough and doesn't really > >have a wide enough application to expend much effort on it. The model > >application I'm thinking of is not the problem of mapping krbnames to > >local usernames, but web based access to various resources. This is > >where we have used our model of using LDAP as an authorization server > >to great success. This does have the advantage of a high ratio of > >servers to clients and our setup has a very centralized set of > >servers. > > This sounds interesting; two questions: > > - Is access to the LDAP directory authenticated? - Yes, via the umich kerberos 4 hack, which I would really like to replace with a true SASL method. > - Where is the source code? :-) - Often we don't even know... %-)! The project is called WebAuth and it's implemented as an Apache Module. There are various other bits and pieces all over the place. It uses that horrible S/Ident software to do the user authentication. I think if you search www.stanford.edu with webauth as the topic you'll find at least a user's guide and maybe even some design documents. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 16:35:42 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10788 for ; Wed, 3 May 2000 16:35:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA16276 for ietf-cat-wg-out720680; Wed, 3 May 2000 12:54:48 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA16267 for ; Wed, 3 May 2000 12:54:45 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA18837; Wed, 3 May 00 15:30:33 EDT Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA26155; Wed, 3 May 2000 14:33:26 -0400 (EDT) Message-Id: <200005031833.OAA26155@ginger.cmf.nrl.navy.mil> To: Nicolas Williams Cc: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Wed, 03 May 2000 14:26:16 EDT." <20000503142614.V1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 14:33:24 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >So that you can install and run third party software without full >priviledges but which can nevertheless obtain priviledges properly >delegated to it. Uhh ... what? If you're talking about "delegation", that's handled _completely_ differently. That's already been standardized, and everyone knows how to do that. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 16:36:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10801 for ; Wed, 3 May 2000 16:36:38 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA16488 for ietf-cat-wg-out720680; Wed, 3 May 2000 12:57:03 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA16466 for ; Wed, 3 May 2000 12:56:56 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA17998; Wed, 3 May 00 15:29:13 EDT Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA25915; Wed, 3 May 2000 14:14:42 -0400 (EDT) Message-Id: <200005031814.OAA25915@ginger.cmf.nrl.navy.mil> To: Nicolas Williams Cc: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Tue, 02 May 2000 16:09:20 EDT." <20000502160918.M1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 14:14:40 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >The second signature, the one signed with the KDC's key, is there so >that non-system services (services that don't have local priviledges to >start with, i.e., services which "don't run as root") can ask the OS to >let them assume the credentials of the remote user. In such cases the OS >has to check a PAC signature that the service itself couldn't fake. Maybe this is a MS thing - but explain to me again why the non-system service needs the ability to become the remote user? --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 17:27:58 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11574 for ; Wed, 3 May 2000 17:27:56 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA23219 for ietf-cat-wg-out720680; Wed, 3 May 2000 13:57:48 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA23214 for ; Wed, 3 May 2000 13:57:46 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 May 2000 10:52:26 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2172.1); Wed, 3 May 2000 10:59:12 -0700 content-class: urn:content-classes:message Subject: RE: Ticket extensions in Kerberos revisions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB528.7A7572E0" Date: Wed, 3 May 2000 10:53:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4356.2 Message-ID: <19398D273324D3118A2B0008C7E9A5690AE47D48@SIT.platinum.corp.microsoft.com> Thread-Topic: Ticket extensions in Kerberos revisions Thread-Index: Ab+1FnzwQwC1pqtLT1q8ELjfENqIWwAByK1w From: "John Brezak" To: "Nicolas Williams" , "Booker C. Bense" Cc: , X-OriginalArrivalTime: 03 May 2000 17:59:12.0733 (UTC) FILETIME=[49DF70D0:01BFB529] Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFB528.7A7572E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When a Windows 2000 KDC gets a TGS-REQ with a TGT without Windows 2000 authzdata - such as a TGT from a trusted Kerberos realm, it will use the cname in the ticket to locate an account in the Windows 2000 domain that will be used to construct the authzdata and insert the authzdata into the ticket. This is referred to as the cross-realm scenario, where the Kerberos realm has a trust with the Windows 2000 forest. The Kerberos realm is acting as the authentication service (issues TGTs for users) and the Windows 2000 domain is acting as the authorization service (decorates service tickets with the needed authzdata) to access Windows 2000 services that are using the Windows 2000 domain security model for access control. In the end the ticket's authzdata is used to construct an access token for the service.=20 In the case where Windows 2000 systems are not a member of any domain, a Kerberos realm can be used for authentication, but authorization is based on establishing mappings between the cname in the ticket with a local (SAM) account on the computer. The mapping is used to create the access token. This is very similar to the mapping mechanism between Kerberos principal names and /etc/passwd names on Unix systems to establish a local uid for access checking. > -----Original Message----- > From: Nicolas Williams [mailto:willian@ubsw.com] > Sent: Wednesday, May 03, 2000 8:25 AM > To: Booker C. Bense > Cc: ietf-cat-wg@lists.Stanford.EDU; krb-protocol@mit.edu > Subject: Re: Ticket extensions in Kerberos revisions >=20 >=20 >=20 > On Wed, 03 May 2000, Greg Hudson wrote: > > >> As Ken pointed out, it is significant to save apps the=20 > extra work, > > >> the extra tickets (why should a server ever have to "log=20 > in" -- get > > >> a TGT?), etc. > >=20 > > > - Because it's secure and extensible and a much better model?=20 > >=20 > > Separating out authorization database from the KDC database does not > > implicitly require the servers (other than the authorization server) > > to "log in." > >=20 > > Here is an example: > >=20 > > 1. User gets TGT (containing no auth data) > > 2. User contacts authorization server and presents a ticket > > and authenticator, and asks for authorization data for > > "fooservice". > > 3. Authorization server gets credentials for "fooservice". > > 4. Authorization server sends to user its ticket (not the > > session key, of course) and sends the authorization data > > sealed using its session key. > > 5. User contacts "fooservice" and presents its normal > > ticket and authenticator, plus the bundle it got from the > > authorization server. > >=20 > > The server can now verify the authorization data using the=20 > session key > > located in the authorization server's ticket. No need for=20 > the server > > to go off and check. >=20 > Hey, that's pretty good. This would solve the problem of=20 > anonymous user > login info lookups as well. So if such a system could be standardized > then we can get rid of the Kerberos extensions altogether. >=20 > Nico > -- >=20 > = -++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--= ++**=3D=3D > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to=20 > majordomo@lists.stanford.edu >=20 ------_=_NextPart_001_01BFB528.7A7572E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Ticket extensions in Kerberos revisions

When a Windows 2000 KDC gets a TGS-REQ with a TGT = without Windows 2000 authzdata - such as a TGT from a trusted Kerberos = realm, it will use the cname in the ticket to locate an account in the = Windows 2000 domain that will be used to construct the authzdata and = insert the authzdata into the ticket. This is referred to as the = cross-realm scenario, where the Kerberos realm has a trust with the = Windows 2000 forest.

The Kerberos realm is acting as the authentication = service (issues TGTs for users) and the Windows 2000 domain is acting as = the authorization service (decorates service tickets with the needed = authzdata) to access Windows 2000 services that are using the Windows = 2000 domain security model for access control.

In the end the ticket's authzdata is used to construct = an access token for the service.

In the case where Windows 2000 systems are not a = member of any domain, a Kerberos realm can be used for authentication, = but authorization is based on establishing mappings between the cname in = the ticket with a local (SAM) account on the computer. The mapping is = used to create the access token. This is very similar to the mapping = mechanism between Kerberos principal names and /etc/passwd names on Unix = systems to establish a local uid for access checking.


> -----Original Message-----
> From: Nicolas Williams [mailto:willian@ubsw.com]
> Sent: Wednesday, May 03, 2000 8:25 AM
> To: Booker C. Bense
> Cc: ietf-cat-wg@lists.Stanford.EDU; = krb-protocol@mit.edu
> Subject: Re: Ticket extensions in Kerberos = revisions
>
>
>
> On Wed, 03 May 2000, Greg Hudson = <ghudson@MIT.EDU> wrote:
> > >> As Ken pointed out, it is = significant to save apps the
> extra work,
> > >> the extra tickets (why should a = server ever have to "log
> in" -- get
> > >> a TGT?), etc.
> >
> > > - Because it's secure and extensible = and a much better model?
> >
> > Separating out authorization database from = the KDC database does not
> > implicitly require the servers (other than = the authorization server)
> > to "log in."
> >
> > Here is an example:
> >
> = >         1. User gets TGT = (containing no auth data)
> = >         2. User contacts = authorization server and presents a ticket
> = >            = and authenticator, and asks for authorization data for
> = >            = "fooservice".
> = >         3. Authorization = server gets credentials for "fooservice".
> = >         4. Authorization = server sends to user its ticket (not the
> = >            = session key, of course) and sends the authorization data
> = >            = sealed using its session key.
> = >         5. User contacts = "fooservice" and presents its normal
> = >            = ticket and authenticator, plus the bundle it got from the
> = >            = authorization server.
> >
> > The server can now verify the authorization = data using the
> session key
> > located in the authorization server's = ticket.  No need for
> the server
> > to go off and check.
>
> Hey, that's pretty good. This would solve the = problem of
> anonymous user
> login info lookups as well. So if such a system = could be standardized
> then we can get rid of the Kerberos extensions = altogether.
>
> Nico
> --
>
> = -++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--= ++**=3D=3D
> This message was posted through the Stanford = campus mailing list
> server.  If you wish to unsubscribe from = this mailing list, send the
> message body of "unsubscribe = ietf-cat-wg" to
> majordomo@lists.stanford.edu
>

------_=_NextPart_001_01BFB528.7A7572E0-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 20:09:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13222 for ; Wed, 3 May 2000 20:09:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA01941 for ietf-cat-wg-out720680; Wed, 3 May 2000 15:24:44 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id PAA01924 for ; Wed, 3 May 2000 15:24:38 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA24295; Wed, 3 May 00 14:30:59 EDT Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA25915; Wed, 3 May 2000 14:14:42 -0400 (EDT) Message-Id: <200005031814.OAA25915@ginger.cmf.nrl.navy.mil> To: Nicolas Williams Cc: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Tue, 02 May 2000 16:09:20 EDT." <20000502160918.M1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 03 May 2000 14:14:40 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >The second signature, the one signed with the KDC's key, is there so >that non-system services (services that don't have local priviledges to >start with, i.e., services which "don't run as root") can ask the OS to >let them assume the credentials of the remote user. In such cases the OS >has to check a PAC signature that the service itself couldn't fake. Maybe this is a MS thing - but explain to me again why the non-system service needs the ability to become the remote user? --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 20:14:41 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13268 for ; Wed, 3 May 2000 20:14:40 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA07448 for ietf-cat-wg-out720680; Wed, 3 May 2000 16:38:08 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA07442 for ; Wed, 3 May 2000 16:38:05 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA01534; Wed, 3 May 00 14:58:14 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id OAA27258; Wed, 3 May 2000 14:44:02 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma027140; Wed, 3 May 2000 14:43:45 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA01907; Wed, 3 May 2000 14:47:20 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA07317; Wed, 3 May 2000 14:43:24 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA11299; Wed, 3 May 2000 14:40:10 -0400 (EDT) Date: Wed, 3 May 2000 14:40:10 -0400 From: Nicolas Williams To: Ken Hornstein Cc: Nicolas Williams , cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000503144009.W1094@sm2p1386swk.wdr.com> References: <20000503142614.V1094@sm2p1386swk.wdr.com> <200005031833.OAA26155@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005031833.OAA26155@ginger.cmf.nrl.navy.mil>; from kenh@cmf.nrl.navy.mil on Wed, May 03, 2000 at 02:33:24PM -0400 X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, May 03, 2000 at 02:33:24PM -0400, Ken Hornstein wrote: > >So that you can install and run third party software without full > >priviledges but which can nevertheless obtain priviledges properly > >delegated to it. > > Uhh ... what? > > If you're talking about "delegation", that's handled _completely_ > differently. That's already been standardized, and everyone knows how > to do that. Not just delegation of Kerberos tickets. How does a Unix daemon become some user on behalf of which it needs to perform some service when the service itself does not run as that user or as root? The answer is run the server as root. In Windows 2000 you don't have to do that. I think it's security advantage not to have to run services with priviledges, though it's not a perfect solution wrt untrusted software. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 20:39:22 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13526 for ; Wed, 3 May 2000 20:39:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA10060 for ietf-cat-wg-out720680; Wed, 3 May 2000 17:10:27 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.12.23]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id RAA10051 for ; Wed, 3 May 2000 17:10:24 -0700 (PDT) Received: (qmail 29766 invoked by uid 50); 4 May 2000 00:10:23 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: In-Reply-To: "Booker C. Bense"'s message of "Wed, 3 May 2000 12:15:48 -0700 (PDT)" From: Russ Allbery Organization: The Eyrie Date: 03 May 2000 17:10:23 -0700 Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Booker C Bense writes: > - Often we don't even know... %-)! The project is called WebAuth and > it's implemented as an Apache Module. There are various other bits and > pieces all over the place. It uses that horrible S/Ident software to do > the user authentication. I think if you search www.stanford.edu with > webauth as the topic you'll find at least a user's guide and maybe even > some design documents. And if what you find is interesting enough that you'd like to investigate further, I think I know where most of the separate pieces are and can try to hunt them down. At some point, packaging it up would be good, but we haven't had anywhere close to enough time to think about that. :/ -- Russ Allbery (rra@stanford.edu) -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed May 3 22:40:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15977 for ; Wed, 3 May 2000 22:40:09 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA18194 for ietf-cat-wg-out720680; Wed, 3 May 2000 19:07:08 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id TAA18189 for ; Wed, 3 May 2000 19:07:05 -0700 (PDT) Received: from fwma1.certco.com by MIT.EDU with SMTP id AA29265; Wed, 3 May 00 22:09:08 EDT Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 7FD5415534; Wed, 3 May 2000 22:07:01 -0400 (EDT) Received: by haggis.ma.certco.com (Postfix, from userid 1079) id 0658D7C0E8; Wed, 3 May 2000 22:07:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by haggis.ma.certco.com (Postfix) with SMTP id EE32F744C6; Wed, 3 May 2000 22:07:00 -0400 (EDT) Date: Wed, 3 May 2000 22:07:00 -0400 (EDT) From: Rich Salz To: Ken Hornstein Cc: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: <200005031814.OAA25915@ginger.cmf.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Maybe this is a MS thing - but explain to me again why the non-system service > needs the ability to become the remote user? So that it can be a non-system service. :) It means that the server-writer doesn't have to emulate all the permission checks that the operating system would normally do. That kind of thing is error-prone and risky. /r$ -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 01:14:33 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18976 for ; Thu, 4 May 2000 01:14:32 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id VAA25117 for ietf-cat-wg-out720680; Wed, 3 May 2000 21:25:24 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA25112 for ; Wed, 3 May 2000 21:25:22 -0700 (PDT) Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id AAA05995; Thu, 4 May 2000 00:25:18 -0400 (EDT) Message-Id: <200005040425.AAA05995@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "02 May 2000 16:55:43 PDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 04 May 2000 00:25:17 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Doing the authorization queries against an external database using the >Kerberos identity information as the key works. We've widely deployed it >and related systems at Stanford for a variety of different applications, >and in fact using LDAP for this seems to scale even better than a standard >Kerberos server setup. LDAP has real-time replication, something akin to >commits and rollbacks, changelogs that can be replayed, and lots of other >protocol infrastructure aimed at solving the distribution, scaling, and >replication problems even better than Kerberos's support for multiple >authentication servers. I feel I must point out that this is technically _not_ a feature of LDAP per se, but the LDAP implementations. You could do the same things with Kerberos, and some of the commercial versions have done that; it's just that no one has (yet) spent the time & energy in the freeware Kerberos versions that are out there. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 01:19:03 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19581 for ; Thu, 4 May 2000 01:19:03 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA25694 for ietf-cat-wg-out720680; Wed, 3 May 2000 21:34:26 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id VAA25689 for ; Wed, 3 May 2000 21:34:24 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA26745; Thu, 4 May 00 00:21:11 EDT Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id AAA05937; Thu, 4 May 2000 00:19:05 -0400 (EDT) Message-Id: <200005040419.AAA05937@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Wed, 03 May 2000 14:40:10 EDT." <20000503144009.W1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 04 May 2000 00:19:04 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >In Windows 2000 you don't have to do that. I think it's security >advantage not to have to run services with priviledges, though it's not >a perfect solution wrt untrusted software. You're forgetting one thing - Kerberos was designed to authenticate principals _across a network_, not through a third party on the same machine. If it's on the same machine, it's explicitly outside of the Kerberos design criteria. (It makes me wonder why the third-party app couldn't pass ticket + authenticator to a system service, where _he_ could verify it and give the appropriate privs to the third-party app). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 01:25:21 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20479 for ; Thu, 4 May 2000 01:25:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA26368 for ietf-cat-wg-out720680; Wed, 3 May 2000 21:41:18 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.12.23]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id VAA26361 for ; Wed, 3 May 2000 21:41:15 -0700 (PDT) Received: (qmail 846 invoked by uid 50); 4 May 2000 04:41:14 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <200005040425.AAA05995@ginger.cmf.nrl.navy.mil> In-Reply-To: Ken Hornstein's message of "Thu, 04 May 2000 00:25:17 -0400" From: Russ Allbery Organization: The Eyrie Date: 03 May 2000 21:41:14 -0700 Message-ID: Lines: 30 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Hornstein writes: >> Doing the authorization queries against an external database using the >> Kerberos identity information as the key works. We've widely deployed >> it and related systems at Stanford for a variety of different >> applications, and in fact using LDAP for this seems to scale even >> better than a standard Kerberos server setup. LDAP has real-time >> replication, something akin to commits and rollbacks, changelogs that >> can be replayed, and lots of other protocol infrastructure aimed at >> solving the distribution, scaling, and replication problems even better >> than Kerberos's support for multiple authentication servers. > I feel I must point out that this is technically _not_ a feature of LDAP > per se, but the LDAP implementations. You could do the same things with > Kerberos, and some of the commercial versions have done that; it's just > that no one has (yet) spent the time & energy in the freeware Kerberos > versions that are out there. I was under the impression that the protocols for doing replication were standardized, as was the import/export format (or at least being actively worked on within the IETF). I don't follow LDAP standardization closely, though, so my apologies if I'm mistaken. I certainly agree that this is possible in Kerberos (and Transarc has been doing it with AFS's Kerberos implementation for a while), but developing a client/server replication protocol would IMO be the first step of doing that generally and with interoperability. -- Russ Allbery (rra@stanford.edu) -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 01:40:51 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22573 for ; Thu, 4 May 2000 01:40:51 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id VAA27092 for ietf-cat-wg-out720680; Wed, 3 May 2000 21:57:44 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA27085 for ; Wed, 3 May 2000 21:57:41 -0700 (PDT) Received: from cmf.nrl.navy.mil (fermi.cmf.nrl.navy.mil [134.207.10.73]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id AAA06209; Thu, 4 May 2000 00:57:38 -0400 (EDT) Message-Id: <200005040457.AAA06209@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-reply-to: Your message of "03 May 2000 21:41:14 PDT." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 04 May 2000 00:57:34 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> I feel I must point out that this is technically _not_ a feature of LDAP >> per se, but the LDAP implementations. You could do the same things with >> Kerberos, and some of the commercial versions have done that; it's just >> that no one has (yet) spent the time & energy in the freeware Kerberos >> versions that are out there. > >I was under the impression that the protocols for doing replication were >standardized, as was the import/export format (or at least being actively >worked on within the IETF). I don't follow LDAP standardization closely, >though, so my apologies if I'm mistaken. Certainly there is the LDUP working group, and they have a number of Internet-Drafts out (but no RFCs AFAIK). But AFAIK, none of it is required to be implemented (please don't think I'm beating on the LDAP guys, because they're certainly ahead of Kerberos in this regard). >I certainly agree that this is possible in Kerberos (and Transarc has been >doing it with AFS's Kerberos implementation for a while), but developing a >client/server replication protocol would IMO be the first step of doing >that generally and with interoperability. I'm not sure I can see a whole lot of value in being interoperable with other vendors Kerberos servers; the database format tends to be very server implementation-specific. That's not a problem with LDAP, of course :-) --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 04:53:28 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01188 for ; Thu, 4 May 2000 04:53:27 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id BAA06468 for ietf-cat-wg-out720680; Thu, 4 May 2000 01:20:18 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id BAA06463 for ; Thu, 4 May 2000 01:20:16 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA29869; Thu, 4 May 00 04:22:16 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id KAA06784; Thu, 4 May 2000 10:16:27 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [155.56.94.51]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id KAA04889; Thu, 4 May 2000 10:16:39 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id KAA07960; Thu, 4 May 2000 10:16:39 +0200 (METDST) From: Martin Rex Message-Id: <200005040816.KAA07960@hw1464.wdf.sap-ag.de> Subject: Re: Ticket extensions in Kerberos revisions To: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 4 May 2000 10:16:38 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200005040419.AAA05937@ginger.cmf.nrl.navy.mil> from "Ken Hornstein" at May 4, 0 00:19:04 am Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Ken Hornstein wrote: > > >In Windows 2000 you don't have to do that. I think it's security > >advantage not to have to run services with priviledges, though it's not > >a perfect solution wrt untrusted software. > > You're forgetting one thing - Kerberos was designed to authenticate > principals _across a network_, not through a third party on the same > machine. If it's on the same machine, it's explicitly outside of the > Kerberos design criteria. I strongly doubt that there ever was a design requirement in Kerberos that prohibited performing the authentication within the TCB. Anyway, this is how all authentication systems with POSIX-style access control in the TCB make it (DCE, SESAME, Microsoft SSP). > > (It makes me wonder why the third-party app couldn't pass ticket + > authenticator to a system service, where _he_ could verify it and give > the appropriate privs to the third-party app). That's exactly what happens. Maybe you didn't read my original mail on this, it already contained all the information: Windows NT works with POSIX-style access control that is enforced by the trusted computing base (TCB), and not by any application code. Therefore the authentication of the user is performed by a system service (the LSA), which will also create an access token for the service that will permit the service to run "in the context of the client". When running in the client context, then the TCB performs access control against the client's privileges instead of the server's privileges. Microsoft calls this model "Impersonation", it is described in detail in the Online Help of Visual Studio. All Microsoft applications use this access control model, and MS recommends all application writers to use it (so that there is a homogeneous ACL structure on MS platforms). The end result is that you can run the service under any account that you want, it will still get access tokens with the client's privileges created by the LSA. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 12:35:56 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10538 for ; Thu, 4 May 2000 12:35:55 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA22873 for ietf-cat-wg-out720680; Thu, 4 May 2000 09:06:11 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA22868 for ; Thu, 4 May 2000 09:06:08 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA14710; Thu, 4 May 00 11:49:49 EDT Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id LAA11924; Thu, 4 May 2000 11:47:37 -0400 (EDT) Message-Id: <200005041547.LAA11924@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions In-Reply-To: Your message of "Thu, 04 May 2000 11:39:16 EDT." <20000504113915.B1094@sm2p1386swk.wdr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 04 May 2000 11:47:35 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> (It makes me wonder why the third-party app couldn't pass ticket + >> authenticator to a system service, where _he_ could verify it and give >> the appropriate privs to the third-party app). > >Because the third-party app has to have access to its service principal >key and so can forge tickets to itself. So give only the system service access to the principal key (and I'm confused right now; according to Martin Rex, what I described _is_ the way it works. Who's right?) --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 12:39:22 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10639 for ; Thu, 4 May 2000 12:39:20 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA23317 for ietf-cat-wg-out720680; Thu, 4 May 2000 09:14:50 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA23307 for ; Thu, 4 May 2000 09:14:47 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA16514; Thu, 4 May 00 11:43:38 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA11836; Thu, 4 May 2000 11:42:49 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma011708; Thu, 4 May 2000 11:42:35 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA09001; Thu, 4 May 2000 11:46:10 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA06304; Thu, 4 May 2000 11:42:32 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA01303; Thu, 4 May 2000 11:39:16 -0400 (EDT) Date: Thu, 4 May 2000 11:39:16 -0400 From: Nicolas Williams To: cat-ietf@mit.edu, krb-protocol@mit.edu Cc: Ken Hornstein Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000504113915.B1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005040419.AAA05937@ginger.cmf.nrl.navy.mil> X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Thu, 04 May 2000 00:19:04 -0400 From: Ken Hornstein On Thu, 04 May 2000, Ken Hornstein wrote: > >In Windows 2000 you don't have to do that. I think it's security > >advantage not to have to run services with priviledges, though it's not > >a perfect solution wrt untrusted software. > > You're forgetting one thing - Kerberos was designed to authenticate > principals _across a network_, not through a third party on the same > machine. If it's on the same machine, it's explicitly outside of the > Kerberos design criteria. This is the reason for that KDC PAC signature in the MS spec. I propose that it be done differently, but either way it doesn't cost much at all (signatures are small). > (It makes me wonder why the third-party app couldn't pass ticket + > authenticator to a system service, where _he_ could verify it and give > the appropriate privs to the third-party app). Because the third-party app has to have access to its service principal key and so can forge tickets to itself. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 4 13:40:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12530 for ; Thu, 4 May 2000 13:40:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA26975 for ietf-cat-wg-out720680; Thu, 4 May 2000 09:59:13 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA26966 for ; Thu, 4 May 2000 09:59:09 -0700 (PDT) Received: from gate.stm.wdr.com by MIT.EDU with SMTP id AA02943; Thu, 4 May 00 12:26:13 EDT Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id MAA23996; Thu, 4 May 2000 12:26:13 -0400 (EDT) Received: from (eight.wdr.com [192.168.0.3]) by gate via smap (V2.0) id xma023909; Thu, 4 May 2000 12:25:57 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA12725; Thu, 4 May 2000 12:29:31 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA19504; Thu, 4 May 2000 12:25:50 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA01690; Thu, 4 May 2000 12:22:18 -0400 (EDT) Date: Thu, 4 May 2000 12:22:18 -0400 From: Nicolas Williams To: cat-ietf@mit.edu, krb-protocol@mit.edu Cc: Ken Hornstein Subject: Re: Ticket extensions in Kerberos revisions Message-Id: <20000504122216.C1094@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005041547.LAA11924@ginger.cmf.nrl.navy.mil> X-Wdr-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, 04 May 2000, Ken Hornstein wrote: > >> (It makes me wonder why the third-party app couldn't pass ticket + > >> authenticator to a system service, where _he_ could verify it and give > >> the appropriate privs to the third-party app). > > > >Because the third-party app has to have access to its service principal > >key and so can forge tickets to itself. > > So give only the system service access to the principal key (and I'm > confused right now; according to Martin Rex, what I described _is_ the > way it works. Who's right?) Ok, that'd work. So what should be done with that ticket extension field in the draft? I would still endorse a new standard along the lines of what MS did or my other proposal. But I'm not convinced anymore that it's absolutely necessary. > --Ken Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri May 5 11:27:21 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21468 for ; Fri, 5 May 2000 11:27:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA16259 for ietf-cat-wg-out720680; Fri, 5 May 2000 07:47:32 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA16208 for ; Fri, 5 May 2000 07:47:09 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 5 May 2000 14:42:58 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA25195; Fri, 5 May 2000 10:46:39 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Fri, 5 May 2000 10:47:00 -0400 Message-ID: From: "Linn, John" To: "'mrex@sap-ag.de'" , mre@Eng.Sun.COM Cc: "'CAT-WG List'" Subject: RE: hostbased service names (or not) Date: Fri, 5 May 2000 10:46:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Martin wrote: > Mike Eisler wrote: > > > > > After Ted's hint about what else is written in section > 4.1 of rfc2743, > > > I realize that this section is breaching the GSS-API > abstraction itself, > > > because it suggest to make assumptions that every gssapi mechanism > > > in the world and of the future can be assumed to look like the > > > Kerberos of today. > > > > I don't see the violation. "host" is just a string. RFC 2743 could > > have selected any arbitrary string. All it is saying is > that there is > > well known target name that an application *may* use. nfs doesn't > > use it it, ftp does, etc. > > "host" is not just a string. It is a particular notion of sharing > credentials on a host by services that traditionally run under > the root account of Unix machines. For MIT Kerberos, the > default acceptor credentials resolve to "host/f.q.d.n". > (btw. rfc1964bis could also give some guidance on default > acceptor credential resolution). While the use of "host" initially evolved as a reflection of UNIX root practice, I don't think that the idea of a host-level identity, typically representing an end system's OS rather than a particular application within that system, is necessarily OS-specific. > > Just as each of the protocols rlogin,rexec,telnet as well as > ftp,nfs,ssh > are assigned distinct well-known TCP-ports, they should be assigned > distinct well-known hostbased service names. I think this is appropriately a case-by-case judgment. For the case of closely-related application families (e.g, perhaps, (some of) rtools), it may be appropriate for those families' designers to make the determination that family members can be appropriately served by a common service identity. > > Just because different application protocols offer essentially the > same service doesn't mean that we should discriminate against gssapi > mechanisms that do not offer to share credentials across processes. In GSS terms, I don't think that what we're discussing here is actually credential sharing across processes, but rather the ability to satisfy multiple authorized processes' requests and thereby obtain for those processes different credentials operating under the same identity. Depending on the mechanism and implementation, this may result in more or less sharing and indirection to underlying objects. What's the state of currently-implemented practice wrt ability to satisfy multiple processes' requests for acceptor credentials under the same identity? > > I think that requiring nfs@hostname for NFSv4 is the way > every application > should do it. I think this usage is good practice in many cases, but (as noted) don't believe that it needs to be mandated universally. Again, I strongly suggest that Kerberos gssapi > mechanism > should be permitted to map "nfs@hostname" to the > "host/f.q.d.n" principal > when the sysadmin wants this. This mapping would be convenient operationally, but the principle could complicate mutual authentication if applied in a general, cross-mechanism sense: what rules should an initiator-side implementation follow to determine whether an authenticated target identity acceptably matches the name the originator requested, if the knowledge of mapping vs. non-mapping is locally held only at the target? > > > > > > > - SPKM and LIPKEY lack the definition of a mechanism specific > > > nametype. > > > For SPKM this has caused all independent implementations to > > > create non-interoperable nametypes (I've seen 5 independent > > > mechanisms so far). I have no reason to believe that LIPKEY > > > will improve the situation. I strongly encourage the > > > document authors to propose a mechanism specific nametype, > > > discuss it here and nail it down. Since existing > implementations > > > are non-interoperable, we can only make things better. > > > > NFSv4 since is specified to use LIPKEY. If NFSv4 is > successful. i.e. there are > > at least two independent interoperable implementations that > fully conform to > > all mandatory features of the protocol, including LIPKEY > and SPKM-3, then > > there will be two LIPKEY/SPKM-3 mechanisms that > interoperate. At which time, > > the specifications can be tightened. > > Oh, that sounds interesting: > > How do you verify that an implementation of LIPKEY and SPKM-3 conforms > to the mandatory feature "all generic nametypes of rfc2078", when > this part is not actually specified? We have an IESG-approved document awaiting publication as Proposed Standard. I think that we should proceed to trial implementations which will contain support for the designated name types in some form, reflecting any further refinement and agreements in successor or adjunct Internet-Drafts as the process evolves. I expect that further text on internal mechanism and export name formats for LIPKEY will be likely results of this process. > > > -Martin --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun May 7 15:47:03 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11926 for ; Sun, 7 May 2000 15:47:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA19803 for ietf-cat-wg-out720680; Sun, 7 May 2000 12:11:45 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA19794 for ; Sun, 7 May 2000 12:11:42 -0700 (PDT) From: bench1@indyracers.com Received: from 01-050.011.popsite.net by MIT.EDU with SMTP id AA06799; Sun, 7 May 00 15:13:27 EDT Subject: your imaging supplies Date: Sun, 7 May 2000 00:30:24 Message-Id: <104.825278.305596@> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $84 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 8 09:48:36 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07607 for ; Mon, 8 May 2000 09:48:36 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA23854 for ietf-cat-wg-out720680; Mon, 8 May 2000 06:12:23 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id GAA23849 for ; Mon, 8 May 2000 06:12:20 -0700 (PDT) Received: by sentry.gw.tislabs.com; id JAA27638; Mon, 8 May 2000 09:14:09 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma027633; Mon, 8 May 00 09:13:23 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA06965 for ietf-cat-wg@lists.stanford.edu; Mon, 8 May 2000 09:06:47 -0400 (EDT) Date: Mon, 8 May 2000 09:06:47 -0400 (EDT) From: "David M. Balenson" Message-Id: <200005081306.JAA06965@clipper.gw.tislabs.com> To: ietf-cat-wg@lists.Stanford.EDU Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk C A L L F O R P A P E R S The Internet Society 2001 Network and Distributed System Security Symposium (NDSS'01) February 7-9, 2001 Catamaran Resort, San Diego, California IMPORTANT DATES Paper Submission due: August 2, 2000 Author Notification: September 27, 2000 Camera-ready final papers due: October 31, 2000 GOAL: This symposium will foster information exchange among researchers and practioners of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce: e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Public Key Infrastructure. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, database management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures. * Network Perimeter Controls: firewalls, packet filters, application gateways. * Virtual Private Networks. BEST PAPER AWARD: There will be a best paper award again this year. The award will be presented at the symposium to the authors of the best overall paper as selected by the Program Committee. SUBMISSIONS: The Program Committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may - at the discretion of the panel chair - include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by August 2, 2000, and must be made via electronically in either PostScript or ASCII format. If the Committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. Submission information can be found at http://www.isoc.org/ndss01/cfp. Dates, final call for papers, advance program, and registration information will be available soon at http://www.isoc.org/ndss01. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program Co-chairs as indicated below. Authors and panelists will be notified of acceptance by September 27, 2000. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 31, 2000. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society PROGRAM COMMITTEE: Bennet Yee, University of California San Diego Bill Cheswick, Bell Labs Dave Kormann, AT&T Labs - Research David Aucksmith, Intel Corportation David P. Maher, Intertrust David Wagner, UC Berkeley Edward W. Felten, Princeton University Fabian Monrose, Bell Labs Gary McGraw, Reliable Software Technologies James Ellis, Sun Microsystems Kevin McCurley, IBM Almaden Research Center Matt Bishop, UC Davis Mudge, L0pht Heavy Industries, Inc. Peter Gutmann, University of Auckland, New Zealand Radia Perlman, Sun Microsystems Sandra Murphy, Network Associates Tom Berson, Anagram Laboratories Virgil D. Gligor, University of Maryland -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 8 21:51:00 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25977 for ; Mon, 8 May 2000 21:50:59 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA09464 for ietf-cat-wg-out720680; Mon, 8 May 2000 18:14:12 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id SAA09459 for ; Mon, 8 May 2000 18:14:09 -0700 (PDT) Received: from TED-W20.MIT.EDU by MIT.EDU with SMTP id AA21590; Mon, 8 May 00 21:16:16 EDT Received: (from tytso@localhost) by trampoline.thunk.org (8.9.3/8.9.3) id VAA23856; Mon, 8 May 2000 21:13:57 -0400 Date: Mon, 8 May 2000 21:13:57 -0400 From: "Theodore Ts'o" Message-Id: <200005090113.VAA23856@trampoline.thunk.org> To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu In-Reply-To: <200005021607.SAA25992@hw1464.wdf.sap-ag.de> (message from Martin Rex on Tue, 2 May 2000 18:07:05 +0200 (METDST)) Subject: Re: hostbased service names (or not) Phone: (781) 391-3464 References: <200005021607.SAA25992@hw1464.wdf.sap-ag.de> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Martin Rex Date: Tue, 2 May 2000 18:07:05 +0200 (METDST) "host" is not just a string. It is a particular notion of sharing credentials on a host by services that traditionally run under the root account of Unix machines. For MIT Kerberos, the default acceptor credentials resolve to "host/f.q.d.n". (btw. rfc1964bis could also give some guidance on default acceptor credential resolution). Just as each of the protocols rlogin,rexec,telnet as well as ftp,nfs,ssh are assigned distinct well-known TCP-ports, they should be assigned distinct well-known hostbased service names. Just because different application protocols offer essentially the same service doesn't mean that we should discriminate against gssapi mechanisms that do not offer to share credentials across processes. What GSSAPI mechanisms don't allow sharing of credentials across processes? It's just a matter of configuring any system so that each process has access to the same set of cryptographic material (service key in the case of Kerberos, private key in the case of an X.509 certificate, etc.). Whether or not the system is a Unix based system is really irrelevant to the discussion --- the same applies whether you're on an NT system, or any other OS. I think that requiring nfs@hostname for NFSv4 is the way every application should do it. Again, I strongly suggest that Kerberos gssapi mechanism should be permitted to map "nfs@hostname" to the "host/f.q.d.n" principal when the sysadmin wants this. Agreed, there should be a way for the system administrator to map GSSAPI service names to actual kernel names. The current default behaviour isfine, but it should be overrideable by the sysadmin. - Ted -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 9 10:55:31 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21841 for ; Tue, 9 May 2000 10:55:29 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id HAA05737 for ietf-cat-wg-out720680; Tue, 9 May 2000 07:11:34 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA05732 for ; Tue, 9 May 2000 07:11:31 -0700 (PDT) Received: from [194.75.152.224] by MIT.EDU with SMTP id AA23914; Tue, 9 May 00 10:11:25 EDT Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id MAA18861; Tue, 9 May 2000 12:38:45 +0100 (BST) Message-Id: <002501bfb9ad$fe3db180$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Charlie Fletcher - www.ukdata.com" Subject: UK Company Formations www.formacompany.co.uk Date: Tue, 9 May 2000 12:45:01 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mime-Autoconverted: from 8bit to quoted-printable by scooby.lineone.net id MAA18861 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.Stanford.EDU id HAA05733 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Do you need a company registered in the UK. Please visit www.formacompany.co.uk where you can form your new company on-line for only £98 Thank you Maureen Cavely www.formacompany.co.uk -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 9 10:56:07 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21859 for ; Tue, 9 May 2000 10:56:06 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA05767 for ietf-cat-wg-out720680; Tue, 9 May 2000 07:12:24 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA05762 for ; Tue, 9 May 2000 07:12:22 -0700 (PDT) Received: from [194.75.152.224] by MIT.EDU with SMTP id AA24216; Tue, 9 May 00 10:12:17 EDT Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id OAA09681; Tue, 9 May 2000 14:14:24 +0100 (BST) Message-Id: <002d01bfb9b9$92d0a9a0$09b1abc3@ukd> From: "Formacompany" To: "Finance Director" Subject: Instant Financial Data on every UK Business www.ukdata.com Date: Tue, 9 May 2000 14:20:42 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 9 14:30:27 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27461 for ; Tue, 9 May 2000 14:30:26 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA15583 for ietf-cat-wg-out720680; Tue, 9 May 2000 10:43:55 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA15507; Tue, 9 May 2000 10:43:29 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 15 08:48:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02649 for ; Mon, 15 May 2000 08:48:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA04099 for ietf-cat-wg-out720680; Mon, 15 May 2000 05:17:05 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id FAA04013 for ; Mon, 15 May 2000 05:16:50 -0700 (PDT) From: bench1@themail.com Received: from 01-048.011.popsite.net by MIT.EDU with SMTP id AA09473; Mon, 15 May 00 08:16:38 EDT Subject: your imaging supplies Date: Sun, 14 May 2000 16:34:29 Message-Id: <648.232350.713480@> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $84 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon May 22 12:55:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05135 for ; Mon, 22 May 2000 12:55:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA18447 for ietf-cat-wg-out720680; Mon, 22 May 2000 09:16:08 -0700 (PDT) Received: from gate.stm.swissbank.com (gate.stm.wdr.com [151.191.1.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA18441 for ; Mon, 22 May 2000 09:16:06 -0700 (PDT) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id MAA03382; Mon, 22 May 2000 12:15:54 -0400 (EDT) Received: from (nine.wdr.com [192.168.0.4]) by gate via smap (V2.0) id xmag03195; Mon, 22 May 2000 12:15:35 -0400 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA16162; Mon, 22 May 2000 12:16:25 -0400 (EDT) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA18205; Mon, 22 May 2000 12:14:47 -0400 (EDT) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA27811; Mon, 22 May 2000 12:11:04 -0400 (EDT) Date: Mon, 22 May 2000 12:11:04 -0400 From: Nicolas Williams To: Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: One more proposal (was Re: Ticket extensions in Kerberos revisions) Message-ID: <20000522121103.B27366@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200004190431.VAA10992@cayman-islands.isi.edu> X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk In this thread I proposed several technical approaches to extending Kerberos in a way that would solve the problem that I think Microsoft was trying to solve with it's PAC extension. Having seen Active Directory in action now, I am more convinced than ever that MS really was trying to make it possible to restrict or deny anonymous lookups of user account information. The second proposal I made was very skimpy on details because I hadn't thought those details through. I wish to put this proposal to you once more; it's a very generic one and, I think, fixes a number of problems, not just the problem MS was trying to solve with its PAC extension. Essentially I'm proposing a generic way of adding multiple extensions onto a any ticket, with several predefined extensions, such as: TGT restrictions (restrict what svc tkts a TGT may be used to get), embedded forwarded TGT extension (possibly with TGT restrictions), "localname" extension, LDAP access restriction extension, etc... The TGT restriction extension by itself could obsoletes proxy tickets and adds a large degree of flexibility to users and/or administrators about how much authority to delegate to services. The embedded ticket extension makes it possible for these extensions to be used with no client modifications; administrators would set default delegation policies. And so on. Here then, is more detail: 1. Generic ticket extensions. Tickets could have zero or more extensions included, on request of clients or by administrative policy, by the KDC. The format of these extensions might be: - Extension Name / Type (string) - Applicable Service Principals (list of applicable/not-applicable principal patterns) - Extension Data (possibly required to be parameter=value pairs; service specific extensions for proprietary services would be allowed to encode their data opaquely) encoded in, say, ASN.1 (for consistency). Clients of the TGS could request that some extensions be added. The TGS could automatically add extensions as per administrative policy, unless a client specifies otherwise. When a TGT bearing extensions is used to request a service ticket the TGS should copy all applicable extensions to the service ticket. 2. Some Extensions [To Be Standardized] a. TGT Restrictions Extension A list of allow/deny principal patterns. When a restricted TGT is used to request a service ticket from a TGS the TGS should attempt to match the requested service principal name with an allow principal pattern in this list; if no allow matches occur or if any deny matches occur, then the request should be denied. A restricted TGT could be used to request a cross-realm restricted TGT if the service principal's name is allowed by the pattern list and its realm is no that of the TGS handling the request. The TGS would copy ALL ticket extensions to the cross-realm TGT. b. Embedded Ticket Extension An embedded forwarded ticket. A service ticket may have this extension included by the TGS on request or by administrative policy; the embedded ticket would be for the target service principal of the containing ticket to use to impersonate the client principal requesting the service ticket. Embedded tickets may, of course, bear ticket extensions, such as TGT restrictions, say. c. Localname Extension A system username, a POSIX UID, a Windows domain SID and user RID and/or a specification for a name service query that will return a user's system credential profile. d. LDAP Restrictions Extension A list of LDAP object/container distinguished name (patterns?) that a ticket holder is allowed/not allowed to query and whether the ticket holder can modify any of those. e. Permission To Impersonate System Credentials Simply indicates to the a named system-specific service principal (say, LSA, for Windows 2000) that the service principal to which this ticket was forwarded has permission to locally impersonate the original user principal (i.e., the one that forwarded the ticket). f. Signature A service principal name and a checksum of the entire containing ticket, minus signature extensions, encrypted in the named principal's key (kvno should also be included). g. Generic File Services Restrictions Extension A list of generic restrictions to be applied to all remote filesystem protocols that can support them. One restriction might restrict the ticket holder to read-only operations for all of the original user's shared files. Another restriction might name some tags and permissions to be allowed to the ticket holder on any files of the original user that are so tagged. Another restriction might name a filesystem, a relative path from its root and a permissions mask such that the ticket holder can only operate with those permissions in the named directory (and sub-directories) of the named filesystem. I think such a restriction could be implemented even for NFS, though with some state on the server. h. Protocol-specific File Services Restrictions Extension i. Generic Naming Services Restrictions Extension j. Protocol-specific Naming Services Restrictions Extension k. Etcetera... Principal patterns would look and be handled much like good old shell globs. I've developed a simple algorithm for applying such patterns to a service principal, though I've yet to commit it to paper (or bits). Some examples: ldap/some.fqdn/*@*.SOME.REALM, ldap/*@SOME.REALM, ldap/*@*, etc... With such a framework of ticket extensions you can see how users and/or administrators would have a far more fine grained choice over credentials forwarding that plain ticket forwarding/proxying. A TGS might know that some services require some forwarding of user credentials and thus might include in all tickets for such services an appropriate embedded forwarded ticket with appropriate restriction extensions included. The replacement of the MS PAC spec, with this proposal, then, is as easy as: including embedded, forwarded TGTs in some service tickets with restriction extensions such that the forwarded ticket allows the service to query LDAP as the user. Such embedded TGTs may also include a "permission to impersonate user locally" extension and a signature signed with the key for the LSA principal on the same host as the service principal. This framework would also make it possible to define an extension that explicitly includes most or all details of a user's system credential profile, as in my first proposal. Only now this is not necessary nor is it desirable, IMHO, except as an optimization. This proposal, I think, solves several problems, including the riddle of how to forward less than a TGT, but more than a single proxy ticket (a restricted TGT could represent a huge number of individual proxy tickets). This framework also makes it possible to take advantage of it with zero client-side modifications to begin with and with service-side modifications only where one wishes to take advantage of these extensions. As a corollary, no modifications would need to be made to any protocols that are already kerberized or GSS-API'ized. And for replacing the MS PAC this system requires modifications only to some DLLs on MS DCs and servers. The fact that this proposed framework solves many problems might make it enticing to Microsoft, should a standard be approved based on it. Though this proposal would be useful regardless of what MS does with it. Finally, it could be argued that the embedded ticket extension is unnecessary, that protocols should be modified to support forwarding of tickets. Fair enough, but the advantage of embedded forwarded tickets is that they can be used with zero client-side code changes, and though GSS-API is the place to deal with forwarding of tickets, I think there's a fair chance that with Windows 2000 and Solaris 8 Kerberos will become the dominant distributed secure authentication system, thus minimizing the difference between using the embedded ticket extension and sending forwarded tickets separately. Toughts? Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 25 07:05:15 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03442 for ; Thu, 25 May 2000 07:05:14 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA24275 for ietf-cat-wg-out720680; Thu, 25 May 2000 03:35:05 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA24268 for ; Thu, 25 May 2000 03:35:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02849; Thu, 25 May 2000 06:34:57 -0400 (EDT) Message-Id: <200005251034.GAA02849@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt Date: Thu, 25 May 2000 06:34:56 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : SASL GSSAPI mechanisms Author(s) : J. Myers Filename : draft-ietf-cat-sasl-gssapi-01.txt Pages : 12 Date : 24-May-00 The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document amends section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt 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-cat-sasl-gssapi-01.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-cat-sasl-gssapi-01.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: <20000524104302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-sasl-gssapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000524104302.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 25 16:59:16 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20625 for ; Thu, 25 May 2000 16:59:15 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA17590 for ietf-cat-wg-out720680; Thu, 25 May 2000 13:19:44 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA17585 for ; Thu, 25 May 2000 13:19:41 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA20030 for ; Thu, 25 May 2000 13:11:59 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FV4TRF00.GF9 for ; Thu, 25 May 2000 13:18:51 -0700 Message-ID: <392D8AA1.C2183AB0@netscape.com> Date: Thu, 25 May 2000 13:18:41 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: SASL GSSAPI draft Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEFCEF23885002779FAF4A602" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------msEFCEF23885002779FAF4A602 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [This is also being discussed on ietf-sasl@imc.org. Please CC any responses there.] Following a between-meetings conversation in Adelaide, I have published a new SASL GSSAPI draft. The main change from the previous draft is that there is now an algorithm for determining the SASL mechanism name for an arbitrary GSSAPI mechanism. The generated names are extremely ugly, but there is really nothing else that will work. This draft maintains the SHOULD NOT directive against using SPNEGO underneath SASL. When the previous draft was published, this raised an objection, but the objection was nontechnical and failed to address or consider the interoperability and security problems which led to the SHOULD NOT directive. Work that remains to be done on the draft: 1. Need to add a directive to the "IANA Considerations" section which reassigns ownership of the GSS-SPNEGO mechanism to the IESG, changes the specification to that document, and changes its intended usage to "LIMITED USE". 2. Need to add an example stating that the SASL mechanism name of SPKM-1 is GSS-K7XIDASOK7XIDASO 3. Need examples of some SASL negotiations. 4. Need to rewrite parts of the sample program in Appendix A. The current program trades too much readability for brevity. It also needs to recognize the OIDs for Kerberos V5 and SPNEGO and map them to their special-case SASL mechanism names. --------------msEFCEF23885002779FAF4A602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIwMTg0MlowIwYJKoZIhvcNAQkEMRYEFG7vod9Wh3bn UnoUoc5+VZ0wHHjsMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAFexY+uxiO6GaIOKdpMrNYlSx9IK5YnRuxs4amiQP4we+ nAxnOKO5zKunDplW6/k6271CuahMUVnh0IDW+mFriGFNBl8+1vvdKUlzoaKfHUh64PGOeJYh PNjzOG2R7fU484v6iBhUAs3y9sGjzGVxSoNk3z5OopqGKqNvUTsJ97k= --------------msEFCEF23885002779FAF4A602-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 25 17:27:07 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21076 for ; Thu, 25 May 2000 17:27:07 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA19972 for ietf-cat-wg-out720680; Thu, 25 May 2000 14:02:35 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA19967 for ; Thu, 25 May 2000 14:02:33 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e4PL2Nt11325; Thu, 25 May 2000 17:02:23 -0400 (EDT) Message-Id: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil> To: jgmyers@netscape.com (John Myers) cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Thu, 25 May 2000 13:18:41 PDT." <392D8AA1.C2183AB0@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 25 May 2000 17:02:22 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >This draft maintains the SHOULD NOT directive against using SPNEGO >underneath SASL. When the previous draft was published, this raised an >objection, but the objection was nontechnical and failed to address or >consider the interoperability and security problems which led to the >SHOULD NOT directive. I think I might have missed that discussion (or did it take place on ietf-sasl?). I'd hate to ask you to reiterate all of that discussion again, so if you could please point me to a mailing list archive and an approximate time frame that the discussion about not using SPNEGO in SASL took place, I'll go away quitely :-) --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 25 17:31:40 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21237 for ; Thu, 25 May 2000 17:31:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA17432 for ietf-cat-wg-out720680; Thu, 25 May 2000 13:17:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA17427 for ; Thu, 25 May 2000 13:17:10 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA19806 for ; Thu, 25 May 2000 13:09:46 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FV4TNR00.QB1 for ; Thu, 25 May 2000 13:16:39 -0700 Message-ID: <392D8A20.8F99DD80@netscape.com> Date: Thu, 25 May 2000 13:16:32 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: [Fwd: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms16AB10EDB45E55198A5FF1ED" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms16AB10EDB45E55198A5FF1ED Content-Type: multipart/mixed; boundary="------------71B4869D48A89E924C037AF6" This is a multi-part message in MIME format. --------------71B4869D48A89E924C037AF6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, I gave the wrong list address to the I-D editor. --------------71B4869D48A89E924C037AF6 Content-Type: message/rfc822 Content-Disposition: inline Path: pixie.netscape.com!gateway From: Internet-Drafts@ietf.org Newsgroups: mcom.list.ietf-acap,mcom.list.ietf-sasl Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-01.txt Date: 25 May 2000 10:34:56 GMT Organization: Netscape Communications Corporation Sender: owner-ietf-sasl@mail.imc.org Approved: usenet@netscape.com Message-ID: <200005251034.GAA02849@ietf.org> Reply-To: Internet-Drafts@ietf.org NNTP-Posting-Host: 205.217.237.94 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Xref: pixie.netscape.com mcom.list.ietf-acap:725 mcom.list.ietf-sasl:296 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : SASL GSSAPI mechanisms Author(s) : J. Myers Filename : draft-ietf-cat-sasl-gssapi-01.txt Pages : 12 Date : 24-May-00 The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document amends section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt 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-cat-sasl-gssapi-01.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-cat-sasl-gssapi-01.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: <20000524104302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-sasl-gssapi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000524104302.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------71B4869D48A89E924C037AF6-- --------------ms16AB10EDB45E55198A5FF1ED Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIwMTYzM1owIwYJKoZIhvcNAQkEMRYEFKjoKjxurvzi 2dSqYNQjsgtMotaZMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAnbV4O7MyjU0UleH76pimxOSnZz+d1km54wBeglANd6up RsGQ77suidzm7PdnctytkbspZu4wdBtrp0Ua/lfbcgcAdj2LkdbH9/ZlK1zNU3zEWyg07vDk iJuZUYWKjUMck58f5fKVGWgcx2EW9lVhscUmSX1fAqbstRAR/Hh/C/Y= --------------ms16AB10EDB45E55198A5FF1ED-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu May 25 18:29:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21981 for ; Thu, 25 May 2000 18:29:09 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA22117 for ietf-cat-wg-out720680; Thu, 25 May 2000 14:40:22 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA22112 for ; Thu, 25 May 2000 14:40:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e4PLa3N09602 for ; Thu, 25 May 2000 14:36:03 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FV4XIC00.77A; Thu, 25 May 2000 14:39:48 -0700 Message-ID: <392D9D9E.97CBB770@netscape.com> Date: Thu, 25 May 2000 14:39:42 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ken Hornstein CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005252102.e4PL2Nt11325@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms73D66CC669AA43C95B91162D" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms73D66CC669AA43C95B91162D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > I think I might have missed that discussion (or did it take place on > ietf-sasl?). There was some discussion around March/April 1999 on the CAT mailing list. I wouldn't say those discussions resolved the issue. Please feel free to bring up concerns you have with my recently posted draft. > I'd hate to ask you to reiterate all of that discussion again, so if > you could please point me to a mailing list archive and an approximate > time frame that the discussion about not using SPNEGO in SASL took > place, I'll go away quitely :-) The reasoning is laid out in section 4 of my recently posted draft. There is a SHOULD NOT directive and a MUST directive in that section. --------------ms73D66CC669AA43C95B91162D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNTIxMzk0M1owIwYJKoZIhvcNAQkEMRYEFMM3zwJ2FpLv NWkRecO0wBenSTNWMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGACZvGKbwQC8vVVov1pCFKji2nIq81WNgh0Q6orFc8JGmb oQ/MAiOnxsFGZla4Hjb0F866c9KbDDsScVv+GWX8kSiwGJrtc7TtcCTk1sXjUfbW1LGPSxUL f6GrNrBub5PoSky3onkdKeumRs6NaxaV3UBcOfpijw1ecKcqI3hFtnI= --------------ms73D66CC669AA43C95B91162D-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri May 26 15:57:13 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24127 for ; Fri, 26 May 2000 15:57:11 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA11205 for ietf-cat-wg-out720680; Fri, 26 May 2000 12:26:00 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA11197 for ; Fri, 26 May 2000 12:25:57 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA01995; Fri, 26 May 00 15:25:59 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA27538 for ; Fri, 26 May 2000 21:22:36 +0200 (MESZ) Received: from uw1048.wdf.sap-ag.de (uw1048.wdf.sap-ag.de [155.56.94.108]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id VAA00554 for ; Fri, 26 May 2000 21:21:32 +0200 (MET DST) Received: (from d019080@localhost) by uw1048.wdf.sap-ag.de (8.8.8+Sun/8.8.8) id VAA23460 for cat-ietf@mit.edu; Fri, 26 May 2000 21:21:32 +0200 (MET DST) From: Martin Rex Message-Id: <200005261921.VAA23460@uw1048.wdf.sap-ag.de> Subject: rfc2744 error in GSS-API sample header To: cat-ietf@mit.edu Date: Fri, 26 May 2000 21:21:32 +0200 (MET DST) Reply-To: mrex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Oooops! It seems that we submitted a defective sample header file in the GSS-API v2 C-Bindings document, now rfc2744. The prototypes of all gssapi calls mis-specify the "minor_status" return value as "OM_uint32" instead of "OM_uint32 *". The oldest version of the c-bindings draft that I still have is -06 (July 1998), and it already has this error. What a pity that we didn't notice this error during all that time... The prototypes at the beginning of every subsection of section 5 are correct, however. Being output parameters, it should be fairly clear to a C-programmer that "OM_uint32 *" is necessary and that the sample header file is inaccurate. (I just received a request from Michael Seipel who is new to GSS-API and got confused by this error.) -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 30 00:20:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08781 for ; Tue, 30 May 2000 00:20:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id UAA01404 for ietf-cat-wg-out720680; Mon, 29 May 2000 20:36:29 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id UAA01399 for ; Mon, 29 May 2000 20:36:26 -0700 (PDT) Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e4U3aDt00689; Mon, 29 May 2000 23:36:13 -0400 (EDT) Message-Id: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> To: jgmyers@netscape.com (John Myers) cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Thu, 25 May 2000 14:39:42 PDT." <392D9D9E.97CBB770@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 29 May 2000 23:36:12 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> I think I might have missed that discussion (or did it take place on >> ietf-sasl?). > >There was some discussion around March/April 1999 on the CAT mailing >list. I wouldn't say those discussions resolved the issue. Please feel >free to bring up concerns you have with my recently posted draft. Okay, I saw only a message from Bill Ricker asking about SPNEGO, posting by you, and Paul Leach's reply. >> I'd hate to ask you to reiterate all of that discussion again, so if >> you could please point me to a mailing list archive and an approximate >> time frame that the discussion about not using SPNEGO in SASL took >> place, I'll go away quitely :-) > >The reasoning is laid out in section 4 of my recently posted draft. >There is a SHOULD NOT directive and a MUST directive in that section. Okay, I reread this section. I take it you mean this: A client which supports, for example, the Kerberos V5 GSSAPI mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL mechanism will not interoperate with a server which supports the Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL mechanism. This might be right, but for the wrong reason. As I read RFC 2478, you always deal with the OID of the underlying mechanism, so I don't think it's possible to support, for example, Kerberos "under" SPNEGO without just supporting Kerberos (well, let me rephrase that ... you could certainly write a SPNEGO implementation that would fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation, but you would have to work at it :-).) Having said that .... I think that a client that sent a SPNEGO token to a SPNEGO-unaware server would fail. I have been thinking for a while on how to migrate to clients & servers supporting SPNEGO, and I haven't come up with any good ideas yet (if I'm missing something obvious, then please let me know). As for this: If a client's policy is to first prefer GSSAPI mechanism X, then non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it may end up using mechanism Z when it should have used mechanism Y. This presumes that the app will have to have special-case code to determine which mechanisms exist and to apply policy information to the mechanism list; I'm not sure how you'll do that without giving the app knowledge of each mechanism, which would kinda defeat part of the purpose of GSSAPI. I have a hard time imaging this done in practice (it seems that you can give SPNEGO some policy constraints, but it doesn't give you the ability to do the ordering you want). I'm really torn here. I can't see the harm in duplicating the SASL negotiation with SPNEGO, and SPNEGO negotiation _is_ protected without having to do any extra work ... but the SASL negotiation really is better suited to piecemeal upgrade, which makes me think it's a better choice (but I'm not completely convinced). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue May 30 10:40:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00021 for ; Tue, 30 May 2000 10:40:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA15727 for ietf-cat-wg-out720680; Tue, 30 May 2000 06:56:05 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id GAA15722 for ; Tue, 30 May 2000 06:56:03 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 30 May 2000 13:51:30 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA19376; Tue, 30 May 2000 09:52:18 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 30 May 2000 09:52:33 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , jgmyers@netscape.com Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: RE: SASL GSSAPI draft Date: Tue, 30 May 2000 09:52:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken wrote, excerpting: > > > >The reasoning is laid out in section 4 of my recently posted draft. > >There is a SHOULD NOT directive and a MUST directive in that section. > > Okay, I reread this section. I take it you mean this: > > A client which supports, for example, the Kerberos V5 GSSAPI > mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL > mechanism will not interoperate with a server which supports the > Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL > mechanism. > > This might be right, but for the wrong reason. As I read RFC 2478, > you always deal with the OID of the underlying mechanism, so I > don't think it's possible to support, for example, Kerberos "under" > SPNEGO without just supporting Kerberos (well, let me rephrase that > ... you could certainly write a SPNEGO implementation that would > fail to interoperate with a vanilla Kerberos 5 GSSAPI implementation, > but you would have to work at it :-).) Having said that .... I > think that a client that sent a SPNEGO token to a SPNEGO-unaware > server would fail. I have been thinking for a while on how to > migrate to clients & servers supporting SPNEGO, and I haven't come > up with any good ideas yet (if I'm missing something obvious, then > please let me know). It's certainly true that an SPNEGO token won't be usefully processable by a target which doesn't support SPNEGO. If, however, a GSS implementation can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that GSS implementation is being used with SASL, it may not be too much incremental effort to make GSS_MECH_A and GSS_MECH_B also available for negotiation at the SASL level. There's a security vs. interoperability tradeoff, since the SPNEGO negotiation is protected but the SASL negotiation isn't. I'd suggest recommending, not discouraging, support for SPNEGO for use where available and appropriate, but also recommending configurable support to allow negotiation of individual GSS mechanisms at the SASL level. > > As for this: > > If a client's policy is to first prefer GSSAPI mechanism X, then > non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server > supports mechanisms Y and Z but not X, then if the client > attempts to > negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it > may end up using mechanism Z when it should have used mechanism Y. > > This presumes that the app will have to have special-case code to > determine which mechanisms exist and to apply policy information > to the mechanism list; I'm not sure how you'll do that without > giving the app knowledge of each mechanism, which would kinda defeat > part of the purpose of GSSAPI. I have a hard time imaging this done > in practice (it seems that you can give SPNEGO some policy > constraints, > but it doesn't give you the ability to do the ordering you want). If an application client (and its associated SASL and/or SPNEGO client) supports policy-driven mechanism negotiation, the preferred set might (1) span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms only, with non-GSS SASL mechanisms to be invoked only as a fallback if none of the GSS mechanisms are available. If (1), the client is most easily served by performing the negotiation (and exposing the individual GSS mechanisms) at the SASL level. Given the prospect of (2), however, it'd be good to be able to negotiate among the available GSS mechanisms in an SPNEGO-protected manner. --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu