From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 3 08:30:25 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 IAA16518 for ; Mon, 3 Apr 2000 08:30:24 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id EAA10243 for ietf-cat-wg-out720680; Mon, 3 Apr 2000 04:55:30 -0700 (PDT) Received: from sweet-transvestite.mit.edu (SWEET-TRANSVESTITE.MIT.EDU [18.177.1.157]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id EAA10231 for ; Mon, 3 Apr 2000 04:55:26 -0700 (PDT) Received: (from hartmans@localhost) by sweet-transvestite.mit.edu (8.9.3) id HAA09094; Mon, 3 Apr 2000 07:55:23 -0400 (EDT) To: Booker Bense Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt References: From: Sam Hartman Date: 03 Apr 2000 07:55:23 -0400 In-Reply-To: Booker Bense's message of "Thu, 30 Mar 2000 11:56:30 -0800 (PST)" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "Booker" == Booker Bense writes: Booker> - This halfway position (i.e. realm names are Booker> case-sensitive, but you can't use lower case ) makes very Booker> little sense to me. It's unfortunately how many of the non-DCE implementations work though. There is a significant deployed base of realms with upper-caseprincipal names. You can't make it case insensitive because that would break realm-based salting of keys among other things. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 3 19:16: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 TAA27124 for ; Mon, 3 Apr 2000 19:16:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA16775 for ietf-cat-wg-out720680; Mon, 3 Apr 2000 15:48:04 -0700 (PDT) Received: from perq.cac.washington.edu (D-140-142-110-88.dhcp.washington.edu [140.142.110.88]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA16770 for ; Mon, 3 Apr 2000 15:48:01 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id PAA04568; Mon, 3 Apr 2000 15:48:08 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Mon, 3 Apr 2000 15:48:07 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: Sam Hartman cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt 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 > It's unfortunately how many of the non-DCE implementations work > though. There is a significant deployed base of realms with > upper-caseprincipal names. You can't make it case insensitive because > that would break realm-based salting of keys among other things. Sorry, this isn't good enough. Let me reach over and turn on my recording (OK, recollection) of John Klensin's famous "pain" speech, which I happen to have handy because he just gave it again in Adelaide at the Internationalized DNS BoF: Resolution of incompatibility is a matter of allocating pain. You can't just say "it has to work this way because otherwise it won't work for me", since the basic problem is that everyone is saying that, so the problem is over-constrained. *Someone* will have to feel the pain of change or of non-interoperability, the question is who. I have a site with 100K user principals and thousands of host principals using an all-lower-case realm. It works fine, for some definition of fine. Changing realm names will be painful. Having to change our realm name, which is entirely compliant with RFC 1510, based on an unjustified one-line change in a not-yet-issed revisions RFC that declares it illegal in a non-backwards-compatible fashion, makes me want to know very precisely whose pain is being avoided, and how much, and why I have to suffer and they don't. It seems clear to me that the desired end state is having realm names be case-preserving in use and case-insensitive in matching, which is to say, *exactly* like host names in DNS. I think the dns-locate functionality serves to further justify this approach. Can someone explain in detail (or point to existing explanations) why requiring all-upper-case realms is a better end state? Thanks, - 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 Mon Apr 3 19:49: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 TAA27955 for ; Mon, 3 Apr 2000 19:49:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA19105 for ietf-cat-wg-out720680; Mon, 3 Apr 2000 16:20:48 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA19097 for ; Mon, 3 Apr 2000 16:20:45 -0700 (PDT) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id QAA23118; Mon, 3 Apr 2000 16:20:42 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id QAA19992; Mon, 3 Apr 2000 16:20:42 -0700 (PDT) Date: Mon, 3 Apr 2000 16:20:42 -0700 (PDT) Message-Id: <200004032320.QAA19992@cayman-islands.isi.edu> From: Clifford Neuman To: rlmorgan@washington.edu CC: hartmans@mit.edu, ietf-cat-wg@lists.Stanford.EDU In-reply-to: (rlmorgan@washington.edu) Subject: Re: comments on kerberos-revisions-05.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Using upper case DNS realm names is not a change, but instead the way things have been all along. Early on it was decided that names in Kerberos needed to be case sensitive because we did not have control over the environments within which Kerberos would be used. If names were not case sensitive, then use of Kerberos in an environment that had case sensitive names would be difficult. However, case sensitive names in Kerberos were easily used in environments where names were not case sensitive, simply by adopting the convention on which case would be used in the Kerberos encoding. Choosing case preservation, but insensitive matching was not an acceptable solution, because in such environments where case sensitivity mattered, the consequence for the security of the system could be significant. As to whether the convention chosen was for DNS realm names to be upper case or lower case, that was decided a LONG time ago. The chose was upper case - I do not recall the reason offhand - but unfortunately it wasn't a significant reason and it might have even been arbitrary. Now, their might have been a failure to communicate this choice, but it was the choice and it is not an issue that can be revisited at this time. Though it doesn't constitute communications of the convention, all DNS based realm name examples in RFC1510 were upper case. That would strongly argue against an imposition of lower case as the convention. 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 Apr 3 20:14: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 UAA28609 for ; Mon, 3 Apr 2000 20:14:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA21502 for ietf-cat-wg-out720680; Mon, 3 Apr 2000 16:44:02 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA21492 for ; Mon, 3 Apr 2000 16:43:59 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id TAA13874; Mon, 3 Apr 2000 19:43:55 -0400 (EDT) Date: Mon, 3 Apr 2000 19:43:54 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: "RL 'Bob' Morgan" Cc: Sam Hartman , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of Mon, 3 Apr 2000 15:48:07 -0700 (PDT) Message-ID: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > It seems clear to me that the desired end state is having realm names be > case-preserving in use and case-insensitive in matching, which is to say, > *exactly* like host names in DNS. I think the dns-locate functionality > serves to further justify this approach. Can someone explain in detail > (or point to existing explanations) why requiring all-upper-case realms is > a better end state? Requiring all upper case realms hurts the fewest number of people. The number of realms that are all upper case significantly surpass the number of realms which use lower or mixed case. Upper case realm names have been recommended practice since K4 days. Making them required is an easy solution to the case sensitivity issues of realm names. The reason that Realm names are case sensitive is due to its use as a seed to ciphers to ensure that the password "password" has a different hash for MY.REALM than for YOUR.REALM. For realm names to be entered in a case insensitive manner it must be possible for the client to determine which case rules are to be applied to the specified realm. This information is not available via dns-locate. The reason the client must be able to know the case of the realm prior to contacting the KDC is so that it can properly generate pre-auth data and/or be able to decode KDC responses. If you have suggestions on how the case rules for a specific realm can be determined, please propose them. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 3 21:10: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 VAA29961 for ; Mon, 3 Apr 2000 21:10:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA26657 for ietf-cat-wg-out720680; Mon, 3 Apr 2000 17:41:18 -0700 (PDT) Received: from perq.cac.washington.edu (D-140-142-110-88.dhcp.washington.edu [140.142.110.88]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA26652 for ; Mon, 3 Apr 2000 17:41:15 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id RAA04651; Mon, 3 Apr 2000 17:41:22 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Mon, 3 Apr 2000 17:41:22 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: Jeffrey Altman cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt 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 > For realm names to be entered in a case insensitive manner it must be > possible for the client to determine which case rules are to be > applied to the specified realm. This information is not available > via dns-locate. The reason the client must be able to know the case > of the realm prior to contacting the KDC is so that it can properly > generate pre-auth data and/or be able to decode KDC responses. > > If you have suggestions on how the case rules for a specific realm > can be determined, please propose them. How about this: In the case of a client using dns-locate methods to do the host->realm mapping, the correct capitalization of the realm name is already found in the value of the TXT record that the client looks up to do this mapping: _kerberos.foo.example.com. IN TXT "Example.Com" If the client has obtained a realm name in some other fashion (eg a user has typed in "kinit user@example.com"), and is going to use SRV records to find the KDCs (or kpasswd servers, etc), it can look up the TXT record corresponding to the realm name: _kerberos.example.com. IN TXT "Example.Com" and obtain the correct capitalization in just the same way. (This does overload the entry containing the realm mapping for the host "example.com"; presumably in practice it would just about always be the case that if there is a host "example.com" and a Kerberos realm "example.com" that the host services would be in that realm. But if separation is desired, there could be an additional record, eg: _kerberos_realm_name.example.com. IN TXT "Example.Com" to supply precisely this bit of info.) If the client is using a standard config file, it can use case-insensitive matching to search that config file for realm names. The only lose (that I can see) from current practice in all these cases is that "example.com", "Example.Com", and "EXAMPLE.COM" can't be separate realms. I hope we can agree that this occurs very little in nature; and the upper-case-only rule eliminates this too, so it isn't any better. I don't see any additional security issues in looking up case-info via DNS, vs looking anything else up in DNS. Any reason why this wouldn't work? Is that really all it takes? - 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 Apr 4 16:04: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 QAA14596 for ; Tue, 4 Apr 2000 16:04:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA00753 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 12:08:24 -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 MAA00725 for ; Tue, 4 Apr 2000 12:08:17 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 4 Apr 2000 19:04:32 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 PAA20350 for ; Tue, 4 Apr 2000 15:05:18 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <2GY3TTYQ>; Tue, 4 Apr 2000 15:08:14 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Draft minutes, Adelaide CAT session Date: Tue, 4 Apr 2000 15:08:12 -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 Attached are my draft minutes for the Adelaide CAT session. If any attendees have additions or corrections to offer, please send them no later than next Monday, 10 April, to support timely submission to the secretariat. Thanks, ... --jl Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF Reported by John Linn, RSA Laboratories. Thanks to Cliff Neuman and Ken Hornstein for providing their notes and slides, which were used as inputs to preparation of these minutes. GENERAL AND ADMINISTRATIVE DISCUSSION The CAT WG met for one session in Adelaide, with 88 attendees. John Linn opened the meeting with a general status overview, handing the floor to Jeff Schiller (MIT, Security AD) to present an organizational update. Jeff noted that the IETF today generally prefers tightly task-focused groups and that CAT's charter has been iteratively evolving for some time. He further observed that CAT's original focus was on the common GSS-API interface, rather than specifically on the Kerberos technology to which currently active standards-track CAT Internet-Drafts relate. It has been decided that the general CAT WG will go dormant, but with the mailing list to remain available as a forum to discuss progression of existing non-Kerberos CAT documents. Kerberos documents are to be transitioned to a new Kerberos WG, with the intent that its charter be established before the next (Pittsburgh) IETF and that an initial WG meeting without prior BOF session will take place there. Doug Engert (Argonne) has agreed to chair the group and will be doing so. Kerberos-related drafts that are ready for imminent Last-Call, in advance of establishment of the Kerberos WG, can still go to CAT. KERBEROS-REVISIONS AND PKINIT Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new Internet-Draft version was recently issued. Significant remaining issues include: decision on the mandatory variants of 3DES, ticket extensions, and integration of the referrals draft. Additionally, some smaller and editorial issues must also be addressed, and a change summary relative to RFC-1510 must be prepared. Updates since the last revision include integrated 3DES options, new registered types, and various edits, some of which require discussion. Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. Cliff also reported that some coordination is pending with Microsoft on PAC usage. List discussion is required on the ticket extensions field, included in the current draft; Cliff intends to send a message to the list initiating debate on the benefits and drawbacks of its retention. Further discussion topics had been introduced on the list: whether policies on adding additional addresses to tickets should be specified, clarification on case sensitivity in names. During the Adelaide IETF week, Cliff's intent was to perform initial wordsmithing and to initiate the 3DES and ticket extensions discussions. He also anticipates referrals text pending from John Brezak (Microsoft), which will require further list discussion. Once at least the two major issues are resolved, WG Last-Call will be requested on Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John Linn suggested that an extended WG Last-Call period would be appropriate. PKINIT is believed to have come to consensus among active participants, and to be ready for a parallel last call with Kerberos-Revisions. Recent changes include: name encoding, application of name constraints, and SignedData and EnvelopedData structure definitions. Regarding name encoding, the section on translation between X.500 names and Kerberos structures has been changed and expanded to specify the translation between general string and UTF8. A new structure corresponding to Kerberos PrinicipalName, but with general string replaced by UTF8String, was defined to enable the use of UTF8 in the additional name field when Kerberos principal names are embedded in certificates. Rules were added for checking of a Kerberos PrincipalName against certificate chains which contain name constraints. The SignedData and EnvelopedData structure explanations have been reformatted and slightly edited for clarity. The old PKCS#7 data OID has been replaced by a pkdata OID under the Kerberos-PKINIT arc. KERBEROS DNS-LOCATE Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document (-02 draft). He reported that dns-locate is currently implemented in two different independent Kerberos implementations, is widely used, and appears to work well in simple usage. There had been significant contention on the CAT list about security concerns with host-to-realm mapping. Ken observed that the vulnerability exists only between realms which share a cross-realm relationship, and that it can exist in many common Kerberos implementations even without the use of DNS-based host-realm mapping; use of a different naming approach would be required to resolve this. Ken believes that the facility is useful and should remain within the draft as a feature that could be activated selectively. Following the discussion which has taken place, he also believes that more clarification is needed somewhere about the relation between Kerberos and DNS, and may consider a separate informational document for this purpose. GAA Cliff Neuman presented an update on the GAA drafts. It was noted that any request for progression of these documents would target Experimental status and would follow integration results with several applications. Recent GAA work has focused on implementation and changes needed for integration with particular applications. The new drafts define new generic conditions, which generate audit records when policies containing those conditions are encountered. Also, optional parameters are now translated to appropriate types by condition evaluation functions rather than being described by the separate gaa_options structure. The new C bindings have focused on a more "object-oriented" approach, inspired by the style of Hudson and Young's SSLeay, and with three classes of functions. The draft now uses a generic gaa_stack object (with implementation-specific structure) for representation of ordered lists rather than using a separate ordered list for each type of data. OTHER TOPICS Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated that Microsoft and others are interested in squeezing 3DES into RFC-1964 rather than doing a general cryptosystem-independent scheme, and asked the attendees whether they wished to voice any objections to hacking into RFC-1964 rather than pursuing a wholly new approach. It was noted that interoperability issues might arise if a single OID were used. Ted Ts'o (VA Linux) would like to see an analysis of what the failure cases and modes would be. Tom plans to circulate a more detailed proposal to the list. A new version of PKCROSS is planned, but is currently blocked pending resolution on the Kerberos-Revisions ticket extensions question. Ted Ts'o asked the meeting about continued interest in specification of a GSS adjunct interface for interactive credential acquisition, such as that which had been documented in his GSS Conversation Interface draft. Approximately three attendees indicated interest. To this point, GSS' scope has excluded asynchronous callbacks to applications and their associated users, partly for reasons of OS independence. Sam Hartman (FundsXpress) observed that SASL is an important client of GSS, and that it already has its own facilities for asynchronous callbacks to applications; given these facts, he considered that it would be inappropriate to define an incompatible facility at the GSS level. Ted indicated that he was not aware of API-level convergence among SASL providers, but others commented that such convergence was progressing. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 4 17:27:38 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 RAA16976 for ; Tue, 4 Apr 2000 17:27:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA07707 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 13:30:52 -0700 (PDT) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA07700 for ; Tue, 4 Apr 2000 13:30:50 -0700 (PDT) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA06210 for ; Tue, 4 Apr 2000 13:30:49 -0700 (PDT) Message-Id: <200004042030.NAA06210@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: Re: comments on kerberos-revisions-05.txt To: ietf-cat-wg@lists.Stanford.EDU In-reply-to: Your message of Mon, 03 Apr 2000 16:20:42 -0700 Reply-to: ietf-cat-wg@lists.Stanford.EDU From: Jeff.Hodges@stanford.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Apr 2000 13:30:49 -0700 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk bcn@isi.edu said: > Choosing case preservation, but insensitive matching was not an > acceptable solution, because in such environments where case > sensitivity mattered, the consequence for the security of the system > could be significant. Please pardon my ignorance here: I'm curious about what consequential vulnerabilities you're postulating here. A specific concrete example would help, too. thanks, JeffH -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 4 17:32:25 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 RAA17209 for ; Tue, 4 Apr 2000 17:32:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA10440 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 13:59:33 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA10422 for ; Tue, 4 Apr 2000 13:59:26 -0700 (PDT) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA19925; Tue, 4 Apr 2000 13:59:26 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id NAA20746; Tue, 4 Apr 2000 13:59:25 -0700 (PDT) Date: Tue, 4 Apr 2000 13:59:25 -0700 (PDT) Message-Id: <200004042059.NAA20746@cayman-islands.isi.edu> From: Clifford Neuman To: ietf-cat-wg@lists.Stanford.EDU In-reply-to: <200004042030.NAA06210@breakaway.Stanford.EDU> (Jeff.Hodges@stanford.edu) Subject: Re: comments on kerberos-revisions-05.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Jeff.Hodges@stanford.edu Date: Tue, 04 Apr 2000 13:30:49 -0700 bcn@isi.edu said: > Choosing case preservation, but insensitive matching was not an > acceptable solution, because in such environments where case > sensitivity mattered, the consequence for the security of the system > could be significant. Please pardon my ignorance here: I'm curious about what consequential vulnerabilities you're postulating here. A specific concrete example would help, too. If an access control list were set up and entries matched in a case insensitive manner when a realm name was generated by systems with case sensitive names, and where two realms shared the same name except for case differences, then access would be granted even though the principal was not the one intended. 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 Tue Apr 4 18:16: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 SAA18542 for ; Tue, 4 Apr 2000 18:16:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA15547 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 14:50:51 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA15533 for ; Tue, 4 Apr 2000 14:50:47 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id RAA03993; Tue, 4 Apr 2000 17:50:46 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt References: Mime-Version: 1.0 From: Ken Raeburn Date: 04 Apr 2000 17:50:45 -0400 In-Reply-To: "RL 'Bob' Morgan"'s message of "Mon, 3 Apr 2000 17:41:22 -0700 (PDT)" Message-ID: Lines: 15 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > I don't see any additional security issues in looking up case-info via > DNS, vs looking anything else up in DNS. I think it yields the same exposures as mapping host->realm via DNS, but only if you don't verify that it's the same string (aside from case conversions) as the original. If that check is done, only DoS attacks should be left. I would suggest a different name than _kerberos since there's a chance that realm FOO.BLAH.ORG exists but host foo.blah.org isn't in it. > Any reason why this wouldn't work? Is that really all it takes? Sounds good to me.... -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 4 21:19:06 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 VAA21178 for ; Tue, 4 Apr 2000 21:19:05 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA06998 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 17:54:33 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA06978 for ; Tue, 4 Apr 2000 17:54:29 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id UAA04125; Tue, 4 Apr 2000 20:54:28 -0400 (EDT) To: "'CAT-WG List'" Subject: 3DES and RFC1964 References: Mime-Version: 1.0 From: Ken Raeburn Date: 04 Apr 2000 20:54:28 -0400 In-Reply-To: "Linn, John"'s message of "Tue, 4 Apr 2000 15:08:12 -0400" Message-ID: Lines: 68 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated > that Microsoft and others are interested in squeezing 3DES into RFC-1964 > rather than doing a general cryptosystem-independent scheme, and asked the > attendees whether they wished to voice any objections to hacking into > RFC-1964 rather than pursuing a wholly new approach. Shouldn't have been "rather", but "in addition to" or "while". The goal is to get 3DES available *now*, and a better cryptosystem-independent scheme available when we've banged out the details of little issues like whether ASN.1 sucks or whether 32-bit numbers are big enough or whether we should use already-defined Kerberos message structures or whether we can extend RFC1964 to be more cryptosystem-independent or whether we should order pizza for late-night meetings where go back and forth endlessly on such things without making any decisions. > It was noted that > interoperability issues might arise if a single OID were used. Ted Ts'o (VA > Linux) would like to see an analysis of what the failure cases and modes > would be. Tom plans to circulate a more detailed proposal to the list. IMHO the interoperability problems are similar to those that come up when adding new cryptosystems to Kerberos. Client side: Request from the KDC a session key from a list of cryptosystem types that your GSSAPI mechanism supports. DES must be on the list, unless you simply don't want to talk to a non-updated service; we now add 3DES as an option. If you haven't upgraded your software, you'll be asking for DES only. MIT's 1.0 release didn't do this, in fact it lacked a lot of compatibility support for cryptosystem additions, in the krb5 core as well as GSSAPI. The 1.1.1 release should fare much better -- it asks for DES only. Server side: Until the server-side software is updated for 3DES support, tell the KDC not to issue 3DES session keys for its services even if clients ask. If the KDC has 3DES support, it must include somewhere, somehow, an indication of whether a given application server can support 3DES. (Worst case, a flag saying "turn 3des support off". Best case, separate data for each principal.) This is needed for a smooth upgrade of Kerberos, even ignoring GSSAPI issues. If a client initiates a connection using a 3DES session key, and the server's krb5 code supports it but the GSSAPI code does not (meaning IMHO that the KDC isn't configured right), context establishment will probably succeed, and all following messages will fail to be understood. The end result of that depends entirely on how the GSSAPI library used and the application are written. If they're written poorly, a crash or security compromise could result; that's always the case though. If they're written well, they should print or log an error message, and fail. This could be a problem with code that negotiates for one of several authentication mechanisms -- the GSSAPI-KERBEROS context establishment will presumably be enough for both sides to agree on the use of that mechanism, and move on to exchanging data, but the data exchanges would fail because the messages couldn't be decoded. But as I said, this situation is assuming a KDC that's misconfigured for that application server. 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 Apr 4 21:59: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 VAA22304 for ; Tue, 4 Apr 2000 21:59:35 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA11963 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 18:36:17 -0700 (PDT) Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA11958 for ; Tue, 4 Apr 2000 18:36:15 -0700 (PDT) From: David_Hemsath@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id UAA27639; Tue, 4 Apr 2000 20:36:10 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568B8.0008CC07 ; Tue, 4 Apr 2000 20:36:05 -0500 X-Lotus-FromDomain: TIVOLI SYSTEMS To: ietf-cat-wg@lists.Stanford.EDU cc: raeburn@mit.edu Message-ID: <862568B8.0008CB9F.00@tivmta4.tivoli.com> Date: Tue, 4 Apr 2000 20:35:53 -0500 Subject: Re: 3DES and RFC1964 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk In regards to Ken Raeburn's posting of 04Apr2000 at 19:58:24, I respectfully disagree with the proposed "due it now/fast" approach. While I too want to see 3DES and other crypto algorithms available, in addition to DES, for the wrap() and unwrap() calls, I don't believe the problem is so bad that we cannot fix it in a more robust, well throught out manner. AFAIK, DES has not been the weak link (so far) in the vast majority of security breaches that get reported. It's usually poor planning, operation, human failure, et cetera. At one point, I thought an extension to RFC 2078 (GSS-API v2) for QoP specification would be the right approach, but I've since changed my mind. I think we should focus our efforts on SPNEGO and a new mechanism or mechanisms with stronger symmetric crypto. > > >> Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated >> that Microsoft and others are interested in squeezing 3DES into RFC-1964 >> rather than doing a general cryptosystem-independent scheme, and asked the >> attendees whether they wished to voice any objections to hacking into >> RFC-1964 rather than pursuing a wholly new approach. > >Shouldn't have been "rather", but "in addition to" or "while". The >goal is to get 3DES available *now*, and a better >cryptosystem-independent scheme available when we've banged out the >details of little issues like whether ASN.1 sucks or whether 32-bit >numbers are big enough or whether we should use already-defined >Kerberos message structures or whether we can extend RFC1964 to be >more cryptosystem-independent or whether we should order pizza for >late-night meetings where go back and forth endlessly on such things >without making any decisions. > >> It was noted that >> interoperability issues might arise if a single OID were used. Ted Ts'o (VA >> Linux) would like to see an analysis of what the failure cases and modes >> would be. Tom plans to circulate a more detailed proposal to the list. > >IMHO the interoperability problems are similar to those that come up >when adding new cryptosystems to Kerberos. > >Client side: > >Request from the KDC a session key from a list of cryptosystem types >that your GSSAPI mechanism supports. DES must be on the list, unless >you simply don't want to talk to a non-updated service; we now add >3DES as an option. If you haven't upgraded your software, you'll be >asking for DES only. > >MIT's 1.0 release didn't do this, in fact it lacked a lot of >compatibility support for cryptosystem additions, in the krb5 core as >well as GSSAPI. The 1.1.1 release should fare much better -- it asks >for DES only. > > >Server side: > >Until the server-side software is updated for 3DES support, tell the >KDC not to issue 3DES session keys for its services even if clients >ask. If the KDC has 3DES support, it must include somewhere, somehow, >an indication of whether a given application server can support 3DES. >(Worst case, a flag saying "turn 3des support off". Best case, >separate data for each principal.) This is needed for a smooth >upgrade of Kerberos, even ignoring GSSAPI issues. > >If a client initiates a connection using a 3DES session key, and the >server's krb5 code supports it but the GSSAPI code does not (meaning >IMHO that the KDC isn't configured right), context establishment will >probably succeed, and all following messages will fail to be >understood. The end result of that depends entirely on how the GSSAPI >library used and the application are written. If they're written >poorly, a crash or security compromise could result; that's always the >case though. If they're written well, they should print or log an >error message, and fail. > >This could be a problem with code that negotiates for one of several >authentication mechanisms -- the GSSAPI-KERBEROS context establishment >will presumably be enough for both sides to agree on the use of that >mechanism, and move on to exchanging data, but the data exchanges >would fail because the messages couldn't be decoded. But as I said, >this situation is assuming a KDC that's misconfigured for that >application server. > >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 David K. Hemsath, Senior Security Architect IBM Tivoli Security Business Unit Building 1, Suite 270 9020 Capital of Texas Hwy N. GHCC Austin, TX 78759 USA e-mail: dhemsath@tivoli.com Telephone: +1(512)458-4037 x5027; Fax: 2377 Cell phone/pager: +1(512)632-8567/5126328567@mobile.att.net -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 4 22:08: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 WAA22430 for ; Tue, 4 Apr 2000 22:08:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA12223 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 18:40:23 -0700 (PDT) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id SAA12218 for ; Tue, 4 Apr 2000 18:40:21 -0700 (PDT) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id VAA13545; Tue, 4 Apr 2000 21:40:17 -0400 Date: Tue, 4 Apr 2000 21:40:17 -0400 Message-Id: <200004050140.VAA13545@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "RL 'Bob' Morgan" CC: Sam Hartman , ietf-cat-wg@lists.Stanford.EDU In-reply-to: RL 'Bob' Morgan's message of Mon, 3 Apr 2000 15:48:07 -0700 (PDT), Subject: Re: comments on kerberos-revisions-05.txt Phone: (781) 391-3464 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > It's unfortunately how many of the non-DCE implementations work > though. There is a significant deployed base of realms with > upper-caseprincipal names. You can't make it case insensitive because > that would break realm-based salting of keys among other things. Since the very, very, very early days, Kerberos has always used upper-case realm names as the convention. This was the case for both Kerberos V4 and V5. OSF DCE violated this convention for apparently no good reason, and instead adopted the opposite convention --- and by the time those of us at MIT found out about it, it was too late to get them to change it. (Unfortunately, vendors have this bad track record of taking Open Source Software, making incompatible changes, and not telling the original authors about it until it's way too late, which usually causes a massive support headache for the original authors. This is one of the reasons why some GPL advocates dislike the BSD or X-consortium style copyrights. MIT explicitly chose the an X-consortium because we wanted vendors to adopt our code. This means we have to live with the consequences of some bad decisions by a number of vendors, not just OSF. Given 20/20 hindsight, if I had to do it all over ago, I'd probably argue in favor of some copyright license which didn't allow the implementation of protocol changes or enhancements without the express approval of the MIT Kerberos team. But, I digress. It probably wouldn't have helped the OSF screwup in any case.) Fortunately or unfortunately, only a few institutions chose to hook themselves to the falling star which was OSF DCE. There are a number of reasons why OSF DCE was a failure, but it basically boiled down to very few people wanting to adopt the super-heavyweight infrastructure which was OSF DCE. So I'd argue there are relatively few sites which have the lower-case realm name problem, especially in comparison with all of the other sites which obeyed the original Kerberos convention. This includes everyone using Transarc AFS, and the Cygnus, Cybersafe, and other commercial Kerberos products which didn't stray as far as from the original MIT implementation, and of course, not to mention, Windows 2000, which at least got right the upper-case convention for realm names. It seems clear to me that the desired end state is having realm names be case-preserving in use and case-insensitive in matching, which is to say, *exactly* like host names in DNS. I think the dns-locate functionality serves to further justify this approach. Can someone explain in detail (or point to existing explanations) why requiring all-upper-case realms is a better end state? No, I think matching needs to remain case-sensitive; otherwise you run into random access control list problems. It's better to be able to encourage people to use upper-case realm names, and it would be possible to add support to a KDC to help make the transition to upper-case realm names less painful. However, given that the Kerberos DNS I-D does support mixed-case realm names (with a someone awkward escape mechanism, but since it only hits mixed-case realms, I don't mind), I don't think we necessary need to chance anything from the current treatment of realm names, which is: * case sensitive * all upper-case convention for realm names strongly encouraged. - 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 Apr 4 22:49:29 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 WAA23516 for ; Tue, 4 Apr 2000 22:49:28 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id TAA14754 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 19:23:28 -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 TAA14749 for ; Tue, 4 Apr 2000 19:23:26 -0700 (PDT) Received: (qmail 28325 invoked by uid 50); 5 Apr 2000 02:23:25 -0000 To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt References: <200004050140.VAA13545@tsx-prime.MIT.EDU> In-Reply-To: "Theodore Y. Ts'o"'s message of "Tue, 4 Apr 2000 21:40:17 -0400" From: Russ Allbery Organization: The Eyrie Date: 04 Apr 2000 19:23:25 -0700 Message-ID: Lines: 32 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 Theodore Y Ts'o writes: > Since the very, very, very early days, Kerberos has always used > upper-case realm names as the convention. This was the case for both > Kerberos V4 and V5. OSF DCE violated this convention for apparently no > good reason, and instead adopted the opposite convention --- and by the > time those of us at MIT found out about it, it was too late to get them > to change it. We had some discussion of the issue here at Stanford when we had a good opportunity to pick our realm name, and decided that all lowercase was preferrable from a user education standpoint. A Kerberos principal looks very much like an e-mail address, and given that our K5 realm name will be the same as our main mailing domain (stanford.edu), we felt it would be a lot easier to explain username@stanford.edu to users who don't really understand all of this than username@STANFORD.EDU. I admit to a strong personal bias in favor of all-lowercase domain names everywhere. The MIT uppercase convention has always bugged me, and so has Stanford's current mixed case convention. :) Uppercase characters are harder to type, less frequently used, and pretty much everything else except LISTSERV (*sigh*) uses lowercase for just about everything. The all-uppercase realm name convention seems an odd throwback to me. I don't think that any of the above is a strong argument, in the sense that I think technical arguments and backwards compatibility arguments do trump these sorts of issues. But I wanted to throw out an example of reasons why people may decide to use lowercase realm names even without issues related to DCE. -- 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 Apr 4 23:46: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 XAA24299 for ; Tue, 4 Apr 2000 23:46:18 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id UAA18895 for ietf-cat-wg-out720680; Tue, 4 Apr 2000 20:24:10 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id UAA18890 for ; Tue, 4 Apr 2000 20:24:07 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id XAA04259; Tue, 4 Apr 2000 23:24:04 -0400 (EDT) To: David_Hemsath@tivoli.com Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: 3DES and RFC1964 References: <862568B8.0008CB9F.00@tivmta4.tivoli.com> Mime-Version: 1.0 From: Ken Raeburn Date: 04 Apr 2000 23:24:04 -0400 In-Reply-To: David_Hemsath@tivoli.com's message of "Tue, 4 Apr 2000 20:35:53 -0500" Message-ID: Lines: 43 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk David_Hemsath@tivoli.com writes: > In regards to Ken Raeburn's posting of 04Apr2000 at 19:58:24, I respectfully > disagree with the proposed "due it now/fast" approach. While I too want to see > 3DES and other crypto algorithms available, in addition to DES, for the wrap() > and unwrap() calls, I don't believe the problem is so bad that we cannot fix it > in a more robust, well throught out manner. AFAIK, DES has not been the weak > link (so far) in the vast majority of security breaches that get reported. It's > usually poor planning, operation, human failure, et cetera. Let me make this perfectly clear: I don't want work on a better, cleaner mechanism to stop. I want it pushed ahead. A point I tried to make in my previous message was that these are not mutually exclusive approaches. I'm absolutely certain it can be done better, and I've been of that opinion since well before MIT hired me nearly a year ago. In fact, I've been opposed to doing this hack in discussions on this topic in the past, specifically because I wanted the effort to go into getting the new mechanism done. But progress on that front has been slow; some proposals were put out longer ago than that. I'm very skeptical that it will be finished up any time soon. I don't want to have to tell someone, "No, we won't give you 3DES protection, because we're taking our time deciding details of a new mechanism to deploy it, and we decided not to put in the day's effort to add it to the old mechanism, because we don't like the old mechanism." At least, not to someone asking why we've added 3DES protection to everything except the MIT krb5 administrative interface that's based on GSSAPI, or why we recommend the GSSAPI over the krb5 interface when in our implementation it can't provide the same level of protection. One of the benefits of extending RFC1964 is that 95% of the work is already done, and most of the decisions are already made; it's almost a no-brainer. Whether or not there's been an actual breach -- a publicly reported one, that is -- is not the issue; it's coming within reach of large, determined organizations now, and it'll only get easier. IMHO that means we need to raise the bar higher ASAP. But yes, the fact that other attacks have been easier so far does reduce the pressure somewhat. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 7 09:23: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 JAA07642 for ; Fri, 7 Apr 2000 09:23:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA10692 for ietf-cat-wg-out720680; Fri, 7 Apr 2000 05:47:20 -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 FAA10685 for ; Fri, 7 Apr 2000 05:47:17 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA17590; Fri, 7 Apr 00 08:47:13 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id OAA13779; Fri, 7 Apr 2000 14:44:23 +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 OAA12790; Fri, 7 Apr 2000 14:42:42 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id OAA08367; Fri, 7 Apr 2000 14:42:42 +0200 (METDST) From: Martin Rex Message-Id: <200004071242.OAA08367@hw1464.wdf.sap-ag.de> Subject: Re: Draft minutes, Adelaide CAT session To: jlinn@rsasecurity.com (Linn John) Date: Fri, 7 Apr 2000 14:42:41 +0200 (METDST) Cc: cat-ietf@mit.edu, jis@mit.edu In-Reply-To: from "Linn, John" at Apr 4, 0 03:08:12 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 Just comments, no corrections (I wasn't at the meeting). Linn, John wrote: > > GENERAL AND ADMINISTRATIVE DISCUSSION > > The CAT WG met for one session in Adelaide, with 88 attendees. > > John Linn opened the meeting with a general status overview, handing the > floor to Jeff Schiller (MIT, Security AD) to present an organizational > update. Jeff noted that the IETF today generally prefers tightly > task-focused groups and that CAT's charter has been iteratively evolving for > some time. He further observed that CAT's original focus was on the common > GSS-API interface, rather than specifically on the Kerberos technology to > which currently active standards-track CAT Internet-Drafts relate. It has > been decided that the general CAT WG will go dormant, but with the mailing > list to remain available as a forum to discuss progression of existing > non-Kerberos CAT documents. Kerberos documents are to be transitioned to a > new Kerberos WG, with the intent that its charter be established before the > next (Pittsburgh) IETF and that an initial WG meeting without prior BOF > session will take place there. Doug Engert (Argonne) has agreed to chair > the group and will be doing so. Kerberos-related drafts that are ready for > imminent Last-Call, in advance of establishment of the Kerberos WG, can > still go to CAT. I must admit that we in the CAT WG have not really played by the IETF rules regarding the "timely fashion" and "focus" when discussing and finalizing most of our documents. Therefore I can fully understand Jeff's position procedurally (wearing his IESG hat). On the other hand I would really miss a single forum with the full scope that CAT had de-facto gathered over the last couple of years (that I remember). Could we retain this forum with its broad scope as it has been, even if we don't carry-on a formal active IETF WG status -- but still remain an IETF(-related) activity? I think it would be ok to spin off actual IETF WGs with a clear focus every once in a while when a specific need has gained enough momentum and interested parties to get some work done in short time -- while reporting WG status and results back to the CAT forum in a similar fashion as its currently done with rfc1510bis progress. What worries me: if CAT is no longer a working group, the "push" of 3 IETF meetings per year for the progress reports on all the individual issues within the current CAT scope may disappear, and the forum itself may loose significant value. While I was going to IETF meetings, there was a SAAG slot every time. And the scope of SAAG was even broader than CAT, it was about all of the security area in the IETF. And I really liked the overall wrap-up. SAAG is not an IETF WG, therefore no charter and no timelines either, and I still consider it a useful forum within the IETF. Security is complex and takes more time that a simple "feature-du-jour" protocol extension in the applications area. And over the past few years I've learned that defining an API and _getting_it_right_ is a difficult task; and for a security-related API it is extremely difficult. In the past I've built application support for arbitrary gss-api mechanisms, and I was really impressed about the quality of the abstraction of the API in most areas. Three years ago I basically finalized the GSS-API support within our "portable" application, based on the experience with two particular gssapi mechanism, Kerberos 5 and a public key based mechanism similar to SPKM. In the meantime 5 more gssapi mechanism are being used with our application, and I didn't touch my code at all. And I might add that I am using EXACTLY the same code on all of our supported platforms: Win32, OS/2, AppleMac, 6 different Unix, AS/400, OS/390. These days, I'm trying to provide the same vendor-independent interface for SSL libraries, and I can tell you it is a BIG MESS! I have made the first prototypes with OpenSSL, and I tell you that it is no fun. Not only is the code buggy as hell, the API is spread over ~2000 calls (pick what you need), seriously inconsistent (some get() calls return standalone copies, some return readonly references) and not really defined at all (what calls do you need to make to achieve an authentication with certain constraints -- most of the included sample code appears to allow client authentication, but is missing important prerequisite calls). Read it like that: I'm not a Kerberos guru, and I don't want to subscribe to any kerberos-bugs or kerberos-developers mailing lists, because I would have a hard time sorting out information relevant to me. However I am exceptionally pleased with the amount and contents of information that was compiled and distributed in this forum about all of the developments in the Kerberos area, because of a relatively low number of messages with high informational value. In the second half of 1999 I wrote a SSPI to GSS-API v2 translator for Microsoft Windows 2000, and my company has agreed to publish this code with a BSD-style copyright. It already does most of what our application needs and makes W2K Kerberos look just like MIT Kerberos 5 to our application, however there still are some open issues (and a few bugs). One of those is the resolution of hostbased service names and how it should be done. Currently the code performs the processing from RFC2743, Section 4.1, but it doesn't know how to come up with a REALM name. I'm still looking for volunteers to try and comment, however because of current job-related time constraints I may show significant delays in response over the next two months. Although technically, I know little about Kerberos protocol details, the broad scope of information discussed in CAT during the past years, and the expertise of the participants provided enough information to write this wrapper in a fashion that makes our application happy. On a related issue, I'm very interested in how the 3DES encryption will be integrated into Kerberos, because some of the issues will matter for the interoperability and upgrade/migration when running our GSS-API based application with Kerberos. > > OTHER TOPICS > > Ted Ts'o asked the meeting about continued interest in specification of a > GSS adjunct interface for interactive credential acquisition, such as that > which had been documented in his GSS Conversation Interface draft. > Approximately three attendees indicated interest. To this point, GSS' scope > has excluded asynchronous callbacks to applications and their associated > users, partly for reasons of OS independence. Sam Hartman (FundsXpress) > observed that SASL is an important client of GSS, and that it already has > its own facilities for asynchronous callbacks to applications; given these > facts, he considered that it would be inappropriate to define an > incompatible facility at the GSS level. Ted indicated that he was not aware > of API-level convergence among SASL providers, but others commented that > such convergence was progressing. Independent of what the SASL providers are doing, if SASL was using GSS-API as one of its methods, it could only use callbacks provided via GSS-API anyways (which we currently don't have). So the SASL guys should be *requesting* a gss-api level callback from us that they can pass through. And in order to make things interoperable they can discuss their ideas with us. :) As a kind of library and "middleware" provider in our company, I'm not totally comfortable with Ted's callback proposal. But it's probably nothing about the details of the proposal itself, rather than the situation when this stuff is going to happen, and the way in which gssapi mechanism implementors are going to use it. In distributed environments, where gssapi security contexts may be established and destroyed very freqently, some sort of Single Sign-On will usually be required to be usable (=acceptable to users). GSS-API mechanisms that perform a credentials callback for every single security context won't fly in most distributed environments. Most everyone has probably seen or heard of "SecurID" cards, which may have helped Security Dynamics to buy out RSA. Now if one such beast was used by a gssapi mechanism to "authenticate" a user directly during security context establishment, there is no chance that such a mechanism would fly with applications like ours. If instead one was using a certain commercial Kerberos and used the SecurID card for initial authentication to obtain a TGT, the applications wouldn't notice a difference to other Kerberi and be happy. One of the things why I dislike the callback method is because the application will loose control for an indeterminate time, being locked within context establishment, tying resources of the server. And since during a callback were way down the call stack, so you can't just go on processing all other events that your application may be expected to process. I would really like the option to handle the user interaction in an asynchronous fashion, just like I'm doing it with GUI events and Network I/O events. -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 Fri Apr 7 10:23: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 KAA08764 for ; Fri, 7 Apr 2000 10:23:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA11564 for ietf-cat-wg-out720680; Fri, 7 Apr 2000 06:52:21 -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 GAA11558 for ; Fri, 7 Apr 2000 06:52:19 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 7 Apr 2000 13:48:32 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 JAA20262; Fri, 7 Apr 2000 09:49:14 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <2N2QZB90>; Fri, 7 Apr 2000 09:52:14 -0400 Message-ID: From: "Linn, John" To: "'mrex@sap-ag.de'" Cc: jis@mit.edu, "'CAT-WG List'" Subject: RE: Draft minutes, Adelaide CAT session Date: Fri, 7 Apr 2000 09:52:14 -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 writes, excerpting: > I must admit that we in the CAT WG have not really played by the IETF > rules regarding the "timely fashion" and "focus" when discussing and > finalizing most of our documents. Therefore I can fully > understand Jeff's > position procedurally (wearing his IESG hat). On the other > hand I would > really miss a single forum with the full scope that CAT had de-facto > gathered over the last couple of years (that I remember). > > Could we retain this forum with its broad scope as it has been, even > if we don't carry-on a formal active IETF WG status -- but > still remain > an IETF(-related) activity? I think it would be ok to spin off actual > IETF WGs with a clear focus every once in a while when a specific need > has gained enough momentum and interested parties to get some work > done in short time -- while reporting WG status and results back to > the CAT forum in a similar fashion as its currently done with > rfc1510bis > progress. What worries me: if CAT is no longer a working group, > the "push" of 3 IETF meetings per year for the progress reports on all > the individual issues within the current CAT scope may disappear, > and the forum itself may loose significant value. While I was going > to IETF meetings, there was a SAAG slot every time. And the scope > of SAAG was even broader than CAT, it was about all of the security > area in the IETF. And I really liked the overall wrap-up. SAAG > is not an IETF WG, therefore no charter and no timelines either, > and I still consider it a useful forum within the IETF. The CAT-WG mailing list will continue, as an appropriate channel for discussing status and activities related to CAT-produced documents, excepting the Kerberos work which will proceed in its own new WG. IETF WG meeting slots are a limited resource, and need to be applied most effectively to the tasks of standards generation, where issues on actively evolving specifications need to be resolved. In CAT, most of the documents with current activity and consensus for standards-track advancement are already Proposed Standards or have been approved for Proposed Standard publication. For IETF purposes, CAT's ongoing primary role will be to support their ongoing advancement as schedules and circumstances permit. As such, I believe we've reached a right point for the group to transition to e-mail operation. > > Security is complex and takes more time that a simple > "feature-du-jour" > protocol extension in the applications area. And over the > past few years > I've learned that defining an API and _getting_it_right_ is a > difficult > task; and for a security-related API it is extremely difficult. > In the past I've built application support for arbitrary gss-api > mechanisms, and I was really impressed about the quality of the > abstraction of the API in most areas. Three years ago I basically > finalized the GSS-API support within our "portable" application, > based on the experience with two particular gssapi mechanism, > Kerberos 5 and a public key based mechanism similar to SPKM. > In the meantime 5 more gssapi mechanism are being used with our > application, and I didn't touch my code at all. And I might add > that I am using EXACTLY the same code on all of our supported > platforms: Win32, OS/2, AppleMac, 6 different Unix, AS/400, OS/390. Thanks for this excellent report. If your code corresponds to RFCs 2743/2744 (vs. 2078/1509), this could be material input to the cause of advancing these documents to Draft Standards once the time is right. --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 Fri Apr 7 21: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 VAA22402 for ; Fri, 7 Apr 2000 21:33:30 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA29879 for ietf-cat-wg-out720680; Fri, 7 Apr 2000 18:05: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 SAA29869 for ; Fri, 7 Apr 2000 18:05:43 -0700 (PDT) Received: from punsmtp.ip.eth.net by MIT.EDU with SMTP id AA18810; Fri, 7 Apr 00 21:07:27 EDT Received: from localhost ([202.60.147.121]) by ip.eth.net with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 8 Apr 2000 06:33:32 +0530 From: "Navtam Gosai" To: "uk-email1" Date: Sat, 08 Apr 2000 06:26:29 +0550 Subject: ARTHRITIS - NOW DRUGS FREE CURE!!! Reply-To: healing@healthcarenoticeboard.com Mime-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001__863052_23189.48" Content-Transfer-Encoding: 7bit X-Priority: 3 Message-Id: <088f03203010840PUNSMTP01@ip.eth.net> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__863052_23189.48 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002__863052_23189.48" ------=_NextPart_001_002__863052_23189.48 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable NOW PAIN RELIEF AND GREATER MOBILITY CAN BE REALITY=20 If you are suffering from arthritis or any other acute or chronic pain rela= ted=20 condition, you have just taken the first step towards a better quality of l= ife. OUR PROMISE TO YOU!! We guarantee that if you use ACE as specified in our instruction manual you= will=20 have pain relief and increased mobility in just a few weeks, or in some cas= es=20 days. ACE's patented formula of currents and frequencies, take the body out= of=20 protection mode and into healing mode, giving prolonged pain relief and inc= reased=20 mobility.=20 UNIQUE If you've tried everything else you must try ACE which is now being recomme= nded=20 by doctors and hospitals world-wide - it is an approved medical device. The= original=20 price of this valuable instrument is is =A3245, but as a special case you c= an get=20 this for =A3199 including tax and delivery.=20 To know more about Acehealing Machine and to place order just type the following address:=20 http://www.healthcarenoticeboard.com/acehealing/default.htm =20 We are health related site and have new and unique products.=20 - Thank you. ------=_NextPart_001_002__863052_23189.48 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable NOW PAIN RELIEF AND GREATER MOBILITY CAN BE REALITY  If you are= suffering from arthritis or any other acute or chronic pain related=


Autorised Agents

 

NOW PAIN RELIEF AND GREATER MOBILITY CAN BE REALITY

If you are suffering from arthritis or any other acute or chronic pain rel= ated condition, you have just taken the first step towards a better quality= of life.


OUR PROMISE TO YOU!!

We guarantee that if you use ACE as specified in our instruction ma= nual you will have pain relief and increased mobility in just a few weeks, = or in some cases days. ACE's patented formula of currents and frequencies= , take the body out of protection mode and into healing mode, giving prolonged pain relief and increased mobility.<= /font>

UNIQUE

If you've tried everything else you must try ACE which is now being= recommended by doctors and hospitals world-wide - it is an approved medical device= . The original price of this valuable instrument is is =A3245, but as a s= pecial case you can get this for =A3199 including tax and delivery. <= br>
To know more about Acehealing Machine and to place order
Just click Here

or just type the following address:

http://www.healthcarenoticeboard.com/acehealing/de= fault.htm =


We are health related site and have new and unique products - howev= er, if you do not wish to receive any more e-mails from us - please click here


- Thank you.
------=_NextPart_001_002__863052_23189.48-- ------=_NextPart_000_001__863052_23189.48 Content-Type: image/gif; name="healthcity_title.gif" Content-Transfer-Encoding: base64 Content-ID: <86306727712@healthcity_title.gif> Content-Transfer-Encoding: base64 R0lGODlhLQFHAPf/AP///xAQECEhITExMUJCQlJSUmNjY3Nzc4yMjJycnK2trb29vc7Ozt7e 3u/v70I5Oe/Ozq2UlJyEhP/W1v/OznNaWr2UlCEYGDEhIRAICCEQEP/Oxu+9tf/Wzr2UjO/G vf/e1u/OxnNSSv/Gtb2Ec2NCOe/Wzv/OvXNaUmNKQv+1nEIpITEYEL2lnP/Wxr2UhP+9pZxz Y+/Gte+1nM6Ue/+tjFIpGHM5If/ezr2cjP/Grd6ljEIxKf+1lHNSQq17Y72Ea++lhIxaQr1j Od5zQiEQCM6tnK2Me//OtYxrWv+9nL2Mc++tjN6ce5xrUv+thGNCMb17Wq1rSnNCKb1rQu+E SoxKKc5rOUIhEGMxGHNjWv/Gpc6Uc/+1jL2EY++lezEhGP+lc++ca5xjQr1zSv+cY857SoxS MWM5Ia1jOd57Qv+MSr1jMf/Wvb2Ue3NaSv+9lJxzWu+thIxjSv+1hFI5Kc6MY/+te96UY717 UnNKMf+la4xaOa1rQu+UWr1zQt6ESv+UUpxaMb1rOd69pZyEc//Ore+1jGNKOb2Ma++lc5xr Sv+tc61zSu+cY86EUt6MUkIpGP+cWu+UUs57Qu+MSoxSKf+USnNCIa1jMf/GnIxrUv+9jO+t e3NSOf+1e72EWu+la2NCKb17Sv+lY5xjOf+cUr1zOVIxGGM5GP/Wtb2Uc//GlL2MY96lc/+9 hIxjQv+ta3NKKWNaUkIxISEYEP+1c//Wrb2ce1JCMf/GjGNKMXNSMTEhEEIpEBAIACEYAK2l AL21AM7GAN7WAO/nAP/3AP//5ykpAEJCAFJSAGNjAHNzAISEAJSUAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAALQFHAEAI/wCfCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgjMjPGkZiyXwI3cmQ2MRlHY8syqlzJsqXLlzBbLjtJrOHMYcBMciwG8pnI mgJ1Gis2DGSzk8EI6hwm0NlJYM+CGRu2sRjSnjGzat3KtStCkUMrirRqjORAYRyTCvxF1hnB ncYGIhvGUdlAZSfNet3Lt6/fv8+QcSw6MAGAw4gPCByAOPFeBI0PL4TcWAHgyw8fhADRoYML F0iQjNCxRROrXBhZ7CnDuswfzBIJRAZAYKDsyLUHDnAw+7CDAgYP9J7NwHbkBQoX4D4ovLHi hgaGH07AXHrj4rcbN3hmeHbu3cN/H/98AAKHixMnUFB0cwvJCQ88DMaav2cPKftlSJWRtF+S /zRUmIIGQZgEssYNsEVH3AEMDCfBM5E5IJAACswm4TMBNGgdYpY9k91hyD2j3IYKLFBiBAcI INCHGz7THGLFOZThhhwK9CJiDmRwUIQTVsjjQG6QBoMSIlBkxyd3IHlHIwxFoh9/CaESSCCX rGFlEbAJ1F1jBLEIgIoY8hZZAgYgICYAEXA33AIjImbAQA1Eth1CjDWWm0FtHvbmit494yON IKrZG5uR7SlQb88ZFMCZiJFpJmJpFpQBEF1U2kOlNTyh6aaaKgJGQZ6EIaqoe+jB0BT+SUKF QYJMuUYgWGT/KatLW0o2660rZTCKHlji2hdYJ5Xl67DEFusSXoNhZZAxQD3zSzLIGJRMMgXN xFFKz0wbrUI5JQPVQc9S+8xRHH1r7Lno7mVtWBOtS61UPK2FFEHkoiQQssx2ZJdByBbjVroA B8wXW0MZ8+9Av9BVzLYHCYVtQckobEwwDxf0C1pDBSNuQcAw4/G+AocsMmZCBeuMsnzOFkDK jYXY1Z+BJqRgY2AWVKuhEB3AKAAuoxsBZ51t4IFErejCydGcyFEHQqKsRop+rj2DhiwDonuj dnHONhDMADBAQAYG7JzoMxKYiMAFXUY2UGQdFjRArdIhF8ByzxiQNQANgOmlAzUv/1S2Amen zWUBG/Kto5+ReQ222AR5IFpoGGyVwRn4sSZJ1QVREogpVBpoZRawzR3Z2Hcf9tzVid95aGMP FnTmnB5qjdDVCaEOgGWEVzbLbGMnFFnrBL2um8qzW+c1QmAM2YMSSvRAw+EIabCLJxoItAKS jDByR/ZN9nc5QoJw/mqsvhZwwAE4P5N7jZIyWJkCB6BtUAYEHFA2o7A/o+Fhkfre8kRXG8BB 6He+AvZtfvW7n3YKMjMA8K0hGXAfh+AnP5eIghH1CcMeHOGQSEgCEARp1SUMhKCRBaxOiDGh Cle4ko55rGIsjKEM99KxYAjjhs0AGUWEYq4Z+vCHMHHKSP/AxRGUOaQYVikGEJfIxIyARRgL YcYyfiGVk8RLIFWMy0CGQRZiBOtaBhFiFo3BsHqlxWRNTCO64LKxhwCjYGrRSTMGAi9hBeUk UBTIun6RsJ2gjC4dMaIaB+mrJ1aEGFahGBhDUjBzvZEjB8OYHRMCSC0S8pLGIou9DoIMq7RR KQUzWEGEaK+xMEwgmgxWMXT4DC9aRZCYjOWskpFKLnJEGD08iBeNsTEBFNAAKxtIA2O0l/3h TZZeqYAMToAEHThTB8z7gUpEATU/9Ao24UrGLzq2k1NeAFEsQ0zPtsK1cUrKQsjMDAjK4xkX EAIFPEBBEtwwA9Mk4iBeeIUXdgH/vYSQwWmseY3AvESdcJouIwNQoDgPEEwbHSc5kUHAQRoI gN4tRAA7g1FCEroARi2AoQO5EQMaWoASfbShFJFAZyiwgQ1UYCKruMUWSLMFOMhhFwPRA33q 8zSo8SdV30MIFmC5F4IWRnYCKZ10cGa73rTtoQj5ptoOsr7DqI5OGeXZVQvS1NlYJqsWEuAz lDqc9FUAPRtwgRFi0gj63Ec/T7OcJPwwBR2hYUqmwMQzbPCqNegVM1wDlGISRxAUppAgdqPR 2v73DIwC6keRKUAEeiNRCI0pIoltEeJ6w4B+Wlajw5uqQF6ABEOQxrMQcQIoVgsKKDDkEXAt A0J+gVcD/xmICFnyUqKqetDNFi43FD0MAxBgAMciJjdeGsgFDOhbWx3ESzga3dWIuZDgdo24 xrWqQSuKkMD2xgFXfcOQhqQEREjEE0m6w/YYgYcm8Yc1kUhIJWwLq1nNpmdXcxlZF1DBghSK q84JKVINwqKtCiSwz0luYB0AUoEUgFGf1ROAHbPYyiRkv/1FCCKa14MOX6oHXvDBCjzhhCBo ig4oBgVBFGGL7DEiDIxYAUN+KokpHKRVtiXfrZTqutERRAI0KqgAyNob5PJOIT6mqgJO1DfR 2UkgAQAyjQw1ZECprjfpK4iUrdO/g6zAB15oQhc4FQUhfAohYnixBvdAhoacwf8/Ah0Ijl9l AxMGAGYucWwDUBoRmJlzVnrms8AaUZ9Cp9OEtDu0ohc9kQie74CMjrSkJ01p2CRDkkOstKYP /ZNlBMOGJ9u0qH0FjDEGgyz+OiVEdqmWUbsaV6QMNUFE8kmHkFLVr871X+p1sGVZEiKCSUtW cpJLXRt7LbvkpUImdi+yVEyIeWzKSZLBDE32miDKSLYolZLFZJBS2ccO9zOSaAxWcjKVmX4G Kd8SLGJUmyytFgi5SEJKavVRk6heRrHF/eoszrEh2pT2InUSbbAU41tCiXYrwQiMJObRGTwx Y7z5feySEVUhWQSJSECWbHPNxCp6YXUydikMlP0iWLX/priuq2IMhUPk5EMU9h0XKZBK9uQo XYQhvU5ibpWvfF4UqaINkYgVISpxICxnWLAI8gunbAzmzPY5v01CFqIiI+X3+mIPq8gUeQeS 3SPhJs3HNW2pU5yUzWI6XYgBS6FcUS6qHEyxjY7HXD5yKmZXOb4mhnBX4nrWHXGIAAhAeL8E AAFsUgCk886XR/iBD9fcyi+YkUViOAPrgDfGvxubuIbuDDheCS5DDFBAseb6Ai3AgWeY6Uzy HkIlj2CNfmRRrE4O5ZQZTfB995Knri2kN6+eBdA+44I2iEYHIyiNJuKAET3cJz9laDNsGv7F jqgauqD3Utu40vvtE3g2wGPg//myDBHznQ/0AMsABCbQGRd0oBCoVUgrXnE0OXgi/mupnH7i jBlyFYMYzfB3sUNY2+V9WpFfCnE1+TMQApBkDyEAxsQlF1E/6CNoK0Ee7NcZH1ALEpEIrKAJ cBCCRwMLB1EK9SF7ZdAHkNAfgoAuumUcDghlEgQiDUZgESgnpsciBkgQXEN+V2NRMgNWAEB+ BHCD2iFADZhkcLNnAxEAM8gzNWgQJsAZG3ACHIB/C+EGx6AKojECS3BmAoEHOxVXKAhUkvAH LBB5AnEFgYA5gOEl6Ic6pgce1pE+XfVfq8M+CDEb8Xc16KcQ1gUiBuYij2UA0OVdOfIMdLhU BqEFnf+xehw4EZuwCkmweM8wH7HAU2S4H94DCEXwZqbQggJRBVZSQpfBWxI2VkgViBbSUIbV NQZwAVHWGBcSYTxTO7IzeASgN3QDURHyh3SSOLE4izjyDJNVOGDCihGCUkfATOihBVlRC2fg CPbRUz8FCVOAFUUgCXiFBpngOaYIGL0XZAKxMxWUhIixgItBegXUexUWM411AAoghMBni7UB N0N4YH0SEQPAjufjjs8ghCMVPJFxjnLSOCNgCKblFc7XU7J1EFPAOVNiW2ughn6BjzSCHFAl EOM4EBkwjpwFZWyjj4/VGHuSOMOBHbORYQrxkYASIxg5kP7FWBw5YKS1BVv/AAPxMRG0QAdK cge8wBB6AH2kkBDh0zlWYgW5NRuwE1gxsjMMYIT5qD8lqXu06GByMmAFAV3DUT8j6RBSCU6E GBldRpDXIZU4EwMwgJNKsAMTAQU/qT150D39wQLyJZFrMASy4iV3kgFH1lzDgQDQ03uCSRB5 EkzJhRBwg4uIcjUIgDoWiCcR1U+HuV3kB5iUhVopQF5KoAJMgIUIgV5J4mKM0CRPIgnxdRC+ gJR6aV8RZZhf+Yo4AoSRcUCG5TKoIzO1WTwRoiIswjdhpSjdISG7WVg0aYtfEozfBYQEsQMe BgcdxgW0YBBgMAeu8AoodmZFoCSkmZoJwQJPUgY2/2YQRWAKI5SXuBKBtTiWEsieiPGHBsAm AqRUC4B+eZIogZUQBdZdB7ldA8CVtyOPWkOf9hlg7/ievNkY8CmfBkECHtZhXVADERqhnHIH dKAI1TMQeeBiGhQGovBaqXIG5GmeBtKatyJ6DDgbszAQqDgoz5ABRFZkEzIbBbWHBiqZ6Sg4 T5YBYTkbKgKjj3Vlf0lVgPJnz1ACYiahFJopZCZoLKBmpMIHDJEBqbIqBFGe52miuFJlhzUQ x6iHAhE20uEAFeSEMYoYiOmjSHajEKFUqnMBEhCjDXBVZrohKLUzDhCZwiSED+QSY0Aq9TGX UzoJqnKl4hMIuGVCeaKOF1UBpIcRfuozfgyRJzvIEAEwIg3AnI16N5D6DMv1aMWSAWtmaA6B Bvw3X65ikSHznwRgeriyqIzHEE1TH6Vgl7HKFYl2q7q6l6K1q756GW3CqL+KGQEBADs= ------=_NextPart_000_001__863052_23189.48-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Sat Apr 8 17:20: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 RAA15182 for ; Sat, 8 Apr 2000 17:20:31 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA20280 for ietf-cat-wg-out720680; Sat, 8 Apr 2000 13:41:41 -0700 (PDT) Received: from relay2.sion.com (root@relay2.sion.com [200.43.36.101]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA20271 for ; Sat, 8 Apr 2000 13:41:34 -0700 (PDT) Received: from PROXY (smtp.sion.com [200.43.36.110]) by relay2.sion.com (8.9.3/8.9.3) with ESMTP id RAA17599 for ; Sat, 8 Apr 2000 17:56:36 -0300 Received: from intranet - 200.43.37.94 by sion.net with Microsoft SMTPSVC; Sat, 8 Apr 2000 17:38:20 -0300 From: "PortalProfesional.com" To: "ietf-cat-wg@lists.stanford.edu" Date: Sat, 08 Apr 2000 17:40:04 -0300 Subject: LEAME, ES IMPORTANTE - www.portalprofesional.com Reply-To: info@portalprofesional.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Message-ID: <014392038200840PROXY@sion.net> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Muchas Preguntas: - Estas Buscando Empleo? - Tienes empleo pero quieres uno mejor? - No sabes donde dejar tu Curriculum? - Eres Profesional o a punto de egresar? - Ud es una Empresa y necesita hacer publicidad? - Necesitas EMAIL Gratis? - Necesitas Pagina Web Gratis? - Ud es una Consultora o Empresa y necesita publicar sus Busquedas Laborales? - Nunca encuentras lo que buscas en Internet? UNA SOLA RESPUESTA: www.portalprofesional.com VISITANOS. No te vas a arrepentir! ICQ: 64451825 www.portalprofesional.com.ar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 9 13:33: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 NAA09551 for ; Sun, 9 Apr 2000 13:33:27 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA12202 for ietf-cat-wg-out720680; Sun, 9 Apr 2000 09:55:09 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA12197 for ; Sun, 9 Apr 2000 09:55:06 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id SAA85593; Sun, 9 Apr 2000 18:55:06 +0200 (CEST) (envelope-from assar) To: "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session References: From: Assar Westerlund Date: 09 Apr 2000 18:55:05 +0200 In-Reply-To: "Linn, John"'s message of "Tue, 4 Apr 2000 15:08:12 -0400" Message-ID: <5l66tr6wpi.fsf@assaris.sics.se> Lines: 17 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk "Linn, John" writes: > Updates since the last revision include integrated 3DES options, new > registered types, and various edits, some of which require discussion. > Cliff reported that the current 3DES description integrates all options in a > single parameterized discussion, but that it references currently expired > drafts and material must therefore be adapted from them. List discussion is > needed to resolve whether or not to use the key derivation variant; Cliff > reported that Microsoft and CyberSafe have tentatively agreed to accept key > derivation, though that some skepticism was observed about its value. I would think it a really bad idea having tow different kinds of 3DES in the spec. And since, as I'm lead to believe from the minutes, everybody agrees on using 3DES with key-derivation, I propose that we just keep that in the spec, of course letting the assignment of the etype to the old 3DES stay. Any comments? /assar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 9 20:29:25 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 UAA15299 for ; Sun, 9 Apr 2000 20:29:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA10982 for ietf-cat-wg-out720680; Sun, 9 Apr 2000 16:54:53 -0700 (PDT) Received: from dns2.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA10974 for ; Sun, 9 Apr 2000 16:54:50 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA07054; Sun, 9 Apr 2000 18:54:49 -0500 (CDT) Message-ID: <38F11877.A922E1AA@anl.gov> Date: Sun, 09 Apr 2000 18:55:35 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: "RL 'Bob' Morgan" , Jeffrey Altman , krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit With all the discussion this week on the case of the realm name, and how to add case sensitive names to DNS, I would like to ask what it would take to say realm names are case insensitive? I agree with Bob that lower case realm names are widely used, and can not be dismissed easily. (We have a lower case realm name.) As I understand it, the main problem comes from using the realm name as a salt where the case of the salt is significant, and the realm name is needed by preauth. But don't all preauths have the ability to return the correct salt in an error message if it was not correct on the first try? In any case, the only time the client needs to know the salt is when using a password to get a ticket, or to change a password. In these cases the user is talking to his local realm, and could even specify the case sensitive realm for the salt as part of the principal name as input to kinit or kpasswd. So in other words, the salt would not strictly be the realm name, but a case sensitive string derived from the case insensitive realm name. By default it would be determined by the principal name. Having case insensitive realm names, would simplify any DNS issues, and eliminate the proposals to add a DNS function to get the case of the realm. It should also address any problems of the realm in an ACL. I would also not expect there are two production realms which differ only by case. Does anyone know of any? Are there any realms with mixed case realm names? -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 02:09:37 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 CAA01663 for ; Mon, 10 Apr 2000 02:09:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id WAA26003 for ietf-cat-wg-out720680; Sun, 9 Apr 2000 22:37:03 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id WAA25991 for ; Sun, 9 Apr 2000 22:36:59 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id BAA07132; Mon, 10 Apr 2000 01:36:53 -0400 (EDT) To: deengert@anl.gov Cc: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <38F11877.A922E1AA@anl.gov> Mime-Version: 1.0 From: Ken Raeburn Date: 10 Apr 2000 01:36:50 -0400 In-Reply-To: "Douglas E. Engert"'s message of "Sun, 09 Apr 2000 18:55:35 -0500" Message-ID: Lines: 36 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > As I understand it, the main problem comes from using the realm > name as a salt where the case of the salt is significant, and the > realm name is needed by preauth. But don't all preauths have the > ability to return the correct salt in an error message if it was not > correct on the first try? In any case, the only time the client > needs to know the salt is when using a password to get a ticket, > or to change a password. In these cases the user is talking to > his local realm, and could even specify the case sensitive realm > for the salt as part of the principal name as input to kinit or > kpasswd. > > So in other words, the salt would not strictly be the realm name, > but a case sensitive string derived from the case insensitive realm name. > By default it would be determined by the principal name. Yes, I think that could probably work. Though unless we specify some case conversion as part of generating the salt for a given realm, we'll *always* have to return the salt info. > Having case insensitive realm names, would simplify any DNS issues, > and eliminate the proposals to add a DNS function to get the case of the > realm. It should also address any problems of the realm in an ACL. That's not the only instance in which the case matters. Currently, the non-realm part of the principal name is also case sensitive, and a realm name is used in the non-realm part of a ticket-granting ticket's service name. Unless we make the entire principal name case-insensitive, we still need to be able to determine the correct case. So, can we make principal names case-insensitive? Certainly email addresses are case-insensitive. But in other contexts, OS user names are often considered case sensitive. Are IANA-assigned service names considered case-insensitive? How else are principal names chosen in various deployments? -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 02:33: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 CAA02074 for ; Mon, 10 Apr 2000 02:33:56 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA27514 for ietf-cat-wg-out720680; Sun, 9 Apr 2000 23:04:05 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id XAA27509 for ; Sun, 9 Apr 2000 23:04:03 -0700 (PDT) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id XAA22771; Sun, 9 Apr 2000 23:04:02 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id XAA04216; Sun, 9 Apr 2000 23:04:01 -0700 (PDT) Date: Sun, 9 Apr 2000 23:04:01 -0700 (PDT) Message-Id: <200004100604.XAA04216@cayman-islands.isi.edu> From: Clifford Neuman To: raeburn@mit.edu CC: deengert@anl.gov, ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu In-reply-to: (message from Ken Raeburn on 10 Apr 2000 01:36:50 -0400) Subject: Re: comments on kerberos-revisions-05.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Before this discussion gets out of hand, let me make it clear that changing names in Kerberos to be case insensitive is a mistake. The reasons for case sensitivity in principal and realm names were described in my message of April 3rd, which I repeat below for easy reference. It is acceptable to provide external means to appropriately choose a default case for particular principals, and to map case when entered by the user at login. Such changes could be implementation specific and would not involve a change to the protocol, nor the interpretation of the protocol. Clifford Neuman Date: Mon, 3 Apr 2000 16:20:42 -0700 (PDT) From: Clifford Neuman To: rlmorgan@washington.edu CC: hartmans@mit.edu, ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt Using upper case DNS realm names is not a change, but instead the way things have been all along. Early on it was decided that names in Kerberos needed to be case sensitive because we did not have control over the environments within which Kerberos would be used. If names were not case sensitive, then use of Kerberos in an environment that had case sensitive names would be difficult. However, case sensitive names in Kerberos were easily used in environments where names were not case sensitive, simply by adopting the convention on which case would be used in the Kerberos encoding. Choosing case preservation, but insensitive matching was not an acceptable solution, because in such environments where case sensitivity mattered, the consequence for the security of the system could be significant. As to whether the convention chosen was for DNS realm names to be upper case or lower case, that was decided a LONG time ago. The chose was upper case - I do not recall the reason offhand - but unfortunately it wasn't a significant reason and it might have even been arbitrary. Now, their might have been a failure to communicate this choice, but it was the choice and it is not an issue that can be revisited at this time. Though it doesn't constitute communications of the convention, all DNS based realm name examples in RFC1510 were upper case. That would strongly argue against an imposition of lower case as the convention. 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 Apr 10 08:17: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 IAA07123 for ; Mon, 10 Apr 2000 08:17:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id EAA06481 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 04:33:19 -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 EAA06475 for ; Mon, 10 Apr 2000 04:33:17 -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 HAA05341; Mon, 10 Apr 2000 07:33:13 -0400 (EDT) Message-Id: <200004101133.HAA05341@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-cross-06.txt Date: Mon, 10 Apr 2000 07:33:12 -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 : Public Key Cryptography for Cross-Realm Authentication in Kerberos Author(s) : M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky, B. Sommerfeld Filename : draft-ietf-cat-kerberos-pk-cross-06.txt Pages : 5 Date : 06-Apr-00 This document defines extensions to the Kerberos protocol specification [1] to provide a method for using public key cryptography to enable cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-cross-06.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-kerberos-pk-cross-06.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-kerberos-pk-cross-06.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: <20000406142411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-cross-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000406142411.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 Mon Apr 10 11:45: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 LAA19155 for ; Mon, 10 Apr 2000 11:45:44 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA08561 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 08:05:58 -0700 (PDT) Received: from dns2.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA08556 for ; Mon, 10 Apr 2000 08:05:56 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA26308; Mon, 10 Apr 2000 10:05:41 -0500 (CDT) Message-ID: <38F1EDF4.6C30C424@anl.gov> Date: Mon, 10 Apr 2000 10:06:28 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Clifford Neuman CC: raeburn@mit.edu, ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <200004100604.XAA04216@cayman-islands.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Clifford Neuman wrote: > > Before this discussion gets out of hand, let me make it clear that > changing names in Kerberos to be case insensitive is a mistake. The > reasons for case sensitivity in principal and realm names were > described in my message of April 3rd, which I repeat below for easy > reference. > I was bringing this up, as we seam to be bending over backwards, with trying to use a case insensitive service, DNS, when it is still not clear to me why Kerberos has to have case sensitive names, and adding more DNS lookups to get the case of the realm may be counter productive. I have some more questions about that below. > It is acceptable to provide external means to appropriately choose a > default case for particular principals, and to map case when entered > by the user at login. Such changes could be implementation specific > and would not involve a change to the protocol, nor the interpretation > of the protocol. I would argue that changing the case at login, is stretching it, to abide by the "convention". The user my have wanted the lower case name. As a convenence you may determing that the closest match to an existing realm is uppercase and change it for the user, but you should first check if the user typed a valid case sensitive realm name. (The only place we ever found this to be a problem in the MIT code was in an older Windows cns.rc where we removed the ES_UPPERCASE flag of the edit box dialog box.) > > Clifford Neuman > > Date: Mon, 3 Apr 2000 16:20:42 -0700 (PDT) > From: Clifford Neuman > To: rlmorgan@washington.edu > CC: hartmans@mit.edu, ietf-cat-wg@lists.Stanford.EDU > Subject: Re: comments on kerberos-revisions-05.txt > > Using upper case DNS realm names is not a change, but instead the way > things have been all along. Early on it was decided that names in > Kerberos needed to be case sensitive because we did not have control > over the environments within which Kerberos would be used. > > If names were not case sensitive, then use of Kerberos in an > environment that had case sensitive names would be difficult. But this is the same situation DNS and email names have, i.e. they are case insensitive and they don't seam to have these problems. > However, case sensitive names in Kerberos were easily used in > environments where names were not case sensitive, simply by adopting > the convention on which case would be used in the Kerberos encoding. > But it was a "convention" and names are still case sensitive, so therefore you could use lower or mixed case realm names and still be with in the specifications. We now have a large community using lower case realm names. > Choosing case preservation, but insensitive matching was not an > acceptable solution, because in such environments where case > sensitivity mattered, the consequence for the security of the system > could be significant. Could you give some example here? What if we are only talking about the realm name being case insensitive. > > As to whether the convention chosen was for DNS realm names to be > upper case or lower case, that was decided a LONG time ago. The chose > was upper case - I do not recall the reason offhand - but > unfortunately it wasn't a significant reason and it might have even > been arbitrary. > > Now, their might have been a failure to communicate this choice, but > it was the choice and it is not an issue that can be revisited at this > time. Though it doesn't constitute communications of the convention, > all DNS based realm name examples in RFC1510 were upper case. That > would strongly argue against an imposition of lower case as the > convention. > I am just asking the question. It there some time when it might be revisited? Is there any thing we could do now to make it easiter to reviit this in the future? Users have become accustomed to using lower case with any network names, like host, e-mail and URLs, which are case insensitive. I would also not expect there to be two production realms where the names differed by only case. So if the specifications were changed, this should not be a problem. There could be others, that is why I was just asking. > Clifford Neuman -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 12:06: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 MAA20908 for ; Mon, 10 Apr 2000 12:06:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA09645 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 08:29:18 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA09640 for ; Mon, 10 Apr 2000 08:29:16 -0700 (PDT) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA14943; Mon, 10 Apr 2000 08:25:53 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id IAA04503; Mon, 10 Apr 2000 08:25:52 -0700 (PDT) Date: Mon, 10 Apr 2000 08:25:52 -0700 (PDT) Message-Id: <200004101525.IAA04503@cayman-islands.isi.edu> From: Clifford Neuman To: deengert@anl.gov CC: raeburn@mit.edu, ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu In-reply-to: <38F1EDF4.6C30C424@anl.gov> (deengert@anl.gov) Subject: Re: comments on kerberos-revisions-05.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Mon, 10 Apr 2000 10:06:28 -0500 From: "Douglas E. Engert" Clifford Neuman wrote: > > Before this discussion gets out of hand, let me make it clear that > changing names in Kerberos to be case insensitive is a mistake. The > reasons for case sensitivity in principal and realm names were > described in my message of April 3rd, which I repeat below for easy > reference. > I was bringing this up, as we seam to be bending over backwards, with trying to use a case insensitive service, DNS, when it is still not clear to me why Kerberos has to have case sensitive names, and adding more DNS lookups to get the case of the realm may be counter productive. I have some more questions about that below. > It is acceptable to provide external means to appropriately choose a > default case for particular principals, and to map case when entered > by the user at login. Such changes could be implementation specific > and would not involve a change to the protocol, nor the interpretation > of the protocol. I would argue that changing the case at login, is stretching it, to abide by the "convention". The user my have wanted the lower case name. As a convenence you may determing that the closest match to an existing realm is uppercase and change it for the user, but you should first check if the user typed a valid case sensitive realm name. (The only place we ever found this to be a problem in the MIT code was in an older Windows cns.rc where we removed the ES_UPPERCASE flag of the edit box dialog box.) I am not arguing that realm names must be upper case, simply that the matching of realm names to determine equivalence of a principal (e.g. when checking an access control list) must be case sensitive. I still feel that the convention should remain as upper case realm names when the realm name is based on a domain name. However, mapping case at login to the "best" match seems a completely reasonable thing to do. The only other place where mapping to other than the conventional case might occur would be when looking up the realm of a server principal. So long as you have a secure means to do that mapping, I don't see a problem. This mapping operation is the same one needed when the hierarchy of domain names does not precisely match the hierarchy of realm names - and unfortunately there are weaknesses in the some of the ways this mapping is done presently. > If names were not case sensitive, then use of Kerberos in an > environment that had case sensitive names would be difficult. But this is the same situation DNS and email names have, i.e. they are case insensitive and they don't seam to have these problems. DNS was able to define it's own name space (in fact, it did define a new name space, and all the existing hosts on the Internet had to change their names). As to e-mail names, you are welcome to argue that issue with Jerry Saltzer. > Choosing case preservation, but insensitive matching was not an > acceptable solution, because in such environments where case > sensitivity mattered, the consequence for the security of the system > could be significant. Could you give some example here? What if we are only talking about the realm name being case insensitive. If an access control list were set up and entries matched in a case insensitive manner when a realm name was generated by systems with case sensitive names, and where two realms shared the same name except for case differences, then access would be granted even though the principal was not the one intended. > > As to whether the convention chosen was for DNS realm names to be > upper case or lower case, that was decided a LONG time ago. The chose > was upper case - I do not recall the reason offhand - but > unfortunately it wasn't a significant reason and it might have even > been arbitrary. > > Now, their might have been a failure to communicate this choice, but > it was the choice and it is not an issue that can be revisited at this > time. I am just asking the question. Is there some time when it might be revisited? Is there any thing we could do now to make it easier to revisit this in the future? Users have become accustomed to using lower case with any network names, like host, e-mail and URLs, which are case insensitive. I don't think that revisiting the specific convention makes sense. However, as long as the mechanisms to securely map to the appropriate realm name exists when looking up server principals, as well as when initially logging in to the system, then the convention becomes less relevant. Some of the name referrals proposals out of Microsoft would in fact provide such mapping in a secure manner (i.e. the KDC can refer you to the correct realm regardless of the case). 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 Apr 10 13:35: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 NAA26801 for ; Mon, 10 Apr 2000 13:35:03 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA18423 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 09:54:27 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA18411 for ; Mon, 10 Apr 2000 09:54:23 -0700 (PDT) Received: (qmail 27047 invoked from network); 10 Apr 2000 16:53:52 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 10 Apr 2000 16:53:52 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Mon, 10 Apr 2000 09:50:05 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id <2MKX7HKY>; Mon, 10 Apr 2000 09:53:16 -0700 Message-ID: <80A473F584BED311810D0050DA289BD4142241@corporate.cybersafe.com> From: Tony Andrea To: "'Assar Westerlund'" , "'CAT-WG List'" Subject: RE: Draft minutes, Adelaide CAT session Date: Mon, 10 Apr 2000 09:53:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA30D.440CFBD0" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA30D.440CFBD0 Content-Type: text/plain; charset="iso-8859-1" cybersafe has not agreed to do key derivation. there is little to no advantage in doing so. microsoft and cybersafe have tentatively agreed to implement des3-cbc-sha1 (etype 7), with no key derivation. cybersafe also supports des3-cbc-md5 (etype 5). later, tony. > -----Original Message----- > From: Assar Westerlund [mailto:assar@sics.se] > Sent: Sunday, April 09, 2000 9:55 AM > To: 'CAT-WG List' > Subject: Re: Draft minutes, Adelaide CAT session > > > "Linn, John" writes: > > Updates since the last revision include integrated 3DES options, new > > registered types, and various edits, some of which require > discussion. > > Cliff reported that the current 3DES description integrates > all options in a > > single parameterized discussion, but that it references > currently expired > > drafts and material must therefore be adapted from them. > List discussion is > > needed to resolve whether or not to use the key derivation > variant; Cliff > > reported that Microsoft and CyberSafe have tentatively > agreed to accept key > > derivation, though that some skepticism was observed about > its value. > > I would think it a really bad idea having tow different kinds of 3DES > in the spec. And since, as I'm lead to believe from the minutes, > everybody agrees on using 3DES with key-derivation, I propose that we > just keep that in the spec, of course letting the assignment of the > etype to the old 3DES stay. Any comments? > > /assar > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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_01BFA30D.440CFBD0 Content-Type: text/html; charset="iso-8859-1" RE: Draft minutes, Adelaide CAT session

cybersafe has not agreed to do key derivation. there is
little to no advantage in doing so.  microsoft and cybersafe
have tentatively agreed to implement des3-cbc-sha1 (etype 7),
with no key derivation.  cybersafe also supports des3-cbc-md5
(etype 5). 

later,
tony.

> -----Original Message-----
> From: Assar Westerlund [mailto:assar@sics.se]
> Sent: Sunday, April 09, 2000 9:55 AM
> To: 'CAT-WG List'
> Subject: Re: Draft minutes, Adelaide CAT session
>
>
> "Linn, John" <jlinn@rsasecurity.com> writes:
> > Updates since the last revision include integrated 3DES options, new
> > registered types, and various edits, some of which require
> discussion.
> > Cliff reported that the current 3DES description integrates
> all options in a
> > single parameterized discussion, but that it references
> currently expired
> > drafts and material must therefore be adapted from them. 
> List discussion is
> > needed to resolve whether or not to use the key derivation
> variant; Cliff
> > reported that Microsoft and CyberSafe have tentatively
> agreed to accept key
> > derivation, though that some skepticism was observed about
> its value.
>
> I would think it a really bad idea having tow different kinds of 3DES
> in the spec.  And since, as I'm lead to believe from the minutes,
> everybody agrees on using 3DES with key-derivation, I propose that we
> just keep that in the spec, of course letting the assignment of the
> etype to the old 3DES stay.  Any comments?
>
> /assar
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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_01BFA30D.440CFBD0-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 15:34:38 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 PAA01275 for ; Mon, 10 Apr 2000 15:34:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA29834 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 12:00:35 -0700 (PDT) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA29826 for ; Mon, 10 Apr 2000 12:00:31 -0700 (PDT) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id PAA14136; Mon, 10 Apr 2000 15:00:29 -0400 Date: Mon, 10 Apr 2000 15:00:29 -0400 Message-Id: <200004101900.PAA14136@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Tony Andrea CC: "'Assar Westerlund'" , "'CAT-WG List'" In-reply-to: Tony Andrea's message of Mon, 10 Apr 2000 09:53:15 -0700, <80A473F584BED311810D0050DA289BD4142241@corporate.cybersafe.com> Subject: Re: Draft minutes, Adelaide CAT session Phone: (781) 391-3464 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Tony Andrea Date: Mon, 10 Apr 2000 09:53:15 -0700 cybersafe has not agreed to do key derivation. there is little to no advantage in doing so. microsoft and cybersafe have tentatively agreed to implement des3-cbc-sha1 (etype 7), with no key derivation. cybersafe also supports des3-cbc-md5 (etype 5). That's interesting; that's not what Cliff Neumann reported at the CAT working group meeting in Adelaide, and given that he's a Chief Scientist at Cybersafe, I thought he was speaking authoratatively. - 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 Mon Apr 10 18:28: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 SAA05880 for ; Mon, 10 Apr 2000 18:28:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA11949 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 14:48:32 -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 OAA11944 for ; Mon, 10 Apr 2000 14:48:29 -0700 (PDT) Received: (qmail 27183 invoked by uid 50); 10 Apr 2000 21:48:29 -0000 To: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <38F11877.A922E1AA@anl.gov> In-Reply-To: Ken Raeburn's message of "10 Apr 2000 01:36:50 -0400" From: Russ Allbery Organization: The Eyrie Date: 10 Apr 2000 14:48:28 -0700 Message-ID: Lines: 18 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 Raeburn writes: > So, can we make principal names case-insensitive? Certainly email > addresses are case-insensitive. But in other contexts, OS user names > are often considered case sensitive. Are IANA-assigned service names > considered case-insensitive? How else are principal names chosen in > various deployments? E-mail addresses are not case-insensitive on the LHS except for the special case of "postmaster". Local systems are permitted to treat them as such, and most of the major MDAs do so, but RFC 822 is quite explicit about the fact that the LHS is case-sensitive and user@example.com and User@example.com may be completely different mailboxes. I do know that some people use this, although not very many. -- 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 Mon Apr 10 18:57: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 SAA06266 for ; Mon, 10 Apr 2000 18:57:26 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA13889 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 15:24:01 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA13876 for ; Mon, 10 Apr 2000 15:23:57 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03766; Mon, 10 Apr 2000 15:23:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA20142; Mon, 10 Apr 2000 15:23:52 -0700 (PDT) Received: from teal (awe8-149.Central.Sun.COM [129.147.8.149]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3AMNow802066; Mon, 10 Apr 2000 15:23:50 -0700 (PDT) Date: Mon, 10 Apr 2000 15:27:12 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: comments on kerberos-revisions-05.txt To: Russ Allbery Cc: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Ken Raeburn writes: > > > So, can we make principal names case-insensitive? Certainly email > > addresses are case-insensitive. But in other contexts, OS user names > > are often considered case sensitive. Are IANA-assigned service names > > considered case-insensitive? How else are principal names chosen in > > various deployments? > > E-mail addresses are not case-insensitive on the LHS except for the > special case of "postmaster". Local systems are permitted to treat them > as such, and most of the major MDAs do so, but RFC 822 is quite explicit > about the fact that the LHS is case-sensitive and user@example.com and > User@example.com may be completely different mailboxes. > > I do know that some people use this, although not very many. Why can't the parts of the principal name that refer neither to a realm nor a host or sub-domain of realm be case sensitive, and the other parts case insensitive. E.g. joe@widget.com JOE@widget.com are distinct, but joe@WIDGET.COM joe@widget.com are not. For instance specific examples: host/server.widget.com@widget.com HOST/server.widget.com@widget.com are distinct, but host/SERVER.widget.com@widget.com host/server.widget.com@widget.com are not. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 19:50: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 TAA07071 for ; Mon, 10 Apr 2000 19:50:44 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id QAA17356 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 16:12:32 -0700 (PDT) Received: from blubb.pdc.kth.se (asynk50.modempool.kth.se [130.237.10.50]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA17351 for ; Mon, 10 Apr 2000 16:12:27 -0700 (PDT) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12enLY-00006J-00; Tue, 11 Apr 2000 01:11:56 +0200 To: Mike Eisler Cc: Russ Allbery , ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: From: joda@pdc.kth.se (Johan Danielsson) Date: 11 Apr 2000 01:11:52 +0200 In-Reply-To: Mike Eisler's message of "Mon, 10 Apr 2000 15:27:12 -0700 (PDT)" Message-ID: Lines: 24 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Mike Eisler writes: > Why can't the parts of the principal name that refer neither to a > realm nor a host or sub-domain of realm be case sensitive, and the > other parts case insensitive. Why bother? Having some parts case sensitive, and some insensitive is just going to cause a whole lot of confusion. Realms are *not* mail domains, and principals are *not* email addresses. The fact that you in some, perhaps even most, cases can convert from one to the other by changing case is irrelevant. I think that it's perfectly ok to have some piece of user interface that converts from a mail address to a principal, and that the KDC might assist in this conversion. Infact this is exactly what the `local realm' is for -- so you can enter your username (which is also not a principal), and have the system expand it into a principal. Please don't try to make it mandatory that every part of the already complex protocol should be able to handle arbitrarly composed principals that might look like some address. /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 20:46:29 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 UAA07737 for ; Mon, 10 Apr 2000 20:46:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA22385 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 17:12:55 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA22376 for ; Mon, 10 Apr 2000 17:12:52 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id CAA91565; Tue, 11 Apr 2000 02:12:48 +0200 (CEST) (envelope-from assar) To: Tony Andrea Cc: "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session References: <80A473F584BED311810D0050DA289BD4142241@corporate.cybersafe.com> From: Assar Westerlund Date: 11 Apr 2000 02:12:48 +0200 In-Reply-To: Tony Andrea's message of "Mon, 10 Apr 2000 09:53:15 -0700" Message-ID: <5lln2lh4vz.fsf@assaris.sics.se> Lines: 18 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Tony Andrea writes: > cybersafe has not agreed to do key derivation. Ok, sorry if I was implying something that was not true. I got that impression from reading the minutes (I wasn't in Adelaide). > microsoft and cybersafe have tentatively agreed to implement > des3-cbc-sha1 (etype 7), with no key derivation. cybersafe also > supports des3-cbc-md5 (etype 5). I really think it's un-optimal there being one 3DES variant used by MIT-Heimdal and another by Cybersafe-Microsoft. Don't you? How can we try to resolve this? You said earlier that there was `little to no advantage'. Is there any disadvantage to doing so? Other than a little bit of more code. /assar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 21:50: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 VAA09470 for ; Mon, 10 Apr 2000 21:50:51 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA26243 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 18:07:10 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA26238 for ; Mon, 10 Apr 2000 18:07:08 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id VAA07552; Mon, 10 Apr 2000 21:07:01 -0400 (EDT) To: Russ Allbery Cc: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <38F11877.A922E1AA@anl.gov> Mime-Version: 1.0 From: Ken Raeburn Date: 10 Apr 2000 21:07:01 -0400 In-Reply-To: Russ Allbery's message of "10 Apr 2000 14:48:28 -0700" Message-ID: Lines: 12 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Russ Allbery writes: > E-mail addresses are not case-insensitive on the LHS except for the > special case of "postmaster". Local systems are permitted to treat them > as such, and most of the major MDAs do so, but RFC 822 is quite explicit > about the fact that the LHS is case-sensitive and user@example.com and > User@example.com may be completely different mailboxes. Well, you learn something new every day... :-) Certainly I expect most people's experiences to suggest to them that they are "always" case-insensitive though. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 10 22:24: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 WAA09945 for ; Mon, 10 Apr 2000 22:24:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA28838 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 18:47:34 -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 SAA28833 for ; Mon, 10 Apr 2000 18:47:32 -0700 (PDT) Received: from bcn (ras01.isi.edu [128.9.176.101]) by venera.isi.edu (8.8.7/8.8.6) with SMTP id SAA11784; Mon, 10 Apr 2000 18:47:16 -0700 (PDT) From: "Clifford Neuman" To: "Assar Westerlund" , "'CAT-WG List'" Subject: RE: Draft minutes, Adelaide CAT session Date: Mon, 10 Apr 2000 18:46:55 -0700 Message-ID: <000501bfa357$d0e7d600$3c3ffea9@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: <5l66tr6wpi.fsf@assaris.sics.se> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. I would think it a really bad idea having tow different kinds of 3DES in the spec. And since, as I'm lead to believe from the minutes, everybody agrees on using 3DES with key-derivation, I propose that we just keep that in the spec, of course letting the assignment of the etype to the old 3DES stay. Any comments? Then perhaps you would like to reopen the debate about whether key derivation should be the must implement version. In the discussions I reported, the general feeling was that there was not significant benefit to key dervation, but there was a willingness to go along with it to put the discussion behind us and to move forward. It was not an agreement that the kd version was the better choice. If you are proposing now that the non kd version shouldn't even be included in the spec, then you will find them more likely to push the issue, and less willing to go along with the compromise. 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 Apr 10 22:36: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 WAA11022 for ; Mon, 10 Apr 2000 22:36:06 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA29886 for ietf-cat-wg-out720680; Mon, 10 Apr 2000 19:03:23 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id TAA29873 for ; Mon, 10 Apr 2000 19:03:18 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id EAA38812; Tue, 11 Apr 2000 04:03:15 +0200 (CEST) (envelope-from assar) To: "Clifford Neuman" Cc: "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session References: <000501bfa357$d0e7d600$3c3ffea9@bcn.isi.edu> From: Assar Westerlund Date: 11 Apr 2000 04:03:15 +0200 In-Reply-To: "Clifford Neuman"'s message of "Mon, 10 Apr 2000 18:46:55 -0700" Message-ID: <5l4s99z95o.fsf@assaris.sics.se> Lines: 37 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk "Clifford Neuman" writes: > Then perhaps you would like to reopen the debate about whether key > derivation should be the must implement version. That was what I thought I had just done. :-) > In the discussions I reported, the general feeling was that there > was not significant benefit to key dervation, but there was a > willingness to go along with it to put the discussion behind us and > to move forward. I think, as I have said, that the most important thing is to have just one mandatory-to-implement 3DES variant and I would really like it to be implemented (and interoperable) in all the implementations. > It was not an agreement that the kd version was the better choice. ok > If you are proposing now that the non kd version shouldn't even be > included in the spec, then you will find them more likely to push > the issue, and less willing to go along with the compromise. As I understood it from reading the minutes and the mailing-list, Cybersafe and Microsoft were talking about implementing 3DES, in other words, that they haven't done so. In that case, I frankly don't see the point of implementing two different mechanisms. If the case is that it's already implemented, then I think it should be in the specification, regardless of which mechanism turns out to be the mandatory. So what I'm after here is consensus on the mandatory 3DES mechanism. What are the arguments for and against the kd-variant here? It's some more code, but it gives compatibility with the MIT and Heimdal implementations. /assar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 05:27: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 FAA26791 for ; Tue, 11 Apr 2000 05:27:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id BAA19325 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 01:47:41 -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 BAA19320 for ; Tue, 11 Apr 2000 01:47:39 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA26492; Tue, 11 Apr 00 04:47:35 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id KAA20908; Tue, 11 Apr 2000 10:44:43 +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 KAA00524; Tue, 11 Apr 2000 10:44:22 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id KAA02791; Tue, 11 Apr 2000 10:44:22 +0200 (METDST) From: Martin Rex Message-Id: <200004110844.KAA02791@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: mre@Eng.Sun.COM Date: Tue, 11 Apr 2000 10:44:21 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 10, 0 03:27:12 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 Mike Eisler wrote: > > Why can't the parts of the principal name that refer neither to a realm nor a > host or sub-domain of realm be case sensitive, and the other parts case > insensitive. E.g. > > joe@widget.com JOE@widget.com > > are distinct, but > > joe@WIDGET.COM joe@widget.com > > are not. For instance specific examples: > > host/server.widget.com@widget.com HOST/server.widget.com@widget.com > > are distinct, but > > host/SERVER.widget.com@widget.com host/server.widget.com@widget.com > > are not. Beware! MIT Kerberos will distinguish the latter two names -- they're not equivalent at all. Don't confuse the hostname canonicalization that is applied to hostbased service names (i.e. host@server.widget.com) with the case sensitivity of Kerberos principal names. You can add the principal "host/SERVER.widget.com", however it will probably never get used by the majority of native Kerberos applications that specify hostbased service names as target names. When using a Kerberos principal name as target, no transformations are applied to the hostname that is part of the name, AFAIK. -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 Apr 11 06:09:53 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 GAA27080 for ; Tue, 11 Apr 2000 06:09:52 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id CAA20272 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 02:35:06 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id CAA20266 for ; Tue, 11 Apr 2000 02:35:03 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06970; Tue, 11 Apr 2000 02:35:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id CAA25693; Tue, 11 Apr 2000 02:35:00 -0700 (PDT) Received: from teal (awe8-110.Central.Sun.COM [129.147.8.110]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3B9Z1w860948; Tue, 11 Apr 2000 02:35:01 -0700 (PDT) Date: Tue, 11 Apr 2000 02:38:21 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: comments on kerberos-revisions-05.txt To: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu In-Reply-To: "Your message with ID" <200004110844.KAA02791@hw1464.wdf.sap-ag.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Matin Rex writes: > > Why can't the parts of the principal name that refer neither to a realm nor a > > host or sub-domain of realm be case sensitive, and the other parts case > > insensitive. E.g. > > > > joe@widget.com JOE@widget.com > > > > are distinct, but > > > > joe@WIDGET.COM joe@widget.com > > > > are not. For instance specific examples: > > > > host/server.widget.com@widget.com HOST/server.widget.com@widget.com > > > > are distinct, but > > > > host/SERVER.widget.com@widget.com host/server.widget.com@widget.com > > > > are not. > > Beware! MIT Kerberos will distinguish the latter two names -- they're Believe me, I know. > not equivalent at all. Don't confuse the hostname canonicalization > that is applied to hostbased service names (i.e. host@server.widget.com) > with the case sensitivity of Kerberos principal names. You can add > the principal "host/SERVER.widget.com", however it will probably never > get used by the majority of native Kerberos applications that specify > hostbased service names as target names. When using a Kerberos Yes, that's what I thought too. > principal name as target, no transformations are applied to the > hostname that is part of the name, AFAIK. Which I think is broken. Consider a real world application, like NFS. The NFS client does: mount -o sec=krb5 server:/export /mnt This NFS client uses GSS-API, and so needs to establish a GSS-API security context between itself and the target, "nfs@server" via the Kerberos V5 mechanism. "nfs@server" is merely the canonical RFC 2078 name. The RFC 1964 name is "nfs/server.@", which the initiator has to expand "server" to in the following steps: 1. prefix "nfs/" 2. append the fully qualified domain name (FQDN) of "server" 3. append the "@" as defined by the rules in krb5.conf. Depending on how resolv.conf is configured, the FQDN of "server" can take on different forms of case. The work-around is in step 2 to always convert of FQDN of "server" to lower case. However, if that's what one must do (and both RFC 1510 and draft-ietf-cat-kerberos-revisions-05.txt say that's what one must do, see section 7.2.1), that seems rather silly. Kerberos V5 is relying on a case insensitive, case preserving directory called DNS; Kerberos V5 should simply follow the conventions of DNS rather make up its own which lead to implementation bugs in step 2. This is what my suggestion And by the way, telling the user that the he MUST when invoking the mount command, specify a lower case, FQDN for "server" is a non-starter. Johan Danielsson writes: > > Why can't the parts of the principal name that refer neither to a realm nor a > > host or sub-domain of realm be case sensitive, and the other parts case > > insensitive. > Why bother? Having some parts case sensitive, and some insensitive is Because as is clear from the discussion, some people want to preserve the case of realm names, host names, and domain names, and some people want one or more of these names to be case insensitive. > just going to cause a whole lot of confusion. As opposed to what current implementation practice is? My approach eliminates all the confusion by adhering to the case preserving, case insensitive semantics of the underlying directory, while still adhering to the case sensitive semantics of RFC 822. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 09:34: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 JAA03435 for ; Tue, 11 Apr 2000 09:34:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA23543 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 05:48:10 -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 FAA23538 for ; Tue, 11 Apr 2000 05:48:08 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 11 Apr 2000 12:44:18 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 IAA11162; Tue, 11 Apr 2000 08:44:57 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <2W9T36K8>; Tue, 11 Apr 2000 08:48:03 -0400 Message-ID: From: "Linn, John" To: "'minutes@ietf.org'" Cc: "'CAT-WG List'" Subject: Minutes, CAT-WG Adelaide meeting Date: Tue, 11 Apr 2000 08:48:03 -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 [Note to list subscribers: this version is slightly revised from the 4 April draft, in response to posted comments re the Kerberos GSS mechanism discussion.] Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF Reported by John Linn, RSA Laboratories. Thanks to Cliff Neuman and Ken Hornstein for providing their notes and slides, which were used as inputs to preparation of these minutes. GENERAL AND ADMINISTRATIVE DISCUSSION The CAT WG met for one session in Adelaide, with 88 attendees. John Linn opened the meeting with a general status overview, handing the floor to Jeff Schiller (MIT, Security AD) to present an organizational update. Jeff noted that the IETF today generally prefers tightly task-focused groups and that CAT's charter has been iteratively evolving for some time. He further observed that CAT's original focus was on the common GSS-API interface, rather than specifically on the Kerberos technology to which currently active standards-track CAT Internet-Drafts relate. It has been decided that the general CAT WG will go dormant, but with the mailing list to remain available as a forum to discuss progression of existing non-Kerberos CAT documents. Kerberos documents are to be transitioned to a new Kerberos WG, with the intent that its charter be established before the next (Pittsburgh) IETF and that an initial WG meeting without prior BOF session will take place there. Doug Engert (Argonne) has agreed to chair the group and will be doing so. Kerberos-related drafts that are ready for imminent Last-Call, in advance of establishment of the Kerberos WG, can still go to CAT. KERBEROS-REVISIONS AND PKINIT Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new Internet-Draft version was recently issued. Significant remaining issues include: decision on the mandatory variants of 3DES, ticket extensions, and integration of the referrals draft. Additionally, some smaller and editorial issues must also be addressed, and a change summary relative to RFC-1510 must be prepared. Updates since the last revision include integrated 3DES options, new registered types, and various edits, some of which require discussion. Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. Cliff also reported that some coordination is pending with Microsoft on PAC usage. List discussion is required on the ticket extensions field, included in the current draft; Cliff intends to send a message to the list initiating debate on the benefits and drawbacks of its retention. Further discussion topics had been introduced on the list: whether policies on adding additional addresses to tickets should be specified, clarification on case sensitivity in names. During the Adelaide IETF week, Cliff's intent was to perform initial wordsmithing and to initiate the 3DES and ticket extensions discussions. He also anticipates referrals text pending from John Brezak (Microsoft), which will require further list discussion. Once at least the two major issues are resolved, WG Last-Call will be requested on Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John Linn suggested that an extended WG Last-Call period would be appropriate. PKINIT is believed to have come to consensus among active participants, and to be ready for a parallel last call with Kerberos-Revisions. Recent changes include: name encoding, application of name constraints, and SignedData and EnvelopedData structure definitions. Regarding name encoding, the section on translation between X.500 names and Kerberos structures has been changed and expanded to specify the translation between general string and UTF8. A new structure corresponding to Kerberos PrincipalName, but with general string replaced by UTF8String, was defined to enable the use of UTF8 in the additional name field when Kerberos principal names are embedded in certificates. Rules were added for checking of a Kerberos PrincipalName against certificate chains which contain name constraints. The SignedData and EnvelopedData structure explanations have been reformatted and slightly edited for clarity. The old PKCS#7 data OID has been replaced by a pkdata OID under the Kerberos-PKINIT arc. KERBEROS DNS-LOCATE Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document (-02 draft). He reported that dns-locate is currently implemented in two different independent Kerberos implementations, is widely used, and appears to work well in simple usage. There had been significant contention on the CAT list about security concerns with host-to-realm mapping. Ken observed that the vulnerability exists only between realms which share a cross-realm relationship, and that it can exist in many common Kerberos implementations even without the use of DNS-based host-realm mapping; use of a different naming approach would be required to resolve this. Ken believes that the facility is useful and should remain within the draft as a feature that could be activated selectively. Following the discussion which has taken place, he also believes that more clarification is needed somewhere about the relation between Kerberos and DNS, and may consider a separate informational document for this purpose. GAA Cliff Neuman presented an update on the GAA drafts. It was noted that any request for progression of these documents would target Experimental status and would follow integration results with several applications. Recent GAA work has focused on implementation and changes needed for integration with particular applications. The new drafts define new generic conditions, which generate audit records when policies containing those conditions are encountered. Also, optional parameters are now translated to appropriate types by condition evaluation functions rather than being described by the separate gaa_options structure. The new C bindings have focused on a more "object-oriented" approach, inspired by the style of Hudson and Young's SSLeay, and with three classes of functions. The draft now uses a generic gaa_stack object (with implementation-specific structure) for representation of ordered lists rather than using a separate ordered list for each type of data. OTHER TOPICS Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated that Microsoft and others are interested in squeezing 3DES into RFC-1964 rather than doing a general cryptosystem-independent scheme, and asked the attendees whether they wished to voice any objections to hacking into RFC-1964 rather than pursuing a wholly new approach. (Subsequent discussion observed that work on a near-term 3DES approach with RFC-1964 need not be mutually exclusive with parallel effort on a new approach.) It was noted that interoperability issues might arise if a single OID were used. Ted Ts'o (VA Linux) would like to see an analysis of what the failure cases and modes would be. Tom plans to circulate a more detailed proposal to the list. A new version of PKCROSS is planned, but is currently blocked pending resolution on the Kerberos-Revisions ticket extensions question. Ted Ts'o asked the meeting about continued interest in specification of a GSS adjunct interface for interactive credential acquisition, such as that which had been documented in his GSS Conversation Interface draft. Approximately three attendees indicated interest. To this point, GSS' scope has excluded asynchronous callbacks to applications and their associated users, partly for reasons of OS independence. Sam Hartman (FundsXpress) observed that SASL is an important client of GSS, and that it already has its own facilities for asynchronous callbacks to applications; given these facts, he considered that it would be inappropriate to define an incompatible facility at the GSS level. Ted indicated that he was not aware of API-level convergence among SASL providers, but others commented that such convergence was progressing. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 11:14: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 LAA08378 for ; Tue, 11 Apr 2000 11:14:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA25519 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 07:37: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 HAA25511 for ; Tue, 11 Apr 2000 07:37:19 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA01070; Tue, 11 Apr 00 10:39:09 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id QAA09984; Tue, 11 Apr 2000 16:34:28 +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 QAA16992; Tue, 11 Apr 2000 16:33:58 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id QAA04590; Tue, 11 Apr 2000 16:33:58 +0200 (METDST) From: Martin Rex Message-Id: <200004111433.QAA04590@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: mre@Eng.Sun.COM Date: Tue, 11 Apr 2000 16:33:57 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 11, 0 02:38:21 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 Hi Mike, Mike Eisler wrote: > > > principal name as target, no transformations are applied to the > > hostname that is part of the name, AFAIK. > > Which I think is broken. Consider a real world application, like > NFS. The NFS client does: > > mount -o sec=krb5 server:/export /mnt > > This NFS client uses GSS-API, and so needs to establish a GSS-API security > context between itself and the target, "nfs@server" via the Kerberos V5 > mechanism. "nfs@server" is merely the canonical RFC 2078 name. "nfs@server" is a so-called "hostbased service name", as described in section 4.1 of RFC-2743. Although defined in the generic GSS-API spec, this nametype is understood only by a few gssapi mechanisms and therefore non-portable. The procedure how to canonicalize the hostname part of a hostbased service names is specified in section 4.1 of RFC-2743. It explicitly says that the fqdn must be mapped to lowercase by the canonicalization (i.e. after DNS lookup). It does not define, how the two parts of the hostbased service name (after canonicalization) are being used to derive the real name of the target in a form that is acceptable to the GSS-API mechanism. For Kerberos 5 there is a convention to derive a principal name like this: /@ How to derive the is not actually specified in rfc1964, I think. > The RFC 1964 > name is "nfs/server.@", which the initiator has > to expand "server" to in the following steps: > > 1. prefix "nfs/" > 2. append the fully qualified domain name (FQDN) of "server" > 3. append the "@" as defined by the rules in krb5.conf. Could it be that they forgot to put the "lowercasing after DNS lookup" into rfc1964? It is in rfc2078 and rfc2743, and because Kerberos is using the same OIDs as in rfc2744, the definition of rfc-2743, section 4.1 should apply (as well). -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 Apr 11 13:12:52 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 NAA13359 for ; Tue, 11 Apr 2000 13:12:51 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA29890 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 09:29:35 -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 JAA29885 for ; Tue, 11 Apr 2000 09:29:32 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA17466; Tue, 11 Apr 00 12:29:28 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18100; Tue, 11 Apr 2000 09:29:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA03757; Tue, 11 Apr 2000 09:29:20 -0700 (PDT) Received: from teal (awe8-110.Central.Sun.COM [129.147.8.110]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3BGTKw907716; Tue, 11 Apr 2000 09:29:21 -0700 (PDT) Date: Tue, 11 Apr 2000 09:32:40 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: comments on kerberos-revisions-05.txt To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004111433.QAA04590@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > > principal name as target, no transformations are applied to the > > > hostname that is part of the name, AFAIK. > > > > Which I think is broken. Consider a real world application, like > > NFS. The NFS client does: > > > > mount -o sec=krb5 server:/export /mnt > > > > This NFS client uses GSS-API, and so needs to establish a GSS-API security > > context between itself and the target, "nfs@server" via the Kerberos V5 > > mechanism. "nfs@server" is merely the canonical RFC 2078 name. > > "nfs@server" is a so-called "hostbased service name", as described > in section 4.1 of RFC-2743. Although defined in the generic GSS-API > spec, this nametype is understood only by a few gssapi mechanisms > and therefore non-portable. Given that there are but a few gssapi mechanisms, I'm not sure I understand the non-portability comment. In any case, portable or not, host-based service names give one the best opportunity to build security mechanism independent applications, so nfs uses them. > The procedure how to canonicalize the hostname part of a hostbased > service names is specified in section 4.1 of RFC-2743. It explicitly > says that the fqdn must be mapped to lowercase by the canonicalization OK, but when the lower-cased fqdn is passed to the implementation of rfc1964, that opens a window for fqdn to become upper case, which is what I've observed in at least one implementation. The point being that DNS is case-insensitive, and so such programming "errors" are likely. Nonetheless, I concede that RFC 2743 and RFC 1510 are pretty clear on the issue (even if I find the specifications on the issue disagreeable), so treating the fqdn in host-based principals is not needed. Still, Kerberos principals of form: @ could treat the as case insensitive, and as case sensitive, which would satisfy the various concerns raised on this topic, and has the virtue of being consistent with conventions for mailboxes. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 14:54: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 OAA16918 for ; Tue, 11 Apr 2000 14:54:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA10183 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 11:17:35 -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 LAA10172 for ; Tue, 11 Apr 2000 11:17:31 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA25886; Tue, 11 Apr 00 14:17:21 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id UAA28782; Tue, 11 Apr 2000 20:14:32 +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 UAA28262; Tue, 11 Apr 2000 20:15:52 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id UAA05538; Tue, 11 Apr 2000 20:15:52 +0200 (METDST) From: Martin Rex Message-Id: <200004111815.UAA05538@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: mre@Eng.Sun.COM Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 11, 0 09:32:40 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: > > > > > principal name as target, no transformations are applied to the > > > > hostname that is part of the name, AFAIK. > > > > > > Which I think is broken. Consider a real world application, like > > > NFS. The NFS client does: > > > > > > mount -o sec=krb5 server:/export /mnt > > > > > > This NFS client uses GSS-API, and so needs to establish a GSS-API security > > > context between itself and the target, "nfs@server" via the Kerberos V5 > > > mechanism. "nfs@server" is merely the canonical RFC 2078 name. > > > > "nfs@server" is a so-called "hostbased service name", as described > > in section 4.1 of RFC-2743. Although defined in the generic GSS-API > > spec, this nametype is understood only by a few gssapi mechanisms > > and therefore non-portable. > > Given that there are but a few gssapi mechanisms, I'm not sure I understand > the non-portability comment. In any case, portable or not, host-based service > names give one the best opportunity to build security mechanism independent > applications, so nfs uses them. IMHO this is exactly wrong. hostbased service names are mech-specific, so your code is very mechanism dependent. It may be unfortunate, but there are no "portable" names at all, so portable applications must not attempt to derive gssapi names algorithmically from transport endpoints. When using GSS-API, a TCP transport endpoint is securely identified by three parameters: IP-Addr, Port#, Target-Name, and none of the three is redundant. Previously insecure applications that want to use GSS-API to secure their communications must add an additional parameter for the target that a user/adminstrator will have to provide. I personally dislike hostbased service names for many reasons: - they don't easily work for plain IP-Addrs/Port# - they don't easily work for non-standard apps or apps on non-standard ports - they use INsecure DNS for canonicalization and are therefore vulnerable - they're available only in the minority of gssapi mechanisms - even with Kerberos, they don't universally work for target names, e.g. when the target is a user I know there are a lot of kerberized apps that have been or are being shifted to use GSS-API instead of native Kerberos, but no provisions are made to make them portable gssapi applications by allowing the user and/or administrator to supply a target name. -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 Apr 11 15:00: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 PAA17178 for ; Tue, 11 Apr 2000 15:00:13 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA11176 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 11:32: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 LAA11171 for ; Tue, 11 Apr 2000 11:32:01 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA00441; Tue, 11 Apr 00 14:33:45 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16566; Tue, 11 Apr 2000 11:31:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA09751; Tue, 11 Apr 2000 11:31:47 -0700 (PDT) Received: from teal (awe8-110.Central.Sun.COM [129.147.8.110]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3BIVjw930810; Tue, 11 Apr 2000 11:31:45 -0700 (PDT) Date: Tue, 11 Apr 2000 11:35:05 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: host based principal names To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004111815.UAA05538@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > > "nfs@server" is a so-called "hostbased service name", as described > > > in section 4.1 of RFC-2743. Although defined in the generic GSS-API > > > spec, this nametype is understood only by a few gssapi mechanisms > > > and therefore non-portable. > > > > Given that there are but a few gssapi mechanisms, I'm not sure I understand > > the non-portability comment. In any case, portable or not, host-based service > > names give one the best opportunity to build security mechanism independent > > applications, so nfs uses them. > > IMHO this is exactly wrong. hostbased service names are mech-specific, > so your code is very mechanism dependent. It may be unfortunate, but > there are no "portable" names at all, so portable applications must not > attempt to derive gssapi names algorithmically from transport endpoints. nfs@server.widget.com is a very portable name. It happens to get translated to mechanism specific names, which is a bit of an implementation inconvenience, but it simply means that for every mechanism the application supports, there has to be another corresponding mech specific name. It serves the desired purpose, no less than ftp@server.widget.com does for ftp servers. > I know there are a lot of kerberized apps that have been or are being > shifted to use GSS-API instead of native Kerberos, but no provisions > are made to make them portable gssapi applications by allowing the > user and/or administrator to supply a target name. The NFS implementation I worked on is a portable gssapi application. It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY, simultaneously. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 15:50: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 PAA18738 for ; Tue, 11 Apr 2000 15:50:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA14631 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 12:22: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 MAA14618 for ; Tue, 11 Apr 2000 12:22:29 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA19111; Tue, 11 Apr 00 15:22:23 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA16177; Tue, 11 Apr 2000 21:19: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 VAA01216; Tue, 11 Apr 2000 21:21:16 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA05843; Tue, 11 Apr 2000 21:21:17 +0200 (METDST) From: Martin Rex Message-Id: <200004111921.VAA05843@hw1464.wdf.sap-ag.de> Subject: Re: host based principal names To: mre@Eng.Sun.COM Date: Tue, 11 Apr 2000 21:21:17 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 11, 0 11:35:05 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: > > > > > > "nfs@server" is a so-called "hostbased service name", as described > > > > in section 4.1 of RFC-2743. Although defined in the generic GSS-API > > > > spec, this nametype is understood only by a few gssapi mechanisms > > > > and therefore non-portable. > > > > > > Given that there are but a few gssapi mechanisms, I'm not sure I understand > > > the non-portability comment. In any case, portable or not, host-based service > > > names give one the best opportunity to build security mechanism independent > > > applications, so nfs uses them. > > > > IMHO this is exactly wrong. hostbased service names are mech-specific, > > so your code is very mechanism dependent. It may be unfortunate, but > > there are no "portable" names at all, so portable applications must not > > attempt to derive gssapi names algorithmically from transport endpoints. > > nfs@server.widget.com is a very portable name. It happens to get translated to > mechanism specific names, which is a bit of an implementation inconvenience, > but it simply means that for every mechanism the application supports, there > has to be another corresponding mech specific name. It serves the desired > purpose, no less than ftp@server.widget.com does for ftp servers. Where does this portable name "nfs@server.widget.com" get translated? Most gssapi mechanisms will simply return "GSS_S_BAD_NAMETYPE" when they are given an hostbased service name. If you do the translation within your code, then it is a different name than the one I was talking of. It is the same with FTP, and it is really unfortunate that the use of a hostbased service name is actually recommended in the FTP spec, simply because it is non-portable across the majority of the gssapi mechanisms. > > > I know there are a lot of kerberized apps that have been or are being > > shifted to use GSS-API instead of native Kerberos, but no provisions > > are made to make them portable gssapi applications by allowing the > > user and/or administrator to supply a target name. > > The NFS implementation I worked on is a portable gssapi application. > It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY, > simultaneously. The three(four) different SPKMs that I've seen all do not understand hostbased service names. And unfortunately, because rfc2025(SPKM) fails to specify any nametype at all -- provide completely independent nametypes which are interoperating only in a limited way. :-(( -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 Apr 11 16:06: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 QAA19150 for ; Tue, 11 Apr 2000 16:06:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA15124 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 12:32:25 -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 MAA15114 for ; Tue, 11 Apr 2000 12:32:21 -0700 (PDT) Received: from [130.202.20.3] by MIT.EDU with SMTP id AA22791; Tue, 11 Apr 00 15:34:11 EDT Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA00342; Tue, 11 Apr 2000 14:32:14 -0500 (CDT) Message-Id: <38F37DE3.7A1875CF@anl.gov> Date: Tue, 11 Apr 2000 14:32:51 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <200004111815.UAA05538@hw1464.wdf.sap-ag.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Martin Rex wrote: > > > > Given that there are but a few gssapi mechanisms, I'm not sure I understand > > the non-portability comment. In any case, portable or not, host-based service > > names give one the best opportunity to build security mechanism independent > > applications, so nfs uses them. > > IMHO this is exactly wrong. hostbased service names are mech-specific, > so your code is very mechanism dependent. It may be unfortunate, but > there are no "portable" names at all, so portable applications must not > attempt to derive gssapi names algorithmically from transport endpoints. I disagree. They don't have to be mech-specific, and with our GSSAPI based on SSL, we use the host@FQDN just like Kerberos. Sometimes all you have to work with is the hostname, so you have to derive a target name from it. If you have a target_name from some other source, fine, but is then not hostbased. Portable names are another issue, there are not hostbased, as you point out, so why does should this stop one from using hostbased services for services on a host? > > When using GSS-API, a TCP transport endpoint is securely identified by > three parameters: IP-Addr, Port#, Target-Name, and none of the three > is redundant. Previously insecure applications that want to use > GSS-API to secure their communications must add an additional > parameter for the target that a user/adminstrator will have to provide. But for the target to authenticate to the client, the target still needs credentials, which are usually issued or signed be some trusted third party, like a KDC or a CA. So deriving the target name from the hostname when the application is host based and then authenticating it are not completely independent. The target is still proving its identity. > > I personally dislike hostbased service names for many reasons: > - they don't easily work for plain IP-Addrs/Port# > - they don't easily work for non-standard apps or apps on non-standard ports > - they use INsecure DNS for canonicalization and are therefore vulnerable > - they're available only in the minority of gssapi mechanisms > - even with Kerberos, they don't universally work for target names, > e.g. when the target is a user But for a user, it is not a hostbased target. The application can still provide a non hostbased target name if it chooses, so many of these arguments don't realy apply. So maybe we are arguing the same point: If you have a target name, great, use it, if not, and all you have is a FQDN, then you have to use hostbased services. > > I know there are a lot of kerberized apps that have been or are being > shifted to use GSS-API instead of native Kerberos, but no provisions > are made to make them portable gssapi applications by allowing the > user and/or administrator to supply a target name. > > -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 -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 16:14: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 QAA19342 for ; Tue, 11 Apr 2000 16:14:06 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA16139 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 12:46:03 -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 MAA16134 for ; Tue, 11 Apr 2000 12:46:01 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA27475; Tue, 11 Apr 00 15:45:56 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15194; Tue, 11 Apr 2000 12:45:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA29376; Tue, 11 Apr 2000 12:45:51 -0700 (PDT) Received: from teal (awe8-110.Central.Sun.COM [129.147.8.110]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3BJjpw940281; Tue, 11 Apr 2000 12:45:52 -0700 (PDT) Date: Tue, 11 Apr 2000 12:49:11 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: host based principal names To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004111921.VAA05843@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > > IMHO this is exactly wrong. hostbased service names are mech-specific, > > > so your code is very mechanism dependent. It may be unfortunate, but > > > there are no "portable" names at all, so portable applications must not > > > attempt to derive gssapi names algorithmically from transport endpoints. > > > > nfs@server.widget.com is a very portable name. It happens to get translated to > > mechanism specific names, which is a bit of an implementation inconvenience, > > but it simply means that for every mechanism the application supports, there > > has to be another corresponding mech specific name. It serves the desired > > purpose, no less than ftp@server.widget.com does for ftp servers. > > > Where does this portable name "nfs@server.widget.com" get translated? In the mechanism. > Most gssapi mechanisms will simply return "GSS_S_BAD_NAMETYPE" when What's the alternative way to achieve portability if we can't count on the generic gss-api name types being supported? > > The NFS implementation I worked on is a portable gssapi application. > > It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY, > > simultaneously. > > The three(four) different SPKMs that I've seen all do not understand > hostbased service names. And unfortunately, because rfc2025(SPKM) > fails to specify any nametype at all -- provide completely independent > nametypes which are interoperating only in a limited way. :-(( SPKM-3 (part of the pending LIPKEY RFC) mandates all of the name forms of RFC 2078. If a mechanism doesn't support the host based nametyope, then its usefulness is going to be limited, because ftp, ldap, nfs, etc. will expect it. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 17:54: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 RAA22730 for ; Tue, 11 Apr 2000 17:54:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA25501 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 14:24:52 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA25496 for ; Tue, 11 Apr 2000 14:24:48 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id VAA15313; Tue, 11 Apr 2000 21:24:42 GMT Message-Id: <200004112124.VAA15313@orchard.arlington.ma.us> To: Tony Andrea cc: "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session In-Reply-To: Message from Tony Andrea of "Mon, 10 Apr 2000 09:53:15 PDT." <80A473F584BED311810D0050DA289BD4142241@corporate.cybersafe.com> Date: Tue, 11 Apr 2000 17:24:42 -0400 From: Bill Sommerfeld Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I've been largely ignoring CAT for a while, but I'll butt in here since I was around for some of the early discussions of key derivation. Key derivation was designed to eliminate one of the cryptographic "sins" from the original kerberos design: namely, the use of a single key with multiple algorithms for multiple purposes. If you assume the algorithms you're using are perfect, this doesn't add any real strength, but well, we're living in the real world, and the algorithms aren't perfect, so you do key derivation to add a margin of safety. For the most part, we here in CAT-land are plumbers who use cryptography, not cryptographers. When real cryptographers have things to say, and say them strongly, we should listen to them. I believe it would be unwise to discard their contribution. I'll go back to lurking now.. - Bill -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 19:14: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 TAA23829 for ; Tue, 11 Apr 2000 19:14:57 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA02699 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 15:53:45 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA02694 for ; Tue, 11 Apr 2000 15:53:42 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id WAA15714; Tue, 11 Apr 2000 22:53:40 GMT Message-Id: <200004112253.WAA15714@orchard.arlington.ma.us> To: Tony Andrea cc: "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session In-Reply-To: Message from Tony Andrea of "Tue, 11 Apr 2000 15:42:06 PDT." <80A473F584BED311810D0050DA289BD4142251@corporate.cybersafe.com> Date: Tue, 11 Apr 2000 18:53:40 -0400 From: Bill Sommerfeld Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I don't have any references at hand; I'll see what I can dig up. I'd dig through the CAT archives for messages from Marc Horowitz and Uri Blumenthal starting at around june/july of 1996, which was about when work on key derivation got underway. I haven't seen Uri at an IETF in a while.. he was one of the IBM folks who were calling for it and who convinced me and Marc and a few others of its necessity at the Montreal IETF.. - Bill -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 19:17: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 TAA23860 for ; Tue, 11 Apr 2000 19:17:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA01657 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 15:43:14 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id PAA01643 for ; Tue, 11 Apr 2000 15:43:09 -0700 (PDT) Received: (qmail 11187 invoked from network); 11 Apr 2000 22:42:38 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 11 Apr 2000 22:42:38 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Tue, 11 Apr 2000 15:38:50 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id <2MKX7MKQ>; Tue, 11 Apr 2000 15:42:07 -0700 Message-ID: <80A473F584BED311810D0050DA289BD4142251@corporate.cybersafe.com> From: Tony Andrea To: "'Bill Sommerfeld'" Cc: "'CAT-WG List'" Subject: RE: Draft minutes, Adelaide CAT session Date: Tue, 11 Apr 2000 15:42:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA407.2A46A110" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA407.2A46A110 Content-Type: text/plain; charset="iso-8859-1" where can i find documentation on the added security of key derivation as it relates to kerberos? i certainly agree that ignoring someone who knows what they are talking about (a cryptographer in this case) would be a bad plan.... thanks, tony. > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@orchard.arlington.ma.us] > Sent: Tuesday, April 11, 2000 2:25 PM > To: Tony Andrea > Cc: 'CAT-WG List' > Subject: Re: Draft minutes, Adelaide CAT session > > > I've been largely ignoring CAT for a while, but I'll butt in here > since I was around for some of the early discussions of key > derivation. > > Key derivation was designed to eliminate one of the cryptographic > "sins" from the original kerberos design: namely, the use of a single > key with multiple algorithms for multiple purposes. If you assume the > algorithms you're using are perfect, this doesn't add any real > strength, but well, we're living in the real world, and the algorithms > aren't perfect, so you do key derivation to add a margin of safety. > > For the most part, we here in CAT-land are plumbers who use > cryptography, not cryptographers. When real cryptographers have > things to say, and say them strongly, we should listen to them. > I believe it would be unwise to discard their contribution. > > I'll go back to lurking now.. > > - Bill > ------_=_NextPart_001_01BFA407.2A46A110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft minutes, Adelaide CAT session

where can i find documentation on the added = security
of key derivation as it relates to kerberos? i = certainly
agree that ignoring someone who knows what they = are
talking about (a cryptographer in this case) would = be a
bad plan....

thanks,
tony.


> -----Original Message-----
> From: Bill Sommerfeld [mailto:sommerfeld@orc= hard.arlington.ma.us]
> Sent: Tuesday, April 11, 2000 2:25 PM
> To: Tony Andrea
> Cc: 'CAT-WG List'
> Subject: Re: Draft minutes, Adelaide CAT = session
>
>
> I've been largely ignoring CAT for a while, but = I'll butt in here
> since I was around for some of the early = discussions of key
> derivation.
>
> Key derivation was designed to eliminate one of = the cryptographic
> "sins" from the original kerberos = design: namely, the use of a single
> key with multiple algorithms for multiple = purposes.  If you assume the
> algorithms you're using are perfect, this = doesn't add any real
> strength, but well, we're living in the real = world, and the algorithms
> aren't perfect, so you do key derivation to add = a margin of safety.
>
> For the most part, we here in CAT-land are = plumbers who use
> cryptography, not cryptographers.  When = real cryptographers have
> things to say, and say them strongly, we should = listen to them.
> I believe it would be unwise to discard their = contribution.
>
> I'll go back to lurking now..
>
>       =         =         =         =         =         - Bill
>

------_=_NextPart_001_01BFA407.2A46A110-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 11 19:47:25 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 TAA24066 for ; Tue, 11 Apr 2000 19:47:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA04391 for ietf-cat-wg-out720680; Tue, 11 Apr 2000 16:08:26 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA04383 for ; Tue, 11 Apr 2000 16:08:23 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 972EE4ED for ; Tue, 11 Apr 2000 16:08:22 -0700 (PDT) Received: by mail-proxy-2.amazon.com id QAA07253; Tue, 11 Apr 2000 16:08:22 -0700 (PDT) Message-ID: <38F3AF3D.2661B642@amazon.com> Date: Tue, 11 Apr 2000 16:03:25 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Draft minutes, Adelaide CAT session References: <200004112124.VAA15313@orchard.arlington.ma.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I wasn't at adelaide, but as a user (not an implementer) I can say that microsoft&cybersafe being non-interoperable with MIT&Heimdal in this regard would be very disappointing. What choice do I have for interoperable etypes > 56 bit DES? Microsoft uses RC4-HMAC which nobody else supports, Cybersafe uses 3DES without key derivation which nobody else supports to my knowledge. Bill Sommerfeld wrote: > I've been largely ignoring CAT for a while, but I'll butt in here > since I was around for some of the early discussions of key > derivation. > > Key derivation was designed to eliminate one of the cryptographic > "sins" from the original kerberos design: namely, the use of a single > key with multiple algorithms for multiple purposes. If you assume the > algorithms you're using are perfect, this doesn't add any real > strength, but well, we're living in the real world, and the algorithms > aren't perfect, so you do key derivation to add a margin of safety. > > For the most part, we here in CAT-land are plumbers who use > cryptography, not cryptographers. When real cryptographers have > things to say, and say them strongly, we should listen to them. > I believe it would be unwise to discard their contribution. > > I'll go back to lurking now.. > > - Bill > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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 Apr 12 06:48:12 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 GAA14861 for ; Wed, 12 Apr 2000 06:48:12 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09268 for ietf-cat-wg-out720680; Wed, 12 Apr 2000 03:11:41 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09263 for ; Wed, 12 Apr 2000 03:11:37 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id MAA73081; Wed, 12 Apr 2000 12:11:34 +0200 (CEST) (envelope-from assar) To: David Margrave Cc: ietf-cat-wg@lists.Stanford.EDU, heimdal-discuss@sics.se Subject: Re: Draft minutes, Adelaide CAT session References: <200004112124.VAA15313@orchard.arlington.ma.us> <38F3AF3D.2661B642@amazon.com> From: Assar Westerlund Date: 12 Apr 2000 12:11:34 +0200 In-Reply-To: David Margrave's message of "Tue, 11 Apr 2000 16:03:25 -0700" Message-ID: <5lln2jk4rt.fsf@assaris.sics.se> Lines: 18 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk David Margrave writes: > I wasn't at adelaide, but as a user (not an implementer) I can say that > microsoft&cybersafe being non-interoperable with MIT&Heimdal in this regard > would be very disappointing. What choice do I have for interoperable > etypes > 56 bit DES? Microsoft uses RC4-HMAC which nobody else supports, > Cybersafe uses 3DES without key derivation which nobody else supports to my > knowledge. I've started implementing RC4-HMAC but haven't gotten anything that interoperates with w2k yet. And if Microsoft and/or Cybersafe starts using 3DES without key-derivation we'll add it in Heimdal to be able to interoperate with them, but I would prefer that everybody plays the same 3DES game. This is getting off-topic for the CAT list, so please move it over to the Heimdal mailing list for further implementation-discussions. /assar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 12 06:58:38 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 GAA14955 for ; Wed, 12 Apr 2000 06:58:38 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09390 for ietf-cat-wg-out720680; Wed, 12 Apr 2000 03:18:05 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09385 for ; Wed, 12 Apr 2000 03:18:02 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id MAA73094; Wed, 12 Apr 2000 12:18:00 +0200 (CEST) (envelope-from assar) To: Tony Andrea Cc: marc@mit.edu, "'CAT-WG List'" Subject: Re: Draft minutes, Adelaide CAT session References: <80A473F584BED311810D0050DA289BD4142251@corporate.cybersafe.com> From: Assar Westerlund Date: 12 Apr 2000 12:18:00 +0200 In-Reply-To: Tony Andrea's message of "Tue, 11 Apr 2000 15:42:06 -0700" Message-ID: <5lhfd7k4h3.fsf@assaris.sics.se> Lines: 18 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Tony Andrea writes: > where can i find documentation on the added security > of key derivation as it relates to kerberos? i certainly > agree that ignoring someone who knows what they are > talking about (a cryptographer in this case) would be a > bad plan.... I think this is the most relevant paper that I've seen referenced about this: http://www.research.att.com/~smb/papers/ides.ps And then there are the Horowitz-drafts on key derivation, but that's more on howto rather than why. But then I guess Marc (hi there) is the person to ask about this. /assar -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 13 10:51: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 KAA03828 for ; Thu, 13 Apr 2000 10:51:42 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id HAA28875 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 07:20:07 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id HAA28870 for ; Thu, 13 Apr 2000 07:20:05 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12109 for ; Thu, 13 Apr 2000 07:20:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id HAA03964 for ; Thu, 13 Apr 2000 07:20:00 -0700 (PDT) Received: from teal (awe8-113.Central.Sun.COM [129.147.8.113]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3DEJww334105; Thu, 13 Apr 2000 07:19:58 -0700 (PDT) Date: Thu, 13 Apr 2000 07:23:17 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: RPCSEC_GSS and GSS-API source code To: ietf-cat-wg@lists.Stanford.EDU Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is posted with permission of the CAT chair. An implementation of RPCSEC_GSS described in RFC 2203 has been made available for download (under the Sun Industry Standards Source license agreement) via Sun's recent release of TI-RPC: http://soldc.sun.com/tools/index.html This release provides a convenient means of verifying interoperability of other independent implementations of RPCSEC_GSS and helps advance RFC 2203 to Draft Standard. Also included in this TI-RPC release is an implementation of the following RFCs: - XDR: External Data Representation Standard (RFC 1832) - RPC: Remote Procedure Call Protocol Specification Version 2 (RFC 1831) - Binding Protocols for ONC RPC Version 2 (RFC 1833) - Generic Security Service Application Program Interface, Version 2 (RFC 2078) - At this time, it includes two mechanisms. - A dummy mechanism intended for testing purposes - A 640 bit and 1024 bit Diffie-Hellman mechanism designed for RPC applications, and intended to replace the AUTH_DES (AUTH_DH) RPC authentication flavor. - Authentication Mechanisms for ONC RPC (RFC 2695) - just AUTH_DH, not AUTH_KERB4. For more details please visit the above website. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 13 15:52: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 PAA12625 for ; Thu, 13 Apr 2000 15:52:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA15120 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 12:13: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 MAA15115 for ; Thu, 13 Apr 2000 12:13:31 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA11022; Thu, 13 Apr 00 15:12:50 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA08129; Thu, 13 Apr 2000 21:09:33 +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 VAA09811; Thu, 13 Apr 2000 21:08:55 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA19831; Thu, 13 Apr 2000 21:08:56 +0200 (METDST) From: Martin Rex Message-Id: <200004131908.VAA19831@hw1464.wdf.sap-ag.de> Subject: Re: host based principal names To: mre@Eng.Sun.COM Date: Thu, 13 Apr 2000 21:08:55 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 11, 0 12:49:11 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 Mike Eisler wrote: > > > > > Where does this portable name "nfs@server.widget.com" get translated? > > In the mechanism. > > > Most gssapi mechanisms will simply return "GSS_S_BAD_NAMETYPE" when > > What's the alternative way to achieve portability if we can't count on > the generic gss-api name types being supported? Let users/administrators provide the names, just as they provide their gssapi implementation. Don't hardcode names or nametypes into your application, because this will definitely make it non-portable, even if it works with all the mechanisms that you're using yourself right now. > > > > The NFS implementation I worked on is a portable gssapi application. > > > It works over Kerberos V5 today, and will someday work over SPKM/LIPKEY, > > > simultaneously. > > > > The three(four) different SPKMs that I've seen all do not understand > > hostbased service names. And unfortunately, because rfc2025(SPKM) > > fails to specify any nametype at all -- provide completely independent > > nametypes which are interoperating only in a limited way. :-(( > > SPKM-3 (part of the pending LIPKEY RFC) mandates all of the > name forms of RFC 2078. Uh-oh! ... I have just browsed through the lipkey-03 document quickly and I'm not amused. The spec is sufficiently vague to prevent interoperability of any two independent implementations (i.e. before they meet for the first time). Somehow I get the feeling that this proposed mechanism bends the gssapi framework over its limits, i.e. the only thing that works like gssapi is the context token handshake and the message protection calls. There is so much more to GSS-API than that. Some things that I noticed: - section 4.1 repeats section 2.1 section 4.2 repeats section 2.2 - Requiring "all generic nametypes of rfc2078" is inappropriate. A real gssapi mechanism spec (which rfc2025(spkm) is not quite) needs to define a mechanism-specific name format first. Then it may define how generic nametypes of rfc2743 are to be transformed into this mechanism-specific format. rfc1964 (the Kerberos5 gssapi mechanism spec), section 2.1 is much better in this respect, although it is missing the definition how to map the mandatory hostbased service name into a kerberos principal name in section 2.1.2, and also missing such guidance for the optional name forms in 2.2 Although lacking the guidance, all Kerberos5 gssapi mechanisms that I've seen are fortunately doing it in the same way. Note in particular the header of section 2.2 in rfc1964 and you'll notice why sections 2.2/4.2 of lipkey are inappropriate as they are. Among the nametypes defined in rfc2743(rfc2078) is also an exported name type. A generic framing is given in section 3.2 of rfc2743. If a mechanism wants to support exported names, it will need to define how its own mechanism-specific names are put into the payload of the generic exported-names framing. quoting rfc2743, section 3.2: "mechanism-independent exported name format" "The format of names encapsulated via this representation shall be defined within individual mechanism drafts." rfc2025 (SPKM) is seriously incomplete because it fails to define a clear mechanism specific nametype and how to map generic nametypes into the mechanism-specific ones. All the (4) SPKM implementations that I've seen so far implemented their own mechanism-specific nametypes and they basically do not interoperate on names. The libkey-03 draft is just as incomplete in this respect. - in 3.3.3 gss_accept_sec_context() should return GSS_S_NO_CRED when the users credentials are invalid. This is a bad abuse of this error code, because for gss_accept_sec_context() it is meant to apply to the acceptor credentials, NOT the initiator credentials. You should be defining a new major status code for your purpose. - although the spec talks of unilateral authentication in several locations (which would not require a target name at all for GSS-API v2) it makes use of the target name all over the place with fuzzy purpose. It suggest some sort of target name to Server certificate mapping, however doesn't say how. There is the GSS_C_MUTUAL_FLAG as input to and output from gss_init_sec_context(), which really should get used if any target name validation (I doubt it will be a real authentication) for this mechanism is performed at all. Otherwise the whole target name stuff should be dropped all together. > > If a mechanism doesn't support the host based nametype, then its usefulness > is going to be limited, because ftp, ldap, nfs, etc. will expect it. The applicability of applications that hardcode names and nametypes is going to be limited, because they didn't understand the gssapi spec. Applications must have provisions to pass a gssapi name and nametype opaque from the user/administrator to the gssapi mechanism, or they're broken. -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 Apr 13 16:58:47 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 QAA13867 for ; Thu, 13 Apr 2000 16:58:46 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA22552 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 13:32:20 -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 NAA22544 for ; Thu, 13 Apr 2000 13:32:17 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA22596; Thu, 13 Apr 00 16:34:07 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28350; Thu, 13 Apr 2000 13:32:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA10794; Thu, 13 Apr 2000 13:32:12 -0700 (PDT) Received: from teal (awe8-113.Central.Sun.COM [129.147.8.113]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3DKW9w392928; Thu, 13 Apr 2000 13:32:10 -0700 (PDT) Date: Thu, 13 Apr 2000 13:35:28 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: host based principal names To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004131908.VAA19831@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > What's the alternative way to achieve portability if we can't count on > > the generic gss-api name types being supported? > > Let users/administrators provide the names, just as they provide > their gssapi implementation. Don't hardcode names or nametypes into > your application, because this will definitely make it non-portable, > even if it works with all the mechanisms that you're using yourself > right now. Please elaborate, perhaps with a simple example. > I have just browsed through the lipkey-03 document quickly and > I'm not amused. The spec is sufficiently vague to prevent interoperability > of any two independent implementations (i.e. before they meet for the > first time). Somehow I get the feeling that this proposed mechanism > bends the gssapi framework over its limits, i.e. the only thing that > works like gssapi is the context token handshake and the message > protection calls. There is so much more to GSS-API than that. > > > Some things that I noticed: > > - section 4.1 repeats section 2.1 > section 4.2 repeats section 2.2 There's no repetition since 2.1 and 2.2 refer to SPKM-3, and 4.1 and 4.2 refer to LIPKEY. > - Requiring "all generic nametypes of rfc2078" is inappropriate. > > A real gssapi mechanism spec (which rfc2025(spkm) is not quite) > needs to define a mechanism-specific name format first. Then > it may define how generic nametypes of rfc2743 are to be transformed > into this mechanism-specific format. rfc1964 (the Kerberos5 gssapi > mechanism spec), section 2.1 is much better in this respect, although > it is missing the definition how to map the mandatory hostbased > service name into a kerberos principal name in section 2.1.2, > and also missing such guidance for the optional name forms in 2.2 > Although lacking the guidance, all Kerberos5 gssapi mechanisms > that I've seen are fortunately doing it in the same way. Which would prevent LIPKEY/SPKM-3 from reaching Draft, at which point this will have to nailed down. My mistake for overlooking it. I suspect implementors will follow the Kerberos V5 approaches. > - in 3.3.3 gss_accept_sec_context() should return GSS_S_NO_CRED > when the users credentials are invalid. This is a bad abuse of this > error code, because for gss_accept_sec_context() it is meant to > apply to the acceptor credentials, NOT the initiator credentials. > You should be defining a new major status code for your purpose. I don't really care for new major status code's since it impacts portability. GSS_S_NO_CRED is closest one to matching the requirement. > - although the spec talks of unilateral authentication in several > locations (which would not require a target name at all for GSS-API v2) SPKM supports two types of unilateral authentication. One form authenticates just the target. Another form authenticates just the initiator. LIPKEY is layered over the former form. > it makes use of the target name all over the place with fuzzy > purpose. It suggest some sort of target name to Server certificate > mapping, however doesn't say how. My, possibly naive, notion was that the target name, service[@host] would be compared with the SubjectAltName in the certificate. service@host has an obvious 1-1 mapping with the rfc822Name field. > > If a mechanism doesn't support the host based nametype, then its usefulness > > is going to be limited, because ftp, ldap, nfs, etc. will expect it. > > The applicability of applications that hardcode names and nametypes > is going to be limited, because they didn't understand the gssapi spec. > Applications must have provisions to pass a gssapi name and nametype opaque > from the user/administrator to the gssapi mechanism, or they're broken. I admit to not understanding the issue above. However, it seems to be that given ftp, ldap, nfs, etc. can be made to work over Kerberos V5, and goiven SPKM is underspecifying in the areas of principal name management, the experiences of Kerberos V5 can be be applied to SPKM, and SPKM can then be better specified. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 13 17:32: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 RAA14523 for ; Thu, 13 Apr 2000 17:32:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA25498 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 13:58:28 -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 NAA25490 for ; Thu, 13 Apr 2000 13:58:25 -0700 (PDT) Received: from ABDCCB13.ipt.aol.com by MIT.EDU with SMTP id AA22978; Thu, 13 Apr 00 16:58:18 EDT Message-Id: <10004132058.AA22978@MIT.EDU> From: "Marc Lev" To: Subject: We pay cash, now! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Apr 2000 17:07:55 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Do you know someone who is currently trying to sell their mobile home or mobile home park? Do you know of someoone who is receiving payments from the sale of a mobile home or mobile home park? If you answered yes to either of these questions we may be able to help. At Trans World Funding we are in the business of helping people convert payments from mobile home and park sales into immediate cash. We have investors who purchase mobile home notes and give the sellers a lump sum of cash instead of them having to receive monthly payments over a long period of time. We can also finance the purchase of new mobile homes for dealerships throughout the country. If you know of someone who is selling a mobile home or mobile home park, this may help them sell it much faster! If you know someone who has sold a mobile home or park with seller financing and is receiving payments, this may help them financially. Please feel free to contact me at any time. Marc L. Lev, DCFS President Trans World Funding TWF2000@aol.com (410) 243-9382 PS We are much more liberal and more flexable than a conventional bank! PPS We pay very nice referral fees. If you have received this e-mail in error, please remain calm. We have either communicated in the past or our names are on the same list. If you wish to be removed from our mailing list, just send us a blank e-mail and put the word remove in the subject line. Thank you for your time. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 13 22:10: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 WAA18232 for ; Thu, 13 Apr 2000 22:10:12 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA17685 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 18:44:26 -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 SAA17663 for ; Thu, 13 Apr 2000 18:44:20 -0700 (PDT) Received: from TRAMPOLINE.THUNK.ORG by MIT.EDU with SMTP id AA05595; Thu, 13 Apr 00 21:44:14 EDT Received: (from tytso@localhost) by trampoline.thunk.org (8.9.3/8.9.3) id VAA02140; Thu, 13 Apr 2000 21:47:55 -0400 Date: Thu, 13 Apr 2000 21:47:55 -0400 Message-Id: <200004140147.VAA02140@trampoline.thunk.org> To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu In-Reply-To: <200004111815.UAA05538@hw1464.wdf.sap-ag.de> (message from Martin Rex on Tue, 11 Apr 2000 20:15:52 +0200 (METDST)) Subject: Re: comments on kerberos-revisions-05.txt From: tytso@mit.edu Phone: (781) 391-3464 References: <200004111815.UAA05538@hw1464.wdf.sap-ag.de> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Martin Rex Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST) IMHO this is exactly wrong. hostbased service names are mech-specific, so your code is very mechanism dependent. It may be unfortunate, but there are no "portable" names at all, so portable applications must not attempt to derive gssapi names algorithmically from transport endpoints. From the start, hostbased service names were designed to be mechanism independent. That's why they're in the generic GSSAPI draft. It just so happens that for Kerberos there's a simple algorithmic tranformation between the hostbased service name and the Kerberos principal name, but I believe the original vision was one where some database might be consulted to translate the hostbased service name into a X.509 Distinguished Name, for example. I think you're making the argument that the way implementations have turned out haven't matched with the vision, but that's different from saying that the whole concept of host-based service names was wrong. It's true that specifying all three parameters (IP-Addr, Port#, and Target-name) is the most general, but I think it's important to have defaults whenever possible. Most people don't specify the telnet port when they telnet to a host, and I think most would rebel if we asked them to specify the target-name as well! Especially if it were an X.509 Distinguished name. Can you imagine people typing: telnet bitsy.mit.edu 23 /C=US/SP=Massachusetts/OU=Massachusetts Institute of Technology/CN=bitsy.mit.edu when they want to telnet to the machine bitsy.mit.edu? I think not! (Thus the old joke whose punchline was: "... and when two X.400 users meet in a conference, and want to reach each other afterwards ---- they use the telephone.) Details about whether an insecure means is used for canonicalizing them is really an implementation issue. We could devise a secure means of canonicalizing the name (including deploying SecureDNS :-), if we really wanted to deal with that issue. More of an issue is your observation that many gssapi mechanisms apparently aren't implementing the host-based service name. This is unfortunate, but basically, this is a hard problem that I don't think we can just define away. For certain applications it may be OK to hard-code the target name in the command-line associated with an icon which the user double-clicks (which is the case with the SAPGUI, for example), but I don't think that's a general solution to the problem. - 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 Fri Apr 14 00:35:38 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 AAA21311 for ; Fri, 14 Apr 2000 00:35:38 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id VAA24213 for ietf-cat-wg-out720680; Thu, 13 Apr 2000 21:10:52 -0700 (PDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA24203 for ; Thu, 13 Apr 2000 21:10:39 -0700 (PDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id UAA46879 for ; Thu, 13 Apr 2000 20:56:53 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP Date: Thu, 13 Apr 2000 21:12:39 -0700 Message-ID: <016701bfa5c7$acec8580$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5lln2jk4rt.fsf@assaris.sics.se> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP The Authentication, Authorization and Accounting (AAA) Working Group of the Internet Engineering Task Force is currently soliciting submission of protocols for authentication, authorization and accounting as applied to network access. Submissions are being solicited effective immediately. Authors of candidate protocols are required to notify the AAA WG chairs, Bernard Aboba and Paul Krumviede of their intent to submit a candidate protocol. It is desirable that this notification be sent by May 1, 2000. Protocol submissions and compliance description documents are to be submitted in Internet Draft format by email to internet-drafts@ietf.org. The deadline for submissions is June 1, 2000. To be considered as a candidate, submissions must include an unqualified RFC 2026 statement, as described at: http://www.ietf.org/Sec10.txt Information on the Internet Draft format is available at: http://www.ietf.org/ietf/1id-guidelines.txt The compliance description document must explain on a detailed requirement-by-requirement basis how the submitted protocol satisfies the AAA network access requirements. The requirements are available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt (or later version). The protocol submission and compliance description documents will then be used as the basis for an independent evaluation. Based on the results of the independent evaluation, the working group will decide whether one or more submissions meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a protocol from scratch. In the protocol development process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development. Authors of candidate protocols must be willing to give up change control to the IETF, so as to allow modification of the candidate protocols to AAA WG needs. For further information on the IETF AAA WG, including working group drafts and milestones, please consult the working group web page at: http://www.ietf.org/html.charters/aaa-charter.html -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 14 12:30: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 MAA10157 for ; Fri, 14 Apr 2000 12:30:32 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA11575 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 08:42:27 -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 IAA11570 for ; Fri, 14 Apr 2000 08:42:24 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA17243; Fri, 14 Apr 00 11:42:17 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id RAA29895; Fri, 14 Apr 2000 17:39:30 +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 RAA24165; Fri, 14 Apr 2000 17:41:35 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id RAA25663; Fri, 14 Apr 2000 17:41:35 +0200 (METDST) From: Martin Rex Message-Id: <200004141541.RAA25663@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: tytso@mit.edu Date: Fri, 14 Apr 2000 17:41:35 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004140147.VAA02140@trampoline.thunk.org> from "tytso@MIT.EDU" at Apr 13, 0 09:47:55 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 tytso@MIT.EDU wrote: > > From: Martin Rex > Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST) > > IMHO this is exactly wrong. hostbased service names are mech-specific, > so your code is very mechanism dependent. It may be unfortunate, but > there are no "portable" names at all, so portable applications must not > attempt to derive gssapi names algorithmically from transport > endpoints. > > From the start, hostbased service names were designed to be mechanism > independent. That's why they're in the generic GSSAPI draft. It just > so happens that for Kerberos there's a simple algorithmic tranformation > between the hostbased service name and the Kerberos principal name, but > I believe the original vision was one where some database might be > consulted to translate the hostbased service name into a X.509 > Distinguished Name, for example. > > I think you're making the argument that the way implementations have > turned out haven't matched with the vision, but that's different from > saying that the whole concept of host-based service names was wrong. My oberservations of hostbased service names are: - they are INSECURE how rfc2743 defines them and the way they have been implemented in MIT Kerberos 5. - they are not available in many of gssapi mechanisms that I have seen, in particular the public key based mechanisms - they don't scale for distributed services where the end system decides which machine is going to serve the request. - they don't work for proxy-traversal, i.e. environments where the service is located behind a single or even a chain of firewalls > > It's true that specifying all three parameters (IP-Addr, Port#, and > Target-name) is the most general, but I think it's important to have > defaults whenever possible. Most people don't specify the telnet port > when they telnet to a host, and I think most would rebel if we asked > them to specify the target-name as well! Especially if it were an > X.509 Distinguished name. Can you imagine people typing: > > telnet bitsy.mit.edu 23 /C=US/SP=Massachusetts/OU=Massachusetts Institute of Technology/CN=bitsy.mit.edu > > when they want to telnet to the machine bitsy.mit.edu? I think not! Yes, sort of! To ease the user interface, you can make it work backwards. There is a popular telnet replacement called SSH which does just that. It eases the use by caching the identities (which are public keys in SSH) under the alias of the hostname. You know that if you don't verify "authenticate" a host key (by transfering them out-of-band or comparing fingerprints), then you're taking a risk. I think it would be a good idea for apps such as telnet to use a similar scheme when adding security. SSH's use of the hostname as the lookup key doesn't scale with firewall traversal, however. Re-use of the host key in a server farm should work, however. Your example CN is acutally quite short. There are CAs that put a policy and other junk into the DN as well... Because of that I think it's a bad idea to use the full or parts of the subject DN for authentication. The important point is not to force them typing lengthy names, but to require a SECURE transformation from the target name that the user supplies into the name that is compared against the target's real identity. As long as ALL transformations on the target name are secure, - it will be ok to resolve the transport endpoint through insecure naming services. - it won't matter if the transport endpoint resolves round-robin to a particular instance of a server farm / cluster. - it won't matter if the transport endpoint is actually a proxy that will decide by it's own to which machine of a server farm you will be connected/routed. - it is possible to share a single server credential across all servers of a server farm / cluster. hostbased service names are a very Kerberos-centric view of the situation. Because of the way the Kerberos authentication works (authenticator and replay cache), sharing server credentials across several hosts of a cluster would result in a replay vulerability. Hostbased service names scale badly in server farms / clustered environments. Here, servers are not only acceptors, they're often initiators, so a server farm with 100 servers need not only 100 server credentials, but also Access Control lists with 100 entries on each of the server to allow internal delegation, cross-connects and load-balancing. Using a single service name and a single credential eases the adminstration significantly, and changes in the exact procedure how to connect a client to a particular service instance will not interfere with a secure name resolution of the client. > > Details about whether an insecure means is used for canonicalizing them > is really an implementation issue. We could devise a secure means of > canonicalizing the name (including deploying SecureDNS :-), if we really > wanted to deal with that issue. Even zillion-bit secure DNS will not prevent the transfer of a DNS-domain from one company to another by a court order resulting from a trademark dispute. And this is becoming more and more common nowadays. The remaining security problem with DNS is that the allocation of DNS domains is not secure, but a first-come first-serve service with legal battles over the domain ownerships. And I don't think this will change soon. No, *I* don't want to root my trust in DNS, even if they switch to secure DNS. Now if I accidentally connect to "www.openssl.de" instead of "www.openssl.org", then it is exactly the insecure hostname and domain allocation of DNS that could fool me to believe everything is just fine if they showed me a VeriSign Server Certificate for www.openssl.de (which they rightfully could obtain). > > More of an issue is your observation that many gssapi mechanisms > apparently aren't implementing the host-based service name. This is > unfortunate, but basically, this is a hard problem that I don't think we > can just define away. For certain applications it may be OK to > hard-code the target name in the command-line associated with an icon > which the user double-clicks (which is the case with the SAPGUI, for > example), but I don't think that's a general solution to the problem. It may depend on the application how it caches the target names, however I think the full names should always be used and cached, and when the user starts the game with a short name (or without any name just like in SSH), the user should at most once have to take a risk of an insecure target identity transformation. When using public key based technology and preconfigured trusted roots, the risk of the initial insecure name transformation could be further reduced. -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 Fri Apr 14 13:26: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 NAA11397 for ; Fri, 14 Apr 2000 13:26:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA14660 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 09:47:16 -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 JAA14655 for ; Fri, 14 Apr 2000 09:47:13 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA09783; Fri, 14 Apr 00 12:47:08 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA02493; Fri, 14 Apr 2000 12:47:09 -0400 (EDT) Date: Fri, 14 Apr 2000 12:47:09 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: tytso@mit.edu, cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of Fri, 14 Apr 2000 17:41:35 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > My oberservations of hostbased service names are: > - they are INSECURE how rfc2743 defines them and the way they have > been implemented in MIT Kerberos 5. I'm not sure what you are saying here. Is this supposed to mean that because Kerberos 5 uses hostnames in Kerberos principals that Kerberos 5 is insecure? Or just the GSSAPI implementation? And in what way is it insecure? > There is a popular telnet replacement called SSH which does just that. > It eases the use by caching the identities (which are public keys in SSH) > under the alias of the hostname. You know that if you don't verify > "authenticate" a host key (by transfering them out-of-band or comparing > fingerprints), then you're taking a risk. > I think it would be a good idea for apps such as telnet to use a similar > scheme when adding security. SSH's use of the hostname as the lookup > key doesn't scale with firewall traversal, however. Re-use of the > host key in a server farm should work, however. SSH in particular is insecure because it does rely on the caching of public keys under the host name alias on insecure client operating systems and file systems. SSH is even worse in that is relies on an insecure client operating system and/or file systems to protect end user private keys. I would not use SSH as an example upon which to recommend secure protocols be based. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 14 14:20: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 OAA12323 for ; Fri, 14 Apr 2000 14:20:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA19314 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 10:47:26 -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 KAA19309 for ; Fri, 14 Apr 2000 10:47:23 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA01287; Fri, 14 Apr 00 13:47:18 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA05040; Fri, 14 Apr 2000 19:44:29 +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 TAA27361; Fri, 14 Apr 2000 19:44:11 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA26335; Fri, 14 Apr 2000 19:44:11 +0200 (METDST) From: Martin Rex Message-Id: <200004141744.TAA26335@hw1464.wdf.sap-ag.de> Subject: Re: host based principal names To: mre@Eng.Sun.COM Date: Fri, 14 Apr 2000 19:44:10 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 13, 0 01:35:28 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 Mike Eisler wrote: > > > > What's the alternative way to achieve portability if we can't count on > > > the generic gss-api name types being supported? > > > > Let users/administrators provide the names, just as they provide > > their gssapi implementation. Don't hardcode names or nametypes into > > your application, because this will definitely make it non-portable, > > even if it works with all the mechanisms that you're using yourself > > right now. > > Please elaborate, perhaps with a simple example. Look at the CN=f.q.d.n check that Web-Browsers perform. This is a hardcoded and stupid target name validation, which doesn't add real security, it only verifies the association of a public key with a hostname that is allocated from a first-come first-served namespace (the DNS). We are going to add HTTPS accessibility to our application servers, but because of this silly browser habit, we will have to torment the administrators with getting Server Cert's signed for each and every server seperately and to maintain ACLs whenever any of the servers accesses another server by HTTPS client authentication (within the same server farm of from a different server farm). In a simple Web-Server scenario it is possible to cheat the clients about the transport endpoint, either by using a TCP-Proxy (or a NAT) and using a Certificate with the address of the proxy machine (or the NAT). This has an added benefit that "bookmarks" will have the correct entry point. However this also provides a single point of failure and network traffic hotspots. And why do we have to cheat the client at all -- it would be much better if the client was so short-sighted in the first place. > > > I have just browsed through the lipkey-03 document quickly and > > I'm not amused. The spec is sufficiently vague to prevent interoperability > > of any two independent implementations (i.e. before they meet for the > > first time). Somehow I get the feeling that this proposed mechanism > > bends the gssapi framework over its limits, i.e. the only thing that > > works like gssapi is the context token handshake and the message > > protection calls. There is so much more to GSS-API than that. > > > > > > Some things that I noticed: > > > > - section 4.1 repeats section 2.1 > > section 4.2 repeats section 2.2 > > There's no repetition since 2.1 and 2.2 refer to SPKM-3, and > 4.1 and 4.2 refer to LIPKEY. OK, I'm sorry. So much for my speed-reading capabilities at night. I searched for certain keywords only and only read the near vicinity around them. > > > - Requiring "all generic nametypes of rfc2078" is inappropriate. > > > > A real gssapi mechanism spec (which rfc2025(spkm) is not quite) > > needs to define a mechanism-specific name format first. Then > > it may define how generic nametypes of rfc2743 are to be transformed > > into this mechanism-specific format. rfc1964 (the Kerberos5 gssapi > > mechanism spec), section 2.1 is much better in this respect, although > > it is missing the definition how to map the mandatory hostbased > > service name into a kerberos principal name in section 2.1.2, > > and also missing such guidance for the optional name forms in 2.2 > > Although lacking the guidance, all Kerberos5 gssapi mechanisms > > that I've seen are fortunately doing it in the same way. > > Which would prevent LIPKEY/SPKM-3 from reaching Draft, at which point > this will have to nailed down. My mistake for overlooking it. > I suspect implementors will follow the Kerberos V5 approaches. This didn't work at all with SPKM, how are you so optimitic that it will work with an SPKM-derived mechanism? > > > - in 3.3.3 gss_accept_sec_context() should return GSS_S_NO_CRED > > when the users credentials are invalid. This is a bad abuse of this > > error code, because for gss_accept_sec_context() it is meant to > > apply to the acceptor credentials, NOT the initiator credentials. > > You should be defining a new major status code for your purpose. > > I don't really care for new major status code's since it impacts > portability. GSS_S_NO_CRED is closest one to matching the > requirement. Semantically it is the wrong status code. Quoting rfc2743, section 2.2.2, GSS_Accept_sec_context o GSS_S_NO_CRED indicates that no context was established, either because the input cred_handle was invalid, because the referenced credentials are valid for context initiator use only, because the caller lacks authorization to access the referenced credentials, or because the procedure for default credential resolution failed. When returned by gss_accept_sec_context(), this status code is reserved for failures related to the explicit or implicit acceptor credentials. It is wrong to use it for indicating that client credentials in the context token are invalid for logon. I don't by the portability argument: existing full-blown gssapi mechanisms, (if they ever let you this far) will have to return GSS_S_FAILURE. Again, if you want to indicate the particular failure that the client credentials transferred by LIPKEY are invalid for logon, then invent a new major status code, *please*. > > > - although the spec talks of unilateral authentication in several > > locations (which would not require a target name at all for GSS-API v2) > > SPKM supports two types of unilateral authentication. One form > authenticates just the target. Another form authenticates > just the initiator. LIPKEY is layered over the former form. > > > it makes use of the target name all over the place with fuzzy > > purpose. It suggest some sort of target name to Server certificate > > mapping, however doesn't say how. > > My, possibly naive, notion was that the target name, service[@host] would be > compared with the SubjectAltName in the certificate. service@host has an > obvious 1-1 mapping with the rfc822Name field. Don't count on the obvious. History with SPKM shows that implementors get things wrong ... terribly wrong, simply because they will have to deliver a product long before they have a chance to look closely at other implementations. I would really appreciate if the LIPKEY spec would *mandate* a particular mapping. Keeping in mind the drawbacks of strict hostbased service names, such a mapping should offer more flexibility. The ID draft-ietf-tls-https-04.txt, section 3.1, makes at least some provisions for supporting server farms with a single credential. This draft mentions transport-independent target authentication, but doesn't realize their huge potential benefits. > > > > If a mechanism doesn't support the host based nametype, then its usefulness > > > is going to be limited, because ftp, ldap, nfs, etc. will expect it. > > > > The applicability of applications that hardcode names and nametypes > > is going to be limited, because they didn't understand the gssapi spec. > > Applications must have provisions to pass a gssapi name and nametype opaque > > from the user/administrator to the gssapi mechanism, or they're broken. > > I admit to not understanding the issue above. However, it seems to be > that given ftp, ldap, nfs, etc. can be made to work over Kerberos V5, and > given SPKM is underspecifying in the areas of principal name management, > the experiences of Kerberos V5 can be be applied to SPKM, and SPKM can > then be better specified. Updating the SPKM spec to define a mechanism-specific nametype and in particular the exact mapping of hostbased service names into this namespace would be a great benefit in my opinion. However it would require backwards-incompatible code updates for all existing SPKM implementations and provide clear guidelines for CAs how to issue Certificates for server instances. One of the reasons why the SPKM spec is lacking such definitions is probably that they didn't want to force certificate content constraints onto CAs. Up to now, CAs were the ones to set rules for the contents of their certificates. -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 Fri Apr 14 14:21: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 OAA12340 for ; Fri, 14 Apr 2000 14:21:44 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA19066 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 10:44: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 KAA19061 for ; Fri, 14 Apr 2000 10:44:05 -0700 (PDT) Received: from tholian.securid.com by MIT.EDU with SMTP id AA05037; Fri, 14 Apr 00 13:45:53 EDT Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) with SMTP; 14 Apr 2000 17:40:07 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 NAA26942; Fri, 14 Apr 2000 13:40:48 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <2ZJHJ6ZT>; Fri, 14 Apr 2000 13:43:59 -0400 Message-Id: From: "Linn, John" To: "'tytso@mit.edu'" , mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Subject: RE: comments on kerberos-revisions-05.txt Date: Fri, 14 Apr 2000 13:43:58 -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 Ted writes: > From: Martin Rex > Date: Tue, 11 Apr 2000 20:15:52 +0200 (METDST) > > IMHO this is exactly wrong. hostbased service names are > mech-specific, > so your code is very mechanism dependent. It may be > unfortunate, but > there are no "portable" names at all, so portable > applications must not > attempt to derive gssapi names algorithmically from transport > endpoints. > > From the start, hostbased service names were designed to be mechanism > independent. That's why they're in the generic GSSAPI draft. It just > so happens that for Kerberos there's a simple algorithmic > tranformation > between the hostbased service name and the Kerberos principal > name, but > I believe the original vision was one where some database might be > consulted to translate the hostbased service name into a X.509 > Distinguished Name, for example. Agreed. The fundamental idea is that each mechanism supporting HBSNs defines how they map into the naming structures that it uses. I think they're an important step towards cross-mechanism portability, and think it would be a Useful Thing in this regard if more mechanisms take up RFC-2743's recommendation to support them. > > I think you're making the argument that the way implementations have > turned out haven't matched with the vision, but that's different from > saying that the whole concept of host-based service names was wrong. > > It's true that specifying all three parameters (IP-Addr, Port#, and > Target-name) is the most general, but I think it's important to have > defaults whenever possible. Most people don't specify the telnet port > when they telnet to a host, and I think most would rebel if we asked > them to specify the target-name as well! Especially if it were an > X.509 Distinguished name. Can you imagine people typing: > > telnet bitsy.mit.edu 23 > /C=US/SP=Massachusetts/OU=Massachusetts Institute of > Technology/CN=bitsy.mit.edu > > when they want to telnet to the machine bitsy.mit.edu? I think not! > (Thus the old joke whose punchline was: "... and when two X.400 users > meet in a conference, and want to reach each other afterwards > ---- they > use the telephone.) Agreed again; for most users, it's highly desirable to defer this mechanism-specific name processing and knowledge (including, if mutual authentication is active, the determination of whether the target's authenticated name appropriately corresponds to the HBSN requested by the initiator) to be handled within the mechanism. --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 Fri Apr 14 14:32: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 OAA12663 for ; Fri, 14 Apr 2000 14:32:20 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA20059 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 11:02: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 LAA20054 for ; Fri, 14 Apr 2000 11:02:23 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA11727; Fri, 14 Apr 00 14:04:15 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA08537; Fri, 14 Apr 2000 19:59:30 +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 TAA27709; Fri, 14 Apr 2000 19:59:33 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA26399; Fri, 14 Apr 2000 19:59:33 +0200 (METDST) From: Martin Rex Message-Id: <200004141759.TAA26399@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: jaltman@columbia.edu Date: Fri, 14 Apr 2000 19:59:32 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 14, 0 12:47:09 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: > > > My oberservations of hostbased service names are: > > - they are INSECURE how rfc2743 defines them and the way they have > > been implemented in MIT Kerberos 5. > > I'm not sure what you are saying here. Is this supposed to mean that > because Kerberos 5 uses hostnames in Kerberos principals that Kerberos > 5 is insecure? > > Or just the GSSAPI implementation? > > And in what way is it insecure? (Most of) the Kerberos guys are well aware of the issues. Traditionally, all you give to your kerberized telnet is the hostname. Telnet will looks up the IP-addr via DNS and composes the hostbased service name as "host@given-hostname" and pass it to Kerberos, where it is processed according to the rules for hostbased service names, where the hostname part is canonicalized via DNS. If the DNS lookups that telnet performs can be spoofed (which is possible in most installations today), an attacker can redirect the actual TCP connect to a host of his choice, and he can have you authenticate to the principal of any machine in any of the trusted realms, and given a large installation there is probably a machine where he can break in and get access to the host principal's key. > > > There is a popular telnet replacement called SSH which does just that. > > It eases the use by caching the identities (which are public keys in SSH) > > under the alias of the hostname. You know that if you don't verify > > "authenticate" a host key (by transfering them out-of-band or comparing > > fingerprints), then you're taking a risk. > > I think it would be a good idea for apps such as telnet to use a similar > > scheme when adding security. SSH's use of the hostname as the lookup > > key doesn't scale with firewall traversal, however. Re-use of the > > host key in a server farm should work, however. > > SSH in particular is insecure because it does rely on the caching > of public keys under the host name alias on insecure client operating > systems and file systems. > > SSH is even worse in that is relies on an insecure client operating > system and/or file systems to protect end user private keys. > > I would not use SSH as an example upon which to recommend secure > protocols be based. Come on. This applies to all software, be it SSH or Kerberos or something else. If you can not trust the machine, there is no software which you could add that would make it more trustworthy. -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 Fri Apr 14 16:42: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 QAA14235 for ; Fri, 14 Apr 2000 16:42:07 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA27012 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 13:11:43 -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 NAA27005 for ; Fri, 14 Apr 2000 13:11:41 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA28697; Fri, 14 Apr 00 16:13:32 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id QAA23958; Fri, 14 Apr 2000 16:11:38 -0400 (EDT) Message-Id: <200004142011.QAA23958@small-gods.mit.edu> To: jaltman@columbia.edu Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of "Fri, 14 Apr 2000 12:47:09 EDT." Date: Fri, 14 Apr 2000 16:11:38 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> There is a popular telnet replacement called SSH which does just >> that. It eases the use by caching the identities (which are public >> keys in SSH) under the alias of the hostname. > SSH in particular is insecure because it does rely on the caching of > public keys under the host name alias on insecure client operating > systems and file systems. At the risk of descending into a rathole: if you're not going to trust the client to safely store public keys, why are you going to trust the client to accurately relay keystrokes? And what does this have to do with SSH's practice of associating the identity with the alias? Kerberos would still work, with its current key management, if you required each alias to have its own service key (there are complications with the domain search, but that's an implementation convenience issue). -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Sat Apr 15 01:33:47 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 BAA23883 for ; Sat, 15 Apr 2000 01:33:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA24922 for ietf-cat-wg-out720680; Fri, 14 Apr 2000 21:56:38 -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 VAA24917 for ; Fri, 14 Apr 2000 21:56:36 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA09917; Sat, 15 Apr 00 00:58:28 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id AAA23288; Sat, 15 Apr 2000 00:56:33 -0400 (EDT) Date: Sat, 15 Apr 2000 0:56:33 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of Fri, 14 Apr 2000 19:59:32 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > (Most of) the Kerberos guys are well aware of the issues. > > Traditionally, all you give to your kerberized telnet is the hostname. > Telnet will looks up the IP-addr via DNS and composes the hostbased > service name as "host@given-hostname" and pass it to Kerberos, where > it is processed according to the rules for hostbased service names, > where the hostname part is canonicalized via DNS. If the DNS lookups > that telnet performs can be spoofed (which is possible in most > installations today), an attacker can redirect the actual > TCP connect to a host of his choice, and he can have you authenticate > to the principal of any machine in any of the trusted realms, > and given a large installation there is probably a machine where > he can break in and get access to the host principal's key. > This discussion was very recently had on this mailing list when we discussed the security weaknesses associated with the DNS Lookup draft. The problem you discuss is only if the telnet client performs a reverse DNS lookup on the IP address received from the initial hostname search. If the reverse lookup is not performed your attack is simply a denial of service. > > SSH is even worse in that is relies on an insecure client operating > > system and/or file systems to protect end user private keys. > > > > I would not use SSH as an example upon which to recommend secure > > protocols be based. > > > Come on. > > This applies to all software, be it SSH or Kerberos or something else. > If you can not trust the machine, there is no software which you could > add that would make it more trustworthy. The problem with SSH is that its data is good for all time. It does not timeout and become invalid. Windows machines are inherently insecure. The rate at which viruses are distributed as well as Back Orifice being found on machines is outrageous. To store private keys and public keys with a list of the machines to which those keys are valid is absolutely insane. Last week we had a virus discovered that distributes itself by searching out shares on nearby machines. What a great way to distribute back orifice. Then all that is needed is a series of probes to determine which machines have BO installed and use it to read the SSH files from said machine. Its a little harder to do this with a memory based cache storing Kerberos credentials that will expire and must be used in association with an IP address spoof. Plus once the SSH data is retrieved and a breakin is discovered there is no way for a sysadmin to know the scope of the damage. The password for the account can't be changed; the list of machines for which the private key is valid is not available; ... SSH with its public key authentication is a disaster waiting to happen. The only reason that I haven't written and published the software to take advantage of this hole is because the Columbia lawyers refuse to defend me when I get arrested and sent to jail for assisting some teenager that uses the code to breakin to hundreds of systems. Kerberos is not the only other method for secure authentication. SRP, one time pads, ... are also fine examples of more secure methods for insecure machines. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 16 03:53: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 DAA05675 for ; Sun, 16 Apr 2000 03:53:43 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id AAA27372 for ietf-cat-wg-out720680; Sun, 16 Apr 2000 00:22:21 -0700 (PDT) Received: from perq.cac.washington.edu (mg-206253202-46.ricochet.net [206.253.202.46]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id AAA27367 for ; Sun, 16 Apr 2000 00:22:14 -0700 (PDT) Received: from localhost (rlmorgan@localhost) by perq.cac.washington.edu (8.9.3/8.9.3) with ESMTP id AAA17595 for ; Sun, 16 Apr 2000 00:22:30 -0700 X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing -bs Date: Sun, 16 Apr 2000 00:22:29 -0700 (PDT) From: "RL 'Bob' Morgan" X-Sender: rlmorgan@perq.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: ietf-cat-wg@lists.Stanford.EDU Subject: the realm-name case issue Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Here's what I suggest regarding realm names and case. New language for kerberos-revisions is at the end. I really don't care about the case-insensitivity issues except to the extent that they are wrongly mixed up with the issue I do care about, which is not having my installation's realm name declared non-compliant. I think there are three separate (though related) design decisions: (1) What is the acceptable character set for DNS-based realm names? Possibilities include: upper-case only; all characters permitted in DNS host names (per RFC 952: a-zA-Z0-9-, "." only as element separator); or all characters supported in DNS labels in general (any data, only limited by length); or some other set. (2) If mixed case realm names are supported in (1), does the DNS-based configuration scheme (being defined in draft-ietf-cat-krb-dns-locate-*) have to support the use of distinct realms whose names match via a case-insensitive comparison (eg, "Example.Com" and "EXAMPLE.COM" as distinct realms)? Or, is it acceptable to say: setting up two or more realms whose names differ only by case produces undefined results, when using this configuration scheme? (3) Should there be support in client and server implementations, and in the protocol if necessary, for case-insensitive matching of realm names in all places where realm names are compared? These issues seem to get jumbled up in discussion (including in my own previous comments, I'll admit). I suggest that if issue (1) can be separated from the others it can be decided in a reasonable way while while we go on debating the UI issues in (3) till we're exhausted. Regarding (1), we know these things: (a) a fundamental constraint is that the realm name is used in the crypto, so to do a successful ticket request a client must know the case-exact realm name string; (b) RFC 1510 says that realm names are GeneralStrings, hence any character (except NUL), but conventions apply to particular uses, eg domain names; (c) the upper-case-only convention has been promoted by the MIT implementation for a long time, and most sites do that; (d) some (no one knows how many, but more than a handful) sites that use domain-name-based realms use lower- or mixed-case realm names; (e) kerberos-revisions-05 proposes to make the upper-case convention a MUST (section 7.1: "Domain names must be converted to upper case when used as realm names"). Now, what is the reasoning behind the proposed all-upper-case realm name rule? As far as I can tell it is this: (i) there are times when a client has to derive a realm name from a DNS name (eg to use a kerberized service on a host, or to construct an inter-realm path), because it has no explicit info mapping that DNS name to a realm name; (ii) in these cases the client needs to derive the exact (case-correct) realm name; (iii) so, this DNS-to-realm derivation must use a simple rule with a deterministic result, and convert-to-upper-case is the arbitrarily chosen simple rule; (iv) hence DNS-based realm names must always be upper case so that this rule will work. The MIT Kerb5 admin documentation says, regarding the domain_realm section of the krb5.conf file: The [domain_realm] section provides a translation from a domain name or hostname to a Kerberos realm name. The tag name can be a host name, or a domain name, where domain names are indicated by a prefix of a period (`.'). The value of the relation is the Kerberos realm name for that particular host or domain. Host names and domain names should be in lower case. If no translation entry applies, the host's realm is considered to be the hostname's domain portion converted to upper case. (I assume that equivalent configuration functionality is provided in other implementations.) Now if the client finds an applicable translation entry, it uses the realm name exactly as found there; so upper-, lower-, and mixed-case realm names can be used in this case. (Doing host->realm translation via DNS TXT record lookup also works fine with non-upper-case realms, as we have demonstrated here.) So in this, the normal case, non-upper-case realms present no problem at all. If there is no translation available, then the DNS name is converted to upper case as described. But what does the client *do* with the realm name that it has just derived? The only reason I can think of to do this derivation is to contact (ultimately, perhaps via intermediate KDCs) a KDC for the derived realm to obtain a service ticket. To do this, the client has to have configuration info available to it about that realm, in particular the realm's KDCs; and if there is configuration info available for the realm, that info includes (or should include) the case-exact spelling of the realm name. If the client is using the traditional config file to get KDC info, then obviously the exact realm name is there. If the client is using the dns-locate method to find KDCs, then there's no reason it can't use DNS to find the exact realm name spelling too (we'll have to define this, and we should). Any other realm-config-data method should do the same. So in the supposed cases where the converted-to-upper-case derived realm name is needed, it is in fact *not* needed, because either the proper name of the realm is available, or the realm is unknown and hence the derived name is useless. If someone can present a practical case where the derived realm name is actually useful, I would love to understand it. (Let me note here that there is IMHO an important difference between (a) the operation of mapping a DNS domain name -- which is inherently case-insensitive -- into a realm name, an operation that simply has to be done in some circumstances; and (b) the idea of handling purported realm name strings themselves (as typed in a kinit command, say, or found in an ACL entry) in a case-insensitive manner, which is an *optional* thing to do as a convenience to the user.) Now it may be the case that some sites are using krb5.conf files (or their equivalent) that do provide realm config info, but don't provide domain->realm mapping info, and hence rely on the current name-derivation scheme to generate realm names, which realm names would currently have to be all upper-case. This is fine (though a bit odd), but surely isn't any reason why *other* sites can't have non-upper-case realm names. I suggest that these sites would be better-served by using the dns-locate method to deliver the exact realm name to the client, or by a more flexible realm-name-derivation algorithm that takes the input domain name, searches case-insensitively for a match for it among the set of known realms, and uses the exact realm string if found; either of these would allow non-upper case realm names to work. (But I wouldn't force them to use these better methods, either.) It may be that another argument for the upper-case-only rule is more UI-oriented, namely that if users always see realm names in upper case, they'll be more likely to get them typed right; whereas if they see lower- and mixed-case realms too they'll think that realms are inherently case-insensitive and will be confused. I don't see that this argument has enough weight to make upper-case-only be a MUST. So, in the absence of evidence to the contrary, I conclude: that the upper-case convention, however venerable, is completely unnecessary (in fact it's bad if it makes client-writers assume that realm names will always be upper-case); that realms using upper-, lower-, and mixed-case are all equally acceptable; and that implementations should be encouraged to support all of them equally. I propose that language to this effect be added to kerberos-revisions in the section about domain-style realm names; possible language is below, also fixing other problems with the current language. Regarding design decision (2) above, I think it is reasonable to say that defining distinct realms that differ only by case is an unusual thing to do, so the dns-locate method doesn't need to support it by defining some awkward means to represent case-specific names. Arguments about (3), the case-insensitive handling of realm names in general, can proceed independently ... - RL "Bob" --- Proposed new language for section 7.1 of kerberos-revisions: domain: ATHENA.MIT.EDU (example) X500: C=US/O=OSF (example) other: NAMETYPE:rest/of.name=without-restrictions (example) reserved: reserved, but will not conflict with above Domain-name-style realm names are based on the string form of DNS names [Moc87]. They consist of components separated by dots ("."). A component may not contain a dot, a colon (":") or a slash ("/"). Names may contain upper-case or lower-case letters, but defining distinct domain-name-style realm names that differ only by case (e.g., "Example.Com" and "EXAMPLE.COM") may produce undefined results. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 17 04:20:29 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 EAA27501 for ; Mon, 17 Apr 2000 04:20:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id AAA03132 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 00:37:42 -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 AAA03127 for ; Mon, 17 Apr 2000 00:37:39 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA07393; Mon, 17 Apr 00 03:37:33 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id JAA01721; Mon, 17 Apr 2000 09:34:36 +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 JAA27910; Mon, 17 Apr 2000 09:32:42 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id JAA12514; Mon, 17 Apr 2000 09:32:41 +0200 (METDST) From: Martin Rex Message-Id: <200004170732.JAA12514@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: jaltman@columbia.edu Date: Mon, 17 Apr 2000 09:32:41 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 15, 0 00:56:33 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 Jeffrey Altman wrote: > > > (Most of) the Kerberos guys are well aware of the issues. > > > > Traditionally, all you give to your kerberized telnet is the hostname. > > Telnet will looks up the IP-addr via DNS and composes the hostbased > > service name as "host@given-hostname" and pass it to Kerberos, where > > it is processed according to the rules for hostbased service names, > > where the hostname part is canonicalized via DNS. If the DNS lookups > > that telnet performs can be spoofed (which is possible in most > > installations today), an attacker can redirect the actual > > TCP connect to a host of his choice, and he can have you authenticate > > to the principal of any machine in any of the trusted realms, > > and given a large installation there is probably a machine where > > he can break in and get access to the host principal's key. > > > > This discussion was very recently had on this mailing list when we > discussed the security weaknesses associated with the DNS Lookup > draft. The problem you discuss is only if the telnet client performs > a reverse DNS lookup on the IP address received from the initial > hostname search. > > If the reverse lookup is not performed your attack is simply a denial > of service. Maybe you thinking of a different problem? The problem I'm talking of if with any regular use and gives you at least target impersonation. And if the victim had delegation of credentials enabled, you can not only get access to these credentials, you could also do a man in the middle attack (instead of trying to impersonate the real target) and wait for other secret information being disclosed during the session. All this with spoofing the forward DNS resolution that will *always* be performed if the target is specified by hostname. Scenarios like "SecureCRT" with Kerberos-GSSAPI are probably at risk. I don't know about the traditional kerberized telnet, but my assumption is, that the spec for *forward* transformation of the hostbased service name into a Kerberos principal name was adopted from Kerberos. > > > > SSH is even worse in that is relies on an insecure client operating > > > system and/or file systems to protect end user private keys. > > > > > > I would not use SSH as an example upon which to recommend secure > > > protocols be based. > > > > > > Come on. > > > > This applies to all software, be it SSH or Kerberos or something else. > > If you can not trust the machine, there is no software which you could > > add that would make it more trustworthy. > > The problem with SSH is that its data is good for all time. It does > not timeout and become invalid. Windows machines are inherently > insecure. The rate at which viruses are distributed as well as Back > Orifice being found on machines is outrageous. To store private keys > and public keys with a list of the machines to which those keys are > valid is absolutely insane. Welcome to the world of Single Break-In^H^H^H^H^H^H^H^HSign-On. I'm sorry, but I don't buy your arguments. On insecure machines you cannot add security by adding software. Adding single sign-on to vulnerable machines will make it easier for intruders to compromise more machines after initial break-in. It doesn't matter whether the single sign-on is based on Kerberos, SSH or any other software. Requiring Hardware tokens (i.e. SmartCards) for each and every authentication will help you, but it will also restrict the features available from the single sign-on and it may significantly impact the throughput of distributed software. > > Last week we had a virus discovered that distributes itself by > searching out shares on nearby machines. What a great way to > distribute back orifice. Then all that is needed is a series of > probes to determine which machines have BO installed and use it to > read the SSH files from said machine. > > Its a little harder to do this with a memory based cache storing > Kerberos credentials that will expire and must be used in association > with an IP address spoof. Welcome to Windows 2000 Kerberos -- caching your password and providing automatic ticket refresh. > > Plus once the SSH data is retrieved and a breakin is discovered there > is no way for a sysadmin to know the scope of the damage. The > password for the account can't be changed; the list of machines for > which the private key is valid is not available; ... > > SSH with its public key authentication is a disaster waiting to > happen. The only reason that I haven't written and published the > software to take advantage of this hole is because the Columbia > lawyers refuse to defend me when I get arrested and sent to jail for > assisting some teenager that uses the code to breakin to hundreds of > systems. Supply and use SSH with a PKI that supports certificate revocation and you can invalidate the credentials. SSH is a protocol, not just a particular implementation. No one forces you to use a tool that is inadequate for your environments. I'm using SSH on my windows Machine, and I don't feel bad about it. But I also browse the internet with a HTML-only browser, use a plain-ASCII Email reader, ignoring all non-ASCII Mime-Attachments that are sent to me. -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 Mon Apr 17 07:20:25 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 HAA29056 for ; Mon, 17 Apr 2000 07:20:24 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA07850 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 03:53:16 -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 DAA07845 for ; Mon, 17 Apr 2000 03:53:11 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA06009; Mon, 17 Apr 00 06:55:04 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id GAA18594; Mon, 17 Apr 2000 06:53:06 -0400 (EDT) Date: Mon, 17 Apr 2000 6:53:05 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of Mon, 17 Apr 2000 09:32:41 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Maybe you thinking of a different problem? > > The problem I'm talking of if with any regular use and gives > you at least target impersonation. And if the victim had delegation of > credentials enabled, you can not only get access to these credentials, > you could also do a man in the middle attack (instead of trying to > impersonate the real target) and wait for other secret information > being disclosed during the session. > All this with spoofing the forward DNS resolution that will *always* > be performed if the target is specified by hostname. > > Scenarios like "SecureCRT" with Kerberos-GSSAPI are probably at risk. > I don't know about the traditional kerberized telnet, but my assumption > is, that the spec for *forward* transformation of the hostbased service > name into a Kerberos principal name was adopted from Kerberos. I would really like to understand this attack. But somehow I am failing to. Here is my scenario, you please explain how the attack is performed. . client retreives a forwardable TGT . client decides to telnet to foo.bar.edu. telnet client performs forward DNS to retrieve ip address for said host. (The IP address is spoofed and attacker's compromised machine, y.y.y.y, is provided instead.) . client retrieves service ticket for host/foo.bar.edu@REALM . client performs mutual auth with y.y.y.y using ticket host/foo.bar.edu@REALM. Authentication fails. This is a denial of service attack, not a successful attack. As for the man in the middle attacks. Even if I connect from A to B and then to C, no *sensitive data* or forwarded credentials should be sent until after I have succeeded in the mutual authentication AND successfully encrypted the channel in both directions. How is the person at B going to read anything I send or receive? Clearly, if you send a forwardable credential to an unauthenticated host or send it over an unencrypted channel you have problems. Same if you base the construction of your service ticket request upon data stored in the DNS. Somehow I get the feeling you are referring to the use of one-way authentication and insecure applications; not a weakness inherent in the protocol. If I am wrong, please explain it to me. If these holes are as obvious as you seem to make them out to be then I am making some bad assumptions about how to secure my infrastructure. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 17 09:45: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 JAA02671 for ; Mon, 17 Apr 2000 09:45:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA09275 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 06:17: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 GAA09270 for ; Mon, 17 Apr 2000 06:17:30 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA08941; Mon, 17 Apr 00 09:17:24 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id PAA15448; Mon, 17 Apr 2000 15:14:35 +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 PAA11380; Mon, 17 Apr 2000 15:14:22 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id PAA14605; Mon, 17 Apr 2000 15:14:22 +0200 (METDST) From: Martin Rex Message-Id: <200004171314.PAA14605@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: jaltman@columbia.edu Date: Mon, 17 Apr 2000 15:14:21 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 17, 0 06:53:05 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 Jeffrey Altman wrote: > > > Maybe you thinking of a different problem? > > > > The problem I'm talking of if with any regular use and gives > > you at least target impersonation. And if the victim had delegation of > > credentials enabled, you can not only get access to these credentials, > > you could also do a man in the middle attack (instead of trying to > > impersonate the real target) and wait for other secret information > > being disclosed during the session. > > All this with spoofing the forward DNS resolution that will *always* > > be performed if the target is specified by hostname. > > > > Scenarios like "SecureCRT" with Kerberos-GSSAPI are probably at risk. > > I don't know about the traditional kerberized telnet, but my assumption > > is, that the spec for *forward* transformation of the hostbased service > > name into a Kerberos principal name was adopted from Kerberos. > > I would really like to understand this attack. But somehow I am > failing to. Here is my scenario, you please explain how the attack is > performed. > > . client retreives a forwardable TGT > > . client decides to telnet to foo.bar.edu. telnet client performs > forward DNS to retrieve ip address for said host. (The IP > address is spoofed and attacker's compromised machine, > y.y.y.y, is provided instead.) > > . client retrieves service ticket for host/foo.bar.edu@REALM Wrong. The client passes either "telnet@foo.bar.edu" or "host@foo.bar.edu" as a "hostbased service name to Kerberos (via or without GSS-API", and the transformation into a Kerberos principal name canonicalizes the hostname via DNS. That's what rfc2743, Section 4.1 specifies and what MIT Kerberos 5 has been doing all the time. Therefore your client is going to acquire a service ticket to host/attackers.host.of.choice@ANY-TRUSTED-REALM and perform a successful mutual authentication with the attackers host of choice. Man in the middle attack is possible when client uses credential forwarding. -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 Mon Apr 17 20:43: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 UAA12108 for ; Mon, 17 Apr 2000 20:43:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA17124 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 16:53:51 -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 QAA17117 for ; Mon, 17 Apr 2000 16:53:47 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA19392; Mon, 17 Apr 00 19:53:40 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id TAA15059; Mon, 17 Apr 2000 19:53:43 -0400 (EDT) Date: Mon, 17 Apr 2000 19:53:43 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of Mon, 17 Apr 2000 15:14:21 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Wrong. > > The client passes either "telnet@foo.bar.edu" or "host@foo.bar.edu" > as a "hostbased service name to Kerberos (via or without GSS-API", > and the transformation into a Kerberos principal name canonicalizes > the hostname via DNS. That's what rfc2743, Section 4.1 specifies > and what MIT Kerberos 5 has been doing all the time. > > Therefore your client is going to acquire a service ticket to > > host/attackers.host.of.choice@ANY-TRUSTED-REALM > > and perform a successful mutual authentication with the attackers > host of choice. > Question: This makes no sense. What you are telling me is that my providing a fully qualified domain name to Kerberos 5 is meaningless because not only is Kerberos 5 going to perform a Forward DNS lookup (which will not cause a name change) but that it is also going to perform a Reverse DNS lookup which will cause a name change? I find this very hard to believe. When I get some time later tonight or tomorrow I will setup my Network Monitor and debugger and trace all of the DNS calls being made by MIT Kerberos 5 during the acquisition of a service ticket. If this is what is being done it is absurd. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 00:46:52 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 AAA16589 for ; Tue, 18 Apr 2000 00:46:51 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA01472 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 21:15: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 VAA01467 for ; Mon, 17 Apr 2000 21:14:57 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA25373; Tue, 18 Apr 00 00:16:51 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id AAA14770; Tue, 18 Apr 2000 00:14:54 -0400 (EDT) Message-Id: <200004180414.AAA14770@small-gods.mit.edu> To: jaltman@columbia.edu Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of "Mon, 17 Apr 2000 19:53:43 EDT." Date: Tue, 18 Apr 2000 00:14:54 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> The client passes either "telnet@foo.bar.edu" or "host@foo.bar.edu" >> as a "hostbased service name to Kerberos (via or without GSS-API", >> and the transformation into a Kerberos principal name canonicalizes >> the hostname via DNS. > This makes no sense. What you are telling me is that my providing a > fully qualified domain name to Kerberos 5 is meaningless because not > only is Kerberos 5 going to perform a Forward DNS lookup (which will > not cause a name change) but that it is also going to perform a > Reverse DNS lookup which will cause a name change? It only takes a forward lookup to canonicalize a hostname, at least in the sense of "follow cnames to the domain they point to". (If there are multiple A records with the same IP address, then it will take a PTR lookup to fine out which name(s) have PTR records, which I suppose someone might think of as "canonicalizing.") For instance, if I do a recursive query for hodge.mit.edu in a, I get answers like: hodge.mit.edu. 6H IN CNAME HODGE-PODGE.MIT.EDU. HODGE-PODGE.MIT.EDU. 6H IN A 18.187.1.128 And the resolver will store the name HODGE-PODGE.MIT.EDU into h_name. Kerberos implementations have sometimes performed an additional PTR lookup, I think to work around broken (or at least Different) Sun resolvers. But it's certainly not necessary from a protocol point of view. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 02:08: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 CAA28396 for ; Tue, 18 Apr 2000 02:08:53 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id WAA04346 for ietf-cat-wg-out720680; Mon, 17 Apr 2000 22:23: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 WAA04341 for ; Mon, 17 Apr 2000 22:23:07 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA18535; Tue, 18 Apr 00 01:23:00 EDT Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id BAA01497; Tue, 18 Apr 2000 01:23:05 -0400 (EDT) To: jaltman@columbia.edu Cc: mrex@sap-ag.de, cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: Mime-Version: 1.0 From: Ken Raeburn Date: 18 Apr 2000 01:23:05 -0400 In-Reply-To: Jeffrey Altman's message of "Mon, 17 Apr 2000 19:53:43 EDT" Message-Id: Lines: 66 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Martin Rex wrote: > > Wrong. > > > > The client passes either "telnet@foo.bar.edu" or "host@foo.bar.edu" > > as a "hostbased service name to Kerberos (via or without GSS-API", > > and the transformation into a Kerberos principal name canonicalizes > > the hostname via DNS. That's what rfc2743, Section 4.1 specifies > > and what MIT Kerberos 5 has been doing all the time. The RFC says: When a reference to a name of this type is resolved, the "hostname" may (as an example implementation strategy) be canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters. What the MIT code does is a little different, because we've found that Certain Vendors didn't give us any easy way to get the canonical name without doing the reverse lookup. Now, though, we've got code that calls the resolver directly (for SRV records), so maybe it wouldn't be so hideous to add a little more, to look up CNAME records and skip the PTR records. As I read this, though, it is not *required* that the canonicalization be done at all. In fact, the appendix "CHANGES RELATIVE TO RFC-2078" says in part: Name-related: Downgraded reference to name canonicalization via DNS lookup to an example. Jeffrey Altman responded: > This makes no sense. What you are telling me is that my providing > a fully qualified domain name to Kerberos 5 is meaningless because not > only is Kerberos 5 going to perform a Forward DNS lookup (which will > not cause a name change) but that it is also going to perform a > Reverse DNS lookup which will cause a name change? Merely getting an FQDN doesn't ensure that it's the canonical name. For example, "kermit.columbia.edu" is an FQDN, but the name that we use for Kerberos is watsun.cc.columbia.edu. Similarly, the convenience alias "prep.cygnus.com" is not the canonical name, "prep.ai.mit.edu" is. Actually, prep.cygnus.com has a CNAME record, pointing to prep.ai.mit.edu which has an A record, but the PTR record for the address points back to gnudist.gnu.org. So in one sense prep.ai.mit.edu is the canonical name, but gnudist.gnu.org might also be considered the "real" name. (This gets us into issues regarding multihomed hosts with different "primary" names for different interfaces; people with personal domains listing A records for home systems where the ISP rigidly controls the PTR records with no customization options; server clusters with a common name mapping to multiple IP addresses, each of which has a different PTR record; etc.) Doing away with all canonicalization of FQDNs means that either (a) a service would have to be aware of and have keys for every convenience alias the host has, even in other domains outside the control of the maintainers of the host or service, (b) we have to change names somewhere else, such as through canonicalizing principal names or using secure DNS, or (c) the user of such aliases just loses. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 06:46:53 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 GAA00120 for ; Tue, 18 Apr 2000 06:46:52 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA15209 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 03:08:00 -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 DAA15204 for ; Tue, 18 Apr 2000 03:07:57 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA19557; Tue, 18 Apr 00 06:07:49 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id MAA02395; Tue, 18 Apr 2000 12:05:01 +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 MAA23659; Tue, 18 Apr 2000 12:05:31 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id MAA20608; Tue, 18 Apr 2000 12:05:31 +0200 (METDST) From: Martin Rex Message-Id: <200004181005.MAA20608@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: jaltman@columbia.edu Date: Tue, 18 Apr 2000 12:05:31 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 17, 0 07:53:43 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: > > > Wrong. > > > > The client passes either "telnet@foo.bar.edu" or "host@foo.bar.edu" > > as a "hostbased service name to Kerberos (via or without GSS-API", > > and the transformation into a Kerberos principal name canonicalizes > > the hostname via DNS. That's what rfc2743, Section 4.1 specifies > > and what MIT Kerberos 5 has been doing all the time. > > > > Therefore your client is going to acquire a service ticket to > > > > host/attackers.host.of.choice@ANY-TRUSTED-REALM > > > > and perform a successful mutual authentication with the attackers > > host of choice. > > > > Question: > > This makes no sense. What you are telling me is that my providing > a fully qualified domain name to Kerberos 5 is meaningless because not > only is Kerberos 5 going to perform a Forward DNS lookup (which will > not cause a name change) but that it is also going to perform a > Reverse DNS lookup which will cause a name change? Kerberos 5 is going to do a forward DNS lookup, whether or not the name that you supply is fully qualified or lacking the domain name. The spec requires that if DNS claims the supplied name to be a CNAME then it must be replaced by the canonical name that the CNAME record points to. This is what the spec means by "canonicalization", and it will happen with regular forward DNS lookup. Now if you spoof the Kerberos DNS lookup and give it a CNAME when it canonicalizes the hostbased service name, you can have this name replaced. Am I really so bad at explaining the issue? :-( -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 Apr 18 09:25: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 JAA04074 for ; Tue, 18 Apr 2000 09:25:25 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA17308 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 05:52: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 FAA17303 for ; Tue, 18 Apr 2000 05:52:31 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA13213; Tue, 18 Apr 00 08:52:24 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA17456; Tue, 18 Apr 2000 08:52:29 -0400 (EDT) Date: Tue, 18 Apr 2000 8:52:28 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ken Raeburn Cc: mrex@sap-ag.de, cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of 18 Apr 2000 01:23:05 -0400 Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Raeburn wrote: > > Doing away with all canonicalization of FQDNs means that either (a) a > service would have to be aware of and have keys for every convenience > alias the host has, even in other domains outside the control of the > maintainers of the host or service, (b) we have to change names > somewhere else, such as through canonicalizing principal names or > using secure DNS, or (c) the user of such aliases just loses. Isn't (a) what Win2000 requires now? Isn't (b) what the Microsoft folk are proposing be done by the KDC? Now I am beginning to understand and appreciate why Microsoft would like these translations to be done by the KDC. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 11:12: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 LAA05963 for ; Tue, 18 Apr 2000 11:12:35 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA20526 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 07:36:57 -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 HAA20521 for ; Tue, 18 Apr 2000 07:36:54 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA17211; Tue, 18 Apr 00 10:36:47 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id KAA17186; Tue, 18 Apr 2000 10:36:51 -0400 (EDT) Message-Id: <200004181436.KAA17186@small-gods.mit.edu> To: jaltman@columbia.edu Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of "Tue, 18 Apr 2000 08:52:28 EDT." Date: Tue, 18 Apr 2000 10:36:50 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Now I am beginning to understand and appreciate why Microsoft would > like these translations to be done by the KDC. I understood their argument from the get go, but it doesn't seem like the KDC is in a good position to canonicalize service names either. What Microsoft's proposal lets you do is effectively centralize static configuration within a Kerberos site; that's somewhat orthogonal to taking advantage of the nice, federated (but insecure) DNS namespace for service canonicalization and realm mappings. Even if we accept the general idea of Microsoft's proposal, it's not clear to me why service name canonicalization should be a KDC function rather than a potentially separate Kerberos service. > Doing away with all canonicalization of FQDNs means that either (a) a > service would have to be aware of and have keys for every convenience > alias the host has, even in other domains outside the control of the > maintainers of the host or service, I'm not unhappy with (a) for service name canonicalization. (Well, in combination with (c): the user of an alias loses if the service doesn't have a key for a given alias.) But it doesn't help much at all for realm mapping. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 12:18: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 MAA07374 for ; Tue, 18 Apr 2000 12:18:07 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA24180 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 08:45:25 -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 IAA24170 for ; Tue, 18 Apr 2000 08:45:21 -0700 (PDT) Received: from [131.107.88.59] by MIT.EDU with SMTP id AA14115; Tue, 18 Apr 00 11:45:11 EDT Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Apr 2000 08:34:08 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Apr 2000 08:34:08 -0700 Message-Id: <19398D273324D3118A2B0008C7E9A5690716FA8C@SIT.platinum.corp.microsoft.com> From: John Brezak To: "'jaltman@columbia.edu'" , Ken Raeburn Cc: mrex@sap-ag.de, cat-ietf@mit.edu Subject: RE: comments on kerberos-revisions-05.txt Date: Tue, 18 Apr 2000 08:34:06 -0700 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk below > -----Original Message----- > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > Sent: Tuesday, April 18, 2000 5:52 AM > To: Ken Raeburn > Cc: mrex@sap-ag.de; cat-ietf@mit.edu > Subject: Re: comments on kerberos-revisions-05.txt > > > Ken Raeburn wrote: > > > > Doing away with all canonicalization of FQDNs means that > either (a) a > > service would have to be aware of and have keys for every > convenience > > alias the host has, even in other domains outside the control of the > > maintainers of the host or service, (b) we have to change names > > somewhere else, such as through canonicalizing principal names or > > using secure DNS, or (c) the user of such aliases just loses. > > Isn't (a) what Win2000 requires now? No. Name-canonicalization provides a mechanism that allows a principal to be known by many identities, but translated to a single name. The client knows the principal by many names, but the server is aware of only its canonical name. The server would only need one key because it has only one real name. This is documented in the Kerberos referrals I-D - http://www.ietf.org/internet-drafts/draft-swift-win2k-krb-referrals-00.txt > > Isn't (b) what the Microsoft folk are proposing be done by the KDC? The Microsoft proposal doesn't use DNS. It requires a database that provides this information to the KDC. In the Windows 2000 implementation this is provided by Active Directory. > > Now I am beginning to understand and appreciate why Microsoft would > like these translations to be done by the KDC. > > > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for > Win32 and OS/2 > The Kermit Project * Columbia University > 612 West 115th St #716 * New York, NY * 10025 > http://www.kermit-project.org/k95.html * > kermit-support@kermit-project.org > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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 Tue Apr 18 12:20: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 MAA07414 for ; Tue, 18 Apr 2000 12:20:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA24312 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 08:47:52 -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 IAA24307 for ; Tue, 18 Apr 2000 08:47:48 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA15140; Tue, 18 Apr 00 11:47:41 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id RAA27802; Tue, 18 Apr 2000 17:44:44 +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 RAA07338; Tue, 18 Apr 2000 17:46:15 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id RAA22393; Tue, 18 Apr 2000 17:46:15 +0200 (METDST) From: Martin Rex Message-Id: <200004181546.RAA22393@hw1464.wdf.sap-ag.de> Subject: Re: comments on kerberos-revisions-05.txt To: jaltman@columbia.edu Date: Tue, 18 Apr 2000 17:46:15 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 18, 0 08:52:28 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 Jeffrey Altman wrote: > > Ken Raeburn wrote: > > > > Doing away with all canonicalization of FQDNs means that either (a) a > > service would have to be aware of and have keys for every convenience > > alias the host has, even in other domains outside the control of the > > maintainers of the host or service, (b) we have to change names > > somewhere else, such as through canonicalizing principal names or > > using secure DNS, or (c) the user of such aliases just loses. > > Isn't (a) what Win2000 requires now? I have the impression that Microsoft implemented the reverse of (a), at least for w2k beta 3. I haven't checked recently. The service will retrieve the cleartext realm and sname from the ticket inside the AP_REQ and use the password of the service to create a key which will then be used to unwrap the ticket. This means that every w2k service will "brute force" all tickets that are sent to him with his own password. I don't know whether it at least verifies the realm to match it's own. What lead me to this assumtion: I created *two* user accounts: test1 and test2 and entered the same password for both. Then I requested context establishment with test1, but exchanged the tokens with a server running under user test2. The server successfully established the security context and passed the name-based authentication. I didn't try whether "impersonation" and "delegation" also work. Since you can not supply a "random" password to a service in w2k, and human admins are bad random password generators, the probability of the same password for independent services is much higher than what it could be -- does this permit session replay on a different target?). > > Isn't (b) what the Microsoft folk are proposing be done by the KDC? > > Now I am beginning to understand and appreciate why Microsoft would > like these translations to be done by the KDC. A translation on the KDC would probably be a good secure solution for the majority of the users. However roaming users or visitors may not want to blindly trust a foreign KDCs translation and realm mapping for all hosts. I also think that using Secure DNS will not ultimately solve our problem. In the IETF we need to specify solutions that scale to the whole internet. Maybe you are sure about the ownership of your own domain, but as I mentioned in previous Emails, DNS domain allocation is done on a first-come first-served basis and domains are sold or transfered over trademark disputes, so won't be anything like a "secure domain allocation". And the big companies have a clear advantage over all the small businesses. I really think it would be a bad idea to algorithmically derive trust from the DNS namespace. -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 Apr 18 20:01: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 UAA14759 for ; Tue, 18 Apr 2000 20:01:51 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA08009 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 16:20:40 -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 QAA08003 for ; Tue, 18 Apr 2000 16:20:37 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA16020; Tue, 18 Apr 00 19:22:31 EDT Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id TAA01771; Tue, 18 Apr 2000 19:20:35 -0400 (EDT) To: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <200004181436.KAA17186@small-gods.mit.edu> Mime-Version: 1.0 From: Ken Raeburn Date: 18 Apr 2000 19:20:35 -0400 In-Reply-To: Greg Hudson's message of "Tue, 18 Apr 2000 10:36:50 -0400" Message-Id: Lines: 33 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Greg Hudson writes: > Even if we accept the general idea of Microsoft's proposal, it's not > clear to me why service name canonicalization should be a KDC function > rather than a potentially separate Kerberos service. That's my main argument against it. I don't see a need for introducing "principal name aliases" into the Kerberos world, and I think that's basically what they're proposing. > > Doing away with all canonicalization of FQDNs means that either (a) a > > service would have to be aware of and have keys for every convenience > > alias the host has, even in other domains outside the control of the > > maintainers of the host or service, > > I'm not unhappy with (a) for service name canonicalization. (Well, in > combination with (c): the user of an alias loses if the service > doesn't have a key for a given alias.) But it doesn't help much at > all for realm mapping. My guess is lots of people would disagree with you. For one thing, cross-domain convenience aliases would be useless. ("Hi, could you please add this Kerberos host key to machine foo, we've got a DNS alias we'd like to use to reach it.") For another, what used to be a minor tweak to the zone file that the host wouldn't care about would instead involve KDC updates and sysadmin work on the host itself. In an environment like MIT's where for paranoia's sake we keep the KDC separate from everything else and limit admin access to it, that would make adding an alias an even bigger pain. But that's just my opinion, I could be wrong. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 18 20:47: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 UAA15184 for ; Tue, 18 Apr 2000 20:47:32 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA12282 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 17:15:40 -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 RAA12277 for ; Tue, 18 Apr 2000 17:15:37 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA27074; Tue, 18 Apr 00 20:17:32 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id UAA20729; Tue, 18 Apr 2000 20:15:36 -0400 (EDT) Message-Id: <200004190015.UAA20729@small-gods.mit.edu> To: Ken Raeburn Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of "18 Apr 2000 19:20:35 EDT." Date: Tue, 18 Apr 2000 20:15:36 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > For one thing, cross-domain convenience aliases would be useless. Granted. (Although cross-domain aliases would also be of limited use in a world with Kerberos-based hostname canonicalization, since people will be dependent on their local Kerberos realm for mappings.) > For another, what used to be a minor tweak to the zone file that the > host wouldn't care about would instead involve KDC updates and > sysadmin work on the host itself. In an environment like MIT's > where for paranoia's sake we keep the KDC separate from everything > else and limit admin access to it, that would make adding an alias > an even bigger pain. This argument is partially overblown. MIT is fooling itself it it thinks it can be paranoid about the KDC and not paranoid about the naming of host-based services. The security of a system is only as strong as its weakest aspect, and the security of host-based services at MIT will not be any stronger than the security of whatever system maps hostnames to keys. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 19 01:12: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 BAA20159 for ; Wed, 19 Apr 2000 01:12:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA27743 for ietf-cat-wg-out720680; Tue, 18 Apr 2000 21:31:28 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA27732 for ; Tue, 18 Apr 2000 21:31:25 -0700 (PDT) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA08533; Tue, 18 Apr 2000 21:31:24 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id VAA10992; Tue, 18 Apr 2000 21:31:23 -0700 (PDT) Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT) Message-Id: <200004190431.VAA10992@cayman-islands.isi.edu> From: Clifford Neuman To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Ticket extensions in Kerberos revisions Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk 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 Wed Apr 19 17:16:12 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 RAA14573 for ; Wed, 19 Apr 2000 17:16:11 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA17900 for ietf-cat-wg-out720680; Wed, 19 Apr 2000 13:43:25 -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 NAA17895 for ; Wed, 19 Apr 2000 13:43:22 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA27175; Wed, 19 Apr 00 16:45:17 EDT Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id QAA21285; Wed, 19 Apr 2000 16:43:21 -0400 (EDT) To: Greg Hudson Cc: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt References: <200004190015.UAA20729@small-gods.mit.edu> Mime-Version: 1.0 From: Ken Raeburn Date: 19 Apr 2000 16:43:20 -0400 In-Reply-To: Greg Hudson's message of "Tue, 18 Apr 2000 20:15:36 -0400" Message-Id: Lines: 25 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Greg Hudson writes: > > For one thing, cross-domain convenience aliases would be useless. > > Granted. (Although cross-domain aliases would also be of limited use > in a world with Kerberos-based hostname canonicalization, since people > will be dependent on their local Kerberos realm for mappings.) Normally I'd expect the cross-domain aliases to be used by people at the place where the admins have defined those aliases. For example, prep.cygnus.com is there for the convenience of Cygnus employees. So if they have authenticated access to cygnus.com domain info, they can securely find out that the CNAME record refers to prep.ai.mit.edu. > >[...host alias changes would require kdc & system admin changes...] > This argument is partially overblown. MIT is fooling itself it it > thinks it can be paranoid about the KDC and not paranoid about the > naming of host-based services. The security of a system is only as > strong as its weakest aspect, and the security of host-based services > at MIT will not be any stronger than the security of whatever system > maps hostnames to keys. Agreed, and this isn't the only way DNS introduces vulnerabilities into our environment, but I don't think that's an argument for tighter integration of Kerberos and (a subset of) name service. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 19 21:39: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 VAA17313 for ; Wed, 19 Apr 2000 21:39:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA09223 for ietf-cat-wg-out720680; Wed, 19 Apr 2000 18:02:40 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA09211 for ; Wed, 19 Apr 2000 18:02:35 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 66A0A75B; Wed, 19 Apr 2000 18:02:34 -0700 (PDT) Received: by mail-proxy-2.amazon.com id SAA11646; Wed, 19 Apr 2000 18:02:34 -0700 (PDT) Message-ID: <38FE5750.BEEED3E0@amazon.com> Date: Wed, 19 Apr 2000 18:03:12 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Cc: krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <200004190431.VAA10992@cayman-islands.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I think the cows have already left the barn, so to speak, with regard to proprietary extensions! I can't imagine a scenario where ticket extensions would do any more harm to interoperability than has already been done with other things that are here to stay, say like proprietary authz-data or etypes based on patented-protected cryptographic algorithms. If anyone thinks I'm wrong, feel free to straighten me out. So speaking as a user, other than earlier krb implementations' ASN.1 code puking on the extra member in the sequence, I wouldn't have any objections to the ticket extension field. It would be great to get this nailed down and see working PK-CROSS implementations at some point. If anyone has a concrete example of an older implementation that croaks on ticket extensions, please share it. Dave 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 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 20 07:21: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 HAA06365 for ; Thu, 20 Apr 2000 07:21:20 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA02552 for ietf-cat-wg-out720680; Thu, 20 Apr 2000 03:43:15 -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 DAA02547 for ; Thu, 20 Apr 2000 03:43:11 -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 GAA05403; Thu, 20 Apr 2000 06:43:07 -0400 (EDT) Message-Id: <200004201043.GAA05403@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-set-passwd-03.txt Date: Thu, 20 Apr 2000 06:43:07 -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 : Kerberos Set/Change Password: Version 2 Author(s) : M. Swift, J. Trostle, J. Brezak, B. Gossman Filename : draft-ietf-cat-kerberos-set-passwd-03.txt Pages : 6 Date : 19-Apr-00 The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), does not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal extends [4] to allow password setting. The changes are: adding new fields to the request message to indicate the principal which is having its password set, not requiring the initial flag in the service ticket, using a new protocol version number, and adding three new result codes. We also extend the set/change protocol to allow a client to send a sequence of keys to the KDC instead of a cleartext password. If in the cleartext password case, the cleartext password fails to satisfy password policy, the server should use the result code KRB5_KPASSWD_POLICY_REJECT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.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-kerberos-set-passwd-03.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-kerberos-set-passwd-03.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: <20000419115740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-set-passwd-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000419115740.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 Apr 20 13:05:47 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 NAA16210 for ; Thu, 20 Apr 2000 13:05:46 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA09842 for ietf-cat-wg-out720680; Thu, 20 Apr 2000 09:40:04 -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 JAA09825 for ; Thu, 20 Apr 2000 09:40:00 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA27584; Thu, 20 Apr 00 12:39:51 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04663 for ; Thu, 20 Apr 2000 09:39:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA24437 for ; Thu, 20 Apr 2000 09:39:57 -0700 (PDT) Received: from teal (awe8-109.Central.Sun.COM [129.147.8.109]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3KGdth294615 for ; Thu, 20 Apr 2000 09:39:55 -0700 (PDT) Date: Thu, 20 Apr 2000 09:43:13 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: LIKPEY issues (was Re: host based principal names) To: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004141744.TAA26335@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Martin Rex has raised the following issues with LIPKEY 1. Misuse of GSS_S_NO_CRED to indicate failure to authenticate the user's password. 2. Use of host-based service names. 3. No defined mapping between host-based service names to the certificate. 4. No specification of mechanism specific forms for the generic name types. --------- With respect to 1, I now agree with Martin. I think it should be changed to GSS_S_FAILURE. I propose that when the RFC editor provides me with the 48 hour window to make editorial changes, that this change be made then. The number of characters in both error codes is the same, so this is easy to do. If there is consensus to do this, I will ask the Aread Advisor, Jeff Schiller, for his permission, or if he requires it, re-submit the i-d to make that change. With respect to 2, both John and Ted have made arguments in favor of host based service names. I don't see a consensus to change LIPKEY's bias from host based service names. With respect to 3 and 4, the specification is perhaps underspecified in these areas. However, the TLS RFC is similarly underspecified in the corresponding areas. The intent of LIPKEY is to operate in environments that are accustomed to using TLS. It isn't clear how specify LIPKEY to address issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer with implementation experience, right now, I've none to offer. Because LIPKEY is mandatory to implement for NFSv4, I believe that implementation experience will occur. At which time, we could re-visit these issues, and if it possible to drill down on issues 3 and 4, do so, by issuing an RFC to replace the previous LIPKEY RFC. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 20 16:30:05 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 QAA20716 for ; Thu, 20 Apr 2000 16:30:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA23226 for ietf-cat-wg-out720680; Thu, 20 Apr 2000 13:04:50 -0700 (PDT) Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA23221 for ; Thu, 20 Apr 2000 13:04:47 -0700 (PDT) Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id QAA28109; Thu, 20 Apr 2000 16:04:41 -0400 Date: Thu, 20 Apr 2000 16:04:41 -0400 Message-Id: <200004202004.QAA28109@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Clifford Neuman CC: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu In-reply-to: Clifford Neuman's message of Tue, 18 Apr 2000 21:31:23 -0700 (PDT), <200004190431.VAA10992@cayman-islands.isi.edu> Subject: Re: Ticket extensions in Kerberos revisions Phone: (781) 391-3464 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT) From: Clifford Neuman 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 problem is the extensions which are placed in the unencrypted part of the ticket. If I recall correctly, ASN.1 makes no guarantees that implementations which see unexpected fields will do anything sane, and in fact the best you can hope for is that implementations will ignore that which they do not understand. The problem is that when they then re-encode the ticket, the new extended fields will get dropped, thus breaking the crypto checksum on the ticket. This causes some severe interoperability issues. If we had added type-length-value array from the beginning to handle extensions, ala X.509, we would have been OK. Unfortunately, we weren't far-sighted enough to do this. As a result, I don't think we can put an unencrpyted extension. I think that recent MIT Krb5 implementations (although someone from MIT should check me on this) have been modified to not give a parse failure if they see an unknown/unexpected SEQUENCE OF element. This means that putting a new extended element inside the encrypted part of the ticket is far safer. I understand this doesn't fully meet the needs of some of the uses for which you wanted to use the ticket extensions field; but I'm not sure what else is actually safe to do. I believe ASN.1 has some special tag words that indicate how unexpected fields should be handled; I don't know if they existed in the older versions of ASN.1, and we didn't use those keywords anyway. As I've said before, "Friends don't let friends use ASN.1". :-) - 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 Thu Apr 20 16:40: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 QAA20975 for ; Thu, 20 Apr 2000 16:40:34 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id NAA23651 for ietf-cat-wg-out720680; Thu, 20 Apr 2000 13:13:20 -0700 (PDT) Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA23646 for ; Thu, 20 Apr 2000 13:13:18 -0700 (PDT) Received: from jtrostle-nt2 (dhcp-171-71-229-135.cisco.com [171.71.229.135]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA10833; Thu, 20 Apr 2000 13:12:16 -0700 (PDT) Message-Id: <4.1.20000420130124.00c20940@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 20 Apr 2000 13:16:47 -0700 To: Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu From: Jonathan Trostle Subject: Re: Ticket extensions in Kerberos revisions Cc: jtrostle@cisco.com In-Reply-To: <200004190431.VAA10992@cayman-islands.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk One approach to backwards compatibility would be for clients that support ticket extensions to indicate this to the KDC in the AS_REQ message, by setting a bit in the kdc-options field. KDC's would not use the ticket extensions field if the client does not set the bit. The bit would cause a ticket flag to be set, so this would allow pkcross to be used for clients that support ticket extensions. I'm not sure if the ticket flag in the TGT needs to carry into derived tickets. If the KDC doesn't support the new kdc-options bit, it should reply with error 13. If clients are upgraded before KDC's, the cost is one extra round trip at logon time. So this approach is optimal if KDC's are upgraded first. Jonathan At 09:31 PM 4/18/00 -0700, 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 > -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 20 17:09:02 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 RAA21391 for ; Thu, 20 Apr 2000 17:09:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA24567 for ietf-cat-wg-out720680; Thu, 20 Apr 2000 13:36:26 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA24554 for ; Thu, 20 Apr 2000 13:36:21 -0700 (PDT) Received: (qmail 3613 invoked from network); 20 Apr 2000 20:35:50 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 20 Apr 2000 20:35:50 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Thu, 20 Apr 2000 13:31:54 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Apr 2000 13:35:22 -0700 Message-ID: <80A473F584BED311810D0050DA289BD40F3F33@corporate.cybersafe.com> From: Matt Hur To: "'Jonathan Trostle'" , Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Thu, 20 Apr 2000 13:35:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFAB07.F2FF0990" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFAB07.F2FF0990 Content-Type: text/plain; charset="iso-8859-1" The only clients that may be affected are those that decode the ticket rather than just stash the ticket from the KDC-REP. There are many deployed, commercial clients that, without modification, will pass on the ticket extensions. We should not require changes to the client in order to use ticket extensions. A client could pass a tag to the KDC in the AS-REQ to indicate that it supports ticket extensions. The KDC could then make a decision based on its policy (it could flag principals in the database that do not support ticket extensions) and on the information in the AS-REQ. --Matt > -----Original Message----- > From: Jonathan Trostle [mailto:jtrostle@cisco.com] > Sent: Thursday, April 20, 2000 1:17 PM > To: Clifford Neuman; ietf-cat-wg@lists.Stanford.EDU; > krb-protocol@mit.edu > Cc: jtrostle@cisco.com > Subject: Re: Ticket extensions in Kerberos revisions > > > One approach to backwards compatibility would be for clients > that support ticket extensions to indicate this to the KDC in > the AS_REQ message, by setting a bit in the kdc-options > field. KDC's would not use the ticket extensions field if the > client does not set the bit. The bit would cause a ticket > flag to be set, so this would allow pkcross to be used for > clients that support ticket extensions. I'm not sure if the > ticket flag in the TGT needs to carry into derived tickets. > > If the KDC doesn't support the new kdc-options bit, it should > reply with error 13. If clients are upgraded before KDC's, > the cost is one extra round trip at logon time. So this > approach is optimal if KDC's are upgraded first. > > Jonathan > > > At 09:31 PM 4/18/00 -0700, 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 > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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_01BFAB07.F2FF0990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ticket extensions in Kerberos revisions

The only clients that may be affected are those that = decode the ticket rather than just stash the ticket from the = KDC-REP.

There are many deployed, commercial clients that, = without modification, will pass on the ticket extensions.

We should not require changes to the client in order = to use ticket extensions.  A client could pass a tag to the KDC in = the AS-REQ to indicate that it supports ticket extensions.  The = KDC could then make a decision based on its policy (it could flag = principals in the database that do not support ticket extensions) and = on the information in the AS-REQ.

--Matt


> -----Original Message-----
> From: Jonathan Trostle [mailto:jtrostle@cisco.com]=
> Sent: Thursday, April 20, 2000 1:17 PM
> To: Clifford Neuman; = ietf-cat-wg@lists.Stanford.EDU;
> krb-protocol@mit.edu
> Cc: jtrostle@cisco.com
> Subject: Re: Ticket extensions in Kerberos = revisions
>
>
> One approach to backwards compatibility would = be for clients
> that support ticket extensions to indicate this = to the KDC in
> the AS_REQ message, by setting a bit in the = kdc-options
> field. KDC's would not use the ticket = extensions field if the
> client does not set the bit. The bit would = cause a ticket
> flag to be set, so this would allow pkcross to = be used for
> clients that support ticket extensions. I'm not = sure if the
> ticket flag in the TGT needs to carry into = derived tickets.
>
> If the KDC doesn't support the new kdc-options = bit, it should
> reply with error 13. If clients are upgraded = before KDC's,
> the cost is one extra round trip at logon time. = So this
> approach is optimal if KDC's are upgraded = first.
>
> Jonathan
>
>
> At 09:31 PM 4/18/00 -0700, 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
> = >-++**=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
> >
>
> = -++**=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_01BFAB07.F2FF0990-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 24 21:17: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 VAA19163 for ; Mon, 24 Apr 2000 21:17:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA06671 for ietf-cat-wg-out720680; Mon, 24 Apr 2000 17:47:54 -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 RAA06666 for ; Mon, 24 Apr 2000 17:47:51 -0700 (PDT) Received: from host220.resumecard.com by MIT.EDU with SMTP id AA04033; Mon, 24 Apr 00 20:49:40 EDT Received: from nt4wk02 (host210.resumecard.com [4.17.135.210]) by mail.resumecard.com (8.9.3/8.8.7) with SMTP id UAA21946; Mon, 24 Apr 2000 20:09:16 -0400 Reply-To: From: "Taylor Huggins" To: Subject: Your resume is now... Date: Mon, 24 Apr 2000 20:44:16 -0400 Message-Id: <00f701bfae4f$6311bee0$6d0110ac@resumecard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mime-Autoconverted: from 8bit to quoted-printable by mail.resumecard.com id UAA21946 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.Stanford.EDU id RAA06667 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit (You are receiving this email because you have been identified as an Internet user who may benefit from this service) Dear Friend, Your resume is now available in a convenient wallet size. Introducing the ResumeCARD – the first NETWORKING tool that lets you bring your resume ANYWHERE. ResumeCARDs are business cards with the unique URL of your online resume. Pick your own URL and build a homepage for your resume in minutes. Add hyperlinks to past jobs, schools, projects and your favorite websites. When your done we'll send you 15 FREE personalized ResumeCARDs. Visit www.resumecard.com for your FREE ResumeCARDs. To demo our interactive ResumeBUILDER click here: http://www.resumecard.com/demodesign/index2.htm We look forward to seeing you, The RC Team ResumeCARD.com How to Network www.resumecard.com =============================== -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 10:28: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 KAA13356 for ; Tue, 25 Apr 2000 10:28:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA28333 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 06:58:05 -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 GAA28326 for ; Tue, 25 Apr 2000 06:58:02 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA14296; Tue, 25 Apr 00 10:00:00 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id PAA20541; Tue, 25 Apr 2000 15:55:02 +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 PAA13049; Tue, 25 Apr 2000 15:56:52 +0200 (MET DST) Received: (from d019080@localhost) by uw1048.wdf.sap-ag.de (8.8.8+Sun/8.8.8) id PAA21351; Tue, 25 Apr 2000 15:56:52 +0200 (MET DST) From: Martin Rex Message-Id: <200004251356.PAA21351@uw1048.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: mre@Eng.Sun.COM Date: Tue, 25 Apr 2000 15:56:52 +0200 (MET DST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 20, 0 09:43:13 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: > > Martin Rex has raised the following issues with LIPKEY > > 1. Misuse of GSS_S_NO_CRED to indicate failure to authenticate the user's > password. > > 2. Use of host-based service names. > > 3. No defined mapping between host-based service names to the certificate. > > 4. No specification of mechanism specific forms for the generic name types. > > --------- > > With respect to 1, I now agree with Martin. I think it should be changed > to GSS_S_FAILURE. I propose that when the RFC editor provides me with the 48 > hour window to make editorial changes, that this change be made then. The > number of characters in both error codes is the same, so this is easy to do. > If there is consensus to do this, I will ask the Aread Advisor, Jeff Schiller, > for his permission, or if he requires it, re-submit the i-d to make that > change. > > With respect to 2, both John and Ted have made arguments in favor of > host based service names. I don't see a consensus to change LIPKEY's > bias from host based service names. OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. Where is the spec for Kerberos that tells me how to map the hostbased service name into full Kerberos principal name. (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) My understanding is that many of the traditionally kerberized Unix services share the "host/f.q.d.n" key. What are the rules when using GSS-API? Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: The client must begin the authentication exchange by calling GSS_Init_Sec_Context, passing in 0 for input_context_handle (initially), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of Host-Based Service and input_name_string of "ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. (Failing this, the client may try again using input_name_string of "host@hostname".) The parenthesized suggestion seems to indicate that hostbased service names may be broken in Kerberos GSS-API. Personally, I consider it unacceptable that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. As long as there is no official Kerberos spec that mandates how to map gssapi hostbased service names into Kerberos principal names, their use is non-portable and should be discouraged. What Kerberos principal name is supposed to be used for nfs? Your Email seems to suggest that a nfs/f.q.d.n principal is required for that? > > With respect to 3 and 4, the specification is perhaps underspecified in these > areas. However, the TLS RFC is similarly underspecified in the corresponding > areas. The intent of LIPKEY is to operate in environments that are > accustomed to using TLS. It isn't clear how specify LIPKEY to address > issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer > with implementation experience, right now, I've none to offer. Because > LIPKEY is mandatory to implement for NFSv4, I believe that implementation > experience will occur. At which time, we could re-visit these issues, > and if it possible to drill down on issues 3 and 4, do so, by > issuing an RFC to replace the previous LIPKEY RFC. The lack of names in TLS is not a valid reason, TLS is a wire protocol, not an API. -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 Apr 25 11:37: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 LAA17409 for ; Tue, 25 Apr 2000 11:37:40 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA29691 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:06:19 -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 IAA29684 for ; Tue, 25 Apr 2000 08:06:15 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA11701; Tue, 25 Apr 00 11:08:14 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id LAA04880; Tue, 25 Apr 2000 11:06:05 -0400 (EDT) Date: Tue, 25 Apr 2000 11:06:05 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 15:56:52 +0200 (MET DST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > Where is the spec for Kerberos that tells me how to map the hostbased > service name into full Kerberos principal name. > (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > > My understanding is that many of the traditionally kerberized Unix services > share the "host/f.q.d.n" key. What are the rules when using GSS-API? There is no GSSAPI authentication method for "telnet". But if there was it would use "host/f.q.d.n" since that is what the KERBEROS_V5 AUTH method uses. > > With respect to 3 and 4, the specification is perhaps underspecified in these > > areas. However, the TLS RFC is similarly underspecified in the corresponding > > areas. The intent of LIPKEY is to operate in environments that are > > accustomed to using TLS. It isn't clear how specify LIPKEY to address > > issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer > > with implementation experience, right now, I've none to offer. Because > > LIPKEY is mandatory to implement for NFSv4, I believe that implementation > > experience will occur. At which time, we could re-visit these issues, > > and if it possible to drill down on issues 3 and 4, do so, by > > issuing an RFC to replace the previous LIPKEY RFC. > > > The lack of names in TLS is not a valid reason, > TLS is a wire protocol, not an API. I am fairly sure that the comment regarding hostnames and TLS has to do with the rather confusing ways that hostnames are used in X.509 certificates. The rules for verifying a host certificate basicly say do (1) but if (1) fails, look for (2) and if (2) fails, you can try (3) but we do not recommend it. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 11:40: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 LAA17502 for ; Tue, 25 Apr 2000 11:40:55 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA29606 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:04:52 -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 IAA29595 for ; Tue, 25 Apr 2000 08:04:48 -0700 (PDT) Received: from [130.202.20.3] by MIT.EDU with SMTP id AA11022; Tue, 25 Apr 00 11:06:46 EDT Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA23488; Tue, 25 Apr 2000 10:04:39 -0500 (CDT) Message-Id: <3905B433.B1382ACC@anl.gov> Date: Tue, 25 Apr 2000 10:05:23 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) References: <200004251356.PAA21351@uw1048.wdf.sap-ag.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Martin Rex wrote: > OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > Where is the spec for Kerberos that tells me how to map the hostbased > service name into full Kerberos principal name. > (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > > My understanding is that many of the traditionally kerberized Unix services > share the "host/f.q.d.n" key. What are the rules when using GSS-API? > The choice of the service name is up to the application, so your W2K Kerberos SSP wrapper GSS should not care. RFC 2743 says it is: This name type is used to represent services associated with host computers. Support for this name form is recommended to mechanism designers in the interests of portability, but is not mandated by this specification. This name form is constructed using two elements, "service" and "hostname", as follows: service@hostname Then Kerberos goes on to convert this to the principal service/fqdn@realm after canonicalization of the hostname via DNS. (Which as you have pointed out may be a security risk.) > Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: > > The client must begin the authentication exchange by calling > GSS_Init_Sec_Context, passing in 0 for input_context_handle > (initially), and a targ_name equal to output_name from > GSS_Import_Name called with input_name_type of Host-Based Service and > input_name_string of "ftp@hostname" where "hostname" is the fully > qualified host name of the server with all letters in lower case. > (Failing this, the client may try again using input_name_string of > "host@hostname".) > > The parenthesized suggestion seems to indicate that hostbased service names > may be broken in Kerberos GSS-API. Personally, I consider it unacceptable > that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. > Yes that is to bad that that was not resolved earlier, but that is an FTP problem not a GSSAPI problem. > As long as there is no official Kerberos spec that mandates how to map > gssapi hostbased service names into Kerberos principal names, their use > is non-portable and should be discouraged. > > What Kerberos principal name is supposed to be used for nfs? > Your Email seems to suggest that a nfs/f.q.d.n principal is required > for that? > That would be up to the application writer (NFS developer) to define the service which could be "nfs". This would then map to nfs/fqdn@realm as a principal. They might even want to use "host". But the GSSAPI should not care what the service is. Using a single "host" service for all root-login type operations simplifies the sysadmin life as he does not need a dozen principals and keys. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 11:44:14 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 LAA17591 for ; Tue, 25 Apr 2000 11:44:13 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA29891 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:16:20 -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 IAA29886 for ; Tue, 25 Apr 2000 08:16:16 -0700 (PDT) From: towusu@us.ibm.com Received: from e22.nc.us.ibm.com by MIT.EDU with SMTP id AA10157; Tue, 25 Apr 00 11:16:07 EDT Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA15212; Tue, 25 Apr 2000 10:56:39 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id LAA86618; Tue, 25 Apr 2000 11:15:55 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568CC.0053D6BA ; Tue, 25 Apr 2000 11:15:44 -0400 X-Lotus-Fromdomain: IBMUS To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Message-Id: <852568CC.0053C6A8.00@d54mta03.raleigh.ibm.com> Date: Tue, 25 Apr 2000 10:14:58 -0500 Subject: Re: LIKPEY issues (was Re: host based principal names) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk RFC-1964 (Kerberos V5 GSS-API Mechanism) section 2.1.2 specifies how to deal with hostbased service names: Host-Based Service Name Form This name form has been incorporated at the mechanism-independent GSS-API level as of GSS-API, Version 2. This subsection retains the Object Identifier and symbolic name assignments previously made at the Kerberos V5 GSS-API mechanism level, and adopts the definition as promoted to the mechanism-independent level. This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) service_name(4)}. The previously recommended symbolic name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME". The currently preferred symbolic name for this type is "GSS_C_NT_HOSTBASED_SERVICE". This name type is used to represent services associated with host computers. This name form is constructed using two elements, "service" and "hostname", as follows: service@hostname When a reference to a name of this type is resolved, the "hostname" is canonicalized by attempting a DNS lookup and using the fully- qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters. The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulted to the canonicalized name of the local host. Values for the "service" element will be registered with the IANA. --- Thomas Owusu Java Security towusu@us.ibm.com Martin Rex @lists.Stanford.EDU on 04/25/2000 08:56:52 AM Please respond to mrex@sap-ag.de Sent by: owner-ietf-cat-wg@lists.Stanford.EDU To: mre@Eng.Sun.COM cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) Mike Eisler wrote: > > Martin Rex has raised the following issues with LIPKEY > > 1. Misuse of GSS_S_NO_CRED to indicate failure to authenticate the user's > password. > > 2. Use of host-based service names. > > 3. No defined mapping between host-based service names to the certificate. > > 4. No specification of mechanism specific forms for the generic name types. > > --------- > > With respect to 1, I now agree with Martin. I think it should be changed > to GSS_S_FAILURE. I propose that when the RFC editor provides me with the 48 > hour window to make editorial changes, that this change be made then. The > number of characters in both error codes is the same, so this is easy to do. > If there is consensus to do this, I will ask the Aread Advisor, Jeff Schiller, > for his permission, or if he requires it, re-submit the i-d to make that > change. > > With respect to 2, both John and Ted have made arguments in favor of > host based service names. I don't see a consensus to change LIPKEY's > bias from host based service names. OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. Where is the spec for Kerberos that tells me how to map the hostbased service name into full Kerberos principal name. (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) My understanding is that many of the traditionally kerberized Unix services share the "host/f.q.d.n" key. What are the rules when using GSS-API? Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: The client must begin the authentication exchange by calling GSS_Init_Sec_Context, passing in 0 for input_context_handle (initially), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of Host-Based Service and input_name_string of "ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. (Failing this, the client may try again using input_name_string of "host@hostname".) The parenthesized suggestion seems to indicate that hostbased service names may be broken in Kerberos GSS-API. Personally, I consider it unacceptable that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. As long as there is no official Kerberos spec that mandates how to map gssapi hostbased service names into Kerberos principal names, their use is non-portable and should be discouraged. What Kerberos principal name is supposed to be used for nfs? Your Email seems to suggest that a nfs/f.q.d.n principal is required for that? > > With respect to 3 and 4, the specification is perhaps underspecified in these > areas. However, the TLS RFC is similarly underspecified in the corresponding > areas. The intent of LIPKEY is to operate in environments that are > accustomed to using TLS. It isn't clear how specify LIPKEY to address > issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer > with implementation experience, right now, I've none to offer. Because > LIPKEY is mandatory to implement for NFSv4, I believe that implementation > experience will occur. At which time, we could re-visit these issues, > and if it possible to drill down on issues 3 and 4, do so, by > issuing an RFC to replace the previous LIPKEY RFC. The lack of names in TLS is not a valid reason, TLS is a wire protocol, not an API. -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 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 11:52:30 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 LAA17844 for ; Tue, 25 Apr 2000 11:52:29 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA00209 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:23:03 -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 IAA00198 for ; Tue, 25 Apr 2000 08:22:57 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA12761; Tue, 25 Apr 00 11:22:53 EDT Received: from elvis.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 LAA01980; Tue, 25 Apr 2000 11:22:28 -0400 (EDT) Message-Id: <200004251522.LAA01980@ginger.cmf.nrl.navy.mil> To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of "Tue, 25 Apr 2000 15:56:52 +0200." <200004251356.PAA21351@uw1048.wdf.sap-ag.de> 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, 25 Apr 2000 11:22:26 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> With respect to 2, both John and Ted have made arguments in favor of >> host based service names. I don't see a consensus to change LIPKEY's >> bias from host based service names. > >OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. >Where is the spec for Kerberos that tells me how to map the hostbased >service name into full Kerberos principal name. >(i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > >My understanding is that many of the traditionally kerberized Unix services >share the "host/f.q.d.n" key. What are the rules when using GSS-API? Martin, I was under the impression your complaint was with the use of the hostname-based service name, not with the rules used to map service names to Kerberos principals. As I understand it, the mapping between the GSSAPI service name and Kerberos principal is very simple: service@f.q.d.n maps to service/f.q.d.n@REALM. All of the traditional Kerberized Unix remote access utilities (with the exception of ftp) don't use GSS-API. "host" in the Kerberos sense traditionally is a key readable only by the root user on Unix, and all of the services that require root level access (such as telnetd, rlogind) share this key. If they did use the GSSAPI, I think all of their service names would be "host@f.q.d.n". >Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: > > The client must begin the authentication exchange by calling > GSS_Init_Sec_Context, passing in 0 for input_context_handle > (initially), and a targ_name equal to output_name from > GSS_Import_Name called with input_name_type of Host-Based Service and > input_name_string of "ftp@hostname" where "hostname" is the fully > qualified host name of the server with all letters in lower case. > (Failing this, the client may try again using input_name_string of > "host@hostname".) > >The parenthesized suggestion seems to indicate that hostbased service names >may be broken in Kerberos GSS-API. Personally, I consider it unacceptable >that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. I have never really understood why the RFC2228 authors choose two possible service names, but this isn't really related to Kerberos from my point of view. The ftp client that comes with MIT Kerberos tries both ftp@f.q.d.n and host@f.q.d.n (which maps to the Kerberos principals ftp/f.q.d.n@REALM and host/f.q.d.n@REALM respectively). >As long as there is no official Kerberos spec that mandates how to map >gssapi hostbased service names into Kerberos principal names, their use >is non-portable and should be discouraged. Section 2.1.2 of RFC 1964 isn't exactly unambiguous, but: This name type is used to represent services associated with host computers. This name form is constructed using two elements, "service" and "hostname", as follows: service@hostname I think most people who are knowledgable about Kerberos would agree that this means "service" should be the first label, and hostname would be the instance. I think if 1964 gets revised, this should be made more clear. >What Kerberos principal name is supposed to be used for nfs? >Your Email seems to suggest that a nfs/f.q.d.n principal is required >for that? Seems relatively clear to me; what's the problem? (I would have personally chosen "host", though). Let's ask a different question: is there an IETF protocol that specifies the use of GSSAPI and _doesn't_ use the host-based service name form? Certainly the largest consumer of GSSAPI that I'm aware of (SASL) mandates the use of host-based service names. --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 Apr 25 12:20: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 MAA18747 for ; Tue, 25 Apr 2000 12:20:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA01084 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:49: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 IAA01078 for ; Tue, 25 Apr 2000 08:49:15 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA00437; Tue, 25 Apr 00 11:51:13 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28332; Tue, 25 Apr 2000 08:49:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA22062; Tue, 25 Apr 2000 08:46:58 -0700 (PDT) Received: from teal (awe8-128.Central.Sun.COM [129.147.8.128]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3PFkqh796783; Tue, 25 Apr 2000 08:46:52 -0700 (PDT) Date: Tue, 25 Apr 2000 08:50:05 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: LIKPEY issues (was Re: host based principal names) To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004251356.PAA21351@uw1048.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Mike Eisler wrote: > > > > Martin Rex has raised the following issues with LIPKEY > > > > 1. Misuse of GSS_S_NO_CRED to indicate failure to authenticate the user's > > password. > > > > 2. Use of host-based service names. > > > > 3. No defined mapping between host-based service names to the certificate. > > > > 4. No specification of mechanism specific forms for the generic name types. > > [...] > > With respect to 2, both John and Ted have made arguments in favor of > > host based service names. I don't see a consensus to change LIPKEY's > > bias from host based service names. > > OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > Where is the spec for Kerberos that tells me how to map the hostbased > service name into full Kerberos principal name. > (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) The topic is LIPKEY and SPKM-3, but, in RFC 1510, it says in section 7.2.1 "Name of server principals" The principal identifier for a server on a host will generally be composed of two parts: (1) the realm of the KDC with which the server is registered, and (2) a two-component name of type NT-SRV-HST if the host name is an Internet domain name or a multi-component name of type NT-SRV-XHST if the name of the host is of a form such as X.500 that allows slash (/) separators. The first component of the two- or multi-component name will identify the service and the latter components will identify the host. Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host must be lower case. For services such as telnet and the Berkeley R commands which run with system privileges, the first component will be the string "host" instead of a service specific identifier. I agree that the above is somewhat underspecified. > My understanding is that many of the traditionally kerberized Unix services > share the "host/f.q.d.n" key. What are the rules when using GSS-API? I've presumed that when GSS-APU gets a target name like host@ then when using a Kerberos V5 target, this becomes host/@ > Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: > > The client must begin the authentication exchange by calling > GSS_Init_Sec_Context, passing in 0 for input_context_handle > (initially), and a targ_name equal to output_name from > GSS_Import_Name called with input_name_type of Host-Based Service and > input_name_string of "ftp@hostname" where "hostname" is the fully > qualified host name of the server with all letters in lower case. > (Failing this, the client may try again using input_name_string of > "host@hostname".) > > The parenthesized suggestion seems to indicate that hostbased service names > may be broken in Kerberos GSS-API. Personally, I consider it unacceptable > that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. Perhaps you should have objected when the ftp i-id was being considered by the WG several years ago. > As long as there is no official Kerberos spec that mandates how to map > gssapi hostbased service names into Kerberos principal names, their use > is non-portable and should be discouraged. This isn't a new point in the discussion. We'll have to agree to disagree. Since RFC 1510 is being re-worked in this WG, you might want raised this point to the authors of the i-d that is to replace RFC 1510. > What Kerberos principal name is supposed to be used for nfs? > Your Email seems to suggest that a nfs/f.q.d.n principal is required > for that? Yes it is. > > With respect to 3 and 4, the specification is perhaps underspecified in these > > areas. However, the TLS RFC is similarly underspecified in the corresponding > > areas. The intent of LIPKEY is to operate in environments that are > > accustomed to using TLS. It isn't clear how specify LIPKEY to address > > issues 3 and 3, and not avoid inconsistency with TLS. It would be clearer > > with implementation experience, right now, I've none to offer. Because > > LIPKEY is mandatory to implement for NFSv4, I believe that implementation > > experience will occur. At which time, we could re-visit these issues, > > and if it possible to drill down on issues 3 and 4, do so, by > > issuing an RFC to replace the previous LIPKEY RFC. > > > The lack of names in TLS is not a valid reason, Considering that LIPKEY is intended to work in environments that TLS does, it is valid. > TLS is a wire protocol, not an API. But GSS-API is a wire protocol. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 12:22: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 MAA18839 for ; Tue, 25 Apr 2000 12:22:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA01643 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 08:58:41 -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 IAA01580 for ; Tue, 25 Apr 2000 08:58:23 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA23972; Tue, 25 Apr 00 11:58:17 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03257; Tue, 25 Apr 2000 08:58:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA24706; Tue, 25 Apr 2000 08:57:18 -0700 (PDT) Received: from teal (awe8-128.Central.Sun.COM [129.147.8.128]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3PFvGh797925; Tue, 25 Apr 2000 08:57:16 -0700 (PDT) Date: Tue, 25 Apr 2000 09:00:29 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: LIKPEY issues (was Re: host based principal names) To: Ken Hornstein Cc: mrex@sap-ag.de, cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004251522.LAA01980@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 > >What Kerberos principal name is supposed to be used for nfs? > >Your Email seems to suggest that a nfs/f.q.d.n principal is required > >for that? > Seems relatively clear to me; what's the problem? (I would have personally > chosen "host", though). Getting way off topic here, but one reason I opted for "nfs" and not "host" was that NFS servers often operate in a kernel environment and not a user level environment, and I wanted to accommodate implementations that might chose to keep the keytab information completely in the kernel. If "host" were used, and the same machine supported a telnet service and an nfs service, this would not be possible for such implementations. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 13:59: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 NAA20987 for ; Tue, 25 Apr 2000 13:59:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA09921 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 10:18: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 KAA09916 for ; Tue, 25 Apr 2000 10:18:13 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA06945; Tue, 25 Apr 00 13:20:10 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA26115; Tue, 25 Apr 2000 19:14:51 +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 TAA21286; Tue, 25 Apr 2000 19:12:51 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA09792; Tue, 25 Apr 2000 19:12:51 +0200 (METDST) From: Martin Rex Message-Id: <200004251712.TAA09792@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: mre@Eng.Sun.COM Date: Tue, 25 Apr 2000 19:12:51 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 25, 0 08:50:05 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: > > Martin Rex wrote: > > > > OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > > Where is the spec for Kerberos that tells me how to map the hostbased > > service name into full Kerberos principal name. > > (i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > > The topic is LIPKEY and SPKM-3, but, in RFC 1510, it > says in section 7.2.1 "Name of server principals" > > The principal identifier for a server on a host will generally be > composed of two parts: (1) the realm of the KDC with which the server > is registered, and (2) a two-component name of type NT-SRV-HST if the > host name is an Internet domain name or a multi-component name of > type NT-SRV-XHST if the name of the host is of a form such as X.500 > that allows slash (/) separators. The first component of the two- or > multi-component name will identify the service and the latter > components will identify the host. Where the name of the host is not > case sensitive (for example, with Internet domain names) the name of > the host must be lower case. For services such as telnet and the > Berkeley R commands which run with system privileges, the first > component will be the string "host" instead of a service specific > identifier. > > I agree that the above is somewhat underspecified. What I'd like to know is whether I can blindly create a Kerberos principal name from a hostbased service name in my wrapper any rely on the Service-specific principals to exist whenever a GSS-API variant of a kerberized service is built, or whether there is a subset of services that should be mapped to the common "host" key. > > > My understanding is that many of the traditionally kerberized Unix services > > share the "host/f.q.d.n" key. What are the rules when using GSS-API? > > I've presumed that when GSS-APU gets a target name like > host@ > then when using a Kerberos V5 target, this becomes > host/@ > > > Quoting rfc2228 "FTP security Extensions", Appendix I, 3rd paragraph: > > > > The client must begin the authentication exchange by calling > > GSS_Init_Sec_Context, passing in 0 for input_context_handle > > (initially), and a targ_name equal to output_name from > > GSS_Import_Name called with input_name_type of Host-Based Service and > > input_name_string of "ftp@hostname" where "hostname" is the fully > > qualified host name of the server with all letters in lower case. > > (Failing this, the client may try again using input_name_string of > > "host@hostname".) > > > > The parenthesized suggestion seems to indicate that hostbased service names > > may be broken in Kerberos GSS-API. Personally, I consider it unacceptable > > that "ftp@f.q.d.n" may not work and I should try "host@hostname" instead. > > Perhaps you should have objected when the ftp i-id was being considered > by the WG several years ago. So many documents to read, so little time. I hope that this is the first and the last document that permits trial and error administration. > > > As long as there is no official Kerberos spec that mandates how to map > > gssapi hostbased service names into Kerberos principal names, their use > > is non-portable and should be discouraged. > > This isn't a new point in the discussion. We'll have to agree to disagree. > Since RFC 1510 is being re-worked in this WG, you might want raised this point > to the authors of the i-d that is to replace RFC 1510. > > > What Kerberos principal name is supposed to be used for nfs? > > Your Email seems to suggest that a nfs/f.q.d.n principal is required > > for that? > > Yes it is. What I wanted to ask: Do you require "ftp@f.q.d.n", or do you allow "host@f.q.d.n" fallback as in the Secure FTP extensions? > > > > > The lack of names in TLS is not a valid reason, > > Considering that LIPKEY is intended to work in environments > that TLS does, it is valid. > > > TLS is a wire protocol, not an API. > > But GSS-API is a wire protocol. GSS-API is both, a wire protocol *and* an API. GSS-API has primitives for doing name-based access control, and the minimum "service" provided by GSS-API is authentication. GSS-API is made for authentication-aware applications. TLS still shows its SSL heritage in that authentication is not provided in a uniform fashion, they primarily wanted to provide an encrypted channel and ignore authentication issues at the application level. TLS-based applications often don't care about authentication at the TLS level. -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 Apr 25 14:02: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 OAA21159 for ; Tue, 25 Apr 2000 14:02:20 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA11382 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 10:32:00 -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 KAA11367 for ; Tue, 25 Apr 2000 10:31:55 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA27809; Tue, 25 Apr 00 13:31:46 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA00366; Tue, 25 Apr 2000 19:24:55 +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 TAA21559; Tue, 25 Apr 2000 19:23:45 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA09871; Tue, 25 Apr 2000 19:23:45 +0200 (METDST) From: Martin Rex Message-Id: <200004251723.TAA09871@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: towusu@us.ibm.com Date: Tue, 25 Apr 2000 19:23:45 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <852568CC.0053C6A8.00@d54mta03.raleigh.ibm.com> from "towusu@us.ibm.com" at Apr 25, 0 10:14:58 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 towusu@us.ibm.com wrote: > > RFC-1964 (Kerberos V5 GSS-API Mechanism) section 2.1.2 specifies how > to deal with hostbased service names: No, it doesn't. This section is copied verbatim from rfc2078 and specifies only transformations at the generic GSS-API level. It doesn't specify how to map these names into the mechanism-specific name form Kerberos principal names. What I'd like to see in the rfc1964 successor is either a definition for this mapping or a clear reference of such a mapping in another RFC (e.g. rfc1510bis). In particular, I'd like to see whether any service names must or must not be transformed into the "host" principal. A requirement for independent principals for every service would be sufficient for the spec, but it may require lots of additional service keys to be generated when GSS-API variants of services are installed. -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 Apr 25 14:21:25 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 OAA21530 for ; Tue, 25 Apr 2000 14:21:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA12524 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 10:43:37 -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 KAA12516 for ; Tue, 25 Apr 2000 10:43:34 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA02618; Tue, 25 Apr 00 13:43:32 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id TAA05836; Tue, 25 Apr 2000 19:39:54 +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 TAA21944; Tue, 25 Apr 2000 19:38:16 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id TAA09958; Tue, 25 Apr 2000 19:38:16 +0200 (METDST) From: Martin Rex Message-Id: <200004251738.TAA09958@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Tue, 25 Apr 2000 19:38:16 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004251522.LAA01980@ginger.cmf.nrl.navy.mil> from "Ken Hornstein" at Apr 25, 0 11:22:26 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 Ok, this is a Kerberos and not a LIPKEY issue... Ken Hornstein wrote: > > Martin Rex wrote: > > > >OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > >Where is the spec for Kerberos that tells me how to map the hostbased > >service name into full Kerberos principal name. > >(i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > > > >My understanding is that many of the traditionally kerberized Unix services > >share the "host/f.q.d.n" key. What are the rules when using GSS-API? > > Martin, I was under the impression your complaint was with the use of > the hostname-based service name, not with the rules used to map service > names to Kerberos principals. As I understand it, the mapping between > the GSSAPI service name and Kerberos principal is very simple: > service@f.q.d.n maps to service/f.q.d.n@REALM. > > All of the traditional Kerberized Unix remote access utilities (with the > exception of ftp) don't use GSS-API. "host" in the Kerberos sense > traditionally is a key readable only by the root user on Unix, and all > of the services that require root level access (such as telnetd, rlogind) > share this key. If they did use the GSSAPI, I think all of their service > names would be "host@f.q.d.n". Do I need to map "telnet@f.q.d.n" into "host/f.q.d.n@REALM", or should I always map it into "telnet/f.q.d.n@REALM". Telnet SHOULD NEVER have to try both "telnet@f.q.d.n" and "host@f.q.d.n" in way that the current Secure FTP extensions suggest. I need a formal specification for any such mapping (if there should be one for Kerberos 5) because I want to ship code! ;-) If an application tries "telnet@f.q.d.n" as target name, then there are two failure possibilities: 1. (one network roundtrip to the KDC): the principal for "telnet" doesn't exist gss_init_sec_context() fails with GSS_S_FAILURE 2. (one network roundtrip to the KDC, one to the target): the principal for "telnet" exists, but the target is using "host" credentials for accepting, gss_init_sec_context() succeeds for the initiator, but gss_accept_sec_context() fails for the acceptor. I don't like either one, because both failures have network roundtrip and crypto overhead. -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 Apr 25 14:33:30 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 OAA21807 for ; Tue, 25 Apr 2000 14:33:29 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA14226 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:09:19 -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 LAA14216 for ; Tue, 25 Apr 2000 11:09:15 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA25894; Tue, 25 Apr 00 14:11:13 EDT Received: from elvis.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 OAA03978; Tue, 25 Apr 2000 14:09:11 -0400 (EDT) Message-Id: <200004251809.OAA03978@ginger.cmf.nrl.navy.mil> To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of "Tue, 25 Apr 2000 19:38:16 +0200." <200004251738.TAA09958@hw1464.wdf.sap-ag.de> 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, 25 Apr 2000 14:09:09 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Do I need to map "telnet@f.q.d.n" into "host/f.q.d.n@REALM", >or should I always map it into "telnet/f.q.d.n@REALM". >Telnet SHOULD NEVER have to try both "telnet@f.q.d.n" and "host@f.q.d.n" >in way that the current Secure FTP extensions suggest. I agree, and _if_ we had a GSS-API authentication mechanism for telnet, I would say that the only target name that should be tried would be "host@f.q.d.n". >I need a formal specification for any such mapping (if there should >be one for Kerberos 5) because I want to ship code! ;-) I think ftp is the exception in this regard (the fact that there are two possible target names that may work). I believe that everyone agrees that there is a one-to-one mapping between Kerberos principals and GSSAPI host-based service names, so I don't think this is an issue. Even in the ftp case, this isn't a Kerberos issue; the issue is that two different _GSSAPI_ service names are specified. >[... From another note ...] >What I'd like to know is whether I can blindly create a Kerberos >principal name from a hostbased service name in my wrapper any >rely on the Service-specific principals to exist whenever a GSS-API >variant of a kerberized service is built, or whether there is >a subset of services that should be mapped to the common "host" key. I believe everyone would agree that you don't need to do any special mapping between GSS-API service names and Kerberos principals; whatever the protocol specifies as the service name will be the correct principal. Of course, some protocols may specify more than one service name (like ftp), but IMHO that's a protocol-specific issue. (If there was going to be GSSAPI versions of telnet and rlogin, I think everyone would agree they would all use "host@f.q.d.n" as a service name). --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 Apr 25 14:37: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 OAA21857 for ; Tue, 25 Apr 2000 14:37:09 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA14264 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:09:42 -0700 (PDT) Received: from dns2.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA14255 for ; Tue, 25 Apr 2000 11:09:38 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA04644; Tue, 25 Apr 2000 13:09:32 -0500 (CDT) Message-ID: <3905DF87.55BE778E@anl.gov> Date: Tue, 25 Apr 2000 13:10:15 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Y. Ts'o" CC: Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <200004202004.QAA28109@tsx-prime.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Ted, Your comments below on the ASN.1 and X.509 extensions brings up an interesting question. What would it take to allow a Kerberos ticket to have a copy of some x.509 extension? There might be some situations where you might want to have PK_INIT copy an extension, to the TGT or if you used a Kerberos ticket to get a certificate to copy the extension from the ticket to the certificate. Or possibly even with PK_INIT coping the certificate chain to the ticket. This might allow the authorization data to be transfered from a certificate to a ticket. "Theodore Y. Ts'o" wrote: > > Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT) > From: Clifford Neuman > > 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 problem is the extensions which are placed in the unencrypted part > of the ticket. If I recall correctly, ASN.1 makes no guarantees that > implementations which see unexpected fields will do anything sane, and > in fact the best you can hope for is that implementations will ignore > that which they do not understand. The problem is that when they then > re-encode the ticket, the new extended fields will get dropped, thus > breaking the crypto checksum on the ticket. This causes some severe > interoperability issues. > > If we had added type-length-value array from the beginning to handle > extensions, ala X.509, we would have been OK. Unfortunately, we weren't > far-sighted enough to do this. As a result, I don't think we can put an > unencrpyted extension. > > I think that recent MIT Krb5 implementations (although someone from MIT > should check me on this) have been modified to not give a parse failure > if they see an unknown/unexpected SEQUENCE OF element. This means that > putting a new extended element inside the encrypted part of the ticket > is far safer. I understand this doesn't fully meet the needs of some of > the uses for which you wanted to use the ticket extensions field; but > I'm not sure what else is actually safe to do. > > I believe ASN.1 has some special tag words that indicate how unexpected > fields should be handled; I don't know if they existed in the older > versions of ASN.1, and we didn't use those keywords anyway. > > As I've said before, "Friends don't let friends use ASN.1". :-) > > - Ted -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 14: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 OAA22208 for ; Tue, 25 Apr 2000 14:48:35 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA16170 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:23:04 -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 LAA16150 for ; Tue, 25 Apr 2000 11:22:57 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA16529; Tue, 25 Apr 00 14:22:55 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA13238; Tue, 25 Apr 2000 14:22:46 -0400 (EDT) Date: Tue, 25 Apr 2000 14:22:46 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: towusu@us.ibm.com, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 19:23:45 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > What I'd like to see in the rfc1964 successor is either a definition > for this mapping or a clear reference of such a mapping in another RFC > (e.g. rfc1510bis). In particular, I'd like to see whether any service > names must or must not be transformed into the "host" principal. I think you confusing things. The GSS-API does not perform any mapping from ftp@kermit.columbia.edu to host/kermit.columbia.edu@CC.COLUMBIA.EDU when using Kerberos V. When the GSSAPI-Kerberos_V FTP client creates a security context it first calls gss_ini_sec_context() with the result of calling gss_import_name() with the string "ftp@f.q.d.n". If the authentication fails, it then silently tries again with "host@f.q.d.n". There is no mapping within the GSSAPI implementation from "ftp" to "host". This is simply part of the specification for how GSSAPI is used with a specific application level protocol (such as FTP.) Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 15:03: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 PAA22727 for ; Tue, 25 Apr 2000 15:03:01 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA17576 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:36:47 -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 LAA17569 for ; Tue, 25 Apr 2000 11:36:44 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA07078; Tue, 25 Apr 00 14:38:42 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA16938; Tue, 25 Apr 2000 14:36:32 -0400 (EDT) Date: Tue, 25 Apr 2000 14:36:32 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: mre@Eng.Sun.COM, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 19:12:51 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > What I'd like to know is whether I can blindly create a Kerberos > principal name from a hostbased service name in my wrapper any > rely on the Service-specific principals to exist whenever a GSS-API > variant of a kerberized service is built, or whether there is > a subset of services that should be mapped to the common "host" key. You should blindly create a Kerberos principal from a host based service name. You cannot count on the service specific principals existing. If I don't want a specific service to be authenticated I don't create keys for that service/host combination. You do not perform service name translations within the GSSAPI implementation. > So many documents to read, so little time. > > I hope that this is the first and the last document that permits trial > and error administration. Why? There are a lot of benefits associated by being able to specify either a global key for all services or individual keys for each service. Obviously, it is an either/or situation. > TLS still shows its SSL heritage in that authentication is not provided > in a uniform fashion, they primarily wanted to provide an encrypted channel > and ignore authentication issues at the application level. > TLS-based applications often don't care about authentication at the > TLS level. Authentication is REQUIRED at the TLS level. That is why the IESG mandated that the anonymous ciphers be deprecated. TLS without authentication of the server is insecure and susceptible to man in the middle attacks. End user authentication may either be performed during the TLS negotiations or as a subsequent negotiation after TLS is established. Telnet and FTP are both examples of services which allow end user authentication to be performed either as part of the TLS negotiation or as a subsequent authentication protocol. Whichever is used, TLS provides privacy and integrity protection for the channel but only if (1) the server was authenticated during TLS initialization; or (2) the TLS negotiations are later verified during the subsequent authentication The second method is not described in any Internet-Drafts and is not formally implemented. As soon as the current set of Telnet Internet-Drafts are approved by the IESG I will publish the I-D describing how to authenticate an anonymous or unverified TLS connection. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 15:15: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 PAA23320 for ; Tue, 25 Apr 2000 15:15:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA18268 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:43:01 -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 LAA18247 for ; Tue, 25 Apr 2000 11:42:55 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA09905; Tue, 25 Apr 00 14:44:51 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id UAA27133; Tue, 25 Apr 2000 20:39:53 +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 UAA24151; Tue, 25 Apr 2000 20:38:57 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id UAA10344; Tue, 25 Apr 2000 20:38:58 +0200 (METDST) From: Martin Rex Message-Id: <200004251838.UAA10344@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: jaltman@columbia.edu Date: Tue, 25 Apr 2000 20:38:57 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 25, 0 02:22:46 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: > > > What I'd like to see in the rfc1964 successor is either a definition > > for this mapping or a clear reference of such a mapping in another RFC > > (e.g. rfc1510bis). In particular, I'd like to see whether any service > > names must or must not be transformed into the "host" principal. > > I think you confusing things. The GSS-API does not perform any > mapping from > > ftp@kermit.columbia.edu > > to > > host/kermit.columbia.edu@CC.COLUMBIA.EDU > > when using Kerberos V. That is exactly what I am complaining about! If you insist on using a "portable" hostbased service name for applications, then I insist on using A SINGLE one. I.e. I want to require that telnet via GSS-API always use exactly "telnet@f.q.d.n", rlogin via GSS-API always use exactly "rlogin@f.q.d.n", ftp via GSS-API always use exactly "ftp@f.q.d.n", nfs via GSS-API always use exactly "nfs@f.q.d.n" No alternate trying of "host@f.q.d.n" permitted for the application (because this is a Kerberos mechanism-specific thingy). If Kerberos wants to share the host/f.q.d.n for several services, then it is up to the Kerberos GSS-API mechanism spec to define exactly how an when "telnet@f.q.d.n", "rlogin@f.q.d.n", "ftp@f.q.d.n", etc. are internally transformed into "host/f.q.d.n". > > When the GSSAPI-Kerberos_V FTP client creates a security context it > first calls gss_ini_sec_context() with the result of calling > gss_import_name() with the string "ftp@f.q.d.n". If the > authentication fails, it then silently tries again with > "host@f.q.d.n". There is no mapping within the GSSAPI implementation > from "ftp" to "host". This is simply part of the specification for > how GSSAPI is used with a specific application level protocol (such as > FTP.) This is exactly broken application behaviour to work around defects in the Kerberos GSS-API spec. Yuck! -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 Apr 25 15:22: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 PAA23473 for ; Tue, 25 Apr 2000 15:22:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA19345 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 11:57:34 -0700 (PDT) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA19318 for ; Tue, 25 Apr 2000 11:57:27 -0700 (PDT) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id OAA02293; Tue, 25 Apr 2000 14:57:15 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <200004202004.QAA28109@tsx-prime.MIT.EDU> Mime-Version: 1.0 From: Ken Raeburn Date: 25 Apr 2000 14:57:15 -0400 In-Reply-To: "Theodore Y. Ts'o"'s message of "Thu, 20 Apr 2000 16:04:41 -0400" Message-ID: Lines: 38 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk "Theodore Y. Ts'o" writes: > The problem is the extensions which are placed in the unencrypted part > of the ticket. If I recall correctly, ASN.1 makes no guarantees that > implementations which see unexpected fields will do anything sane, and > in fact the best you can hope for is that implementations will ignore > that which they do not understand. The problem is that when they then > re-encode the ticket, the new extended fields will get dropped, thus > breaking the crypto checksum on the ticket. This causes some severe > interoperability issues. If an ASN.1 implementation does something "insane" when parsing what it might consider "corrupted" input, it's absolutely not suitable for security software. But that should be an implementation issue, not an ASN.1 specification issue. As far as interoperability goes, haven't we already lost in some ways because of sender addresses becoming optional? If an application protocol using Kerberos doesn't specify the presence or absence of the address (i.e., which version of Kerberos 5 protocol to use), the only safe approach is to always include it -- and likewise, always omit ticket extensions. Most direct uses of Kerberos that I've seen don't have the flexibility to try once with the new protocol rev, then if it fails, try again in backwards-compatibility mode. With GSSAPI or SASL applications it may be possible, but that'd essentially be by treating new-Kerberos-5 and old-Kerberos-5 as two different mechanisms under the same name. > I think that recent MIT Krb5 implementations (although someone from MIT > should check me on this) have been modified to not give a parse failure > if they see an unknown/unexpected SEQUENCE OF element. This means that > putting a new extended element inside the encrypted part of the ticket > is far safer. I understand this doesn't fully meet the needs of some of > the uses for which you wanted to use the ticket extensions field; but > I'm not sure what else is actually safe to do. Tom did this because a DCE server was adding extra stuff to a sequence. (I don't remember which sequence though.) -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 15:31: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 PAA23713 for ; Tue, 25 Apr 2000 15:31:50 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id MAA19514 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:00:48 -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 MAA19509 for ; Tue, 25 Apr 2000 12:00:45 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA28481; Tue, 25 Apr 00 15:00:43 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA22321; Tue, 25 Apr 2000 15:00:41 -0400 (EDT) Date: Tue, 25 Apr 2000 15:00:41 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 20:38:57 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > If you insist on using a "portable" hostbased service name for applications, > then I insist on using A SINGLE one. > > I.e. I want to require that > telnet via GSS-API always use exactly "telnet@f.q.d.n", > rlogin via GSS-API always use exactly "rlogin@f.q.d.n", > ftp via GSS-API always use exactly "ftp@f.q.d.n", > nfs via GSS-API always use exactly "nfs@f.q.d.n" > > No alternate trying of "host@f.q.d.n" permitted for the application > (because this is a Kerberos mechanism-specific thingy). This is not a Kerberos mechansim specific thingy. This is a FTP GSSAPI-KERBEROS_V5 specific thingy. > If Kerberos wants to share the host/f.q.d.n for several services, > then it is up to the Kerberos GSS-API mechanism spec to define > exactly how an when "telnet@f.q.d.n", "rlogin@f.q.d.n", "ftp@f.q.d.n", > etc. are internally transformed into "host/f.q.d.n". Read my words: Your GSSAPI mechanism is NOT to perform any transformations of the service name as specified by the application. > This is exactly broken application behaviour to work around defects > in the Kerberos GSS-API spec. Yuck! There are no defects in the GSS-API spec. There are no mapping of service names in the GSS-API specification. You are creating something that does not exist. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 15:33: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 PAA23782 for ; Tue, 25 Apr 2000 15:33:55 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA19665 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:04:02 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA19658 for ; Tue, 25 Apr 2000 12:04:00 -0700 (PDT) Received: (qmail 24437 invoked from network); 25 Apr 2000 19:03:29 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 25 Apr 2000 19:03:29 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Tue, 25 Apr 2000 11:59:30 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Apr 2000 12:03:02 -0700 Message-ID: <80A473F584BED311810D0050DA289BD40F3F4B@corporate.cybersafe.com> From: Matt Hur To: "'deengert@anl.gov'" , "Theodore Y. Ts'o" Cc: Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: RE: Ticket extensions in Kerberos revisions Date: Tue, 25 Apr 2000 12:02:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFAEE8.E11C1A40" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFAEE8.E11C1A40 Content-Type: text/plain; charset="iso-8859-1" Doug, You would do this by putting the X.509 extension into a ticket extension. The ticket extension could be bound via a checksum in the authorization field. --Matt > -----Original Message----- > From: Douglas E. Engert [mailto:deengert@anl.gov] > Sent: Tuesday, April 25, 2000 11:10 AM > To: Theodore Y. Ts'o > Cc: Clifford Neuman; ietf-cat-wg@lists.Stanford.EDU; > krb-protocol@mit.edu > Subject: Re: Ticket extensions in Kerberos revisions > > > Ted, > > Your comments below on the ASN.1 and X.509 extensions brings > up an interesting > question. What would it take to allow a Kerberos ticket to > have a copy of > some x.509 extension? There might be some situations where > you might want > to have PK_INIT copy an extension, to the TGT or if you used > a Kerberos > ticket to get a certificate to copy the extension from the > ticket to the > certificate. Or possibly even with PK_INIT coping the > certificate chain > to the ticket. > > This might allow the authorization data to be transfered from > a certificate > to a ticket. > > "Theodore Y. Ts'o" wrote: > > > > Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT) > > From: Clifford Neuman > > > > 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 problem is the extensions which are placed in the > unencrypted part > > of the ticket. If I recall correctly, ASN.1 makes no > guarantees that > > implementations which see unexpected fields will do > anything sane, and > > in fact the best you can hope for is that implementations > will ignore > > that which they do not understand. The problem is that > when they then > > re-encode the ticket, the new extended fields will get dropped, thus > > breaking the crypto checksum on the ticket. This causes some severe > > interoperability issues. > > > > If we had added type-length-value array from the beginning to handle > > extensions, ala X.509, we would have been OK. > Unfortunately, we weren't > > far-sighted enough to do this. As a result, I don't think > we can put an > > unencrpyted extension. > > > > I think that recent MIT Krb5 implementations (although > someone from MIT > > should check me on this) have been modified to not give a > parse failure > > if they see an unknown/unexpected SEQUENCE OF element. > This means that > > putting a new extended element inside the encrypted part of > the ticket > > is far safer. I understand this doesn't fully meet the > needs of some of > > the uses for which you wanted to use the ticket extensions > field; but > > I'm not sure what else is actually safe to do. > > > > I believe ASN.1 has some special tag words that indicate > how unexpected > > fields should be handled; I don't know if they existed in the older > > versions of ASN.1, and we didn't use those keywords anyway. > > > > As I've said before, "Friends don't let friends use ASN.1". :-) > > > > - Ted > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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_01BFAEE8.E11C1A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ticket extensions in Kerberos revisions

Doug,

You would do this by putting the X.509 extension into = a ticket extension.  The ticket extension could be bound via a = checksum in the authorization field.

--Matt


> -----Original Message-----
> From: Douglas E. Engert [mailto:deengert@anl.gov]
> Sent: Tuesday, April 25, 2000 11:10 AM
> To: Theodore Y. Ts'o
> Cc: Clifford Neuman; = ietf-cat-wg@lists.Stanford.EDU;
> krb-protocol@mit.edu
> Subject: Re: Ticket extensions in Kerberos = revisions
>
>
> Ted,
>
> Your comments below on the ASN.1 and X.509 = extensions brings
> up an interesting
> question. What would it take to allow a = Kerberos ticket to
> have a copy of
> some x.509 extension? There might be some = situations where
> you might want
> to have PK_INIT copy an extension, to the TGT = or if you used
> a Kerberos
> ticket to get a certificate to copy the = extension from the
> ticket to the
> certificate. Or possibly even with PK_INIT = coping the
> certificate chain
> to the ticket.
>
> This might allow the authorization data to be = transfered from
> a certificate
> to a ticket. 
>
> "Theodore Y. Ts'o" wrote:
> >
> >    Date: Tue, 18 Apr 2000 = 21:31:23 -0700 (PDT)
> >    From: Clifford Neuman = <bcn@ISI.EDU>
> >
> >    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 problem is the extensions which are = placed in the
> unencrypted part
> > of the ticket.  If I recall = correctly, ASN.1 makes no
> guarantees that
> > implementations which see unexpected = fields will do
> anything sane, and
> > in fact the best you can hope for is that = implementations
> will ignore
> > that which they do not understand.  = The problem is that
> when they then
> > re-encode the ticket, the new extended = fields will get dropped, thus
> > breaking the crypto checksum on the = ticket.  This causes some severe
> > interoperability issues.
> >
> > If we had added type-length-value array = from the beginning to handle
> > extensions, ala X.509, we would have been = OK. 
> Unfortunately, we weren't
> > far-sighted enough to do this.  As a = result, I don't think
> we can put an
> > unencrpyted extension.
> >
> > I think that recent MIT Krb5 = implementations (although
> someone from MIT
> > should check me on this) have been = modified to not give a
> parse failure
> > if they see an unknown/unexpected SEQUENCE = OF element. 
> This means that
> > putting a new extended element inside the = encrypted part of
> the ticket
> > is far safer.  I understand this = doesn't fully meet the
> needs of some of
> > the uses for which you wanted to use the = ticket extensions
> field; but
> > I'm not sure what else is actually safe to = do.
> >
> > I believe ASN.1 has some special tag words = that indicate
> how unexpected
> > fields should be handled; I don't know if = they existed in the older
> > versions of ASN.1, and we didn't use those = keywords anyway.
> >
> > As I've said before, "Friends don't = let friends use ASN.1".   :-)
> >
> = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp; - Ted
>
> --
>
>  Douglas E. Engert  = <DEEngert@anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> = -++**=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_01BFAEE8.E11C1A40-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 15:47: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 PAA24147 for ; Tue, 25 Apr 2000 15:47:01 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA20530 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:23:02 -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 MAA20523 for ; Tue, 25 Apr 2000 12:22:59 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA15308; Tue, 25 Apr 00 14:58:34 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA21551; Tue, 25 Apr 2000 14:56:34 -0400 (EDT) Date: Tue, 25 Apr 2000 14:56:34 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: cat-ietf@mit.edu, krbdev@mit.edu Subject: Telnet GSSAPI Authentication was Re: LIKPEY issues (was Re: host based principal names) from CAT-WG mailing list In-Reply-To: Your message of Tue, 25 Apr 2000 14:09:09 -0400 Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > I agree, and _if_ we had a GSS-API authentication mechanism for telnet, > I would say that the only target name that should be tried would be > "host@f.q.d.n". > > (If there was going to be GSSAPI versions of telnet and rlogin, I > think everyone would agree they would all use "host@f.q.d.n" as a > service name). I would agree. Although we may not have the ability to make the choice. The Microsoft NT Services for Unix (SFU) group that is responsible for the Telnet implementation Windows 2000 has a problem. Their Telnet Server does not implement the AUTH KERBEROS_V5 option because it is incompatible with their Kerberos SSPI. When Windows 2000 is configured to use KERBEROS_V only it disables the only authentication method (NTLM) which is supported by the Telnet Server. This forces users to type plaintext usernames and passwords. It is my belief that if the SFU group decides to rectify this problem they will do so by creating a Telnet AUTH GSSAPI-KERBEROS_V method that uses the service name "telnet" and not "host". I have tried to contact Microsoft to find out what they plan to do but have not received any replies. In the past I have argued against the implememtation of a GSSAPI Telnet AUTH method on the grounds that it is not needed and the extra overhead of wrapping GSS around other protocols within a Telnet AUTH negotiation is unwarranted. But given the inability of using the traditional KERBEROS_V5 authentication method with Windows 2000, perhaps it has become necessary to define such a standard to head off the implementation of a KERBEROS_5 SSPI specific method; or the use of service names which we would disagree with. Anyone have an opinion on this matter? Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 16:00: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 QAA24569 for ; Tue, 25 Apr 2000 16:00:53 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA20803 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:27:15 -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 MAA20596 for ; Tue, 25 Apr 2000 12:24:12 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA07237; Tue, 25 Apr 00 15:24:10 EDT Received: from elvis.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 PAA04785 for ; Tue, 25 Apr 2000 15:24:09 -0400 (EDT) Message-Id: <200004251924.PAA04785@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of "Tue, 25 Apr 2000 20:38:57 +0200." <200004251838.UAA10344@hw1464.wdf.sap-ag.de> 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, 25 Apr 2000 15:24:07 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >If you insist on using a "portable" hostbased service name for applications, >then I insist on using A SINGLE one. > >I.e. I want to require that > telnet via GSS-API always use exactly "telnet@f.q.d.n", > rlogin via GSS-API always use exactly "rlogin@f.q.d.n", > ftp via GSS-API always use exactly "ftp@f.q.d.n", > nfs via GSS-API always use exactly "nfs@f.q.d.n" > >No alternate trying of "host@f.q.d.n" permitted for the application >(because this is a Kerberos mechanism-specific thingy). And the reason these various protocols can't all share a single "host" service name is ... ? (okay, for ftp it's already too late, and nfs has already been decided, but I don't see why telnet and rlogin can't simply be specified to both use "host"). >This is exactly broken application behaviour to work around defects >in the Kerberos GSS-API spec. Yuck! I think I'm with others on this one: it's a little late to complain about this aspect of GSSAPI authentication inside of ftp now. --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 Apr 25 16:11: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 QAA24802 for ; Tue, 25 Apr 2000 16:11:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22168 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:45: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 MAA22163 for ; Tue, 25 Apr 2000 12:45:47 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA13228; Tue, 25 Apr 00 15:45:45 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA02106; Tue, 25 Apr 2000 15:44:52 -0400 (EDT) Date: Tue, 25 Apr 2000 15:44:51 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: towusu@us.ibm.com Cc: mrex@sap-ag.de, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 14:36:00 -0500 Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > What about GSS_Canonicalize_name? Is that supposed to perform > transformation from "service@fqdn" to "service/fqdn@realm" when > the mech type is Kerberos? Exactly. That is the conversion from host based service name to Kerberos principal name. There are no mapping of the service name from one value to another. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 16:11: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 QAA24803 for ; Tue, 25 Apr 2000 16:11:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA21272 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:35:07 -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 MAA21267 for ; Tue, 25 Apr 2000 12:35:04 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA09897; Tue, 25 Apr 00 15:35:02 EDT Received: from elvis.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 PAA04928 for ; Tue, 25 Apr 2000 15:35:02 -0400 (EDT) Message-Id: <200004251935.PAA04928@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: Your message of "Fri, 14 Apr 2000 17:41:35 +0200." <200004141541.RAA25663@hw1464.wdf.sap-ag.de> 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, 25 Apr 2000 15:35:00 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Okay, this is a bit of an old message, but I was digging out of some old email, and I figured it was relevant ... From: Martin Rex >My oberservations of hostbased service names are: >[...] >- they are not available in many of gssapi mechanisms that > I have seen, in particular the public key based mechanisms Are there a _lot_ of GSSAPI mechanisms that I'm simply not aware of? The GSSAPI mechanisms that I know about are: - Kerberos 5 - DCE - SPKM - LIPKEY I know that Kerberos 5, DCE, and LIPKEY all support hostbased service names. I'm not sure about SPKM (but the spec says it's designed to be as compatible with Kerberos as it can, so I would guess that it would support host-based serivce names). Meta-observation: most of the code I'm aware of today that uses GSSAPI is using it as a way to provide Kerberos authentication to protocols & applications, and all of it is written to use host-based service names. If they're truely "not portable" (and I believe the consenses is that _are_ supposed to be portable) then any mechanism that doesn't implement host-based service names is going to be for an unpleasant surprise, to say the least. --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 Apr 25 16:11: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 QAA24828 for ; Tue, 25 Apr 2000 16:11:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA21440 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:37:52 -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 MAA21420 for ; Tue, 25 Apr 2000 12:37:48 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA10997; Tue, 25 Apr 00 15:37:42 EDT Received: from elvis.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 PAA04965; Tue, 25 Apr 2000 15:37:39 -0400 (EDT) Message-Id: <200004251937.PAA04965@ginger.cmf.nrl.navy.mil> To: jaltman@columbia.edu Cc: cat-ietf@mit.edu Subject: Re: Telnet GSSAPI Authentication was Re: LIKPEY issues (was Re: host based principal names) from CAT-WG mailing list In-Reply-To: Your message of "Tue, 25 Apr 2000 14:56:34 EDT." 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, 25 Apr 2000 15:37:37 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Telnet AUTH method on the grounds that it is not needed and the >extra overhead of wrapping GSS around other protocols within a >Telnet AUTH negotiation is unwarranted. But given the inability >of using the traditional KERBEROS_V5 authentication method with >Windows 2000, perhaps it has become necessary to define such a >standard to head off the implementation of a KERBEROS_5 SSPI specific >method; or the use of service names which we would disagree with. > >Anyone have an opinion on this matter? 1) Fix the dang Windows 2K SSPI (besides ... I thought that the Kerberos change password protocol uses raw Kerberos, and aren't they doing that?) 2) If 1) isn't possible, then use "host" as the service name!! --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 Apr 25 16:17: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 QAA24934 for ; Tue, 25 Apr 2000 16:17:09 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA21336 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:36:19 -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 MAA21330 for ; Tue, 25 Apr 2000 12:36:17 -0700 (PDT) From: towusu@us.ibm.com Received: from e21.nc.us.ibm.com by MIT.EDU with SMTP id AA02026; Tue, 25 Apr 00 15:38:14 EDT Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA15248; Tue, 25 Apr 2000 15:27:20 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA82152; Tue, 25 Apr 2000 15:36:12 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568CC.006BAD3A ; Tue, 25 Apr 2000 15:36:06 -0400 X-Lotus-Fromdomain: IBMUS To: jaltman@columbia.edu Cc: mrex@sap-ag.de, cat-ietf@mit.edu Message-Id: <852568CC.006BAAD4.00@d54mta03.raleigh.ibm.com> Date: Tue, 25 Apr 2000 14:36:00 -0500 Subject: Re: LIKPEY issues (was Re: host based principal names) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Jeffrey, What about GSS_Canonicalize_name? Is that supposed to perform transformation from "service@fqdn" to "service/fqdn@realm" when the mech type is Kerberos? --- Thomas Owusu Java Security towusu@us.ibm.com Jeffrey Altman @lists.Stanford.EDU on 04/25/2000 02:00:41 PM Please respond to jaltman@columbia.edu Sent by: owner-ietf-cat-wg@lists.Stanford.EDU To: mrex@sap-ag.de cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) > If you insist on using a "portable" hostbased service name for applications, > then I insist on using A SINGLE one. > > I.e. I want to require that > telnet via GSS-API always use exactly "telnet@f.q.d.n", > rlogin via GSS-API always use exactly "rlogin@f.q.d.n", > ftp via GSS-API always use exactly "ftp@f.q.d.n", > nfs via GSS-API always use exactly "nfs@f.q.d.n" > > No alternate trying of "host@f.q.d.n" permitted for the application > (because this is a Kerberos mechanism-specific thingy). This is not a Kerberos mechansim specific thingy. This is a FTP GSSAPI-KERBEROS_V5 specific thingy. > If Kerberos wants to share the host/f.q.d.n for several services, > then it is up to the Kerberos GSS-API mechanism spec to define > exactly how an when "telnet@f.q.d.n", "rlogin@f.q.d.n", "ftp@f.q.d.n", > etc. are internally transformed into "host/f.q.d.n". Read my words: Your GSSAPI mechanism is NOT to perform any transformations of the service name as specified by the application. > This is exactly broken application behaviour to work around defects > in the Kerberos GSS-API spec. Yuck! There are no defects in the GSS-API spec. There are no mapping of service names in the GSS-API specification. You are creating something that does not exist. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Tue Apr 25 16:19: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 QAA24976 for ; Tue, 25 Apr 2000 16:19:57 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22582 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:53:41 -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 MAA22575 for ; Tue, 25 Apr 2000 12:53:37 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA15572; Tue, 25 Apr 00 15:53:35 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id PAA12935; Tue, 25 Apr 2000 15:53:33 -0400 (EDT) Message-Id: <200004251953.PAA12935@small-gods.mit.edu> To: jaltman@columbia.edu Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of "Tue, 25 Apr 2000 15:00:41 EDT." Date: Tue, 25 Apr 2000 15:53:33 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Read my words: > Your GSSAPI mechanism is NOT to perform any transformations of the > service name as specified by the application. On what authority do you say this? It doesn't make sense for the application to be worrying about the service namespace of the mechanism, since the whole point of GSSAPI is to abstract away the details of the mechanisms. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 16:20: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 QAA25012 for ; Tue, 25 Apr 2000 16:20:26 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22116 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 12:45:09 -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 MAA22107 for ; Tue, 25 Apr 2000 12:45:06 -0700 (PDT) Received: from elvis.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 PAA05059; Tue, 25 Apr 2000 15:44:59 -0400 (EDT) Message-Id: <200004251944.PAA05059@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 "25 Apr 2000 14:57:15 EDT." 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, 25 Apr 2000 15:44:57 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >If an ASN.1 implementation does something "insane" when parsing what >it might consider "corrupted" input, it's absolutely not suitable for >security software. But that should be an implementation issue, not an >ASN.1 specification issue. I have been thinking for a while that an interoperability report w.r.t ticket extensions would be _really_ nice to see (then we could determine what will really all break). >Most direct uses of Kerberos that I've seen don't have the flexibility >to try once with the new protocol rev, then if it fails, try again in >backwards-compatibility mode. With GSSAPI or SASL applications it may >be possible, but that'd essentially be by treating new-Kerberos-5 and >old-Kerberos-5 as two different mechanisms under the same name. Well, when I last stared at the MIT Kerberos GSSAPI mechanism, it still uses the "old" mechanism OID (iso.org.dod.internet.security.kerberosv5). You could simply say that "new" Kerberos is everything that uses the "new" mechanism OID (iso.member-body.US.mit.infosys.gssapi.krb5). You'd probably want SPNEGO for that, though (and I'm not sure what happens when both sides don't support SPNEGO). --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 Apr 25 16:36: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 QAA25423 for ; Tue, 25 Apr 2000 16:36:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA23767 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 13:08:13 -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 NAA23760 for ; Tue, 25 Apr 2000 13:08:10 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA15148; Tue, 25 Apr 00 16:10:08 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id QAA06336; Tue, 25 Apr 2000 16:08:07 -0400 (EDT) From: Jeffrey Altman Date: Tue, 25 Apr 2000 16:08:07 EDT Reply-To: jaltman@columbia.edu To: Greg Hudson Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of Tue, 25 Apr 2000 15:53:33 -0400 Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > On what authority do you say this? It doesn't make sense for the > application to be worrying about the service namespace of the > mechanism, since the whole point of GSSAPI is to abstract away the > details of the mechanisms. > Whether the application uses "ftp@f.q.d.n" or "host@f.q.d.n" is not part of the GSSAPI mechanism. By saying that the GSSAPI mechanism is supposed to perform this translation would require that everytime someone decides to implement GSSAPI in a new application (for instance, "telnet"), every GSSAPI implementation would have to be updated to support the new entry. This is what makes no sense. The service name to be used is defined by the application protocol not by the GSSAPI. The exact same problem exists in applications that use Kerberos without the GSSAPI. You need to know what service name is used on the host. I know of several organizations which use alternate service names for Kerberos authentication instead of "host" because they want to be able to authorize access to some services and not all services on a given host. That is why my applications allows the end user to specify the service name to be used when authenticating to a host. It would be completely inappropriate for the GSSAPI to decide that it does not recognize "foo" as a service name and therefore translate it to "host". Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 17:32:25 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 RAA26643 for ; Tue, 25 Apr 2000 17:32:24 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA27367 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 14:05:14 -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 OAA27361 for ; Tue, 25 Apr 2000 14:05:11 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA08705; Tue, 25 Apr 00 17:07:05 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23977; Tue, 25 Apr 2000 14:05:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA15533; Tue, 25 Apr 2000 14:05:01 -0700 (PDT) Received: from teal (awe8-128.Central.Sun.COM [129.147.8.128]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3PL4wh849750; Tue, 25 Apr 2000 14:04:58 -0700 (PDT) Date: Tue, 25 Apr 2000 14:08:12 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: LIKPEY issues (was Re: host based principal names) To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004251838.UAA10344@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > That is exactly what I am complaining about! > > If you insist on using a "portable" hostbased service name for applications, > then I insist on using A SINGLE one. > > I.e. I want to require that > telnet via GSS-API always use exactly "telnet@f.q.d.n", > rlogin via GSS-API always use exactly "rlogin@f.q.d.n", > ftp via GSS-API always use exactly "ftp@f.q.d.n", > nfs via GSS-API always use exactly "nfs@f.q.d.n" > > No alternate trying of "host@f.q.d.n" permitted for the application > (because this is a Kerberos mechanism-specific thingy). Applications should be free to specify the name of principal used for the target. As an application writer you are free to use host@fqdn or @fqdn for your own applications. However, for better or worse, ftp and nfs do not require the use use of host@, and in the case of nfs, do not allow the use of host@. And there are RFCs for each that say that. I don't know what the treatment is for ldap, the dns transfer service, or anything else that uses GSS-API. I don't see that the inconsistency in target names among applications is much of an inconvenience. Each application protocol is unique, and the name used for the target is yet another aspect of the uniqueness. What would be extremely inconvient would be if each applciation/mechanism pair used a unique GSS-API name type. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 17:57: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 RAA27197 for ; Tue, 25 Apr 2000 17:57:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA28924 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 14:26:51 -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 OAA28918 for ; Tue, 25 Apr 2000 14:26:48 -0700 (PDT) Received: from [130.202.20.3] by MIT.EDU with SMTP id AA16081; Tue, 25 Apr 00 17:28:46 EDT Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA16673; Tue, 25 Apr 2000 16:23:11 -0500 (CDT) Message-Id: <39060CE9.66F0D4B8@anl.gov> Date: Tue, 25 Apr 2000 16:23:53 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: towusu@us.ibm.com Cc: jaltman@columbia.edu, mrex@sap-ag.de, cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) References: <852568CC.006BAAD4.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit towusu@us.ibm.com wrote: > > Jeffrey, > What about GSS_Canonicalize_name? Is that supposed to perform > transformation from "service@fqdn" to "service/fqdn@realm" when > the mech type is Kerberos? > Not clear. What you are really looking for is: gss_import_name(&ms, "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name_one); gss_canconicalize_name(&ms, name_one, mech_type, &name_two); gss_export_name(&ms,name_two, &buffer); -or- gss_display_name(&ms,name_two, &buffer, &oid); Would buffer then have "service/fqdn@realm" with oid = GSS_C_NO_OID or "service/host@realm" with oid = GSS_C_NO_OID or "service@host" with OID=GSS_C_NT_HOSTBASED_SERVICE or "service@fqdn" with OID=GSS_C_NT_HOSTBASED_SERVICE Since it is a host based service, the GSSAPI could be using DNS internally to convert host to fqdn too. What one would like to get is the first. > --- > Thomas Owusu > Java Security > towusu@us.ibm.com > > Jeffrey Altman @lists.Stanford.EDU on 04/25/2000 > 02:00:41 PM > > Please respond to jaltman@columbia.edu > > Sent by: owner-ietf-cat-wg@lists.Stanford.EDU > > To: mrex@sap-ag.de > cc: cat-ietf@mit.edu > Subject: Re: LIKPEY issues (was Re: host based principal names) > > > If you insist on using a "portable" hostbased service name for > applications, > > then I insist on using A SINGLE one. > > > > I.e. I want to require that > > telnet via GSS-API always use exactly "telnet@f.q.d.n", > > rlogin via GSS-API always use exactly "rlogin@f.q.d.n", > > ftp via GSS-API always use exactly "ftp@f.q.d.n", > > nfs via GSS-API always use exactly "nfs@f.q.d.n" > > > > No alternate trying of "host@f.q.d.n" permitted for the application > > (because this is a Kerberos mechanism-specific thingy). > > This is not a Kerberos mechansim specific thingy. This is a FTP > GSSAPI-KERBEROS_V5 specific thingy. > > > If Kerberos wants to share the host/f.q.d.n for several services, > > then it is up to the Kerberos GSS-API mechanism spec to define > > exactly how an when "telnet@f.q.d.n", "rlogin@f.q.d.n", "ftp@f.q.d.n", > > etc. are internally transformed into "host/f.q.d.n". > > Read my words: > > Your GSSAPI mechanism is NOT to perform any transformations of the > service name as specified by the application. > > > This is exactly broken application behaviour to work around defects > > in the Kerberos GSS-API spec. Yuck! > > There are no defects in the GSS-API spec. There are no mapping of > service names in the GSS-API specification. You are creating > something that does not exist. > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 > The Kermit Project * Columbia University > 612 West 115th St #716 * New York, NY * 10025 > http://www.kermit-project.org/k95.html * > kermit-support@kermit-project.org > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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 -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 25 18:07: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 SAA27413 for ; Tue, 25 Apr 2000 18:07:15 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA25250 for ietf-cat-wg-out720680; Tue, 25 Apr 2000 13:27:36 -0700 (PDT) Received: from dns2.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA25245 for ; Tue, 25 Apr 2000 13:27:34 -0700 (PDT) Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA13067; Tue, 25 Apr 2000 15:27:19 -0500 (CDT) Message-ID: <3905FFD1.C4D96C8D@anl.gov> Date: Tue, 25 Apr 2000 15:28:02 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Hur CC: "Theodore Y. Ts'o" , Clifford Neuman , ietf-cat-wg@lists.Stanford.EDU, krb-protocol@mit.edu Subject: Re: Ticket extensions in Kerberos revisions References: <80A473F584BED311810D0050DA289BD40F3F4B@corporate.cybersafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Matt Hur wrote: > > Doug, > > You would do this by putting the X.509 extension into a ticket extension. The ticket extension > could be bound via a checksum in the authorization field. The question was can current K5 implementations handle the ASN.1 used in X.509, other then the UDP size problems. > > --Matt > > > -----Original Message----- > > From: Douglas E. Engert [mailto:deengert@anl.gov] > > Sent: Tuesday, April 25, 2000 11:10 AM > > To: Theodore Y. Ts'o > > Cc: Clifford Neuman; ietf-cat-wg@lists.Stanford.EDU; > > krb-protocol@mit.edu > > Subject: Re: Ticket extensions in Kerberos revisions > > > > > > Ted, > > > > Your comments below on the ASN.1 and X.509 extensions brings > > up an interesting > > question. What would it take to allow a Kerberos ticket to > > have a copy of > > some x.509 extension? There might be some situations where > > you might want > > to have PK_INIT copy an extension, to the TGT or if you used > > a Kerberos > > ticket to get a certificate to copy the extension from the > > ticket to the > > certificate. Or possibly even with PK_INIT coping the > > certificate chain > > to the ticket. > > > > This might allow the authorization data to be transfered from > > a certificate > > to a ticket. > > > > "Theodore Y. Ts'o" wrote: > > > > > > Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT) > > > From: Clifford Neuman > > > > > > 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 problem is the extensions which are placed in the > > unencrypted part > > > of the ticket. If I recall correctly, ASN.1 makes no > > guarantees that > > > implementations which see unexpected fields will do > > anything sane, and > > > in fact the best you can hope for is that implementations > > will ignore > > > that which they do not understand. The problem is that > > when they then > > > re-encode the ticket, the new extended fields will get dropped, thus > > > breaking the crypto checksum on the ticket. This causes some severe > > > interoperability issues. > > > > > > If we had added type-length-value array from the beginning to handle > > > extensions, ala X.509, we would have been OK. > > Unfortunately, we weren't > > > far-sighted enough to do this. As a result, I don't think > > we can put an > > > unencrpyted extension. > > > > > > I think that recent MIT Krb5 implementations (although > > someone from MIT > > > should check me on this) have been modified to not give a > > parse failure > > > if they see an unknown/unexpected SEQUENCE OF element. > > This means that > > > putting a new extended element inside the encrypted part of > > the ticket > > > is far safer. I understand this doesn't fully meet the > > needs of some of > > > the uses for which you wanted to use the ticket extensions > > field; but > > > I'm not sure what else is actually safe to do. > > > > > > I believe ASN.1 has some special tag words that indicate > > how unexpected > > > fields should be handled; I don't know if they existed in the older > > > versions of ASN.1, and we didn't use those keywords anyway. > > > > > > As I've said before, "Friends don't let friends use ASN.1". :-) > > > > > > - Ted > > > > -- > > > > Douglas E. Engert > > Argonne National Laboratory > > 9700 South Cass Avenue > > Argonne, Illinois 60439 > > (630) 252-5444 > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > > 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 > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 13:47:52 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 NAA01094 for ; Wed, 26 Apr 2000 13:47:51 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA12691 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 10:11:39 -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 KAA12686 for ; Wed, 26 Apr 2000 10:11:36 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA26601; Wed, 26 Apr 00 13:11:31 EDT Received: from elvis.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 NAA15589 for ; Wed, 26 Apr 2000 13:11:30 -0400 (EDT) Message-Id: <200004261711.NAA15589@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) In-Reply-To: Your message of "Wed, 26 Apr 2000 18:47:32 +0200." <200004261647.SAA17776@hw1464.wdf.sap-ag.de> 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, 26 Apr 2000 13:11:29 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >I know that they currently don't use GSS-API. >However if any of those application protocols were expanded to use >GSS-API (directly or through SASL), a compiled-in hostbased service >name would have to be "rcmd@hostname", "imap@hostname", "pop@hostname", >"ftp@hostname", "nfs@hostname", but NEVER "host@hostname"! Let's address these individually: rcmd@hostname - rcmd is a leftover V4ism, nothing in the V5 world uses it anymore. imap@hostname,pop@hostname - Already defined and used for those protocols. There's no fallback to host@hostname. ftp@hostname - We already know all about this one :-) nfs@hostname - From what Mike has said, nfs@hostname is the only valid GSSAPI service name (that's correct, isn't it, Mike?) >There is an IANA registry for the services of hostbased service names > >"http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names" See, now this is a bit strange. How come rcmd was brought forward as a valid GSSAPI service name? The RFC referenced in the service name assignments for rcmd is a Telnet V4 RFC that predates GSSAPI! It sounds like to me that rcmd should be depreciated and replaced with host. >One should not confuse the abstract hostbased service names at >the GSS-API level with the specific hostbased service principals >of the Kerberos 5 GSS-API mechanism. It is up to the mechanism >to define the mapping, it doesn't need to be one-to-one and it >doesn't need to be fixed. The current spec rfc1964 doesn't define >any mapping at all and is therefore incomplete. Well, _that_ sounds like a bug in the spec to me. But I think everyone agrees here that current implementations don't do any mapping, nor is one required. >It is inappropriate to specify for GSS-API enabled application protocols >to use the hostbased service name "host@hostname" as the target name, >because that is Kerberos-specific and doesn't meet the GSS-API abstraction. Okay, so is your complaint that "host@hostname" isn't registered with IANA? That should be easy to fix. I don't think the intent is that "host@hostname" is supposed to be Kerberos-specific. >As I initially requested, it should be possible for a user to supply >a target name to perform a real target authentication, and the application >must support an arbitrary target name, if any, so that it doesn't >matter whether it is "host@hostname", "host/f.q.d.n@SOME-REALM" or >"CN=xyz-service, OU=division, O=company, C=DE" (note that the latter >two are mechanism specific names, usually imported without nametype OID. Well, my only answer to this is that it doesn't seem like support for arbitrary target names in GSS-API is in any IETF protocol today (they all seem to use host-based service names). There would need to be some serious thought as to how to fix this problem if people really want to use arbitrary target names. >> Seems relatively clear to me; what's the problem? (I would have personally >> chosen "host", though). > >At the GSS-API level, this is the wrong answer, because it is lacks >the abstraction. I'm not sure I know exactly what abstraction you're referring to. --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 Apr 26 13:48: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 NAA01106 for ; Wed, 26 Apr 2000 13:48:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA12978 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 10:17:22 -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 KAA12973 for ; Wed, 26 Apr 2000 10:17:19 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA20162; Wed, 26 Apr 00 12:48:31 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id SAA09493; Wed, 26 Apr 2000 18:44:53 +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 SAA17619; Wed, 26 Apr 2000 18:47:33 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id SAA17776; Wed, 26 Apr 2000 18:47:32 +0200 (METDST) From: Martin Rex Message-Id: <200004261647.SAA17776@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Wed, 26 Apr 2000 18:47:32 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004251522.LAA01980@ginger.cmf.nrl.navy.mil> from "Ken Hornstein" at Apr 25, 0 11:22:26 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: > > >> With respect to 2, both John and Ted have made arguments in favor of > >> host based service names. I don't see a consensus to change LIPKEY's > >> bias from host based service names. > > > >OK, I want to add hostbased service names to my W2K Kerberos SSP wrapper. > >Where is the spec for Kerberos that tells me how to map the hostbased > >service name into full Kerberos principal name. > >(i.e. "telnet", "ftp", "rcmd", "rlogin", "pop3", ...) > > > >My understanding is that many of the traditionally kerberized Unix services > >share the "host/f.q.d.n" key. What are the rules when using GSS-API? > > Martin, I was under the impression your complaint was with the use of > the hostname-based service name, not with the rules used to map service > names to Kerberos principals. As I understand it, the mapping between > the GSSAPI service name and Kerberos principal is very simple: > service@f.q.d.n maps to service/f.q.d.n@REALM. > > All of the traditional Kerberized Unix remote access utilities (with the > exception of ftp) don't use GSS-API. "host" in the Kerberos sense > traditionally is a key readable only by the root user on Unix, and all > of the services that require root level access (such as telnetd, rlogind) > share this key. If they did use the GSSAPI, I think all of their service > names would be "host@f.q.d.n". I know that they currently don't use GSS-API. However if any of those application protocols were expanded to use GSS-API (directly or through SASL), a compiled-in hostbased service name would have to be "rcmd@hostname", "imap@hostname", "pop@hostname", "ftp@hostname", "nfs@hostname", but NEVER "host@hostname"! There is an IANA registry for the services of hostbased service names "http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names" One should not confuse the abstract hostbased service names at the GSS-API level with the specific hostbased service principals of the Kerberos 5 GSS-API mechanism. It is up to the mechanism to define the mapping, it doesn't need to be one-to-one and it doesn't need to be fixed. The current spec rfc1964 doesn't define any mapping at all and is therefore incomplete. It would be ok for the Kerberos 5 gssapi mechanism to define that the GSS-API hostbased service name "rcmd@hostname" should be mapped to the service principal "rcmd/f.q.d.n@SOME-REALM" in general, but it could also specify that a implmenentation specific service name resolution might map it to the service principal "host/f.q.d.n@SOME-REALM" if the user or administrator defines this in their Kerberos configuration. It is inappropriate to specify for GSS-API enabled application protocols to use the hostbased service name "host@hostname" as the target name, because that is Kerberos-specific and doesn't meet the GSS-API abstraction. As I initially requested, it should be possible for a user to supply a target name to perform a real target authentication, and the application must support an arbitrary target name, if any, so that it doesn't matter whether it is "host@hostname", "host/f.q.d.n@SOME-REALM" or "CN=xyz-service, OU=division, O=company, C=DE" (note that the latter two are mechanism specific names, usually imported without nametype OID. > > >What Kerberos principal name is supposed to be used for nfs? > >Your Email seems to suggest that a nfs/f.q.d.n principal is required > >for that? I am very pleased that Mike wants to require support for the GSS-API hostbased service name "nfs@hostname". It would be ok for the Kerberos GSS-API mechanism to map this generic name into the Kerberos mechanism specific name "host/f.q.d.n@SOME-REALM". > > Seems relatively clear to me; what's the problem? (I would have personally > chosen "host", though). At the GSS-API level, this is the wrong answer, because it is lacks the abstraction. If one requires different hostbased service names, then it will be possible to run the services with independent credentials. It will also be possible to run the services with shared credentials, one only needs a mechanism-specific or an implementation specific service name resolution that maps the different abstract GSS-API names into the same principal. -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 Wed Apr 26 14:15:47 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 OAA01627 for ; Wed, 26 Apr 2000 14:15:47 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA14452 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 10:44:19 -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 KAA14447 for ; Wed, 26 Apr 2000 10:44:16 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA28622; Wed, 26 Apr 00 13:46:14 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22066; Wed, 26 Apr 2000 10:44:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA18089; Wed, 26 Apr 2000 10:44:11 -0700 (PDT) Received: from teal (awe8-105.Central.Sun.COM [129.147.8.105]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3QHiAh963330; Wed, 26 Apr 2000 10:44:10 -0700 (PDT) Date: Wed, 26 Apr 2000 10:47:23 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: LIKPEY issues (was Re: host based principal names) To: Ken Hornstein Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004261711.NAA15589@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 > nfs@hostname - From what Mike has said, nfs@hostname is the only valid > GSSAPI service name (that's correct, isn't it, Mike?) Correct. > >It is inappropriate to specify for GSS-API enabled application protocols > >to use the hostbased service name "host@hostname" as the target name, > >because that is Kerberos-specific and doesn't meet the GSS-API abstraction. > > Okay, so is your complaint that "host@hostname" isn't registered with > IANA? That should be easy to fix. I don't think the intent is that > "host@hostname" is supposed to be Kerberos-specific. The other complaint might be that host@hostname isn't mentioned in RFC 2743 (GSS-API). But that's a minor issue. I've always assumed that host@hostname was not intended to be Kerberos specific and vaugely recall discussion on cat about this. The reason why I didn't use it for NFS is what I said before: that NFs servers oare usually kernel resident, and this might cause problems for implementations on hosts that support r*, telnet, ftp, and nfs simultaneusly. This wouldn't be a problem for the Solaris implementation of NFS, but I try to to think of other operating environments. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 15:28: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 PAA03203 for ; Wed, 26 Apr 2000 15:28:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA20001 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 11:50:45 -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 LAA19994 for ; Wed, 26 Apr 2000 11:50:39 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA25144; Wed, 26 Apr 00 14:50:28 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id OAA20979; Wed, 26 Apr 2000 14:49:57 -0400 (EDT) Message-Id: <200004261849.OAA20979@small-gods.mit.edu> To: Mike Eisler Cc: cat-ietf@mit.edu Subject: GSSAPI service names (was Re: LIKPEY issues) In-Reply-To: Your message of "Wed, 26 Apr 2000 10:47:23 PDT." Date: Wed, 26 Apr 2000 14:49:56 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I don't think we can resolve this issue in a satisfactory way. The whole point of GSSAPI is that we have N services and M security mechanisms, and we would like to have O(M+N) bits of code instead of O(M*N) bits of code. But the mapping of GSSAPI service names to mechanism-specific service names is an inherently M*N thing; either the mechanism knows about all the services or the service knows about all the mechanisms. Using a configuration file instead of a hardcoded mapping would help, but it's still not very satisfactory. The only out is if we require all mechanisms to use the GSSAPI service name conventions, so that there is no mapping. But then we lose the ability to cleanly interface with any kind of preexisting key management practices for a security mechanism. Kerberos 5's "host" key is just the first example. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 15:37: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 PAA03405 for ; Wed, 26 Apr 2000 15:37:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA20749 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 12:06:51 -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 MAA20737 for ; Wed, 26 Apr 2000 12:06:47 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA06678; Wed, 26 Apr 00 15:08:41 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29419; Wed, 26 Apr 2000 12:06:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA10378; Wed, 26 Apr 2000 12:06:32 -0700 (PDT) Received: from teal (awe8-105.Central.Sun.COM [129.147.8.105]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3QJ6Uh980212; Wed, 26 Apr 2000 12:06:30 -0700 (PDT) Date: Wed, 26 Apr 2000 12:09:43 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: GSSAPI service names (was Re: LIKPEY issues) To: Greg Hudson Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004261849.OAA20979@small-gods.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > I don't think we can resolve this issue in a satisfactory way. > > The whole point of GSSAPI is that we have N services and M security > mechanisms, and we would like to have O(M+N) bits of code instead of > O(M*N) bits of code. But the mapping of GSSAPI service names to > mechanism-specific service names is an inherently M*N thing; either > the mechanism knows about all the services or the service knows about > all the mechanisms. Using a configuration file instead of a hardcoded > mapping would help, but it's still not very satisfactory. Or the mechanism is designed to map arbitrary things of form service@host to the underlying mechanism specific representation without the need to have mapping table. Kerberos V5 does this: the transformation from service@host is service/fqdn@REALM Regardless how the mechanism deals with it, there are still O(N) bits of application code. > The only out is if we require all mechanisms to use the GSSAPI service > name conventions, so that there is no mapping. But then we lose the Impossible. For example, in Kerberos V5, there is the notion of the REALM that is part of the full principal name. If GSS-API starts to dictate mechanism specific naming, then GSS-API will find few mechanisms it can work over. > ability to cleanly interface with any kind of preexisting key > management practices for a security mechanism. Kerberos 5's "host" > key is just the first example. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 16:15: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 QAA03967 for ; Wed, 26 Apr 2000 16:15:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA21688 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 12:21:27 -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 MAA21683 for ; Wed, 26 Apr 2000 12:21:24 -0700 (PDT) Received: from SMALL-GODS.MIT.EDU by MIT.EDU with SMTP id AA13431; Wed, 26 Apr 00 15:23:17 EDT Received: (from ghudson@localhost) by small-gods.mit.edu (8.9.3) id PAA21361; Wed, 26 Apr 2000 15:15:40 -0400 (EDT) Message-Id: <200004261915.PAA21361@small-gods.mit.edu> To: Mike Eisler Cc: cat-ietf@mit.edu Subject: Re: GSSAPI service names (was Re: LIKPEY issues) In-Reply-To: Your message of "Wed, 26 Apr 2000 12:09:43 PDT." Date: Wed, 26 Apr 2000 15:15:39 -0400 From: Greg Hudson Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Uh, we seem to have miscommunicated. When I was talking about "the mapping of service names," I meant mapping the actual name of the service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5 service "host". I wasn't talking about mapping the syntax of how you put the service name and the hostname together, or the mapping of adding a realm, or whatnot; that clearly doesn't require any knowledge of the applications. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 16:42:05 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 QAA04284 for ; Wed, 26 Apr 2000 16:42:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22009 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 12:28:32 -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 MAA21999 for ; Wed, 26 Apr 2000 12:28:28 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA01712; Wed, 26 Apr 00 15:27:59 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA20288 for ; Wed, 26 Apr 2000 21:24:55 +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 VAA22862 for ; Wed, 26 Apr 2000 21:26:49 +0200 (MET DST) Received: (from d019080@localhost) by uw1048.wdf.sap-ag.de (8.8.8+Sun/8.8.8) id VAA24217 for cat-ietf@mit.edu; Wed, 26 Apr 2000 21:26:50 +0200 (MET DST) From: Martin Rex Message-Id: <200004261926.VAA24217@uw1048.wdf.sap-ag.de> Subject: hostbased service names (or not) To: cat-ietf@mit.edu Date: Wed, 26 Apr 2000 21:26:50 +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 Mike Eisler wrote: > > Martin Rex wrote: > > > > What Kerberos principal name is supposed to be used for nfs? > > Your Email seems to suggest that a nfs/f.q.d.n principal is required > > for that? > > Yes it is. > > Getting way off topic here, but one reason I opted for "nfs" and not "host" > was that NFS servers often operate in a kernel environment and not a > user level environment, and I wanted to accommodate implementations that > might chose to keep the keytab information completely in the kernel. If > "host" were used, and the same machine supported a telnet service and an > nfs service, this would not be possible for such implementations. I'm really glad to hear the NFSv4 will require support for a the abstract hostbased service "nfs@hostname". Thanks Mike! Using "host@hostname" would have been a Kerberos-solution and not a portable GSS-API solution. At the GSS-API level, there should be a distinct service name for every application protocol, so that it is possible to run the services with different credentials. It is possible at the gssapi mechanism spec level to define that particular services should be mapped to a common target principal, or it can be an implementation issue to perform such a mapping, perhaps based on local or central configuration data. Jeffrey Altman wrote: > > There is no GSSAPI authentication method for "telnet". But if there > was it would use "host/f.q.d.n" since that is what the KERBEROS_V5 > AUTH method uses. Ken Hornstein wrote: > I agree, and _if_ we had a GSS-API authentication mechanism for telnet, > I would say that the only target name that should be tried would be > "host@f.q.d.n". I strongly object. GSS-API is an abstraction, the "host" service principal that kerberized applications traditionally share is Kerberos-specific. It MUST be "telnet@hostname", and the application doesn't care whether your kerberos implementation maps this into "host/f.q.d.n@SOME-REALM" or "telnet/f.q.d.n@SOME-REALM". Jeffrey Altman wrote: > > There is no mapping within the GSSAPI implementation from "ftp" to > "host". This is simply part of the specification for how GSSAPI > is used with a specific application level protocol (such as FTP.) Ken Hornstein wrote: > > I believe everyone would agree that you don't need to do any special > mapping between GSS-API service names and Kerberos principals; whatever > the protocol specifies as the service name will be the correct principal. > Of course, some protocols may specify more than one service name (like > ftp), but IMHO that's a protocol-specific issue. I object again! Every mechanism must do a mapping, and even Kerberos performs one. The current Kerberos practice seems to be to replace the hostname part with the FQDN from a DNS lookup. It would be just fine if Kerberos defined a similar "canonicalization" for the service part of a hostbased service name to allow sharing of service credentials, just as it seems to be done with the "host" service principal. If SPKM-based mechanisms that use X.509 certs would adopt hostbased service names (which I still doubt), they would have to define the mapping, and it would be more complex than replacing "@" with "/" and tacking on a REALM. Currently they expose the subject DN from the certificate in its full beauty, so you have to deal with "OU=", "L=", "O=", "C=" and a few other components. The way how SPKM and similar gssapi mechanisms are shipped and used today, it is impossible to algorithmically map a hostbased service name into a complete subject DN. The extra DN components for a particular installation are influenced by the CAs policy and the administrators gusto, and it varies considerably these days... That's why I would appreciate strict service naming rules for SPKM mechanisms, but personally, I think it is impossible to fit them into a GSS-API v2 mechanism together with X.500 DNs, because some of the necessary name transformations are impossible (i.e. populating ACLs via gss_export_name()). Greg Hudson wrote: > > Jeffrey Altman wrote: > > > > Martin Rex wrote: > > > If Kerberos wants to share the host/f.q.d.n for several services, > > > then it is up to the Kerberos GSS-API mechanism spec to define > > > exactly how an when "telnet@f.q.d.n", "rlogin@f.q.d.n", "ftp@f.q.d.n", > > > etc. are internally transformed into "host/f.q.d.n". > > > > Read my words: > > > > Your GSSAPI mechanism is NOT to perform any transformations of the > > service name as specified by the application. > > On what authority do you say this? It doesn't make sense for the > application to be worrying about the service namespace of the > mechanism, since the whole point of GSSAPI is to abstract away the > details of the mechanisms. Thanks Greg! I finally don't seem to be alone with my opinion that GSS-API is an abstraction and mechanism specs need to take this abstraction back into the real world with a clear specification. Jeffrey Altman wrote: > > Martin Rex wrote: > > > > This is exactly broken application behaviour to work around defects > > in the Kerberos GSS-API spec. Yuck! > > There are no defects in the GSS-API spec. There are no mapping of > service names in the GSS-API specification. You are creating > something that does not exist. I realize that you are a die-hard Kerberos enthusiast. However you're trying to wag a dog by it's tail. GSS-API is not simply a neat Kerberos API, but Kerberos 5 is one particular out of many existing GSS-API mechanism. Every mechanism needs to define its name syntax and the transformations of any generic nametypes to provide interoperability for the applications at the API level. Btw. every Kerberos 5 gssapi mechanism must transform hostbased service names into Kerberos principal names, because (1) they don't have a REALM and (2) the '@' characters would have to be quoted to be permitted within the name. rfc1964 is simply lacking the specification how to perform the mapping from the abstract hostbased service name into the Kerberos 5 mechanism specific "Kerberos Principal Name". rfc1964bis can either add the missing definition, or it can reference another standard that contains the definition. The current hints in some Kerberos documents for sharing the "host/f.q.d.n@SOME-REALM" service principal for serveral applications is something that might impact the definition of such a mapping (e.g. a [service_principal] section in krb5.conf). Kerberos-specific issues of sharing particular credentials are a mechanism-specific issue. It MUST be hidden from applications at the GSS-API level. We run our application server farms with an SPKM-like gssapi mechanism and share the server credentials across all the servers of a server farm. This eases our administration. As a result, our application can not possibly use hostbased service names as the target name. Thomas Owusu wrote: > > What about GSS_Canonicalize_name? Is that supposed to perform > transformation from "service@fqdn" to "service/fqdn@realm" when > the mech type is Kerberos? It depends on the particular Kerberos implementation. MIT Kerberos seems to perform the transformation immediately during gss_import_name(). gss_canonicalize_name() will ultimately have to map any name into the canonical mechanism specific name format for a generic gssapi mech. Jeffrey Altman wrote: > > There are a lot of benefits associated by being able to specify > either a global key for all services or individual keys for each > service. Obviously, it is an either/or situation. There are a lot of benefits with being able to share service credentials for a server farm/cluster. Traditional Kerberos 5 cannot solve this (replay cache problem). SPKM gssapi mechanisms don't have this limitation. Coincidentally, hostbased service names will not work for this scenario, one of the reasons why I don't like them. Ken Hornstein wrote: > > Martin Rex wrote: > > It is inappropriate to specify for GSS-API enabled application protocols > > to use the hostbased service name "host@hostname" as the target name, > > because that is Kerberos-specific and doesn't meet the GSS-API abstraction. > > Okay, so is your complaint that "host@hostname" isn't registered with > IANA? That should be easy to fix. I don't think the intent is that > "host@hostname" is supposed to be Kerberos-specific. Nope. Registering "host" with IANA would be very bad and misleading. The notion of "host" is a breach of the GSS-API abstraction level. The desire of Kerberos (admins) to share a common credential and reuse an existing service-key infrastructure for serveral services on a host is a (Kerberos) mechanism issue and not a GSS-API issue. On those grounds, my request for requiring a host-independent service name to share server credentials over multiple hosts of a server farm with SPKM would be just as valid as the requirement for hostbased service names from all gssapi mechanisms. Mike Eisler wrote: > > The other complaint might be that host@hostname isn't mentioned in RFC 2743 > (GSS-API). But that's a minor issue. I've always assumed that host@hostname > was not intended to be Kerberos specific and vaugely recall discussion on cat > about this. The reason why I didn't use it for NFS is what I said before: that > NFs servers oare usually kernel resident, and this might cause problems for > implementations on hosts that support r*, telnet, ftp, and nfs simultaneusly. > This wouldn't be a problem for the Solaris implementation of NFS, but I try > to to think of other operating environments. "host" is Kerberos specific, because it ignores the application/service that is acutally being requested and assumes that (1) there are shared credentials and (2) there is an almighty "root" account. Jeffrey Altman wrote: > > In the past I have argued against the implememtation of a GSSAPI > Telnet AUTH method on the grounds that it is not needed and the > extra overhead of wrapping GSS around other protocols within a > Telnet AUTH negotiation is unwarranted. But given the inability > of using the traditional KERBEROS_V5 authentication method with > Windows 2000, perhaps it has become necessary to define such a > standard to head off the implementation of a KERBEROS_5 SSPI specific > method; or the use of service names which we would disagree with. > > Anyone have an opinion on this matter? I don't know the details of kerberized telnet, but wasn't it insecure in that it didn't provide integrity protection on the datastream? I think the real network overhead of GSS-API framing is not as bad as some people make it sound. Compare the overheads of a) traditional password-based telnet over IPSEC or b) GSS-API protected telnet I haven't checked, but I assume the overhead is roughly the same. Ken Hornstein wrote: > > Are there a _lot_ of GSSAPI mechanisms that I'm simply not aware of? Yes there are. Besides DASS (rfc1507 -- maybe long dead), I have seen SESAME (Bull), 3 independent SPKMs, 2 other public-key based mechs, Keon Agent (SecurityDynamics), my own SAPNTLM mechanism (a gssapi wrapper for Microsoft Win32 NTLM SSP), a proprietary mechanism of a Swiss Bank. > > The GSSAPI mechanisms that I know about are: > > - Kerberos 5 > - DCE > - SPKM > - LIPKEY > > I know that Kerberos 5, DCE, and LIPKEY all support hostbased service > names. W2K Kerberos doesn't support GSS-API service names at the API. That's why I want to add it into my GSS-API wrapper to the W2K Kerberos SSP. However rfc1964 fails specify how this is to be done, and some people participating in this discussion have apparently not realized that this area is heavily underspecified. Microsoft seems to have implemented a different service name model. They probably encountered similar problems as all others that try to operate in a truely distributed environment. Even DCE realized that hostbased service names don't scale and invented abstract service names. Because of the underlying Kerberos protocol, the abstract service names still get translated into host-specific service principals internally. Could someone please verify whether DCE really supports the hostbased service nametype at the API level? Since the name-based Kerberos authentication is still available from DCE, this could be possible, but it is *NOT* implicit. There is another Kerberos-derived GSS-API mechanism called "SESAME". Last time I saw it, it didn't return the nametype OID for hostbased service names from gss_inquire_names_for_mech(). I assume they have more generic (i.e. hostindependent) service names. Keon Agent doesn't return the OID for hostbased service names from gss_inquire_names_for_mech() either. Face it, hostbased service names are Kerberos-specific. :) Ken Hornstein wrote: > > I'm not sure about SPKM (but the spec says it's designed to > be as compatible with Kerberos as it can, so I would guess that it > would support host-based serivce names). I'm afraid to tell you the bad news. Nope, none of 3 independent SPKM implementations I've seen and neither of the two other public key based mechanisms support hostbased service names. The simple problem is that nobody knows how to map between hostbased service names and X.500 DNs. Names at GSS-API require several features. Think not only of how to compare only one or both elements of a hostbased service name with parts of a X.500 DN in a similar stupid way how Web-Browsers match their URLs against a server certificate. There is gss_canonicalize_name() and gss_export_name() which must be able to populate an ACL. > > Meta-observation: most of the code I'm aware of today that uses GSSAPI > is using it as a way to provide Kerberos authentication to protocols & > applications, and all of it is written to use host-based service > names. If they're truely "not portable" (and I believe the consenses > is that _are_ supposed to be portable) then any mechanism that doesn't > implement host-based service names is going to be for an unpleasant > surprise, to say the least. The only way for applications to portably support arbitrary gssapi mechanisms is to provide a means for the user and/or administrator to pass an opaque target name to the gssapi mechanism. From the past discussion I read that this is even required for Kerberos, since people cannot make up their minds which services share which keys -- and a connect/fail/connect-again is not an acceptable solution. Maybe it never occured to you that you had to audit every single failed logon and needed to make sure that not a single one was an attempted break-in. You absolutely don't want applications that trial-and-error a list of target names, besides of the wasted resources. What scares me as a result from this discussion is how many people don't really care about really authenticating a target. Every single one that uses hostbased service names which are canonicalized via traditional DNS is guilty of not doing target authentication. 99.999% of HTTPS is done without target authentication. The reason why kerberized application are providing the target name is because they need to know for which service to request a ticket -- even if they actually don't care. Even the GSS-API spec unconditionally required a target name for gss_init_sec_context(), but it was finally relaxed before we finalized rfc2743. When the client doesn't care about the target's identity, it should not be required to provide a target name. It would be quite possible to write a Kerberos-based gssapi mechanism spec that would allow this: the first token exchange would simply request the service name from the target, the second round would perform the regular AP_REQ/AP_REP. Or even further: Don't use an a-priori target name for mutual authentication similar to what TLS does. Mutually prove your identities and decide after the "identity verification" whether you want to talk to this server or not. However there are some implicit requirements in the gss_*_name() calls of GSS-API v2 that limit the flexibility of what a GSS-API mechanism might support in this area. -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 Wed Apr 26 16:46: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 QAA04304 for ; Wed, 26 Apr 2000 16:46:12 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22548 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 12:40:42 -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 MAA22543 for ; Wed, 26 Apr 2000 12:40:39 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA21407; Wed, 26 Apr 00 15:42:33 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12333; Wed, 26 Apr 2000 12:40:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA17998; Wed, 26 Apr 2000 12:40:31 -0700 (PDT) Received: from teal (awe8-105.Central.Sun.COM [129.147.8.105]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3QJeTh984701; Wed, 26 Apr 2000 12:40:29 -0700 (PDT) Date: Wed, 26 Apr 2000 12:43:42 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: GSSAPI service names (was Re: LIKPEY issues) To: Greg Hudson Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004261915.PAA21361@small-gods.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Uh, we seem to have miscommunicated. When I was talking about "the > mapping of service names," I meant mapping the actual name of the > service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > service "host". I wasn't talking about mapping the syntax of how you ^^^^^^^^^^^^^^^^ > put the service name and the hostname together, or the mapping of > adding a realm, or whatnot; that clearly doesn't require any knowledge > of the applications. I don't consider "host" to be a Kerberos 5 specific service name. It's as generic as "ldap" , "ftp", or "nfs". If it's not registered with IANA, then it should be, since RFC 2228 refers to it. RFC 2228 (ftp security extensions), doesn't state or imply that any mapping from "ftp" to "host" should take place. I'm not advocating mapping the GSS-API service name for "telnet" to "host". If "telnet" is passwd to GSS-API, then GSS-API must pass "telnet" to the krb5 mechanism. If the telnet protocol is specified to use GSS-API with a target of "host", then telnet clients and servers should use "host". In the end, it's an application decision. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 17:18: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 RAA04784 for ; Wed, 26 Apr 2000 17:18:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA25297 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 13:24:17 -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 NAA25292 for ; Wed, 26 Apr 2000 13:24:14 -0700 (PDT) Received: from [130.202.20.3] by MIT.EDU with SMTP id AA20380; Wed, 26 Apr 00 16:24:12 EDT Received: from anl.gov (apollo.ctd.anl.gov [146.137.96.39]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA02955; Wed, 26 Apr 2000 15:24:10 -0500 (CDT) Message-Id: <39075095.CE57DBE1@anl.gov> Date: Wed, 26 Apr 2000 15:24:53 -0500 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en Mime-Version: 1.0 To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: LIKPEY issues (was Re: host based principal names) References: <200004261939.VAA18636@hw1464.wdf.sap-ag.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I don't think you understood the point I was trying to make. Is there any way to pass in a hostbased service name, and get back from gssapi what is the actual name that would be used? In Kerberos it would be the principal of service/fqdn@realm. This would allow an application to see how the gss converted the name, which would include the canoniclization of the hostname and the selection of the realm. In other words will gss_export_name return the derived principal name, or will/should it return service@host with the OID of the hostbased service? Then what about gss_inquire_context? There I assume it would return the principal name, as the contexti had been established. Martin Rex wrote: > > Douglas E. Engert wrote: > > > > towusu@us.ibm.com wrote: > > > What about GSS_Canonicalize_name? Is that supposed to perform > > > transformation from "service@fqdn" to "service/fqdn@realm" when > > > the mech type is Kerberos? > > > > > > > Not clear. What you are really looking for is: > > > > gss_import_name(&ms, "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name_one); > > gss_canconicalize_name(&ms, name_one, mech_type, &name_two); > > > > gss_export_name(&ms,name_two, &buffer); > > -or- > > gss_display_name(&ms,name_two, &buffer, &oid); > > > > Would buffer then have "service/fqdn@realm" with oid = GSS_C_NO_OID > > or "service/host@realm" with oid = GSS_C_NO_OID > > or "service@host" with OID=GSS_C_NT_HOSTBASED_SERVICE > > or "service@fqdn" with OID=GSS_C_NT_HOSTBASED_SERVICE > > > > Since it is a host based service, the GSSAPI could be using DNS internally to > > convert host to fqdn too. > > > > What one would like to get is the first. > > BEWARE! There are some implicit requirements set by the GSS-API spec > and the definition of some gss_*_name() calls that you don't seem > to know. > OK, the above was an example, the question was what name (and what OID) would be returned? > GSS_C_NO_OID was not allowed as output from gss_display_name() before > rfc2743. To allow lazy name evaluation, something that I needed > in my generic gssapi mechanism layer, a very specific exception was > added (quoting rfc2743, section 2.4.4 GSS_Display_Name): > > The GSS_C_NO_OID name type is to be returned only when the > corresponding internal name was created through import with > GSS_C_NO_OID. It is acceptable for mechanisms to normalize names > imported with GSS_C_NO_OID into other supported types and, therefore, > to display them with types other than GSS_C_NO_OID. > > In your above example, the first two names would have > to be accompanied by the nametype OID for a Kerberos Principal name. But which of the 4 would it be expected to return? > > -Martin -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 17:18: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 RAA04808 for ; Wed, 26 Apr 2000 17:18:34 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA26522 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 13:40:02 -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 NAA26508 for ; Wed, 26 Apr 2000 13:39:58 -0700 (PDT) Received: from smaug.wrq.com by MIT.EDU with SMTP id AA10374; Wed, 26 Apr 00 16:39:11 EDT 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 NAA16904 for ; Wed, 26 Apr 2000 13:35:45 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2650.21) id <205G4R7C>; Wed, 26 Apr 2000 13:35:44 -0700 Message-Id: <86EDBD151558D311BB5700508B2E03FC0336F631@pikachu.wrq.com> From: Joe Salowey To: cat-ietf@mit.edu Subject: RE: GSSAPI service names (was Re: LIKPEY issues) Date: Wed, 26 Apr 2000 13:35:40 -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 Applications need to define how they use GSSAPI, this includes how to name a service. For GSSAPI to be useful all GSSAPI mechanisms should be able to process the same service name. Additionally, the GSSAPI layer should not have to know anything about a particular application protocol. Applications that use GSSAPI such as ftp, nfs, pop, imap have defined service names. Telnet has no standard way to use GSSAPI, so it is not of relevant here. SASL specifies that an application needs to specify a service name (service@host) and that this service name is carried through if GSSAPI is used. Therefore an application that defines a SASL profile also defines a host based service name to be used in GSSAPI. If this is a problem then the SASL/GSSAPI spec needs to be fixed. It seems that this issue has come up before. There used to be a draft from John Myers that updated the SASL/GSSAPI interaction, I don't remember if it addressed these issues (does anyone have a copy?). Joe > -----Original Message----- > From: Greg Hudson [mailto:ghudson@mit.edu] > Sent: Wednesday, April 26, 2000 12:16 PM > To: Mike Eisler > Cc: cat-ietf@mit.edu > Subject: Re: GSSAPI service names (was Re: LIKPEY issues) > > > Uh, we seem to have miscommunicated. When I was talking about "the > mapping of service names," I meant mapping the actual name of the > service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5 > service "host". I wasn't talking about mapping the syntax of how you > put the service name and the hostname together, or the mapping of > adding a realm, or whatnot; that clearly doesn't require any knowledge > of the applications. > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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 Apr 26 17:23: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 RAA04938 for ; Wed, 26 Apr 2000 17:23:53 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id MAA22742 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 12:43:32 -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 MAA22732 for ; Wed, 26 Apr 2000 12:43:29 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA22400; Wed, 26 Apr 00 15:45:23 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA24069; Wed, 26 Apr 2000 21:39:54 +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 VAA23230; Wed, 26 Apr 2000 21:39:25 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA18636; Wed, 26 Apr 2000 21:39:26 +0200 (METDST) From: Martin Rex Message-Id: <200004261939.VAA18636@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: deengert@anl.gov Date: Wed, 26 Apr 2000 21:39:26 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <39060CE9.66F0D4B8@anl.gov> from "Douglas E. Engert" at Apr 25, 0 04:23:53 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 Douglas E. Engert wrote: > > towusu@us.ibm.com wrote: > > What about GSS_Canonicalize_name? Is that supposed to perform > > transformation from "service@fqdn" to "service/fqdn@realm" when > > the mech type is Kerberos? > > > > Not clear. What you are really looking for is: > > gss_import_name(&ms, "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name_one); > gss_canconicalize_name(&ms, name_one, mech_type, &name_two); > > gss_export_name(&ms,name_two, &buffer); > -or- > gss_display_name(&ms,name_two, &buffer, &oid); > > Would buffer then have "service/fqdn@realm" with oid = GSS_C_NO_OID > or "service/host@realm" with oid = GSS_C_NO_OID > or "service@host" with OID=GSS_C_NT_HOSTBASED_SERVICE > or "service@fqdn" with OID=GSS_C_NT_HOSTBASED_SERVICE > > Since it is a host based service, the GSSAPI could be using DNS internally to > convert host to fqdn too. > > What one would like to get is the first. BEWARE! There are some implicit requirements set by the GSS-API spec and the definition of some gss_*_name() calls that you don't seem to know. GSS_C_NO_OID was not allowed as output from gss_display_name() before rfc2743. To allow lazy name evaluation, something that I needed in my generic gssapi mechanism layer, a very specific exception was added (quoting rfc2743, section 2.4.4 GSS_Display_Name): The GSS_C_NO_OID name type is to be returned only when the corresponding internal name was created through import with GSS_C_NO_OID. It is acceptable for mechanisms to normalize names imported with GSS_C_NO_OID into other supported types and, therefore, to display them with types other than GSS_C_NO_OID. In your above example, the first two names would have to be accompanied by the nametype OID for a Kerberos Principal name. -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 Wed Apr 26 17:53: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 RAA05496 for ; Wed, 26 Apr 2000 17:53:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA28471 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 14:09:40 -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 OAA28466 for ; Wed, 26 Apr 2000 14:09:37 -0700 (PDT) Received: from gungnir.fnal.gov by MIT.EDU with SMTP id AA23085; Wed, 26 Apr 00 17:11:36 EDT Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA19716 for ; Wed, 26 Apr 2000 16:09:35 -0500 (CDT) Message-Id: <200004262109.QAA19716@gungnir.fnal.gov> To: cat-ietf@mit.edu From: "Matt Crawford" Subject: Re: hostbased service names (or not) In-Reply-To: Your message of Wed, 26 Apr 2000 21:26:50 +0200. <200004261926.VAA24217@uw1048.wdf.sap-ag.de> Date: Wed, 26 Apr 2000 16:09:35 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk They way I see it, the telnet, rsh and rlogin protocols all get you the same service, from a security point of view. They all let you run commands on the machine; they just wrap the presentation differently. NFS and ftp give you different services from the above. But if POP and IMAP were just a little less different, I'd consider them to be the same service in a different protocol wrapping also. > Using "host@hostname" would have been a Kerberos-solution and not > a portable GSS-API solution. At the GSS-API level, there should be > a distinct service name for every application protocol, so that > it is possible to run the services with different credentials. > [...] > I strongly object. GSS-API is an abstraction, the "host" service principal > that kerberized applications traditionally share is Kerberos-specific. > > It MUST be "telnet@hostname", and the application doesn't care whether > your kerberos implementation maps this into "host/f.q.d.n@SOME-REALM" > or "telnet/f.q.d.n@SOME-REALM". -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 26 17:57: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 RAA05517 for ; Wed, 26 Apr 2000 17:57:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA29548 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 14:24:06 -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 OAA29514 for ; Wed, 26 Apr 2000 14:24:00 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA27433; Wed, 26 Apr 00 17:25:59 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA28098; Wed, 26 Apr 2000 17:23:52 -0400 (EDT) Date: Wed, 26 Apr 2000 17:23:52 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: hostbased service names (or not) In-Reply-To: Your message of Wed, 26 Apr 2000 21:26:50 +0200 (MET DST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > I object again! Every mechanism must do a mapping, and even Kerberos > performs one. The current Kerberos practice seems to be to replace the > hostname part with the FQDN from a DNS lookup. It would be just fine > if Kerberos defined a similar "canonicalization" for the service part > of a hostbased service name to allow sharing of service credentials, > just as it seems to be done with the "host" service principal. Every mechanism does a format mapping. The mechansim MUST NOT change the data the application passes to the mechanism. > If SPKM-based mechanisms that use X.509 certs would adopt hostbased > service names (which I still doubt), they would have to define > the mapping, and it would be more complex than replacing "@" with "/" > and tacking on a REALM. Currently they expose the subject DN from > the certificate in its full beauty, so you have to deal with > "OU=", "L=", "O=", "C=" and a few other components. Exactly. The mechanism is not allowed to change the value of the data. All it can do is change the format of the data to ensure that the format is compatible with the GSSAPI exchange. > > Jeffrey Altman wrote: > > > > Martin Rex wrote: > > > > > > This is exactly broken application behaviour to work around defects > > > in the Kerberos GSS-API spec. Yuck! > > > > There are no defects in the GSS-API spec. There are no mapping of > > service names in the GSS-API specification. You are creating > > something that does not exist. > > I realize that you are a die-hard Kerberos enthusiast. However > you're trying to wag a dog by it's tail. GSS-API is not simply > a neat Kerberos API, but Kerberos 5 is one particular out of many > existing GSS-API mechanism. Funny, I seem to support quite a wide range of authentication methods: . X.509 certificates . Kerberos . SRP . S/Key I use them all... > Every mechanism needs to define its name syntax and the transformations > of any generic nametypes to provide interoperability for the applications > at the API level. Interoperability 'yes'. Tampering with the requested credentials 'no'. > Jeffrey Altman wrote: > > > > In the past I have argued against the implememtation of a GSSAPI > > Telnet AUTH method on the grounds that it is not needed and the > > extra overhead of wrapping GSS around other protocols within a > > Telnet AUTH negotiation is unwarranted. But given the inability > > of using the traditional KERBEROS_V5 authentication method with > > Windows 2000, perhaps it has become necessary to define such a > > standard to head off the implementation of a KERBEROS_5 SSPI specific > > method; or the use of service names which we would disagree with. > > > > Anyone have an opinion on this matter? > > I don't know the details of kerberized telnet, but wasn't it > insecure in that it didn't provide integrity protection on the > datastream? Privacy and integrity protection can be provided for telnet via TLS. The old telnet encryption option (which has nothing to do with a particular authentication option) does not provide integrity protection. That is why it is being replaced by TLS. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 27 03:02: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 DAA24627 for ; Thu, 27 Apr 2000 03:02:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA01707 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 23:28:02 -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 XAA01692 for ; Wed, 26 Apr 2000 23:27:58 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA06389; Thu, 27 Apr 00 02:27:56 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id IAA05996; Thu, 27 Apr 2000 08:24:56 +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 IAA13943; Thu, 27 Apr 2000 08:23:12 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id IAA21209; Thu, 27 Apr 2000 08:23:12 +0200 (METDST) From: Martin Rex Message-Id: <200004270623.IAA21209@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: jaltman@columbia.edu Date: Thu, 27 Apr 2000 08:23:11 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 26, 0 05:23:52 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: > > > I object again! Every mechanism must do a mapping, and even Kerberos > > performs one. The current Kerberos practice seems to be to replace the > > hostname part with the FQDN from a DNS lookup. It would be just fine > > if Kerberos defined a similar "canonicalization" for the service part > > of a hostbased service name to allow sharing of service credentials, > > just as it seems to be done with the "host" service principal. > > Every mechanism does a format mapping. The mechansim MUST NOT change > the data the application passes to the mechanism. This discussion is going round in circles. You apparently ignore completely what the GSS-API spec explicitly recommends and the abstraction model behind GSS-API. You also ignore what Kerberos will have to do and what each and every existing Kerberos gssapi mechanism actually does. Take MIT's Kerberos (at least this was the behaviour for beta6 -> v1.0.5): Pass in a hostbased service name via gss_import_name() and print the resulting name via gss_display_name(). You will realize that it was mapped into a Kerberos principal name, i.e. the '@' was replaced by a '/', the hostname part was canonicalized via DNS, and a REALM was appended. Whether the resulting service principal is "service/f.q.d.n@REALM-A" or "service/f.q.d.n@REALM-B" is beyond the control of the application as long as it sticks to hostbased service names. In MIT Kerberos, the [domain_realm] section of krb5.conf will be checked with the domain name of the canonicalized host to figure out in which REALM the host(based service) resides. > > > If SPKM-based mechanisms that use X.509 certs would adopt hostbased > > service names (which I still doubt), they would have to define > > the mapping, and it would be more complex than replacing "@" with "/" > > and tacking on a REALM. Currently they expose the subject DN from > > the certificate in its full beauty, so you have to deal with > > "OU=", "L=", "O=", "C=" and a few other components. > > Exactly. The mechanism is not allowed to change the value of the > data. All it can do is change the format of the data to ensure that > the format is compatible with the GSSAPI exchange. I'm sorry, but this is BS. Which part of the GSS-API spec is so misleading that it causes this confusion for you -- maybe we need to fix it? There is absolutely no requirement for GSS-API mechanisms that the target ever gets to know which target name the initiator has used or wants to authenticate. For the abstract GSS-API, the target name is only required as a reference value when doing target authentication. However there is a historical shortcoming in the Kerberos GSS-API mechanism that requires the presence of a target name even for unilateral authentication of the initiator by the acceptor. There is another misconception that you seem to have. The original purpose of authentication in GSS-API and in many applications is not to simply distinguish sessions, but to be able to recognize principals each and every time that they authenticate. Normally this is done with some sort of mapping table that contains the name of the principal and a (locally) unique key (UID,SID,UUID), under which authorization data and user profile information is keyed. Usually the intermediate unique key is only need to adapt to the access control list (ACL) structure of an underlying TCB. If authorization is handled completely within the application, the application ACL may directly contain the (externally) authenticated identities. There were some functions added to Version 2 of GSS-API which will enable ACL maintenance for applications. The requirement is, that every valid name can be canonicalized and be used to populate a binary ACL before the referenced identity even authenticates for the first time to this application. If an application imports "service@host" with a Kerberos GSS-API mechanism and puts it into its ACL, it will be remembered as "service/f.q.d.n@REALMA". Now when the [domain_realm] part of krb5.conf is changed, or when the "host" entry in DNS is made a CNAME referencing a different host, then "service@host" may suddenly resolve to "service/f.q.d.n@REALMB". This change will go unnoticed by the target name to gss_init_sec_context(), but it will certainly show when the application receives a request from said service and no longer find a matching ACL entry. In a truely distributed environment there are no distinct users and services, everything takes every role and authentications are performed in both directions alike. Just as Kerberos does not require hostbased users, it should not require hostbased services. The reason why it does is the replay cache problem with the authenticators. This makes me wonder: is there any protection of users against replay of service tickets from the KDC? > > > > > Jeffrey Altman wrote: > > > > > > Martin Rex wrote: > > > > > > > > This is exactly broken application behaviour to work around defects > > > > in the Kerberos GSS-API spec. Yuck! > > > > > > There are no defects in the GSS-API spec. There are no mapping of > > > service names in the GSS-API specification. You are creating > > > something that does not exist. > > > > I realize that you are a die-hard Kerberos enthusiast. However > > you're trying to wag a dog by it's tail. GSS-API is not simply > > a neat Kerberos API, but Kerberos 5 is one particular out of many > > existing GSS-API mechanism. > > Funny, I seem to support quite a wide range of authentication methods: > > . X.509 certificates > . Kerberos > . SRP > . S/Key > > I use them all... Wow - Great! You seem to be a mighty wizard. Please share the wisdom with us how to map between hostbased service names and X.509 certificates, because none of us has been able to come up with a solution so far. > > > Every mechanism needs to define its name syntax and the transformations > > of any generic nametypes to provide interoperability for the applications > > at the API level. > > Interoperability 'yes'. Tampering with the requested credentials 'no'. Tampering with credentials? You're taking the GSS-API spec backwards again. An application can not supply credentials to a gssapi mechanism via the regular GSS-API (ignoring Ted's proposed interactive query here). Did you realize that for GSS-API v1 it was not even required that a process could acquire credentials by name (only default credentials were required -- despite the fact that default Kerberos acceptor credentials are underspecified!). It took me a while to convince people that support for requesting credentials by name should be in the base 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 Thu Apr 27 03:22: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 DAA24788 for ; Thu, 27 Apr 2000 03:22:01 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA02557 for ietf-cat-wg-out720680; Wed, 26 Apr 2000 23:43: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 XAA02552 for ; Wed, 26 Apr 2000 23:43:05 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA07028; Thu, 27 Apr 00 02:45:04 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id IAA09870; Thu, 27 Apr 2000 08:40:05 +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 IAA14642; Thu, 27 Apr 2000 08:39:28 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id IAA21291; Thu, 27 Apr 2000 08:39:28 +0200 (METDST) From: Martin Rex Message-Id: <200004270639.IAA21291@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: crawdad@fnal.gov (Matt Crawford) Date: Thu, 27 Apr 2000 08:39:28 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004262109.QAA19716@gungnir.fnal.gov> from "Matt Crawford" at Apr 26, 0 04:09:35 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 Matt Crawford wrote: > > They way I see it, the telnet, rsh and rlogin protocols all get you > the same service, from a security point of view. They all let you > run commands on the machine; they just wrap the presentation > differently. NFS and ftp give you different services from the > above. But if POP and IMAP were just a little less different, I'd > consider them to be the same service in a different protocol wrapping > also. If your only tool is a hammer, everything looks just like a nail.. The GSS-API abstraction will classify "telnet", "rsh" and "rlogin" as individual and distinct applications and provide independent hostbased service names for each of them. This is the abstraction level of GSS-API. On all C2-level or less Unix systems these services offer the same level of access and are run with the same privileges. It would be ok to share the gssapi service credentials for these services provided that the employed gssapi mechanism supports this sharing. It is tradition with Kerberos to share these credentials and therefore it would be a sensible action to expand the Kerberos gssapi mechanism and define a mapping of the "telnet", "rlogin" and "rsh" services to the same "host" service principal. AGAIN, this is not an application issue and not a GSS-API issue!!! (I will bring a clue-x-4 to the Pittsburgh IETF meeting...) It might not be obvious for you, but it would be quite possible to have a gssapi mechanism that uses credentials on a SmartCard and does not allow multi-process access to this credential, so that sharing of the credential, even for applications providing the same level of access is not possible. This is well within the spec of GSS-API, and applications must not discriminate such a GSS-API mechanism by assuming shared credentials for any independent applications. -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 Apr 27 04:44: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 EAA25218 for ; Thu, 27 Apr 2000 04:44:35 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id AAA05943 for ietf-cat-wg-out720680; Thu, 27 Apr 2000 00:58:44 -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 AAA05934 for ; Thu, 27 Apr 2000 00:58:41 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA16611; Thu, 27 Apr 00 04:00:40 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id JAA06155; Thu, 27 Apr 2000 09:55:11 +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 JAA17291; Thu, 27 Apr 2000 09:54:25 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id JAA21705; Thu, 27 Apr 2000 09:54:25 +0200 (METDST) From: Martin Rex Message-Id: <200004270754.JAA21705@hw1464.wdf.sap-ag.de> Subject: Re: LIKPEY issues (was Re: host based principal names) To: deengert@anl.gov Date: Thu, 27 Apr 2000 09:54:24 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <39075095.CE57DBE1@anl.gov> from "Douglas E. Engert" at Apr 26, 0 03:24:53 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 Douglas E. Engert wrote: > > I don't think you understood the point I was trying to make. > > Is there any way to pass in a hostbased service name, and get back > from gssapi what is the actual name that would be used? Yes and no. After a long and hard battle, gss_export_name() was added which requires the ability to create a canonical name *binary* blob to populate ACLs. Although the GSS-API spec itself does not require a printable canonical name, most gssapi mechanism implementations will provide you with one anyhow when you perform the following function calls: gss_import_name( "service@host", GSS_C_NT_HOSTBASED_SERVICE, &name ); gss_canonicalize_name( name, mech_oid, &cname ) gss_display_name( cname, &buffer &nametype_oid ) For some mechanisms it will work without calling gss_canonicalize_name(), however portable applications shouldn't rely on this feature. MIT Kerberos will always return Kerberos principal names from gss_display_name() accompanied by the GSS_KRB5_NT_PRINCIPAL_NAME nametype oid, i.e. one can see the result of the transformation that was applied to a hostbased service name, and this transformation is a performed mostly locally (don't forget the DNS lookup). I therefore find it hard to mimic this exact behaviour with the service name resolution that Microsoft Kerberos offers. I don't want to imply that Microsoft's approach is wrong. My perception is rather that it was wrong trying to push the service name resolution down into GSS-API, because this will not work for host-independent service names, where one needs to lookup the pair of the transport endpoint and a particular service instance from a secure naming service. Why are the printable names not guaranteed to be canonical? Quoting historic CAT discussion: > From: "Theodore Ts'o" > Date: Fri, 28 Jul 1995 14:14:58 -0400 > Subject: Re: errata > > [...] > > I don't know about other implementations, though --- do they make this > guarantee today? And is it acceptable to make gss_display_name() always > return a canonical form that doesn't change no matter what your locale > is? Remember, gss_display_name() is supposed to return something that's > suitable for human consumption. > > To take an example, if your X.500 name is: > > /Country=United States of America/Organizational Unit=Massachusetts > Institute of Technology/Organizational Unit=Information Systems/ > Organizational Unit=Distributed Computing and Network Services/ > Common Name=Theodore Y. Ts'o > > ...and the locale is set to Spain, wouldn't you want gss_display_name() > to return something started with: "/Pais=Los Estados Unidos...."? And > if you were in France (or your environment variable indicated you wanted > the French locale), would gss_display_name() would return something like > "/Pays=...."? Douglas E. Engert wrote: > > Then what about gss_inquire_context? There I assume it would return > the principal name, as the contexti had been established. Yes and no, see above. gss_inquire_context() returns a gss_name_t, not a printable. Use either gss_display_name() or gss_export_name() with mentioned characteristics. gss_inquire_context() must return a mechanism-specific name, so one doesn't need to call gss_canonicalize_name() for it. Douglas E. Engert wrote: > > In Kerberos it would be the principal of service/fqdn@realm. > This would allow an application to see how the gss converted the name, > which would include the canoniclization of the hostname and the > selection of the realm. I remember when we installed our application at the MIT in sprint 1996 and Ted Ts'o configured a hostbased service name, but security context establishment always failed. Looking at the KDC syslog info we saw that a service ticket was requested, but for the wrong f.q.d.n. I suggested checking the hosts file on the Sun workstation we were using and that turned out to be the culprit. (It was not the first problem that we encountered, that's why it took us ~5 minutes to spot this problem.) It is one of the reasons why I decided to avoid hostbased service names. I consider Ted a Kerberos wizard, and I really don't want to offend him by disclosing that even wizards can occasionally get confused by their own magic for a few seconds. ;-) In fact, during the past couple of year I found Ted to be an extremely valuable advisor on many GSS-API and security issues. In particular I am very grateful that he always explained to me, exactly and carefully, when and how I was breaching the GSS-API abstraction when I entered the discussion of the GSS-API v2 spec during 1995. And I think I since have learned a lot about GSS-API and I know precisely what I'm talking about. -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 Apr 27 05:47: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 FAA25549 for ; Thu, 27 Apr 2000 05:47:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id CAA08823 for ietf-cat-wg-out720680; Thu, 27 Apr 2000 02:18:01 -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 CAA08816 for ; Thu, 27 Apr 2000 02:17:57 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA23794; Thu, 27 Apr 00 05:17:55 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id LAA05866; Thu, 27 Apr 2000 11:14:56 +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 LAA21313; Thu, 27 Apr 2000 11:17:34 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id LAA22237; Thu, 27 Apr 2000 11:17:34 +0200 (METDST) From: Martin Rex Message-Id: <200004270917.LAA22237@hw1464.wdf.sap-ag.de> Subject: Re: GSSAPI service names (was Re: LIKPEY issues) To: mre@Eng.Sun.COM Date: Thu, 27 Apr 2000 11:17:34 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Mike Eisler" at Apr 26, 0 12:43:42 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 Mike Eisler wrote: > > > Uh, we seem to have miscommunicated. When I was talking about "the > > mapping of service names," I meant mapping the actual name of the > > service, e.g. mapping the GSSAPI service "telnet" to the Kerberos 5 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > service "host". I wasn't talking about mapping the syntax of how you > ^^^^^^^^^^^^^^^^ > > put the service name and the hostname together, or the mapping of > > adding a realm, or whatnot; that clearly doesn't require any knowledge > > of the applications. > > I don't consider "host" to be a Kerberos 5 specific service name. It's as > generic as "ldap" , "ftp", or "nfs". If it's not registered with IANA, then it > should be, since RFC 2228 refers to it. RFC 2228 (ftp security extensions), > doesn't state or imply that any mapping from "ftp" to "host" should take place. Of course it is Kerberos specific. It doesn't refer to the service as the GSS-API abstraction requires, it refers to a shared host key under the assumption that the service has access to a common host key that is used with Kerberos. It is wrong for the application to make assumptions about the underlying security architecture. It is particularly wrong for initiator side of an application to make assumptions about the security architecture of the gssapi mechanism implementation that the acceptor side is using. > > I'm not advocating mapping the GSS-API service name for "telnet" to "host". If > "telnet" is passwd to GSS-API, then GSS-API must pass "telnet" to the krb5 > mechanism. Which intermediate layer "GSS-API" between the application and the krb5 mechanism are your talking of? The krb5 gssapi mechanism spec (rfc1964bis) must define whether and how abstract hostbased services are to be mapped to Kerberos 5 principal names. And it would be appropriate if it required to map the abstract services "telnet", "rsh" and "rlogin" all to the "host" service instance. But in order not to limit future development of Kerberos, it should probably rather define there should be an implementation-specific configuration option that will cause this mapping, rather than requiring a hardcoded mapping. > > If the telnet protocol is specified to use GSS-API with a target of "host", > then telnet clients and servers should use "host". In the end, it's an > application decision. No, its not. I'm strongly opposed to register "host" with IANA to cover the rfc2228 error. Since "host" is already mentioned in rfc2228 for ftp, IANA should refuse to register it with any other application, even after the error in rfc2228 is corrected. -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 Apr 27 10:56: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 KAA01568 for ; Thu, 27 Apr 2000 10:56:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA12872 for ietf-cat-wg-out720680; Thu, 27 Apr 2000 07:16:22 -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 HAA12867 for ; Thu, 27 Apr 2000 07:16:19 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA14630; Thu, 27 Apr 00 10:16:17 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id KAA15713; Thu, 27 Apr 2000 10:15:37 -0400 (EDT) Date: Thu, 27 Apr 2000 10:15:36 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: hostbased service names (or not) In-Reply-To: Your message of Thu, 27 Apr 2000 08:23:11 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Wow - Great! You seem to be a mighty wizard. And now you are just being condescending. > Please share the wisdom with us how to map between hostbased service names > and X.509 certificates, because none of us has been able to come up > with a solution so far. It is the same problem that exists with regards to mapping userid's to X.509 certificates. Given the current lack of an infrastructure of trust and real standards for what goes into a certificate it is not possible to receive a certificate issued by a semi-trusted third party and really accept the data inside the certificate. Because of this fundamental problem which I have seen handled in different ways at different organizations, all of my applications provide either callbacks or other user defined implementations to perform the mappings from certificates to entities. Many sites issue certificates without any identifying information and simply perform database comparisions from the cert to the entity. In someways this illustrates my point. I understand that GSSAPI is supposed to give an application designer the appropriate credentials for a given "hostbased service name". If I make a connection to a host on port 3000 what service am I using? Is there a mapping from port number to service? Some might say 'yes'. Simply call getservbyport() and use the service name that is returned. But I know of plenty of sites that run services on non-standard ports. If I have established a connection on a port that implements a custom application protocol and I decide to use GSSAPI to authenticate; and I call my service "frisbee". Since "frisbee" is not a IANA registered service name what is GSSAPI (in your opinion) supposed to do? Shouldn't it attempt to find a matching credential for that hostbased service name "frisbee@f.q.d.n" and fail if it can't? Is it up to the application designer to determine which credentials s/he wants? If I as the application request the credentials for "frisbee@f.q.d.n" and GSSAPI can't get them; or the negotiation fails; doesn't it make sense that I might want to try an alternate route to getting my job done? Maybe my rules say . first attempt to use the really efficient "frisbee" service . but if the service is not accessible use "rsh" and do things some other way In that case, I would (according to you) as for "frisbee@f.q.d.n" and then "rsh@f.q.d.n". This is not any different by an application first attempting to use "ftp@f.q.d.n" and then using "host@f.q.d.n" as a fallback. Depending on the model, it may be that the "frisbee@f.q.d.n" credential is very specific to the service that it can be used for and provides higher levels of access whereas "host@f.q.d.n" is more general purpose and provides a lower level of access that might happen to be sufficient for the application. It doesn't matter whether these credentials are Kerberos principals, X.509 certificates, or anything else. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 27 15:47:47 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 PAA05866 for ; Thu, 27 Apr 2000 15:47:46 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA27978 for ietf-cat-wg-out720680; Thu, 27 Apr 2000 12:08: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 MAA27971 for ; Thu, 27 Apr 2000 12:08:41 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil by MIT.EDU with SMTP id AA21922; Thu, 27 Apr 00 15:08:39 EDT Received: from elvis.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 PAA28274 for ; Thu, 27 Apr 2000 15:08:25 -0400 (EDT) Message-Id: <200004271908.PAA28274@ginger.cmf.nrl.navy.mil> To: cat-ietf@mit.edu Subject: Re: hostbased service names (or not) In-Reply-To: Your message of "Thu, 27 Apr 2000 08:23:11 +0200." <200004270623.IAA21209@hw1464.wdf.sap-ag.de> 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, 27 Apr 2000 15:08:23 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >You apparently ignore completely what the GSS-API spec explicitly >recommends and the abstraction model behind GSS-API. This I believe is part of the problem. I think that very few people truely understand GSSAPI. I certainly don't think that I do. But I have at least read some of the GSSAPI RFC's, and I don't believe I know what you're referring to when you say "what the GSS-API spec explicitly recommends", and I _certainly_ don't understand the abstraction model; it's never clearly explained (IMHO). I mean yes, I understand that GSS-API is supposed to abstract out the details of the way the security mechanism works, but I don't agree that the use of "host" as a service name violates any fundamental abstraction that _I've_ read about. I'd welcome corrections, of course. Some observations about this whole discussion: - Martin, you are the _only_ person arguing that host-based service names are not portable. Everyone else disagrees with you, and I'm not talking about nutballs like me; both Cliff Newmann and John Linn (who's name is actually _on_ the GSS-API spec) say that the host-based service names have always been intended to be mechanism independent. The specification also disagrees with you; section 4.1 of RFC 2743 says "Support for this name form is recommended to mechanism designers _in the interests of portability_, but is not mandated by this specification". In my mind, that is rather unambiguously saying that host-based service names are intended to be portable. - The arguments you make about "host" being shared among services also apply to the IANA registered service for "rcmd", do they not? But I see that "host" has already been specified in RFC 2743, _and_ in fact the whole service name sharing concept (again, from section 4.1). Documents specifying means for GSS integration into a particular protocol should state either: (a) that a specific IANA-registered name associated with that protocol shall be used for the "service" element (this admits, if needed, the possibility that a single name can be registered and shared among a related set of protocols), or (b) that the generic name "host" shall be used for the "service" element, or (c) that, for that protocol, fallback in specified order (a, then b) or (b, then a) shall be applied. It seems to me that what RFC 2228 describes for GSSAPI and FTP is perfectly allowable in light of RFC 2743, and in fact sharing "host" among telnet/rlogin/rsh is perfectly fine. - I have not been able to find an example of an IETF protocol that uses GSSAPI and _doesn't_ use host-based service names. If we really shouldn't be using them as portable names, us folks in CAT have really screwed up in telling the rest of IETF "this is how you use GSSAPI in your protocol". - While the whole discussion about associating services with hosts versus abstract service names probably should be a seperate thread, I feel I must point out that one of the drawbacks to doing this is a lowering of security (because if one machine is compromised, all machines that use this service will be compromised). Also, you _could_ have designed a application protocol that used host-based service names (it didn't even have to use DNS for the host identification part); certainly the use of distributed services doesn't preclude the use of host-specific names. - Your objections to the use of Secure DNS to secure the canonicalization of hostnames seems to be mostly political rather than technical. >In a truely distributed environment there are no distinct users and >services, everything takes every role and authentications are performed >in both directions alike. Just as Kerberos does not require hostbased >users, it should not require hostbased services. The reason why it does >is the replay cache problem with the authenticators. This makes me >wonder: is there any protection of users against replay of service >tickets from the KDC? There isn't, actually, but this in particular isn't a problem, because you still need the TGT session key to unlock the reply from the KDC (and if you have _that_, you already know enough to make a legitimate service ticket request). --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 Apr 27 23:07:12 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 XAA12255 for ; Thu, 27 Apr 2000 23:07:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA21402 for ietf-cat-wg-out720680; Thu, 27 Apr 2000 19:22:43 -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 TAA21397 for ; Thu, 27 Apr 2000 19:22:40 -0700 (PDT) Received: from TSX-PRIME.MIT.EDU by MIT.EDU with SMTP id AA22066; Thu, 27 Apr 00 22:24:40 EDT Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id WAA22824; Thu, 27 Apr 2000 22:22:31 -0400 Date: Thu, 27 Apr 2000 22:22:31 -0400 Message-Id: <200004280222.WAA22824@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Mike Eisler Cc: Ken Hornstein , cat-ietf@mit.edu In-Reply-To: Mike Eisler's message of Wed, 26 Apr 2000 10:47:23 -0700 (PDT), Subject: Re: LIKPEY issues (was Re: host based principal names) Phone: (781) 391-3464 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Date: Wed, 26 Apr 2000 10:47:23 -0700 (PDT) From: Mike Eisler The other complaint might be that host@hostname isn't mentioned in RFC 2743 (GSS-API). But that's a minor issue. I've always assumed that host@hostname was not intended to be Kerberos specific and vaugely recall discussion on cat about this. But it *is* mentioned in RFC 2743. Take a closer look at section 4.1 on page 85. It specifically talks about the generic "host" service name. Sorry for not chiming in on this discussion earlier, but between being spammed by the discussion on the ietf mailing lists, and now on the cat-ietf list (never has more bits been killed over something which is already specified in the RFC :-), I'm a bit behind on all of my e-mail..... - 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 Fri Apr 28 10:12: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 KAA01702 for ; Fri, 28 Apr 2000 10:12:40 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA07216 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 06:43:38 -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 GAA07211 for ; Fri, 28 Apr 2000 06:43:35 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA07424; Fri, 28 Apr 00 09:45:34 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id PAA22952; Fri, 28 Apr 2000 15:40:02 +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 PAA13891; Fri, 28 Apr 2000 15:39:44 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id PAA00832; Fri, 28 Apr 2000 15:39:43 +0200 (METDST) From: Martin Rex Message-Id: <200004281339.PAA00832@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 28 Apr 2000 15:39:43 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <200004271908.PAA28274@ginger.cmf.nrl.navy.mil> from "Ken Hornstein" at Apr 27, 0 03:08:23 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 Ken Hornstein wrote: > > >You apparently ignore completely what the GSS-API spec explicitly > >recommends and the abstraction model behind GSS-API. > > This I believe is part of the problem. > > I think that very few people truely understand GSSAPI. I certainly > don't think that I do. But I have at least read some of the > GSSAPI RFC's, and I don't believe I know what you're referring to > when you say "what the GSS-API spec explicitly recommends", and > I _certainly_ don't understand the abstraction model; it's never > clearly explained (IMHO). I mean yes, I understand that GSS-API > is supposed to abstract out the details of the way the security > mechanism works, but I don't agree that the use of "host" as a service > name violates any fundamental abstraction that _I've_ read about. > I'd welcome corrections, of course. The notion that two independent applications *must* be able to share an identity (and therefore a credential) is an obvious breach of the GSS-API abstraction. 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 think the idea of sharing a single generic name for applications is invalid at the GSS-API level. It is very valid and useful to allow sharing of identities (=credentials) at the mechanism level, provided that the mechanism is capable of doing that. > > Some observations about this whole discussion: > > - Martin, you are the _only_ person arguing that host-based service > names are not portable. Everyone else disagrees with you, and I'm > not talking about nutballs like me; both Cliff Newmann and John Linn > (who's name is actually _on_ the GSS-API spec) say that the > host-based service names have always been intended to be mechanism > independent. Maybe I'm the only one that uses gssapi mechanisms that don't support hostbased service names. Facts are: - there are several gssapi mechanisms that do not support the GSS_C_NT_HOSTBASED_SERVICE oid. None of the public key based mechanisms (SPKM and related) has it. Maybe its a simple bug that SecurityDynamics KeonAgent doesn't return the OID in the set from gss_inquire_names_for_mech(). - Only the Kerberos gssapi mechanism defines a mechanism specific nametype "Kerberos principal name". (btw. rfc1964bis should address UTF8 names and their encoding) - 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. - None of the available mechanism specification properly defines a mapping between the generic nametypes at the gssapi level and the mechanism specific nametype of the mechanism. Because of the simple structure of Kerberos principal names and the codesharing tradition among Kerberos implementors, we do have interoperable name mappings in most implementations. However I still see battles on Kerberos naming in various places: the case of the realm name, the determination of a realm for a particular host (this directly affects the implementation of hostbased service names), and the mapping of service names that Microsoft has implemented. This is a clear indicator that Kerberos names were underspecified in previous specs. I want to add an interoperable hostbased service name implementation to my GSS-API v2 wrapper to the W2K Kerberos SSP, that's why I have been asking for the exact spec -- rfc1964 is incomplete. > > The specification also disagrees with you; section 4.1 > of RFC 2743 says "Support for this name form is recommended to > mechanism designers _in the interests of portability_, but is not > mandated by this specification". In my mind, that is rather > unambiguously saying that host-based service names are intended > to be portable. They are intended to be portable, and they may even be the most portable nametype that is currently contained in rfc2743. Fact is, they are not portable, because non-Kerberos mechanisms haven't defined a mapping and as a result not implemented them. If the LIPKEY spec is not updated to specify how to perform the authentication of an X.509-based server identity with the hostbased service name it will be guaranteed to result in non-interoperable API implementations. Interoperability on the wire is not enough, GSS-API is an API! To me, it sounded like Mike has a LIPKEY implementation. At least he should publish how it implements the authentication and maybe we can refine the example into a requirement for the spec to allow interoperable independent implementations to happen. > > - The arguments you make about "host" being shared among services also > apply to the IANA registered service for "rcmd", do they not? But I > see that "host" has already been specified in RFC 2743, _and_ in fact > the whole service name sharing concept (again, from section 4.1). > > Documents specifying means for GSS integration into a particular > protocol should state either: > > (a) that a specific IANA-registered name associated with that > protocol shall be used for the "service" element (this admits, if > needed, the possibility that a single name can be registered and > shared among a related set of protocols), or > > (b) that the generic name "host" shall be used for the "service" > element, or > > (c) that, for that protocol, fallback in specified order (a, then > b) or (b, then a) shall be applied. > > It seems to me that what RFC 2228 describes for GSSAPI and FTP is > perfectly allowable in light of RFC 2743, and in fact sharing "host" > among telnet/rlogin/rsh is perfectly fine. It is *broken* to specify procedures that will cause authentication failures. rfc2228 has exactly this potential. One may find fail-back modes ok for human interactions, but for services talking to other services the overhead of resource-wasting fail-backs must be avoided. Authentication failures may be particularly annoying, because they fill up audit logs and may set off alarms. And frequent false alarms will significantly drain attention from real alarms. > > - I have not been able to find an example of an IETF protocol that uses > GSSAPI and _doesn't_ use host-based service names. If we really > shouldn't be using them as portable names, us folks in CAT have > really screwed up in telling the rest of IETF "this is how you use > GSSAPI in your protocol". Because they don't know better. Some of the application developers may have Kerberos experience, and some may have even tried with the Kerberos gssapi mechanism and some may have even read rfc2078/2743 and bought into section 4.1. vision of a portable hostbased service name. SPKM and related gssapi mechanisms and a few others are only available for $$$, if at all, and they take a considerable effort for installation and creation of credentials, that's probably the reason why none of the apps guys has ever tried any of them. I think we should write a BCP for GSS-API use and the common pitfalls, like the assumption that hostbased service names are available and portable accross (non-Kerberos) gssapi mechanisms. > > - While the whole discussion about associating services with hosts > versus abstract service names probably should be a seperate thread, I > feel I must point out that one of the drawbacks to doing this is a > lowering of security (because if one machine is compromised, all > machines that use this service will be compromised). Also, you > _could_ have designed a application protocol that used host-based > service names (it didn't even have to use DNS for the host > identification part); certainly the use of distributed services > doesn't preclude the use of host-specific names. Yes, host-independent service names and their resolution into a pair of (target name, transport endpoint) should be a seperate thread. We didn't write our own gssapi mechanism, we bought one. And it does *not* implement hostbased service names, just like every other SPKM and related gssapi mechanism with X.509 certs that I have seen. > > - Your objections to the use of Secure DNS to secure the canonicalization > of hostnames seems to be mostly political rather than technical. Not completely. There is a technical issue in that the registration of DNS domains as well as the assignment of hostnames within organizations is (a) insecure, (b) performed on a first-come first-serve basis and (c) unreliable because of ownership transfer over (trademark) disputes. I haven't looked at any of the Secure DNS specs, but I'm convinced that it causes plenty of security illusions with a lot of people. I doubt that it will be possible for anyone to come up with a secure trustmodel for secure DNS that is still manageable. Blind trust in a single root will open myriads of tiny security vulnerabilities, and attackers will figure out ways to widen one or the other to an actual hole whenever they need it. > > >In a truely distributed environment there are no distinct users and > >services, everything takes every role and authentications are performed > >in both directions alike. Just as Kerberos does not require hostbased > >users, it should not require hostbased services. The reason why it does > >is the replay cache problem with the authenticators. This makes me > >wonder: is there any protection of users against replay of service > >tickets from the KDC? > > There isn't, actually, but this in particular isn't a problem, because > you still need the TGT session key to unlock the reply from the KDC > (and if you have _that_, you already know enough to make a legitimate > service ticket request). I didn't say that I want to look inside the ticket. I just remembered that Ted once told me the key for a service ticket was used to seed the generation of session keys on the assumption it is "fresh and hasn't been used before". I know to little about how and where entropy is gathered in Kerberos, and I was wondering about the motivation of key derivation discussion. -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 Fri Apr 28 12:19: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 MAA04941 for ; Fri, 28 Apr 2000 12:19:15 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA10962 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 08:47:27 -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 IAA10957 for ; Fri, 28 Apr 2000 08:47:24 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA21467; Fri, 28 Apr 00 11:49:24 EDT Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21852; Fri, 28 Apr 2000 08:47:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA06141; Fri, 28 Apr 2000 08:47:20 -0700 (PDT) Received: from teal (awe8-103.Central.Sun.COM [129.147.8.103]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e3SFlIh341442; Fri, 28 Apr 2000 08:47:18 -0700 (PDT) Date: Fri, 28 Apr 2000 08:50:29 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: hostbased service names (or not) To: mrex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: "Your message with ID" <200004281339.PAA00832@hw1464.wdf.sap-ag.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > 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. There's absolutely nothing that is Kerberos V5 specific about it. > - 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. > If the LIPKEY spec is not updated to specify how to perform the > authentication of an X.509-based server identity with the hostbased > service name it will be guaranteed to result in non-interoperable > API implementations. Interoperability on the wire is not enough, > GSS-API is an API! TLS doesn't specify this, and interoperability is achieved. I don't see why the fact that GSS-API is an API has anything to do with it. > To me, it sounded like Mike has a LIPKEY implementation. At least > he should publish how it implements the authentication and maybe As I've said before, I don't have an implementation. > we can refine the example into a requirement for the spec to > allow interoperable independent implementations to happen. The above doesn't parse at all. Any proposed standard has an implicit requirement to allow interoperable independent implementations. You claim that the existing LIPKEY/SPKM-3 specification is insufficient to allow multiple interoperable implementations to exist. You might be right. However, until independent implementations are attempted, we won't know, and when we know, we can update the LIPKEY rfc to further specify the issues in question before advancing to Draft. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 28 14:52:47 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 OAA08837 for ; Fri, 28 Apr 2000 14:52:45 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA20225 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 11:23:16 -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 LAA20220 for ; Fri, 28 Apr 2000 11:23:14 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA19791; Fri, 28 Apr 00 14:23:11 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id UAA20715 for ; Fri, 28 Apr 2000 20:20:09 +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 UAA23518 for ; Fri, 28 Apr 2000 20:17:55 +0200 (MET DST) Received: (from d019080@localhost) by uw1048.wdf.sap-ag.de (8.8.8+Sun/8.8.8) id UAA27642 for cat-ietf@mit.edu; Fri, 28 Apr 2000 20:17:55 +0200 (MET DST) From: Martin Rex Message-Id: <200004281817.UAA27642@uw1048.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) Orig-To: mre@Eng.Sun.COM To: cat-ietf@mit.edu Date: Fri, 28 Apr 2000 20:17:37 +0200 (METDST) 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. > > There's absolutely nothing that is Kerberos V5 specific about it. > > > - 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. We're not discussing wire-protocol compatibility (which all SPKM gssapi mechanism implementations have), we're discussion GSS-API level application interoperability, more specifically the interoperability of names/nametypes. GSS-API is also an API, and LIPKEY a gssapi mechanism. I suspect that your LIPKEY mechanisms will not interoperate on server authentication, probably they will simply not authenticate servers. > > > If the LIPKEY spec is not updated to specify how to perform the > > authentication of an X.509-based server identity with the hostbased > > service name it will be guaranteed to result in non-interoperable > > API implementations. Interoperability on the wire is not enough, > > GSS-API is an API! > > TLS doesn't specify this, and interoperability is achieved. I don't see > why the fact that GSS-API is an API has anything to do with it. Because they don't care a penny about authentication. They verify signatures, verify certificate trust pathes and skip the authentication. -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 Fri Apr 28 14:53: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 OAA08858 for ; Fri, 28 Apr 2000 14:53:05 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA20092 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 11:19:51 -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 LAA20068 for ; Fri, 28 Apr 2000 11:19:45 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA18416; Fri, 28 Apr 00 14:19:43 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA09305; Fri, 28 Apr 2000 14:19:42 -0400 (EDT) Date: Fri, 28 Apr 2000 14:19:41 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: hostbased service names (or not) In-Reply-To: Your message of Fri, 28 Apr 2000 20:08:38 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Which credentials can be our should be shared is extremely dependent > on the capabilities of the gssapi mechanism as well as the habits > and policies of the system administration. The application should > neither make assumptions nor set requirements in this area, because > that will definitely reduce the portability across gssapi mechanisms > and computing environments. > so really we disagree on whether or not System Administrators should be allowed to set policy via the applications as opposed to the GSSAPI mechansim. Since the GSSAPI mechanism may not allow policy to be set the application should be able to enforce the policy of the system administration. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 28 14:54: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 OAA08925 for ; Fri, 28 Apr 2000 14:54:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA19692 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 11:13:17 -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 LAA19687 for ; Fri, 28 Apr 2000 11:13:14 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA16103; Fri, 28 Apr 00 14:13:11 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id UAA18698; Fri, 28 Apr 2000 20:10:12 +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 UAA22936; Fri, 28 Apr 2000 20:08:38 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id UAA01584; Fri, 28 Apr 2000 20:08:38 +0200 (METDST) From: Martin Rex Message-Id: <200004281808.UAA01584@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: jaltman@columbia.edu Date: Fri, 28 Apr 2000 20:08:38 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 27, 0 10:15:36 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 Jeffrey Altman wrote: > > > Please share the wisdom with us how to map between hostbased service names > > and X.509 certificates, because none of us has been able to come up > > with a solution so far. > > It is the same problem that exists with regards to mapping userid's to > X.509 certificates. Given the current lack of an infrastructure of > trust and real standards for what goes into a certificate it is not > possible to receive a certificate issued by a semi-trusted third party > and really accept the data inside the certificate. > > Because of this fundamental problem which I have seen handled in > different ways at different organizations, all of my applications > provide either callbacks or other user defined implementations to > perform the mappings from certificates to entities. Many sites issue > certificates without any identifying information and simply perform > database comparisions from the cert to the entity. I think it is just fine to map an opaque certificate directly to a user via a database/directory. I don't know the details, but isn't this actually how certificate-based logons work in W2K with the Active Directory? The drawback is, that one needs to get hold of each certificate to put it into the database and verify the association of a human being with a user account oneself. Keep the opaque certificate in your mapping table. Basically you map from the contained public key and ignore everything else. - PROs: - it is independent of the CAs naming convention and policies, - you don't need to trust the CA - you don't need a particular(ly expensive) CA - when the keypair was not created by the CA, only the public key is signed by it, then this mapping is even secure when the CA is corrupted - you don't need a PKI - you can yourself control the quality of the association between a user (account) and a certificate, independent of the policies and qualities of the CAs whose certs your users are using. - CONs: - certificate rollover (expiration/loss/replacement) in your mapping table requires administrative action - if you're operating PKI-less, you may have to implement manual access revocation procedures. - you have to check the association of a user (account) with a certificate yourself, because there is no common pool of (trusted) information that you can use. > > In someways this illustrates my point. I understand that GSSAPI is > supposed to give an application designer the appropriate credentials > for a given "hostbased service name". If I make a connection to a > host on port 3000 what service am I using? > > Is there a mapping from port number to service? > > Some might say 'yes'. Simply call getservbyport() and use the service > name that is returned. But I know of plenty of sites that run > services on non-standard ports. We run services on >600 non-standard ports :-) The TCP port that you use shouldn't really matter, the application protocol that you use is the one that should count. On Unix machines it is quite easy to run sshd (or telnetd/rlogind/...) on an arbitrary port, just by adding an extra line to /etc/inetd.conf. One might be doing it to get around access list on some routers... > > If I have established a connection on a port that implements a custom > application protocol and I decide to use GSSAPI to authenticate; and > I call my service "frisbee". Since "frisbee" is not a IANA > registered service name what is GSSAPI (in your opinion) supposed to > do? The gssapi mechanism spec of the mechanism that you're using should tell you how/whether this can be mapped to a principal at all. If you were going to use one of the existing SPKM gssapi mechanisms, it wouldn't really matter, since every conceivable hostbased service name would fail equally. Having the user or administrator supply the names of targets and credentials in full-length mechanism-specific syntax will work in all cases, all environments and with all mechanisms. > > Shouldn't it attempt to find a matching credential for that hostbased > service name "frisbee@f.q.d.n" and fail if it can't? > > Is it up to the application designer to determine which credentials > s/he wants? I think it should be up to the human being that installs the application to create, install and configure the credentials. This is what our application requires and it has since worked with every gssapi mechanism that popped up. Being able to plug an arbitrary never-having-seen-before gssapi mechanism into an application and getting it run without having to recompile the application is what I consider application "portability" in the GSS-API sense. The devil is in the details, because the GSS-API spec is extremely flexible in some areas. If for example a programmer of a non-trivial application only had exposure to a SPKM gssapi mechanism, he may be surprized when tries to use the product with the Kerberos gssapi mechanism and it doesn't work because the executables started by the user find themselves unable to accept security contexts. In a distributed environment, this limitation of rfc1964 might be a showstopper. Btw. the Microsoft W2K Kerberos SSP doesn't have this limitation. ;-) > > If I as the application request the credentials for "frisbee@f.q.d.n" > and GSSAPI can't get them; or the negotiation fails; doesn't it make > sense that I might want to try an alternate route to getting my job > done? Our application guys even circumvent or disable security to get their job done when they run into "access denied" problems. "Don't force it, use a bigger hammer!" Security-wise it's a bad idea to promote trial-and-error approaches. Every time when access of a remote file on Windows NT via UNC-syntax fails with a logon failure, it will increase the logon failure counter by 3, because under the hood it performs some retries (I don't know the exact details). Our domain admin has set a lockout count at 12, and some components of our distributed build environment access remote files via shares. I don't know why exactly it happens, but in the past few month my account was locked out 5 times because of some strange bugs in Microsofts networking that sometimes cause network logon failures. And since the make environment requests files via UNC from 5 different servers, using the build process once during such a strange network confusion will lock out my account. :-(( > > Maybe my rules say > > . first attempt to use the really efficient "frisbee" service > > . but if the service is not accessible use "rsh" and do things > some other way > > In that case, I would (according to you) as for "frisbee@f.q.d.n" > and then "rsh@f.q.d.n". This is not any different by an application > first attempting to use "ftp@f.q.d.n" and then using "host@f.q.d.n" > as a fallback. ... the shotgun approach: Kill 'em all, let's God sort them out. It is a bad idea to specify an try-and-error approach when it can easily be avoided. > > Depending on the model, it may be that the "frisbee@f.q.d.n" > credential is very specific to the service that it can be used for > and provides higher levels of access whereas "host@f.q.d.n" is > more general purpose and provides a lower level of access that might > happen to be sufficient for the application. It doesn't matter > whether these credentials are Kerberos principals, X.509 certificates, > or anything else. Which credentials can be our should be shared is extremely dependent on the capabilities of the gssapi mechanism as well as the habits and policies of the system administration. The application should neither make assumptions nor set requirements in this area, because that will definitely reduce the portability across gssapi mechanisms and computing environments. -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 Fri Apr 28 15:44: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 PAA10388 for ; Fri, 28 Apr 2000 15:44:14 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA24730 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 12:19:39 -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 MAA24723 for ; Fri, 28 Apr 2000 12:19:36 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA04006; Fri, 28 Apr 00 15:21:36 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA04000; Fri, 28 Apr 2000 21:16:30 +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 VAA25917; Fri, 28 Apr 2000 21:15:47 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA01913; Fri, 28 Apr 2000 21:15:47 +0200 (METDST) From: Martin Rex Message-Id: <200004281915.VAA01913@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: jaltman@columbia.edu Date: Fri, 28 Apr 2000 21:15:47 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Jeffrey Altman" at Apr 28, 0 02:19:41 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: > > > > Which credentials can be our should be shared is extremely dependent > > on the capabilities of the gssapi mechanism as well as the habits > > and policies of the system administration. The application should > > neither make assumptions nor set requirements in this area, because > > that will definitely reduce the portability across gssapi mechanisms > > and computing environments. > > > > so really we disagree on whether or not System Administrators should > be allowed to set policy via the applications as opposed to the GSSAPI > mechansim. Since the GSSAPI mechanism may not allow policy to be set > the application should be able to enforce the policy of the system > administration. No. 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). -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 Fri Apr 28 16:01: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 QAA10686 for ; Fri, 28 Apr 2000 16:01:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA26347 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 12:37:48 -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 MAA26329 for ; Fri, 28 Apr 2000 12:37:43 -0700 (PDT) Received: from watsun.cc.columbia.edu by MIT.EDU with SMTP id AA16681; Fri, 28 Apr 00 15:37:41 EDT Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA27118; Fri, 28 Apr 2000 15:37:39 -0400 (EDT) Date: Fri, 28 Apr 2000 15:37:39 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: mrex@sap-ag.de Cc: cat-ietf@mit.edu Subject: Re: hostbased service names (or not) In-Reply-To: Your message of Fri, 28 Apr 2000 21:15:47 +0200 (METDST) Message-Id: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > 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. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Apr 28 16:06: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 QAA10764 for ; Fri, 28 Apr 2000 16:06:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA25933 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 12:29:57 -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 MAA25928 for ; Fri, 28 Apr 2000 12:29:53 -0700 (PDT) Received: from nat-su-33.valinux.com by MIT.EDU with SMTP id AA13556; Fri, 28 Apr 00 15:29:47 EDT Received: (from tytso@localhost) by rsts-11.su.valinux.com (8.9.3/8.9.3) id PAA02500; Fri, 28 Apr 2000 15:29:39 -0400 Date: Fri, 28 Apr 2000 15:29:39 -0400 From: "Theodore Ts'o" Message-Id: <200004281929.PAA02500@rsts-11.su.valinux.com> To: mrex@sap-ag.de Cc: kenh@cmf.nrl.navy.mil, cat-ietf@mit.edu In-Reply-To: <200004281339.PAA00832@hw1464.wdf.sap-ag.de> (message from Martin Rex on Fri, 28 Apr 2000 15:39:43 +0200 (METDST)) Subject: Re: hostbased service names (or not) Phone: (781) 391-3464 References: <200004281339.PAA00832@hw1464.wdf.sap-ag.de> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Martin Rex Date: Fri, 28 Apr 2000 15:39:43 +0200 (METDST) The notion that two independent applications *must* be able to share an identity (and therefore a credential) is an obvious breach of the GSS-API abstraction. 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. No, not necessarily. You're assuming that there will always being an algorithmic transform from the GSSAPI service@hostname name form, and the mechanism-specific low-level name format. It may very well be the case that the mapping will require a database lookup --- using LDAP, or consulting the MS Active Directory, or whatever, to map www@host.thunk.org to some X.509 name. I don't think there's any assumption here that future mechanism's naming architectures have to look like Kerberos of today. It *does* mean that in some cases gss_import_name may need to do a database lookup of some kind, and that database lookup may require consulting a remote directory over some kind of secure/trusted path. Kerberos implementations hasn't needed to do this up until now because of its relatively simple naming structure, but to the extent that we need to deal with the secure DNS issue, we may end up needing to consult some kind of secure directory as well (whether it is secure DNS or some kind of LDAP server is really an implementation issue, though, and not a protocol issue.) - I think the idea of sharing a single generic name for applications is invalid at the GSS-API level. It is very valid and useful to allow sharing of identities (=credentials) at the mechanism level, provided that the mechanism is capable of doing that. It's up to the application protocol specification whether or not the generic "host" service name should be used. In some cases, such as rlogin/telnet/ssh/etc., it really doesn't make any sense to have unique identifies, since at some level, it's all the same service. But for other application protocols it doesn't make sense, in which case the specification shouldn't make use of the generic "host" service. They are intended to be portable, and they may even be the most portable nametype that is currently contained in rfc2743. Fact is, they are not portable, because non-Kerberos mechanisms haven't defined a mapping and as a result not implemented them. That is arguably a difficiency in design and implementations the non-Kerberos mechanisms, though, and not in the basic idea. These sorts of difficiencies can be addressed. This kind of thing is important to get right. If we don't have a host-based service name, then trying to do GSSAPI mechanism negotiation is *really* hard, since you now the application has to pass in the target name before knowing which GSSAPI mechanism will be selected. - 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 Fri Apr 28 16:16: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 QAA10957 for ; Fri, 28 Apr 2000 16:16:15 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA26868 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 12:49:00 -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 MAA26861 for ; Fri, 28 Apr 2000 12:48:57 -0700 (PDT) Received: from smtpde02.sap-ag.de by MIT.EDU with SMTP id AA20885; Fri, 28 Apr 00 15:48:54 EDT Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA13542 for ; Fri, 28 Apr 2000 21:45:56 +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 VAA27905 for ; Fri, 28 Apr 2000 21:34:31 +0200 (MET DST) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA01991 for ; Fri, 28 Apr 2000 21:34:31 +0200 (METDST) From: Martin Rex Message-Id: <200004281934.VAA01991@hw1464.wdf.sap-ag.de> Subject: Re: hostbased service names (or not) To: cat-ietf@mit.edu Date: Fri, 28 Apr 2000 21:34:31 +0200 (METDST) In-Reply-To: <200004281808.UAA01584@hw1464.wdf.sap-ag.de> from "Martin Rex" at Apr 28, 0 08:08:38 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 Martin Rex wrote: > > Jeffrey Altman wrote: > > > > > Please share the wisdom with us how to map between hostbased service names > > > and X.509 certificates, because none of us has been able to come up > > > with a solution so far. > > > > It is the same problem that exists with regards to mapping userid's to > > X.509 certificates. Given the current lack of an infrastructure of > > trust and real standards for what goes into a certificate it is not > > possible to receive a certificate issued by a semi-trusted third party > > and really accept the data inside the certificate. > > > > Because of this fundamental problem which I have seen handled in > > different ways at different organizations, all of my applications > > provide either callbacks or other user defined implementations to > > perform the mappings from certificates to entities. Many sites issue > > certificates without any identifying information and simply perform > > database comparisions from the cert to the entity. > > I think it is just fine to map an opaque certificate directly to > a user via a database/directory. I don't know the details, but isn't > this actually how certificate-based logons work in W2K with the > Active Directory? The drawback is, that one needs to get hold of > each certificate to put it into the database and verify the > association of a human being with a user account oneself. > > Keep the opaque certificate in your mapping table. Basically > you map from the contained public key and ignore everything else. > > - PROs: - it is independent of the CAs naming convention and policies, > - you don't need to trust the CA > - you don't need a particular(ly expensive) CA > - when the keypair was not created by the CA, only the > public key is signed by it, then this mapping is even > secure when the CA is corrupted > - you don't need a PKI > - you can yourself control the quality of the association > between a user (account) and a certificate, independent > of the policies and qualities of the CAs whose certs > your users are using. > > - CONs: - certificate rollover (expiration/loss/replacement) > in your mapping table requires administrative action > - if you're operating PKI-less, you may have to implement > manual access revocation procedures. > - you have to check the association of a user (account) > with a certificate yourself, because there is no common > pool of (trusted) information that you can use. Oooops, what I totally forgot to mention: This mapping of opaque certificates into users is not an option for GSS-API mechanisms. GSS-API is modeled to perform name-based authentication. One could define a nametype that used base64-encoded X.509 certificates, but no human would want to type these in. ;-) One could reduce it to simply the base64-encoded public key within the certificate, but those would still be hard to recognize and relate by humans. Maybe the concatentation of the subject_dn with the base-64 encoded public key? When not including the public key in the cert, then you suddenly have to carefully review and rely on all policies of all CA (trees) that you accept. Better run your own CA, trust only that, and issue certificates for everbody who needs one. Then you may get along with only mapping the subject DN or even only a particular attribute of the alt_subject name. -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 Sat Apr 29 03:09: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 DAA07607 for ; Sat, 29 Apr 2000 03:09:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA23617 for ietf-cat-wg-out720680; Fri, 28 Apr 2000 23:37:53 -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 XAA23612 for ; Fri, 28 Apr 2000 23:37:50 -0700 (PDT) Received: from nat-su-33.valinux.com by MIT.EDU with SMTP id AA12474; Sat, 29 Apr 00 02:39:51 EDT Received: (from tytso@localhost) by rsts-11.su.valinux.com (8.9.3/8.9.3) id CAA05660; Sat, 29 Apr 2000 02:37:45 -0400 Date: Sat, 29 Apr 2000 02:37:45 -0400 From: "Theodore Ts'o" Message-Id: <200004290637.CAA05660@rsts-11.su.valinux.com> To: mrex@sap-ag.de Cc: jaltman@columbia.edu, cat-ietf@mit.edu In-Reply-To: <200004281915.VAA01913@hw1464.wdf.sap-ag.de> (message from Martin Rex on Fri, 28 Apr 2000 21:15:47 +0200 (METDST)) Subject: Re: hostbased service names (or not) Phone: (781) 391-3464 References: <200004281915.VAA01913@hw1464.wdf.sap-ag.de> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: Martin Rex Date: Fri, 28 Apr 2000 21:15:47 +0200 (METDST) Your posistion: applications should enforce architecture and policies on sysadmins and gssapi mechanisms by requiring hostbased services names to work. 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. 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. - 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