From owner-ietf-krb-wg@achilles.ctd.anl.gov Fri Dec 1 00:17:09 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15924 for ; Fri, 1 Dec 2000 00:17:09 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id WAA21499 for ietf-krb-wg-outgoing; Thu, 30 Nov 2000 22:47:52 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id WAA21492; Thu, 30 Nov 2000 22:47:49 -0600 (CST) 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 WAA21943; Thu, 30 Nov 2000 22:47:48 -0600 (CST) Message-ID: <3A272DB6.2D5B1E86@anl.gov> Date: Thu, 30 Nov 2000 22:48:54 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov, agenda@ietf.org CC: "Douglas E. Engert" Subject: Agenda for Kerberos Working Group (krb-wg) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit CHAIR: Doug Engert AGENDA: Introduction Doug Engert (ANL) Kerberos revisions - Cliff Neuman (ISI) The main objective of the working group is to move this draft forward to last call. We have made some progress but not as much as I would have liked to see. Therefore this can last as long as needed. PKINIT, PKCROSS, PKTAPP - Waiting for Revisions, brief updates. Matt Hur (CISCO), Sasha Medvinsky (Motorola), Brian Tung (ISI) AES and Kerberos - Ken Raeburn MIT RC4-HMAC as "standard" etype - John Brezak (Microsoft) John reports that there are at least 3 implementations of Kerberos which have this, so should it be standard? Kerberos changes/set password I-D update John Brezak (Microsoft), Jonathan Trostle (CISCO) IAKERB - Preparing for Working Group last call Jonathan Trostle (CISCO) Kerberos GSS User-to-user John Brezek (Microsoft), Tom Yu (MIT) , Pat Moore (SANDIA) TLS KRB5 - brief update Jeffrey Altman (Columbia), Matt Hur (CISCO) draft-skibbie-krb-kdc-ldap-schema-00.txt "Donna Skibbie" This draft has not been assigned to a working group, but many in the krb-wg have concerns over the concept. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@achilles.ctd.anl.gov Fri Dec 1 06:50:14 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05547 for ; Fri, 1 Dec 2000 06:50:14 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id FAA17716 for ietf-krb-wg-outgoing; Fri, 1 Dec 2000 05:33:43 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA17706 for ; Fri, 1 Dec 2000 05:33:38 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id FAA20807 for ; Fri, 1 Dec 2000 05:33:37 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25334; Fri, 1 Dec 2000 06:32:15 -0500 (EST) Message-Id: <200012011132.GAA25334@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-krb-wg@anl.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-revisions-07.txt Date: Fri, 01 Dec 2000 06:32:14 -0500 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kerberos WG Working Group of the IETF. Title : The Kerberos Network Authentication Service (V5) Author(s) : C. Neuman, G. Kohl, T. Ts'o Filename : draft-ietf-cat-kerberos-revisions-07.txt Pages : 103 Date : 30-Nov-00 This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], are available elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-07.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-revisions-07.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-revisions-07.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: <20001130115109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-revisions-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-revisions-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115109.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-krb-wg@achilles.ctd.anl.gov Fri Dec 1 20:32:28 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27200 for ; Fri, 1 Dec 2000 20:32:27 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id TAA26811 for ietf-krb-wg-outgoing; Fri, 1 Dec 2000 19:20:33 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA26805 for ; Fri, 1 Dec 2000 19:20:30 -0600 (CST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA18633 for ; Fri, 1 Dec 2000 19:20:29 -0600 (CST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id UAA28304; Fri, 1 Dec 2000 20:20:28 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: do we care about deterministic encodings? From: Tom Yu Date: 01 Dec 2000 20:20:28 -0500 Message-ID: Lines: 57 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk How important do we think it is that a given encoding of a Kerberos message be preserved upon decoding and reencoding? This is a separate issue from BER versus DER, since even a DER encoding may be nondeterministic if there are indistinguishable semantics between lacking a value and encoding a specific value. For example, in the case of an optional "microseconds" field, some implementations cannot distinguish between a value of zero and the lack of an encoded value. Decoding and reencoding of a message may therefore not produce the exact same encoding as received. We can make the *specification* of the protocol deterministic by judicious use of the DEFAULT keyword, which requires that the implementation not encode the "default" value listed in the ASN.1 syntax. Optional microseconds fields almost always appear in conjunction KerberosTime fields. When an optional microseconds field appears in conjunction with a required KerberosTime field, it is apparent that an implementation is very likely to "encode" a value of zero microseconds by omitting the field altogether. However, when a microseconds field appears in conjunction with an optional KerberosTime field, is is not obvious whether a value of zero microseconds should be encoded or not when the associated KerberosTime is encoded. At least the MIT implementation does appear to encode an actual zero value for a microseconds field associated with an optional KerberosTime field in the case where the KerberosTime field is actually encoded. It would be dubious utility to encode the microseconds without encoding the associated KerberosTime, though. :-) Q: Does anyone think that the ambiguity relating to microseconds encoding is worth the trouble of resolving, given that (in my opinion) there are somewhat inadequate data regarding the behaviors of existing implementations? Additional related questions are: Q: Given that the MIT implementation seems to always encode microseconds (even zero values) that are associated with an optional KerberosTime, and omit microseconds that are associated with a non-optional KerberosTime, should we impose this behavior on all implementations? How are non-MIT implemenations behaving? Likewise, there is a lack of semantic distinction between an omitted optional sequence-of and an encoded zero-element sequence-of. In contrast to the microseconds case, the behavior of an implementation is likely to be less ambiguos. In a C-language implementation, where the in-program representation of an empty sequence-of is likely to be merely a NULL pointer, the encoders would likely omit the encoding altogether. The one case that Ken Raeburn pointed out in terms of address lists needs to be considered, though, and we would need to evaluate instances where there actually can be a useful semantic distinction. Q: Does anyone feel that there needs to be a semantic distinction between a zero-length list and an omitted list for any types other than HostAddresses? ---Tom From owner-ietf-krb-wg@achilles.ctd.anl.gov Sat Dec 2 14:20:05 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27111 for ; Sat, 2 Dec 2000 14:20:04 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id NAA26859 for ietf-krb-wg-outgoing; Sat, 2 Dec 2000 13:07:58 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA26853 for ; Sat, 2 Dec 2000 13:07:55 -0600 (CST) Received: from blubb.pdc.kth.se (asynk40.modempool.kth.se [130.237.10.40]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA15344 for ; Sat, 2 Dec 2000 13:07:52 -0600 (CST) Received: from joda by blubb.pdc.kth.se with local (Exim 3.13 #1) id 142Hzf-0003ux-00; Sat, 02 Dec 2000 20:06:43 +0100 To: Tom Yu Cc: ietf-krb-wg@anl.gov Subject: Re: do we care about deterministic encodings? References: From: joda@pdc.kth.se (Johan Danielsson) Date: 02 Dec 2000 20:06:43 +0100 In-Reply-To: Tom Yu's message of "01 Dec 2000 20:20:28 -0500" Message-ID: Lines: 39 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Tom Yu writes: > Q: Does anyone think that the ambiguity relating to microseconds > encoding is worth the trouble of resolving, given that (in my > opinion) there are somewhat inadequate data regarding the > behaviors of existing implementations? Which usec's should be optional and not seems like pretty random right now. What someone should have done in the first place was probably something like: KerberosTime ::= SEQUENCE { time GeneralizedTime, usec INTEGER OPTIONAL } and always use that. Anyway, the usec field is just an optional integer, and as such it's probably easier to re-encode it as received, instead of doing something with it. It doesn't matter much. > Q: Given that the MIT implementation seems to always encode > microseconds (even zero values) that are associated with an > optional KerberosTime, and omit microseconds that are associated > with a non-optional KerberosTime, should we impose this behavior > on all implementations? How are non-MIT implemenations > behaving? We seem to always encode microseconds (regardless of them being zero and/or optional). > Q: Does anyone feel that there needs to be a semantic > distinction between a zero-length list and an omitted list for > any types other than HostAddresses? If there should be a difference for HostAddresses I think there should be for any other type. Adding more (unneeded) semantics to the ASN.1 mess we have doesn't sound like a great idea to me. /Johan From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 11:19:45 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07199 for ; Mon, 4 Dec 2000 11:19:44 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA00927 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 09:57:33 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA00920 for ; Mon, 4 Dec 2000 09:57:30 -0600 (CST) 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 JAA23766; Mon, 4 Dec 2000 09:57:23 -0600 (CST) Message-ID: <3A2BBF26.1E469E8E@anl.gov> Date: Mon, 04 Dec 2000 09:58:30 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: jhutz+@cmu.edu, joes@wrq.com, hartmans@mit.edu, galb@vandyke.com, jpv@vandyke.com, welch@mcs.anl.gov, ietf-krb-wg@anl.gov Subject: Re: (Draft 3.0) Agenda for Kerberos Working Group References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > > On Tue, 28 Nov 2000, Douglas E. Engert wrote: > > > (Draft 3.0) Agenda for Kerberos WG (krb-wg) > > Is it too late to get some time to talk about issues with Kerberos and > SSH v2? Particularly, I'd like to see some discussion on the key exchange > methods described in draft-salowey-secsh-kerbkeyex-00.txt, and on how that > mechanism might be extended to support arbitrary GSSAPI mechanisms. I am reluctant to do this, since this document is not assigned to the krb-wg, and we have a lot to talk about already. I should also point out SSH GSS-API Authentication Method which does support arbitrary GSSAPI mechanisms with SSH. I would encourage the authors of these two drafts to get involved, if they have not already don so. > > I suppose it's worthwhile to also try to get some time with the secsh > folks... > > -- Jeff -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 12:01:12 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23519 for ; Mon, 4 Dec 2000 12:01:12 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id KAA01593 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 10:49:55 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA01586; Mon, 4 Dec 2000 10:49:51 -0600 (CST) Received: from zalon.pc.cs.cmu.edu (ZALON.REM.CS.CMU.EDU [128.2.81.62]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id KAA04076; Mon, 4 Dec 2000 10:49:50 -0600 (CST) Received: from zalon.pc.cs.cmu.edu by zalon.pc.cs.cmu.edu id aa08617; 4 Dec 2000 11:49 EST Date: Mon, 4 Dec 2000 11:49:24 -0500 (EST) From: Jeffrey Hutzelman X-Sender: jhutz@zalon.pc.cs.cmu.edu Reply-To: Jeffrey Hutzelman To: "Douglas E. Engert" cc: joes@wrq.com, hartmans@mit.edu, galb@vandyke.com, jpv@vandyke.com, welch@mcs.anl.gov, ietf-krb-wg@anl.gov Subject: Re: (Draft 3.0) Agenda for Kerberos Working Group In-Reply-To: <3A2BBF26.1E469E8E@anl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Mon, 4 Dec 2000, Douglas E. Engert wrote: > I am reluctant to do this, since this document is not assigned to the > krb-wg, and we have a lot to talk about already. OK; I can understand that. > I should also point out > SSH GSS-API Authentication Method which does support arbitrary GSSAPI > mechanisms with SSH. > > I would encourage the authors of these two drafts to get involved, > if they have not already don so. Hm. I was not aware of the existence of that draft. I would like to talk to its authors about mechanism negotiation -- it looks like what they are doing will result in two levels of negotiation for GSSAPI mechanisms, which can be problematic if implementations want to support a mixture of GSSAPI and non-GSSAPI mechanisms with intermixed levels of preference. A better approach is that used in draft-ietf-cat-sasl-gssapi-02.txt, which defines a class of mechanisms such that a first-class SASL mechanism can be derived for any GSSAPI mechanism, allowing all mechanisms to proceed equally in the negoitation process without having to separately standardize a SASL wrapper for each GSSAPI mechanism in advance. In any event, the user auth method described in that draft doesn't really overlap what we're trying to do with key exchange methods. In fact, the two are complementary; between them, they accomplish most of what we were hoping for when I first started this thread in krb-wg. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 14:06:05 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00921 for ; Mon, 4 Dec 2000 14:06:05 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id MAA02989 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 12:55:57 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA02982; Mon, 4 Dec 2000 12:55:53 -0600 (CST) Received: from cerberos2.ncsa.uiuc.edu (c794543-a.chmpgn1.il.home.com [24.183.29.30]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA27537; Mon, 4 Dec 2000 12:55:52 -0600 (CST) Received: from vwelch by cerberos2.ncsa.uiuc.edu with local (Exim 3.10 #2) id 1430mv-00017B-00; Mon, 04 Dec 2000 12:56:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14891.59616.997129.810314@cerberos2.ncsa.uiuc.edu> Date: Mon, 4 Dec 2000 12:56:32 -0600 To: Jeffrey Hutzelman Cc: "Douglas E. Engert" , joes@wrq.com, hartmans@mit.edu, galb@vandyke.com, jpv@vandyke.com, ietf-krb-wg@anl.gov Subject: Re: (Draft 3.0) Agenda for Kerberos Working Group In-Reply-To: References: <3A2BBF26.1E469E8E@anl.gov> X-Mailer: VM 6.76 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid From: Von Welch Reply-To: Von Welch Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit Jeffrey Hutzelman writes: > > I should also point out > > SSH GSS-API Authentication Method which does support arbitrary GSSAPI > > mechanisms with SSH. > > > > I would encourage the authors of these two drafts to get involved, > > if they have not already don so. > > Hm. I was not aware of the existence of that draft. I would like to talk > to its authors about mechanism negotiation -- it looks like what they are > doing will result in two levels of negotiation for GSSAPI mechanisms, > which can be problematic if implementations want to support a mixture of > GSSAPI and non-GSSAPI mechanisms with intermixed levels of preference. If I understand you correctly, I think we can support this. A client who is interested in mixing gssapi and non-gssapi mechanisms on their preferred list can split the gssapi requests over multiple SSH_MSG_USER_AUTH_REQUEST messages, in order of preference, where each request has only a single mechanism OID (or some subset of supported mechanisms OIDs) and there may be non-GSSAPI request interspersed. We might want to add a way for the server to send messages distinguish between "I don't support any of the requested gssapi mechanisms" and "I don't support gssapi". Von > A better approach is that used in draft-ietf-cat-sasl-gssapi-02.txt, which > defines a class of mechanisms such that a first-class SASL mechanism can > be derived for any GSSAPI mechanism, allowing all mechanisms to proceed > equally in the negoitation process without having to separately > standardize a SASL wrapper for each GSSAPI mechanism in advance. > > In any event, the user auth method described in that draft doesn't really > overlap what we're trying to do with key exchange methods. In fact, the > two are complementary; between them, they accomplish most of what we were > hoping for when I first started this thread in krb-wg. > > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 16:05:27 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29669 for ; Mon, 4 Dec 2000 16:05:27 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id OAA04963 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 14:57:11 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA04957 for ; Mon, 4 Dec 2000 14:57:08 -0600 (CST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA20960 for ; Mon, 4 Dec 2000 14:57:08 -0600 (CST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id PAA04207; Mon, 4 Dec 2000 15:57:07 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: new KRB-SAFE/KRB-PRIV messages From: Tom Yu Date: 04 Dec 2000 15:57:06 -0500 Message-ID: Lines: 67 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk The revisions as they currently stand change the KRB-SAFE and KRB-PRIV messages to premit the omission of the sender address. This creates a backwards compatibility problem. As I indicated in my previous comments on section 5 of kerberos-revisions, there should be new types defined, probably as follows: KRB-SAFE-2 ::= [APPLICATION 18] SEQUENCE { pvno [0] INTEGER, msg-type [1] INTEGER, safe-body [2] KRB-SAFE-BODY-2 OPTIONAL, cksum [3] CHecksum } KRB-SAFE-BODY-2 ::= SEQUENCE { user-data [0] OCTET STRING, timestamp [1] KerberosTime OPTIONAL, usec [2] INTEGER OPTIONAL, seq-number [3] INGETER OPTIONAL, s-address [4] HostAddress OPTIONAL, r-address [5] HostAddress OPTIONAL } KRB-PRIV-2 ::= [APPLICATION 19] SEQUENCE { pvno [0] INTEGER, msg-type [1] INTEGER, enc-part [3] EncryptedData -- encrypted EncKrbPrivPart2 } EncKrbPrivPart2 ::= [APPLICATION 24] SEQUENCE { user-data [0] OCTET STRING, timestamp [1] KerberosTime OPTIONAL, usec [2] INTEGER OPTIONAL, seq-number [3] INTEGER OPTIONAL, s-address [4] HostAddress OPTIONAL, r-address [5] Hostaddress OPTIONAL } The reason to make the safe-body field of KRB-SAFE-2 optional is to allow for an application to encode a KRB-SAFE-BODY-2 but not transmit it. This is a Kerberos protocol equivalent of a GSSAPI MIC token, which would make the definition of a GSSAPI mechanism based almost entirely on Kerberos messages possible. This numbering of the tag numbers is chosen to keep the functional blocks of tag numbers contiguous. The only way to extend the block of tag numbers associated with "encparts" (25..29) is backwards; extending that block forwards would collide with [APPLICATION 30], which is KRB-ERROR. Likewise, the block of tag numbers associated with "application messages" (20..22) is extended backwards to avoid conflict with the "encpart" tag number space. Incidentally, we may want to rethink the numbering of the TGT-REQ and TGT-REP (if we want to have a TGT-REP one as opposed to sending a raw ticket) messages in the light of the directions we need to extend the application protcol messages for KRB-SAFE and KRB-PRIV. Also, somewhat arguably, a TGT-REQ is part of an application protocol, not a core authentication message. Backwards compatitility problems are then solved by making it the application protocol designer's choice whether to use the new messages in a new revision of the protocol, rather than retroactively modifying existing protocols by redefining Kerberos message types. Are there any objections to this concept for creating new types for KRB-SAFE and KRB-PRIV? ---Tom From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 16:20:42 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03205 for ; Mon, 4 Dec 2000 16:20:41 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA05270 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 15:11:47 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA05264 for ; Mon, 4 Dec 2000 15:11:44 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA23955 for ; Mon, 4 Dec 2000 15:11:44 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id QAA22470; Mon, 4 Dec 2000 16:11:39 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: new KRB-SAFE/KRB-PRIV messages References: Mime-Version: 1.0 From: Ken Raeburn Date: 04 Dec 2000 16:11:39 -0500 In-Reply-To: Tom Yu's message of "04 Dec 2000 15:57:06 -0500" Message-ID: Lines: 11 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Tom Yu writes: > The reason to make the safe-body field of KRB-SAFE-2 optional is to > allow for an application to encode a KRB-SAFE-BODY-2 but not transmit > it. This is a Kerberos protocol equivalent of a GSSAPI MIC token, > which would make the definition of a GSSAPI mechanism based almost > entirely on Kerberos messages possible. Might we want to use any of the other fields of KRB-SAFE-BODY-2 (most likely the sequence number, but perhaps the timestamp) in a MIC token? If so, then the user-data, not the safe-body, should be the OPTIONAL field. From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 16:36:00 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07922 for ; Mon, 4 Dec 2000 16:35:57 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA05526 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 15:27:20 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA05520 for ; Mon, 4 Dec 2000 15:27:18 -0600 (CST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA27001 for ; Mon, 4 Dec 2000 15:27:17 -0600 (CST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 13:25:59 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 13:26:41 -0800 (Pacific Standard Time) Received: from df-goofy.platinum.corp.microsoft.com ([172.30.236.130]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 13:26:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: name canonicalization review - canonicalization service? Date: Mon, 4 Dec 2000 13:26:39 -0800 Message-ID: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> Thread-Topic: name canonicalization review - canonicalization service? Thread-Index: AcBaFUaHuLtfioilRIW4md5X+q8f1gEI4lYg From: "John Brezak" To: "Ken Raeburn" , X-OriginalArrivalTime: 04 Dec 2000 21:26:40.0549 (UTC) FILETIME=[E429AD50:01C05E38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id PAA05521 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit Entries on ACLs in the Win2000 implementation are based on the SID - where the SID is the unit of authorization. The Kerberos principal name is not used for access control. In DCE this is also the case - access control is based on the UUIDs not principals. Name canonlicalization is not a mechanism for access control. If a service is needed to handle lookup of service names to canonical names, LDAP would easiliy be able to handle this. > -----Original Message----- > From: Ken Raeburn [mailto:raeburn@mit.edu] > Sent: Tuesday, November 28, 2000 7:02 PM > To: ietf-krb-wg@anl.gov > Subject: Re: name canonicalization review - canonicalization service? > > > > Martin Rex pointed out a number of problems with name > canonicalization. Many of them were simply ways in which it couldn't > be used (e.g., generic hostnames mapping to multiple machines, when > you don't know which you'll connect to), or how it really ought to > work parallel to and in conjunction with DNS aliases to avoid > surprising the end user. > > The main omission Martin brought up, I believe, is the lack of the > ability to do secure name canonicalization anywhere outside of an > AS_REQ or TGS_REQ. > > * gss_canonicalize_name needs this service, to permit (pre)populating > ACLs (and I could imagine some Kerberos situations where this might > be the case too); the specification of the GSS_Canonicalize_name > function specifically says it's for use with ACL entries > > * You can't set up ACLs with "whatever ldap/host.dom.ain@FOO maps to > at run time", since the mapping can't be performed. > > These could be addressed by a KDC service which did *only* name > canonicalization, securely; this should IMNSHO be as integral to the > Kerberos service as name canonicalization itself. (Or reverse it: If > this canonicalization service isn't integral to the Kerberos spec, the > optimization of name canonicalization as part of KDC_REQ processing > shouldn't be either.) Using the TGS isn't good enough -- the > principal name you want to canonicalize may be one for which service > tickets are prohibited by site policy. > > But no one has suggested anything. > Well, I keep suggesting removing name canonicalization, but no one > seems interested. :-) > > Even if we add such a service, gss_canonicalize_name will require a > round-trip to the KDC, while text in RFC 2744 suggests that > gss_canonicalize_name is supposed to be much more efficient than > actually going through the authentication steps. (Granted, that's > just the C bindings document, and such things should be a matter for > the generic GSSAPI spec.) > > How does gss_canonicalize_name work in the Microsoft implementation? > > Adding such a service might also permit more flexibility in name > canonicalization, for example, making "ftp/gnuftp@RAEBURN.ORG" an > alias for "ftp/ftp.gnu.org@GNU.ORG", which I believe is impossible > with the current mechanism, so I can't just type "ftp gnuftp" and have > the right magic happen, as I can with normal DNS canonicalization. > (For that to fully work, name canonicalization as part of the AS and > TGS would have to change. But the right thing, IMNSHO, would've been > to design name canonicalization well, and *then* look at optimizing > the combination with AS and TGS exchanges.) > > Do people think we need such a service? > Should it be in kerberos-revisions? > Should kerberos-revisions be finalized without any such facility? > > Ken > > P.S. RFC 2743 specifies the use of DNS to canonicalize a supplied > hostname for GSS_C_NT_HOSTBASED_SERVICE. Perhaps a future Update 2 > should address the security issues here somehow, and perhaps change > that specification. > From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 16:39:26 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08936 for ; Mon, 4 Dec 2000 16:39:26 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA05562 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 15:29:51 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA05554 for ; Mon, 4 Dec 2000 15:29:47 -0600 (CST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA27574 for ; Mon, 4 Dec 2000 15:29:46 -0600 (CST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id QAA04239; Mon, 4 Dec 2000 16:29:44 -0500 (EST) To: Ken Raeburn Cc: ietf-krb-wg@anl.gov Subject: Re: new KRB-SAFE/KRB-PRIV messages References: From: Tom Yu Date: 04 Dec 2000 16:29:44 -0500 In-Reply-To: Ken Raeburn's message of "04 Dec 2000 16:11:39 -0500" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk >>>>> "raeburn" == Ken Raeburn writes: raeburn> Might we want to use any of the other fields of raeburn> KRB-SAFE-BODY-2 (most likely the sequence number, but perhaps raeburn> the timestamp) in a MIC token? If so, then the user-data, raeburn> not the safe-body, should be the OPTIONAL field. Oh. Now that I think about it, you're right. That would make all components of a KRB-SAFE-BODY-2 optional, and an application (or GSSAPI mechanism) wanting to send a MIC token or equivalent would have to encode the KRB-SAFE-BODY-2 twice: once with the user-data, and once without. This does bring up the problem of re-encoding, since an application would likely decode the KRB-SAFE-BODY-2 and re-encode it with the user-data field present, which could cause problems with things such as the usec field, for instance. A careful implementation could probably get around that, though, by keeping track of whether certain fields were actually encoded. ---Tom From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 16:52:04 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12879 for ; Mon, 4 Dec 2000 16:52:03 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA05748 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 15:41:14 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA05742 for ; Mon, 4 Dec 2000 15:41:10 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA29733 for ; Mon, 4 Dec 2000 15:41:10 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id QAA22488; Mon, 4 Dec 2000 16:41:06 -0500 (EST) To: Subject: Re: name canonicalization review - canonicalization service? References: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> Mime-Version: 1.0 From: Ken Raeburn Date: 04 Dec 2000 16:41:05 -0500 In-Reply-To: "John Brezak"'s message of "Mon, 4 Dec 2000 13:26:39 -0800" Message-ID: Lines: 15 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk "John Brezak" writes: > Name canonlicalization is not a mechanism for access control. If a No, but Kerberos principal names can be, and name canonicalization has now become a part of handling names. > service is needed to handle lookup of service names to canonical names, > LDAP would easiliy be able to handle this. So, which do you recommend -- that we mandate LDAP access to the database as part of all Kerberos implementations, or that we offer no portable way to make gss_canonicalize_name work for the Kerberos mechanism? Ken From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 17:20:17 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23137 for ; Mon, 4 Dec 2000 17:20:15 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA06233 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 16:12:10 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA06227 for ; Mon, 4 Dec 2000 16:12:06 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA05722 for ; Mon, 4 Dec 2000 16:12:06 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id RAA22505; Mon, 4 Dec 2000 17:12:05 -0500 (EST) Date: Mon, 4 Dec 2000 17:12:05 -0500 (EST) Message-Id: <200012042212.RAA22505@dcl.mit.edu> From: Ken Raeburn To: ietf-krb-wg@anl.gov Subject: RC4-HMAC Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Doug put this on the agenda: RC4-HMAC as "standard" etype - John Brezak (Microsoft) John reports that there are at least 3 implementations of Kerberos which have this, so should it be standard? I didn't realize it, because it hadn't been announced here (AFAICT), but there's a new draft (draft-brezak-win2k-krb-rc4-hmac-02.txt) that came out in November, and it looks significantly different from the -00 and -01 versions. It incorporates key derivation "as defined in RFC1510bis" (or similar language), and then goes on to describe a completely different mechanism using an MD5 HMAC. A different list of key usage numbers that doesn't match up with all the uses in RFC1510bis is also given, with no explanation for the changes; making one implementation handle both will be a pain in the backside, though a sort of translation table from RFC1510bis numbers to RC4 numbers might work. There were some other bits I had questions on (mostly the reasoning for certain decisions), but I'd have to go back and check it again. I did notice the checksum number chosen for HMAC MD5 is still negative -- that is, in the "local use" range. If it's going to be an IETF standard, it should have a positive number, IMNSHO. My main question is: Which versions of this spec have been implemented (and by whom), and what version are we talking about making a standard? Ken From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 17:53:19 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06104 for ; Mon, 4 Dec 2000 17:53:17 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA06827 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 16:44:55 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA06821 for ; Mon, 4 Dec 2000 16:44:53 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA11826 for ; Mon, 4 Dec 2000 16:44:52 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id RAA24445; Mon, 4 Dec 2000 17:40:49 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma023956; Mon, 4 Dec 2000 17:39:45 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id RAA11888; Mon, 4 Dec 2000 17:41:16 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id RAA00698; Mon, 4 Dec 2000 17:39:53 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id RAA08362; Mon, 4 Dec 2000 17:35:25 -0500 (EST) Date: Mon, 4 Dec 2000 17:35:25 -0500 From: Nicolas Williams To: Ken Raeburn Cc: ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? Message-ID: <20001204173523.U22005@sm2p1386swk.wdr.com> Mail-Followup-To: Ken Raeburn , ietf-krb-wg@anl.gov References: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from raeburn@mit.edu on Mon, Dec 04, 2000 at 04:41:05PM -0500 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk I would say that a new KDC protocol is called for whereby properly authenticated clients can ask the KDC to canonicalize principal names. I.e., clients authenticating with a kerberos ticket for any user or service principal should be able to ask the KDC to canonicalize a given principal name. Alternatively gss_canonicalize_name() will have to be prepared to authenticate as the given principal name in order to canonicalize it, if that given PN is not a canonical name to begin with. This may not always be possible, certainly not in applications where one is trying to populate ACLs with a batch job. Yet another alternative, for SPNs anyways, is algorythmic canonicalization. If the client knows and can rely on a simple rule for how all canonical SPNs in a given realm are formed then it may be able to perform PN canonicalization off-line with no assistance from the KDC. E.g., if all SPNs in a given realm are always of the form host/fqdn@REALM, then obviously, telnet/a-given-fqdn@REALM should be canonicalized to host/same-fqdn@REALM. This approach is somewhat problematic however, as there is no way to confirm that the alias SPN is actually _valid_ as an alias (one might want to have the KDC reject requests for telnet/fqdn@REALM, rather than canonicalize the SPN). Nico On Mon, Dec 04, 2000 at 04:41:05PM -0500, Ken Raeburn wrote: > "John Brezak" writes: > > Name canonlicalization is not a mechanism for access control. If a > > No, but Kerberos principal names can be, and name canonicalization has > now become a part of handling names. > > > service is needed to handle lookup of service names to canonical names, > > LDAP would easiliy be able to handle this. > > So, which do you recommend -- that we mandate LDAP access to the > database as part of all Kerberos implementations, or that we offer no > portable way to make gss_canonicalize_name work for the Kerberos > mechanism? > > Ken -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 20:36:53 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21535 for ; Mon, 4 Dec 2000 20:36:53 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id TAA08474 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 19:24:52 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA08468 for ; Mon, 4 Dec 2000 19:24:50 -0600 (CST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA07932 for ; Mon, 4 Dec 2000 19:24:50 -0600 (CST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:18:39 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 17:19:21 -0800 (Pacific Standard Time) Received: from df-goofy.platinum.corp.microsoft.com ([172.30.236.130]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:19:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: RC4-HMAC Date: Mon, 4 Dec 2000 17:19:20 -0800 Message-ID: <7B430B24307F4A41ACE280B550308D8C020478@jbrezak43> Thread-Topic: RC4-HMAC Thread-Index: AcBeP5iHu+rjl7ktQ0imViZwKUw+IAAGP53g From: "John Brezak" To: "Ken Raeburn" , X-OriginalArrivalTime: 05 Dec 2000 01:19:20.0971 (UTC) FILETIME=[653905B0:01C05E59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id TAA08469 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit A few clarifications: - The initial intent of the RC4-HMAC I-D was to publish it as informational for those folks that want to interoperate with Win2000. - KD values and the assigned values represent the "experimental" nature of the protocol and lessons learned during implementation (bugs if you will). If this is to proceed on a standards track, then these issues should be cleaned up, however the informational nature of the I-D is still very relevant to at least the win2000 implementation. Heimdal has implemented the RC4-HMAC enctype and a few others that are not public. The latest posting reflects changes pointed out during implementations from the earlier versions. -----Original Message----- From: Ken Raeburn [mailto:raeburn@mit.edu] Sent: Monday, December 04, 2000 2:12 PM To: ietf-krb-wg@anl.gov Subject: RC4-HMAC Doug put this on the agenda: RC4-HMAC as "standard" etype - John Brezak (Microsoft) John reports that there are at least 3 implementations of Kerberos which have this, so should it be standard? I didn't realize it, because it hadn't been announced here (AFAICT), but there's a new draft (draft-brezak-win2k-krb-rc4-hmac-02.txt) that came out in November, and it looks significantly different from the -00 and -01 versions. It incorporates key derivation "as defined in RFC1510bis" (or similar language), and then goes on to describe a completely different mechanism using an MD5 HMAC. A different list of key usage numbers that doesn't match up with all the uses in RFC1510bis is also given, with no explanation for the changes; making one implementation handle both will be a pain in the backside, though a sort of translation table from RFC1510bis numbers to RC4 numbers might work. There were some other bits I had questions on (mostly the reasoning for certain decisions), but I'd have to go back and check it again. I did notice the checksum number chosen for HMAC MD5 is still negative -- that is, in the "local use" range. If it's going to be an IETF standard, it should have a positive number, IMNSHO. My main question is: Which versions of this spec have been implemented (and by whom), and what version are we talking about making a standard? Ken From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 20:46:50 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24609 for ; Mon, 4 Dec 2000 20:46:50 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id TAA08601 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 19:41:33 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA08595 for ; Mon, 4 Dec 2000 19:41:32 -0600 (CST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA10390 for ; Mon, 4 Dec 2000 19:41:31 -0600 (CST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id UAA04686; Mon, 4 Dec 2000 20:41:30 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: constrained integer types From: Tom Yu Date: 04 Dec 2000 20:41:30 -0500 Message-ID: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk There are a number of places in the Kerberos protocol where unconstrained integers are used. The integer values that may be encoded in ASN.1 are effectively unbounded. Most implementations will only use 32-bit integers. The following types may be useful: Int32 ::= INTEGER (-2147483648..2147483647) -- signed values representable in 32 bits UInt32 ::= INTEGER (0..4294967295) -- unsigned 32 bit values Microseconds ::= INTEGER (0..99999) Int32 would be used in every case where a protocol constant (e.g. enctypes, checksumtypes) is needed, since these may take on negative values. UInt32 would be used for other things, such as sequence numbers. The behavior of wrapping at 32 bits is made more explicit in the most recent -revisions draft, but in my opinion, making a constrained type for it is best. (Strangely enough, the MIT implementation uses signed sequence numbers, which is likely a bug...) Microseconds would be used in the obvious places. This constraint already exists in the text of RFC-1510 but not in the ASN.1 syntax. Are there any objections to the above proposals? Do people think it's reasonable to constrain a nonce to 32 bits? Should it be signed or unsigned? (The MIT implementation sends it as signed, which is probably a bug, but also uses the current unix time...) Also, do people think it's reasonable to apply explicit single-value constraints to integer fields of messages that may only take on one value, such as the pvno or msg-type fields of many messages? The MIT implementation using signed 32 bit integers in various places where one might expect unsigned integers is somewhat of a problem, though. I'm not sure quite how we should accomodate this. If we make into unsigned integers the types that one would expect to be unsigned, then things may fail half the time, due to negative numbers being sent by MIT code. The current code also probably depends on non-portable wraparound behavior of signed integers, but that's a separate issue. ---Tom From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 20:53:34 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26765 for ; Mon, 4 Dec 2000 20:53:33 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id TAA08657 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 19:44:53 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA08651 for ; Mon, 4 Dec 2000 19:44:52 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA10860 for ; Mon, 4 Dec 2000 19:44:52 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id UAA22752; Mon, 4 Dec 2000 20:44:51 -0500 (EST) To: Subject: Re: RC4-HMAC References: <7B430B24307F4A41ACE280B550308D8C020478@jbrezak43> Mime-Version: 1.0 From: Ken Raeburn Date: 04 Dec 2000 20:44:50 -0500 In-Reply-To: "John Brezak"'s message of "Mon, 4 Dec 2000 17:19:20 -0800" Message-ID: Lines: 34 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk "John Brezak" writes: > A few clarifications: > - The initial intent of the RC4-HMAC I-D was to publish it as > informational for those folks that want to interoperate with Win2000. > - KD values and the assigned values represent the "experimental" nature > of the protocol and lessons learned during implementation (bugs if you > will). > > If this is to proceed on a standards track, then these issues should be > cleaned up, however the informational nature of the I-D is still very > relevant to at least the win2000 implementation. Sure. The main thing is, is it to be an Informational RFC or standards-track? If it's informational, then it should describe what Win2000 is doing well enough to make an interoperable implementation. If it's standards track, it should conform to the Kerberos spec or give a good reason why it the divergence was necessary. (IMO, of course.) Jeff Schiller suggested that I go with Informational for the 3DES GSSAPI spec, because eventually we ought to go with a new mechanism that better utilizes the existing Kerberos messages and encryption scheme definitions rather than re-inventing them. The 3DES extensions are not intended to be what we want everyone to settle on, just an intermediate measure for better security in the short term. > Heimdal has implemented the RC4-HMAC enctype and a few others that are > not public. The latest posting reflects changes pointed out during > implementations from the earlier versions. Just to be clear: Heimdal's implemented the -02 version then? Ken From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 20:56:45 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27760 for ; Mon, 4 Dec 2000 20:56:45 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id TAA08697 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 19:46:28 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA08691 for ; Mon, 4 Dec 2000 19:46:26 -0600 (CST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id TAA11036 for ; Mon, 4 Dec 2000 19:46:26 -0600 (CST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:45:04 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 17:45:46 -0800 (Pacific Standard Time) Received: from df-goofy.platinum.corp.microsoft.com ([172.30.236.130]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:45:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: name canonicalization review - canonicalization service? Date: Mon, 4 Dec 2000 17:45:44 -0800 Message-ID: <52E28A515344104299B5E7AABC32045F689F3A@df-goofy.dogfood> Thread-Topic: name canonicalization review - canonicalization service? Thread-Index: AcBeRBkBmNSZQhbDS+aVgCwIRSnvDgAFuijw From: "John Brezak" To: "Nicolas Williams" , "Ken Raeburn" Cc: X-OriginalArrivalTime: 05 Dec 2000 01:45:45.0752 (UTC) FILETIME=[15D36980:01C05E5D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id TAA08692 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit inline. > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@ubsw.com] > Sent: Monday, December 04, 2000 2:35 PM > To: Ken Raeburn > Cc: ietf-krb-wg@anl.gov > Subject: Re: name canonicalization review - canonicalization service? > > > I would say that a new KDC protocol is called for whereby properly > authenticated clients can ask the KDC to canonicalize principal names. [JBrezak] Now you really are turning Kerberos into a name service. > > I.e., clients authenticating with a kerberos ticket for any user or > service principal should be able to ask the KDC to > canonicalize a given > principal name. [JBrezak] In the original proposal for NC, the list of aliases was returned in a ticket extension. However this was left out of the document because it was considered to be a performance optimization. But this list would give the client/server the needed information to be able to let the gss_canonicalize_name() api function. - Ticket extension data for aliases to optimize caching KRB-TE-REFERRAL :: = SEQUENCE { referred-realm[0] Realm, referred-server-names[1] SEQUENCE OF PrincipalNames OPTIONAL } The TE is signed with the ticket's session-key. If the user needed to find out a canonical name for a principal, it could make a TGS request for that principal and specify name-canonicalization. The resulting ticket would have the canonical name in the sname/srealm and the ticket extension would have the known aliases. > > Alternatively gss_canonicalize_name() will have to be prepared to > authenticate as the given principal name in order to > canonicalize it, if > that given PN is not a canonical name to begin with. This may > not always > be possible, certainly not in applications where one is trying to > populate ACLs with a batch job. > > Yet another alternative, for SPNs anyways, is algorythmic > canonicalization. If the client knows and can rely on a > simple rule for > how all canonical SPNs in a given realm are formed then it may be able > to perform PN canonicalization off-line with no assistance > from the KDC. > E.g., if all SPNs in a given realm are always of the form > host/fqdn@REALM, then obviously, telnet/a-given-fqdn@REALM should be > canonicalized to host/same-fqdn@REALM. This approach is somewhat > problematic however, as there is no way to confirm that the > alias SPN is > actually _valid_ as an alias (one might want to have the KDC reject > requests for telnet/fqdn@REALM, rather than canonicalize the SPN). > > Nico > > > On Mon, Dec 04, 2000 at 04:41:05PM -0500, Ken Raeburn wrote: > > "John Brezak" writes: > > > Name canonlicalization is not a mechanism for access control. If a > > > > No, but Kerberos principal names can be, and name > canonicalization has > > now become a part of handling names. [Jbrezak] ACLs generally contain canonical representations of a user - UID, UUID, SIDs that are specific to the authorization implementation. If one were to contruct an authorization mechansim that used a canonical principal name as a subject name for authz, then I agree that a service can be contructed to handle this. However you are trying to bridge Kerberos between authentication and authorization. > > > > > service is needed to handle lookup of service names to > canonical names, > > > LDAP would easiliy be able to handle this. > > > > So, which do you recommend -- that we mandate LDAP access to the > > database as part of all Kerberos implementations, or that > we offer no > > portable way to make gss_canonicalize_name work for the Kerberos > > mechanism? [Jbrezak] LDAP is one way or the request a ticket with the ticket extension above. > > > > Ken > -- > From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 4 21:07:22 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01129 for ; Mon, 4 Dec 2000 21:07:22 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id UAA08817 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 20:02:01 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA08807 for ; Mon, 4 Dec 2000 20:01:59 -0600 (CST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA13331 for ; Mon, 4 Dec 2000 20:01:58 -0600 (CST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:57:56 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 17:58:38 -0800 (Pacific Standard Time) Received: from df-goofy.platinum.corp.microsoft.com ([172.30.236.130]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 4 Dec 2000 17:58:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: RC4-HMAC Date: Mon, 4 Dec 2000 17:58:37 -0800 Message-ID: <52E28A515344104299B5E7AABC32045FC640A9@df-goofy.dogfood> Thread-Topic: RC4-HMAC Thread-Index: AcBeXQe6aEtF7tlSTU+aPlgMU1G+BgAAb+IQ From: "John Brezak" To: "Ken Raeburn" , , "Assar Westerlund" X-OriginalArrivalTime: 05 Dec 2000 01:58:38.0065 (UTC) FILETIME=[E2290610:01C05E5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id UAA08808 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit inline > -----Original Message----- > From: Ken Raeburn [mailto:raeburn@mit.edu] > Sent: Monday, December 04, 2000 5:45 PM > To: ietf-krb-wg@anl.gov > Subject: Re: RC4-HMAC > > > "John Brezak" writes: > > > A few clarifications: > > - The initial intent of the RC4-HMAC I-D was to publish it as > > informational for those folks that want to interoperate > with Win2000. > > - KD values and the assigned values represent the > "experimental" nature > > of the protocol and lessons learned during implementation > (bugs if you > > will). > > > > If this is to proceed on a standards track, then these > issues should be > > cleaned up, however the informational nature of the I-D is > still very > > relevant to at least the win2000 implementation. > > Sure. The main thing is, is it to be an Informational RFC or > standards-track? If it's informational, then it should describe what > Win2000 is doing well enough to make an interoperable implementation. > If it's standards track, it should conform to the Kerberos spec or > give a good reason why it the divergence was necessary. (IMO, of > course.) > > Jeff Schiller suggested that I go with Informational for the 3DES > GSSAPI spec, because eventually we ought to go with a new mechanism > that better utilizes the existing Kerberos messages and encryption > scheme definitions rather than re-inventing them. The 3DES extensions > are not intended to be what we want everyone to settle on, just an > intermediate measure for better security in the short term. [JBrezak] This was the purpose to discuss it at the WG. If there was sufficient interest to make RC4-HMAC a standards-track RFC or just informational. Conformance to the other KD table would be nice, but it may be very expensive to achive. The mapping table was something the Microsoft devs are considering for the 3DES work. > > > Heimdal has implemented the RC4-HMAC enctype and a few > others that are > > not public. The latest posting reflects changes pointed out during > > implementations from the earlier versions. > > Just to be clear: Heimdal's implemented the -02 version then? [JBrezak] That is my understanding - Assar? > > Ken > From owner-ietf-krb-wg@achilles.ctd.anl.gov Tue Dec 5 00:31:26 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23029 for ; Tue, 5 Dec 2000 00:31:26 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id XAA10415 for ietf-krb-wg-outgoing; Mon, 4 Dec 2000 23:23:15 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA10409 for ; Mon, 4 Dec 2000 23:23:13 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id XAA12722 for ; Mon, 4 Dec 2000 23:23:13 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id AAA22803; Tue, 5 Dec 2000 00:23:12 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? References: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> <20001204173523.U22005@sm2p1386swk.wdr.com> Mime-Version: 1.0 From: Ken Raeburn Date: 05 Dec 2000 00:23:12 -0500 In-Reply-To: Nicolas Williams's message of "Mon, 4 Dec 2000 17:35:25 -0500" Message-ID: Lines: 91 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Nicolas Williams writes: > Alternatively gss_canonicalize_name() will have to be prepared to > authenticate as the given principal name in order to canonicalize it, if > that given PN is not a canonical name to begin with. This may not always > be possible, certainly not in applications where one is trying to > populate ACLs with a batch job. Not authenticate *as*, since AS_REQ canonicalization isn't secure, but authenticate *to*, provided the KDC policy permits it, which it might not. The batch job shouldn't be any different -- if you don't have tickets, you can't ask the KDC anything. > Yet another alternative, for SPNs anyways, is algorythmic > canonicalization. If the client knows and can rely on a simple rule for From earlier discussions, it seems that's likely not to be the case. At least, not in any way you'd hard-code in an application. "John Brezak" writes: > > I would say that a new KDC protocol is called for whereby properly > > authenticated clients can ask the KDC to canonicalize principal names. > > [JBrezak] Now you really are turning Kerberos into a name service. I'd say name canonicalization does that already. The TGS_REQ canonicalization is an optimization of name service query and ticket acquisition -- at least, it has never looked like anything else to me. > [JBrezak] In the original proposal for NC, the list of aliases was > returned in a ticket extension. However this was left out of the > document because it was considered to be a performance optimization. But > this list would give the client/server the needed information to be able > to let the gss_canonicalize_name() api function. Um, no, not if the target principal in question is not allowed to be used as a service. I.e., KDC will let the principal act as a client, or participate in user-to-user authentication, but won't issue tickets encrypted in the principal's long-term secret key, since they could be attacked offline. That, in combination with preauth mechanisms, might be used as a way to further protect the secret key from exposure, for the really paranoid. And if the specified principal can be used as a normal service, the server name in the issued tickets will tell the application all it needs to know, at least for that one operation. And if the application needs to make use of any other alias information provided in the ticket extension, well, then you've got that name service functionality piggy-backed on a TGS_REQ exchange. The only problem is, IMO, we need a standard secure way to get the information without requiring a successful TGS_REQ exchange. > If the user needed to find out a canonical name for a principal, it > could make a TGS request for that principal and specify > name-canonicalization. The resulting ticket would have the canonical > name in the sname/srealm and the ticket extension would have the known > aliases. Yes, *if* KDC policy doesn't prohibit issuing tickets. > [Jbrezak] ACLs generally contain canonical representations of a user - > UID, UUID, SIDs that are specific to the authorization implementation. > If one were to contruct an authorization mechansim that used a canonical > principal name as a subject name for authz, then I agree that a service > can be contructed to handle this. However you are trying to bridge > Kerberos between authentication and authorization. I don't see it that way. Kerberos principal names have for a long time been a means of expressing a unique identity, that could be used directly for access control if the designer of the authorization scheme so desired. If we don't have a standalone name canonicalization scheme, that ability is to some degree lost. > > > So, which do you recommend -- that we mandate LDAP access to the > > > database as part of all Kerberos implementations, or that > > we offer no > > > portable way to make gss_canonicalize_name work for the Kerberos > > > mechanism? > > [Jbrezak] LDAP is one way or the request a ticket with the ticket > extension above. Suggesting a couple things that we might try, and which might work depending on the target realm's software and configuration, isn't a solution. Unless we make one of them (mandate LDAP, or insist that KDC policy cannot prohibit tickets from being issued) or something else be the standard way of getting this information, we still have no portable way to make gss_canonicalize_name work. From owner-ietf-krb-wg@achilles.ctd.anl.gov Tue Dec 5 17:45:42 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02999 for ; Tue, 5 Dec 2000 17:45:42 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA13729 for ietf-krb-wg-outgoing; Tue, 5 Dec 2000 16:32:53 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA13723 for ; Tue, 5 Dec 2000 16:32:51 -0600 (CST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA08074 for ; Tue, 5 Dec 2000 16:32:50 -0600 (CST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 5 Dec 2000 14:11:04 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Dec 2000 14:11:46 -0800 (Pacific Standard Time) Received: from df-goofy.platinum.corp.microsoft.com ([172.30.236.130]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 5 Dec 2000 14:11:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4599.0 content-class: urn:content-classes:message Subject: RE: name canonicalization review - canonicalization service? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 5 Dec 2000 14:11:45 -0800 Message-ID: <52E28A515344104299B5E7AABC32045F689F3F@df-goofy.dogfood> Thread-Topic: name canonicalization review - canonicalization service? Thread-Index: AcBee5CqliYs1V96TV2EOUg+kbjsdwAiu3wg From: "John Brezak" To: "Ken Raeburn" , X-OriginalArrivalTime: 05 Dec 2000 22:11:46.0567 (UTC) FILETIME=[5B7D0170:01C05F08] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id QAA13724 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Ken Raeburn [mailto:raeburn@mit.edu] > Sent: Monday, December 04, 2000 9:23 PM > To: ietf-krb-wg@anl.gov > Subject: Re: name canonicalization review - canonicalization service? > > > "John Brezak" writes: > > [JBrezak] In the original proposal for NC, the list of aliases was > > returned in a ticket extension. However this was left out of the > > document because it was considered to be a performance > optimization. But > > this list would give the client/server the needed > information to be able > > to let the gss_canonicalize_name() api function. > > Um, no, not if the target principal in question is not allowed to be > used as a service. I.e., KDC will let the principal act as a client, > or participate in user-to-user authentication, but won't issue tickets > encrypted in the principal's long-term secret key, since they could be > attacked offline. That, in combination with preauth mechanisms, might > be used as a way to further protect the secret key from exposure, for > the really paranoid. > > And if the specified principal can be used as a normal service, the > server name in the issued tickets will tell the application all it > needs to know, at least for that one operation. And if the > application needs to make use of any other alias information provided > in the ticket extension, well, then you've got that name service > functionality piggy-backed on a TGS_REQ exchange. > > The only problem is, IMO, we need a standard secure way to get the > information without requiring a successful TGS_REQ exchange. [JBrezak] A standard way when principal names are being used for authorization in this example? > > > If the user needed to find out a canonical name for a principal, it > > could make a TGS request for that principal and specify > > name-canonicalization. The resulting ticket would have the canonical > > name in the sname/srealm and the ticket extension would > have the known > > aliases. > > Yes, *if* KDC policy doesn't prohibit issuing tickets. > > > [Jbrezak] ACLs generally contain canonical representations > of a user - > > UID, UUID, SIDs that are specific to the authorization > implementation. > > If one were to contruct an authorization mechansim that > used a canonical > > principal name as a subject name for authz, then I agree > that a service > > can be contructed to handle this. However you are trying to bridge > > Kerberos between authentication and authorization. > > I don't see it that way. Kerberos principal names have for a long > time been a means of expressing a unique identity, that could be used > directly for access control if the designer of the authorization > scheme so desired. If we don't have a standalone name > canonicalization scheme, that ability is to some degree lost. [JBrezak] The problem is that there is now a possible indirection between the principal name being used for authentication and what is used for authorization. In cases where the authorization data in the ticket is being used for access control mechanism, there apparently is not a problem. However where the principal name is being used from the ticket, the name may not correspond to a principal name on an ACL. Worst case for such a service is that the canonical client principal name will be used on the ACL. > > > > > So, which do you recommend -- that we mandate LDAP access to the > > > > database as part of all Kerberos implementations, or that > > > we offer no > > > > portable way to make gss_canonicalize_name work for the Kerberos > > > > mechanism? > > > > [Jbrezak] LDAP is one way or the request a ticket with the ticket > > extension above. > > Suggesting a couple things that we might try, and which might work > depending on the target realm's software and configuration, isn't a > solution. Unless we make one of them (mandate LDAP, or insist that > KDC policy cannot prohibit tickets from being issued) or something > else be the standard way of getting this information, we still have no > portable way to make gss_canonicalize_name work. [JBrezak] I still prefer that a name service be used for lookups when using authenticated principal names for authorization. LDAP is an example of such a widely available name service, I don't see the need for designing another lookup service just for binding authorization principals (subjects) to authentication principals if one already exists. I'd suggest that if you want to construct a new lookup service, that it isn't part of Kerberos- revisions since it is intended to bridge authentication to name-based authorization. From owner-ietf-krb-wg@achilles.ctd.anl.gov Tue Dec 5 20:07:22 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00350 for ; Tue, 5 Dec 2000 20:07:22 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id SAA14938 for ietf-krb-wg-outgoing; Tue, 5 Dec 2000 18:54:57 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA14932 for ; Tue, 5 Dec 2000 18:54:55 -0600 (CST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA01709 for ; Tue, 5 Dec 2000 18:54:54 -0600 (CST) Received: from jtrostle-nt2 (dhcp-128-107-141-184.cisco.com [128.107.141.184]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA08806; Tue, 5 Dec 2000 16:54:23 -0800 (PST) Message-Id: <4.1.20001205164133.00b8e220@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Dec 2000 16:56:39 -0800 To: ietf-krb-wg@anl.gov, raeburn@mit.edu From: Jonathan Trostle Subject: name canonicalization in kerb revisions Cc: jtrostle@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Two things that should be considered for name canonicalization in the kerberos revisions: (1) Ticket extension to return list of alias names to the client in a TGS_REP message, signed with session key from the ticket: KRB-TE-REFERRAL :: = SEQUENCE { referred-realm[0] Realm, referred-server-names[1] SEQUENCE OF PrincipalNames OPTIONAL } (2) Language to encourage clients to canonicalize short names into the corresponding long name (possibly an alias): Clients MUST be capable of canonicalizing short names into long names and using the long name in the TGS_REQ message, in order to preserve interrealm interoperability. (Since a KDC that is presented with a short name may be unable to refer the client to the appropriate realm.) The client MUST check that the user entered short name is a prefix of the long name resulting from canonicalization. Jonathan From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 03:17:53 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28686 for ; Wed, 6 Dec 2000 03:17:53 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id CAA11621 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 02:09:00 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA11615 for ; Wed, 6 Dec 2000 02:08:58 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA05652 for ; Wed, 6 Dec 2000 02:08:56 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id DAA23989; Wed, 6 Dec 2000 03:08:55 -0500 (EST) To: Subject: Re: name canonicalization review - canonicalization service? References: <52E28A515344104299B5E7AABC32045F689F3F@df-goofy.dogfood> Mime-Version: 1.0 From: Ken Raeburn Date: 06 Dec 2000 03:08:55 -0500 In-Reply-To: "John Brezak"'s message of "Tue, 5 Dec 2000 14:11:45 -0800" Message-ID: Lines: 56 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk "John Brezak" writes: > > The only problem is, IMO, we need a standard secure way to get the > > information without requiring a successful TGS_REQ exchange. > > [JBrezak] A standard way when principal names are being used for > authorization in this example? Yes. > [JBrezak] The problem is that there is now a possible indirection > between the principal name being used for authentication and > what is used for authorization. In cases where the authorization No, the indirection is between the set of names that can be used for an authentication entity and the "true" name of the entity, where they used to be one and the same. > data in the ticket is being used for access control mechanism, > there apparently is not a problem. However where the principal > name is being used from the ticket, the name may not correspond > to a principal name on an ACL. Worst case for such a service is that > the canonical client principal name will be used on the ACL. Well, yes, clearly, but how do we get to that point? > [JBrezak] I still prefer that a name service be used for lookups when > using > authenticated principal names for authorization. LDAP is an example of > such > a widely available name service, I don't see the need for designing > another > lookup service just for binding authorization principals (subjects) to > authentication principals if one already exists. I'd suggest that if you > want to construct a new lookup service, that it isn't part of Kerberos- > revisions since it is intended to bridge authentication to name-based > authorization. To name-based anything besides authentication, really. Auditing, perhaps: Connections initiated by service principal foo/penguin.quux.com should be logged ... but what if that's not the canonical name? Accounting: Use of a service by user joe is charged to account #12345, but is his Kerberos principal in the local realm or another one at the company? Any time you want to specify the canonical authentication names of entities without authenticating to them as services. The current spec only provides for certain uses; anything else, and you just lose. I could turn it around and suggest that the whole business of permitting the login or other initial authentication of users from multiple realms (AS_REQ canonicalization), or the providing of multiple services by a single account, should be separate from the actual authentication itself, and handled through a different service that's consulted before Kerberos. Then Kerberos would be just the authentication service, and not authentication plus a piece of a name service. From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 03:27:02 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00680 for ; Wed, 6 Dec 2000 03:27:02 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id CAA11681 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 02:19:16 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA11674 for ; Wed, 6 Dec 2000 02:19:14 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id CAA07183 for ; Wed, 6 Dec 2000 02:19:13 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id DAA23993; Wed, 6 Dec 2000 03:19:12 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: name canonicalization in kerb revisions References: <4.1.20001205164133.00b8e220@nsm-mail2> Mime-Version: 1.0 From: Ken Raeburn Date: 06 Dec 2000 03:19:12 -0500 In-Reply-To: Jonathan Trostle's message of "Tue, 05 Dec 2000 16:56:39 -0800" Message-ID: Lines: 26 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Jonathan Trostle writes: > Two things that should be considered for name canonicalization in the kerberos revisions: (Once again, please wrap your lines to < 80 columns.) > (2) Language to encourage clients to canonicalize short names into > the corresponding long name (possibly an alias): Clients MUST be > capable of canonicalizing short names into long names and using the > long name in the TGS_REQ message, in order to preserve interrealm > interoperability. (Since a KDC that is presented with a short name > may be unable to refer the client to the appropriate realm.) The > client MUST check that the user entered short name is a prefix of > the long name resulting from canonicalization. I'm not clear on what you're saying here. If you're referring to principal name canonicalization, how can a client do the canonicalization and *then* send off its TGS_REQ message, if TGS_REQ is the only way to do the canonicalization? And what does one name being a prefix of another have to do with it? Your use of "short name" and "long name" make me think maybe you're talking about hostnames, but then we still have the open question of doing DNS canonicalization securely, and again I don't see how the prefix check helps. Just because you get back a DNS response saying "fileserver-1" is a CNAME for "fileserver-1.raeburn.org" doesn't mean I'm not spoofing... From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 15:38:16 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12188 for ; Wed, 6 Dec 2000 15:38:15 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id OAA18522 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 14:31:20 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA18516 for ; Wed, 6 Dec 2000 14:31:16 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA13482 for ; Wed, 6 Dec 2000 14:31:14 -0600 (CST) Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id VAA16791; Wed, 6 Dec 2000 21:24:04 +0100 (MEZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [10.18.108.105]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id VAA28125; Wed, 6 Dec 2000 21:29:10 +0100 (MET) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id VAA16482; Wed, 6 Dec 2000 21:29:10 +0100 (MET) From: Martin Rex Message-Id: <200012062029.VAA16482@hw1464.wdf.sap-ag.de> Subject: Re: name canonicalization review - canonicalization service? To: jbrezak@Exchange.Microsoft.com (John Brezak) Date: Wed, 6 Dec 2000 21:29:10 +0100 (MET) Cc: ietf-krb-wg@anl.gov In-Reply-To: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> from "John Brezak" at Dec 4, 0 01:26:39 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit John Brezak wrote: > > Entries on ACLs in the Win2000 implementation are based on the SID - > where the SID is the unit of authorization. The Kerberos principal name > is not used for access control. In DCE this is also the case - access > control is based on the UUIDs not principals. When I read the DCE manuals, it explicitly mentioned that DCE explicitly offers name-based authentication. One of the reasons is (application) interoperability with standard Kerberos 5. As far as I recall, the protocol spec under discussion is the "standard" Kerberos 5... > > Name canonlicalization is not a mechanism for access control. If a > service is needed to handle lookup of service names to canonical names, > LDAP would easiliy be able to handle this. You're kidding. The Kerberos revisions document is about to be completed. Adding a requirement for LDAP access into every Kerberos 5 KDC and secure LDAP queries into every Kerberos 5 client is probably not what the people on this list are looking for. Not only because it's incompatible with the installed base, would seriously bloat the architecture and would delay the kerberos revisions spec by at least two more years. I know that Microsoft's incarnation of GSS-API (called SSPI) is broken and incomplete in particular concerning the name-based authentication, credentials acquisition and service principals, but the other two rfc-1964 compliant Kerberos GSSAPI mechanisms with true GSS-API v2 that I know (Cybersafe and MIT) are very usable with plain GSS-API v2 - no dirty hacks and additional APIs necessary to work around bugs and shortcomings. LDAP for name canonicalization would require that the Kerberos implementation must do it internally, below the GSS-API, or distributed gssapi-based applicatoins will not be able to use it. One of the *serious* drawbacks of LDAP lookups would be the additional (network) overhead. It would be a serious no-no to have a lookup during authentication, but even for name canonicalization during gss_canonicalize_name(), LDAP lookups would kill performance of most maintenance functions. Why does Microsoft put the PAC into the ticket? Why don't you look up that information via LDAP with the name from the name based authentication? We all know the answer: performance, complexity, reliability. -Martin From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 16:21:08 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24702 for ; Wed, 6 Dec 2000 16:21:07 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA19114 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 15:10:51 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA19108 for ; Wed, 6 Dec 2000 15:10:48 -0600 (CST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [194.39.131.53]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA21305 for ; Wed, 6 Dec 2000 15:10:46 -0600 (CST) Received: from sap-ag.de ([194.39.131.3]) by smtpde02.sap-ag.de (out) with ESMTP id WAA29099; Wed, 6 Dec 2000 22:05:04 +0100 (MEZ) Received: from hw1464.wdf.sap-ag.de (hw1464.wdf.sap-ag.de [10.18.108.105]) by sap-ag.de (8.8.8/8.8.8) with ESMTP id WAA29849; Wed, 6 Dec 2000 22:10:10 +0100 (MET) Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id WAA16753; Wed, 6 Dec 2000 22:10:11 +0100 (MET) From: Martin Rex Message-Id: <200012062110.WAA16753@hw1464.wdf.sap-ag.de> Subject: Re: name canonicalization review - canonicalization service? To: jbrezak@Exchange.Microsoft.com (John Brezak) Date: Wed, 6 Dec 2000 22:10:11 +0100 (MET) Cc: Ietf-krb-wg@anl.gov In-Reply-To: <52E28A515344104299B5E7AABC32045F689F3A@df-goofy.dogfood> from "John Brezak" at Dec 4, 0 05:45:44 pm Reply-To: mrex@sap-ag.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit John Brezak wrote: > > > From: Nicolas Williams [mailto:Nicolas.Williams@ubsw.com] > > > > I would say that a new KDC protocol is called for whereby properly > > authenticated clients can ask the KDC to canonicalize principal names. > > [JBrezak] Now you really are turning Kerberos into a name service. NO. Adding name canonicalization in the ticket request is the feature that introduces the "name service" functionality. You did that. Seperate-from-Authentication name canonicalization is required to provide the original authentication service in a consistent fashion. > > > > > I.e., clients authenticating with a kerberos ticket for any user or > > service principal should be able to ask the KDC to > > canonicalize a given > > principal name. > > [JBrezak] In the original proposal for NC, the list of aliases was > returned in a ticket extension. However this was left out of the > document because it was considered to be a performance optimization. But > this list would give the client/server the needed information to be able > to let the gss_canonicalize_name() api function. > > - Ticket extension data for aliases to optimize caching > KRB-TE-REFERRAL :: = SEQUENCE { > referred-realm[0] Realm, > referred-server-names[1] SEQUENCE OF PrincipalNames OPTIONAL > } > > The TE is signed with the ticket's session-key. > > If the user needed to find out a canonical name for a principal, it > could make a TGS request for that principal and specify > name-canonicalization. The resulting ticket would have the canonical > name in the sname/srealm and the ticket extension would have the known > aliases. Yuck! This looks like a very dirty hack to me. What about the canonicalization of user principal names -- from what I read on this list, there are KDCs that don't issue TGS for users? Portable gssapi based applications distinguish authenticated entities only by their canonical name, there is no user vs service distinction, because all SPKM and similar gssapi mechanisms don't have/offer such a distinction. When "maintaining" huge ACLs (i.e. >1000 entries being displayed to the user/admin), you would request tons of individual tickets that are trashed. Are there any limits in the KDCs on the amount of tickets (session keys) that can be generated per second (I'm not a cryptographer, but to me it sounds like draining entropy from the KDC in this fashion.) I'd really prefer a seperate request and reply that doesn't result in the creation of a ticket for the name that is to be canonicalized. > > > On Mon, Dec 04, 2000 at 04:41:05PM -0500, Ken Raeburn wrote: > > > "John Brezak" writes: > > > > Name canonlicalization is not a mechanism for access control. If a > > > > > > No, but Kerberos principal names can be, and name > > canonicalization has > > > now become a part of handling names. > > [Jbrezak] ACLs generally contain canonical representations of a user - > UID, UUID, SIDs that are specific to the authorization implementation. > If one were to contruct an authorization mechansim that used a canonical > principal name as a subject name for authz, then I agree that a service > can be contructed to handle this. However you are trying to bridge > Kerberos between authentication and authorization. No, not at all. If the authentication system doesn't play games with names, the out-of-band canonicalization is not necessary at all. It is the invention of the canonicalization during the ticket request that will require the out-of-band name canonicalization to retain the originally consistent authentication service. -Martin From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 17:37:37 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18642 for ; Wed, 6 Dec 2000 17:37:36 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA19994 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 16:23:22 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA19988 for ; Wed, 6 Dec 2000 16:23:19 -0600 (CST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.12.91]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA05389 for ; Wed, 6 Dec 2000 16:23:18 -0600 (CST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.2.Beta1/8.10.0.PreAlpha1) with ESMTP id eB6MNHU25363 for ; Wed, 6 Dec 2000 14:23:17 -0800 (PST) Date: Wed, 6 Dec 2000 14:23:17 -0800 (PST) From: "Booker C. Bense" To: Subject: Re: name canonicalization review - canonicalization service? In-Reply-To: <200012062029.VAA16482@hw1464.wdf.sap-ag.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Wed, 6 Dec 2000, Martin Rex wrote: > John Brezak wrote: > > > > > > > Name canonlicalization is not a mechanism for access control. - If it's available, it will be used as one. Regardless of the wisdom of the concept, it's just too easy to make that additional step. In many ways, the only thing an authority service really does is "name canonicalization". > > If a > > service is needed to handle lookup of service names to canonical names, > > LDAP would easiliy be able to handle this. > > > LDAP for name canonicalization would require that the Kerberos > implementation must do it internally, below the GSS-API, or > distributed gssapi-based applicatoins will not be able to use it. > > One of the *serious* drawbacks of LDAP lookups would be the > additional (network) overhead. It would be a serious no-no > to have a lookup during authentication, but even for name canonicalization > during gss_canonicalize_name(), LDAP lookups would kill performance > of most maintenance functions. Why does Microsoft put the PAC into > the ticket? Why don't you look up that information via LDAP with > the name from the name based authentication? We all know the > answer: performance, complexity, reliability. > - I also see a chicken and egg problem. How do you authenticate to LDAP to do the name lookup?[1] At our site the mapping between real world name [2] and kerberos principal is something we work pretty hard to give users a knob to control who can and can not view this information. It's been a real stumbling block to deploying W2k. Perhaps this is not an issue in the debate, I haven't been following the technical arguements well enough to say for sure. ( I must admit I consider this whole thing to be a blecherous hack, however much we need a secure naming service kerberos is the wrong place to put it. ) - IMHO, kerberos should stick to authentication and leave name canonicalization to a true authority service. To me it seems clear from this debate that you can't get it right unless you give up the idea that a principal IS the unique identifier of a user. Unless you add something like a SID or uuid and an authority model to go with it, you can't reliably specify between the "real" and "fake" principals. - Booker C. Bense [1]- The arguement about user principals may not apply in this case, but if you have to use the name canonicalization service to find the ldap service name to to use the name canonicalization service.... [2]- It's much more than just that mapping, pretty much connecting any data to the kerberos principal is considered to be a potential privacy issue. Your principal must be public, but the mapping of that principal to any other data is not. From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 19:25:53 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16996 for ; Wed, 6 Dec 2000 19:25:53 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id SAA25232 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 18:15:50 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA25226 for ; Wed, 6 Dec 2000 18:15:48 -0600 (CST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id SAA24679 for ; Wed, 6 Dec 2000 18:15:46 -0600 (CST) Received: from jtrostle-nt2 (dhcp-128-107-141-184.cisco.com [128.107.141.184]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA18512; Wed, 6 Dec 2000 16:14:44 -0800 (PST) Message-Id: <4.1.20001206155316.00b75a20@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 06 Dec 2000 16:17:00 -0800 To: Ken Raeburn , ietf-krb-wg@anl.gov From: Jonathan Trostle Subject: Re: name canonicalization in kerb revisions Cc: jtrostle@cisco.com In-Reply-To: References: <4.1.20001205164133.00b8e220@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk At 03:19 AM 12/6/00 -0500, Ken Raeburn wrote: >Jonathan Trostle writes: >> Two things that should be considered for name canonicalization in the >kerberos revisions: > >(Once again, please wrap your lines to < 80 columns.) > >> (2) Language to encourage clients to canonicalize short names into >> the corresponding long name (possibly an alias): Clients MUST be >> capable of canonicalizing short names into long names and using the >> long name in the TGS_REQ message, in order to preserve interrealm >> interoperability. (Since a KDC that is presented with a short name >> may be unable to refer the client to the appropriate realm.) The >> client MUST check that the user entered short name is a prefix of >> the long name resulting from canonicalization. > >I'm not clear on what you're saying here. If you're referring to >principal name canonicalization, how can a client do the >canonicalization and *then* send off its TGS_REQ message, if TGS_REQ >is the only way to do the canonicalization? And what does one name I'm saying that the client should do the conversion from the short name to the long name. Assuming that the possible DNS completions from the client's DNS completion list will only yield one possible principal name (in other words, that the order of the DNS completion list doesn't matter), then spoofing can at most lead to DoS attack. But the client would not canonicalize the alias to the DNS canonical name. Regarding the gss_canonicalize_name function, would the following work? gss_canonicalize_name does the conversion of the short name to the long name. Then the long name is inputted into init_sec_context. The target name argument in init_sec_context is IN/OUT and the mechanism returns the canonical name in the target name argument. This works for both Kerberos and X.509 certificates, assuming the X.509 cert contains the alias DNS names as subjectAltName extensions. >being a prefix of another have to do with it? > >Your use of "short name" and "long name" make me think maybe you're >talking about hostnames, but then we still have the open question of >doing DNS canonicalization securely, and again I don't see how the >prefix check helps. Just because you get back a DNS response saying >"fileserver-1" is a CNAME for "fileserver-1.raeburn.org" doesn't mean >I'm not spoofing... I don't understand your example - fileserver-1 is not a domain name. Is it supposed to be a short name? Jonathan From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 21:54:19 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13881 for ; Wed, 6 Dec 2000 21:54:18 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id UAA28558 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 20:43:57 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA28552 for ; Wed, 6 Dec 2000 20:43:54 -0600 (CST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id UAA16703 for ; Wed, 6 Dec 2000 20:43:52 -0600 (CST) Received: from jtrostle-nt2 (dhcp-128-107-141-184.cisco.com [128.107.141.184]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA27406 for ; Wed, 6 Dec 2000 18:43:21 -0800 (PST) Message-Id: <4.1.20001206095402.00b69610@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 06 Dec 2000 18:45:37 -0800 To: ietf-krb-wg@anl.gov From: Jonathan Trostle Subject: update to change/set password Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_37038007==_" Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk --=====================_37038007==_ Content-Type: text/plain; charset="us-ascii" I have attached the updated Kerb change/set password draft. I made some minor changes plus I added the functionality to have the server generate keys and return them to the client, which was requested in the last WG meeting. There is a new field in the request structure: RequestFlags which has the flag that the client sets to tell the server to return keys. Only to be used in change/set key. Also, the reply message has a new status (11) which the server uses to tell the client that the KeySequences structure is included in the edata of the reply message. The new keys are in the KeySequences structure. Jonathan --=====================_37038007==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-ietf-cat-kerberos-set-passwd-04.txt" Content-Transfer-Encoding: quoted-printable =0AINTERNET-DRAFT Mike Swift= =0Adraft-ietf-cat-kerberos-set-passwd-04.txt University of= WA=0ADecember 2000 Jonathan= Trostle=0A Cisco= Systems=0A John= Brezak=0A Microsoft=0A= Bill Gossman=0A = Cybersafe=0A=0A = Kerberos Set/Change Password: Version 2=0A=0A=0A0. Status Of This Memo=0A= =0A This document is an Internet-Draft and is in full conformance with =0A= all provisions of Section 10 of RFC2026 [1]. =0A=0A Internet-Drafts are= working documents of the Internet Engineering=0A Task Force (IETF), its= areas, and its working groups. Note that=0A other groups may also= distribute working documents as =0A Internet-Drafts.=0A=0A = Internet-Drafts are draft documents valid for a maximum of six=0A months= and may be updated, replaced, or obsoleted by other=0A documents at any= time. It is inappropriate to use Internet-=0A Drafts as reference= material or to cite them other than as=0A "work in progress."=0A=0A The= list of current Internet-Drafts can be accessed at=0A = http://www.ietf.org/ietf/1id-abstracts.txt=0A=0A The list of= Internet-Draft Shadow Directories can be accessed at=0A = http://www.ietf.org/shadow.html.=0A=0A Comments and suggestions on this= document are encouraged. Comments =0A on this document should be sent to= the CAT working group discussion =0A list: ietf-cat-wg@stanford.edu.=0A= =0A This draft expires on June 30th, 2001.=0A=0A1. Abstract=0A=0A The= Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), =0A does= not allow for an administrator to set a password for a new user. =0A This= functionality is useful in some environments, and this proposal =0A = extends [4] to allow password setting. The changes are: adding new =0A = fields to the request message to indicate the principal which is =0A = having its password set, not requiring the initial flag in the service =0A = ticket, using a new protocol version number, and adding three new =0A = result codes. We also extend the set/change protocol to allow a =0A = client to send a sequence of keys to the KDC instead of a cleartext =0A = password. If in the cleartext password case, the cleartext password =0A = fails to satisfy password policy, the server should use the result =0A = code KRB5_KPASSWD_POLICY_REJECT.=0A=0C=0A2. Conventions used in this= document =0A =0A The key words "MUST", "MUST NOT", "REQUIRED",= "SHALL", "SHALL NOT", =0A "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",= and "OPTIONAL" in =0A this document are to be interpreted as described in= RFC-2119 [2]. =0A =0A3. The Protocol=0A=0A The service must accept= requests on UDP port 464 and TCP port 464 as =0A well. The protocol= consists of a single request message followed by =0A a single reply= message. For UDP transport, each message must be fully =0A contained in= a single UDP packet.=0A=0A For TCP transport, there is a 4 octet header= in network byte order=0A precedes the message and specifies the length of= the message. This=0A requirement is consistent with the TCP transport= header in 1510bis.=0A=0ARequest Message=0A=0A 0 1 = 2 3=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= message length | protocol version number |=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= AP_REQ length | AP-REQ data /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A /= KRB-PRIV message /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A = All 16 bit fields are in network byte order. =0A=0A message length field:= contains the number of bytes in the message =0A including this field.=0A= =0A protocol version number: contains the hex constant 0x0002 (network=0A = byte order).=0A=0A AP-REQ length: length of AP-REQ data, in bytes. If= the length is zero, =0A then the last field contains a KRB-ERROR message= instead of a KRB-PRIV =0A message.=0A=0A AP-REQ data: (see [3]) For a= change password/key request, the AP-REQ =0A message service ticket sname,= srealm principal identifier is =0A kadmin/changepw@REALM where REALM is= the realm of the change password =0A service. The same applies to a set= password/key request except the =0A principal identifier is= kadmin/setpw@REALM. To enable setting of =0A passwords/keys, it is not= required that the initial flag be set in the =0A Kerberos service ticket.= The initial flag is required for change requests,=0A but not for set= requests. We have the following definitions:=0A=0A old= passwd initial flag target principal can be=0A in= request? required? distinct from =0A = authenticating principal?=0A = =0A change password: yes yes no=0A=0A set= password: no policy (*) yes=0A=0A set key: no = policy (*) yes=0A =0A change= key: no yes no=0A=0C=0A policy (*):= implementations SHOULD allow administrators to set the=0A initial flag= required for set requests policy to either yes or no.=0A Clients MUST be= able to retry set requests that fail due to error 7=0A (initial flag= required) with an initial ticket. Clients SHOULD NOT=0A cache service= tickets targetted at kadmin/changepw.=0A=0A KRB-PRIV message (see [3])= This KRB-PRIV message must be encrypted=0A using the session key from the= ticket in the AP-REQ. =0A=0A The user-data component of the message= consists of the following ASN.1 =0A encoded structure:=0A=0A = ChangePasswdData :: =3D SEQUENCE {=0A = newpasswdorkeys[0] NewPasswdOrKeys,=0A targname[1] = PrincipalName OPTIONAL,=0A -- only present= in set password/key: the principal=0A -- which will= have its password or keys set. Not=0A -- present in= a set request if the client principal=0A -- from= the ticket is the principal having its =0A --= passwords or keys set.=0A targrealm[2] Realm= OPTIONAL, =0A -- only present in set password/key:= the realm for =0A -- the principal which will have= its password or=0A -- keys set. Not present in a= set request if the =0A -- client principal from the= ticket is the principal =0A -- having its passwords= or keys set.=0A flags[3] RequestFlags= OPTIONAL=0A -- 32 bit string=0A = }=0A=0A NewPasswdOrKeys :: =3D CHOICE {=0A = passwords[0] PasswordSequence, -- change/set passwd =0A = keyseq[1] KeySequences -- change/set key=0A }=0A = =0A KeySequences :: =3D SEQUENCE OF KeySequence=0A=0A = KeySequence :: =3D SEQUENCE {=0A key[0] = EncryptionKey,=0A salt[1] OCTET STRING= OPTIONAL,=0A salt-type[2] INTEGER OPTIONAL=0A }=0A= =0A PasswordSequence :: =3D SEQUENCE {=0A = newpasswd[0] OCTET STRING,=0A oldpasswd[1] OCTET= STRING OPTIONAL=0A -- oldpasswd always present for= change password=0A -- but not present for set= password, set key, or=0A -- change key=0A }=0A=0A= RequestFlags :: =3D BIT STRING {=0A reserved(0),=0A = request-srv-gen-keys(1) -- only in change/set keys=0A = -- if the client desires=0A = -- server to contribute to keys;=0A = -- server will return keys=0A = }=0A=0C=0A=0A The server must verify the AP-REQ= message, check whether the client =0A principal in the ticket is= authorized to set or change the password =0A (either for that principal,= or for the principal in the targname =0A field if present), and decrypt= the new password/keys. The server =0A also checks whether the initial= flag is required for this request, =0A replying with status 0x0007 if it= is not set and should be. An =0A authorization failure is cause to= respond with status 0x0005. For =0A forward compatibility, the server= should be prepared to ignore fields =0A after targrealm in the structure= that it does not understand. =0A=0A The newpasswdorkeys field contains= either the new cleartext password =0A (with the old cleartext password= for a change password operation), =0A or a sequence of encryption keys= with their respective salts. =0A=0A In the cleartext password case, if= the old password is sent in the=0A request, the request MUST be a change= password request. If the old =0A password is not present in the request,= the request MUST be a set=0A password request. The server should apply= policy checks to the old =0A and new password after verifying that the= old password is valid. =0A The server can check validity by obtaining a= key from the old =0A password with a keytype that is present in the KDC= database for the =0A user and comparing the keys for equality. The server= then generates =0A the appropriate keytypes from the password and stores= them in the KDC =0A database. If all goes well, status 0x0000 is returned= to the client =0A in the reply message (see below). For a change password= operation,=0A the initial flag in the service ticket MUST be set. =0A=0A = In the key sequence case, the sequence of keys is sent to the change=0A = or set password service (kadmin/changepw or kadmin/setpw respectively). =0A= For a principal that can act as a server, its preferred keytype should = =0A be sent as the first key in the sequence, but the KDC is not required= =0A to honor this preference. Application servers should use the key =0A = sequence option for changing/setting their keys. The change/set password = =0A services should check that all keys are in the proper format,= returning =0A the KRB5_KPASSWD_MALFORMED error otherwise. =0A=0A For= change/set key, the request message may include the request flags bit=0A = string with the request-srv-gen-keys bit set. In this case, the client=0A = is requesting that the server add entropy to its keys in the KeySequences= =0A field. When using this option, the client SHOULD attempt to generate = =0A pseudorandom keys with as much entropy as possible in its request.= The=0A server will return the final key sequence in a KeySequences= structure in=0A the edata of the reply message. A conformant server MUST= support this =0A option.=0A=0AReply Message=0A=0A 0 = 1 2 3=0A 0 1 2 3 4 5 6 7 8 9 0= 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= message length | protocol version number |=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= AP_REP length | AP-REP data /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A /= KRB-PRIV message /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A=0C= =0A All 16 bit fields are in network byte order. =0A=0A message length= field: contains the number of bytes in the message =0A including this= field.=0A=0A protocol version number: contains the hex constant 0x0002= (network=0A byte order). (The reply message has the same format as in= [4]).=0A=0A AP-REP length: length of AP-REP data, in bytes. If the length= is zero, =0A then the last field contains a KRB-ERROR message instead of= a KRB-PRIV =0A message.=0A=0A AP-REP data: the AP-REP is the response= to the AP-REQ in the request =0A packet.=0A =0A KRB-PRIV from [4]:= This KRB-PRIV message must be encrypted using the =0A session key from= the ticket in the AP-REQ.=0A=0A The server will respond with a KRB-PRIV= message unless it cannot=0A validate the client AP-REQ or KRB-PRIV= message, in which case it will=0A respond with a KRB-ERROR message. NOTE:= Unlike change password version=0A 1, the KRB-ERROR message will be sent= back without any encapsulation. =0A=0A The user-data component of the= KRB-PRIV message, or e-data component =0A of the KRB-ERROR message, must= consist of the following data.=0A=0A 0 1 = 2 3=0A 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8= 9 0 1 2 3 4 5 6 7 8 9 0 1=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= result code | result string /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A |= edata /=0A = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=0A = result code (16 bits) (result codes 0-4 are from [4]):=0A The= result code must have one of the following values (network=0A byte= order):=0A KRB5_KPASSWD_SUCCESS 0 request succeeds (This value= is not =0A allowed in a KRB-ERROR= message)=0A KRB5_KPASSWD_MALFORMED 1 request fails due to being= malformed=0A KRB5_KPASSWD_HARDERROR 2 request fails due to= "hard" error in=0A processing the= request (for example, =0A there is a= resource or other problem =0A causing= the request to fail)=0A KRB5_KPASSWD_AUTHERROR 3 request fails= due to an error in =0A authentication= processing=0A KRB5_KPASSWD_SOFTERROR 4 request fails due to a= soft error =0A in processing the= request =0A KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized=0A= KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported=0A = KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required=0A = KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;=0A = the result string should include a text message to be presented=0A = to the user.=0A KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does= not exist=0A (only in response to a set password or set key= request).=0A KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a= key sequence=0A containing at least one etype that is not supported= by the KDC.=0A=0C=0A The response edata contains an ASN.1 encoded= PKERB-ETYPE-INFO =0A type that specifies the etypes that the KDC= supports:=0A =0A KERB-ETYPE-INFO-ENTRY :: =3D SEQUENCE {=0A= encryption-type[0] INTEGER,=0A salt[1] = OCTET STRING OPTIONAL -- not sent=0A }=0A=0A = PKERB-ETYPE-INFO ::=3D SEQUENCE OF KERB-ETYPE-INFO-ENTRY=0A=0A The= client should retry the request using only etypes (keytypes)=0A = that are contained within the PKERB-ETYPE-INFO structure in the=0A = previous response. =0A KRB5_KPASSWD_ETYPE_SRV_GEN_KEYS 11 the= request has the request-=0A srv-gen-keys flag set and the server is= returning the KeySequence=0A structure defined above in the edata= field of the reply. The server=0A returns one key sequence= structure of the same keytype for each key =0A sequence structure= in the client request, unless it does not support=0A one of the= keytypes (or etypes). In that case, it returns error=0A = KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST=0A = add keylength number of bits of entropy to each key. The assumption=0A = here is that the client may have added insufficient entropy to the=0A = request keys. The server SHOULD use the client key from each =0A = KeySequence structure as input into the final keyvalue for the =0A = returned key. =0A 0xFFFF if the request fails for some other= reason.=0A The client must interpret any non-zero result code as a= failure.=0A result string - from [4]:=0A This field is a UTF-8= encoded string which should be displayed=0A to the user by the= client. Specific reasons for a password =0A set/change policy= failure is one use for this string. =0A edata: used to convey= additional information as defined by the =0A result code. =0A=0A4.= Acknowledgements=0A =0A The authors thank Tony Andrea for his input to= the document.=0A=0A5. References=0A=0A [1] Bradner, S., "The Internet= Standards Process -- Revision 3", BCP =0A 9, RFC 2026, October 1996.= =0A =0A [2] Bradner, S., "Key words for use in RFCs to Indicate= Requirement =0A Levels", BCP 14, RFC 2119, March 1997 =0A =0A [3]= J. Kohl, C. Neuman. The Kerberos Network Authentication=0A Service= (V5), Request for Comments 1510.=0A=0A [4] M. Horowitz. Kerberos Change= Password Protocol,=0A ftp://ds.internic.net/internet-drafts/=0A = draft-ietf-cat-kerb-chg-password-02.txt=0A=0A6. Expiration Date=0A=0A = This draft expires on June 30th, 2001.=0A=0C=0A7. Authors' Addresses=0A=0A = Jonathan Trostle=0A Cisco Systems=0A 170 W. Tasman Dr.=0A San Jose,= CA 95134=0A Email: jtrostle@cisco.com=0A=0A Mike Swift =0A University= of Washington=0A Seattle, WA=0A Email: mikesw@cs.washington.edu=0A=0A = John Brezak=0A 1 Microsoft Way=0A Redmond, WA 98052=0A Email:= jbrezak@microsoft.com=0A=0A Bill Gossman=0A Cybersafe Corporation=0A = 1605 NW Sammamish Rd.=0A Issaquah, WA 98027-5378=0A Email: bill.gossman= @cybersafe.com=0A=0A --=====================_37038007==_-- From owner-ietf-krb-wg@achilles.ctd.anl.gov Wed Dec 6 22:29:07 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19983 for ; Wed, 6 Dec 2000 22:29:06 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id VAA29218 for ietf-krb-wg-outgoing; Wed, 6 Dec 2000 21:20:15 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA29212 for ; Wed, 6 Dec 2000 21:20:13 -0600 (CST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id VAA21891 for ; Wed, 6 Dec 2000 21:20:11 -0600 (CST) Received: from jtrostle-nt2 (dhcp-128-107-141-184.cisco.com [128.107.141.184]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id TAA28818; Wed, 6 Dec 2000 19:19:40 -0800 (PST) Message-Id: <4.1.20001206191414.00b87c50@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 06 Dec 2000 19:21:56 -0800 To: Jonathan Trostle , ietf-krb-wg@anl.gov From: Jonathan Trostle Subject: Re: update to change/set password In-Reply-To: <4.1.20001206095402.00b69610@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk At 06:45 PM 12/6/00 -0800, Jonathan Trostle wrote: > >I have attached the updated Kerb change/set password draft. I made some >minor changes plus I added the functionality to have the server generate >keys and return them to the client, which was requested in the last WG >meeting. There is a new field in the request >structure: RequestFlags which has the flag that the client sets to tell the >server to return keys. Only to be used in change/set key. Also, the reply >message has a new status (11) which the server uses to tell the client that >the KeySequences structure is included in the edata of the reply message. >The new keys are in the KeySequences structure. > >Jonathan > Here is text: INTERNET-DRAFT Mike Swift draft-ietf-cat-kerberos-set-passwd-04.txt University of WA December 2000 Jonathan Trostle Cisco Systems John Brezak Microsoft Bill Gossman Cybersafe Kerberos Set/Change Password: Version 2 0. Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the CAT working group discussion list: ietf-cat-wg@stanford.edu. This draft expires on June 30th, 2001. 1. Abstract 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. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. The Protocol The service must accept requests on UDP port 464 and TCP port 464 as well. The protocol consists of a single request message followed by a single reply message. For UDP transport, each message must be fully contained in a single UDP packet. For TCP transport, there is a 4 octet header in network byte order precedes the message and specifies the length of the message. This requirement is consistent with the TCP transport header in 1510bis. Request Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP_REQ length | AP-REQ data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All 16 bit fields are in network byte order. message length field: contains the number of bytes in the message including this field. protocol version number: contains the hex constant 0x0002 (network byte order). AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, then the last field contains a KRB-ERROR message instead of a KRB-PRIV message. AP-REQ data: (see [3]) For a change password/key request, the AP-REQ message service ticket sname, srealm principal identifier is kadmin/changepw@REALM where REALM is the realm of the change password service. The same applies to a set password/key request except the principal identifier is kadmin/setpw@REALM. To enable setting of passwords/keys, it is not required that the initial flag be set in the Kerberos service ticket. The initial flag is required for change requests, but not for set requests. We have the following definitions: old passwd initial flag target principal can be in request? required? distinct from authenticating principal? change password: yes yes no set password: no policy (*) yes set key: no policy (*) yes change key: no yes no policy (*): implementations SHOULD allow administrators to set the initial flag required for set requests policy to either yes or no. Clients MUST be able to retry set requests that fail due to error 7 (initial flag required) with an initial ticket. Clients SHOULD NOT cache service tickets targetted at kadmin/changepw. KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted using the session key from the ticket in the AP-REQ. The user-data component of the message consists of the following ASN.1 encoded structure: ChangePasswdData :: = SEQUENCE { newpasswdorkeys[0] NewPasswdOrKeys, targname[1] PrincipalName OPTIONAL, -- only present in set password/key: the principal -- which will have its password or keys set. Not -- present in a set request if the client principal -- from the ticket is the principal having its -- passwords or keys set. targrealm[2] Realm OPTIONAL, -- only present in set password/key: the realm for -- the principal which will have its password or -- keys set. Not present in a set request if the -- client principal from the ticket is the principal -- having its passwords or keys set. flags[3] RequestFlags OPTIONAL -- 32 bit string } NewPasswdOrKeys :: = CHOICE { passwords[0] PasswordSequence, -- change/set passwd keyseq[1] KeySequences -- change/set key } KeySequences :: = SEQUENCE OF KeySequence KeySequence :: = SEQUENCE { key[0] EncryptionKey, salt[1] OCTET STRING OPTIONAL, salt-type[2] INTEGER OPTIONAL } PasswordSequence :: = SEQUENCE { newpasswd[0] OCTET STRING, oldpasswd[1] OCTET STRING OPTIONAL -- oldpasswd always present for change password -- but not present for set password, set key, or -- change key } RequestFlags :: = BIT STRING { reserved(0), request-srv-gen-keys(1) -- only in change/set keys -- if the client desires -- server to contribute to keys; -- server will return keys } The server must verify the AP-REQ message, check whether the client principal in the ticket is authorized to set or change the password (either for that principal, or for the principal in the targname field if present), and decrypt the new password/keys. The server also checks whether the initial flag is required for this request, replying with status 0x0007 if it is not set and should be. An authorization failure is cause to respond with status 0x0005. For forward compatibility, the server should be prepared to ignore fields after targrealm in the structure that it does not understand. The newpasswdorkeys field contains either the new cleartext password (with the old cleartext password for a change password operation), or a sequence of encryption keys with their respective salts. In the cleartext password case, if the old password is sent in the request, the request MUST be a change password request. If the old password is not present in the request, the request MUST be a set password request. The server should apply policy checks to the old and new password after verifying that the old password is valid. The server can check validity by obtaining a key from the old password with a keytype that is present in the KDC database for the user and comparing the keys for equality. The server then generates the appropriate keytypes from the password and stores them in the KDC database. If all goes well, status 0x0000 is returned to the client in the reply message (see below). For a change password operation, the initial flag in the service ticket MUST be set. In the key sequence case, the sequence of keys is sent to the change or set password service (kadmin/changepw or kadmin/setpw respectively). For a principal that can act as a server, its preferred keytype should be sent as the first key in the sequence, but the KDC is not required to honor this preference. Application servers should use the key sequence option for changing/setting their keys. The change/set password services should check that all keys are in the proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. For change/set key, the request message may include the request flags bit string with the request-srv-gen-keys bit set. In this case, the client is requesting that the server add entropy to its keys in the KeySequences field. When using this option, the client SHOULD attempt to generate pseudorandom keys with as much entropy as possible in its request. The server will return the final key sequence in a KeySequences structure in the edata of the reply message. A conformant server MUST support this option. Reply Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP_REP length | AP-REP data / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All 16 bit fields are in network byte order. message length field: contains the number of bytes in the message including this field. protocol version number: contains the hex constant 0x0002 (network byte order). (The reply message has the same format as in [4]). AP-REP length: length of AP-REP data, in bytes. If the length is zero, then the last field contains a KRB-ERROR message instead of a KRB-PRIV message. AP-REP data: the AP-REP is the response to the AP-REQ in the request packet. KRB-PRIV from [4]: This KRB-PRIV message must be encrypted using the session key from the ticket in the AP-REQ. The server will respond with a KRB-PRIV message unless it cannot validate the client AP-REQ or KRB-PRIV message, in which case it will respond with a KRB-ERROR message. NOTE: Unlike change password version 1, the KRB-ERROR message will be sent back without any encapsulation. The user-data component of the KRB-PRIV message, or e-data component of the KRB-ERROR message, must consist of the following data. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | result code | result string / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | edata / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ result code (16 bits) (result codes 0-4 are from [4]): The result code must have one of the following values (network byte order): KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not allowed in a KRB-ERROR message) KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in processing the request (for example, there is a resource or other problem causing the request to fail) KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in authentication processing KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error in processing the request KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; the result string should include a text message to be presented to the user. KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist (only in response to a set password or set key request). KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence containing at least one etype that is not supported by the KDC. The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO type that specifies the etypes that the KDC supports: KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { encryption-type[0] INTEGER, salt[1] OCTET STRING OPTIONAL -- not sent } PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY The client should retry the request using only etypes (keytypes) that are contained within the PKERB-ETYPE-INFO structure in the previous response. KRB5_KPASSWD_ETYPE_SRV_GEN_KEYS 11 the request has the request- srv-gen-keys flag set and the server is returning the KeySequence structure defined above in the edata field of the reply. The server returns one key sequence structure of the same keytype for each key sequence structure in the client request, unless it does not support one of the keytypes (or etypes). In that case, it returns error KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST add keylength number of bits of entropy to each key. The assumption here is that the client may have added insufficient entropy to the request keys. The server SHOULD use the client key from each KeySequence structure as input into the final keyvalue for the returned key. 0xFFFF if the request fails for some other reason. The client must interpret any non-zero result code as a failure. result string - from [4]: This field is a UTF-8 encoded string which should be displayed to the user by the client. Specific reasons for a password set/change policy failure is one use for this string. edata: used to convey additional information as defined by the result code. 4. Acknowledgements The authors thank Tony Andrea for his input to the document. 5. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5), Request for Comments 1510. [4] M. Horowitz. Kerberos Change Password Protocol, ftp://ds.internic.net/internet-drafts/ draft-ietf-cat-kerb-chg-password-02.txt 6. Expiration Date This draft expires on June 30th, 2001. 7. Authors' Addresses Jonathan Trostle Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: jtrostle@cisco.com Mike Swift University of Washington Seattle, WA Email: mikesw@cs.washington.edu John Brezak 1 Microsoft Way Redmond, WA 98052 Email: jbrezak@microsoft.com Bill Gossman Cybersafe Corporation 1605 NW Sammamish Rd. Issaquah, WA 98027-5378 Email: bill.gossman@cybersafe.com From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 10:26:15 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03101 for ; Thu, 7 Dec 2000 10:26:13 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id IAA10590 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 08:59:49 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA10583; Thu, 7 Dec 2000 08:59:45 -0600 (CST) 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 IAA07042; Thu, 7 Dec 2000 08:59:43 -0600 (CST) Message-ID: <3A2FA623.5517A92E@anl.gov> Date: Thu, 07 Dec 2000 09:00:51 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov CC: "Douglas E. Engert" Subject: Agenda (5.0) for Kerberos Working Group (krb-wg) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit CHAIR: Doug Engert AGENDA: Introduction Doug Engert (ANL) Kerberos revisions - Cliff Neuman (ISI) The main objective of the working group is to move this draft forward to last call. We have made some progress but not as much as I would have liked to see. Therefore this can last as long as needed. PKINIT, PKCROSS, PKTAPP - Waiting for Revisions, brief updates. Matt Hur (CISCO), Sasha Medvinsky (Motorola), Brian Tung (ISI) AES and Kerberos - Ken Raeburn MIT RC4-HMAC as "standard" etype - John Brezak (Microsoft) John reports that there are at least 3 implementations of Kerberos which have this, so should it be standard? Kerberos changes/set password I-D update John Brezak (Microsoft), Jonathan Trostle (CISCO) IAKERB - Preparing for Working Group last call Jonathan Trostle (CISCO) Kerberos GSS User-to-user John Brezek (Microsoft), Tom Yu (MIT) , Pat Moore (SANDIA) TLS KRB5 - brief update Jeffrey Altman (Columbia), Matt Hur (CISCO) draft-skibbie-krb-kdc-ldap-schema-00.txt (THIS ITEM HAS BEEN DROPED at request of author) "Donna Skibbie" -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 10:32:24 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03973 for ; Thu, 7 Dec 2000 10:32:23 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA11047 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 09:09:20 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA11040; Thu, 7 Dec 2000 09:09:17 -0600 (CST) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [130.237.221.147]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA08714; Thu, 7 Dec 2000 09:09:15 -0600 (CST) Received: from joda by blubb.pdc.kth.se with local (Exim 3.13 #1) id 1442eY-0001rz-00; Thu, 07 Dec 2000 16:08:10 +0100 To: "Douglas E. Engert" Cc: ietf-krb-wg@anl.gov Subject: Re: Agenda (5.0) for Kerberos Working Group (krb-wg) References: <3A2FA623.5517A92E@anl.gov> From: joda@pdc.kth.se (Johan Danielsson) Date: 07 Dec 2000 16:08:10 +0100 In-Reply-To: "Douglas E. Engert"'s message of "Thu, 07 Dec 2000 09:00:51 -0600" Message-ID: Lines: 9 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk "Douglas E. Engert" writes: > Kerberos changes/set password I-D update > John Brezak (Microsoft), Jonathan Trostle (CISCO) I'm not going to San Diego, but my view on this is that it shouldn't use ASN.1. /Johan From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 11:26:05 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12065 for ; Thu, 7 Dec 2000 11:26:04 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA11764 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 09:58:58 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA11758 for ; Thu, 7 Dec 2000 09:58:52 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA19298 for ; Thu, 7 Dec 2000 09:58:32 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id KAA25785; Thu, 7 Dec 2000 10:56:24 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma025604; Thu, 7 Dec 2000 10:56:06 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA29032; Thu, 7 Dec 2000 10:57:33 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA14842; Thu, 7 Dec 2000 10:56:11 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA15759; Thu, 7 Dec 2000 10:51:38 -0500 (EST) Date: Thu, 7 Dec 2000 10:51:38 -0500 From: Nicolas Williams To: John Brezak Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? Message-ID: <20001207105137.W22005@sm2p1386swk.wdr.com> Mail-Followup-To: John Brezak , Ken Raeburn , ietf-krb-wg@anl.gov References: <52E28A515344104299B5E7AABC32045F689F3A@df-goofy.dogfood> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <52E28A515344104299B5E7AABC32045F689F3A@df-goofy.dogfood>; from jbrezak@Exchange.Microsoft.com on Mon, Dec 04, 2000 at 05:45:44PM -0800 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Mon, Dec 04, 2000 at 05:45:44PM -0800, John Brezak wrote: > inline. Same. > > -----Original Message----- > > From: Nicolas Williams [mailto:Nicolas.Williams@ubsw.com] > > Sent: Monday, December 04, 2000 2:35 PM > > To: Ken Raeburn > > Cc: ietf-krb-wg@anl.gov > > Subject: Re: name canonicalization review - canonicalization service? > > > > > > I would say that a new KDC protocol is called for whereby properly > > authenticated clients can ask the KDC to canonicalize principal names. > > [JBrezak] Now you really are turning Kerberos into a name service. :) Yeah. I see. Upon further reflection I would agree that to add such a service would, in effect, enable the sort of semi-anonymous lookups that I was decrying elsewhere in that post. Thus I retract the above call for a new KDC service. > > > > I.e., clients authenticating with a kerberos ticket for any user or > > service principal should be able to ask the KDC to > > canonicalize a given > > principal name. > > [JBrezak] In the original proposal for NC, the list of aliases was > returned in a ticket extension. However this was left out of the > document because it was considered to be a performance optimization. But > this list would give the client/server the needed information to be able > to let the gss_canonicalize_name() api function. The list of aliases could, technically, be infinite. No? > - Ticket extension data for aliases to optimize caching > KRB-TE-REFERRAL :: = SEQUENCE { > referred-realm[0] Realm, > referred-server-names[1] SEQUENCE OF PrincipalNames OPTIONAL > } > > The TE is signed with the ticket's session-key. > > If the user needed to find out a canonical name for a principal, it > could make a TGS request for that principal and specify > name-canonicalization. The resulting ticket would have the canonical > name in the sname/srealm and the ticket extension would have the known > aliases. The user can find the canonical principal name in this way without this extension. I had missed the symmetry between UPN and SPN canonicalization. As far as Kerberos is concerned there is no real difference between UPNs and SPNs, but I had obviously lost sight of that. [...] > > > > Nico > > > > > > On Mon, Dec 04, 2000 at 04:41:05PM -0500, Ken Raeburn wrote: > > > "John Brezak" writes: > > > > Name canonlicalization is not a mechanism for access control. If a > > > > > > No, but Kerberos principal names can be, and name > > canonicalization has > > > now become a part of handling names. > > [Jbrezak] ACLs generally contain canonical representations of a user - > UID, UUID, SIDs that are specific to the authorization implementation. > If one were to contruct an authorization mechansim that used a canonical > principal name as a subject name for authz, then I agree that a service > can be contructed to handle this. However you are trying to bridge > Kerberos between authentication and authorization. Isn't bridging "between authentication and authorization" what Microsoft, effectively, did by putting user profiles in tickets? I understand what it is that putting user profiles in tickets achieves, or at least I think I do: - enables the use of the special group identity "Authenticated Users" in ActiveDirectory (LDAP) ACLs that protect data relevant to users' profiles. By putting the information in the ticket (that the user had to initially pre-authenticate to obtain -- thus we have an authenticated user) the lookup of the user's profile, by the services the user uses, is rendered unnecessary. Thus only authenticated users (not services) ever lookup user profiles in the name service (LDAP). - optimizes the login process by rendering user profile lookups unnecessary following Kerberos network authentication. I believe that the first of the above benefits of carrying user profiles in Kerberos tickets could have been achieved differently, without resort to adding platform-specific data into Kerberos tickets (except for the OtherNames extension I have mentioned before). > > > > > > > service is needed to handle lookup of service names to > > canonical names, > > > > LDAP would easiliy be able to handle this. > > > > > > So, which do you recommend -- that we mandate LDAP access to the > > > database as part of all Kerberos implementations, or that > > we offer no > > > portable way to make gss_canonicalize_name work for the Kerberos > > > mechanism? > > [Jbrezak] LDAP is one way or the request a ticket with the ticket > extension above. But if a service must use a name service to perform the canonicalization, it must really do so as itself, in which case the "Authenticated Users" special group is rendered significantly less useful, or it must impersonate the given PN to the name service -- something not always possible. A TGS request seems like the way to go. > > > > > > Ken > > -- > > Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 11:40:11 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15300 for ; Thu, 7 Dec 2000 11:40:10 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id KAA12018 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 10:12:37 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA12012 for ; Thu, 7 Dec 2000 10:12:35 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA23783 for ; Thu, 7 Dec 2000 10:12:13 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA04383; Thu, 7 Dec 2000 11:12:04 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma003740; Thu, 7 Dec 2000 11:10:54 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA02555; Thu, 7 Dec 2000 11:12:22 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA29890; Thu, 7 Dec 2000 11:11:01 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA15968; Thu, 7 Dec 2000 11:06:28 -0500 (EST) Date: Thu, 7 Dec 2000 11:06:28 -0500 From: Nicolas Williams To: John Brezak Cc: Ken Raeburn , ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? Message-ID: <20001207110627.Y22005@sm2p1386swk.wdr.com> Mail-Followup-To: John Brezak , Ken Raeburn , ietf-krb-wg@anl.gov References: <52E28A515344104299B5E7AABC32045F689F3F@df-goofy.dogfood> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <52E28A515344104299B5E7AABC32045F689F3F@df-goofy.dogfood>; from jbrezak@Exchange.Microsoft.com on Tue, Dec 05, 2000 at 02:11:45PM -0800 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Tue, Dec 05, 2000 at 02:11:45PM -0800, John Brezak wrote: > > -----Original Message----- > > From: Ken Raeburn [mailto:raeburn@mit.edu] > > Sent: Monday, December 04, 2000 9:23 PM > > To: ietf-krb-wg@anl.gov > > Subject: Re: name canonicalization review - canonicalization service? > > > > > > "John Brezak" writes: > > > > > > [Jbrezak] LDAP is one way or the request a ticket with the ticket > > > extension above. > > > > Suggesting a couple things that we might try, and which might work > > depending on the target realm's software and configuration, isn't a > > solution. Unless we make one of them (mandate LDAP, or insist that > > KDC policy cannot prohibit tickets from being issued) or something > > else be the standard way of getting this information, we still have no > > portable way to make gss_canonicalize_name work. > > [JBrezak] I still prefer that a name service be used for lookups when > using > authenticated principal names for authorization. LDAP is an example of > such > a widely available name service, I don't see the need for designing > another > lookup service just for binding authorization principals (subjects) to > authentication principals if one already exists. I'd suggest that if you > want to construct a new lookup service, that it isn't part of Kerberos- > revisions since it is intended to bridge authentication to name-based > authorization. Sure, but that is not what you implemented in Win2k. In Win2k you avoid the use of the name service by putting all the information that services might need about a user in the user's Kerberos tickets. I believe there's an advantage in your Win2k approach over that which you now propose for the rest of us, namely that the user profile lookups are performed by the KDC only and then only on behalf of [pre-]authenticated users. Whereas in the solution you now suggest the remote services can only perform the lookup as themselves; IFF the user forwards sufficient credentials can the service perform the name service lookups as the user The clear disadvantage of the Win2k profiles-in-tickets approach lies in platform interoperability, or, rather, lack thereof. I suppose the question boils down to: is the "Authenticated Users" special group worth the bother? And if so, how should Kerberos supposrt that concept? Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 11:44:07 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16219 for ; Thu, 7 Dec 2000 11:44:05 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id KAA12222 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 10:18:16 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA12206 for ; Thu, 7 Dec 2000 10:17:58 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA25192 for ; Thu, 7 Dec 2000 10:17:47 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA07366; Thu, 7 Dec 2000 11:17:45 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate via smap (V2.0) id xma006981; Thu, 7 Dec 2000 11:17:05 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA20421; Thu, 7 Dec 2000 11:16:11 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA07221; Thu, 7 Dec 2000 11:17:11 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA16109; Thu, 7 Dec 2000 11:12:39 -0500 (EST) Date: Thu, 7 Dec 2000 11:12:39 -0500 From: Nicolas Williams To: Jonathan Trostle Cc: ietf-krb-wg@anl.gov, raeburn@mit.edu Subject: Re: name canonicalization in kerb revisions Message-ID: <20001207111238.Z22005@sm2p1386swk.wdr.com> Mail-Followup-To: Jonathan Trostle , ietf-krb-wg@anl.gov, raeburn@mit.edu References: <4.1.20001205164133.00b8e220@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <4.1.20001205164133.00b8e220@nsm-mail2>; from jtrostle@cisco.com on Tue, Dec 05, 2000 at 04:56:39PM -0800 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Tue, Dec 05, 2000 at 04:56:39PM -0800, Jonathan Trostle wrote: > Two things that should be considered for name canonicalization in the kerberos revisions: > > (1) Ticket extension to return list of alias names to the client in a TGS_REP message, signed with session key from the ticket: > > KRB-TE-REFERRAL :: = SEQUENCE { > referred-realm[0] Realm, > referred-server-names[1] SEQUENCE OF PrincipalNames OPTIONAL > } Unfortunately, I would imagine that the list of aliases of an SPN may be infinite. Consider a setup where any SPN of the form /fqdn@REALM is always canonicalized to an SPN of the same form and fqdn but with a service name of 'host'. Then all SPNs of the form /fqdn@REALM in such a realm would have an infinite list of aliases. I suppose one could make a distinction between aliases in general and official aliases. > (2) Language to encourage clients to canonicalize short names into the corresponding long name (possibly an alias): Clients MUST be capable of canonicalizing short names into long names and using the long name in the TGS_REQ message, in order to preserve interrealm interoperability. (Since a KDC that is presented with a short name may be unable to refer the client to the appropriate realm.) The client MUST check that the user entered short name is a prefix of the long name resulting from canonicalization. Hmmm. Either that or the KDC and the client must perform hostname lookups in the same way (in DNS terms: they must have the same search list). But I agree. > Jonathan Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 12:01:07 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20568 for ; Thu, 7 Dec 2000 12:01:07 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id KAA17709 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 10:42:57 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA17703 for ; Thu, 7 Dec 2000 10:42:54 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA00962 for ; Thu, 7 Dec 2000 10:40:38 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA18453; Thu, 7 Dec 2000 11:37:53 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate via smap (V2.0) id xma018069; Thu, 7 Dec 2000 11:37:05 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA25115; Thu, 7 Dec 2000 11:36:11 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA27509; Thu, 7 Dec 2000 11:37:12 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA16426; Thu, 7 Dec 2000 11:32:40 -0500 (EST) Date: Thu, 7 Dec 2000 11:32:39 -0500 From: Nicolas Williams To: "Booker C. Bense" Cc: ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? Message-ID: <20001207113238.C22005@sm2p1386swk.wdr.com> Mail-Followup-To: "Booker C. Bense" , ietf-krb-wg@anl.gov References: <200012062029.VAA16482@hw1464.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from bbense@networking.stanford.edu on Wed, Dec 06, 2000 at 02:23:17PM -0800 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Wed, Dec 06, 2000 at 02:23:17PM -0800, Booker C. Bense wrote: > On Wed, 6 Dec 2000, Martin Rex wrote: > > > John Brezak wrote: > > - I also see a chicken and egg problem. How do you authenticate to > LDAP to do the name lookup?[1] At our site the mapping between real world > name [2] and kerberos principal is something we work pretty hard to give > users a knob to control who can and can not view this information. > It's been a real stumbling block to deploying W2k. Perhaps this is not > an issue in the debate, I haven't been following the technical > arguements well enough to say for sure. ( I must admit I consider this > whole thing to be a blecherous hack, however much we need a secure > naming service kerberos is the wrong place to put it. ) I agree with your sentiment, if you're addressing the W2k hacks... In Win2k there is no need to perform the out-of-band lookup nor to authenticate the lookup because the KDC adds all the relevant information (the "user profile") to the users' tickets. And the Win2k services don't use Kerberos principal names but Windows SIDs for authorization. > - IMHO, kerberos should stick to authentication and leave name > canonicalization to a true authority service. To me it seems > clear from this debate that you can't get it right unless you > give up the idea that a principal IS the unique identifier of > a user. Unless you add something like a SID or uuid and an > authority model to go with it, you can't reliably specify > between the "real" and "fake" principals. Right. Hence my Other-Names extension suggestions. If you authorize access using names other than Kerberos principal names (and certainly, all modern OS kernels that I know of do -- i.e., Unix uses UIDs/GIDs, Windows uses SIDs+RIDs, and so on). > - Booker C. Bense > > [1]- The arguement about user principals may not apply in this case, > but if you have to use the name canonicalization service to find the > ldap service name to to use the name canonicalization service.... > > [2]- It's much more than just that mapping, pretty much connecting > any data to the kerberos principal is considered to be a potential > privacy issue. Your principal must be public, but the mapping of that > principal to any other data is not. Hmmm. Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 12:09:43 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23452 for ; Thu, 7 Dec 2000 12:09:43 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id KAA17478 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 10:38:46 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA17472 for ; Thu, 7 Dec 2000 10:38:29 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA29906 for ; Thu, 7 Dec 2000 10:35:49 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAA13951; Thu, 7 Dec 2000 11:29:51 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma013472; Thu, 7 Dec 2000 11:28:59 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA06666; Thu, 7 Dec 2000 11:30:26 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA18613; Thu, 7 Dec 2000 11:29:04 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA16287; Thu, 7 Dec 2000 11:24:32 -0500 (EST) Date: Thu, 7 Dec 2000 11:24:32 -0500 From: Nicolas Williams To: mrex@sap-ag.de Cc: John Brezak , ietf-krb-wg@anl.gov Subject: Re: name canonicalization review - canonicalization service? Message-ID: <20001207112430.B22005@sm2p1386swk.wdr.com> Mail-Followup-To: mrex@sap-ag.de, John Brezak , ietf-krb-wg@anl.gov References: <52E28A515344104299B5E7AABC32045FC64093@df-goofy.dogfood> <200012062029.VAA16482@hw1464.wdf.sap-ag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200012062029.VAA16482@hw1464.wdf.sap-ag.de>; from martin.rex@sap-ag.de on Wed, Dec 06, 2000 at 09:29:10PM +0100 X-WDR-Disclaimer: Version $Revision: 1.13 $ Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk On Wed, Dec 06, 2000 at 09:29:10PM +0100, Martin Rex wrote: > John Brezak wrote: > > One of the *serious* drawbacks of LDAP lookups would be the > additional (network) overhead. It would be a serious no-no > to have a lookup during authentication, but even for name canonicalization > during gss_canonicalize_name(), LDAP lookups would kill performance > of most maintenance functions. Why does Microsoft put the PAC into > the ticket? Why don't you look up that information via LDAP with > the name from the name based authentication? We all know the > answer: performance, complexity, reliability. And one more reason: the data that makes up the profile can be protected in such a way that only the user it refers to can read it because only the [Win2k] KDC performs the lookup, and only during pre-authenticated AS_REQs. This means that services need not be so priviledged that they can enumerate all valid users via the name service, and so on, because they don't have to be. This means that anonymous and semi-anonymous lookups need not be allowed in the name service. This is a feature trumpeted in various places in the MS AD docs, in their classes and so on. And I don't blame them, as they have been criticised before for allowing such anonymous lookups in NT4 domains. > -Martin Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 17:47:23 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21086 for ; Thu, 7 Dec 2000 17:47:23 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA25241 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 16:29:32 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA25235 for ; Thu, 7 Dec 2000 16:29:30 -0600 (CST) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA19612 for ; Thu, 7 Dec 2000 16:29:30 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id XAA97122; Thu, 7 Dec 2000 23:27:55 +0100 (CET) (envelope-from assar) To: "John Brezak" Cc: "Ken Raeburn" , Subject: Re: RC4-HMAC References: <52E28A515344104299B5E7AABC32045FC640A9@df-goofy.dogfood> From: Assar Westerlund Date: 07 Dec 2000 23:27:54 +0100 In-Reply-To: "John Brezak"'s message of "Mon, 4 Dec 2000 17:58:37 -0800" Message-ID: <5l8zprj28l.fsf@assaris.sics.se> Lines: 14 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk "John Brezak" writes: > > > Heimdal has implemented the RC4-HMAC enctype and a few > > others that are > > > not public. The latest posting reflects changes pointed out during > > > implementations from the earlier versions. > > > > Just to be clear: Heimdal's implemented the -02 version then? > > [JBrezak] That is my understanding - Assar? Sorry for taking some time to answer. No, my current code implements the -03 version that I got from John. /assar From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 18:06:23 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23446 for ; Thu, 7 Dec 2000 18:06:22 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id QAA25443 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 16:36:24 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA25437 for ; Thu, 7 Dec 2000 16:36:22 -0600 (CST) Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA20871 for ; Thu, 7 Dec 2000 16:36:22 -0600 (CST) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id XAA97171; Thu, 7 Dec 2000 23:35:14 +0100 (CET) (envelope-from assar) To: "John Brezak" Cc: "Ken Raeburn" , Subject: Re: RC4-HMAC References: <52E28A515344104299B5E7AABC32045FC640A9@df-goofy.dogfood> <5l8zprj28l.fsf@assaris.sics.se> From: Assar Westerlund Date: 07 Dec 2000 23:35:13 +0100 In-Reply-To: Assar Westerlund's message of "07 Dec 2000 23:27:54 +0100" Message-ID: <5l4s0fj1we.fsf@assaris.sics.se> Lines: 22 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk I wrote: > "John Brezak" writes: > > > > Heimdal has implemented the RC4-HMAC enctype and a few > > > others that are > > > > not public. The latest posting reflects changes pointed out during > > > > implementations from the earlier versions. > > > > > > Just to be clear: Heimdal's implemented the -02 version then? > > > > [JBrezak] That is my understanding - Assar? > > Sorry for taking some time to answer. No, my current code implements > the -03 version that I got from John. Lemme try not add more to the confusion here. I did implement it from the text that I got from John. This text was labeled '03' and I got that from John before Novemember. But that text is (except for mark-up and formatting) identical to the draft-brezak-win2k-krb-rc4-mhac-02.txt internet-draft. /assar From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 18:53:26 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01949 for ; Thu, 7 Dec 2000 18:53:25 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id RAA26444 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 17:27:49 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA26438 for ; Thu, 7 Dec 2000 17:27:47 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA29786 for ; Thu, 7 Dec 2000 17:27:47 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id SAA25968; Thu, 7 Dec 2000 18:27:46 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: name canonicalization in kerb revisions References: <4.1.20001205164133.00b8e220@nsm-mail2> <4.1.20001206155316.00b75a20@nsm-mail2> Mime-Version: 1.0 From: Ken Raeburn Date: 07 Dec 2000 18:27:45 -0500 In-Reply-To: Jonathan Trostle's message of "Wed, 06 Dec 2000 16:17:00 -0800" Message-ID: Lines: 41 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Jonathan Trostle writes: > At 03:19 AM 12/6/00 -0500, Ken Raeburn wrote: > >I'm not clear on what you're saying here. If you're referring to > >principal name canonicalization, how can a client do the > >canonicalization and *then* send off its TGS_REQ message, if TGS_REQ > >is the only way to do the canonicalization? And what does one name > I'm saying that the client should do the conversion from the short name > to the long name. Assuming that the possible DNS completions from the > client's DNS completion list will only yield one possible principal name > (in other words, that the order of the DNS completion list doesn't matter), > then spoofing can at most lead to DoS attack. But the client would not > canonicalize the alias to the DNS canonical name. We have arbitrary constructed principal names based on user-provided names (of hosts, users, whatever), and we have canonical principal names, and various kinds of host names. What's a "short name" and what's a "long name", and what do you mean by "canonicalization", in this particular context? Now it sounds to me like maybe you're thinking of hostnames, and doing "canonicalization" only by tacking on domain names (and not doing CNAME processing). But that doesn't help if the KDC canonicalization converts "ftp/ftp.foo.com" into "host/mongo-server.foo.com@ATHENA.FOO.COM", even if the DNS has a CNAME record for ftp.foo.com. > Regarding the gss_canonicalize_name function, would the following work? > gss_canonicalize_name does the conversion of the short name to the > long name. Then the long name is inputted into init_sec_context. The > target name argument in init_sec_context is IN/OUT and the mechanism > returns the canonical name in the target name argument. This works for > both Kerberos and X.509 certificates, assuming the X.509 cert contains > the alias DNS names as subjectAltName extensions. So how does either the application or gss_canonical_name get from GSS name "ftp@ftp" to Kerberos principal name "host/mongo-server.foo.com"? > I don't understand your example - fileserver-1 is not a domain name. Is it > supposed to be a short name? See above confusion about terminology. From owner-ietf-krb-wg@achilles.ctd.anl.gov Thu Dec 7 18:55:01 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02427 for ; Thu, 7 Dec 2000 18:55:00 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id RAA26462 for ietf-krb-wg-outgoing; Thu, 7 Dec 2000 17:29:59 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA26456 for ; Thu, 7 Dec 2000 17:29:57 -0600 (CST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.18.1.70]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA00164 for ; Thu, 7 Dec 2000 17:29:57 -0600 (CST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id SAA25971; Thu, 7 Dec 2000 18:29:56 -0500 (EST) To: ietf-krb-wg@anl.gov Subject: Re: Section 3 (take 2) Kerberos Revisions for comment Mime-Version: 1.0 From: Ken Raeburn Date: 07 Dec 2000 18:29:56 -0500 Message-ID: Lines: 67 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.7 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Doug tells me this bounced when I sent it.... ------- Start of forwarded message ------- Subject: Re: Section 3 (take 2) Kerberos Revisions for comment Date: 28 Nov 2000 18:55:31 -0500 From: Ken Raeburn To: ietf-krb-wg@anl.gov References: 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 Nicolas Williams writes: > > If the authorization > > model is a broken one, > > We're going around in circles. We've agreed about authorizing based on > canonical names only. I think we are going in circles, yes, between a couple different points. We're agreed that using the canonical name is the only way to do it under the current spec. That was never in dispute. My original point was about text that would mislead someone who didn't know that and was trying to figure it out for herself. > I'm interested in knowing if there's a security problem with referrals. In the AS_REQ case, they're insecure; you can't do them securely unless a TGS_REQ fits your circumstances. As long as everyone knows this, no, there's no "security problem". (Unless you count not being able to implement things you want in your security framework because of this lack, but that's a different topic.) > This thread has dragged on. Let's end it here. I've proposed text > changes to the draft. Oh yes, the text in <20001120150603.B22005@sm2p1386swk.wdr.com>. Clients that request canonicalization MUST perform access checks based on the user principal name as canonicalized. and Clients must validate TGTs by using them to obtain service tickets for service principals, local to the client, whose keys can be used to validate said service tickets. I'd rephrase them a little, keeping in mind that some clients (e.g., kinit) don't care about validation or access checks, but they're basically right. For example, "...MUST perform any desired access checks...", "clients can validate..." That's why it took me so long to get my proposed changes sent out; I can spend forever tweaking the wording and still not get it quite right. :-) I thought my original suggestion of deleting half a sentence was adequate, but maybe there's less information in the context than I recall. Ken ------- End of forwarded message ------- From owner-ietf-krb-wg@achilles.ctd.anl.gov Fri Dec 8 11:11:02 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04096 for ; Fri, 8 Dec 2000 11:11:02 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA01244 for ietf-krb-wg-outgoing; Fri, 8 Dec 2000 09:50:54 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA01238 for ; Fri, 8 Dec 2000 09:50:52 -0600 (CST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA00523 for ; Fri, 8 Dec 2000 09:50:51 -0600 (CST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id KAA19891; Fri, 8 Dec 2000 10:50:36 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma017014; Fri, 8 Dec 2000 10:45:37 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA29999; Fri, 8 Dec 2000 10:47:04 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA13426; Fri, 8 Dec 2000 10:45:42 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA22261; Fri, 8 Dec 2000 10:41:08 -0500 (EST) Date: Fri, 8 Dec 2000 10:41:08 -0500 From: Nicolas Williams To: Ken Raeburn Cc: ietf-krb-wg@anl.gov Subject: Re: Section 3 (take 2) Kerberos Revisions for comment Message-ID: <20001208104106.P22005@sm2p1386swk.wdr.com> Mail-Followup-To: Ken Raeburn , ietf-krb-wg@anl.gov References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from raeburn@mit.edu on Thu, Dec 07, 2000 at 06:29:56PM -0500 X-WDR-Disclaimer: Version $Revision: 1.13 $ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by achilles.ctd.anl.gov id JAA01239 Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 8bit I think we're close to putting this to rest. Of course, the issues on the other thread, re: cgss_canonicalize_name() and so on may not be dead yet. On Thu, Dec 07, 2000 at 06:29:56PM -0500, Ken Raeburn wrote: > Nicolas Williams writes: > > We're going around in circles. We've agreed about authorizing based on > > canonical names only. > > I think we are going in circles, yes, between a couple different > points. > > We're agreed that using the canonical name is the only way to do it > under the current spec. That was never in dispute. My original point > was about text that would mislead someone who didn't know that and was > trying to figure it out for herself. Well, most RFCs are hard to read and understand without having other sources of information about the subject at hand, such as experience with existing implementations, natural language descriptions of the protocols/algorythms, etc... ;) > > I'm interested in knowing if there's a security problem with referrals. > > In the AS_REQ case, they're insecure; you can't do them securely > unless a TGS_REQ fits your circumstances. As long as everyone knows > this, no, there's no "security problem". (Unless you count not being > able to implement things you want in your security framework because > of this lack, but that's a different topic.) Well, yes, but I think we established also that IF one uses only the canonical name for authorization, and IF TGTs are validated, then an attacker cannot fool a client, using AS_REP spoofing, into allowing her access rights she didn't already have. In this sense there is no new vulnerability in AS referrals. Use of TCP with strong ISNs should certainly reduce the exposure to KDC spoofing. KDC spoofing should, at worst, make possible only a DoS attack. I believe that's the case, even with AS referrals thrown in the mix. > > This thread has dragged on. Let's end it here. I've proposed text > > changes to the draft. > > Oh yes, the text in <20001120150603.B22005@sm2p1386swk.wdr.com>. :) > Clients that request canonicalization MUST perform access checks > based on the user principal name as canonicalized. > > and > > Clients must validate TGTs by using them to obtain service tickets > for service principals, local to the client, whose keys can be > used to validate said service tickets. > > I'd rephrase them a little, keeping in mind that some clients (e.g., > kinit) don't care about validation or access checks, but they're > basically right. For example, "...MUST perform any desired access > checks...", "clients can validate..." That's why it took me so long > to get my proposed changes sent out; I can spend forever tweaking the > wording and still not get it quite right. :-) Hmmm. Well. Hmmm, see, kinit doesn't have to validate TGTs, no, but that's because kinit doesn't perform any access checks. How about: Clients that request canonicalization MUST perform access checks based on the user principal name as canonicalized and MUST validate credentials so obtained when the clients are using Kerberos for password validation and user authorization. I'm sure there's a much better way to phrase that. Perhaps: Clients that request canonicalization MUST perform access checks based on the user principal name as canonicalized and MUST validate credentials so obtained when the clients are using Kerberos for interactive authentication. Yeah? This leaves kinit-type clients unrestricted since kinit is not performing authentication. > I thought my original suggestion of deleting half a sentence was > adequate, but maybe there's less information in the context than I > recall. I'd have to go look at the draft again and I don't have time to do so today -- gotta go. > Ken Nico -- From owner-ietf-krb-wg@achilles.ctd.anl.gov Fri Dec 8 18:33:09 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03356 for ; Fri, 8 Dec 2000 18:33:08 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id RAA08303 for ietf-krb-wg-outgoing; Fri, 8 Dec 2000 17:10:42 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA08297 for ; Fri, 8 Dec 2000 17:10:38 -0600 (CST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA21972 for ; Fri, 8 Dec 2000 17:10:38 -0600 (CST) Received: by sentry.gw.tislabs.com; id SAA10532; Fri, 8 Dec 2000 18:04:47 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010524; Fri, 8 Dec 00 18:03:52 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id SAA25011 for ietf-krb-wg@anl.gov; Fri, 8 Dec 2000 18:00:09 -0500 (EST) Date: Fri, 8 Dec 2000 18:00:09 -0500 (EST) From: "David M. Balenson" Message-Id: <200012082300.SAA25011@clipper.gw.tislabs.com> To: ietf-krb-wg@anl.gov Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-krb-wg@achilles.ctd.anl.gov Sat Dec 9 02:21:54 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17440 for ; Sat, 9 Dec 2000 02:21:54 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id BAA14600 for ietf-krb-wg-outgoing; Sat, 9 Dec 2000 01:11:05 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id BAA14572 for ; Sat, 9 Dec 2000 01:11:03 -0600 (CST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id BAA23147 for ; Sat, 9 Dec 2000 01:11:02 -0600 (CST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id XAA12744; Fri, 8 Dec 2000 23:09:52 -0800 (PST) Message-Id: <4.1.20001208230559.00b7a9c0@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 08 Dec 2000 23:12:10 -0800 To: Ken Raeburn , ietf-krb-wg@anl.gov From: Jonathan Trostle Subject: Re: name canonicalization in kerb revisions In-Reply-To: References: <4.1.20001205164133.00b8e220@nsm-mail2> <4.1.20001206155316.00b75a20@nsm-mail2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk At 06:27 PM 12/7/00 -0500, Ken Raeburn wrote: >Jonathan Trostle writes: >> At 03:19 AM 12/6/00 -0500, Ken Raeburn wrote: >> >I'm not clear on what you're saying here. If you're referring to >> >principal name canonicalization, how can a client do the >> >canonicalization and *then* send off its TGS_REQ message, if TGS_REQ >> >is the only way to do the canonicalization? And what does one name >> I'm saying that the client should do the conversion from the short name >> to the long name. Assuming that the possible DNS completions from the >> client's DNS completion list will only yield one possible principal name >> (in other words, that the order of the DNS completion list doesn't matter), >> then spoofing can at most lead to DoS attack. But the client would not >> canonicalize the alias to the DNS canonical name. > >We have arbitrary constructed principal names based on user-provided >names (of hosts, users, whatever), and we have canonical principal >names, and various kinds of host names. What's a "short name" and >what's a "long name", and what do you mean by "canonicalization", in >this particular context? > >Now it sounds to me like maybe you're thinking of hostnames, and doing >"canonicalization" only by tacking on domain names (and not doing >CNAME processing). But that doesn't help if the KDC canonicalization >converts "ftp/ftp.foo.com" into >"host/mongo-server.foo.com@ATHENA.FOO.COM", even if the DNS has a >CNAME record for ftp.foo.com. > >> Regarding the gss_canonicalize_name function, would the following work? >> gss_canonicalize_name does the conversion of the short name to the >> long name. Then the long name is inputted into init_sec_context. The >> target name argument in init_sec_context is IN/OUT and the mechanism >> returns the canonical name in the target name argument. This works for >> both Kerberos and X.509 certificates, assuming the X.509 cert contains >> the alias DNS names as subjectAltName extensions. > >So how does either the application or gss_canonical_name get from GSS >name "ftp@ftp" to Kerberos principal name "host/mongo-server.foo.com"? ftp@ftp -> ftp/ftp.foo.com (on the client by making DNS queries on the completed ftp prefix, a spoofer can force a completion to a nonexistent name, or the client gets the correct name). ftp/ftp.foo.com goes into the TGS_REQ the response from the KDC contains the canonical name: host/mongo-server. foo.com Jonathan > >> I don't understand your example - fileserver-1 is not a domain name. Is it >> supposed to be a short name? > >See above confusion about terminology. From owner-ietf-krb-wg@achilles.ctd.anl.gov Sat Dec 9 10:54:06 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13924 for ; Sat, 9 Dec 2000 10:54:06 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA12936 for ietf-krb-wg-outgoing; Sat, 9 Dec 2000 09:39:32 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA12930 for ; Sat, 9 Dec 2000 09:39:30 -0600 (CST) From: scholars@us.net Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id JAA23943 for ; Sat, 9 Dec 2000 09:39:29 -0600 (CST) Received: from host40.pmi1.laurel.us.net by MIT.EDU with SMTP id AA24826; Sat, 9 Dec 00 10:40:53 EST Subject: IT TRAINING SCHOLARSHIPS Date: Sat, 9 Dec 2000 10:43:22 Message-Id: <367.381999.350837@38918745@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk IT TRAINING TUITION SCHOLARSHIPS FOR COLLEGE FACULTY, STUDENTS AND STAFF National Education Foundation CyberLearning, a non-profit organization dedicated to bridging the Digital Divide since 1994, is offering "No Excuse" tuition-free on-line training in Information Technology to the first 10,000 applicants. NEF CyberLearning courses, sponsored by the U.S. DEPARTMENT OF COMMERCE in the Federal Learning Exchange, have recently been acclaimed as "the Best of the Web" in online IT training by the FORBES magazine. Two online course programs are available: 1) Personal Computing (300+ self-study and instructor-led courses including all Microsoft Office, Web Design, Lotus Notes, Internet etc, tuition value of $3,000) for a $75 registration fee, the only cost. 2) Information Technology (650+ self-study and instructor-led courses, including the above and 350+ Certification courses in Microsoft, Cisco, Oracle, Novell, Web Master etc, tuition value of $6,500) for a $270 registration fee, the only cost. For either program, registration is valid through June 30, 2001 and there are no tuition costs for classes. The registrant receives free unlimited access to the courses, a vast online library, chat areas, certification skill tests and evaluations. This is an exceptional value and a great way for anyone to upgrade IT skills and learn new skills. To sign up, visit www.cyberlearning.org and click on "PC Scholarships(300+ Courses)" or click on "IT Scholarships (650+ Courses)." Then, complete the "Teachers and Others in Education" application. Manycolleges, schools and other educational organizations reimburse the training registration fee. Over 5,000 educators, faculty and students have already registered. To bridge the Digital Divide, NEF also provides "No Excuse" IT training scholarships to disadvantaged school and college students and teachers throughout the Nation. Please forward this information to all interested colleagues and others in education, colleges, universities and schools. To unsubscribe, please reply with "unsubscibe" in the subject line. About NEF: The non-profit National Education Foundation CyberLearning has provided tuition-free IT training to thousands of students, teachers, government and non-profit employees and disadvantaged individuals since 1994. NEF is well on its way to training 100,000 IT professionals and a million disadvantaged students nationally through its "No Excuse" IT Training Program. NEF has earned many distinctions including "The Ivy League of IT Training," "1995 Fairfax Human Rights Award," and " A Leader in Bridging the Digital Divide." "You are helping to empower America. I salute you for your ongoing commitment to creating a better America," --- President Clinton "Congratulations on a wonderful program," --- Congressional Leader Tom Davis(R-VA) "This is an awesome opportunity. You are making a difference."-- Washingtonjobs.com "NEF can make a positive difference in the lives of a great number of individuals." --- Microsoft " The best online IT training program I have come across. I am using it to train my students in IT certification," --- Doug Bertain, Palo Alto High School IT Teacher " I just want to say thank you on behalf of the many people that benefit from your incredible benevolence." --- Lilia Nunez, a registrant and a Digital Divide program beneficiary "I have found the CyberLearning online courses to be extremely easy and useful. I liked pre-course self-assessment and IT books online and available 24/7. The course screens were interactive and made me feel as if I was in the application itself. The site looks and feels very professional. The list of courses is huge. It includes something for almost everyone. I find this to be a very worthy cause." --- Ken Horowitz, IT Training Coordinator From owner-ietf-krb-wg@achilles.ctd.anl.gov Sat Dec 9 13:26:29 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03741 for ; Sat, 9 Dec 2000 13:26:29 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id LAA14064 for ietf-krb-wg-outgoing; Sat, 9 Dec 2000 11:14:48 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA14058 for ; Sat, 9 Dec 2000 11:14:43 -0600 (CST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA05475 for ; Sat, 9 Dec 2000 11:14:42 -0600 (CST) Message-Id: <200012091714.LAA05475@dns2.anl.gov> From: Mail Sender To: ietf-itrace@research.att.com CC: ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-ldapbis@openldap.org, ietf-ldapbis-request@openldap.org, ietf-ldapext@netscape.com Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 11 17:11:04 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18547 for ; Mon, 11 Dec 2000 17:11:02 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA08086 for ietf-krb-wg-outgoing; Mon, 11 Dec 2000 15:53:58 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA08080 for ; Mon, 11 Dec 2000 15:53:57 -0600 (CST) Received: from rsx-11.raeburn.org (IDENT:root@ietf.207.137.73.171.tx.verio.net [207.137.73.171]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA15310 for ; Mon, 11 Dec 2000 15:53:55 -0600 (CST) Received: (from raeburn@localhost) by rsx-11.raeburn.org (8.9.3/8.9.3) id QAA08049; Mon, 11 Dec 2000 16:53:54 -0500 X-Authentication-Warning: rsx-11.raeburn.org: raeburn set sender to raeburn@mit.edu using -f To: ietf-krb-wg@anl.gov Subject: Re: update to change/set password References: <4.1.20001206191414.00b87c50@nsm-mail2> From: Ken Raeburn Date: 11 Dec 2000 16:53:54 -0500 In-Reply-To: Jonathan Trostle's message of "Wed, 06 Dec 2000 19:21:56 -0800" Message-ID: Lines: 84 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Jonathan Trostle writes: > The service must accept requests on UDP port 464 and TCP port 464 as > well. The protocol consists of a single request message followed by > a single reply message. For UDP transport, each message must be fully > contained in a single UDP packet. As with kerberos-revisions, since we aren't defining a means for the client to find the service, I think requiring specific port numbers is a bit strong. The location mechanism, if we use DNS SRV, could provide port-number information, and we could recommend both that clients should be able to access other ports and that servers should use 464 -- both "should" and neither "must". Doing otherwise precludes running two realms' services on the same machine with different implementations or versions. > For change/set key, the request message may include the request flags bit > string with the request-srv-gen-keys bit set. In this case, the client > is requesting that the server add entropy to its keys in the KeySequences > field. When using this option, the client SHOULD attempt to generate > pseudorandom keys with as much entropy as possible in its request. The > server will return the final key sequence in a KeySequences structure in > the edata of the reply message. A conformant server MUST support this > option. I see two problems with this: 1) If the response is lost, the KDC thinks the client (presumably often an application server) has got the new key, and will issue tickets using that key. I'm pretty sure this came up when we discussed this on the list before. 2) If the response is delayed, or processing the response on the client is slow, tickets may be issued for communicating with the client (in its application-server role) that use the new key that it doesn't have yet. I don't think we want the client to block until it receives a response from the KDC or times out. If the client (application server) instead has to contact the KDC again to confirm that it's stored the new key (I'm assuming we might want to enforce the KDC-selected key), then the client knows all the important parts of the state -- the new key it's trying to register (even if generated by the KDC), the old key it needs to use until the new key is known to be working, etc. (The change-password service could If we don't do anything to deal with this, I'd suggest at least including language recommending against automated rekeying using this option, since in times of network problems it could have the effect of the client disabling itself. > KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required > KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; > the result string should include a text message to be presented > to the user. Starting with these, this "table" could be formatted much better for readability. > The server will respond with a KRB-PRIV message unless it cannot > validate the client AP-REQ or KRB-PRIV message, in which case it will > respond with a KRB-ERROR message. NOTE: Unlike change password version > 1, the KRB-ERROR message will be sent back without any encapsulation. So the leading bytes we get back are message-length(2), 00, 02, AP_REP tag, ... or KRB_ERROR tag, ... right? In which case, we may need to know something about the ASN.1 encoding of a KRB_ERROR to figure out just how we can tell which message we got back. I'm not sure how it works, but I *think* the 00 02 sequence probably can't show up at that position for KRB_ERROR; if that's the case, the implementation could simply look at those bytes to decide. But rather than making an implementor look up the ASN.1 encoding rules, you should probably recommend a specific check in this document. Or wrap KRB-ERROR with a similar header. Length+version+KRB_ERROR is easy enough to pick apart; after pulling off the first four bytes, you check the type of the ASN.1 message. From owner-ietf-krb-wg@achilles.ctd.anl.gov Mon Dec 11 18:23:01 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00378 for ; Mon, 11 Dec 2000 18:23:00 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id RAA08980 for ietf-krb-wg-outgoing; Mon, 11 Dec 2000 17:04:39 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA08974 for ; Mon, 11 Dec 2000 17:04:37 -0600 (CST) Received: from rsx-11.raeburn.org (IDENT:root@ietf.207.137.73.171.tx.verio.net [207.137.73.171]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA25380 for ; Mon, 11 Dec 2000 17:04:35 -0600 (CST) Received: (from raeburn@localhost) by rsx-11.raeburn.org (8.9.3/8.9.3) id SAA08109; Mon, 11 Dec 2000 18:03:22 -0500 Date: Mon, 11 Dec 2000 18:03:22 -0500 Message-Id: <200012112303.SAA08109@rsx-11.raeburn.org> X-Authentication-Warning: rsx-11.raeburn.org: raeburn set sender to raeburn@mit.edu using -f From: Ken Raeburn To: ietf-krb-wg@anl.gov Subject: possible fixes for some name canonicalizations issues Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk In talking about this with Sam and others last night I realized that some of the things I've been complaining about may be easier to fix than I thought, though they require adding more content to messages. 1) No means to do name canonicalization if you're not authenticating. Is it okay to require credentials in order to do canonicalization? If so, how about this: Send a TGS_REQ for the service name you have. If you get back a TGS_REP for a service, great; pull out the name and throw out the credentials. If you get back a TGS_REP for a TGT service, ask again in the specified realm. If you get back a KRB_ERROR because policy prohibits you from authenticating to that service, we can add to the specification that the {realm,sname} in the KRB_ERROR must be the canonical name, and the checksum must be used. As long as the checksum is present, it's still a secure exchange with the KDC. If we have to be able to do name canonicalization without any sort of credentials, either client-side (tickets) or server-side (tickets automatically acquired via service key), I think we just lose. But maybe GSSAPI should be changed if that's the case. 2) Can't refer to another realm and specify a different service name to give to that realm's KDC. The local KDC can tell you a different service name or a different realm name, but not both. This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type of case I've mentioned. Except ... the KDC-REP structure includes padata and ticket extensions fields that are extensible. We could add a required value to one of them -- perhaps only in the case where you return a TGT when not asked -- that contains signed information about the principal name to ask for in the other realm. (It would have to be required, otherwise a man-in-the-middle could make it go away.) Signing would be done using the session key for the TGS. 3) Secure canonicalization of service name in AS_REQ. If the response is an AS_REP, we need a way to tell that the altered server name wasn't a result of a MITM attack on the AS_REQ message. Again, the KDC-REP extensible fields could have a new required value added when name canonicalization happens, indicating what the original principal name (in the AS_REQ message) was, and signed using the same key as protects the AS_REP. If it doesn't match what the client requested, the messages were altered in transit. 4) Client name needs referral to another realm, and server name needs canonicalization of some sort. The above fixes wouldn't work for this case, and I'm not even sure which KDC should be doing the canonicalization anyways. The other-principal-name datum would probably look something like: PrincipalAndNonce ::= SEQUENCE { name[0] PrincipalName, nonce[1] INTEGER -- copied from KDC_REQ } SignedPrincipal ::= SEQUENCE { name-and-nonce[0] PrincipalAndNonce, cksum[1] Checksum } {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal with the checksum computed over the encoding of the 'name-and-nonce' field, and appropriate PA- or TE- numbers assigned. I don't have a strong opinion on whether it'd be a pa-data or ticket extension; conceptually it seems like an abuse of either, but, well, I think I'd rather abuse them than leave the facility both in and inadequate. The nonce is needed because multiple exchanges may be made with the same key, and these extension fields aren't packed in with the other encrypted data in the same response, so a MITM could pick apart multiple messages and mix-and-match components. (In a TGS_REQ exchange, a subsession key would help, but it's not required.) The extension field would be required to prevent a MITM from discarding the field from a response; a flag bit in a protected part of the message (probably in 'flags' in EncKDCRepPart) could also let us know of a cases where the information can be omitted, namely, when no name change is done. Perhaps the bit should be set to indicate that a name change *was* done, and clear if it wasn't, making the no-change case more directly compatible with RFC1510. Thoughts? Ken From owner-ietf-krb-wg@achilles.ctd.anl.gov Tue Dec 12 10:27:47 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08062 for ; Tue, 12 Dec 2000 10:27:47 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA14288 for ietf-krb-wg-outgoing; Tue, 12 Dec 2000 09:11:50 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA14282 for ; Tue, 12 Dec 2000 09:11:46 -0600 (CST) 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 JAA03405 for ; Tue, 12 Dec 2000 09:11:43 -0600 (CST) Message-ID: <3A364007.819B0E8E@anl.gov> Date: Tue, 12 Dec 2000 09:11:03 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: Draft 1.0 of Kerberos WG minutes - San Diego meeting, 12/11/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit [First Draft of the minutes. Comments and corrections for the minutes are requested, but hold comments or updates on the issues raised until later.] Coments on the The second meeting of the Kerberos WG was held on 12/11/00 with 147 attendees, twice as many at the first meeting. The Kerberos-Revisions is still the top priority of the working group, as most other drafts are waiting for it. Cliff Neuman ran the discussion of the revisions, doing it section by section. Section 1, no comments, but see name canonicalization below. Section 2, questions where raised about unrecognized KDC flags, and it was agreed that they could be ignored by the client, accept in the case when the anonymous bit was set. Section 3, name canonicalization is still of major concern. Sam Hartman suggested that maybe it be deferred to a separate document, as it originally was. Cliff was concerned that name canonicalization addresses concerns with using unsecured DNS instead and was important. Jeff Hutzelman suggested that it introduced new problems too. I suggested that maybe parts of it be left in, to accommodate only host name mapping. Sam Hartman, Jeff Hutzelman and Ken Raeburn are to comment to the list on this. Unfortunately no one for Microsoft was present to comment. (John Brezak was scheduled to attend, but has travel problems.) Section 4, no comments. Section 5, Tom Yu had major concerns about backward compatibility, especially with extra fields and checksums being added to many of the messages. He suggested new message types rather then modifying current messages, and a new KRB_SAFE type be added for use with GSSAPI. Matt Hur questioned if this was just a version number change. But Tom said the version is buried within messages and could not be checked until after the message had been parsed. Cliff said it could be done by adding new message types for the APPLICATION. There was general consensus of 17-2 that using the APPLICATION was acceptable. Jeff Hutzelman requested it be extensible so we don't have the same problem again. Tom needs to comment to the list again on which messages need to be added, as he had quite a few. A comment was made that even though the version number has not change from 5, this might be Kerberos 6 or 7 that is being defined. Section 6, was commented out in the current draft, as there where many questions. There are two 3des implementations, one with Key Derivation, and AES is coming, which can also use key derivation, which may be different. Each many also have its own string-to-key functions. Ken suggested that we not wait for AES. (see below) Sam said, even if we define both 3des but without AES, we will still need to make one mandatory. Ken and Cliff will be meeting later to hash out some of these issues and report back to the list. Section 8, Matt Crawford asked where one could go to get new numbers defined such as IANA. By consensus of 20-1, the requirement that port 88 be the KDC port will be changed to recommended, so that a site could run more then one KDC on separate ports. Pat Moore would like the NT_SRV_HOST name constraints be less restrictive, so as to work with DCE service names. He will get this to Cliff again, as Cliff was still uncomfortable with it. Jeff Altman asked again what happened to the Unicode vs UTF8, and questioned what Microsoft was doing with unicode and principal names. Cliff needs to added this back in to the revisions. We then moved on to PKINIT. Brian Tung said there was only one minor correction. This document has been will scrutinized over the years, and is only waiting for the Kerberos Revisions. Jeff Schiller suggested that we move this on too WG last call, even though it is still waiting. By general consensus, 15-1 we will be doing a WG last call shortly after the meeting. Matt Hur, the discussed PKCROSS, which is waiting for PKINIT. Sasha Medvinsky discussed PKTAPP which is actually informational, describing how to use PKINIT. Pat Moore and Tom Yu discussed issues with adding user-to-user to the Kerberos GSSAPI. Pat had used an old draft from Swift as a starting point and added this to the MIT distribution. Ted Ts'o pointed out that the gss_init_sec_context would need to know the target. Pat said the target is always known with the Globus application which needs this feature. Jonathan said the target_name should be an IN/OUT parameter. Tom Yu brought up the new message types need in the revisions, and it was agreed that these would be added. Finally, Matt Hur and Jeff Altman gave a brief overview of the presentation they will give at the TLC session, for TLS and KRB5. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@achilles.ctd.anl.gov Tue Dec 12 10:28:24 2000 Received: from achilles.ctd.anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08152 for ; Tue, 12 Dec 2000 10:28:24 -0500 (EST) Received: (from majordom@localhost) by achilles.ctd.anl.gov (8.9.1a/8.9.1) id JAA14302 for ietf-krb-wg-outgoing; Tue, 12 Dec 2000 09:12:23 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by achilles.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA14296 for ; Tue, 12 Dec 2000 09:12:21 -0600 (CST) 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 JAA03402; Tue, 12 Dec 2000 09:11:38 -0600 (CST) Message-ID: <3A363F45.9FBDF053@anl.gov> Date: Tue, 12 Dec 2000 09:07:49 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jeffrey I. Schiller" , Marcus Leech , ietf-krb-wg@anl.gov Subject: Summary of Kerberos WG meeting 12/11/00 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: Ietf-krb-wg-Owner@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit The second meeting of the Kerberos WG was held on 12/11/00 with 147 attendees, twice as many at the first meeting. The Kerberos-Revisions is still the top priority of the working group, as most other drafts are waiting for it. Cliff Neuman ran the discussion of the revisions, doing it section by section. Name canonicalization is still of major concern, and it was suggested that if this would help get the revisions moving, it be placed in a separate document, as it was originally. Backward compatibility issues were a major concern, and it was decided to address these with additional message types. The PKINIT draft is waiting for the revisions, but it was decided to move this to WG last call after the meeting. User-to-user for the Kerberos GSSAPI was discussed, work on this is now proceeding. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Dec 28 12:04:26 2000 Received: from atalanta.ctd.anl.gov ([146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17246 for ; Thu, 28 Dec 2000 12:04:25 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA03850 for ietf-krb-wg-outgoing; Thu, 28 Dec 2000 10:03:25 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA03845 for ; Thu, 28 Dec 2000 10:03:24 -0600 (CST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA04795 for ; Thu, 28 Dec 2000 10:03:24 -0600 (CST) Received: from anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA03841 for ; Thu, 28 Dec 2000 10:03:24 -0600 (CST) Message-ID: <3A4B6497.ABA923B@anl.gov> Date: Thu, 28 Dec 2000 10:04:39 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: Problems with mail list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit We have been experiening problems with the mail list since before Christmas, but hope to have them resolved next week. Sorry. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Dec 28 12:14:56 2000 Received: from atalanta.ctd.anl.gov ([146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17308 for ; Thu, 28 Dec 2000 12:14:55 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id KAA09975 for ietf-krb-wg-outgoing; Thu, 28 Dec 2000 10:43:29 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA09970 for ; Thu, 28 Dec 2000 10:43:29 -0600 (CST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA10501 for ; Thu, 28 Dec 2000 10:43:28 -0600 (CST) Received: from anl.gov (achilles.ctd.anl.gov [146.137.64.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA09966 for ; Thu, 28 Dec 2000 10:43:28 -0600 (CST) Message-ID: <3A4B6DFB.7CD8D8E0@anl.gov> Date: Thu, 28 Dec 2000 10:44:43 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-krb-wg@anl.gov Subject: Problems with mail list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk Content-Transfer-Encoding: 7bit We have been experiening problems with the mail list since before Christmas, but hope to have them resolved next week. Sorry. Another test, please ignore. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From owner-ietf-krb-wg@atalanta.ctd.anl.gov Thu Dec 28 17:00:55 2000 Received: from atalanta.ctd.anl.gov ([146.137.64.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19996 for ; Thu, 28 Dec 2000 17:00:50 -0500 (EST) Received: (from majordom@localhost) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) id PAA20759 for ietf-krb-wg-outgoing; Thu, 28 Dec 2000 15:21:16 -0600 (CST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA20754 for ; Thu, 28 Dec 2000 15:21:15 -0600 (CST) From: scholars@us.net Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dns2.anl.gov (8.9.1a/8.9.1) with SMTP id PAA21413 for ; Thu, 28 Dec 2000 15:21:14 -0600 (CST) Received: from host69.pmi2.laurel.us.net by MIT.EDU with SMTP id AA22503; Thu, 28 Dec 00 16:19:46 EST Subject: A Very Special Offer to win $3,300 Date: Thu, 28 Dec 2000 16:24:45 Message-Id: <77.31359.295774@yahoo.com> Reply-To: scholars@us.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-krb-wg@achilles.ctd.anl.gov Precedence: bulk ******************************************************************* A Very Special Offer to win $3,300 ******************************************************************* Dear Friend, Here is a very special offer to win $3300 worth of IT Training Which will be awarded to one lucky person every week for the Next 52 weeks! The Lucky Winner will get FREE access to 650+ online courses, which include MICROSOFT, CISCO, ORACLE, COMPTIA, E-COMMERCE, and WEB-MASTER Certifications etc. This offer is from the most valued Online IT Training Website and the courses being offered have been acclaimed as "The Best of the Web" by Forbes Magazine. And are, Sponsored by U.S. Department of Commerce for Federal Employees Winner will also get: 7 FREE Online IT Library 7 FREE Online Certification Skill Tests 7 24 X 7 Tech Support Take one minute to send an e-mail to scholars@us.net to register and you could be on the road to a Successful career in the HI-Tech Industry Drawings are held weekly, so hurry for your chance to win! ********************************************************************* If you'd not like to receive any special offers in the future, Please respond to this email with the word "unsubscribe" as The first word in the subject line. *********************************************************************