From donn@u.washington.edu Wed Jan 16 19:38:43 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA19936 for ; Wed, 16 Jan 2002 19:38:38 -0500 (EST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA09079 for ; Wed, 16 Jan 2002 19:38:38 -0500 (EST) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0H0cbMP002508 for ; Wed, 16 Jan 2002 16:38:37 -0800 Received: from xceed.cac.washington.edu (xceed.cac.washington.edu [128.95.135.150]) by mailhost1.u.washington.edu (8.12.1+UW01.12/8.12.1+UW01.12) with ESMTP id g0H0cbZU002695 for ; Wed, 16 Jan 2002 16:38:37 -0800 Date: Wed, 16 Jan 2002 16:38:37 -0800 Message-Id: <200201170038.g0H0cbZU002695@mailhost1.u.washington.edu> From: "Donn Cave" To: X-Mailer: BeOS-PyNR V1 Subject: Re: krb5 1.2.3 compile errors Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Quoth Tom Yu : ... | Try using xlc instead. The cc on AIX doesn't seem to deal with ANSI | prototypes. Of course, there is a separate problem in | lib/kadm5/unit-test, in that xlc doesn't like -DFOO=1 -UFOO -DFOO=2, | but that's a separate issue that we're looking into. Strictly speaking, "cc" does support ANSI prototypes, it just doesn't define __STDC__. Same for cc on Digital UNIX 4.0. You more or less need it anyway, as long as the buffer overflow patches require stdarg, so it might be just as well to assume prototype support, __STDC__ or no. (I'm referring to the end of defs.h, P() prototype macro, suggesting you remove the "#ifdef __STDC__".) xlc does define __STDC__. On Digital UNIX 4 you can use cc -std to define it, or -std0 or -std1 if you need more real compliance for some reason. Donn Cave, donn@u.washington.edu From raeburn@MIT.EDU Thu Jan 17 15:37:10 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA04658 for ; Thu, 17 Jan 2002 15:37:10 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28404; Thu, 17 Jan 2002 15:37:10 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA29315; Thu, 17 Jan 2002 15:37:07 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id PAA23971; Thu, 17 Jan 2002 15:37:07 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id PAA13020; Thu, 17 Jan 2002 15:37:08 -0500 To: Emily Ratliff Cc: Subject: Re: thread-safe Kerberos libraries References: From: Ken Raeburn Date: 17 Jan 2002 15:37:08 -0500 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: > I volunteer to write up the shim & callback functionality that you define > in this email, but it will probably take me a little while to get the > code to you. Did one of you want to write it or did you want me to? I > just want to make sure that you want me to do this, so that we are > not duplicating effort. This would be great! I don't think we've got time to do it at MIT right now, though once it's done we should be able to fill in the Windows version etc. This will bring up copyright and licensing issues though... will you/IBM give ownership (copyright) of the code to MIT, or keep it, and if the latter, what are the licensing terms? (Naturally we'd prefer it be assigned to MIT. We have to hash out just what licensing terms are acceptable for contributed or imported code; we've been rather vague on that point in the past.) > It looks good to me, but after reading through your email several times, > I'd like to go ahead and start implementing this before committing to an > opinion about this and your other questions. Great. Let us know how it looks as you get further along. > Well, I think that thread safety is more important until IPv6 becomes > more widespread but I guess it will be best to make it a compile time > option with the default of your choice. Can you remember which OS had the > gethostbyname problem? That way we can track when the problem get solved. Not offhand. In the end, actually, I decided not to bother with either thread safety or IPv6 support in the replacement getaddrinfo I was working on. Either (or maybe both) can be fixed later. I think I've heard more complaints about the lack of IPv6 support than the lack of thread safety, at least recently, but I know both are important to different people... From raeburn@MIT.EDU Thu Jan 17 17:51:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA06320 for ; Thu, 17 Jan 2002 17:51:59 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17180 for ; Thu, 17 Jan 2002 17:51:58 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA21761; Thu, 17 Jan 2002 17:51:58 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01559; Thu, 17 Jan 2002 17:51:58 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id RAA15814; Thu, 17 Jan 2002 17:51:58 -0500 To: krbdev@MIT.EDU Subject: changing krbdev mailing list maintenance (resend) From: Ken Raeburn Date: 17 Jan 2002 17:51:58 -0500 Message-ID: Lines: 38 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: (I'm resending this because some email at MIT was delayed or lost last night due to a mail system hiccup not directly related to these changes.) We're experimenting with moving the krbdev mailing list to a Mailman server at MIT, for easier automated maintenance. If this experiment seems to work well, we will probably also move the Kerberos list to this server. Please let Tom and I know of any problems you encounter with this server. You can make changes to your list subscription, including for example getting digests instead of separate messages, through this web page: http://mailman.mit.edu/mailman/listinfo/krbdev That page also has a pointer to the new (mailman-generated) archives. Older archives are still available in at least one or two places on the net, and will presumably continue to be available. You can also make changes to your subscription through email to krbdev-request@mit.edu, with subjects including "subscribe", "unsubscribe", "help", etc. These messages will now be automatically processed by the mailman server rather than waiting for one of us to get to it. It should also filter out unsubscribe requests sent to the list itself. Each user is assigned a password to use for changing options through the web interface. This password can be retrieved via the web interface. This may be a problem for any redistribution lists and public archives; contact me or Tom if it is. This change should prevent most bounces from being sent back to the original senders; in fact, most of the bounce handling should be automated. Currently, spam filtering is not enabled; we may change that later. Ken From nneul@umr.edu Thu Jan 17 21:55:22 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id VAA09318 for ; Thu, 17 Jan 2002 21:55:21 -0500 (EST) Received: from mx.rollanet.org (mailsrv.rollanet.org [192.55.114.7]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id VAA05414 for ; Thu, 17 Jan 2002 21:55:21 -0500 (EST) Received: (qmail 15513 invoked from network); 18 Jan 2002 02:55:20 -0000 Received: from cessna.rollanet.org (HELO umr.edu) (nneul@216.229.93.21) by mx.rollanet.org with SMTP; 18 Jan 2002 02:55:20 -0000 Message-ID: <3C478E96.10E1E3E8@umr.edu> Date: Thu, 17 Jan 2002 20:55:18 -0600 From: Nathan Neulinger X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.15-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ken Raeburn , krbdev@MIT.EDU Subject: Re: changing krbdev mailing list maintenance (resend) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Hey wait... it isn't April 1st... It's about time. :) -- Nathan Ken Raeburn wrote: > > (I'm resending this because some email at MIT was delayed or lost last > night due to a mail system hiccup not directly related to these > changes.) > > We're experimenting with moving the krbdev mailing list to a Mailman > server at MIT, for easier automated maintenance. If this experiment > seems to work well, we will probably also move the Kerberos list to > this server. Please let Tom and I know of any problems you encounter > with this server. > > You can make changes to your list subscription, including for example > getting digests instead of separate messages, through this web page: > > http://mailman.mit.edu/mailman/listinfo/krbdev > > That page also has a pointer to the new (mailman-generated) archives. > Older archives are still available in at least one or two places on > the net, and will presumably continue to be available. > > You can also make changes to your subscription through email to > krbdev-request@mit.edu, with subjects including "subscribe", > "unsubscribe", "help", etc. These messages will now be automatically > processed by the mailman server rather than waiting for one of us to > get to it. It should also filter out unsubscribe requests sent to the > list itself. > > Each user is assigned a password to use for changing options through > the web interface. This password can be retrieved via the web > interface. This may be a problem for any redistribution lists and > public archives; contact me or Tom if it is. > > This change should prevent most bounces from being sent back to the > original senders; in fact, most of the bounce handling should be > automated. > > Currently, spam filtering is not enabled; we may change that later. > > Ken > _______________________________________________ > krbdev mailing list > krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev -- ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From root@MIT.EDU Thu Jan 17 22:29:51 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA09751 for ; Thu, 17 Jan 2002 22:29:50 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA18362 for ; Thu, 17 Jan 2002 22:29:50 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA15983 for ; Thu, 17 Jan 2002 22:29:50 -0500 (EST) Received: (from root@localhost) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) id WAA08720; Thu, 17 Jan 2002 22:29:50 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id UAA10788; Wed, 16 Jan 2002 20:29:21 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id UAA21272; Wed, 16 Jan 2002 20:29:22 -0500 To: krbdev@MIT.EDU Subject: changing krbdev mailing list maintenance From: Ken Raeburn Date: 16 Jan 2002 20:29:22 -0500 Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: We're experimenting with moving the krbdev mailing list to a Mailman server at MIT, for easier automated maintenance. If this experiment seems to work well, we will probably also move the Kerberos list to this server. Please let Tom and I know of any problems you encounter with this server. You can make changes to your list subscription, including for example getting digests instead of separate messages, through this web page: http://mailman.mit.edu/mailman/listinfo/krbdev That page also has a pointer to the new (mailman-generated) archives. Older archives are still available in at least one or two places on the net, and will presumably continue to be available. You can also make changes to your subscription through email to krbdev-request@mit.edu, with subjects including "subscribe", "unsubscribe", "help", etc. These messages will now be automatically processed by the mailman server rather than waiting for one of us to get to it. It should also filter out unsubscribe requests sent to the list itself (and bounce them, rather than act on them, to teach people to Do The Right Thing). Each user is assigned a password to use for changing options through the web interface. This password can be retrieved via the web interface. This may be a problem for any redistribution lists and public archives; contact me or Tom if it is. This change should prevent most bounces from being sent back to the original senders; in fact, most of the bounce handling should be automated. Currently, spam filtering is not enabled; we may change that later. Ken From root@MIT.EDU Thu Jan 17 22:29:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA09756 for ; Thu, 17 Jan 2002 22:29:53 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA18381 for ; Thu, 17 Jan 2002 22:29:52 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA15992 for ; Thu, 17 Jan 2002 22:29:52 -0500 (EST) Received: (from root@localhost) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) id WAA08728; Thu, 17 Jan 2002 22:29:52 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id UAA11969; Wed, 16 Jan 2002 20:41:15 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id UAA21535; Wed, 16 Jan 2002 20:41:16 -0500 To: krbdev@MIT.EDU Subject: Re: krb5 1.2.3 compile errors References: From: Ken Raeburn Date: 16 Jan 2002 20:41:16 -0500 In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: > we should probably modify configure to look for xlc first, gcc second, > and then cc last. We aren't currently using a search list. If you set $CC or specify --with-cc=FOO, it uses it; otherwise, we use "cc". Maybe we should change it, but I'd recommend just going with the standard autoconf macros, and whatever they look for.... (I.e., unless there's a good reason why krb5 should be different from all other autoconf packages, fix any problems at the autoconf level.) From hartmans@MIT.EDU Fri Jan 18 10:55:47 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA18875 for ; Fri, 18 Jan 2002 10:55:47 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17503 for ; Fri, 18 Jan 2002 10:55:46 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23669; Fri, 18 Jan 2002 10:52:26 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24228; Fri, 18 Jan 2002 10:47:14 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id KAA29107; Fri, 18 Jan 2002 10:47:13 -0500 (EST) To: Ken Raeburn Cc: krbdev@MIT.EDU Subject: Re: changing krbdev mailing list maintenance (resend) References: From: Sam Hartman Date: 18 Jan 2002 10:47:13 -0500 In-Reply-To: Ken Raeburn's message of "17 Jan 2002 17:51:58 -0500" Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: >>>>> "Ken" == Ken Raeburn writes: Ken> That page also has a pointer to the new (mailman-generated) Ken> archives. Older archives are still available in at least one Ken> or two places on the net, and will presumably continue to be Ken> available. I assume the discuss meeting is still subscribed and still getting new messages? From raeburn@MIT.EDU Fri Jan 18 11:29:51 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA19343 for ; Fri, 18 Jan 2002 11:29:51 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA17756 for ; Fri, 18 Jan 2002 11:29:51 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25143; Fri, 18 Jan 2002 11:29:50 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27009; Fri, 18 Jan 2002 11:29:50 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id LAA06494; Fri, 18 Jan 2002 11:29:50 -0500 To: Sam Hartman Cc: krbdev@MIT.EDU Subject: Re: changing krbdev mailing list maintenance (resend) References: From: Ken Raeburn In-Reply-To: Message-ID: Lines: 4 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Date: Fri Jan 18 11:30:01 2002 X-Original-Date: 18 Jan 2002 11:29:50 -0500 > I assume the discuss meeting is still subscribed and still getting new messages? Yes. From mjv@MIT.EDU Fri Jan 18 11:33:17 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA19428 for ; Fri, 18 Jan 2002 11:33:17 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19183; Fri, 18 Jan 2002 11:33:17 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA02152; Fri, 18 Jan 2002 11:33:16 -0500 (EST) Received: from [18.18.1.144] (ETTLINGER-TOR.MIT.EDU [18.18.1.144]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27200; Fri, 18 Jan 2002 11:33:16 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@po12.mit.edu (Unverified) Message-Id: To: krbdev@MIT.EDU From: Marshall Vale Subject: Kerberos for Macintosh 4.0b7 Released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Date: Fri Jan 18 11:34:01 2002 X-Original-Date: Fri, 18 Jan 2002 11:33:12 -0500 The MIT MacDev team is pleased to announce the availability of Kerberos for Macintosh 4.0b7. This release is available from the MIT Kerberos site: Follow the "Getting Kerberos from MIT" link. All feedback and bug reports for Kerberos for Macintosh 4.0b7 should be sent to Overview -------- Kerberos for Macintosh 4.0 expands and improves native support for Mac OS X as well as including the new UI elements for Mac OS 9 introduced in KfM 3.5. With the inclusion of the last major new feature, Kerberos for Macintosh 4.0 has now reached beta stage. MIT Kerberos for Macintosh 4.0b7 is the twelfth public testing release. Please test early and get us your feedback as soon as possible. NOTE: This is a time-limited test release of Kerberos for Macintosh. It will expire after March 12, 2002. An updated release should be available before March 12, 2002, check at that time. Kerberos for Macintosh 4.0b7 requires a Power Macintosh with Mac OS X 10.1 or later for the Mac OS X version, or Mac OS 8.1 or later for the Mac OS 8 & 9 version. Changes since Kerberos For Macintosh 4.0b6 ------------------------------------------ * Mac OS X: Rearranged Kerberos.framework to remove server frameworks * Mac OS X: Kerberos Login dialog should launch quicker * Mac OS X: Principal Translation Plugin API now in Login Library * Mac OS X: Resource fork of preferences file preserved when it's modified by the profile library * Mac OS X: Fixed bugs where Preferences locating code might find backups instead of real Preferences file * Mac OS X: Buttons in login window now supported by authenticator * Mac OS X: Installer now works with UFS-formatted volumes * Mac OS X: Uninstall option available in Mac OS X installer * Mac OS X/9: Updated Kerberos 5 source to v1.2.3 * Mac OS X/9: Fixed Classic freezing when getting or renewing tickets in Classic ticket sharing * Mac OS X/9: Fixed CCache assertions in Classic ticket sharing * Mac OS X/9: Login Library insert realm functions reposition duplicate realm instead of leaving it in old position We have added extra debugging code that may cause asserts or errors to happen when using the Classic/Mac OS X ticket sharing feature. Please report any errors you may receive with a description of what you were doing when they happened to aid us in debugging. If you built an application that linked against the /usr/lib dylibs in KfM 4.0b2 or earlier, or the ones included with Mac OS X 10.1, you will need to re-link your application to work with the KfM 4.0b3 dylibs. Your application will no longer work with pre-4.0b3 releases, however. Ticket Sharing Between Mac OS X and Classic ------------------------------------------- In order for Kerberos tickets to be shared between Mac OS X and Classic, the same version of KfM 4.0 must be installed on both the OS X and Classic systems. When an application running under Classic needs to display the Kerberos Login dialog, the Mac OS X dialog will appear. The Mac OS 9 version of KfM 4.0 detects whether it is running under Mac OS X/Classic or regular Mac OS 9.x and automatically enables support for ticket sharing when possible. Distribution Info ----------------- At this point in time, this release is available as a single package which includes both installers and SDKs. The installers install binaries for people to use with their applications in their environments. The SDKs are for application and library programmers to add Kerberos functionality to their code or update to newer versions of the various Kerberos APIs. Source code for this release will not be made available. From ratliff@austin.ibm.com Tue Jan 22 12:30:29 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA00212 for ; Tue, 22 Jan 2002 12:30:29 -0500 (EST) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA18407; Tue, 22 Jan 2002 12:30:28 -0500 (EST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA04530; Tue, 22 Jan 2002 11:27:44 -0600 Received: from spiff.austin.ibm.com (spiff.austin.ibm.com [9.53.216.123]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA41516; Tue, 22 Jan 2002 11:30:26 -0600 From: Emily Ratliff To: Ken Raeburn cc: krbdev@mit.edu Subject: Re: thread-safe Kerberos libraries In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Date: Tue Jan 22 12:31:01 2002 X-Original-Date: Tue, 22 Jan 2002 11:31:05 -0600 (CST) On 17 Jan 2002, Ken Raeburn wrote: > This will bring up copyright and licensing issues though... will > you/IBM give ownership (copyright) of the code to MIT, or keep it, and > if the latter, what are the licensing terms? Sorry for the delay in the response, I had to check on this. Initial feedback indicates that IBM will assign the copyright to MIT. We would like it to be noted in some way that it was contributed by IBM. Emily -- Emily Ratliff IBM Linux Technology Center, Security From TSun@crt.xerox.com Wed Jan 23 10:24:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA16329 for ; Wed, 23 Jan 2002 10:24:26 -0500 (EST) Received: from ariel.eastgw.xerox.com (ariel.xerox.com [208.140.33.25]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04664 for ; Wed, 23 Jan 2002 10:24:26 -0500 (EST) Received: from crthub2.crt.xerox.com (crthub2.crt.xerox.com [13.138.80.5]) by ariel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA14523 for ; Wed, 23 Jan 2002 10:24:23 -0500 (EST) Received: by crthub2.crt.xerox.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 10:20:55 -0500 Message-ID: From: "Sun, Tong" To: "'krbdev@mit.edu'" Subject: KDC server on NT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Date: Wed Jan 23 10:25:00 2002 X-Original-Date: Wed, 23 Jan 2002 10:24:23 -0500 Hi, Do you have any KDC server software which runs on NT? Currently, we have your KDC server on Solaris and client on NT. We have a strong requirement to host KDC server on NT as well instead of any Unix box. Does "Kerberos 5 NT Alpha 2 Snapshot" include KDC server or it just has a client piece? Thanks for your attention. -Tong From Nicolas.Williams@ubsw.com Wed Jan 23 10:47:44 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA16650 for ; Wed, 23 Jan 2002 10:47:44 -0500 (EST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA13356 for ; Wed, 23 Jan 2002 10:47:43 -0500 (EST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id KAA04501; Wed, 23 Jan 2002 10:50:16 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma002528; Wed, 23 Jan 2002 10:47:26 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id KAA04016; Wed, 23 Jan 2002 10:43:52 -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 KAA16136; Wed, 23 Jan 2002 10:44:16 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id KAA15985; Wed, 23 Jan 2002 10:43:49 -0500 (EST) From: Nicolas Williams To: "Sun, Tong" Cc: "'krbdev@mit.edu'" Subject: Re: KDC server on NT Message-ID: <20020123104348.Y27171@sm2p1386swk.wdr.com> Mail-Followup-To: "Sun, Tong" , "'krbdev@mit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from TSun@crt.xerox.com on Wed, Jan 23, 2002 at 10:24:23AM -0500 Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing LIst List-Unsubscribe: , List-Archive: Date: Wed Jan 23 10:48:01 2002 X-Original-Date: Wed, 23 Jan 2002 10:43:49 -0500 MIT krb5 and Heimdal krb5 both compile fully or almost fully on Cygwin. I have not tested the KDC functionality on Cygwin, but since it compiles and links fine I'd expect that it will probably also run fine. Cheers, Nico On Wed, Jan 23, 2002 at 10:24:23AM -0500, Sun, Tong wrote: > Hi, > > Do you have any KDC server software which runs on NT? Currently, we have > your KDC server on Solaris and client on NT. We have a strong requirement to > host KDC server on NT as well instead of any Unix box. Does "Kerberos 5 NT > Alpha 2 Snapshot" include KDC server or it just has a client piece? > > Thanks for your attention. > > -Tong > > _______________________________________________ > krbdev mailing list > krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From raeburn@MIT.EDU Wed Jan 23 20:39:33 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id UAA23973 for ; Wed, 23 Jan 2002 20:39:33 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA20607; Wed, 23 Jan 2002 20:39:33 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA21366; Wed, 23 Jan 2002 20:39:28 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id UAA08480; Wed, 23 Jan 2002 20:39:24 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id UAA29605; Wed, 23 Jan 2002 20:39:24 -0500 To: "Sun, Tong" Cc: "'krbdev@mit.edu'" Subject: Re: KDC server on NT References: From: Ken Raeburn In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 23 20:40:01 2002 X-Original-Date: 23 Jan 2002 20:39:23 -0500 "Sun, Tong" writes: > Do you have any KDC server software which runs on NT? Currently, we have > your KDC server on Solaris and client on NT. We have a strong requirement to > host KDC server on NT as well instead of any Unix box. Does "Kerberos 5 NT > Alpha 2 Snapshot" include KDC server or it just has a client piece? If you can still find that version (as opposed to just its web page), please don't use it. It's *very* old, and client-side only I'm sure. The current KDC code will probably build on NT, under Cygwin if not natively. (Note though that we're not using Cygwin at MIT.) However, it's not one of the pieces we normally build on Windows, so you could encounter some problems. Are you interested in helping debug it for us? Ken From goHCI@cmu.edu Fri Jan 25 16:10:46 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA25863 for ; Fri, 25 Jan 2002 16:10:46 -0500 (EST) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA06322 for ; Fri, 25 Jan 2002 16:10:46 -0500 (EST) Received: from gohci.cc.cmu.edu (GOHCI.CC.CMU.EDU [128.2.123.158]) (user=rubenc mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g0PLAiPl002995 for ; Fri, 25 Jan 2002 16:10:45 -0500 From: Ruben Carbonell To: krbdev@mit.edu Subject: Kerb v4 for MacOS X Message-ID: <1609375.1011975044@gohci.cc.cmu.edu> Originator-Info: login-token=Mulberry:01qVmjRBvOBanpp/K79K8kwPS2J2MNeBl8NxbO0anfuQ==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Jan 25 16:11:00 2002 X-Original-Date: Fri, 25 Jan 2002 16:10:44 -0500 Hi, 2 suggestions: 1) Is it possible to add the "Change Password" directly in the Kerberos menu/icon? (both the classic and carbon versions) 2) I wonder if there can't be some icon on OS X when Kerberos for Mac is running? For example, Stuffit's Magic Menu has a little icon-menu in the upper right of OS X, next to the Display, Sound and clock icon-menus. I understand why you may not want to install something in the Dock by default. The reason behind this is because 2nd request is because often when users have kerberos / login problems, we trouble- shoot by teasing apart kerberos issues vs other network programs. So we see if they can get tickets first; novice users won't be so easy to walk through finding the Kerberos application and running it to get tickets. Thanks on such a great job with this app! :) Ruben Ruben Carbonell Mac Consultant Carnegie Mellon University From meeroh@MIT.EDU Fri Jan 25 16:18:29 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA25978 for ; Fri, 25 Jan 2002 16:18:29 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10741; Fri, 25 Jan 2002 16:18:29 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA12027; Fri, 25 Jan 2002 16:18:28 -0500 (EST) Received: from [18.18.6.67] (DONT-GRIEVE-ADMIRAL.MIT.EDU [18.18.1.86]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA21726; Fri, 25 Jan 2002 16:18:28 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <1609375.1011975044@gohci.cc.cmu.edu> References: <1609375.1011975044@gohci.cc.cmu.edu> To: Ruben Carbonell , krbdev@MIT.EDU From: Miro Jurisic Subject: Re: Kerb v4 for MacOS X Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Jan 25 16:19:00 2002 X-Original-Date: Fri, 25 Jan 2002 16:17:33 -0500 >1) Is it possible to add the "Change Password" directly in > the Kerberos menu/icon? (both the classic and carbon versions) Probably not. How often do you need to use that? >2) I wonder if there can't be some icon on OS X when Kerberos > for Mac is running? What do you mean by "Kerberos is running"? > The reason behind this is because 2nd request is because > often when users have kerberos / login problems, we trouble- > shoot by teasing apart kerberos issues vs other network > programs. So we see if they can get tickets first; novice > users won't be so easy to walk through finding the Kerberos > application and running it to get tickets. I am not sure how hard it is to tell them to go to the Finder, go to the Applications folder, double-click on Kerberos, click on "Get Tickets". Also, note that Apple has not published a mechanism for menu additions yet, so anything we did would be unlikely to continue working in the future. That's the main reason why we added the Dock feedback to the Kerberos application icon, but no menu addition. >Thanks on such a great job with this app! Thanks! :-) meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From goHCI@cmu.edu Fri Jan 25 16:58:56 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA26501 for ; Fri, 25 Jan 2002 16:58:56 -0500 (EST) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23971; Fri, 25 Jan 2002 16:58:55 -0500 (EST) Received: from gohci.cc.cmu.edu (GOHCI.CC.CMU.EDU [128.2.123.158]) (user=rubenc mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g0PLwSPl005365; Fri, 25 Jan 2002 16:58:55 -0500 From: Ruben Carbonell To: Miro Jurisic cc: krbdev@MIT.EDU Subject: Re: Kerb v4 for MacOS X Message-ID: <1781246.1011977909@gohci.cc.cmu.edu> In-Reply-To: References: <1609375.1011975044@gohci.cc.cmu.edu> Originator-Info: login-token=Mulberry:01ZxvAmNmQIv2naQ8PsnFBFLJ4RLfLOjbQ9dSQ7v2dew==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Jan 25 16:59:01 2002 X-Original-Date: Fri, 25 Jan 2002 16:58:29 -0500 Hi again, >> 1) Is it possible to add the "Change Password" directly in >> the Kerberos menu/icon? (both the classic and carbon versions) > > Probably not. How often do you need to use that? Currently, we're using this pretty often. CMU is upgrading lots of servers to Kerb5 from Kerb4. Users who hadn't updated their password (via changing their password) recently would not be able to access new kerb5 services (as their password entry contained just an old kerb4 entry). Anyhow, the technical reasons are a bit past me. :) I could ask one of our systems developers to explain if you're curious. We also have started running "password crackers" against our /etc/passwd to check for easy-to-guess/crack passwords. And we encourage users to change passwords if guessed. >> 2) I wonder if there can't be some icon on OS X when Kerberos >> for Mac is running? > > What do you mean by "Kerberos is running"? So let me re-phrase :) : We like people to easily know if they have current tickets or not. The KfM for classic always shows by default whether the user has current tickets (via the menu icon) If there's documentation somewhere on how I can configure the installer to place & "run" Kerberos by default on an install, that would rock! So hence, by "run", I mean is an active program on OS X (with that silly triangle under the icon in the Dock). I could be mistaken, but if you open the Kerberos application, you can choose "Keep in Dock", but when the Application is not open, active, and running, the icon will show a YELLOW key whether there are active tickets or not. 2 new requests from our other Mac expert (who also said you guys rock and did a great job with Kerberos for Mac) - we're just full of praise: 3) Kerberos for Mac generates a "Service Expired" message if the Time is out of bounds / off synch. Users get confused by this: Could the error message be changed to something with the word "time" in it; even Time Out of Bounds is fine. Sure, it would be great if Kerberos could tie into the System Prefs and either let the user update the time immediately or take them to the Date & Time prefs. But that's asking a lot. 4) If someone deletes their Kerberos Preferences, they lose their ANDREW.CMU.EDU or CS.CMU.EDU realm and Kerberos reverts to an MIT.EDU server. Is this possible to customize, so CMU's distribution has the default set to ANDREW.CMU.EDU ? :) Once again thank you! Have a great weekend, Ruben Ruben Carbonell Mac Consultant Carnegie Mellon University From meeroh@MIT.EDU Fri Jan 25 17:26:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA26879 for ; Fri, 25 Jan 2002 17:26:18 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01945; Fri, 25 Jan 2002 17:26:17 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02342; Fri, 25 Jan 2002 17:26:17 -0500 (EST) Received: from [18.18.6.67] (DONT-GRIEVE-ADMIRAL.MIT.EDU [18.18.1.86]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA13948; Fri, 25 Jan 2002 17:26:16 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <1781246.1011977909@gohci.cc.cmu.edu> References: <1609375.1011975044@gohci.cc.cmu.edu> <1781246.1011977909@gohci.cc.cmu.edu> To: Ruben Carbonell From: Miro Jurisic Subject: Re: Kerb v4 for MacOS X Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Jan 25 17:27:00 2002 X-Original-Date: Fri, 25 Jan 2002 17:24:20 -0500 >Currently, we're using this pretty often. CMU is upgrading lots >of servers to Kerb5 from Kerb4. Users who hadn't updated their >password (via changing their password) recently would not be able >to access new kerb5 services (as their password entry contained >just an old kerb4 entry). Anyhow, the technical reasons are a >bit past me. :) I could ask one of our systems developers to >explain if you're curious. > >We also have started running "password crackers" against our >/etc/passwd to check for easy-to-guess/crack passwords. And >we encourage users to change passwords if guessed. My personal opinion is that change password is an operation not done frequently enough to warrant putting in the Kerberos menu. I understand the v4 -> v5 transition issue, but that's only going to happen once for any given user. Maybe it's possible that you could convince me that this would be valuable at CMU, but I would still not be convinced that this is something that's useful in general. The whole purpose of the Menu and the Control Strip is to provide commonly used functionality. For example, you can compare this with the Energy Saver control panel and Control Strip module, where the CSM gives you the basic functionality used often, and an option to open the Control Panel if you need more control (note that Kerberos Menu and Kerberos Control Strip module both allow you to open the Kerberos Control Panel on 9). I think that the answer here is that you have a 2-step procedure (on Mac OS 9) for changing password: select "Open Kerberos Control Panel" from Kerberos Menu and then click on "Change Password". I am having a hard time believing that this is either hard to explain to users or hard for users to do when they need to change their password. On Mac OS X, if you are running the Kerberos application, you can close its main window, and then all you will have is the Dock icon which shows you the current status. If you click on that icon, the main window opens, and you can then click on the "Change Password" button. So, if you are running the Kerberos application, it's again a 2-step process -- click on the dock icon, click on "Change Password". We are not opposed to a Kerberos Menu on Mac OS X, however Apple has not provided the documentation for us to do that, and we have focused on a number of more important issues. Don't forget that the Kerberos Menu was completely absent in KfM 3.0 on Mac OS 9, and only came back in 3.5 -- I would not be surprised if something similar happens on Mac OS X. We certainly will not hold up 4.0 final release for Kerberos Menu on Mac OS X :-) >So let me re-phrase :) : We like people to easily know if they >have current tickets or not. The KfM for classic always shows >by default whether the user has current tickets (via the menu >icon) If you run the Kerberos Application on Mac OS X, you get that display in the dock. Which brings us to your next question... >If there's documentation somewhere on how I can configure the >installer to place & "run" Kerberos by default on an install, >that would rock! There is no way to configure the installer to do this right now. Without further investigation I can't tell you whether we can or want to do this right now, so I can't tell you much here :-) > So hence, by "run", I mean is an active program >on OS X (with that silly triangle under the icon in the Dock). >I could be mistaken, but if you open the Kerberos application, >you can choose "Keep in Dock", but when the Application is not >open, active, and running, the icon will show a YELLOW key whether >there are active tickets or not. This is a good point. We'll have to think about this. I agree it can be confusing. >2 new requests from our other Mac expert (who also said you guys >rock and did a great job with Kerberos for Mac) - we're just >full of praise: We really appreciate that :-) >3) Kerberos for Mac generates a "Service Expired" message if the >Time is out of bounds / off synch. Users get confused by this: Could >the error message be changed to something with the word "time" in >it; even Time Out of Bounds is fine. That's interesting. Are you using any form of preauthentication? I could have sworn we verified this and it worked fine in our setup. >Sure, it would be great if Kerberos could tie into the System Prefs >and either let the user update the time immediately or take them to >the Date & Time prefs. But that's asking a lot. It's really none of our business whether your users have time set right or not. We can't give them useful instructions for what to _do_ once in the D&T prefs, because that really depends on what CMU wants them to do. Do you want them to use a specific time server? Setup time by hand? Something else? The best answer is probably for CMU to choose a policy for what the users should do, document the policy, and provide a simple app the users can run to setup their machines according to that policy. I agree that the error message is suboptimal, and we can look into that, but I definitely know that there is one preauthentication mechanism which makes it impossible to detect time out of bounds errors with 100% reliability. >4) If someone deletes their Kerberos Preferences, they lose their >ANDREW.CMU.EDU or CS.CMU.EDU realm and Kerberos reverts to an MIT.EDU >server. Is this possible to customize, so CMU's distribution has >the default set to ANDREW.CMU.EDU ? :) Yes, you can edit /System/Library/Frameworks/Kerberos.framework/Frameworks/KerberosPreferences.framework/Resources/DefaultRealmsConfiguration after the installer installs it. meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From jwe@unc.edu Sun Jan 27 17:17:39 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA01797 for ; Sun, 27 Jan 2002 17:17:38 -0500 (EST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA26924 for ; Sun, 27 Jan 2002 17:17:37 -0500 (EST) Received: from [10.0.1.201] ([24.88.249.223]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Sun, 27 Jan 2002 17:17:30 -0500 User-Agent: Microsoft-Entourage/10.0.0.1429 Subject: Kerberos for Mac issues- From: "John W. Eschelbach" To: Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3094996655_7667585" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Sun Jan 27 17:18:01 2002 X-Original-Date: Sun, 27 Jan 2002 17:17:34 -0500 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3094996655_7667585 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello, I have been playing with KfM for quite a while now and have not been able t= o load my realms as described in the online documentation. I am using a PowerBook G3 Firewire 400 running Mac OS X 10.1.2. The first issue I noticed was that when running the installer, the edu.mit.Kerberos file defaults to being a Microsoft Entourage Preference file. I also have Office X installed and running. I edited the file in BBEdit to only have my realms configuration information. I saved the file without changing the file type or creator. I have also saved it as a BBEdi= t file and a generic text file, but am still unable to Edit my Favorite realm= . When running the Kerberos application, I have tried to Edit My Favorite realm in the preference, but the only realm that is listed is the ATHENA.MIT.EDU realm. When selecting the =B3Edit My Favorites=B2, nothing happens. I have checked the preference file multiple times and am confused where the application is even getting the ATHENA realm from. I assume all of my problems stem from not being able to load my realm correctly. Any suggestions would be greatly appreciated. Thank you, John W. Eschelbach Department of Chemistry University of North Carolina Chapel Hill, NC 27599-3290 E-mail: jwe@unc.edu Sent using the Entourage X Test Drive. --B_3094996655_7667585 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Kerberos for Mac issues- Hello,

I have been playing with KfM for quite a while now and have not been able t= o load my realms as described in the online documentation.

I am using  a PowerBook G3 Firewire 400 running Mac OS X 10.1.2.

The first issue I noticed was that when running the installer, the edu.mit.= Kerberos file defaults to being a Microsoft Entourage Preference file.  = ;I also have Office X installed and running.  I edited the file in BBEd= it to only have my realms configuration information.  I saved the file = without changing the file type or creator.  I have also saved it as a B= BEdit file and a generic text file, but am still unable to Edit my Favorite = realm.

When running the Kerberos application, I have tried to Edit My Favorite rea= lm in the preference, but the only realm that is listed is the ATHENA.MIT.ED= U realm.  When selecting the “Edit My Favorites”, nothing h= appens.  I have checked the preference file multiple times and am confu= sed where the application is even getting the ATHENA realm from.

I assume all of my problems stem from not being able to load my realm corre= ctly.

Any suggestions would be greatly appreciated.

Thank you,


John W. Eschelbach
Department of Chemistry
University of North Carolina
Chapel Hill, NC  27599-3290
E-mail:  jwe@unc.edu


Sent using the Entourage X Test Drive.

--B_3094996655_7667585-- From smcguire@MIT.EDU Mon Jan 28 10:57:43 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA14759 for ; Mon, 28 Jan 2002 10:57:42 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA00504; Mon, 28 Jan 2002 10:57:42 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA19363; Mon, 28 Jan 2002 10:57:41 -0500 (EST) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12053; Mon, 28 Jan 2002 10:57:41 -0500 (EST) Mime-Version: 1.0 X-Sender: eudtest@hesiod Message-Id: In-Reply-To: References: To: "John W. Eschelbach" , From: Scott McGuire Subject: Re: Kerberos for Mac issues Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Jan 28 10:58:01 2002 X-Original-Date: Mon, 28 Jan 2002 10:57:34 -0500 At 5:17 PM -0500 1/27/02, John W. Eschelbach wrote: >I have been playing with KfM for quite a while now and have not been >able to load my realms as described in the online documentation. > >The first issue I noticed was that when running the installer, the >edu.mit.Kerberos file defaults to being a Microsoft Entourage >Preference file. I also have Office X installed and running. I >edited the file in BBEdit to only have my realms configuration >information. I saved the file without changing the file type or >creator. I have also saved it as a BBEdit file and a generic text >file, but am still unable to Edit my Favorite realm. > >When running the Kerberos application, I have tried to Edit My >Favorite realm in the preference, but the only realm that is listed >is the ATHENA.MIT.EDU realm. When selecting the "Edit My >Favorites", nothing happens. I have checked the preference file >multiple times and am confused where the application is even getting >the ATHENA realm from. > >I assume all of my problems stem from not being able to load my >realm correctly. ATHENA.MIT.EDU is the default contents of the favorite realms list right after you install; we have to have an entry there, and we cannot know what your realm is until you edit the edu.mit.Kerberos file, so we default to ATHENA. Once KfM is locating your preferences file, Edit Favorite Realms should show them (and your site's default realm should be added to the favorite realms automatically) and allow you to remove ATHENA. The fact that Mac OS X shows your prefs file as an Entourage preferences file is probably not be relevant; unfortunately Mac OS X is easily confused about who preferences files belong to. My system shows my edu.mit.Kerberos as a BBEdit prefs file, even though the file type/creator are correct for the Kerberos prefs file. It does sound like KfM is having trouble finding the preferences file you edited. There are a number of possible reasons for this. Please do the following: (1) Make sure you are using the latest release of KfM. We released KfM 4.0b7 about 10 days ago, and it fixes some preferences locating bugs. (2) Make sure you are editing the edu.mit.Kerberos file in /Library/Preferences, not the one in /Users/userid/Library/Preferences . In fact, throw out any that you find in /Users/userid/Library/Preferences . (3) Make sure there are no "backup" copies of the edu.mit.Kerberos preferences file (such as files named ~edu.mit.Kerberos or edu.mit.Kerberos.bak) in the /Library/Preferences or /Users/userid/Library/Preferences directories. If there are, trash them. Let us know if this helps. -- Scott McGuire / smcguire@mit.edu MIT Information Systems Macintosh Developer From bbense@shred.stanford.edu Mon Jan 28 16:37:05 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA18943 for ; Mon, 28 Jan 2002 16:37:05 -0500 (EST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA15381 for ; Mon, 28 Jan 2002 16:37:04 -0500 (EST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g0SLb3O02343 for ; Mon, 28 Jan 2002 13:37:03 -0800 (PST) From: "Booker C. Bense" To: krbdev@mit.edu Subject: Status of compile_et In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Jan 28 16:38:00 2002 X-Original-Date: Mon, 28 Jan 2002 13:37:03 -0800 (PST) - What is the reason compile_et is built but not installed in the krb5 src tree? If I have a program that needs it, is there a reason not to use it. - Booker C. Bense From raeburn@MIT.EDU Mon Jan 28 16:46:58 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA19078 for ; Mon, 28 Jan 2002 16:46:58 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19017; Mon, 28 Jan 2002 16:46:58 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA29310; Mon, 28 Jan 2002 16:44:09 -0500 (EST) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA26274; Mon, 28 Jan 2002 16:44:08 -0500 (EST) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3) id QAA32111; Mon, 28 Jan 2002 16:44:09 -0500 To: "Booker C. Bense" Cc: krbdev@MIT.EDU Subject: Re: Status of compile_et References: From: Ken Raeburn In-Reply-To: Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.107 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Jan 28 16:47:01 2002 X-Original-Date: 28 Jan 2002 16:44:09 -0500 "Booker C. Bense" writes: > - What is the reason compile_et is built but not installed in > the krb5 src tree? If I have a program that needs it, is there > a reason not to use it. Already fixed for 1.3, just not in the 1.2.x branch. Also in the plans for 1.3 but not done yet, using an installed system version of com_err and ss if desired (e.g., on Linux) instead of the in-tree versions. Ken From lessing.3@osu.edu Tue Jan 29 13:00:26 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA03902 for ; Tue, 29 Jan 2002 13:00:26 -0500 (EST) Received: from mail1.uts.ohio-state.edu (mail1.uts.ohio-state.edu [128.146.214.30]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA06849; Tue, 29 Jan 2002 13:00:25 -0500 (EST) Received: from dhcp-242-214.uts.ohio-state.edu (dhcp-242-214.uts.ohio-state.edu [128.146.242.214]) by mail1.uts.ohio-state.edu (8.9.3/8.9.3) with ESMTP id NAA01982; Tue, 29 Jan 2002 13:00:24 -0500 (EST) Subject: Kerberos for OS 10.1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: macdev@mit.edu To: krbdev@mit.edu From: Kori Lessing Content-Transfer-Encoding: 7bit Message-Id: <12A0BA74-14E2-11D6-8303-00039319427E@osu.edu> X-Mailer: Apple Mail (2.480) Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Jan 29 13:01:00 2002 X-Original-Date: Tue, 29 Jan 2002 13:00:26 -0500 Hi MIT, I use Eudora 5.1 for OSx for email. Today It fails to launch with the message "This pre-release version of MIT kerberos for Macintosh has expired. Eudora launch fails because of a shared library error :4 <> <>" I am on 10.1.2 Is there a later version that I should have? The Kerberos Application says it is version 4.0a19 Thanks, Ms. Kori Lessing Systems Development Engineer Application Development Systems Office of Information Technology 1121 Kinnear Rd 614-247-6121 lessing.3@osu.edu From smcguire@MIT.EDU Tue Jan 29 13:04:00 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA03963 for ; Tue, 29 Jan 2002 13:04:00 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA24462; Tue, 29 Jan 2002 13:03:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA13672; Tue, 29 Jan 2002 13:03:53 -0500 (EST) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA10589; Tue, 29 Jan 2002 13:03:53 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <12A0BA74-14E2-11D6-8303-00039319427E@osu.edu> References: <12A0BA74-14E2-11D6-8303-00039319427E@osu.edu> To: Kori Lessing , krbdev@MIT.EDU From: Scott McGuire Subject: Re: Kerberos for OS 10.1 Cc: macdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Jan 29 13:05:01 2002 X-Original-Date: Tue, 29 Jan 2002 13:03:50 -0500 At 1:00 PM -0500 1/29/02, Kori Lessing wrote: > I use Eudora 5.1 for OSx for email. Today It fails to launch >with the message "This pre-release version of MIT kerberos for >Macintosh has expired. >Eudora launch fails because of a shared library error >:4 <> <>" > I am on 10.1.2 Is there a later version that I should have? The >Kerberos Application says it is version 4.0a19 You can download the latest version of Kerberos for Macintosh from: Follow the instructions on that page, and look for Kerberos for Macintosh 4.0b7. -- Scott McGuire / smcguire@mit.edu MIT Information Systems Macintosh Developer From lessing.3@osu.edu Tue Jan 29 13:16:55 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA04143 for ; Tue, 29 Jan 2002 13:16:55 -0500 (EST) Received: from mail3.uts.ohio-state.edu (mail3.uts.ohio-state.edu [128.146.214.32]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA11490; Tue, 29 Jan 2002 13:11:49 -0500 (EST) Received: from dhcp-242-214.uts.ohio-state.edu (dhcp-242-214.uts.ohio-state.edu [128.146.242.214]) by mail3.uts.ohio-state.edu (8.9.3/8.9.3) with ESMTP id NAA11168; Tue, 29 Jan 2002 13:11:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: Kerberos for OS 10.1 From: Kori Lessing To: krbdev@mit.edu, macdev@mit.edu Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.480) Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Jan 29 13:17:00 2002 X-Original-Date: Tue, 29 Jan 2002 13:11:48 -0500 Sorry, I found the newer version on your site and installed it okay. Thanks, Kori Begin forwarded message: > From: Kori Lessing > Date: Tue Jan 29, 2002 01:00:26 PM US/Eastern > To: krbdev@mit.edu > Cc: macdev@mit.edu > Subject: Kerberos for OS 10.1 > > Hi MIT, > I use Eudora 5.1 for OSx for email. Today It fails to launch with > the message "This pre-release version of MIT kerberos for Macintosh has > expired. > Eudora launch fails because of a shared library error > :4 <> <>" > I am on 10.1.2 Is there a later version that I should have? The > Kerberos Application says it is version 4.0a19 > Thanks, > From bounce-otcjournal-new-3719211@lyris.otcjournal.com Tue Jan 29 15:43:25 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA05987 for ; Tue, 29 Jan 2002 15:43:25 -0500 (EST) Received: from lyris.otcjournal.com (lyris.otcjournal.com [216.105.36.68]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id PAA02003 for ; Tue, 29 Jan 2002 15:43:24 -0500 (EST) From: "OTCJournal ListServer" Message-Id: X-Authentication-Warning: listserv.otcjournal.com: mail set sender to info@otcjournal.com using -f To: krbdev@mit.edu X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Internet Investing Resource Content-Type: multipart/alternative; boundary="------------4C9006809691A039D8AD8595" List-Owner: X-List-Host: OTCJournal Newsletter Reply-To: "OTCJournal Newsletter" X-Message-Id: <200201291847.KAA31755@listserv.otcjournal.com> Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Jan 29 15:44:00 2002 X-Original-Date: Tue, 29 Jan 2002 10:47:23 -0800 --------------4C9006809691A039D8AD8595 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you are reading this message in plaintext or if you have an AOL address you must click on this link: http://listserv.otcjournal.com/new/ and wait for a web page to automatically open up to properly read this newsletter. You can unsubscribe from this list at any time by Clicking Here and HITTING SEND. If you are having difficulty removing yourself or wish to change your address please go to http://listserv.otcjournal.com/opt.cgi?email=krbdev@mit.edu&list=otcjournal-new. [Image] [Image][Image] [Image] [Image]January 29 , 2002[Image] [Image]Volume V, Issue 1[Image] Email : info@otcjournal.com URL : http://www.otcjournal.com To NEW OTC Journal Members: Your name recently came to us as a subscriber to on-line investment news letters. As such, we are extending you a free subscription to the OTC Journal. If you do not wish to receive our FREE NEWSLETTER, simply follow the directions at the top of this page and your e-mail address will be immediately removed. Please remove yourself if you do not wish to receive our newsletter as it is not our intention to invade your privacy. You can always choose to have your name removed from our Member List simply by going to our home page at http://www.otcjournal.com, and clicking on Change or Remove Your E-Mail on the left hand menu bar. You should also read our privacy policy which states that your E-Mail address will be kept strictly confidential. The OTC Journal site is an investment portal with extremely unique investment tools and resources. There is no charge for membership to the site. Please visit our home page at WWW.OTC Journal.com. The primary focus of the OTC Journal is to provide our members with information about publicly traded small and micro cap companies that you won't read about in the main stream Wall Street media. We identify these companies in their early stage of development and provide you with as much information as possible through our monthly e-mail company profiles. Updates and news releases are provided via e-mail regularly for our members. If you have little or no experience in investing in early stage company please take the time to read our section entitled Are Microcaps For You?, which can be found at our home page. Our best performing profile of 1999 was NetSol International (NASDAQ: NTWK). We originally profiled the company at $3.88 on January 15, 1999. The stock hit a closing high of $75 in March of 2000 for an 1800% return. For our complete track record visit our Profile Tracking button on our home page. Every edition we ever publish is found in the Archive Section. The following is a list of the features that you will find at the OTC Journal Home Page. * Trading Alerts- Short Term trading ideas with Entry Level, Target Price, and Stop Loss. Excellent tool for short term trading ideas. * E-Mail Profiles on Companies that we feel could provide you with substantial returns over a one to two year period of time. Click Here to read our current profile. * IPO Alert- This section is live and has a list of upcoming IPOs that our members have the opportunity to participate in. The section will have a list of upcoming IPOs and direct contact to a stock broker that has shares allocated for our members. * Profile Performance Tracking- Gives you up to the day price performance of our profiled companies dating back to the beginning of 1999 based on closing prices. * Dr Richard Geist's Column On the Psychology of Investing- Dr. Geist is a Doctorate in Psychology from Harvard University and is an instructor in the department of Psychiatry at Harvard Medical School. Dr. Geist's recommendations have been featured in Business Week, Fortune Magazine, Bull and Bear, and The Wall Street Journal. His market commentary and thoughts on the psychology of investing have also been quoted in Barron's, Harvard Magazine, Financial Planning Magazine, Forbes, New York Times, and USA Today; and he has appeared on CNN, CNBC, PBS, and Bloomberg Television. Dr. Geist has also been a special guest on Louis Rukeyser's Wall Street Week. Click Here to go to the archive of columns. * Testimonial Section- Read comments from our long term members. However, the major theme of our newsletter will continue to be ideas in small and microcap stocks which we believe have the potential to provide outstanding returns for investors with a one to two year investment horizon. ------------------------------------------------------------------------ This category of stocks is very risky, and you should never invest more money than you can afford to lose. In addition, you should make an effort to verify through third party sources any claims that we make about the companies that we represent. ------------------------------------------------------------------------ The OTC Journal is a proud partner of the SwingWire.com Online Investment Community. A next generation Online Analyst Exchange providing Members the ability to search, review, track and monitor some of the Internet's best Online CAs (CyberAnalysts). Members have the opportunity to potentially achieve higher returns by viewing top performing portfolios and receiving real-time alerts from favorite CAs. SwingWire.com also has a lucrative incentive model for experienced investors and traders who consistently outperform the market. Share market ideas with other like-minded investors, establish a proven track record, provide insightful commentary, attract followers and ultimately become one of the Internet's highest paid and most sought after CyberAnalysts! Click here to receive your FREE 30-Day Trial Membership with no further obligation. Sign Up Today! Disclaimer The OTCjournal.com Newsletter is an independent electronic publication committed to providing our readers with factual information on selected publicly traded companies. All companies are chosen on the basis of certain financial analysis and other pertinent criteria with a view toward maximizing the upside potential for investors while minimizing the downside risk, whenever possible. Moreover, as detailed below, this publication accepts compensation from certain of the companies which it features. Likewise, this newsletter is owned by MarketByte, LLC. To the degrees enumerated herein, this newsletter should not be regarded as an independent publication. Click Here to view our compensation on every company we have ever covered, or visit the following web address: http://www.otcjournal.com/disclaimer.html for our full profiles and http://www.otcjournal.com/trading-alerts/disclaimer.html for Trading Alerts. All statements and expressions are the sole opinions of the editors and are subject to change without notice. A profile, description, or other mention of a company in the newsletter is neither an offer nor solicitation to buy or sell any securities mentioned. While we believe all sources of information to be factual and reliable, in no way do we represent or guarantee the accuracy thereof, nor the statements made herein. The editor, members of the editor's family, and/or entities with which they are affiliated, are forbidden by company policy to own, buy, sell or otherwise trade stock for their own benefit in the companies who appear in the publication. unless specifically disclosed in the newsletter. The profiles, critiques, and other editorial content of the OTCjournal.com may contain forward-looking statements relating to the expected capabilities of the companies mentioned herein. THE READER SHOULD VERIFY ALL CLAIMS AND DO THEIR OWN DUE DILIGENCE BEFORE INVESTING IN ANY SECURITIES MENTIONED. INVESTING IN SECURITIES IS SPECULATIVE AND CARRIES A HIGH DEGREE OF RISK. THE INFORMATION FOUND IN THIS PROFILE IS PROTECTED BY THE COPYRIGHT LAWS OF THE UNITED STATES AND MAY NOT BE COPIED, OR REPRODUCED IN ANY WAY WITHOUT THE EXPRESSED, WRITTEN CONSENT OF THE EDITORS OF OTCjournal.com. We encourage our readers to invest carefully and read the investor information available at the web sites of the Securities and Exchange Commission ("SEC") at http://www.sec.govand/or the National Association of Securities Dealers ("NASD") at http://www.nasd.com. We also strongly recommend that you read the SEC advisory to investors concerning Internet Stock Fraud, which can be found at http://www.sec.gov/consumer/cyberfr.htm. Readers can review all public filings by companies at the SEC's EDGAR page. The NASD has published information on how to invest carefully at its web site. You can unsubscribe from this list at any time by Clicking Here and HITTING SEND. If you are having difficulty removing yourself or wish to change your address please go to http://listserv.otcjournal.com/opt.cgi?email=krbdev@mit.edu&list=otcjournal-new. [Image] [Image] [Image] [Image] [Image] [Image] [Image] [Image] [Image] [Image] --- You are currently subscribed to otcjournal-new as: krbdev@mit.edu To unsubscribe send a blank email to leave-otcjournal-new-3719211X@lyris.otcjournal.com --------------4C9006809691A039D8AD8595 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit If you are reading this message in plaintext or if you have an AOL address you must click on this link: http://listserv.otcjournal.com/new/ and wait for a web page to automatically open up to properly read this newsletter.

You can unsubscribe from this list at any time by Clicking Here and HITTING SEND. If you are having difficulty removing yourself or wish to change your address please go to http://listserv.otcjournal.com/opt.cgi?email=krbdev@mit.edu&list=otcjournal-new.
January 29 , 2002
Volume V, Issue 1
Email : info@otcjournal.com
URL : http://www.otcjournal.com

To NEW OTC Journal Members:

Your  name recently came to us as a subscriber to on-line investment news letters. As such, we are extending you a free subscription to the OTC Journal. If you do not wish to receive our FREE NEWSLETTER, simply follow the directions at the top of this page and your e-mail address will be immediately removed. Please remove yourself if  you do not wish to receive our newsletter as it is not our intention to invade your privacy.

You can always choose to have your name removed from our Member List simply by going to our home page at http://www.otcjournal.com, and clicking on Change or Remove Your E-Mail on the left hand menu bar.  You should also read our privacy policy which states that your E-Mail address will be kept strictly confidential.

The OTC Journal site is an investment portal with extremely unique investment tools and resources.  There is no charge for membership to the site.  Please visit our home page at WWW.OTC Journal.com.

The primary focus of the OTC Journal is to provide our members with information about publicly traded small and micro cap companies that you won't read about in the main stream Wall Street media.  We identify these companies in their early stage of development and provide you with as much information as possible through our monthly e-mail company profiles.  Updates and news releases are provided via e-mail regularly for our members.  If you have little or no experience in investing in early stage company please take the time to read our section entitled Are Microcaps For You?, which can be found at our home page.

Our best performing profile of 1999 was NetSol International (NASDAQ: NTWK).  We originally profiled the company at $3.88 on January 15, 1999.  The stock hit a closing high of $75 in March of 2000 for an 1800% return.  For our complete track record visit our Profile Tracking button on our home page.  Every edition we ever publish is found in the Archive Section.

The following is a list of the features that you will find at the OTC Journal Home Page.

  • Trading Alerts- Short Term trading ideas with Entry Level, Target Price, and Stop Loss. Excellent tool for short term trading ideas.
  • E-Mail Profiles on Companies that we feel could provide you with substantial returns over a one to two year period of time.  Click Here to read our current profile.
  • IPO Alert-  This section is live and has a list of upcoming IPOs that our members have the opportunity to participate in.  The section will have a list of upcoming IPOs and direct contact to a stock broker that has shares allocated for our members.
  • Profile Performance Tracking- Gives you up to the day price performance of our profiled companies dating back to the beginning of 1999 based on closing prices.
  • Dr Richard Geist's Column On the Psychology of Investing-  Dr. Geist is a Doctorate in Psychology from Harvard University and is an instructor in the department of Psychiatry at Harvard Medical School.  Dr. Geist's recommendations have been featured in Business Week, Fortune Magazine,  Bull and Bear, and The Wall Street Journal.  His market commentary and thoughts on the psychology of investing have also been quoted in Barron's, Harvard Magazine, Financial Planning Magazine, Forbes, New York Times, and USA Today; and he has appeared on CNN, CNBC, PBS, and Bloomberg Television.  Dr. Geist has also been a special guest on Louis Rukeyser's Wall Street Week.  Click Here to go to the archive of columns.
  • Testimonial Section- Read comments from our long term members.
However, the major theme of our newsletter will continue to be ideas in small and microcap stocks which we believe have the potential to provide outstanding returns for investors with a one to two year investment horizon.
This category of stocks is very risky, and you should never invest more money than you can afford to lose.  In addition, you should make an effort to verify through third party sources any claims that we make about the companies that we represent.

The OTC Journal is a proud partner of the SwingWire.com Online Investment Community. A next generation Online Analyst Exchange providing Members the ability to search, review, track and monitor some of the Internet's best Online CAs (CyberAnalysts). Members have the opportunity to potentially achieve higher returns by viewing top performing portfolios and receiving real-time alerts from favorite CAs. 

SwingWire.com also has a lucrative incentive model for experienced investors and traders who consistently outperform the market. Share market ideas with other like-minded investors, establish a proven track record, provide insightful commentary, attract followers and ultimately become one of the Internet's highest paid and most sought after CyberAnalysts! 

Click here to receive your FREE 30-Day Trial Membership with no further obligation. Sign Up Today! 
 
Disclaimer
The OTCjournal.com Newsletter is an independent electronic publication committed to providing our readers with factual information on selected  publicly traded companies. All companies are chosen on the basis of certain financial analysis and other pertinent criteria with a view toward  maximizing the upside potential for investors while minimizing the downside risk, whenever possible.  Moreover, as detailed below, this publication accepts compensation from certain of the companies which it features.  Likewise, this newsletter is owned by MarketByte, LLC.  To the degrees enumerated herein,  this newsletter should not be regarded as an independent publication.

Click Here to view our compensation on every company we have ever covered, or visit the following web address:  http://www.otcjournal.com/disclaimer.html for our full profiles and http://www.otcjournal.com/trading-alerts/disclaimer.html for Trading Alerts.

All statements and expressions are the sole  opinions of the editors and are subject to change without notice. A profile, description, or other mention of a company in the newsletter is neither an offer nor solicitation to buy or sell any securities  mentioned. While we believe all sources of information to be factual and reliable, in no way do we represent or guarantee the accuracy thereof, nor the statements made herein.

The editor, members of the editor's family, and/or entities with  which they are affiliated, are forbidden by company policy to own, buy, sell or otherwise trade stock for their own benefit in the companies who appear in the publication. unless specifically disclosed in the newsletter.

The profiles, critiques, and other editorial content of the OTCjournal.com may contain forward-looking statements relating to the expected capabilities of the companies mentioned herein.

THE READER SHOULD VERIFY ALL CLAIMS AND DO THEIR OWN DUE DILIGENCE BEFORE INVESTING IN ANY SECURITIES MENTIONED. INVESTING IN  SECURITIES IS SPECULATIVE AND CARRIES A HIGH DEGREE OF RISK. THE INFORMATION FOUND IN THIS PROFILE IS PROTECTED BY THE COPYRIGHT LAWS OF THE UNITED STATES AND MAY NOT BE COPIED, OR REPRODUCED IN ANY WAY WITHOUT THE EXPRESSED, WRITTEN  CONSENT OF THE EDITORS OF OTCjournal.com.

We encourage our readers to invest carefully and read the investor information available at the web sites of  the Securities and Exchange Commission ("SEC") at http://www.sec.govand/or the National Association of Securities Dealers ("NASD") at http://www.nasd.com. We also strongly recommend that you read the SEC advisory to investors concerning Internet Stock Fraud, which can be found at  http://www.sec.gov/consumer/cyberfr.htm. Readers can review all public filings by companies at the SEC's EDGAR page. The NASD has published information on how to invest carefully at its web site.

You can unsubscribe from this list at any time by Clicking Here and HITTING SEND. If you are having difficulty removing yourself or wish to change your address please go to http://listserv.otcjournal.com/opt.cgi?email=krbdev@mit.edu&list=otcjournal-new.

  ---
You are currently subscribed to otcjournal-new as: krbdev@mit.edu
To unsubscribe send a blank email to leave-otcjournal-new-3719211X@lyris.otcjournal.com --------------4C9006809691A039D8AD8595-- From lyris-admin@lyris.otcjournal.com Tue Jan 29 16:32:23 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA06606 for ; Tue, 29 Jan 2002 16:32:23 -0500 (EST) Received: from lyris.otcjournal.com (lyris.otcjournal.com [216.105.36.68]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA22158 for ; Tue, 29 Jan 2002 16:32:22 -0500 (EST) Message-Id: X-lyris-type: unsubscribed From: "Lyris ListManager" Reply-To: "Lyris ListManager" To: krbdev@mit.edu Subject: Re: your unsubscribe request Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Jan 29 16:33:00 2002 X-Original-Date: Tue, 29 Jan 2002 14:04:10 -0800 As you requested, you have been unsubscribed from 'otcjournal-new'. --- Return-Path: Received: from listserv.otcjournal.com ([209.75.61.200]) by lyris.otcjournal.com with SMTP (Lyris ListManager SOLARIS/INTEL version 4.1.2); Tue, 29 Jan 2002 13:19:09 -0800 Received: (from nobody@localhost) by listserv.otcjournal.com (8.9.3/8.9.3) id MAA02032 for otcjournal-new-request@lyris.otcjournal.com; Tue, 29 Jan 2002 12:44:51 -0800 Date: Tue, 29 Jan 2002 12:44:51 -0800 From: krbdev@mit.edu Message-Id: <200201292044.MAA02032@listserv.otcjournal.com> X-Authentication-Warning: listserv.otcjournal.com: nobody set sender to krbdev@mit.edu using -f To: otcjournal-new-request@lyris.otcjournal.com Subject: unsubscribe otcjournal-new From akosut@Stanford.EDU Wed Jan 30 02:41:34 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id CAA14044 for ; Wed, 30 Jan 2002 02:41:33 -0500 (EST) Received: from epic3.Stanford.EDU (epic3.Stanford.EDU [171.64.15.36]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA10627 for ; Wed, 30 Jan 2002 02:41:29 -0500 (EST) Received: (from akosut@localhost) by epic3.Stanford.EDU (8.11.6/8.11.6) id g0U7fTH12464 for krbdev@mit.edu; Tue, 29 Jan 2002 23:41:29 -0800 (PST) From: Alexei Kosut To: krbdev@mit.edu Subject: KfM 4.0b7: a few questions Message-ID: <20020129234128.A12371@stanford.edu> Mail-Followup-To: krbdev@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 02:42:00 2002 X-Original-Date: Tue, 29 Jan 2002 23:41:28 -0800 A collection of comments on KfM 4.0b7: 1. The 4.0b7 installer not appear install the header files in /usr/include on Mac OS X. The libraries are in /usr/lib, but I can't find the header files. Everything in the Kerberos framework seems fine, though. It could be just my Mac, though, I guess. 2. The CFM version number of UtilitiesLib seems to have changed again in 4.0b7. I remember this occurring earlier in the 3.5/4.0 release cycle as well. I currently build my CFM binaries against the KfM 3.5 SDK, which worked up until 4.0b6 (although, ironically, it doesn't seem to work for 3.5 itself). I'd like to be able to call unix_time_to_mac_time() and gettimeofday(). I could roll my own, I guess, but I want to be sure I'm using the same time information as KfM. Would it be safer to just use GetSharedLibrary()/FindSymbol() instead of linking to the UtilitiesLib stub library? 3. KfM will automatically invoke the login dialog when certain of the Kerberos4Lib functions are called. I have an application that I absolutely do not want to invoke a login dialog, but I want it to use credentials if they already exist. I can call KLCacheHasValidTickets() first, but on OS X at least, I've been able to log out between that call and the next Kerberos call. Is there some way, on either a per-application or per-call basis, to disable the automatic login dialog? Related comments: a) Why is krb_get_cred() one of the functions that makes the login dialog appear? This seems odd, since this function isn't supposed to actually get new credentials from the TGS. Unless you're requesting the tgt, initating a login dialog won't help. b) get_ad_tkt() doesn't pop up the login dialog, but I happened to notice that it will cause a crash if there are no credentials available. 4. We've gotten a couple complaints here about the login window: If the user clicks on another window while the login server is opening, they may never see the login dialog, since it ends up behind the other app. Going back to their original application doesn't help, and it appears to have hung, since it's waiting for the login dialog to close. Sometimes they eventually find the Kerberos Login Server icon in the dock. Would it be possible to make the login dialog always appear in front of other windows? This would solve this problem nicely. I note that Mac OS X does this for keychain access dialogs, which serve a similar purpose. I know that a Cocoa window can be set to a level of NSStatusWindowLevel to do this; I don't know the equivalent Carbon call, though I imagine there is one. This would probably also reduce the problem I've seen from time to time where the login dialog appears under such a globally-topmost window, making it so you can't easily bring the login dialog forward. Other than that, though, 4.0b7 is running smoothly. I am very pleased. Thanks! -- Alexei Kosut From kqchoi@MIT.EDU Wed Jan 30 10:56:39 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA20079 for ; Wed, 30 Jan 2002 10:56:39 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA18839 for ; Wed, 30 Jan 2002 10:56:39 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09348 for ; Wed, 30 Jan 2002 10:56:39 -0500 (EST) Received: from [18.248.2.167] (FORRESTER.MIT.EDU [18.248.2.167]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA19209 for ; Wed, 30 Jan 2002 10:55:49 -0500 (EST) Mime-Version: 1.0 Message-Id: To: krbdev@MIT.EDU From: Kevin Choi Subject: Printing on Mac OS X to Athena Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 10:57:00 2002 X-Original-Date: Wed, 30 Jan 2002 10:55:50 -0500 Hi, I just installed Mac OS X 10.1 on my computer in my dorm room (East Campus West). I am also running MS Office v.X. How do I print to an athena printer, especially to "helios" in Building 56? (I don't think there's a KLPR client for OS X but is there a workaround?) Thanks, Kevin Choi From smcguire@MIT.EDU Wed Jan 30 11:28:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA20486 for ; Wed, 30 Jan 2002 11:28:26 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA03826; Wed, 30 Jan 2002 11:28:25 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA17795; Wed, 30 Jan 2002 11:28:25 -0500 (EST) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22843; Wed, 30 Jan 2002 11:28:24 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20020129234128.A12371@stanford.edu> References: <20020129234128.A12371@stanford.edu> To: Alexei Kosut , krbdev@MIT.EDU From: Scott McGuire Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 11:29:01 2002 X-Original-Date: Wed, 30 Jan 2002 11:27:29 -0500 At 11:41 PM -0800 1/29/02, Alexei Kosut wrote: >A collection of comments on KfM 4.0b7: > >1. The 4.0b7 installer not appear install the header files in > /usr/include on Mac OS X. The libraries are in /usr/lib, but I > can't find the header files. Everything in the Kerberos framework > seems fine, though. It could be just my Mac, though, I guess. Yes, this appears to be a bug in the 4.0b7 installer, sorry. Thanks for bringing it to our attention. It will be fixed in the next release. Other folks are looking into your other questions. -- Scott McGuire / smcguire@mit.edu MIT Information Systems Macintosh Developer From lxs@MIT.EDU Wed Jan 30 14:49:04 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA22972 for ; Wed, 30 Jan 2002 14:49:04 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA25696; Wed, 30 Jan 2002 14:49:03 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA19504; Wed, 30 Jan 2002 14:49:02 -0500 (EST) Received: from [18.101.1.25] (WEST-NINETYTWO-THREE-SIXTY-SIX.MIT.EDU [18.18.6.111]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA15313; Wed, 30 Jan 2002 14:49:02 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <20020129234128.A12371@stanford.edu> References: <20020129234128.A12371@stanford.edu> To: Alexei Kosut From: Alexandra Ellwood Subject: Re: KfM 4.0b7: a few questions Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 14:50:00 2002 X-Original-Date: Wed, 30 Jan 2002 14:49:00 -0500 >4. We've gotten a couple complaints here about the login window: If > the user clicks on another window while the login server is > opening, they may never see the login dialog, since it ends up > behind the other app. Going back to their original application > doesn't help, and it appears to have hung, since it's waiting for > the login dialog to close. Sometimes they eventually find the > Kerberos Login Server icon in the dock. > > Would it be possible to make the login dialog always appear in > front of other windows? This would solve this problem nicely. I > note that Mac OS X does this for keychain access dialogs, which > serve a similar purpose. I know that a Cocoa window can be set to > a level of NSStatusWindowLevel to do this; I don't know the > equivalent Carbon call, though I imagine there is one. I have written code to place the login window and sub-windows in the utility group layer, which causes them to "float" with the other system utility windows. Pending UI evaluation, this will probably appear in the next release. Hope this helps, --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From smcguire@MIT.EDU Wed Jan 30 15:12:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA23279 for ; Wed, 30 Jan 2002 15:12:53 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA05770; Wed, 30 Jan 2002 15:12:52 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA05306; Wed, 30 Jan 2002 15:12:51 -0500 (EST) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25791; Wed, 30 Jan 2002 15:12:51 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: To: Kevin Choi , krbdev@MIT.EDU From: Scott McGuire Subject: Re: Printing on Mac OS X to Athena Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 15:13:01 2002 X-Original-Date: Wed, 30 Jan 2002 15:10:39 -0500 At 10:55 AM -0500 1/30/02, Kevin Choi wrote: >Hi, I just installed Mac OS X 10.1 on my computer in my dorm room >(East Campus West). I am also running MS Office v.X. How do I print >to an athena printer, especially to "helios" in Building 56? (I >don't think there's a KLPR client for OS X but is there a >workaround?) No, currently there is no KLPR client for Mac OS X nor are we aware of a workaround to print to authenticated printers (which "helios" is). You can print to non-authenticated printers under Mac OS X using the built in lpr on Mac OS X, however. Please note that Mac OS X is not officially supported by MIT Information Systems. For more information, see: -- Scott McGuire / smcguire@mit.edu MIT Information Systems Macintosh Developer From meeroh@MIT.EDU Wed Jan 30 16:46:49 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA24474 for ; Wed, 30 Jan 2002 16:46:49 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA13248; Wed, 30 Jan 2002 16:45:50 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14533; Wed, 30 Jan 2002 16:44:11 -0500 (EST) Received: from [18.18.1.86] (DONT-GRIEVE-ADMIRAL.MIT.EDU [18.18.1.86]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA05762; Wed, 30 Jan 2002 16:43:47 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <20020129234128.A12371@stanford.edu> References: <20020129234128.A12371@stanford.edu> To: Alexei Kosut , krbdev@MIT.EDU From: Miro Jurisic Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 16:47:00 2002 X-Original-Date: Wed, 30 Jan 2002 16:43:44 -0500 >2. The CFM version number of UtilitiesLib seems to have changed again > in 4.0b7. I remember this occurring earlier in the 3.5/4.0 release > cycle as well. I currently build my CFM binaries against the KfM > 3.5 SDK, which worked up until 4.0b6 (although, ironically, it > doesn't seem to work for 3.5 itself). I'll answer the rest of this later, but I would like to know what you mean by that parenthetical remark. meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From akosut@Stanford.EDU Wed Jan 30 17:39:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA25143 for ; Wed, 30 Jan 2002 17:39:46 -0500 (EST) Received: from saga14.Stanford.EDU (saga14.Stanford.EDU [171.64.15.144]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA04350; Wed, 30 Jan 2002 17:39:46 -0500 (EST) Received: (from akosut@localhost) by saga14.Stanford.EDU (8.11.6/8.11.6) id g0UMdjV02693; Wed, 30 Jan 2002 14:39:45 -0800 (PST) From: Alexei Kosut To: Miro Jurisic Cc: krbdev@MIT.EDU Subject: Re: KfM 4.0b7: a few questions Message-ID: <20020130143945.A2584@stanford.edu> Mail-Followup-To: Miro Jurisic , krbdev@MIT.EDU References: <20020129234128.A12371@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meeroh@MIT.EDU on Wed, Jan 30, 2002 at 04:43:44PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 17:40:01 2002 X-Original-Date: Wed, 30 Jan 2002 14:39:45 -0800 On Wed, Jan 30, 2002 at 04:43:44PM -0500, Miro Jurisic wrote: > >2. The CFM version number of UtilitiesLib seems to have changed again > > in 4.0b7. I remember this occurring earlier in the 3.5/4.0 release > > cycle as well. I currently build my CFM binaries against the KfM > > 3.5 SDK, which worked up until 4.0b6 (although, ironically, it > > doesn't seem to work for 3.5 itself). > > > I'll answer the rest of this later, but I would like to know what you > mean by that parenthetical remark. I think it means that I hadn't gotten enough sleep that night. I double-checked, and the 3.5 SDK stub library for UtilitiesLib works just fine against the 3.5 release. I'd gotten confused by my memory of the 4.0a8 release, and made some assumptions I shouldn't have. Sorry about that! -- Alexei Kosut From lxs@MIT.EDU Wed Jan 30 17:55:58 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA25369 for ; Wed, 30 Jan 2002 17:55:58 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA19361; Wed, 30 Jan 2002 17:55:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA23869; Wed, 30 Jan 2002 17:55:54 -0500 (EST) Received: from [18.18.6.111] (WEST-NINETYTWO-THREE-SIXTY-SIX.MIT.EDU [18.18.6.111]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA29746; Wed, 30 Jan 2002 17:55:54 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <20020129234128.A12371@stanford.edu> References: <20020129234128.A12371@stanford.edu> To: Alexei Kosut From: Alexandra Ellwood Subject: Re: KfM 4.0b7: a few questions Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 17:56:00 2002 X-Original-Date: Wed, 30 Jan 2002 17:55:52 -0500 >3. KfM will automatically invoke the login dialog when certain of the > Kerberos4Lib functions are called. I have an application that I > absolutely do not want to invoke a login dialog, but I want it to > use credentials if they already exist. I can call > KLCacheHasValidTickets() first, but on OS X at least, I've been > able to log out between that call and the next Kerberos call. Is > there some way, on either a per-application or per-call basis, to > disable the automatic login dialog? No, there is no way to do this. Is there some technical problem with our login dialog popping up in front of your application? > Related comments: > > a) Why is krb_get_cred() one of the functions that makes the login > dialog appear? This seems odd, since this function isn't supposed > to actually get new credentials from the TGS. Unless you're > requesting the tgt, initating a login dialog won't help. Under Mac OS, we try to automatically prompt for tickets if they are needed and unavailable. From testing, we discovered that users often get confused when presented with a "no credentials" error. This also mimics old KClient behavior, as well as the behavior of most Apple services (such as accessing an alias to an AppleShare volume). I realize that KfM differs from Unix behavior. However, on Unix, the user is almost always using a terminal window when they get the "no credentials" error. Getting credentials then only involves typing "kinit" into an already running process. This is much easier than finding the Kerberos application, waiting for it to launch, and clicking "Get Tickets". The user may not even know where the Kerberos application is if the site has the Kerberos.loginAuthenticator installed, and the user's tickets have expired for the first time. The user can run "kinit" from the terminal in Mac OS X, however, Terminal.app is probably not running by default. Note that for command-line applications running in ssh/telnet/etc sessions, we mimic the Unix behavior and report the "no credentials" error. We only pop up the dialog when the Window server is available. > b) get_ad_tkt() doesn't pop up the login dialog, but I happened to > notice that it will cause a crash if there are no credentials > available. This is a bug; it should be popping up the dialog. It will be fixed in the next release. --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From akosut@Stanford.EDU Wed Jan 30 18:25:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id SAA25767 for ; Wed, 30 Jan 2002 18:25:26 -0500 (EST) Received: from saga13.Stanford.EDU (saga13.Stanford.EDU [171.64.15.143]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA20048; Wed, 30 Jan 2002 18:25:26 -0500 (EST) Received: (from akosut@localhost) by saga13.Stanford.EDU (8.11.6/8.11.6) id g0UNPPM28757; Wed, 30 Jan 2002 15:25:25 -0800 (PST) From: Alexei Kosut To: Alexandra Ellwood Cc: krbdev@mit.edu Subject: Re: KfM 4.0b7: a few questions Message-ID: <20020130152525.A28390@stanford.edu> Mail-Followup-To: Alexandra Ellwood , krbdev@mit.edu References: <20020129234128.A12371@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lxs@mit.edu on Wed, Jan 30, 2002 at 05:55:52PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 18:26:01 2002 X-Original-Date: Wed, 30 Jan 2002 15:25:25 -0800 On Wed, Jan 30, 2002 at 05:55:52PM -0500, Alexandra Ellwood wrote: > >3. KfM will automatically invoke the login dialog when certain of the > > Kerberos4Lib functions are called. I have an application that I > > absolutely do not want to invoke a login dialog, but I want it to > > use credentials if they already exist. I can call > > KLCacheHasValidTickets() first, but on OS X at least, I've been > > able to log out between that call and the next Kerberos call. Is > > there some way, on either a per-application or per-call basis, to > > disable the automatic login dialog? > > No, there is no way to do this. Is there some technical problem with > our login dialog popping up in front of your application? I've got a background application that performs some Kerberos services on behalf of a user who's currently logged in. One of these is to obtain a AFS token after login. When I detect that there's been a login, my app goes and grabs an AFS service ticket and hands it to the AFS cache manager. However, if the user logs in, then immediately afterwards changes their mind and hits Destroy Tickets, they are rewarded by another login dialog, since my background app hits a Kerberos v4 call that pops open the login dialog. The same thing happens if they have multiple logins, and hit "Destroy Tickets" several times in rapid succession to clear them all. I need a way to be able to obtain the service ticket, including contacting the TGS if necessary, such that it simply fails silently if there aren't valid credentials. > > Related comments: > > > > a) Why is krb_get_cred() one of the functions that makes the login > > dialog appear? This seems odd, since this function isn't supposed > > to actually get new credentials from the TGS. Unless you're > > requesting the tgt, initating a login dialog won't help. > > Under Mac OS, we try to automatically prompt for tickets if they are > needed and unavailable. From testing, we discovered that users often > get confused when presented with a "no credentials" error. This also > mimics old KClient behavior, as well as the behavior of most Apple > services (such as accessing an alias to an AppleShare volume). I understand that, and generally I like and appreciate the behavior. It's the right thing to do in 99% of the the cases. But I'm stuck in the remaining 1% right now. You didn't answer my question, though: Why is krb_get_cred() one of the functions that makes the login dialog appear? If I call this function when there are no credentials, even I log in when the dialog appears, the function is still going to fail with RET_NOTKT unless I'm requesting the tgt. It seems pointless to bring up the login dialog otherwise. It's not very important; I was just curious as to the rationale for why certain functions invoke a dialog and others don't. > > b) get_ad_tkt() doesn't pop up the login dialog, but I happened to > > notice that it will cause a crash if there are no credentials > > available. > > This is a bug; it should be popping up the dialog. It will be fixed > in the next release. You'll fix the crash, too, right? (i.e., if I hit "Cancel" at the login dialog) -- Alexei Kosut From lxs@MIT.EDU Wed Jan 30 18:53:58 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id SAA26124 for ; Wed, 30 Jan 2002 18:53:58 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA06023; Wed, 30 Jan 2002 18:53:57 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA00766; Wed, 30 Jan 2002 18:53:57 -0500 (EST) Received: from [18.18.6.111] (WEST-NINETYTWO-THREE-SIXTY-SIX.MIT.EDU [18.18.6.111]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA13496; Wed, 30 Jan 2002 18:53:56 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <20020130152525.A28390@stanford.edu> References: <20020129234128.A12371@stanford.edu> <20020130152525.A28390@stanford.edu> To: Alexei Kosut From: Alexandra Ellwood Subject: Re: KfM 4.0b7: a few questions Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 18:54:01 2002 X-Original-Date: Wed, 30 Jan 2002 18:53:55 -0500 >I've got a background application that performs some Kerberos services >on behalf of a user who's currently logged in. One of these is to >obtain a AFS token after login. When I detect that there's been a >login, my app goes and grabs an AFS service ticket and hands it to the >AFS cache manager. > >However, if the user logs in, then immediately afterwards changes >their mind and hits Destroy Tickets, they are rewarded by another >login dialog, since my background app hits a Kerberos v4 call that >pops open the login dialog. The same thing happens if they have >multiple logins, and hit "Destroy Tickets" several times in rapid >succession to clear them all. > >I need a way to be able to obtain the service ticket, including >contacting the TGS if necessary, such that it simply fails silently if >there aren't valid credentials. That's an interesting situation. We'll look into a solution for you. Are you trying to do this on Mac OS X, Mac OS 9 or both? >You didn't answer my question, though: Why is krb_get_cred() one of >the functions that makes the login dialog appear? If I call this >function when there are no credentials, even I log in when the dialog >appears, the function is still going to fail with RET_NOTKT unless I'm >requesting the tgt. It seems pointless to bring up the login dialog >otherwise. Oh sorry, I misunderstood the question. krb_get_cred() is the trap by which the login dialog comes up. However, really it shouldn't be trying to pop up the dialog unless it's a krbtgt service which is being requested. I'll fix that. >You'll fix the crash, too, right? (i.e., if I hit "Cancel" at the >login dialog) Yup, that's fixed too. --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From meeroh@MIT.EDU Wed Jan 30 19:21:46 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA26491 for ; Wed, 30 Jan 2002 19:21:46 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA04767; Wed, 30 Jan 2002 19:21:43 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA02896; Wed, 30 Jan 2002 19:21:42 -0500 (EST) Received: from [18.18.1.86] (DONT-GRIEVE-ADMIRAL.MIT.EDU [18.18.1.86]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA18094; Wed, 30 Jan 2002 19:21:38 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <20020129234128.A12371@stanford.edu> References: <20020129234128.A12371@stanford.edu> To: Alexei Kosut , krbdev@MIT.EDU From: Miro Jurisic Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 19:22:00 2002 X-Original-Date: Wed, 30 Jan 2002 19:21:19 -0500 >2. The CFM version number of UtilitiesLib seems to have changed again > in 4.0b7. I remember this occurring earlier in the 3.5/4.0 release > cycle as well. I currently build my CFM binaries against the KfM > 3.5 SDK, which worked up until 4.0b6 (although, ironically, it > doesn't seem to work for 3.5 itself). > > I'd like to be able to call unix_time_to_mac_time() and > gettimeofday(). I could roll my own, I guess, but I want to be > sure I'm using the same time information as KfM. Would it be safer > to just use GetSharedLibrary()/FindSymbol() instead of linking to > the UtilitiesLib stub library? Nah, I changed the version number incorrectly. I'll fix it for the next release. meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From akosut@Stanford.EDU Wed Jan 30 20:43:14 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id UAA27503 for ; Wed, 30 Jan 2002 20:43:14 -0500 (EST) Received: from epic19.Stanford.EDU (epic19.Stanford.EDU [171.64.15.54]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA00040; Wed, 30 Jan 2002 20:43:13 -0500 (EST) Received: (from akosut@localhost) by epic19.Stanford.EDU (8.11.6/8.11.6) id g0V1hDV09765; Wed, 30 Jan 2002 17:43:13 -0800 (PST) From: Alexei Kosut To: Alexandra Ellwood Cc: krbdev@mit.edu Subject: Re: KfM 4.0b7: a few questions Message-ID: <20020130174312.A9674@stanford.edu> Mail-Followup-To: Alexandra Ellwood , krbdev@mit.edu References: <20020129234128.A12371@stanford.edu> <20020130152525.A28390@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lxs@mit.edu on Wed, Jan 30, 2002 at 06:53:55PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 20:44:00 2002 X-Original-Date: Wed, 30 Jan 2002 17:43:13 -0800 On Wed, Jan 30, 2002 at 06:53:55PM -0500, Alexandra Ellwood wrote: > >I need a way to be able to obtain the service ticket, including > >contacting the TGS if necessary, such that it simply fails silently if > >there aren't valid credentials. > > That's an interesting situation. We'll look into a solution for you. That'd be great. Thanks! BTW, the other situation where I've been able to coax a login dialog where I didn't want one with this app is when I have multiple Kerberos logins, and I destroy them in rapid succession. My app detects the change of default user and it tries to get a service ticket for the new user, who has also just logged out, prompting a dialog. > Are you trying to do this on Mac OS X, Mac OS 9 or both? Right now, just Mac OS X. Thanks for all your help! -- Alexei Kosut From gavin@umich.edu Wed Jan 30 21:01:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id VAA27749 for ; Wed, 30 Jan 2002 21:01:18 -0500 (EST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA03885 for ; Wed, 30 Jan 2002 21:01:18 -0500 (EST) Received: from [141.213.244.58] (adsl-244-58.ns.itd.umich.edu [141.213.244.58]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id VAA06689 for ; Wed, 30 Jan 2002 21:01:17 -0500 (EST) Mime-Version: 1.0 X-Sender: gavin@forfar.us.itd.umich.edu Message-Id: In-Reply-To: <20020130152525.A28390@stanford.edu> References: <20020129234128.A12371@stanford.edu> <20020130152525.A28390@stanford.edu> To: krbdev@mit.edu From: Gavin Eadie Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 21:02:00 2002 X-Original-Date: Wed, 30 Jan 2002 21:01:14 -0500 At 3:25 PM -0800 1/30/02, Alexei Kosut wrote: > > No, there is no way to do this. Is there some technical problem with >> our login dialog popping up in front of your application? ... there also some sentiment here at umich that people should obtain their credentials before using an application that needs them. Popping up the dialog as a side effect dulls their sensitivity to typing their password into such a dialog whenever they are asked for it. While I understand the convenience and the past history of doing it this way, I'd like to make a pitch for some discussion of this aspect of things. I know there's a preference for this feature, maybe it's enough. What do people think ? ... Gav From mjv@MIT.EDU Wed Jan 30 23:06:42 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id XAA29285 for ; Wed, 30 Jan 2002 23:06:42 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA29275; Wed, 30 Jan 2002 23:06:41 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA25231; Wed, 30 Jan 2002 23:06:40 -0500 (EST) Received: from [192.168.168.6] (merseyside.ne.mediaone.net [66.31.106.229]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id XAA27089; Wed, 30 Jan 2002 23:02:10 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@hesiod (Unverified) Message-Id: In-Reply-To: References: <20020129234128.A12371@stanford.edu> <20020130152525.A28390@stanford.edu> To: Gavin Eadie From: Marshall Vale Subject: Re: KfM 4.0b7: a few questions Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Jan 30 23:07:01 2002 X-Original-Date: Wed, 30 Jan 2002 23:02:05 -0500 At 9:01 PM -0500 1/30/02, Gavin Eadie wrote: >... there also some sentiment here at umich that people should >obtain their credentials before using an application that needs >them. Popping up the dialog as a side effect dulls their sensitivity >to typing their password into such a dialog whenever they are asked >for it. This argument has been brought up from time to time and while it might make sense in a More Perfect World, in practice I believe it creates a bigger burden to the user resulting in higher support costs. A classic tradeoff I've heard for security technology is that the harder it is to use, the more ways around it users will try to find. Additionally, what I've seen from systems we have deployed here at MIT which force users to use a separate application to acquire credentials is that they often generates support calls and questions due to the often bizarre behaviors or messages that come from applications when credentials expire. The sample I'm thinking most prominently here is even of a group of people that "should know better" too. Then the argument leads to something like this: + Then we should pop up a dialog/print message telling people to use application "foo" - But they don't know where it is or how to use it (an argument even presented here on this list recently) + Then we should go find it and open it or print out the command for them - But they might not know what to do next or be confused by the various options presented + then we should bring up the dialog/issue the command for them. ...and we start the circle again. As for the argument about people being desensitized, people are already used to typing in passwords to anything that ask for them. How many of our folks have separate UIs/passwords for the financial system, AIM, Yahoo, online banking, database reporting tool, Apple developer account, web boards, etc.? Hey, maybe .Net will get rid of all of those separate password dialogs and we will be back down to the one true password dialog :) > While I understand the convenience and the past history of doing >it this way, I'd like to make a pitch for some discussion of this >aspect of things. I know there's a preference for this feature, >maybe it's enough. What do people think ? ... Gav It's not really designing a preference here, it's designing a policy system. That is an incredibly complex engineering task that when confronted with the multitude of other requests, always gets bumped off the list. Remember, not every site uses the same privileged application or perhaps may even have several of them. How do you distribute the policies? How do you make those policies secure? Nasty do'ers can still target the policy system to install a trojan application and dialog just like now. Otherwise, you're just annoying the user by forcing them to perform unnecessary steps that the computer should be able to automate. And isn't that what computers are for? Marshall From kenh@cmf.nrl.navy.mil Thu Jan 31 01:13:57 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id BAA00863 for ; Thu, 31 Jan 2002 01:13:57 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.12.161]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id BAA22437 for ; Thu, 31 Jan 2002 01:13:57 -0500 (EST) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id g0V6DtG12571 for ; Thu, 31 Jan 2002 01:13:55 -0500 (EST) Message-Id: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> To: krbdev@mit.edu Subject: Re: KfM 4.0b7: a few questions In-reply-to: Your message of "Wed, 30 Jan 2002 23:02:05 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 01:14:00 2002 X-Original-Date: Thu, 31 Jan 2002 01:13:55 -0500 >It's not really designing a preference here, it's designing a policy >system. That is an incredibly complex engineering task that when >confronted with the multitude of other requests, always gets bumped >off the list. My personal thoughs are that this is overkill for the problem at hand. Many of the wacky changes I've had to made to our Kerberos tree were driven by site policy (and not ones that come from me; these are from the people that give us money). But I've never felt the need to implement a policy system, and looking back over what I had to do, I'm not sure I would have benefited from such a thing. As you point out, such things end up being complicated ... and the changes I had to make to the bits of code are rather small (it just ended up being a lot of them, but I'm not sure that it would have been any savings considering the effort of creating a policy system). I have to believe that changing the library _not_ to pop up a dialog box can't be that big of a change, and there are certainly plenty of places to stuff the information to tell the library how to behave. >Otherwise, you're just annoying the user by forcing them to perform >unnecessary steps that the computer should be able to automate. And >isn't that what computers are for? As for the actual feature request ... I'm of two minds about it (not that I have any actual influence either way :-) ). When you get right down to it, in a system with a nice graphical UI, you _expect_ things to be helpful, like putting up a password dialog when you need to enter your password. But I agree it's important to train users to only enter their Kerberos password into the few places where Kerberos passwords go. But ... if you can pop up a dialog box onto someone's screen, then the game is already over IMHO. But it wouldn't surprise me if a site had a policy prohibiting the auto-password dialog from being used, and it would be shame if you couldn't use the shipped Mac Kerberos at such a site (not that any site that I'm aware of has such a policy today). --Ken From mjv@MIT.EDU Thu Jan 31 11:04:01 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA08056 for ; Thu, 31 Jan 2002 11:04:01 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA05098; Thu, 31 Jan 2002 11:04:00 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA06209; Thu, 31 Jan 2002 11:04:00 -0500 (EST) Received: from [18.18.1.144] (ETTLINGER-TOR.MIT.EDU [18.18.1.144]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28598; Thu, 31 Jan 2002 11:02:28 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@hesiod (Unverified) Message-Id: In-Reply-To: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> References: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> To: Ken Hornstein From: Marshall Vale Subject: Re: KfM 4.0b7: a few questions Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 11:05:00 2002 X-Original-Date: Thu, 31 Jan 2002 11:02:25 -0500 At 1:13 AM -0500 1/31/02, Ken Hornstein wrote: >I have to believe that changing the library _not_ to pop up a dialog >box can't be that big of a change, and there are certainly plenty of >places to stuff the information to tell the library how to behave. Ok, so if you remove the ability for the dialog to pop up, how does it ever get displayed? What triggers it? New APIs? Ones that any trojan application can call itself? A list of privileged applications? One that can be hacked or impersonated? Put yet another copy of the dialog and associated libraries in a privileged application? That's a code synchronization mess. Remember, right now the dialog and associated items are in the library, not any specialized application. >When you get right down to it, in a system with a nice graphical UI, >you _expect_ things >to be helpful, like putting up a password dialog when you need to enter >your password. But I agree it's important to train users to only enter >their Kerberos password into the few places where Kerberos passwords >go. It gets worse on an OS which has multiple types of user interaction each with their own history of standard user interaction. > But ... if you can pop up a dialog box onto someone's screen, >then the game is already over IMHO. But it wouldn't surprise me if a >site had a policy prohibiting the auto-password dialog from being used, >and it would be shame if you couldn't use the shipped Mac Kerberos >at such a site (not that any site that I'm aware of has such a policy >today). And that gets right down to the point, I don't know of any either. There are enough sites with other concrete requests that features for hypothetical situations aren't exactly appealing. I still say that even if you truly disable auto-dialogs, you're only moving the problem laterally. Now you just need a trojan to impersonate the privileged application. If you want to get rid of dialogs, you should implement a system with Kerberos that never needs user UI (dialogs or CLIs or whatever) interaction, such as one of those Kerberos SmartCard projects. Marshall From kenh@cmf.nrl.navy.mil Thu Jan 31 11:27:27 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA08363 for ; Thu, 31 Jan 2002 11:27:26 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.12.161]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA00506 for ; Thu, 31 Jan 2002 11:27:26 -0500 (EST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id g0VGRPG16945 for ; Thu, 31 Jan 2002 11:27:25 -0500 (EST) Message-Id: <200201311627.g0VGRPG16945@ginger.cmf.nrl.navy.mil> To: krbdev@MIT.EDU Subject: Re: KfM 4.0b7: a few questions In-reply-to: Your message of "Thu, 31 Jan 2002 11:02:25 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 11:28:00 2002 X-Original-Date: Thu, 31 Jan 2002 11:27:24 -0500 >At 1:13 AM -0500 1/31/02, Ken Hornstein wrote: >>I have to believe that changing the library _not_ to pop up a dialog >>box can't be that big of a change, and there are certainly plenty of >>places to stuff the information to tell the library how to behave. > >Ok, so if you remove the ability for the dialog to pop up, how does >it ever get displayed? What triggers it? The user, of course. They see the error "Kerberos ticket has expired" and they explicitly run their "Get New Tickets" application. We've used something similar for years, and people don't seem to have that many problems with it. I'm not saying this is desirable; I'm just saying that this is what I think the guys at umich wanted. >New APIs? Ones that any trojan application can call itself? I'm not sure it's reasonable to try to guard against trojan applications; I mean, it's not like there's anything _now_ preventing trojan applications from running wild. Would doing this make things worse? I'm not sure. >And that gets right down to the point, I don't know of any either. >There are enough sites with other concrete requests that features for >hypothetical situations aren't exactly appealing. Well, this didn't seem that hypothetical; the guys at umich (please speak up if I've got it wrong) seemed to have not a "policy", but a preference. And as I understood it, they didn't want to get rid of dialogs completely, just ones that weren't explicitly triggered by the user. --Ken From gavin@umich.edu Thu Jan 31 11:56:32 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA08740 for ; Thu, 31 Jan 2002 11:56:32 -0500 (EST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA13218 for ; Thu, 31 Jan 2002 11:56:31 -0500 (EST) Received: from [141.213.244.149] (adsl-244-149.ns.itd.umich.edu [141.213.244.149]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA04751 for ; Thu, 31 Jan 2002 11:56:31 -0500 (EST) Mime-Version: 1.0 X-Sender: gavin@tremors.imap.itd.umich.edu Message-Id: In-Reply-To: <200201311627.g0VGRPG16945@ginger.cmf.nrl.navy.mil> References: <200201311627.g0VGRPG16945@ginger.cmf.nrl.navy.mil> To: krbdev@mit.edu From: Gavin Eadie Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 11:57:01 2002 X-Original-Date: Thu, 31 Jan 2002 11:56:28 -0500 At 11:27 AM -0500 1/31/02, Ken Hornstein wrote: >I'm not saying this is desirable; I'm just saying that this is what >I think the guys at umich wanted. ... first, let me be clear that I only opened this for a conversation on the merits of a point of view and was NOT asking for anyone to change anything in KfM 4.0. In retrospect, I realize I may have polluted the list and/or caused the MIT guys to take valuable time out from getting KfM 4.0 done to engage in mere chit-chat. IF there were any prevailing sentiment to make such a change, or provide it as an institutional option, it'd be for a KfM 5.0 (4.1?) feature list. >Well, this didn't seem that hypothetical; the guys at umich (please speak >up if I've got it wrong) seemed to have not a "policy", but a preference. >And as I understood it, they didn't want to get rid of dialogs completely, >just ones that weren't explicitly triggered by the user. ... well, even here at umich there may not be agreement! By the way, the "application" I was thinking would be used to refresh/obtain tickets would just be "Kerberos" -- the app/control panel that MIT currently launches automatically. I certainly don't want any other app to get involved. At the risk of extending the conversation, let me surmise that, when Mac OS X login can use Kerberos and obtain a TGT, this issue will largely evaporate. With the software available today, the first Kerberized application that runs (Eudora, Mulberry, Fetch, ...) causes the 'get tickets' dialog to be presented in order to get tickets ... in the future, we presume, the process of logging in will satisfy this need and that such applications will no longer require this intervention (for at least as long as a ticket lifetime). From lxs@MIT.EDU Thu Jan 31 12:04:06 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA08865 for ; Thu, 31 Jan 2002 12:04:06 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA16696 for ; Thu, 31 Jan 2002 12:04:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21407 for ; Thu, 31 Jan 2002 12:04:06 -0500 (EST) Received: from [18.101.1.25] (WEST-NINETYTWO-THREE-SIXTY-SIX.MIT.EDU [18.18.6.111]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA27423 for ; Thu, 31 Jan 2002 12:04:06 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> References: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> To: krbdev@MIT.EDU From: Alexandra Ellwood Subject: Re: KfM 4.0b7: a few questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 12:05:01 2002 X-Original-Date: Thu, 31 Jan 2002 12:04:04 -0500 I'm unclear why is it such a problem to train users to only type their password into the Kerberos Login Server dialog. We present a distinctive and consistent user interface, Dock icon and launch path. Our KerberosLoginServer.app (separate from the Kerberos.app) resides in a location owned by root/wheel so admin users can't modify it without typing in their admin passwords. Any security conscious user can verify via their favorite process monitor that only a user with root access could have tampered with their Kerberos dialog. Non-security conscious users aren't going to verify anything, no matter how hard you try to make them. In fact if you make life too difficult for these users, they'll find a way to circumvent the security entirely. Mac users are intolerant of inconvenient applications -- much more so than Unix users -- especially since Kerberos has been historically more convenient on the Mac. Training users to run "kinit" when they get a "no credentials" error is very similar to training them to type into a specific-looking dialog which appears when credentials are not present. Yes, a malicious application can launch a helper application that presents a similar looking dialog. That same app could also add a line to the user's .cshrc which makes "kinit" an alias to a malicious kinit. Or it could change the Kerberos application icon in the Dock to point to a malicious Kerberos application. If the user is an admin user, the situation is even worse, because /Applications is writable by the admin group, and the malicious application could modify the Kerberos application itself. In order to notice this kind of tampering, users need to run "alias kinit", avoid the Dock, or check the mod dates on the Kerberos application before typing in their password. Any user willing to do that would also be willing to run "/bin/ps" to verify that the real Kerberos Login Server is prompting for a password. If you're going to spend lots of resources training users, you should train them to only download and run trusted software. At the very least, instruct users to create a separate non-admin, non-Kerberos account for recreational software. Once malicious software is running as the user, you've already lost. Even if the malicious program doesn't bother attacking the automatic Kerberos dialog, it still has access to the ticket file/cache, the dock icons, etc. >But it wouldn't surprise me if a >site had a policy prohibiting the auto-password dialog from being used, >and it would be shame if you couldn't use the shipped Mac Kerberos >at such a site (not that any site that I'm aware of has such a policy >today). If a site has such a policy, they won't be able to use Mac OS X at all. Mac OS X automatically prompts for passwords all over the place, especially for the admin password to get root access. In the not too distant future, this admin password could also be the user's Kerberos password. In addition, any site handling very sensitive information on Mac OS X or Windows boxes should have a disconnected network or no network at all. Automatic prompting for passwords is the least of their problems. However, Alexei's automatic AFS token acquisition program exposes a technical problem in the *way* we automatically pop up dialogs. We will investigate ways to fix it in a future release. It probably won't make it into 4.0 though. Fortunately with the Kerberos.loginAuthenticator, users can get tickets on login (via the loginwindow). When the login authenticator is enabled, the automatic dialog should only pop up if users intentionally destroy their tickets, or if the tickets expire. My two cents, --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From nneul@umr.edu Thu Jan 31 13:12:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA09761 for ; Thu, 31 Jan 2002 13:12:53 -0500 (EST) Received: from smtp.umr.edu (mrelay1.cc.umr.edu [131.151.1.120]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA13795 for ; Thu, 31 Jan 2002 13:12:52 -0500 (EST) Received: from umr-mail1.umr.edu (umr-mail1.umr.edu [131.151.1.121]) via ESMTP by mrelay1.cc.umr.edu (8.12.1/) id g0VICouU031273; Thu, 31 Jan 2002 12:12:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: parsing dump format... Message-ID: Thread-Topic: parsing dump format... Thread-Index: AcGqgvc3HR0t9hXCEda/IgBQVgAgFQ== From: "Neulinger, Nathan" To: "krbdev@mit.edu" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id NAA09761 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 13:13:00 2002 X-Original-Date: Thu, 31 Jan 2002 12:12:50 -0600 Is there any quick and easy way to get the last-pw-change date from a dump? It looked to me like the other parameters, such as expiration, etc. are all in there, but I couldn't find the last-pw-change, or last-modified time in there, unless it is embedded in one of the hex blobs. Looks like this might be why it isn't in there: /* * If we don't have any match strings, or if our name matches, then * proceed with the dump, otherwise, just forget about it. */ if (!arg->nnames || name_matches(name, arg)) { /* * Deserialize the modifier record. */ mod_name = (char *) NULL; mod_princ = NULL; last_pwd_change = mod_date = 0; pkey = akey = (krb5_key_data *) NULL; if (!(retval = krb5_dbe_lookup_mod_princ_data(arg->kcontext, Why are those params set to zero for the dump? -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From gavin@umich.edu Thu Jan 31 12:46:59 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA09419 for ; Thu, 31 Jan 2002 12:46:59 -0500 (EST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA01154 for ; Thu, 31 Jan 2002 12:46:59 -0500 (EST) Received: from [141.213.244.149] (adsl-244-149.ns.itd.umich.edu [141.213.244.149]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id MAA06022 for ; Thu, 31 Jan 2002 12:46:57 -0500 (EST) Mime-Version: 1.0 X-Sender: gavin@tremors.imap.itd.umich.edu Message-Id: In-Reply-To: References: <200201310613.g0V6DtG12571@ginger.cmf.nrl.navy.mil> To: krbdev@mit.edu From: Gavin Eadie Subject: Re: KfM 4.0b7: a few questions Content-Type: multipart/Related; boundary="============_-1199623280==_mr============" ; type="text/html" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 13:42:00 2002 X-Original-Date: Thu, 31 Jan 2002 12:46:53 -0500 --============_-1199623280==_mr============ Content-Type: multipart/alternative; boundary="============_-1199623280==_ma============" --============_-1199623280==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:04 PM -0500 1/31/02, Alexandra Ellwood wrote: >I'm unclear why is it such a problem to train users to only type >their password into the Kerberos Login Server dialog. We present a >distinctive and consistent user interface, Dock icon and launch path. ... oh dear, I've not been clear, sorry Alexis. Whatever the actual pros and cons of doing what I was wondering about, I'm ABSOLUTELY committed to presenting users with ONLY the Kerberos Login Server dialog as provided by you guys. In my putative scenario, an application's request for a service ticket, when no ticket granting ticket was available, would cause an authentication failure, rather than the Kerberos Login dialog. However, I hear Marshall's concerns that this might be even more confusing, and likely to generate a heavier help desk load. Well, I've done nothing this morning except reply to email generated by my message to krbdev, so can I respectfully suggest we ease off the topic for a while? I've probably generated a little more heat than light, but certainly sufficient light to illuminate the dark, dusty corners of my brain ... Gav PS: Speaking of light, heat and other meteorological phenomena, those south and west of Ann Arbor might be amused at a foot of show and freezing rain here last night and the view of the trees from my home office window: --============_-1199623280==_ma============ Content-Type: text/html; charset="us-ascii" Re: KfM 4.0b7: a few questions

At 12:04 PM -0500 1/31/02, Alexandra Ellwood wrote:
I'm unclear why is it such a problem to train users to only type their password into the Kerberos Login Server dialog.  We present a distinctive and consistent user interface, Dock icon and launch path.

... oh dear, I've not been clear, sorry Alexis.

    Whatever the actual pros and cons of doing what I was wondering about, I'm ABSOLUTELY committed to presenting users with ONLY the Kerberos Login Server dialog as provided by you guys.

    In my putative scenario, an application's request for a service ticket, when no ticket granting ticket was available, would cause an authentication failure, rather than the Kerberos Login dialog.  However, I hear Marshall's concerns that this might be even more confusing, and likely to generate a heavier help desk load.

    Well, I've done nothing this morning except reply to email generated by my message to krbdev, so can I respectfully suggest we ease off the topic for a while?  I've probably generated a little more heat than light, but certainly sufficient light to illuminate the dark, dusty corners of my brain ... Gav


PS: Speaking of light, heat and other meteorological phenomena, those south and west of Ann Arbor might be amused at a foot of show and freezing rain here last night and the view of the trees from my home office window:

--============_-1199623280==_ma============-- --============_-1199623280==_mr============ Content-Id: Content-Type: image/jpeg; name="brrr.jpg" ; x-mac-type="4A504547" ; x-mac-creator="6F676C65" Content-Disposition: attachment; filename="brrr.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gAMQXBwbGVNYXJrDf/bAIQABwUFBgUFBwYGBggH BwgKEQsKCQkKFA8PDBEYFRkZFxUXFxodJSAaHCMcFxchLCEjJygqKioZHy4xLSkxJSkq KAEHCAgKCQoTCwsTKBsXGygoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo KCgoKCgoKCgoKCgoKCgo/8QBogAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLAQAD AQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUS ITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Sl pqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5 +hEAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/8AAEQgA8AFAAwEiAAIRAQMRAf/aAAwD AQACEQMRAD8A5jW9H1SR7fUbrUheW8jCJLp4mVIMDcAVQEIvfKg++K2dB8Za3p1zbvay w3ji0LW8ZlDI0iFlZQwP91m7gjcPer8CQSQoG1XXHeWdlke3u4Y4kGdgf5VyW78ZBHGa Zc6ppGl3r6ZLqev6lfQM4kks5rcJ8q5JJMZwSQeAT2zTK12ON8Qao/jDXrjU7e3Hn3pE phiO4LhQCc8ccZya6jQNJn0uNxqML/YpoW/0gTxQq7EAFQJXXI6ZPQ4rP1rXLLT9QktI 9OvDHGysbiXUNz9QTiNURT361bvNJHiOPSrsyQIshcCRsBHiOOYs5JIIwyH5gSfagGrG 1/YOl6lbqmtaPf6vAFDQXOjRwyTRA8uSVdzgsCRtx1IwaxPsdz4C8Qef4K1m+Mkqt52l atZywyOiDO0naFcYJwRtI9TU3h+6tRBH5cKwwQc2zOQs65OEwGOcttbIH3d3TvTL6TxO bRdFvLgS6dcXSxRXUU7RyuGKjEqKccAnoACRnnrRuKyPRNK8WaJ4oiFve2tutzeLHdyW zOXSYlcK6k4PA+h4/PN8Uiy0K6SWCa42zlm8iSZPJiRz+82/LlOnAOV+Y8dK8v1zRdSX WppwrmCM4tnSVTKYkGEIxg5IHp3q6njbUdJims/KupbGQjMWsKsynjg7WUgevBp3E7dB 9pNcTXM9ppcix3SGSbZdzIqgAk4IIKlu3bPritG4mvtTMi6gLRJ5hmQ2SSHfnI4CZOSM g4LdelUNH8T+F4dU+36haXZaePyna0vBH5fJAYKwGTjvuHB6GvQ/DKeCleMtqNlqFxuB s4Z18mSEYOfkLYZj1yM0g8zm7NpmhWFPOEU22RrWNmO4KMKHVwGB+gHcU61gaUXAmgli TczMY84BywwRnJ9PxrZ+Idto95qFgLKysor/AGvcSvtwzqmFjjUKRh3ZsZ9FOeBXOXJk WZbZ4/3e1kjnBYYcffPUY6fePGDz0o0Grle0vWtNLtCSoX7J5IkJwN6llIOexGPb860f +E48OeHL2GHR7jVnSEq8tnp/lpDdzgfM8jgGVx1G3pwMDFZVyRp9vd6fqGjC4uIrpLfy WbzHQTBXXywjYYsykZJwOvtVLS9Alupp7yK3bQrK1k2STacwe4R/4lMpyQQD1yBk465o BnQy6j4T8Q6q2qy2esaHqEkZj3xBDFJkADCTDg5A+7tz61ly3ehLcMXk1G/uAFKtcQRl wTjCoWmIRSGBxnnHbNMl0Kxlu59oe/SRFVG1NzJKpUcfODkcbcgcZ9KjsfC+kQRTibRr dnLMsXmqzLGBxlck5JwDz6+1IdrFm41bTNIs7gvJrmmN5pQ2pFszK7jdyysSqnBO0YPX BGaSw8V6SpSe3lu5oxLHsDLHGy7M7RzvPAP41n6z/ZcU8UE9m8krSKscjrhS2Mb3UMAS FKgNyQOPWumsNNgsbuzGsQNY2PmhCsVlJiZZF6My42oBkl/bPShpjv3KWjXK6fMum27i 80mZi9iscvlzR9We3ywxuXOQONy5wTW3H4q0uOFpG8KzPGm0SSxXe9ypH3k3c4wq8HB/ lXP6fplve2l812kkUaMscUhZczy8vGQQD9wfNnptPvXQ3NrBbxpBcxFpk3C3dwssMiKA FcIWBVlI5YYbOeD0pknI63ru0p/wiltqmm3U02+7mlJJZFB2I5KhSp8w/Kcj5eetbOn3 Uz+EbWbyrbT5GaQfPIR5Um14w1vnAU5Eh8vOBnAOcCtHUbK8FzGrRxx3n+ukCX7hxHnG WGWC4yfxGc1wOuJJczCJICsMMjSrGh5DOVQfMf4jtIBJ5znvQOyOt0+xh0/RrRpr+Z7q 7K+a1vhRcQgEIWSX+IjvgnPXNV0k09dNf+y9SSWxhz51t9hYMr9CGACLuA39Oh5z0rWs 9atEvXhmupdYECra3VsiCJUk2EZP8Druz83Xdng8VMIjb6Q1tc6TNvZUube/SKIusm3D xyuG/erg8MMnDAdRyhanPeVHdRu5Z0toSRI8d2fMcYA3fLgDapBJyepGTjNMeC2miEEu ozKrPszI6jzAAeuMbug9D9aoC/gWa53syRSSB4twIlbAUYKHJP3T1wefu1nalqV6jL5c JiLEhZWQGViTkj1Xr0AHtRctRN+21i+8LQeVFrFvc2u7P2We08wEdeAxGPrxWRrnim+1 6ZFSCKCM/KltZ24UsT67eSe1LZeF7+5Q3WoebbRHk7l+f689Pxo1bT77QLmz1LQJrtHi ILIibnjcY+bIHzKcjOf7wGKLXFdLU1PD+hXdvP8AY9RRrVb9Xt9n/LSPMUisSvUe3rik sHtVsrZdPjkQ3Ll1HlsZJFUZwxGSOdvX1NbOj6/qmrQ6JZ3sNy4+0rJ5l1IxkRiQuFXA AVgxxnPT61kS3EceoTmwvZWEcQS1WdN8g8w5UOqZ24O324OcChC1Yn2hXmtLOaaby4Zg 135ZGHEZ3cqMEBSBwTya3JrxUW0iht3ZkWRtjLgn5uOc8nBx2x71ipPBePK2oXsJW2tk hMokCr5hcGUAj/dHT1NVrPVrhbd7bTLiXUIjgLPfxBY1IHXOMv0HYcYoHqbGq6hZafJE +oySxxFiHbeSDLtB3AnPAK4wPT3qwiahrdrPqtnp8kImci9t5IyovFwSZlQf6s9dwJ5w CME4rB063N7JHJse812djHG1yFkS3+cDcqAlQo5IPqK09Ynj1O8jyby9soSlvG8ZbDzb jvIKMCQflJPYKOlAluSw2ejCxhiitrM6bHMkqW9lFNJMXU5BAXIzyclmweOtPbU4PKKW 39rh7kyBYE09IdxHzHdI7SYPPXb1qfxBcWtxeyGbT4JFjPlq5g2qzIzbm7Hg5UDv+FYl xNA9tKP7HcoGRCk1zP5Zzkk4EmOnbp7UD0J9c1qWzitEtNLvdQuLliJPt2pSAQYx8rtC UUcEe3v2rKl8TX2lDzzDp1tdsCoNrYB3jOCVAlmLtjJB3d9pwMc1bt7CxhgFvKlraNcn NrbFhFDg7txUNuwf7rScZ4yMiucn0K4097uSRZL6EE7/ACgfMBznMi9Vx6jg9jigV7E9 j4l1aG4uNUu7qXULmWJ4S13I0m8MCMAdgDggDHQVPZKbS1ivLq4RJ4ZWdIZEZwr5DNvQ DJLcD8qwlld70KzKoQ5JB+VQOePwr0LwvojeIobWR7+C0lngna2EgVo5DHJHhXOcjO/+ RGaBI4+O71W+gjgGs6VGrRAGGWMxKOSdpOCD+HGKsR2mseHmjFvBoF4GBb/Qix2HkEPg KOh9xW7qHgvw9JLFHatOJGkVStvIQQvIYEPnnpyOPY4rFh8F2jXcVrHd6hC8spRmdV27 ckqythQTtxnr14piQHSbvUL5I9asrawee3Mls66lGitswoU5JAPB4ODwa0bdrHRfDjSv bXV5A14qxQSBJHtpV+YyAOVC5PHHOOe9Q6X4Vg07XIjBrEd3p/mFftUkTc/JmQKp4Lqp OT0A9+Ko6y95M019Dq5iihZd1sxZgdxZfNRcHarCMEj3GOtA72LFtqYzDNaaFrl7wgE0 whAdsnBypI5O724rVj1LVLq/s5tRsH06Hb9rtFllWTzMIVVjs5++fu8fTvXPwHXvs2bb Xbd7U3BgWOJTvm24O5EZBleeOnfNaWoC606O2vpNMn1SeFmiWRbiWFLZuu0eUMseTuOd ozikNPQtLp3igwLYR6j4Yt0tQZI0jZ2J3Hn5pDgc4zjpRb2OsxmSOfxBCso2tG0VjFJH u3HcGctgAc8jPWmPq2t2zxhvAepsrRI7Kus3Em4vgKyFM4U5AwcnNVP+E4VICbnwvqcL g4V49UnA3DkqSy/Lx25NMRHfabNZWs8reJJpp4xuSKK2CqxPJXd3IOOmRzUUuh6xNPbS Rvql5DcbWVMOkrcEkKpHIAHL4A49a2NO8Zw6vK0en6X9ncIxMc17cSljjgKRKvQjnjpS SwLdwwS3+iwG5uombfHqV0RCwJZAD5rBvr0zigdjHGo3FpYq9nBqWnypIjRzyXCCVwFY FNjxHJ64G4nrnOcVeGk3unC6sNP8Ttf30REz6fLpYdZWZ1BR3LncxLN0BB2t6imatqOn faYLddMtXu1vIWlgtLaVpbhhnALNJwRzxkAljkHGaUaBfXGr3U1zqBFxcT+bNETnd8x2 q2wnAUkZIOMZxzigmwpsdZ0vVZtNvTPDeTgQvNYxRgwM37yIkB9oOQ+ATuIJwK0PD3gy 61+Z7ez+IKWdzFlfs8trsnUk4I8olW/pkVi/8JNcxi70tI3SFLsXUKzRhJmlRs+Y54O5 lyMHgKQB0r0yfxD4a8cCO01qNPtsKJLDPnyp13LkNFIvPQg46dMincNWcZf+B9Y0jUY7 TU9d1mKJ7k24vQQivwTuQHgjvjOeDVKTS9ftLdJE8TXUsTOwWSW0SSN0GNpBDZ3E8FOS PWu5u73xDHYvp08w1/T4pBtuEAe7RRnb5sS5Y5wRvQNnB4Fc9capO15EunTeYvmhJIZH WR1ToHaJyG4xgjA4PHIpMZzGsyahZ6p9lvbjS9UkBV4p2hkh35AI+6Tg9ufzrUl1nXll jh1HR7i8WC38zEF/Cw8lifuE8hevuMdAKTX/AA/dXt7aXUUZAjIWRGRhklgSRgdM5+lW pJJDLbG72vGksSRLHuBD7RHhj3y20856dKQ7skudZu9MlsZotNu5Y4o/uxshZSQCUIJG OFVcjJIWs28utU8RykyeHtRudQKApMpiyu05XhmPyjB4yCcnua1oILmcyeTPGC1uBHGZ lcx7W+8jOw6ncTjj5hjiobrVNMg013e8FuZLhUDQpvaRVV8gFRsyC2Tyc8ZoHqRXvibV pkurVdDvLGK2mVtRt4ZoVBLbQPN/jKjHrtA69Kyp5Zo7yd57YJczeXPsa82NEIyNuCiE 8HBxyKsf8Jfb21utxpNs0c9jbpZxzy4LyB2LOWAPT5Tgdga52bVrzU90fmYSI5MEChY4 s+iLhVHsKAOp0/UL3SbXUbyG00oR8JK0lx55YgjaNjKCQS2Mg5GT0606SSG5L2ccwYwo sjYkm2Q78EZUnIXpyrY5Gax9O8J3dxMrTKs8gOBDA3nSgDkq3l7mQ9OCPbrxXT2os7fT 7UzSEXULm2dNjZlZCdoYEZ4UjIb09qVguuhm2eg3FzNLAjJp8pXK8IsjjGc4DsSNpzy+ AOoq5p+lJpUsixzG4cQ7ZTIBCVnGcqGCgEA8CTnvyRVm6im02zW2WW9ulncZgjiV4Eyo zhchvlCkfeAPTB4pL/VRumtNTntNWu1+QNBemK9XrtAKqA4Po2evJFMNWODi4tEtBLM8 Tt5mGkAcDJypJIIIIYEDvUMrahFqDTxTW6wOubn7RNnHQb1BGAcA4x1/Cobae7nEMVjp ayXMj5RZbmN3LEKrHCsOuAxz06+tLe+G/GE9t5l5aLZWkRVZVhMUzW5ODk4O1Bgglgeh PvR6BoVNJ0zUtK8URXtzDcrayyotvHJc+a+S64yrHcozjt0z6CqeWl1KaSH7PcTo7KZi xt7aPk9EUmSQfL0zjNatpZ2OgQw6u9w15dLcj98knmwkDayDchOSTkHaOMHmsSHRYpZX 1Cw12wje0jwPIiKzSspYF2TAOOCPl3tgZJo3YOy1Lh0F7e8XU3+y6y0Tb57MoERl6EKM nHsDjrWvDdQXieXY3lxDfxErcWv2QJcRbiBu8ts5ABIJH15rL0meHUbedUvLed2T999m LKHAzgDcFKkls5Nat3bLrGJ7m1+0PFKUtorckXCtjezRv97IxgdskdaALGk2IFld6hLN uuXzFBdJtZuQyBsAAEknoePSqmmTyaVPsurnzY2zH5pVUEUYxkgADBztGBnORgVBqj2u mzxWmp6npup3ePNVFnWK8t25A3Njymcjr8yH1Bp9qdLtb1IHa5tSVBb+1TLJPhhwxBwN ucHcpP8AWgmxdQJrW6GeaW0hgHmytEV353ZLSSHIHRjtHTnLdqqrardXdhZmae9tfIku TKCq4Vtq7gMYPOOnODWWlxcaaiF7KNrWSTM0CHJuTnaBwSNhOD3zjr6yw6zqRW+v40a3 vbdYoki83zI4YwzOyAEYyQmPfNA/Qq6rBHeX9oDdxvAhSMyi4SONEB6lchi+MliR1HSs 668a6lJqMl2pgurRpGW2tbpSypEvCFHUh04x91gD3BrrLu4OpxqIJnkW/wB0oM0obaCC SpzgKvUAfrXCyQ2MtzI0yyWcik48uYXCvjp8vUdP72MUCN1b2DUbS61SLToxcwRZdOPl AwCQ+3LY6jPOMZJNZNuHu97TRm4ZgHkTkkRcMxBzgYwMnGc49Kn8OXVpZanFi6aGGdxF PdTYVUHUMc5wQe3fJHetPTLnSLZH1m2eJDC7R+VPHJ5bljwoTaykEHJG4Yo6B1OpsvtN r/pEghe289pCUhb7hOcsR93qo3dKxpxp9xdtdIk8FrMS0Edw7b3jxxuYHnPZQQSOScGm Xdrq04mSafTYGSVPPN/G1oZBkcBvusOACAc0k17NM0dtd+I/D0jrxHFZMlw/XOCq43Yz /FngY7UFK3crtLcvr1xLcGa2NvYMiRrblDCjlAQkQ+7lWPT61jx6f515dTxwsUkXKoRv bk8EgfdXp19K07uKOBr1H1C4hht7dXe8trZItu5gPmTO4oDwQCD0xWo32i1Sa90+OS2M FszrYxMJY1cjK3CnOZFxnk7iPzouwdtxdGii0qRJGRFvCieU/KrHCw2HYOmHZjgg54zX S3q3jXFxcxSXJu5A6wxTnzJVUsvGwZwPYcH2zXLWNzb6paafPCZY7hQm+JZDmSLzATgd SqsrdBwAKsNe26RSWTarcM4UCaN52JIBzyWJH/Ahj600Jlq1k8m+v7uOZFcRQrLFE4Jy pX7qAcnOTjsBz61DcLLNaI7yCKN7/e+9ifmAOGCr3xu5xTvPQlJPtckUpLLIZkjeEZHQ lkbLYC/KoLDJPSl1HU3mlBXT9LvSm4eTIXtC5bGGUKmHILcZHbleAaAFYxXCarcfaZTL cT7pQZXi2jcXST5SNozkDBzzyeaW60iDyppknnW7dUjVpWDRswQMzFSVGRhjk89ck9aq fYrSa5UQ2DWmoq8JliuZSYwFdF2BuSCMZ5yOOopPEWqPYwI4hEpe7lCAyNnIL8h+mcHt nqOKLiGa1aajMLsabqGlWdtaSOsv2o3Mv3QHJHzSoBtYDBGcqeOabo8OsNo86X+kwS3j TMsMFzapKHJWNxlB0BUSYOAeeM5AqS+vrCO3t7Yyyx2t9MJ3j3KyNG7BjIHz1IyvIBBI rVS4PnSjy0iRJPPa8dCfIEYKoFUlQSz7R9AeeaLgeeQahpdreG41C0v9PLEx5LK6QMeM 8qCNvHHJwMVq6xo93csFsJoUvbeHcYg5wYW+dSpxghSzKCcAgA1paZrunXeqabBbTSmd SXkeAEQuQvzZRyxcFQOuTx14p0fiOw1C5ttStYJbW6mWWOS4hcIxgZ0VS2cg7XKYXGNr HPSgLGaNU1DSr67uF0+4lha0jtYXWDzY3VVRWBOTgECTnn6DrXS2GveG9T0tEvrvVrIj dI4uoor21DMCCA0qcdiARx75rDutI0jTvEVnCkl/YT30m9xGpRETc2XIDAZ4JwBjnpWb pFhr+tRPe2+s36IhKqsrSK8kYUtmP+FumMZ+8RzzSAs3niDS7SXYhsLkxAKJbLSUxIwO S48yMKh6dF7cUuj6xDqF/psEUTxYv0k8uSUkvhgw5wMDI7D1qraC9EkianrniPSLiKNn Xz4HMe0LnO4Ngdh0PWtCHTbmHVLKKXX77UPMnKeTKQduI93mDDHGGJGDz8tBTaZy5k13 xFHbxzC4vZCg2xRRdec5KqOTlup56VtR6BeSaTb2t3YS2piug2ZYdjbNsgPXtkDjFX10 DX4LmHTpdcu5FCI/nopSPbj19gpyO2KZrvhmeytZL5tYuroIQTHIWXcnTcBnBG4gHHPO eKBIbq/he2002lxDNb3XmuXmg89EWGIdN7Agbj6LmmNq2n2UcEMVwbt7XJhSzjYYVj+8 DMMb1wAcHPIpuheG9NmS2n+yi9nuFfdZyzMrybMfMjABf4lAVjyc4YVt2h/sy8WO2klg SSUW5hiUo8DblJ3BuVO0MOeoJIJoArR+JNBlaSRPtTeawfyIoz8p3bmBG4nJPTHQZq/p d5d6h5ttZ2sy2CISqzskcaIG3YUdS2e7HnkE9MSW13qWoWSmS4VSsrTLEcKGiAYsrlsB uD1JXGRyccts5biC9Qrbq9nIrSGW6k8uNsHcAf4JFOcHaxwBRZjuiCWC4vbeWC9aWNXk WN4rclQzlsKNxAABIByM8HrVe48O6VNF9jR59JhWP55oXISYkty+Cc8DPzDoQK25ILZS xuAkllFG3lI4cLHggBCxwMoTwxPzKqkc7sV0/c6fHI07XDWsvmpd/aRMjptP7vYCTnBP ACgqpINAr3KWjifQDpui6V5O26Nxd3N1Gu8tsUCIKc4BYkZx26V6P4b1xobVra8iaC/3 ebPC8iuygqADkdQQODxxXmSXuo6Ylvqmn29i9s/mbBqJnnkQMSVALfc4UduC3NULj4ha zM8ASSwUxZRZ7SBvMRM8JvfGQMZ4HJNF7Ba7PR9V8PRX1u13p9nbeYm6WC2tkWJsHezB cYG4EjHPJY9K4K60XStQvzff2db2UcSi4W5dni+0FujDGN0Y5yRyWyOlWtN+Jl3ZThbi P7WNxLPuIYZxnHY9K6jw3eeGtRh1S8vbW2uo5WeQWl8qOI4FZiAiEcZfee5JP4U7piaa PMtW8PT22oXl7Yzo6xu0kSxQPGXUHJKhucD9cVsadrq+IraafVbm8k+yWhijjadVimYq 5IGACG2g4wcYX1Ir0HQPDttc6Zbyyy6jpOoNbqsjO3mZJHzExtyh7cHp+vnXjX4dal4Z Mut2ot7mxjcOZbYE+Xz1dT90c8gcdadrk36Hc6d8P7WztLdrXYkLwofIt3BLMSGPmSSf eyM9AME4zxmsOwimttfvbS1Lz6lG9z9ohZVx5m7IYO5VMYdlA7qKwrrxpq0ukaXZWN2b OGZBG9zFLvmxnAjXjg47+xqGTQL6eNrFdSlhhnIbUFd5GknYPwXJ4Y88AnOe1K5Vie/8 SWL7bfTdNgivnkw7WMpiRUA+8zZYMAeykDAOOtOH2iAPNa6dGbO4kVRqUEqxo8wzypci FyCD1x3HWtSwvNN8IzILIhrn5Y5reaFvOKyHb5vJ6qAcdBkj1GNXw18WCjT2Wr2aeU6t izSIAPnICjkrluF9CT70IHocVfWCSyyaJdRTLdRsLu1V7V1Ybh88bKpLBTzgqT2IqpqO kabfxF9NurbTLiNVD2Ut2CD2wM4bg9yAfUd66rxRpEWgaZpt3Gsa3Shruea3ZfssbMcC JCOmFAUc87QepqDVp9cu9AFzpt9fSRwqJluZbve5jwdxcMSSqjIPHGMnqKLCbOS0nS9Q t52t7vT5HhuF2M8ZEiH0G5SQOf4uo4960JPDaW8GSbqWTaXhi3Kqbs4KyDHX33AHtmqd rfXVvEl7eapHLnKxQPYQuGz/ABSF0x9Op+laU91d28sWmqttLcW8ZeeR7aLmRsNsyFyQ i8DodxPPSpexSXmX7lbbTTbzi3EUyFzFJJGrtb5PKrGD9fp61fj1W2uE0+2nvNW/s1Hd Qpgti+8jO1m27lQ4PAJOQOTis7ULV7aGNbuRIo3kG0MQxckdQRjI4JyTmm3GmXcGqQRG 4NzEGjbO0xbcZPKscjbhgOee3WqsSrCeMZCbC/njRkW8mtoyOCojAaQLuGOhC1n+ELiK FdQN3PLbwWkS3EdzCCzwOWI2hejB8hSp44B6810dp4Rt/HF9dC31GSySzRFcNAHJ4POS QB0zjHQ1yUtxbeHnv9Na5sdaZ5E/e2qN5YaMkgnJweTyBnp1oKv2O6tJ7LVbOzHkWtyA g+ytbysiKwO4+Uyjcpz96M4PJzkYNZV5HBIks+oXNujpIqR28siqRk4DMpO5gOSRjjt1 zXM+H76e5lvFutQXTdKgt3ubhI0CxFgMISijlixHTmug8S+HxfJDMI1sr6bItmS6SaK6 T7ygsOQSpypYKcUAWDqcEEUNmurWwtLWRniWZWk2gnP1PX/OBT/EOp6PtHmXw+2KqywP FbMqowI54PqD6fhXFjwprr7c2DlmGRH58ZYDnkgNlenQ8+1SReEtZacwzW32ZiXQPcSg IWTGV3AnnkY9c8UC0OjTxhoX2lhbaPcXk87ebJcXV0wJccn5UycE54yPesvUPF1ne2cV pPoFnGluCsKwFxsBOSBuJKcjnGM96jsvBsz3ksL3M1u8IcrMts7IxXuDxkH2qWy8FeZK P7Qvnick/u0j+/tXJyxztGSBkg9/wAM8eI72OFYbGKK1CH5JFBaRepwCxJHJJwPU+taF va6zc6TFMi3E9xdX7SSz3A3qVSPCj5uo3OzcZ5HtUGoaBb6fpkM8huo7ye4SFU81FRFO /LYxuPCqe3Xmta/8Jx20FvaWup3Cqs2NjlXLOzBd/wApxjHI9s0hlbTvCEVvNFHcXjCW VGiQRqVySNvO7BAGcnp096SSwtNL1uCwW5un02aF4Ip/JTzJd7bmTHI9MMuDTrbTtZ0k PfQa1E6J5scaO7B2cKQjbDkYyQQM5z2OKf52vXy2Meu2EMtoQXtLnyBtkYHGQ0XG75T1 weDQIuPIhiS/u4xJdwwvDJdeZkF0BUADJIDBlI7fNV83yahpsEcN7LbvaxFI3RGkMWGU kHByDwAQOepx0rM0LWBe3t2GtzBcMAHVXCsksYyrAnB+ZN3/AH7HrV+31mCRQ+jXyOHG XWe5ZNx6FgO7YweooGhL2PWG08S2uqXDRxlTIfNfIDHk4YZBJ/veuO2KitGtbvX7G4gD Rq1/HjcVGWYsGJ9OSCfX9afbxtETcNPGpubf/SoJm+Tbk4bcCVfBAYHHUDpVDTFFol3d XNuim0uEkSSAtMrNkMeAMD5VOT0G7tQBdsL20juJNLn1dbZJpBKZPKAkiiZyxXeM8fwk 57ZwaqC9u3XW0mihubG6nmgW8jIEUcoXJKMxLMXUJxtAyAcik8b+HHgDX1vAsiWbGN1X PyxElk+hwc/TOPu1i2d3fXGk6q1vDBDYx28a3LuFyXDKFCng72HGB2ApiR1WhSXpsbMW 1pMxaANDcRMPm77NucuevQE47VptJ++xLbPJc27eXbBj5D8tlkO7aWxx8pJXp92rdp4f 0YWMJ07cl1bwJHNDId6ySYUgFCVKllZyNhGcDJJ6ZmvaXrVhJZa0l5ZLZoCtr5FwvlKC SNm9gJBjHI25zldw60htlS4kjstMtLbzIoUuUjjluFkR49oRVYErnbuTaQWODnhu1X9P jh0g3cmZY7JYg91ZvASiHagEwVSygBWwwOeEDccimWSz29sjQmCPbEsImM0ak+W2woN2 TgheTgk7sYPNRy29gXtZV1Cxt7qOQyQ2DCVYlKnlkYgNGOmVKGP0254ALX9nNbQzyack czFC8ieZFEGhUkA4BOCQT1AQ4yrBuKi1VbW6METz3CLazm9VyqkscEAtIpOQRj+EHnrk VSgmgt9Qudkun2JhgG22e7+zypuxv2HJQx5yVHmAAMQCOgu3htjcQ25e4keWTzLm0MEk DQkfMW2K43KzZweVGTg9MNiKqia2Fo0cjIC0m1ZQ2ZlHUgnhtrOBnA6juCBm6j/ZTXiW 89pHPqUmQBCxjJOMbiUyF5ycnpjmt2eG6klmiKG2mWRX8z7PKrCPP3SMYGQRggZHqetZ lvFLa2M9tdXzTCJxPHDCYPvvtDyTM2XI2j+8CcdzSGYt74TltrUT29xvk4LWtwyB3DHH 7sgjdjvx05qiZpbCGDyoxHcmMEzb/mWMsSoX0JyCT9Pet6/1CzsLO3tYTLFEwRfLOGHl bgCBzkHaCRjsax7vXH1IfZbWxW4ZiSv7rLDnPyqDhQMDrngDpQMjbXfEJSLydSvYzASQ 5mYfgxPDD0BBrqp/iJf3VhDafZ0ktZ3S1ufkEj3OVG8c8AHJ7fiK5RtC1K5jWW4njjcn CI5JI9iRwKsafLN4fhunnt0kkibzo23kozD5QF/2gXByRwBigTsdDoVg732ovexzS2cM bboGg8kA4O0Yz2z1HGAaure6Pqt0s0Oox3NyH/e28kyOFChc/MowFPzcqTj0rKTVE8Q2 Edvqd9HZNqUu6KAyyl5ogwRNzJwAQrA5GDjJ9apqNF0+4dNUvY5J70+VGk8BYIjNt3L5 Z4Ax2boOvNMDdvrW1S7ispfKtbx3cxyi8BKDaMriJiQSdvA2544JqK48Q3GlrFfm6S7i hYw2wu4JWDDHzbA3zlgpXBY4HzHuDTJtF1K3vZZdPvdRjhkvzEsyQpLAoB/eFyx+UDOO OOlLc6nFfO1zp9ukCIvllULQl1BwhIYFGJUDBVG/DGaQiHQL+Z7uDWrnTY7q2jdbpNOt YvstnExJ2MxwwcjqBkc0Wuoy2Uuq2elOI7Q75ltnn4kgfiSJmU/KRk4PYdazJI/MkuNP tluLOGRw5intAgJx8x3R5Q4Ofm4J9qsDRxokCahamSZ9yAJ8rLJkHcAOvI/pQFijqWnt cOiw7pEQCVNLWECfHrkt+9X0ZODWT/aM11JesgaC7MvnSJg7nGTnIbkYJ6DHFWNYvdR0 eaP7LdrPpV+PtEFpcossa4wMbTyjL03IVPvWno+rR6rPZLcK1rdTzNDE0kYvIlAGcjeR Mozx/rGx2pPYdzp9KvJdKjjhtbeDVI3AW40i5hWdRzwYGJJZe+xuR2Y1c1nxbpOs6Mb3 WtEs9Rs7cFLY28kltLBjjYvHyMCBwelcBaeJZbT7f9hzpsUkTtbxQAn962ACWzuyASQc 4z2puleJdRk8yKVJNTYIIxcKvmSoAPuyjBEqf7/I4w3aqbEM1PxfqOoaf/ZVq89nprSM 8ieYPNmzwBI6Bd2Bxjge1YiLFGQhBUdNqjJH4V1+p+F4Y40uWgjtpzEsjw6a3nIxPRzE SpUH/YJA745ps2jeTZSxFrZ7lVLgQ/NcA/MNjqhOztgHHqTSGUtMv720ge00TSGmmmIJ kETyy8cjAHGOPTjrW7pCeI73StUkh0WC9unuFS6F6m1REF3FssVGcgKCpyOcU3w40s0l xpsMixzIuI9yybT8jFyzKRgcbTz+HatDVm/sbM2p6ZDFHDbeXa3SX8m7cU3YMSP8uSzY bafQgdaYhkgk1Iae8d+1lcb8oBMQsiqxDRMR95hjIP8AEPxrGtNNvrvxDDEb03JspWmu J1t2aKFzl/Lc5+8QnTGR6V0VmJWtdIh86OLw9MpZ4HhP2l22kKxyP3eCFIOc/McZq1dX lxDGmnQtGQbk3EJvIWiiupUGCrsF++OhB69cYoB+RxGkadcouqodUzPCPszMiltxLkEq GK5yV2jkH5vzkTw3qonH/E0S0R03tLIGYAYyPlXJJ7YFaxhe5e9h+zppcqSKt95NtNcJ KzO3JkUnALYK4A4DECna5rVvBpIuvtSzpZBxEkUjcsz8rkgbeVYkcnAzxQBQtrXXINIE 0HiC2jhj8ye5JuJFjbONq8A5wFb5vu/N9akifXJZrG9tdT065ty0cZSK9QbXCgkSEj5R nuc5xWpb3z/Y4Lm606a0SXO4XUeyJWOBtWUJs24GPm5x2rJ0N4Cs1rcWP2u3ncQQWdvF 87tu3DG0hSCMAZOPvUgEgfXitnZzvZTp5G8y+chMjByCV5O7AxyB2qzaWV3BqUNrI4Fn 9jECTRyJBIkiIHLbshh0zyR1Arp7u1bSIZftKW7W+XlSK3AmaB13EtFwDvUYB2nbnABP SotH0tPE2uJc2V/Fezw2xjMgBQMzhSZVDH5nRTyoPU9QcU7C8zGmOp3tpbCO0zFDL5kK SROGWQDKsCNwOcspVjjD5BJ6ctrWmW4vNlhppt4LhVe0WJnYAYAIYNnBDAg84BrubFDq WpzeWtzPZQCbz3n+6AxTBwCMhWXjvn1HNSKrWN9tSeWGC7aSSOZMMPN/5bwnIwMgbgPq RRYZwug397BLEqXJuIbcb5raQAGFAwHVux3AYU5+bpxXQxTwSLDFc3VvbRmd3kButqhS RhmB5Jxn5c1tXOjxWwu/tK2+p/aF5+1A8NkgAYXjB+7jJBHPINVLV7m31OMWU9xEIdg+ zy30nliQRZL7QCQFVwCADznuaQ7ljSbiM2onjmhvYhCLaVUyxbYMBgwyGGAMZz83FZ+p 6IlzYRaZpDw2NtcS/aAs0Gxpn5ypXPDbdpBHqemKz9X1LUrK5uNTtLXPmQEWtyi+aJJF kVnlIG1kIjZVJIPTGasf8JXbX0rWLu6GTywJg6NHI23JG8Y2/MdvKn35oAmTVbg6Tp+o LZxxzpDGiy28aGVmT5CuCOu/nJOFBznoC7R9UhGry31wtskhYlZpY3lkmk58wyPvEjhc H5eF5JKgYAA4026CPp0UcNzFutfLzsSb7zxHbheRyDgE4PNUR/Z97HGJbcQxzSuVvLd2 QRnJ+Zxw4BbcCpzyOaBGtaf6Xpz3U80a3J8idkYKoKzjc78Z4Qh2YY+6Cc8VYu9G1Pw9 dJFd2lxFC4CC+K+ZHPk53CRMADpgNzjtxmoLWa9sWe5vHhRJJ2gCuVSQg5Yx+Wf9ZsIP GPuk9cCtGLxVeWGjXeh6awb7ZC0atqTMEtQybSyyKz+Yh6rtAAz1oHqYEuoaVKthbWtn Dc3s5eYpcSOhUMGDSBlPBARVT064rQk85RKjL9styiDfPbtKBJnHyj5QM84dVjLkYycA nO1uXwnpdmloJJJ9StraGPfpXl4uHUMAZXbcCoXB7Md3QYrM0q+1jUnuzp9gXMcASP8A 0VpLaAM+CX9TjIXOeTxjrQBuXE0ljpUf2a3S/BkyvmyLM7Bf9ZG4O7Lqf4T1xx3A5ybx DrviZo4NPgwvRIrfIVT7kkKv6V2VzNa6O8dvJq0nm4QbZyQs5BU/KVOdu5uFcNnH3gKh W6heCcJHcKDnfcwWokAbcq/6wyfvCQTnJ3ADvkUBsc5YeEb7VitxqlypWNT/AKtgdwU4 O5yfX5eOM8bhWmkEFhfPK8aHcpUSWh+cfL98hCQ/fOwkgDkY5qO8aadpJIrVGitnUIn2 VUG3aDnZkhSCeit/DV60NpeSRS7jArMsgadAMEA7imf4Rjb1HIPSgLIiK2ohVra+tltn YqLrftWUdMd8sT26/SorueSVLm0c281vIqTQyLtDKV/hI45IA/I0mo2tpJeXs1nOVuXV WYQkJuyDjJzhu3HODVdlDxwDUbeJ4hh0ZHwGXoGI5O7OODwcnHpQMpw6XpXiK+Bub+LT ZVG020k6RyMiKNgQEkYI6+laN1f6fc6h/ZujR24S2dYp4LqIlRGGwZIZUbaTg4wR6YFV L63sLKJZbqy3QW0pYBbReDtPy4zknBBwygA81HbQQw6htWJLS0kQ77eLczbiMpuXrkMV 4GRQI2/C3jXSrO7hs7LTLqCMSZaM2Y8yXaQypuSQ7RuG4jYeR05qbU4rb7TY6y8kMNpq JEl3ZomDbyAkgEhRgt8wEZ5HJ5zx59p2msJ2kn1DY9u4Zmtn3SsT93aegYnkZPA5OAK7 jSvE6Wsci2Ua/bdTMkW5rZrh5d5BYqFwSx4y5GDheMAU7iIp7q51u7meWxntxcbVinwj KDjbsKE/NweRz0qrcaQdNha6sLtrfe/7uJlZopQOSxU/dwOhXrnpWhrug6toUdjexyyW 1pOq+dPBAHnjkcDMTF8hRnA4xnHPNVwzxvax3Bd5o8tmRThs9xjhfQDPGKQ1Zmfeadbz 2It508qzuZN9lOWACXGAXQHnCsDjpwR7VUlktbPXLd7m4SJIIikUAVcjcrDLMccAng+3 FdtqrRSae1tdCIq5VEYL5jJ0JkAAzuLcDPOB2zisS4bS9aspoNUEbPaBYzPcoYGiAIXz AU3FAe4OVBHOKGJas5nw5b+Hh50/iKO4uYwVWG1hldVYk87iinGB7gc98YrV1DWLa9nE MV/o/hu3YC3Sw0qEySCLOR5smNuRnJzznNcl9qlt3MLDGBho2Xr/ALynrXQ2er6BHbJD NZXEfln/AF2nrEkj5xnPmA8D8+eKYI29MkTSIrnWdTv9WMMUY8p2mHnNI/RYxjCk/Keu AM+malsPHmlXUMdrfT3yeQxlge90uK6RW6nGxwyMCTgjjpkZrUfSPB/ii1tbW78Q6jZw B/NsoRIgbGzHz7lOdpJ79znrXH+KfBc/hK7jkiuzqemTA+VdpCf3Zz92QjKg/Q8/pQO6 LF1B4e1Ah45bVt7Dyw9hdCYSEnGURtrBjgYBzzTLbQbJZryaew1FWLN9rj0uQCeJyeVS OfbkgkZADEcYOM1B4a1Q6VexXaYaWNTtUqH3bkYAEEjOc46j610OnpJql5bXWuQrILps tLLFJAty7IV8uJypRkUDnBOSPSgTMCS2t7V7KTSNc17IUG4hvYo1uIW42mOIkFlwQTjp wcmtzUYPFVvBDBcw2Op6RNaKJoLq5WQXDcs0gkiyyFmAOcjoMkVJr03g+GIWkcsFhGUc S29pK1zhiwOQrfKDxjdtXjpkVj2fitfDDSjS9be5idSJLW4iYxThVznOS6Pk8E5X6Ciw am7ZarfWun2DSyyaVBdeZbw2Z3yiBsbN6XPzBUYEABwep5xzWD4jjlnkt9HltWhupJTd X73k8LvEnARQUHyggE5yT8wFTy+Iw1y882nTulqSzRC5/fIyqVUnY2Qi5OCMgkfMexwJ vEcF1Aqpp0U0JQZEqK8ZfBLHGAOSc/gKGK539zqniDT7WOGbUpda05mDxJfRL5xjLYCE O22Zcc54Psa57WwZrqwutPj0q3txOsbJpSpDHgZbYQAOg3Zz1JPbFZMNh4hiilvYtKhs ILUFtsk0cZUYydkbvuPB7Cp7TTPEc2YlmWFxjfGrDcuRnkKOpx060h6bnY3WnW7CF7CG 6sri5yZ8XM0kUJYj5oo2wnQMdpYBc8k7cVnaPYaPp0VzOdUvLdzGWhhAxcSEDdI8n3QS MAYX7x45AxXMjStStljjfUZbS3PzOAJAIF3AFtmV3dc4HPU4OKS98N6nbW8t+0/2i1Dh Gk58xo8j99s5ITvnOe9AaHVWFzpWnWwuR4iUyrE5ayuMpMCNpy2Cc844Hp0qnBq9jrWp /ZVuIzd3BCxSxxMhQgrtYbmLOVOWOcnDOfQVjQeHri1a1uLnRrPUoz+8+zS6g2JUIGG+ VQdvIPBOO4wa2fDs0VmUP/CPvbOI8m7hsxMsoI4COudq4x0GTkgnjBAuX9Vv9UuIpoiV S7aAxvBLGzgkGNsbs5CHYAvA+/n1NZave6haTTNci1uJkZfLQkrGkjquRj+JVRhj/a9q 29tm00EC6nbi+dNssDq0ckglztkKvjIDHt2Y56cU7dvPZYbq2WNZN8VzEMy7CBuKAjGW 3HAJOSScknmgBY9Jkj0HT9Qe6nuLUJslvcqoSHzBJICAMglI0Xk8gnjvWbdaB/aUVrIk LLDc2cl7HeLEGMrvIWKOVGeOAvsa19Cew1eKKyjnvXga2mS2t3ldRuwwCSDJYE475xk8 Emq2n3DraxbrKDdpUn2KWAmRntgwwjK67XBEibG6D5ufWmIwYxfaddnT7+1MqgBRcZDB U4xhhwR6Z5BqfUb/AFBIjcLp8cs24Ldq4I+Z+EnQDkB+56giuj1SW1ttMvg0rTOZlg8u YmRoMgFgpGCx7hsdMCs+4e2jt5LeN7q5uFsyyq93IgjyqkAhQOMsMZJ6fWkM0Lq/guZ1 sIkuGvbFVWO4vlkVDOD8zxNkDPQEvgDHBwAKqWt1GV8q6v0WVWYlfKLnzFGDujjRlVcL 5h+UZMgPUZqppFt59vcJbw2txGIFWSO4RftMcojYYDAZGSwcNu5wOtbltFd2t/b2Mlo6 wopUxyKqNCu7cpTK5ORggk5z0wCRQO9jF160triESxSLKIVMp2xzyCd26qpaMZGTjAYY xnJqpY3drDZwvPf6xpK7z5NxazSDfKBhEAyNrc9WB4PB60ut2mn2kkb21zPZT3JG6JSV OS3LlVGw/L12FST/AAjrUSW2uST3ttp96dVW1KrMWgyCrNsU7Tnr6demaBM6WPQ2vkkv rm+kklsI/wDSNR1FRKXncD90gX5pSq4B5xnA4wQNKLwhqt6GnsXS7iiTLSwXLr57/wBx S+0PjJB+bA6A5zXF6dqN3Y232iXTUeW2Gy3e1XLFAwBGPmB+8xOcdfeuml+Id95S276q 2mzPCQYjaDdGDwCX3NtIHQbcd6Y7djGvRqWjTSvrO+y89QFElsFWEbX4YFwQNzKAy5Bx iqMV5cQXMVqt1aXEUih4ZvKkdXzn7uHyOcgntXS6b4p8K6FaT3WoeEL7W3lIEupzzQ3j PgdHLvlB1OCAOfakuPBtt4kEeoeHrbw54ZhmO/aNeEsbjp/qViKqen3GFBLbRiWi30V0 zzJYb5QgaR4JCSAxKmPD4PLAHcMYpwsrn7WXmlgSO1RS0W4jy4lcKwYl8YznP0q3qvhv xTodykpg0u9hXdsurBzKrbvmJKllK42k9CMqKz9O0+62XMCokcjEwym4i2yS7iM7WZuc sw5/GkVe5qaiJboraRXJhzJIkkYEYMic8l8E8+gx1zVW1t4JL6S5URx28SESPyCuzBPu xwAQO+OSKs2cl/aX1tJb7G1FEMIjKhykqHDsOdoHAOTwODk1QsdOjtNOi+wX1rdwzJ5j JMDN5u88vglMAkD72WPU7QdtAbDbiS6js3tbPThs80NcXO0RRqxUDdtYAuQGPO4j73Xv lJDJHFHNhptStpP3kUM6lkD52sRg4HHb1FdAdRvY9ySw2IuZk2JnR5nYZ45WNgh9ctkC sp4FN+9xbusrzoxdktdkcRGAEjIcgc8Y/GgR0Oia8z3C6dc6tNNEwCBIn3GHP3jtcYfI PTJK/wAOKp3Wl21tq7HR7ya5s/uyyMqzOh5I3MrMq47KcH2rjbO7tWbzBHcRSBSSyvgq Qc5BByCCOvau50/xxealo81jcW8Oo5IR1nk8qVhnIJKgh+hHQEUA7j7ywuBZFUvLm7nW D7RPtiQSRqWwDvC/KOg4561n3t7NFqFkhkhaDLW8LRguxlY9H5yFcHB4PIB9akltb28u re6uroJGE8sbIUj3xD5gDtx5inaOpPpU66SttOuoLcxmOIGW2aSdZMsVwpCAjAyc9Oox Q9iluXb2zs9Tliiv4tOwfmka7xFGpYEZJXDDkDkc+nNcnd+ChcPIdKaSSMcowDtEwIyM SEA8gEgHnA59a6HT9cW5nkk0u5WS6ssNEFjYKRyij5/vEkjjk5xgdarOtysMcc6XMbSN gwzu+MtGU4XoRkjkcYNFhaHFX9jf6b5P2sbEcfuGLhldfUc8fQ0QarqVmrrFczxq42yK WIDAjoVPBH4V076pqMGnz2F1JHcy2cZmhlibCEYD8qccg4/D0qpPciDVNZ1a7hF7E0ht oBIVdXcMAGGeyhDyP8aAMRNWlLLIIomYdR5QUHgjB244wau3/ia/1WFbfULzUZbdMFLV b6QQJgY4Vi3T0q3p9hpi6lYNcaa16J4llmtYyxDszNgKoIOMbcgHJOa6Obwl4YYW3kxz RG5EmBPJcRBMsChK84IXOEPrzTEcPZvoKKRdaZeXHYf6Z5YX/vlB/P8ACtqPVPBytGre HpYYkALgSiVpCPViwbv9OnFbMHg7RJpruS5nms9Ptn4uvtOTKhjEmSCmF644GfxBrOtf BdrqNv8AbLe7urWyliSW3NyiuxDMeu3GRt284GTnjikIy7O8tI5w95eboGufN2JvWRFA IGGXocEjPH41u2ficpAbK61RTBICBLGpUovzAI4C8gKR8y4yQMr3rI1Dwf8AY5vLa+jY eS8wcxEKNpAweeM545+tQ/8ACJzMbpbe9tbiS0kEcqIrgqep7ccevp3pjJH1vU1AhfUb eVFRofMRypljP97CZ3Y4OPQVbi1uwijuBdX8twZGVlcCQk8scHOBkZAHXOB6Vl3/AIau NNhSa5mh2SY2PHuKnPP8QHPX8j7VJbeGVuVl/wBPiikifY0ckTgqeMnnqBnnHTv60h3J rfVdHsL431qt01yQwUuqJHErKVYALyc5PX1rsvD/AIlsLeJZbKB7azuFAS3Un/RpSArl SCuEcjleQM8YrgbvR4bVmRpxKp5jeJsq4Ayfm2nHt1H86s6j4d1TQIoLhZku4Zk3DyFO 6IgDcrrzjGeo4OD6UAdnb2tjp+p6foAW2vdLmmzZlzhIfM8tZU8wNuyiowUcHYc84qW2 F54Uum08T+bcRNttLpH2BlTduVjICvynOfvY3sDngVwSa9vt2tb3zHhODtVvusMbSpzl COcEdM118OoQXWkCK4vra63CDydTuuZbIRn5SqDAY9QR8ucknPSmI6i70GLS7bTobnWr a91S9iJVCPPQxBgA0RfLll3E57/NwAMVzFyrWN+ZY3UzLJiaC+B3AtGqnIfO8NtzjB6/ lZ0nVLe20K5htbVftsLtPfXLBvMnIUhZA5+Xac/cUce2cVAfFtnYW1vDNLbW81/pCXEk wJkaK4IUlMLk/eIxk8DIosAmsahZ2EoZQ9tcLMMvNH97ZwG3FC3bgk4xxUEr2d9qmta7 eTT/ANkX0ckLJGku5mcNnHGN42qwBIGTmsS68aXbQJBFK11Ksflia4AdicYztIIJ6dR1 GeKrR6b4i1iL7bcyT4QMYxJI6s47lewXjAGRkjAFIC9LqF5fIVKNArIAwY7N2B1IJ6/5 zWnNqemQ38S393Hb2NkvmeXAx33UgKDaxHIBCjntgYFZGnQiRE+z6VBIwZTJcWhZzHl8 KHDMSpYgrnpzWtbrNeXvkamv2gsrGJ4I8LIvOd/cYA9OuQfSgENEUU7R3FleR2OVDWUz bmcxtlkU/wDPRAAykEZBiJGDmrGl6xHeFVRre1ubjIS4EjiO7JxuVZGOMjI+VlDKfUVJ ZhrXydKwXgKMllJsBk+cH/RyTgdeYye5K/xc42s2aQWMKW9tA1rDM/kxvHvjnlUjeXB+ 6cDaBnJ2v0AFAFm10dtOkjeW0vDLaM00zsBKxIGUVskg5O0Hnpmrmm60+m2kUh1mKO9h m82aKKRH+0eXIPLLouT/AAgjp168msm2NpZXTadIsVzfYSSKS/hWRVJXIjG/cV2njPfn OOK6KeYXV7bMvnQ/Z0fzhlhEQAzFdh2rkYOcA8AdelA9bmakSQPO0kGb0MFkWNymwMQS XRGAyRgDqNo74OKs1uyrYRS2UOoQxDdPeTuYpmQvnBIwWIXI+oq6sxKBLNvsk8lrE8cD GI78uP3QLjcNq4POT1A7VZe1eW0t3tLYeRcXj28Usu1CDGBuOT0jO/1ABUE9cgBs87W+ KXBlhhezk5KoHYlR6Enk/X2q1eWkLJBfXenWrNdKXjlt5VSRwAMkryO/Ug85rtrmCwvZ 4tKvdKkdlZsvIjA2wUkEFlIHU9mOfTmuQvNJewh+y6jKTaKTsuYlJ+zSNjJxnJQ8ZH4j mgLssW94NIkEj2NsrrGuz+0dOCEK3IImt/LcZHRsE1sDxObqG2jdVuAZlxCmpG4DDGMK 0oMi9M87u1Yd3FcR3lteTPBAkrxC4CSfumCgbXQscMjIvAznIIxTZ5LI2qXmpwWtxNd3 LfZ0t18uMRqx8xiUwD94KB2wT2oA6u3t5LVZxACQjAyXEZOJS275dpHKqQPl4JKgt2xS ttO8q5eRbl3ItgzRcrGoB6gZ45OcHkVntp/hqScpZxX+lyxzrHIkV0W+QHDspbpjGRkn 3rYvvC2q2BRtKvtRv7VlKyWer3CLJuyPuMjY56dOMHJoDQsXdpE1rbJqcXmgAMU+1IY5 fQ7VPOMj5X4+tPuL6ykllD3GnxtKVV1iKRRomRwgU4x1HHqawoU0i4mEEcVtpWpQ8vZa yu4SsQejP8vXHX8KlluVtpGtNV0XSLXyonkMlkizLLkAZx97gkYAwOuM0BoVr9ND3SyR +ILe1ldjuijlULk/xBMn8ehqvYxQW939p066e48vDSIqDy15yGaRiFUdDzzW1b3MyWkS 2uoILNQGMkQdI0zyA3y5Dc/dAZuPu4qS0it3jkurK9EyLISxjtPLRnIXIYysTgHBwUHX IHoWC5GiXUhE95cqDOxaNP3sSOByQHjw7ZJwNpxn6VeTT9MFu8f2QxGZP3iWxSNlHGUZ vvdepY8/SuaPiO+W2e8JjS5WRIri1liV4ywZtwO7LSDAHBOBjjArcPifQ7xI3GnyAYaQ bZhCoZOQm0Nj5uMAD8aTGtySy0DTdJKxQM8we4WU+dIcSFAwXsufvE47EA0CA6fugtrZ VClJlijjUBdpLbAOAc8AZP04FSm3Jgt1fdEyBsSYDjBPXIyF7EZ61SutRvrSye5gazaX ZIUb7GpcFWIHRtucd9ue1X1JvYzNSmmtbu3vvs+2C7AhEMz8MpH3eB8oAAGB6e9ZOpsB dR2CxiGCxPkKm4tyPvHPHfA/D3rotRub2OzkhtIixTZFOz5DhWRTvUqRnaSR82Qcnjis ufQpbzUzcSTxWkNxJ5qmTJ5bBcZzyFYnkZ6VIytpM13HqdvLC3mTpjyhK77QQcKMg5A+ leiyQ65p32h5LaK5iuFHlwgmAPNHzuJYsSFwccckAd8VwkFu9rJHJ5hIU4RoAMsSeCrN 8h7c5OK2p7O8eTV2NgJLyC2ju7mbVLkndC2fmVAD5ygDIDkDjhV4oAJ9QFzLc/aLWBtM vLmSTVPsyKzRuQFVAgK87RkZx949O959X8Om2VppPEVqkCmK3iisEaLYudq5ywHXnnqT z2qs3iHQTdO7L/ZLDbCtquXkkAyW8xfLK7dx4TgqAMEVLHe2TwLFH9jZ2KgeZC4BH3uM jcpwD8pYjBJBp7AY04t54wreJYo0aJfMWVXhHmEh2VvMAGM+57V0Ub6VcpLdRanaAPLJ cFIbuJ5VJ3DHycMAXxzz+tZ08dxaeZO8cZMjKHfzNryDP+rWMsGYk8DgDOM56VqS3lp5 awSxbJYHM8sMFiS0QPSMNhd3bKqfXgUAZs1nfXOmra6gGuEunRBbC1cOCZCZZFlzhQVG OQcE9BVXXNHLTLCk5gvYITPMpuFMdzghVHmrwZFXcOuTxkDms+a7Z7lpIdXvLWKJfJih vdOlmR1wqFWIBxuYc85ya0Y7uHxRo2sySafCni3TrcjEkpX7RbEbQyg9XQHbyOR6ZoEm NuNQgv8ARJLyG1PlmNBKwj+WEEjj5VGAf4S5x1GfXT8PXglF7Zxx3+0o8rT3Lb2dwp4B H3hjJA5wcjAqEaN9nSzcmG1mjWFAzTsk12hGWXjI2gDAz1OfSsm91DRtNvlvdOhkV1Xc m2do5ASeVk8sIGAHQ4DAk5zSGaN54c0rVb+3jiuhbyNAgfaMO3JJfBHzttPPoBXNT+Gp 7OeONby1a4kV2Eav821S3zHgrghCRzVptZvteOqNBE/ntCEitoPmADuq555JC7uvrVmH QbxNQRriOJbb7BFbIvmruxiNZfl+jS8+ucZoFcwruy1WwlRbmCWJmGYsENvGAeCp68gE dR0OKWS+vXZYd07MBl4pQTsYHng9OMdea6uy1yxLxwPAYdShtzdOHULvDqJmXJ+6csRy QBU9rctI1xYam92+m3ebu3nVla4tbvdyCpbJDbtvUg4yPWmBxEOq3cEiyoyq5+46oo9j g4/lWrF421iG2hhN68iQrsjjkCsirxkDjI6etbWv6lqNr9uW5hRjbzSxCNwNisxAyVAI bIyD7jjFVItOs9WsIZ78R/bL2UmKSJAmyJVGQqqNvBIGMdO9IDL0HxKmgyyy2mm2++aP y5A8jFTnPOCevJ/OpofEW8GO90hdViibr55VtwOAxfaeecbsbjwM07UfB91ZTTf2dcwX EaR5mUyLE8Py7sHcRu4XOR0yKz4tV1CxlhhvFyluSyRTjbg/e4Jx3A6UAbNv4h+0Xps4 9PeCN2UIksry7GX7ucjJO4Z5744q9Dr+nTPJbTW81o1kuGmRA7NFF0DocLIcdCcMCxww HFRaN4nfXb37LqEchjkibzD5rbQoyWwM8HnJI67RUVtf+H5NOuZXBPn7gXcMrrExUYyM k84PJ5x2oAtapbWPiNrZ4JrSF3V2txFJturgsw++rLjI27QvmYyD6g1Z022vraM6beQN qcIkYRiaAShGwRuXypH5xkcj8uKwY/ByXdwiWszRNJarKZgQyLIWxswPmAxg5PrUAsdZ 08X1nG9tqEVuNkyyNuj2HaSyq5GR2zjHBHagaOwnsBJfQ7LC20q/ZmVd0TQQ3LZyhbzP 3hkPHRcHjkUPJHrYXS7ONbH+yrSZbrUZpREZZmI3wRFcgsNhG4dSO3WuLtb230SZ4J9K lsmkX54YZGjU5H3gpzg+4xXVWPiu31SRrK7uWtNNCjPl2oaYKDnYhGRHnLEvgsT3HWgV maNzHBo7jSX+wQ3EcaRGziEs0o+XBbAy4Y85IA5PvVO/nsW4k22ERXBa6in25wQWO5O/ pmugsvEcmg262mj6euqW90smIbeIwtKCQQ8kq5UMAuDvYud3FV7XWdWmKQ392lnpr7hb 22mMQ8so/heRzmRQMhieScdKA1ORTRzp/mLLC1xokrkos9q4HH8SkjaBnsTjHOay7/TY Lp7WOzjtrmNLMGJ1DiJhuY4Dl+OW5/HNdjezJbRNJ/xL0SZ5FgmK+UuSduXWPb3AwWOS PXrWHqYvrDVDKl19qHlDfZkNEY9w5MUm4/N34Jx0zQBA+nxaXcB9QmeC6udpEEe7cXKb Wz8vAJbodvYg108F5dtcMLHUvNERERjQbyHUgHKPh8gdWXK85JNcpZXDTtctEpurQxmb O3M0cqjLeYD93p9DxjoKsanpkqXAmt3NtMbiQK0SF0CvjJbqQPlA455oDQ6W8utK1WON tfubU2xYJtKxSGSNc5VGZsJ8zcsDuyMcYqpqXg68s7dJNC1P7DFdSYisJ7jzg6gEgCQ/ MhJAGASMfxVzmqwNcaRGrpEY423mOAf8ejHdvcDAOxmIBGOOtHhjVdRS4tNK/etH5zPI 0zZSNQFYFSewAbpwdwoA24ZbC9eTSbpr1dQU58oyDbJGVBPkkfMHB+bHu2K1/D/hqzu9 StYbHxA2pR3iERwh/PMD7WLeZKIx2BXB5Ge9YerR6KkPmSf8fDShYI2UecxTGPKYFWUj OOSeOPatTw9qWsPAL3TzLcpC7edaNOIZUbYUIAB2s23u/PPDdqBs5jxfoZsXljVcTeeZ ZzEGkEgGVWYd9jcchcZz061yU1pNHAlwqM8THiWIFl/MdDXt0V74f1Oa/utYheJWnRbe zWNjdpiIIIkRRv3EBTleMd8debfw3fadJBqFvaanaKrFN0xCrOq5GGhjZ9p56HZz3oZK WtiydOvLqxe402OBY7Vi88ZmCSK2cfdJycDPXsBVO2tLr7HDbR2/2u5+aNYUlVR8+f48 4HBzk1m3KeK7xllPh240tJASLiTTp52A+kanHbqKoTW11FfrbXXiSVbVyPtE0kj2eM4y FSQDJ7c0+twW1mS2btCL1P3d26zJHF5tx5iSMXy5YgDKLtzkjq3vinm+iileEwM06s3l BY1CM5PBSJiQqk87ny3TGOlD6HpAu7YLcajOLlm8uU3APyBcsQVxkEkKP901PdeHJrL7 aY/LuLEMFxLZtJzgcGWPDr16gMPXnNAGdaCa61G3a8ecMJhuch5JkweSU5d+/GMdK6u9 1GC5fyrKC5fTrWAoZJ3O65kViVDkuSqjaNwbGeBgDNcsHtZLiCa7lnt7SX5Ck7CW3cjG cyAgc994U8+9bNjeJ4ftrd44b+3WBgRItuAlwACMIyOcAkkjmgeprXd7cfvrgFLi3dsA wqW8wsTjHbPvmogSZlV54NzTCG2dpDKVIXcTtU+mAfpiqaaqbycyxeXcmOQyPdNKiM23 oHdvv4yAchxkgYJqzFeahb3E/wBohBu5SY43IlPlR7S5ZkCghT34XOBgYpiJ7vz7CEzm MWxizJslk2JG5GBiT+8OeMg5PI71X0wzTac3lweaY13CaV/9Zzhju3cDJPO48+gAFYni DxdJco5XVJUnVsKtoVHmcDLPkD5Tjoc1gy32s69+7yLmOM+YUjWNFBYgfdAHc9AOM1JW x2UGoLpNjDHey20NxG3zNDKZXU8HlkyOeuMnn0rE1rxDp99E8JsBdCVdjtIRHkYAP3Bu AOOm7HqKr2Phqa83S61qlvpkER+YTXCB2G0nCZyM8AdOpFbem6Z4WSOKcWs90iO32jbP 9ollGGx5fyqExtXJ25O44IxQBy51C7uo/s8URSNgibUUhcgfLlu5wCOTk1o6V4Xtryxn u73UjbuiqIIUC/vXyQy8kcgAHj1rS0D7VpE+o2K6jBHp97cPF5ZbLKUcqCA+DkglRgZ+ lXNS0Z2tkltYIP7PSdvNZyIn81lQBlXdkYYEHg98+lMWpJoAXw5cGPUV02+tt7t9ljcP LCpb/XbQx+Vcc544B7czrbqt0jIse22cMnzLI2RyOhBHYn29a5bQtUuvCfiOFb2aOS1k k2yyeZuTy3bBcMMcHGT9K6/UrF7C8ksVkUeWMxyEjBjIzuB65x3/AK0g9DJvLey1OVLG eJLe4uVlW4kBUSpGEXcA2DuwQuAeo59qxV0zVNItJbnT9bDQwtlrdkLKwBGGUfdPGCeP l71uzxImsF1VBKtqIkV2yp3HduBOM4AGOeoOaXxDp+qwGF/sou5I13G3ZkR4SysquNr/ ADqR3BxkexFMDnp764hV4NY0yTy2ZkkuLc7kc7vmBJJGQc9CCOMirmgyWkpt7e01OKRY lZQJVCMgZ8kgHHOAOQT071pS3NnG6q19YSxPcO1qxuVSQtn5WdG53buScc4561n6VoWi ajDcW3mreTQ4CTxmTc+Qw+8AB1xnIIpD9TqZYWvNPuJJYHJuN+9XOBhjgc/RTisq7jmj aSONLiWBYo7HyoUWTZvOd+G9F3fi1U10DV9Ot5LLTNWG+KVn2So2JlZQNvcDBVhn/a7V SOv3MWbXW7eELI3mC5sZVPGAV+7uII45PY4xT3EdLdeH9P0bTpL5jFFPJHJG9p5ZWSIc qzc/wk55A+XoehrlL/RoEgWwileCaK2R7jzOUmUuST7EZBxmtm41+DUNLbT5YzEGcSrd 3lyTBKxILfvRnaCVztfHWq2tW8ylPtNzpUqgAefB5pLKygAbiMemfzoYinN4a1Ge2new uYrnz2WZVWbYTH84XGeOcAgA9Krm28V2k8kU9nO13LExEZaNnWNXG7KAkgZAHAH863nY zf6CHlt7dh5tvJBK4YRqgXZnaCGGVJ7ZD9qnn2zQTw+Wght1WGWWLavmqeH2lT8vOQRx jIpFGAmp3Uxa2uLFWW+ugjmWEAqiKFJOFGSM9e22qKLokq2ggivYheTkQhZQ7eVv2qTk cknp9K66x+0X0kF1c3Eb31uhNtJbqIxGHwMbA53gceue+aTVY9JNx9l1bQpo5XufJQNb FXjxtIONy4UsxGfduO9AjlbYtEJrnTdVntliuEiQSBleRi3ygbcjPc5rQi13VLB7mG6t be8jhkMdwUAbDZxjeh77fXnFbi+Ere5ZJLW3a0eC5Z1gtGEsUbgDj5cnjHcA57VU0Tw8 VbZJDdoyXfnD/R5xuxzGXLxrhuScetA76jbLXtHvrqF2HksAFRHc+WGyCp5OAM1VttKS a4nuZp45lmZWlK3Aly38XIOcYAxkAcmp9R0nRoY7u5ur198kjKHuCrtG+dzfLFzuwfus F4/OqEXh+2knL2epS2kyRK6eahPmMQSdpGCvbrkjPPSgNGC21xeXd9fQ6hBFebiyxs2U dSQvlEDOeMdgAB1rZsLifUC8Mlk6TbQrQySEAEZHysc7h6c9etc/qMOqxMTfWtvqBjHz TxfNIgxnBdDuXjsaoWt3psjLMl7exKH/AHkJEcy++GIz+YNNCOwPh260qSZ737Ve3a4j W7kXBgUtuIwpHUHqQRjGMVR1GY2SpcWUbtNNKkQEhHQMC6AN2bav3cjv9aURS6jEFn4h aE4yiGUxbj/dKuyrn3D/AIVoy2N/pMZaQ6jqcsZ2orbREmf7rPgev3RJSH0Kd3Hqt9q7 TaPdG9tL12VnLrttnwQzDrgL97Iq3pss9heXM1hbPa2ltB5Ts4aR7kKD++ZAc7sdFHVe pAGaxZ9V160tnW509obHcUWOS3+VAw5BbaOSO/Gc0W3ieK3hMT2KZI2gpJswuc7ccjB4 6DnAzwKCTt7W70wSJb/8TC0ecCS11qGXLy91AK5VVyf9WyhevU803xXp+u6zoEFjcwx3 UkJFzbarZb9sYBO4uijcjHP3l3DjtXMWHiG2t/PhWSRLeVzMLdkyscpz8yDIGD3X8sVO klq9s9laeRBaXTnzshQI8+gJG3pwVJ60PYpLUwtT8U65rB8tru5aTYYmKykNg43Dg8dB nGKt2njbUbDTIrFZJZolBjEc10zLjHIwSeD+XHtWrJ4Z0OXUraz2Tg3AeecwuQ4UAdMn CksSOeMA46GsebRbexaNw0U9jdSskcob95AVOPnHdenIp6iRoaVqcN3aLDYLbWtxDhIo 5Y0k+zszf6tSw5ic/dbOUbAJwRVi18V3l/dRrM7qxuBCU2bWTdK2QV9VRMcf3jWDJJPp 7yRny0CM0fluwAaJvvD1II7jvj0rWhspry4h1G0Z4r8Y2Mjq/wBqIG0PsGZFYjqAjDPO RQGxoW19/aMIluYzHBdO1xIhJXcIyoQOcjgIVLAg5BPpS22kzrGbyJToMzq0qrYyMsCs DwGhfKsMHkjaSazLXT9SgsriK2iUXCSK0kSsj7gOOc/MCMjg4OM+lSSWUd9LazTXD298 reSkMW65wFJ2swwAhCjk5Occ8mgLMZdwWKyyW+q5nZz5DPo8oDsA+45t5V3AEoQWTcKl iv7bSbf7Bomh3d0rwgRPPfPMpLEb8IFXy8jHHIO3BBGamgRJNTs5rkI7xySMt0wYtIFL EZUdCWbA4FTFGMENrNGxjEaxOwHG5SQd3frz2/GhIHZGXLoDXFjbLapp1heyLskilto4 493JyHznOPXdgjjHGZNP8IW9us66nfLcoAVMdtG4VW7YJwW7Djv64rp7a8gWFYFjN2I4 SDCLopCrnIG5sjp6DJxke9Z8lzJp1ikEEA1OdpcosMIijRigJCIM8AbeuTycmgVjDtNI 0TUrprE3959qgfycCZRGEzg7VCHcemcsOlJc+ELG2tmu4NauVRARvaJVaQqpJCrkdxjO eeTTtQ0651mRbk24jZwEBt1KmPA79+OP/rUs93f6ZCbbWbNPJzi31EZIDbTw3PORnrg0 DBPDV+YsR+JHSQbTFHNZEBskdGVyRjjsCatXB8S3U1raWN5FLbXkO1bS4vE8vzW4kQHJ XJ3ZBOM89xU+nJF9jSa3limljiGfIKKg2kEZL5G4kdMDHrViKCPVop7ecRStJI7tLFB5 LI2chxggFs5+ZQB060DOa1bRdcDPb6p4Y1KN7WD52gHmgRDPzFhuyo557VpS/ECOS1sF msISbWBYEupXOZQvTPON3Xpg81rHxJqRtLSw12O6eW34knJQiSMlQS5Rj8pGfr6CmS6v o8N9erYQwSrqdyZZ7W0fZGAcEEO3yxgsvIzxkgDtSEYltPfapdtu1eK2aXaI2V8Myj5Q okc4HBPTrWtbpDbPp1tdaaJVRGePUJXWTedjArtPUZOQcjvzWXcWmntFEstlHHczgSyf ZJgfK3/PgqABn5gMHpgVHbJcQSxPpeoPLD567be+ABjcEYGASpGSvYdelA1Y6Ozsopo9 QbTWjYw/6+KTB2FTyWX0xnPOeAfWruk6XdWs21rk2KyIZcXEhhjkBbKndgjaeDjuTXLx +ILq0vre6vdIiUoqJMUj2mVAfmy6HIYjPOQOmRWrpWuabFf29xaXsggjuHKWdwxDAMMb SwJ+UDB24IyOMUwsy/JZ3lnJLDfRQyJvaGCP7UsbysMljt+YrnnBPHPBrhbTSrw38U1/ bstsoDTSMgMZRV4GRxztAzXeadcWd6t/cvDGkk0g2RRp9mSJByWOVbrjJbHc4BritSbZ Y3F45nnilZoXVLjcYySCU6NgcDDHHp1FILGxeeGBp91O9nfDS7iO5kiKwkvEwAPzGPlt pzgcEdeKyI5r3RzPbahp8UlmZsXCwANb7yOoXgo+O67fcGuw+xfvUksyJHLkecSB5h3D AGTnqGGTgdcd6426jXUI5bNZUO0pNlQeGZfmGR7Nj6g0COqsprTWBHcadN5yGQxhB+7e OQ4cgdAfu55K4z74p2rQ3KwyNJBqX26b5QsBiWMhBhsDOQQGBzlscqdynAlnhtJjb/YU tnjWF9zQSELIrgDopG5ztUZPcCsOytNasWS0M0OpWhIEjMXNxbLyVlU8bgQvVSem1sUD NmO2Fva2s9laC13RLGptp0lxMQT5jR7g6buCeCOmCKkkv9Y89475pJJ7RXdJ5X4aR8Eq wIDZLYPQg7Rg9KrWGsW2ps8lrBHJ5ZCS+ZA0ZjLLja28swHJGFz948sKvuQblpEsZLJm AdvI2rACOFAXcdp+UgnK5zwBzTC1iPzHkhlDnY09zC06Y2/Mm3joM5VO3vVHxMY7aGe8 kt2N0sElvHLAzARh1YbdgUk84OcgDk4HewziUSK8jJuWSRgG+7+7ZeSM4OXBBH0rGeK5 haJ9QjdDGwjhEQ8syx8fM5A27gASFABPbNDF1K+l65GtrDBLCTfQj7QjXBMSyNxsByvz AqF56HirsWpRSXBhFq7SsWUqZVDP6kEAbeB2B4p11oi6zZwXW2S3mWDf9puJd8cQVTiI k444PY4xWbpepxzFIJFVGaQODbRrIvGeYSdxGRwUHUcr0xSKudEupTQ3RSPTLoybzcIo lAifC4AJUlgSCMHAOB+AlurLSNX3Nr+oWcupyIGhMFktl5fJBQRyKskirgYxhifanzXE juyWb2OnQCIANqFzKTPkD5gyKwAOcjPpV22t4LW3l1jXINNn0qKIGLU1u/tDXcgGAiDA xgj7wA5/IMlswX8E6SJJUvY7i1CW8ZXyNwkd3LBWCtuGDjk9BiubudL1Pw/aC/tL25+w mQKIJWKuoOeWUfLjsenNblr4kvvF+vX8ty8kVm1uw2KQBEpIAycHk5zx0Kj0rQ1TUNHm 8N39idRT7eIop7SFfmE0O/5SDwM7efagNTl7XxIstvLp2qWoV5Y9omYMGUEfKxU9R6Yr odPvWNhDYvYRanBHbsqs77oy+OmeqDAHJxjAFVtqXFjNZXKR3sdtbxjZJbM1yrlQRIMD cUOeqkY296ybrTrvRbgrp10ZRt/eK+0LuBwU5PzY460gN3U/DmhSwRgWzWtxO4SIQynL Nx74xgE/1rPuPBtr9rjt7TUZi8hIVGi3qTgnJZfu9O49PWtLSvHwgt59O1WxSC5dtrXL xHzEHBxz90ZA6elbTax4eTTY/wC03a5jKmGS48phu3KR8jJzg9eDkYFO10JXOI1E6pbS NBpuniS2lcP56hnkLAAYl+YjcPcc9QSKrLoviK5t1EzSCJiXRInL7hxnEa8cZ6nFdM9/ Ijecu61ZIsGaHEbgDJJbHBHbBB6cc1DBcQ3CrPdXFxFab94gjuvJeXksHbhsL8v3Bj1p sI67HOzPbXtvHa3kqYgZoYtQZcPCeysATujznvlaJtPE2lpaXaQDUbGQPGGkB89CQDsO cEFdjAj+63em+J5Zl/esGiLztJGAxICnpjIHbrT9AuWv7aezmcxwxwO3mhgPs68Fjkkf LkA4z6jvSQdS3HNcWdg0lxN9tSTbDaLdqJ1iPLO22TcFKqoHTq4rqbOYsyQ+RK8yRJ8s LBgmV5/dllCjdkEDHRfWuGKz20v2CcJmFzOoAIOHChuCPZT+BrqdJsGjs7O7NwYo22ja eflcY2jPvsJ+gPagbLCFYY4UvLlI1QtNEJY2DFg7q6gBgNx+U4JPQ1Pc2CyrNcPbxNIp O+SaEZUEHaWHODuxndnHSoWiS2MxCQzI5klCStKFDFdrgHaw6jPIGD65xUtnZw3bQiaS aNX/AH8YZZJJCnqCnIHUAcUh3sV7iaM2GwT75Htx9oZJMbBvYAbgcbj7dAPfFYE8UtwG lR5nIOGYZ3j2OPoMYPaug1E281vIRE9qrhiXMICnc+SWwSRz329qxJV05I2dJ7l50UFG jOxd+fUrkjHQAD3psSHWZuIrZrmVPtMKsGc5YmFsgfNg55H1HrWzf2I0y7u7K8sVllsB 88KuGQNLjqSMD5Np9Rn3rH8N3aR3pjeS4gaWTB3L98EgdSQuQT17c1ra+yPDfC38uWJp ysf2hsggEKzM5bJ5DHcSOMdsUAYlpo7icz6ZqAsbiW2eWS3Ee6NMkqFIY8gkEe1Tw6jJ a3pttWt7e3ndkJZ0zDcgc4bp24/wrattOs4bbT21PxHbGVcAPFjy1Xb9xSx3SMTjJUbV z1JqfWLXR7mBLWOznu2Z/ngluIzIASQdrkKMDBAP07jFKwakN+0t/cS3N5Z23kvMzW8U kAjUH5fuHIyByMc9hWDBfQSWl+NTKymP7QkEMZAWPEQwGAIJVSDxz1OMdafLb3nhpJxa o1/pefmjaYGaJS3OGQ9GA/8A1Ukj2mr20slpYxy2+0kSS3O2RSy4YPgZByMZ9+KAN7Wt HOp31uojitJWkihvruNSY1Ch1EuNwyu2NM4PHfmo7jw/b2NleSyyQ/a4UWaV13qrOCS2 zcvfbnqBjHPIqbQrqa/mNnqKW7G5WJbe4glyqxpIS6jeNpBRzwQM9fertzp8drn7O7So 2YGwH3OqkqAM84ePyyPqfYmhNEMWijUp5BciKJEidhshbE+1MlVGNpyByc9j9K5mw0u1 umu9JvNO8ye3P2rTrrT8Rm4gJCSIWGd2wsJMcngjgVty6hf2UWW+07IQCVVGkbA43Ffv cr1bB79OKyLq9udO1W01OG1nmt71leWOTIDxsdr7Qe5XcM1I2aJ0WW0ubiJ7yQz2xKo7 E7gBxtYjr1OMg8GuUMuoaO/237PNbQFiDPbzfupCeMNu4P0Yda7if7Kl9LH59vaxzMPs 7Sv5YlG0fMu/BY4wcdea5c30EUJhSSW1Ri5jIZQznP3SpGDkjqRjrk0Br3Ej1nS4Lhpp 9PudPuXAWSQSMqt8uDjjAJBJ60WkllfXqfZ7Xy3a4TZIJw6Pk5OB/CdwHXt6ZrcvI47a 3AvZgrGHzEhjRZQWO3G7I643cDBHPFY1po6vMdQjsowscfnNJauDGF3EEnBB2hQc8cZ9 aCtDpYBBqhe3trOSy1JoyxgCbfM2jJRsHaVySc56fWmaaoS3kt8JFIq5R5FBLM5znGMu BkE4YcN7ZrmZ9Hu4HW30qYXQc+U9nLIS6sRkLu+nHPXFdDY6i1zBZ6bLYxW+qsnltbyo vm7VfC5Y5DfxD1AK/iE6Bbawz+YSixyxxO09vb5yFBC5jA+8uUJwem5c021e2mt7pNEE T7huhttgw20gFhxwCSeRhSetVry5tm062zP5TXd0FQq7IY4wCeCSSPugD369cVXF3Dc2 z2NyBa3kbbo5Ld/LWc7v4QCMEkgkDr1HoAaLtnNLd3DxXMMlsElZHiaNWSXeMAbsnKDH bBBHrVh9Phkl+zfbITE0ZcRF2nKpxhkwCwUYIzjjHGMVPaQ3VzbxtqvN8zyM4dNwlCnK 7j1TyyMAgE8nPXNckNJvbSSQWLJqeljDEI+w7Tk4jyQTjPOD+FMR0mpXd+kdrp6Xhj02 1lDFGU5uSyLhHJPY5PHXPY9cW6ZdQjht7Oyt4WtzLui4SWRMBsnIAPIJBBJHGBV3Tvs7 xyT2WyS28oh7eRdxPDZRsnKnp1/Ks+0t7lIkWFEgn8phA91KE84s7YAaX5Tt8sgHPNIL F6VJxYrPp6vM6Bisc4J6cvFjucZZW4/iwcNUd7q0vjn+z4Z7lIBakI9nDGqRccbsFuAP bP071pwJcTXcVlfXLedFZqZWikVo1O75WGPlDAg4wcEZyMVHeeH7G7YzOHeYkM7xfKFK cNgL19wDQAXGo2OhaRdQ6ZpVuoYbFdl3GZn3Eu5VjwBwB9BXPNGs2i/bgsUCLCYnOAGZ 92Y1Uem0tz/sYq1dX02mvvv4oL2wldhGYZXjlUbccn5SeBjByKhYWVxoFwkLlmMZdsEv tZd7LuzgqcErwCOaB2sblpIiTHzH2XrGPcynDLGi5AYc/LtUZ4/iqjpLpNDPcXMkPkQX Eks8cnLICocOpxyMggjuD6iobj7E91I32+OC4uIosxzrwwdVwq9QfTqoHtV2Fma41GG3 RopfLt3i2J5hjGCCfkz/AHev50AQTWMVza3MmowJdTTOogmEn3sjIZGz93HrVCfRL/S0 ln0e7N9axgfaEK8xnoQwIwwz3HYiujmh/s+yVbiBmjBEsnmRyHywTguEzkKxViRxg5OM VbutK0eWwjhsTq9v5zCS32zIiyqw53SE4f6KScAUPYFuYWiaNd63dfZ4JrG2hjO9RcSY a4x/COMLzz8w5xxmtO7sZ7W2u5tRitDIsvltEjEiNeCxywAI5QZPUniuWutOY6VBrkOp rZsiAKkjbWc5PyoBkk8E9OncVo2fxI1S30uXStQxNa3cDwi4TmRFfG4rzgngHPtTJRzn iGSaSJEkt4okV2KGJNocHv155rLsZniE0SMVEy7HA6MuQcH24rf1Cx/tCJm01vtlug+5 Cd0qf8AJ3HpzjNc+kSbmw53xkM6GNgyj3HagbN/RpItVNvpc0gRl3CylxzGT96E8/dbJ I9Dius07S9Y1EuqQHyo/3bF2UquOGA7BvRTzjn2rh9NsbS/uxELtot7BC33QgJHz9cnB 57dK9A0fU9WitH0/BkuIJvJnSLczNKo4ljAYffTv+vWmInYs6RC7u8Pp8UkToVyWlPyl ySehVWOffGOuGKmp6n/pMNg18oQRpI3l/vDyOhIJGc/MBgfhUi2OstdLOYzc3AJngFlm aTjsyc85PQkgYB610Nrqeqw2bRR+FpNRnZRtl8uaNUWPkLkx45bJwWwc5NAbHLa1pWs2 9nH59izrdQ8uhLqv8W0suRnH8q5maCBo4WYs1v8A89FUkEejEdOldrrXjCwlkSC38OeY 6N5kkZUOksrqRliuQY0JJCkYJCngLk83ptjcWen3S/azAkEQa4dmwEXpxnjOSeO/akwR WtNO1GayuNRu544NFsXDTPkqTgE+XGMYLEcAMQM966HRNPEkS6dOH0KV4hcLFdEm7viA CNgYbEVm2/6sO3uKh0iXT5NIkvtbnaG0SSQ2SzKBBLcGIbXYcgMADhT04xyTXRy+LtC1 1Ta31+9zFGCUt/IimjjBxjadgyM5HOCBinYNQuPBXh7TPLuzpVzJqjGN1t4LuSZ0AIy0 hkH3AwP3Rk7uKoXei3H2CLVdNVrqytpEMzSLHG5cdQqqPuq7ADuTk89TnQeJ9Bs7Mpba /fKkuHnsp7VpIZFwdvzH94MDHAYA4ORzzfvfHVhaXDXU1lc2+2QOWRS9tuHCEnAw24DA I+6oAoYJGZKkkcct9NYyRCR1UbGMbHOFXGcZIwckA9DVK78ManbzHWdNSQzqomuI5VKp ImCxLZ5Hy7Tk4HP59LH4oHiMR6xcbzp9pf8AlwttHyJIGClULFmf7q4AwBn1NNvtWh0y 3vIZL6YgfNG0i7DNEEBRMDcxJ6c8fLk0rD3OM0y6S4jSyj3xm2Yqts+PMjyWJBOBuUZw O49O9d7pV/bz6TLfHSZodWhgaRpLWEJIWC9TgHaWIxkg9D2ri2tNP1Ozt7KMXI16GRmk 1Uw+Um7hm8yQkZySdq4PsaSzmm0zX5IfEEdpBdrsd5HbfDcICpLIQcElR9DzwDSBnU6/ rVnFLG0Fi5ns0Yvc7Wjk3NGox5igBxhB90Dr0zzWV4svLiyGnT28M8sskDS3MNxEMwAs pj27QCVZWbls8+4Nbt1q2jjUxq9zpWqXErqsm5oyipjasbxo+A+0Z7dxgdKy/FSaTc6Z BcyX/iHT3hErQXkrQk3XoiqCuDu7DnnmnYE2VfDWpJr+m+ddW9zLdW1yLeW3swSJEPMZ G5gEHVS2eK8+8QKkEzMJCZiGMqL0QjsGzz1611nh3xFpmlXL6hcalq10isqyefYKwQtw FfZIQQQvB65XjrXMa7ozQSNdacZNT025LvBcW0D4JB+ZWTGUIJxz2xjNAmdL4kl1qzt4 Y5L+2aJpA8O2PymUhOrL6EY5+lXo5dL0mxee2lkMbFYpppoikTllzJwuSq+57n8KwfFm lNpdjamS8+1yzq007srRiH5UAjw7EkrhgT7V2nhXw5qI8PWt3suraNkjZEuLckTEkNkH 7qpx3yTxwAOQd0ibTNV8sS+IbbyZjaW32a1/ellJcEImFPYsGORkKOBWBq9nLYataxfb VvRDavcpgEYb7hBweV3sO/I4PSuu17S9AlstN0nVrV7e+MpnlXT9yzMxyFdlTJdhu47c +ledXkkuh6pqUJWYRpA8IS4g2GJDIpYbATwD6e9FhJ6nUJc/brNdrOVjZ0KJGSflB/e5 GMcDPccMO1Ymo/6BFbXkUMFw1nsnQxSh5CC/8QA+6wPtjPtVnTAbaXyZp4XsbxS3mwxH y9gGPMUk7sAthgf9vir2i2MFtqt9YTxsmohQ9ncbs5RD++R1U524AA/3uOlFhtlvV9R0 KDS5LfTzP/bGIziSTLSRhs5U528HKsfUNmq3lXFnNc22j3Mf2d3ae3t1ZCYjkbonY/xD dwO+09c1Q1Czt5ry4hvNzwylljmhYB1uOCVUg4KyFOncgZ+8arWlpqrNcahprRsCIptl 5kRgE8jI4BJzwfSkFyzeWlpFOLa5u44NWBCCW2fdIikjhyDjjJ4b/wCvUsWo6g0Y/tKV rk20A2yPI2EVfnQMM/Kw+Y/LkcVg2+taXHp5tJdL/s6YfceN/ldgeVJOc8Zx0/KtSwjf Vdbgu4ppUh2SRXJyRkBflcevIHfquRTHc0hez3VlN5rSxTSSEtILhZGZQM7gT1B/PBzx 2paZ4jtJtUnTVklaGONROyKBJGGPzSqrE8KduQAcgAnpmkk08mGaS0glMbSF0TeoX7zf NGDyDxnaeMAc55p+kzNc6ghurtLazUNFdmaBioz8p5B3K3zDKE9M4yOaQtTY8X+BdQgs JdQNymqafseUz22F8peNv7tmJzgknA7Vymm+Hn1my1G6t5Vs77SYCLqyZWjeUqOcDtlO T7g16Bb69aeDFvoUZtRslVZbG5t5PMdo8AGPaWOCvr3XnJwa4DWfEY1vV7nWks3g+0Qe RdLvw8qEYDFgeGHH5U9ASZseGtd8N6dc2ja9okbzvbRNb6hK7vGR5Y4Kk7ePYcVua1rG kr4zXUVuoja3mkjznjYBPkYlT6H5WI9eK5e0sob6ytbOS3NxvsYXeIsYg0oX93tfPO7J UgAH7vWo9E0oSJE8skdxaXEcnkxMzbEcZ+Uk4PIVgeMgigNDYXVB9iF7p02JH2qJJZAq qN7ZYEjoOSFzjntmqlnqNzdMZ7dzbRXTt+63Fk2jITaOpJAJYEEAc8VXt7S1tLaTR/Pu LWB3Ro57i2WYQggAqDkZPTrjOQRnNW7S/Nlpa2lpokqXrzbTdzKFSP5gC6lnx83Jwp9g KT2HfUn8J3hsY4Z54IrnTbCZYrpEn2sqFcEnnrufdjjcM9cVP4t8PaZptyms6BYwXvhP VZFhuLRYSY4JTwk0K8EKfUcZ5Gc8L4kkvF8Q6OfD9vGZr2z+zsWQqLny9uNwGeVH3SQD +FbsGp397eDSNbiez1HcjYc4WVc4EisMKwA9RkdxVXJPMvF3h/SdANq9vPcxXc481Ygd 6Km5gCD94Ebe57jAqpba7qrRrLdRHXLe0XaJGRmeFDngsBuA6/e4rU8eeFJPDWtPps92 Li1kQ3VjPvLmJXc7o5CQP4gcH3qvosuo6NY2UWmxPJe3kkk86qxUCIAooYjIxnLfhQBX sU8M6m9lFOFt7bzP9JE4y7KSOjr6DNdKujWmh3qX/hiYXPkwkhre4fzLhGZg6fMcxuqY deQOW+lZcWl2mp3dw+oWu6FIIgssBEcjttAyCPlyzZzkGnWWhJpk6TC2v7q1mA2LPGuE bnKkIWB9sn8KQWOu0weIpbUXek+L9Wmumh8xZbiwikdIwTlHLMDnJGSw424+qvF8Qb4X Gky+LLdkZWE1sbNly3dCQ27bzychegHXFctaeJzoGp3EN7ZzabeMGiMkgdGZSCB8jcHg 9cV1uj63bX10t5c+JdPtImmRnEliWZiDjAwdgx1yR17UXG1oTR6V4sntLj7PN4N1BjGw LNp0sMv3cFQdu1MDpj0rjLq+ubXTorU6dp8kPmMd9rfec0rBx87EgbiNu30wK7vxjqV7 eWVxZabcNc3E9tJcB942W9mqjdKCoCmR/ujHQk9wa8uVZtQlttJstNm86bCi3hhJlXgb cqOQuMcnHFDEtNSu+oxw27mVZYEaTLSsDhR0IyCQevGfWn6UdKCtMNVtjMpbbAs2Sw9C DjH/ANavTPCvh228L6SLnUbqGSeWEyXKlCRDkrhB7hck+pBrqtVt/DbQLLqPhywkt5C3 2ZnskYBVUqFJ28Z5P4+1Owrs8OtNH/tRraDTbbdMRtRLiQxKAOcGQ5Hc/errra4Phm0u dP8ADRm1XVLxdmpSLN/oxOSdqynAwuWG7I4LHg4qbWfD+g+JLuzg0TwjpdvYzPhbyGPy /tTqGxGrAbVAIG8+mQDk1Z8OeDPB9zeJZ6ppdhdIFdiwaXOQRHGCEYgA7ZW9eAe9AzIn 8N+NHlm1DWNNsrYup2mG9ghCsCCpVYn4wF4JNV9V8MXujX9lp0kdi32hsvJBch0bbgnz GwMHlRyOc/Wuw8Q+BfBu+O2sfDukrFKhmnnjSQNGFIGAScLuJUDAOfm9K4q18OeHXg1Z ktoYrgSxR6Y1uu1XH8Uhbj5SCTg8kUWHqeo+FL64sdHttPiv0s745cW8sfl73brzkiQZ yfkY9hXCfEfQLGFzeNdyeasaiZk3MA7NtUsx7DByB2wKx30TTo7CF3vL6COaJX8qO4lZ X+UE4VsggZ61TttRhhsJtPbVbsW1xKEn+12RbcgI2qTkbduGORwM9KBdRlrr9/Np8WlX TzO9hua3Afa5XcpIHrt25HsDXQa3Npo0K1J0Wzs2EySPLLdzTPMcMcngbSfUdM4xXLXc sur394YYkaZJh5bxSM5jjUuFZVA5XbtBx6A+tSLK+q+a08Hn3dtDHHNbvIQTEAf3iY65 4Jxk9KQMl8OXkF0+p6c+mqbO+t1tytmuZdysDuDt0PU5PC/zrWuranpWumPTJotIa03w +Ws7CNwpJIcucMxI+8cc+lavhSXV9T19rPRLVGuRZvts5Z/JRI1ZflUsuScsDyeckk1j avYeXrt3DqMaQ3cdwxuoJWztfrgEfKw6d+RSAj8RajP4g8hbyJbNfLS3faxdVBzucdz1 zxXpVp4m1bxDrR0s3V3aQy4NvG6Bfta7iNxx/quD0TDY6kVwmg6RL4r8aaVpNyHhhuJW 3vboFxGqsxK5BHYCvXfGT+HvBCHWRDNcaqEa1tnEjO26QAbUTpk4HaqE9GR6bpPhvWH1 W7vt2nySX7JbX8cZTy4IB5QVZTkdUYncefwry7xFbyWGrX3mTxXNtFOzQXCyrtniJYFs L0OBuP8A9evb9G0oaNoOn2CapfokVuI1hu4gElJXncuAx53HbuzzzXk+pabJq+v640SQ wRWMpEqRyg5djsSFB0ySeuQAOaQIraLpl74evkVrEG4nj3orssjxK38QG7bgkgnd6Vf0 9ri21ZntNUEV9pzptR2RiI+DLGNueQvAHo3+zWz4cu/C3g+y1D+0yw1KydrSRrlNpmhy PLO3qcgYIB6g9sVkHVvDJ060h0dmS0N200bSQGOc5YeYd55O0jg4GRkH3LDKS+Tq9zf2 8pS6t4rwlH8sB4ge5yT1ByTkYz+Ul5eahplnqGnyb47uKQWd2bmNiwRpFKTYBwQTHgnp lie4qzHHp8UV7HhoHedZQwgVt+FI5RWAXIY5CkjK9ulZFzrenwSwqsEst/bFjdsZRho2 cZjwSTuBKEDJ5Uds0BYpXl5jUbiGbyJ7BXHmpGQRtbBZjwOcg9uAancXehabDHpjR3MQ aTzYC+9gvdOuQRvH5Uas3lzSXNn4eikaVhM13G5dmRjxJtUBSrg85HH1pEfUYp5LmeC1 t1lGIoooRGsi7yp6HJYFSCT6elIC5oV9b31p9nt5iP3xNzGygMPlI5/DIz70utaqdZ1F i8FrbLNGkahl/eS7fuJIQfwB6jjFQR6U0zz3cF75dzMBGsirhocdyuecY+h9eaXWpH0p Fultrh1dTm6jUSRocYUyYAK5Y+2COCaCgsLm7ju47WRfOgZwhkIzLABn77jBZeDiQdeh 5zUV/JB/ZUrpJGXCiQlUG2QMOGUjp7gcAnPGap6XdnyGEKxJKsbmGRBuO4gbsk9iBgjv 9cGjd/aGiXU8sQWNztW3Wc7BMSuXxnnhgOPXJyeaBGrYMXlNrIi+elvbW/yRfO0JjVg2 7OOGBAbjBxntUs7uklrECweS83PsfDRyM3zMqdhn5hn1I6VPYaY8cTS2aTNJay7FhjJ8 xIyoLIB1IJ3AoORt3LnGDpXdpcW2n6Lfgx3Nl9uW3DGcSSGQhvmPyrt6DueCfSmgZTg8 m4837VLFK6DZEbQlfMCjk/NnJ6jByAPrmqt9YtaMixmy+zklkEkQilB6hhjoBxnGPXFa EBDtb27guWMgltllQI4xkgb8hj6dMGiGyjeZYLFCbdHxEI1TLHjeCBnp39j+NLoNIBrE 41yOea4ITTLdzbxzlQpkYAnBA6BVHX+9S3fiK+1mB4JE+0xGbzVNsxBDcAv5m4KMDGAC eg4NUJJ7ODX7WF0bBmmeWR43KEPGSApxg9FHHTFS3OqWaOqO4tWPP7xgdo7HHTJ9M59R TEZPi+bWriFLueWQ3en2+yaMgET2xbIlGOpBOHHbqOKyNYvHlkETBDZiCHbFB8hBKbuR 6Ak/KfSta4uxFqMa6fdrvKeY15NGJVAJIYFOcgrwR06ccVVNlY6xFcahZTKrMwLShTHA z8clW+aMkcc5X3HSmFybw3ewBYbWSXev2mNwVTJADZO4Hoc4GMV6TqNxYQ2jyG2ilu7m VZGNuVLWyFuQADheGB5/KvJ9MsZv7XWMqbe5tpcyqxxwpyVOM9cY/EVv3GuXNlb3Vvqu nvZrOjok8BDwtn3yApIxyQOmaA6nf+HNOs9fiuBqmm291ax26wNB9n+UvnJd+Tl8gknN cFr/AINsbK8kufDj3NtFE2145cypEAv3sjnGQOOSM5rZttbv3haK3vTCt2WllaORjI5J BZtytgcZrauNSu7OK0EixgKRNFFNxlSd2WHXnaOvapFszmfC/imWG/ks9QurnSZJ/LN1 JpzJ5t0ighQJCDheSfkIPJ6Hr7BE+lxwxXMM/wAoVcXm/LSgDGXc8tjoQxrwvxlJGLVp SiB2mEsLRKAEkZvmVMHI3A5wcg49RzueGPEN/ok02g39vDLJt3pA0uI7jjAG4AlTng8c Hg00xtXOzu3jn8R6dEsoMUcoldEfMMzAS7VGATklRkew7VF4q8SwWWhXd3F9qsik0hfd ceUZJjuAjVd3JLMATjAUE81yt1eT6dbpLeQpZCYuROJkLAuCoWMH5uN2Aefzqje+BvEe p/Y9PtdNthcLM11LealcKpb5FAUZJc4O9jgckrk0XFZIuavrP2uKGyWdHighjtopUUhB gLueNeMZIwPbPrWe7W4lNvZ+Ib+xLticRZVJFCALuAI4ycfTJraufBljp8Bg1ZrHUdVu osBbOWRPsi8tui4PXAyxAGB19c2PxT4V0WBYtN0e81aaKMhZZoHNskgGN2Zm557nPtim HUoWGm2lxtmm+yx6fANs9zeTsnnbN+AAPm2/KQffjPJq7pllDrGjSajaRzNbSNseC1Du URui5HOR8vpxVMeLLjVZpWGj2UT2sYt4pLpRNJGzA/Pjhe+e+McDvVV/HfimGETLc6da LHtjK2ULxsQPlXdtcAnj8qNwsz0bSZNR0m8t4bmIw2C5YypbuA+8plMbW2AbBjoDzn1r q7/SoLhoriPSLS9ljPS4lKrIMfiO+c47V4n/AMJvrKTSO3iCynUopAvHkUscZOFB4G7I wfStbRPjDdySRC90mSVgcubFy2eeAEb/ABpoTRxet6hdaV4q1K7tiLdo9Tl82K2O1Qqy t8g9sEjtXZeKvDsN3Yx+LdE1BobuNRMQwASRDk8EYwcEcdDT/GP/AAhvjGxuL7RJUtfE YkXzorkmKSUDhkZDghuQQcdutV/hz4hkigl0SZxeeUTsVJFGEPQKzEA4OePekNalH4d3 xsvF0ep2Vn590YZIprF7ry2JYDlC2dx+XgHHXr0rH+IzSXfi/VrwWF1ZG4eOR7e6QLKj GJc5AJ7jqMg1f1Pw5qNpqDozS2VyLhpdMvWZQXUtlY2IbAOeBz+hrI8Raxe+Jbk3t+oG s28KWl1GvysxQnEnXBJBAOPTNAg8F3X2W6vJ21W70w21k8kM1tLscS70AGOjZDEYIOc1 6toFpqWn3sHirxlp1zdSSW4aGeFvNGnIw5MsIAKswwWddwHI+UV5H4Qmki8S2xlmt4Gl bAkuwGi3KQwV+eFO3GfevVtS8f3kEEken6WkOsYYR3EV/wDabUDIG8YOR6hT2zk8UC1O k8V/E7QNCghkW9i1SWdBIlrZyLJ5iEcMTnCrnua8f1Xx/qetuqJbW2nac1yJjb2a4Ejb slnbqxq1onhe+utVW2ubCDxBqGUuvs63cAt2RiWfzW3BwevABGTyDkVPq0U95qmo2tv8 PNUSRGw0Vvdhmt2OWDABcbSAcY4IGAaL3K0Rn6f4Ul1PSdY1O81Z47ewleNGkJbzZQRk kk8ALj65FL4e0XfdXDyznZboYFLKG8sOC7HGMYIPH+92xUOo6jP/AGRfabHY3ECzzQXW I3K7sxDzH56ruUZXtuq34T8R32kj+yZLGR4hGz7Zzlif4cEZ7Z4IwaQDLieB57y3VpFn RiD9rMnlPyCNuTgdDjHT0p1rJpep6i13aQK0qzgGeaLgnJ/edRnGAc89ea5rVZlnn2Sm 8mcBsuYiPnPfBxxnPFWtP+zMsNpb31laSOo3/bJDGrg/LwSMAnrg4/SkO51+m3N34c0u 6ttIu1Cq0qzzRqG8xGPUHBO3pwOMknin2k8+o2UFjpGky6rYFhIYWthcLG4ABUMqjbx2 44p1toj21m7218nmrHcG1jR1aILEilBn+IsQ4z0+boa6fQfE1jFDDrFtqF1dNdQJFPFc KIZnOeSi7UQlSNu1OSPcYqiWcdJpOppdWtrqNnLpdqsYiKXbbJNznBw2SAMehz0qlcRx adps1vDfTzSPcPbOyzEbohyyEZ+bI7sMcgg16jreqwyWEXnAxwTXsDzxXOB5kSuN2Vye MAfhXBeILbw87zNpt5cQhpo5QGyI48ny2AJBLLtPr0GM96VgMHQ7SD/Q72BLiK8RlLpE NwmjyQVZcHHpuqxDFFrGpWmnm4Buru5WWaK4QgwfKWDIem0/MhHYxgV1WleIdI0Sx+x6 NFLBZXeIrss7yTRyqx3FWI5Vs9O2OnNclfa5py3l3eWzudOsSzQeSfnjeSRcgE9cMrnB 65x3osM2NQ0m58+dNUgthbq5gaZDtS5KHMb4yWiPPBPAyByDiqzw/Y4rWLdO0kibneSR N0m1ThlUkxOw5yx5AzmnzrPcW+22eSMFknwZHk80EdCWydh7fTsQRVXWmu4LmBY4Y3ub dGmiljYneVQ/K6njOAPmB55oGXb2HBhZLlpEH7uWQgxtkghchTtHzYBHQ5B6Gls7ex08 syalNeTMw/cwwlFyM7gxJBPykgbfWrCTWOoWcdxDbljPCHhbBVs4zhXHy9eCGBHtxmkF sxRp4Lq7D3C7CgjRWtvU5XvkYJPT9al7FLcxrad77+w7jfK6NOsTqThVPKnn6HrTy2Me YXPGAcg5HsfSsjTLjyrS7s2LA2kiXUXsAw3D8ua1LiIR3dzFuOVcspPcHGP0wapkrYSK wV5Zb+VmS1RDGSFJydrHHHbJUZ9652Oxt9KumP2iOePzBFCkRJkI4PPHBGRx60zxZdtN JZWuCoto2xg/eZ2yT+i/lU2qJNZ6tFI0WwR+W0W7oTtBJIz6/wAqYHQXNi8Wq3VzGYhL KVW5gEqsu8EZ2HPAJA+VsEHIGRVqK4fAiKzHepACLvD5OMYJA59s1zemXV0mqSTrKyNP nzGQ7d2ckg+2a3JQHCbBHEo3bUiZkBDdQy7tpxk8gDrSYyOwt10to/7MmkS6iQm7hc4i RhvUqWGc/cDfL34NPfxFqtzqMjanMlncXLB5GkjDlyFVcqx4xwT0qbSrcF4LeIAiScKq KvI3AbQPwPT1JqleG71ueOwCyT6jfShXZfmKFfvcZ4AwePagkt6NpNxr9zNfqkt00YZL GGN9suOjTooxlgc449a077Tn1K0itEuWuNRtY45lkaMIN7ZG8kdC+0gg8dD15rHNxBa3 qJbxPcJbMB5ELgNGoGFBfkBs8nPr0q7cWEup3uZZLVDJIEe3QsUmg6SKw6k475GCBQM2 NE8UfZLeW9uNKS61DTiwe2eMF4pcBQwY8DB7j1JrD1LWPF3ia4M95exaYFjwslvGTsBO dhlOWJOM8Y7dqUS7r46poccRtlQxyRIGLTqp2uSv94dx6AVKJ08hbiwune1zlEI/1bEd PTp3pXG11MCO7vZopTO12XgQRtd3I5Knll3jtwcD3qrqF5at+6N9cS21wVfY7MUPHCjP +RmujMv2gt9pZi4/gx/kVA9nZTyYljDJnksD8voB+VAiC7tNKsEsViWODcnzyFiWZSAd o9yRXIXFvc+fJBGodUYhSzckds5rs7rS7C/WGIyMFtCGjCno2SccnniqbeEtPmbcbqQM epLc0AzjriO5tVR5AAHJxg9Pr6Vr+F9MXVbpZbq9+yWsEil2UZkcjkKo/rW8nge0lbH2 uRl64LjFXoPDBscLDNuUdiBxT5hdTv7i48PeMYUbV9GttYcnAuOI5EH97fkMPzNeOeIt EPhnX7qyhlYCCUSWswb7yHlCD644PuDXaw2U0LfOmQSOQ5AOOnQ1j+NrG81O604rZXHm uhiRcli/O4Be/c4pXC1jpfB/iy38RW/2LVrSK5ntArSRSKpS4TocA98ZyK5/4l272/iq 1MN0pRbCGOC7VRukXMnllxnqOEOeoXPeuUay17R50mm03UdNnikXY09s8e4nOBnGDnHS r/iTV38SXUN21k9uiW4gdm/vZJLZ9s/rTuBnTeXdebexIFvUk8yeDO0Eg8uin36r29MV 6P8ACf4e2XiK1vNd1+3jvoWkMFpbzDMZZWBkkK9M5+Uf8CrgLGB76/tJY5BA8wkkMynD LOisxGScDO3PuGxXo3w8+IUa2NrpU8qWs0QJtUYkRz7jkkk9OSePWkDR1HiT4Y6Jpdtc a94fEvh3UtPglnWfTDsDqAWMbJ0II46enUcV5vZ+Ntc1zXH1+eWIto9uScKIysDMBsdl GGY5z/DnBxjNejeKNWk1TQtY0htbsRNdW7LF5N0oYN94DrxkgD6E5ryyXTZ/Dfg6KG8i eKfWbj7RdqWPywx8IgKnGT+u6quJIzri+ls9VhaRi8E0TpKU5BSQbSR9AqMO+Vpb3y4N Sa4WRy2dp3HIIHQ8dj/I00XUxNxPLGltFKQYnuVKKznqAB6Zx+FWLi0PlQlxHvRditH9 wAEcN6jrgikxiPqKXl5DFDdMZ/K2uNv7qXPJQgnhgOh71RuFs769mtZrc2zSQqyPICSZ Ao+Xr8oIJ5HcCrb2l7FJKjSITISCUwSpx6jnAz3qyI3+0wrFAWmYJBmUFmUkDnjO4E+v rSH0Og8BeH9ct5b7UrdURbQr9lMjgqQoJAXPcgKOmMmodW1nUt16tpdTwPLI07RLgI0j AGQY9cjcPXL+1dbrWo/8I3pdh4ZsJUNxBAqSSZJCYHzE8nk+h9a81MlzKZVs0kP7wTOx 6so6Hg5AByc/jTFr1H2kd3O2NQQlZhsWVCI3jOOGULj15HeoXg0m0t57XULy+liaAuqS TlQjc+WR7A4JHpmre5dSmZFDibYW+/gNgjp2GQDwO/TqKqanZRX4imKJAoCIzAkjg+h6 H1pFW0NLUPDupRw6Rdm4fT45CsBvBiUEkAsSqHBw2cZ5I9803TIbaCKeC7cajHPeNBcr JGVjmRQGDHBDJ86/gGNUNPmksbK90z7RMbFZBKzPnayjptX2P6kCrtjPEmlLPjybmJmu 1OCfMXf9wnIxwgxkHuO9Mk3hZR6dfWemwwQxTZeUeXIUMcX3tgbOffBzkiqbXJuJra9A jbz0Z7cvFtZfkZjuKHkbT1I6imXyp9veG0ALRxgKo+8GDY2KST74rLsMTaxbqedtkGIJ CnYIgTj3xu/WjQZo6Ow0i9vtMeVSsgM1vK/AwOXT3x16DqTirF3HIIkSZpQk03zOGI2n +F+MHjpkc8D3rBv4rnSktljBeaCZmCOFJ3qTkEgkHKkDGe3HoOulK3NtbR2ssUcFym5E 2DhWG5WXDcY4B49MUnsPqf/Z --============_-1199623280==_mr============-- From mitchb@MIT.EDU Thu Jan 31 14:13:06 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA10563 for ; Thu, 31 Jan 2002 14:13:06 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA18849; Thu, 31 Jan 2002 14:13:05 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA21143; Thu, 31 Jan 2002 14:13:05 -0500 (EST) Received: from athenaphobia.mit.edu (ATHENAPHOBIA.MIT.EDU [18.18.2.217]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA29610; Thu, 31 Jan 2002 14:13:05 -0500 (EST) Received: (from mitchb@localhost) by athenaphobia.mit.edu (8.9.3) id OAA07551; Thu, 31 Jan 2002 14:13:05 -0500 Message-Id: <200201311913.OAA07551@athenaphobia.mit.edu> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Neulinger, Nathan" cc: "krbdev@mit.edu" Subject: Re: parsing dump format... In-Reply-To: Your message of "Thu, 31 Jan 2002 12:12:50 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Mitchell E Berger Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 14:14:00 2002 X-Original-Date: Thu, 31 Jan 2002 14:13:05 -0500 The good news ============= In the dump format specified by the code segment you're looking at, you can get the last_pwd_change easily. It's the 16th tab-delimited field. The last line in your snippet of code is the line that fills in the mod_date and mod_princ. Then about 20 lines down, a call to krb5_dbe_lookup_last_pwd_change fills in last_pwd_change. Further down, the tabbed output format is specified. The last_pwd_change field is in the second batch of things outputted. It is recorded as a unix time (i.e. number of seconds since the epoch). The bad news ============ You're looking at the really old dump format, version 2.0. You want to (probably) be looking at the current dump format, version 5. The last password change time isn't explicitly stored in the principal record in a field reserved for specifically that purpose (we're talking about in the database, not the dump file here). It is stored as something called TL_DATA (type length data), which is sort of a hack to allow generic types of new data to be stored in the principal's record without having to change the struct that represents a principal. One type of TL_DATA is KRB5_TL_LAST_PWD_CHANGE, which is what you're after. Another is KRB5_TL_MOD_PRINC, which is the other related type to the code snippet you sent. The old dump format treated these particular TL_DATA types as special cases and extracted them and placed them in reliable fields of the dump file. Newer dump formats treat all TL_DATA equally, as hex blobs, which is what you feared, and each record may have a different number of TL_DATA entries, and the order in which such entries appear cannot be relied upon. Essentially, you could try decoding the hex blob, but it would likely be more trouble than it's worth. You can get kdb5_util to use the old format (with 'kdb5_util dump -old') if what you're really after is the password change dates, but be aware that older formats lack some of the data reported by newer formats (including, for example, policy data). So I'd recommend getting an old format dump just to lookup those dates, but only performing changes or imports from a current format dump. Hope that clears things up and is useful... Mitch > Is there any quick and easy way to get the last-pw-change date from a dump? It looked to me like the other parameters, such as expiration, etc. are all in there, but I couldn't find the last-pw-change, or last-modified time in there, unless it is embedded in one of the hex blobs. > > Looks like this might be why it isn't in there: > > /* > * If we don't have any match strings, or if our name matches, then > * proceed with the dump, otherwise, just forget about it. > */ > if (!arg->nnames || name_matches(name, arg)) { > /* > * Deserialize the modifier record. > */ > mod_name = (char *) NULL; > mod_princ = NULL; > last_pwd_change = mod_date = 0; > pkey = akey = (krb5_key_data *) NULL; > if (!(retval = krb5_dbe_lookup_mod_princ_data(arg->kcontext, > > Why are those params set to zero for the dump? > > -- Nathan > > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 > _______________________________________________ > krbdev mailing list > krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev From kenh@cmf.nrl.navy.mil Thu Jan 31 14:54:16 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA11081 for ; Thu, 31 Jan 2002 14:54:15 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.12.161]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08207 for ; Thu, 31 Jan 2002 14:54:15 -0500 (EST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id g0VJsEG20091 for ; Thu, 31 Jan 2002 14:54:14 -0500 (EST) Message-Id: <200201311954.g0VJsEG20091@ginger.cmf.nrl.navy.mil> To: krbdev@mit.edu Subject: Re: KfM 4.0b7: a few questions In-reply-to: Your message of "Thu, 31 Jan 2002 12:04:04 EST." X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Jan 31 14:55:00 2002 X-Original-Date: Thu, 31 Jan 2002 14:54:12 -0500 >I'm unclear why is it such a problem to train users to only type >their password into the Kerberos Login Server dialog. We present a >distinctive and consistent user interface, Dock icon and launch path. >Our KerberosLoginServer.app (separate from the Kerberos.app) resides >in a location owned by root/wheel so admin users can't modify it >without typing in their admin passwords. Any security conscious user >can verify via their favorite process monitor that only a user with >root access could have tampered with their Kerberos dialog. I'm not sure it was an issue of a trojan application versus the general concept that the Kerberos password is "special" and you shouldn't reveal it to any application that asks for it (e.g. a web browser) but only to a specific one. But it sounds like the consistant UI you've described (something which I didn't completely understand before) is a better solution. --Ken From goHCI@cmu.edu Tue Feb 5 13:16:15 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA08422 for ; Tue, 5 Feb 2002 13:16:14 -0500 (EST) Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA02415; Tue, 5 Feb 2002 13:16:14 -0500 (EST) Received: from gohci.cc.cmu.edu (GOHCI.CC.CMU.EDU [128.2.123.158]) (user=rubenc mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.2.Beta3/8.12.2.Beta3) with ESMTP id g15IGBm0020564; Tue, 5 Feb 2002 13:16:12 -0500 From: Ruben Carbonell To: Miro Jurisic cc: krbdev@MIT.EDU, Yerin Kay Subject: Re: Kerb v4 for MacOS X Message-ID: <823053.1012914971@gohci.cc.cmu.edu> In-Reply-To: References: <1609375.1011975044@gohci.cc.cmu.edu> <1781246.1011977909@gohci.cc.cmu.edu> Originator-Info: login-token=Mulberry:01rHqe2R7vAD7syO1Q99AfVffXIvgQmRQROhnvzD7i2g==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========00837510==========" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 5 13:17:00 2002 X-Original-Date: Tue, 05 Feb 2002 13:16:11 -0500 --==========00837510========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm not sure if we're doing "pre-authentication" as I don't know what that means; however, if the clock is off by 1 hr (or I also tried 9 hours) I do get a "Service Expired" message by both Kerberos for Mac OS 8.6 and Mac OS X 10.1.2. And I do have 4.0b7 on both OS versions. If it helps, I've attached our Kerberos preferences file. Please let me know what else I can do to help you find and alter this error text. :) Thanks as usual --Ruben >> 3) Kerberos for Mac generates a "Service Expired" message if the >> Time is out of bounds / off synch. Users get confused by this: Could >> the error message be changed to something with the word "time" in >> it; even Time Out of Bounds is fine. > > That's interesting. Are you using any form of preauthentication? I could > have sworn we verified this and it worked fine in our setup. > --==========00837510========== Content-Type: application/text; name="edu.mit.Kerberos" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="edu.mit.Kerberos"; size=4508 W2xpYmRlZmF1bHRzXQ0JZGVmYXVsdF9yZWFsbSA9IEFORFJFVy5DTVUuRURVDQlkZWZhdWx0X3Rn c19lbmN0eXBlcyA9IGRlcy1jYmMtY3JjDQlkZWZhdWx0X3RrdF9lbmN0eXBlcyA9IGRlcy1jYmMt Y3JjDQljbG9ja3NrZXcgPSAzMDANCWNoZWNrc3VtX3R5cGUgPSAxDQ1bZG9tYWluX3JlYWxtXQ0u YW5kcmV3LmNtdS5lZHUgPSBBTkRSRVcuQ01VLkVEVQ0uYWNzLmNtdS5lZHUgID0gQU5EUkVXLkNN VS5FRFUNLmNjLmNtdS5lZHUgICA9IEFORFJFVy5DTVUuRURVDS5yZXMuY211LmVkdSAgPSBBTkRS RVcuQ01VLkVEVQ0uZXBwLmNtdS5lZHUgID0gQU5EUkVXLkNNVS5FRFUNLmFzLmNtdS5lZHUgICA9 IEFORFJFVy5DTVUuRURVDS5oc3MuY211LmVkdSAgPSBBTkRSRVcuQ01VLkVEVQ0ubGNsLmNtdS5l ZHUgID0gQU5EUkVXLkNNVS5FRFUNLnBoaWwuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5waHlz LmNtdS5lZHUgPSBBTkRSRVcuQ01VLkVEVQ0uY2ZhLmNtdS5lZHUgID0gQU5EUkVXLkNNVS5FRFUN Lm1hdGguY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5uZXQuY211LmVkdSAgPSBBTkRSRVcuQ01V LkVEVQ0ucHN5LmNtdS5lZHUgID0gQU5EUkVXLkNNVS5FRFUNLmFyYy5jbXUuZWR1ICA9IEFORFJF Vy5DTVUuRURVDS5jZS5jbXUuZWR1ICAgPSBBTkRSRVcuQ01VLkVEVQ0ubGlicmFyeS5jbXUuZWR1 ID0gQU5EUkVXLkNNVS5FRFUNLmNlZXMuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5jaGVtZS5j bXUuZWR1ID0gQU5EUkVXLkNNVS5FRFUNLmdzaWEuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5o ZWluei5jbXUuZWR1ID0gQU5EUkVXLkNNVS5FRFUNLmluaS5jbXUuZWR1ID0gQU5EUkVXLkNNVS5F RFUNLm1lLmNtdS5lZHUgID0gQU5EUkVXLkNNVS5FRFUNLmNzdy5jbXUuZWR1ID0gQU5EUkVXLkNN VS5FRFUNLmNsdWIuY2MuY211LmVkdSA9IENMVUIuQ0MuQ01VLkVEVQ0uY3MuY211LmVkdSAgPSBD Uy5DTVUuRURVDS5yaS5jbXUuZWR1ICA9IENTLkNNVS5FRFUNLmVkcmMuY211LmVkdSA9IENTLkNN VS5FRFUNLmljZXMuY211LmVkdSA9IENTLkNNVS5FRFUNY3MuY211LmVkdSAgID0gQ1MuQ01VLkVE VQ1yaS5jbXUuZWR1ICAgPSBDUy5DTVUuRURVDWVkcmMuY211LmVkdSA9IENTLkNNVS5FRFUNaWNl cy5jbXUuZWR1ID0gQ1MuQ01VLkVEVQ0uc2UuY3MuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5l dm9sLnJpLmNtdS5lZHUgPSBBTkRSRVcuQ01VLkVEVQ0ubWl0LmVkdSA9IEFUSEVOQS5NSVQuRURV DWRldy5lcHAuY211LmVkdSA9IEVDRS5DTVUuRURVDQ1bcmVhbG1zXQ1BTkRSRVcuQ01VLkVEVSA9 IHsNICBrZGMgPSB2aWNlMjguZnMuYW5kcmV3LmNtdS5lZHU6ODgNICBrZGMgPSB2aWNlMi5mcy5h bmRyZXcuY211LmVkdTo4OA0gIGtkYyA9IHZpY2UxMS5mcy5hbmRyZXcuY211LmVkdTo4OA0gIGtk YyA9IHZpY2UxMi5mcy5hbmRyZXcuY211LmVkdTo4OA0gIGFkbWluX3NlcnZlciA9IHZpY2UyOC5m cy5hbmRyZXcuY211LmVkdQ0gIGRlZmF1bHRfZG9tYWluID0gQU5EUkVXLkNNVS5FRFUNICBzdHJp bmdfdG9fa2V5X3R5cGUgPSBtaXRfc3RyaW5nX3RvX2tleQ19DUFUSEVOQS5NSVQuRURVID0gew0g IGtkYyA9IGtlcmJlcm9zLm1pdC5lZHU6ODgNICBrZGMgPSBrZXJiZXJvcy0yLm1pdC5lZHU6ODgN ICBhZG1pbl9zZXJ2ZXIgPSBrZXJiZXJvcy5taXQuZWR1DSAgZGVmYXVsdF9kb21haW4gPSBNSVQu RURVDX0NQ1MuQ01VLkVEVSA9IHsNICBrZGMgPSBrZXJiZXJvcy5jcy5jbXUuZWR1Ojg4DSAga2Rj ID0ga2VyYmVyb3MtMi5zcnYuY3MuY211LmVkdTo4OA0gIGFkbWluX3NlcnZlciA9IGtlcmJlcm9z LmNzLmNtdS5lZHUNICBkZWZhdWx0X2RvbWFpbiA9IENTLkNNVS5FRFUNICB2NF9pbnN0YW5jZV9j b252ZXJ0ID0gew0gICAgcG9zdG9mZmljZSA9IHBvc3RvZmZpY2Uuc3J2LmNzLmNtdS5lZHUNICAg IGF1Y2hlbnRvc2hhbiA9IGF1Y2hlbnRvc2hhbi5wZGwuY3MuY211LmVkdQ0gIH0NfQ0gICAgIA1b djQgcmVhbG1zXQ1BTkRSRVcuQ01VLkVEVSA9IHsNICBrZGMgPSB2aWNlNy5mcy5hbmRyZXcuY211 LmVkdQ0gIGtkYyA9IHZpY2UyLmZzLmFuZHJldy5jbXUuZWR1DSAga2RjID0gdmljZTExLmZzLmFu ZHJldy5jbXUuZWR1DSAga2RjID0gdmljZTI4LmZzLmFuZHJldy5jbXUuZWR1DSAga2RjID0gdmlj ZTEyLmZzLmFuZHJldy5jbXUuZWR1DSAgYWRtaW5fc2VydmVyID0gdmljZTI4LmZzLmFuZHJldy5j bXUuZWR1DSAgZGVmYXVsdF9kb21haW4gPSBBTkRSRVcuQ01VLkVEVQ0gIHN0cmluZ190b19rZXlf dHlwZSA9IG1pdF9zdHJpbmdfdG9fa2V5DX0NQVRIRU5BLk1JVC5FRFUgPSB7DSAga2RjID0ga2Vy YmVyb3MubWl0LmVkdQ0gIGtkYyA9IGtlcmJlcm9zLTEubWl0LmVkdQ0gIGtkYyA9IGtlcmJlcm9z LTIubWl0LmVkdQ0gIGtkYyA9IGtlcmJlcm9zLTMubWl0LmVkdQ0gIGFkbWluX3NlcnZlciA9IGtl cmJlcm9zLm1pdC5lZHUNICBkZWZhdWx0X2RvbWFpbiA9IG1pdC5lZHUNICBzdHJpbmdfdG9fa2V5 X3R5cGUgPSBtaXRfc3RyaW5nX3RvX2tleQ19DUNTLkNNVS5FRFUgPSB7DSAga2RjID0ga2VyYmVy b3MuY3MuY211LmVkdQ0gIGtkYyA9IGtlcmJlcm9zLTIuc3J2LmNzLmNtdS5lZHUNICBhZG1pbl9z ZXJ2ZXIgPSBrZXJiZXJvcy5jcy5jbXUuZWR1DSAgZGVmYXVsdF9kb21haW4gPSBDUy5DTVUuRURV DSAgc3RyaW5nX3RvX2tleV90eXBlID0gbWl0X3N0cmluZ190b19rZXkNfQ0gCQkNW3Y0IGRvbWFp bl9yZWFsbV0NLmFuZHJldy5jbXUuZWR1ID0gQU5EUkVXLkNNVS5FRFUNLmFjcy5jbXUuZWR1ICA9 IEFORFJFVy5DTVUuRURVDS5jYy5jbXUuZWR1ICAgPSBBTkRSRVcuQ01VLkVEVQ0ucmVzLmNtdS5l ZHUgID0gQU5EUkVXLkNNVS5FRFUNLmVwcC5jbXUuZWR1ICA9IEFORFJFVy5DTVUuRURVDS5hcy5j bXUuZWR1ICAgPSBBTkRSRVcuQ01VLkVEVQ0uaHNzLmNtdS5lZHUgID0gQU5EUkVXLkNNVS5FRFUN LmxjbC5jbXUuZWR1ICA9IEFORFJFVy5DTVUuRURVDS5waGlsLmNtdS5lZHUgPSBBTkRSRVcuQ01V LkVEVQ0ucGh5cy5jbXUuZWR1ID0gQU5EUkVXLkNNVS5FRFUNLmNmYS5jbXUuZWR1ICA9IEFORFJF Vy5DTVUuRURVDS5tYXRoLmNtdS5lZHUgPSBBTkRSRVcuQ01VLkVEVQ0ubmV0LmNtdS5lZHUgID0g QU5EUkVXLkNNVS5FRFUNLnBzeS5jbXUuZWR1ICA9IEFORFJFVy5DTVUuRURVDS5hcmMuY211LmVk dSAgPSBBTkRSRVcuQ01VLkVEVQ0uY2UuY211LmVkdSAgID0gQU5EUkVXLkNNVS5FRFUNLmxpYnJh cnkuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5jZWVzLmNtdS5lZHUgPSBBTkRSRVcuQ01VLkVE VQ0uY2hlbWUuY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5nc2lhLmNtdS5lZHUgPSBBTkRSRVcu Q01VLkVEVQ0uaGVpbnouY211LmVkdSA9IEFORFJFVy5DTVUuRURVDS5pbmkuY211LmVkdSA9IEFO RFJFVy5DTVUuRURVDS5tZS5jbXUuZWR1ICA9IEFORFJFVy5DTVUuRURVDS5jc3cuY211LmVkdSA9 IEFORFJFVy5DTVUuRURVDS5jbHViLmNjLmNtdS5lZHUgPSBDTFVCLkNDLkNNVS5FRFUNLmNzLmNt dS5lZHUgID0gQ1MuQ01VLkVEVQ0ucmkuY211LmVkdSAgPSBDUy5DTVUuRURVDS5lZHJjLmNtdS5l ZHUgPSBDUy5DTVUuRURVDS5pY2VzLmNtdS5lZHUgPSBDUy5DTVUuRURVDWNzLmNtdS5lZHUgICA9 IENTLkNNVS5FRFUNcmkuY211LmVkdSAgID0gQ1MuQ01VLkVEVQ1lZHJjLmNtdS5lZHUgPSBDUy5D TVUuRURVDWljZXMuY211LmVkdSA9IENTLkNNVS5FRFUNLnNlLmNzLmNtdS5lZHUgPSBBTkRSRVcu Q01VLkVEVQ0uZXZvbC5yaS5jbXUuZWR1ID0gQU5EUkVXLkNNVS5FRFUNLm1pdC5lZHUgPSBBVEhF TkEuTUlULkVEVQ1kZXcuZXBwLmNtdS5lZHUgPSBFQ0UuQ01VLkVEVQ0= --==========00837510========== Content-Type: text/plain; charset=us-ascii; name="Kerberos Preferences" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Kerberos Preferences"; size=4508 [libdefaults] default_realm = ANDREW.CMU.EDU default_tgs_enctypes = des-cbc-crc default_tkt_enctypes = des-cbc-crc clockskew = 300 checksum_type = 1 [domain_realm] .andrew.cmu.edu = ANDREW.CMU.EDU .acs.cmu.edu = ANDREW.CMU.EDU .cc.cmu.edu = ANDREW.CMU.EDU .res.cmu.edu = ANDREW.CMU.EDU .epp.cmu.edu = ANDREW.CMU.EDU .as.cmu.edu = ANDREW.CMU.EDU .hss.cmu.edu = ANDREW.CMU.EDU .lcl.cmu.edu = ANDREW.CMU.EDU .phil.cmu.edu = ANDREW.CMU.EDU .phys.cmu.edu = ANDREW.CMU.EDU .cfa.cmu.edu = ANDREW.CMU.EDU .math.cmu.edu = ANDREW.CMU.EDU .net.cmu.edu = ANDREW.CMU.EDU .psy.cmu.edu = ANDREW.CMU.EDU .arc.cmu.edu = ANDREW.CMU.EDU .ce.cmu.edu = ANDREW.CMU.EDU .library.cmu.edu = ANDREW.CMU.EDU .cees.cmu.edu = ANDREW.CMU.EDU .cheme.cmu.edu = ANDREW.CMU.EDU .gsia.cmu.edu = ANDREW.CMU.EDU .heinz.cmu.edu = ANDREW.CMU.EDU .ini.cmu.edu = ANDREW.CMU.EDU .me.cmu.edu = ANDREW.CMU.EDU .csw.cmu.edu = ANDREW.CMU.EDU .club.cc.cmu.edu = CLUB.CC.CMU.EDU .cs.cmu.edu = CS.CMU.EDU .ri.cmu.edu = CS.CMU.EDU .edrc.cmu.edu = CS.CMU.EDU .ices.cmu.edu = CS.CMU.EDU cs.cmu.edu = CS.CMU.EDU ri.cmu.edu = CS.CMU.EDU edrc.cmu.edu = CS.CMU.EDU ices.cmu.edu = CS.CMU.EDU .se.cs.cmu.edu = ANDREW.CMU.EDU .evol.ri.cmu.edu = ANDREW.CMU.EDU .mit.edu = ATHENA.MIT.EDU dew.epp.cmu.edu = ECE.CMU.EDU [realms] ANDREW.CMU.EDU = { kdc = vice28.fs.andrew.cmu.edu:88 kdc = vice2.fs.andrew.cmu.edu:88 kdc = vice11.fs.andrew.cmu.edu:88 kdc = vice12.fs.andrew.cmu.edu:88 admin_server = vice28.fs.andrew.cmu.edu default_domain = ANDREW.CMU.EDU string_to_key_type = mit_string_to_key } ATHENA.MIT.EDU = { kdc = kerberos.mit.edu:88 kdc = kerberos-2.mit.edu:88 admin_server = kerberos.mit.edu default_domain = MIT.EDU } CS.CMU.EDU = { kdc = kerberos.cs.cmu.edu:88 kdc = kerberos-2.srv.cs.cmu.edu:88 admin_server = kerberos.cs.cmu.edu default_domain = CS.CMU.EDU v4_instance_convert = { postoffice = postoffice.srv.cs.cmu.edu auchentoshan = auchentoshan.pdl.cs.cmu.edu } } [v4 realms] ANDREW.CMU.EDU = { kdc = vice7.fs.andrew.cmu.edu kdc = vice2.fs.andrew.cmu.edu kdc = vice11.fs.andrew.cmu.edu kdc = vice28.fs.andrew.cmu.edu kdc = vice12.fs.andrew.cmu.edu admin_server = vice28.fs.andrew.cmu.edu default_domain = ANDREW.CMU.EDU string_to_key_type = mit_string_to_key } ATHENA.MIT.EDU = { kdc = kerberos.mit.edu kdc = kerberos-1.mit.edu kdc = kerberos-2.mit.edu kdc = kerberos-3.mit.edu admin_server = kerberos.mit.edu default_domain = mit.edu string_to_key_type = mit_string_to_key } CS.CMU.EDU = { kdc = kerberos.cs.cmu.edu kdc = kerberos-2.srv.cs.cmu.edu admin_server = kerberos.cs.cmu.edu default_domain = CS.CMU.EDU string_to_key_type = mit_string_to_key } [v4 domain_realm] .andrew.cmu.edu = ANDREW.CMU.EDU .acs.cmu.edu = ANDREW.CMU.EDU .cc.cmu.edu = ANDREW.CMU.EDU .res.cmu.edu = ANDREW.CMU.EDU .epp.cmu.edu = ANDREW.CMU.EDU .as.cmu.edu = ANDREW.CMU.EDU .hss.cmu.edu = ANDREW.CMU.EDU .lcl.cmu.edu = ANDREW.CMU.EDU .phil.cmu.edu = ANDREW.CMU.EDU .phys.cmu.edu = ANDREW.CMU.EDU .cfa.cmu.edu = ANDREW.CMU.EDU .math.cmu.edu = ANDREW.CMU.EDU .net.cmu.edu = ANDREW.CMU.EDU .psy.cmu.edu = ANDREW.CMU.EDU .arc.cmu.edu = ANDREW.CMU.EDU .ce.cmu.edu = ANDREW.CMU.EDU .library.cmu.edu = ANDREW.CMU.EDU .cees.cmu.edu = ANDREW.CMU.EDU .cheme.cmu.edu = ANDREW.CMU.EDU .gsia.cmu.edu = ANDREW.CMU.EDU .heinz.cmu.edu = ANDREW.CMU.EDU .ini.cmu.edu = ANDREW.CMU.EDU .me.cmu.edu = ANDREW.CMU.EDU .csw.cmu.edu = ANDREW.CMU.EDU .club.cc.cmu.edu = CLUB.CC.CMU.EDU .cs.cmu.edu = CS.CMU.EDU .ri.cmu.edu = CS.CMU.EDU .edrc.cmu.edu = CS.CMU.EDU .ices.cmu.edu = CS.CMU.EDU cs.cmu.edu = CS.CMU.EDU ri.cmu.edu = CS.CMU.EDU edrc.cmu.edu = CS.CMU.EDU ices.cmu.edu = CS.CMU.EDU .se.cs.cmu.edu = ANDREW.CMU.EDU .evol.ri.cmu.edu = ANDREW.CMU.EDU .mit.edu = ATHENA.MIT.EDU dew.epp.cmu.edu = ECE.CMU.EDU --==========00837510==========-- From lxs@MIT.EDU Tue Feb 5 14:56:18 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA09654 for ; Tue, 5 Feb 2002 14:56:18 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA16185; Tue, 5 Feb 2002 14:56:17 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02103; Tue, 5 Feb 2002 14:56:17 -0500 (EST) Received: from [18.18.1.18] (RAGNA-BLADE.MIT.EDU [18.18.1.18]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12358; Tue, 5 Feb 2002 14:56:17 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <823053.1012914971@gohci.cc.cmu.edu> References: <1609375.1011975044@gohci.cc.cmu.edu> <1781246.1011977909@gohci.cc.cmu.edu> <823053.1012914971@gohci.cc.cmu.edu> To: Ruben Carbonell From: Alexandra Ellwood Subject: Re: Kerb v4 for MacOS X Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 5 14:57:00 2002 X-Original-Date: Tue, 5 Feb 2002 14:56:16 -0500 >Hi, > > I'm not sure if we're doing "pre-authentication" as I don't know >what that means; however, if the clock is off by 1 hr (or I also >tried 9 hours) I do get a "Service Expired" message by both Kerberos >for Mac OS 8.6 and Mac OS X 10.1.2. And I do have 4.0b7 on both >OS versions. > >If it helps, I've attached our Kerberos preferences file. ANDREW.CMU.EDU appears to be running a kaserver, which is a special type of Kerberos 4 KDC shipped by Transarc for use with AFS. I believe this type of server can return KDC_SERVICE_EXP (Service expired) instead of RD_AP_TIME (Clock skew too great) in time-out-of-bounds conditions. While getting an initial ticket, receiving KDC_SERVICE_EXP can only mean two things: the server is a kaserver and the real error is RD_AP_TIME *or* the krbtgt service principal is expired. Since the latter error is unlikely (and will cause immediate serious problems for all Kerberos clients), we will consider working around this problem. However, we will need to verify that this change will not result in bad error reporting for other v4 KDC implementations (I can think of at least four). As a result, I would not expect this change for KfM 4.0. Also, I suspect that you have the wrong string_to_key_type in your preferences file. If you are using a kaserver, you probably want a "afs_string_to_key" rather than "mit_string_to_key". These two types behave the same for passwords of 8 characters or less, so you may not be able to tell that you have the wrong one until you change your password to something longer than 8 chars. Hope this helps, --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From jalonso@MIT.EDU Wed Feb 6 01:32:04 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id BAA17576 for ; Wed, 6 Feb 2002 01:32:04 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id BAA21965 for ; Wed, 6 Feb 2002 01:32:04 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA02548 for ; Wed, 6 Feb 2002 01:32:03 -0500 (EST) Received: from jacobian (JACOBIAN.MIT.EDU [18.247.3.59]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with SMTP id BAA10888 for ; Wed, 6 Feb 2002 01:32:03 -0500 (EST) From: "Jason B. Alonso" To: Subject: Port of Kerberos to Cygwin Message-ID: <002301c1aed7$fcdbcef0$3b03f712@mit.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0024_01C1AEAE.1405C6F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Feb 6 01:33:00 2002 X-Original-Date: Wed, 6 Feb 2002 01:32:01 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1AEAE.1405C6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I recently downloaded the latest release (1.2.3--not the snapshot) of Kerberos V, and I was able to port it to Cygwin using the following minor (though extensive changes): 1) errno is _not_ an "extern int" on Cygwin, so I #ifdef'd _every_ "extern int errno" and inserted an #include in a quite a number of places. 2) Cygwin doesn't have a pututline function to add an entry to utmp, so I wrote one in src/util/pty/update_utmp.c in an #ifdef block. I'm attaching my unified diff that accomplished this, though my #ifndef __CYGWIN__ lines really should be #ifdef ERRNO_EXTERN (and autoconf'd), for cleaner errno declarations. That would probably be a good idea regardless of Cygwin... With the changes I made, Kerberos V builds OTB (well... almost: ./configure --with-netlib) on Cygwin. Sincerely, Jason Alonso p.s. Benchmark: kinit works, and I can telnet (after disabling Krb4) into Athena and run rsh commands without retyping my password. p.p.s. Kerberos V server compiles, but I have NOT tested it. ------=_NextPart_000_0024_01C1AEAE.1405C6F0 Content-Type: application/octet-stream; name="krb5-cygwin.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="krb5-cygwin.diff" diff -u -r -b -H krb5-1.2.3-orig/src/appl/bsd/login.c = krb5-1.2.3/src/appl/bsd/login.c=0A= --- krb5-1.2.3-orig/src/appl/bsd/login.c Wed Jan 9 17:26:49 2002=0A= +++ krb5-1.2.3/src/appl/bsd/login.c Tue Feb 5 20:20:54 2002=0A= @@ -295,7 +295,11 @@=0A= =0A= char term[64], *hostname, *username;=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= #ifdef KRB4=0A= #define KRB_ENVIRON "KRBTKFILE" /* Ticket file environment variable */=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kadmin/dbutil/kdb5_destroy.c = krb5-1.2.3/src/kadmin/dbutil/kdb5_destroy.c=0A= --- krb5-1.2.3-orig/src/kadmin/dbutil/kdb5_destroy.c Wed Jan 9 17:27:12 = 2002=0A= +++ krb5-1.2.3/src/kadmin/dbutil/kdb5_destroy.c Tue Feb 5 20:21:16 2002=0A= @@ -35,7 +35,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= extern int exit_status;=0A= extern krb5_boolean dbactive;=0A= extern kadm5_config_params global_params;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kadmin/dbutil/kdb5_stash.c = krb5-1.2.3/src/kadmin/dbutil/kdb5_stash.c=0A= --- krb5-1.2.3-orig/src/kadmin/dbutil/kdb5_stash.c Wed Jan 9 17:27:12 = 2002=0A= +++ krb5-1.2.3/src/kadmin/dbutil/kdb5_stash.c Tue Feb 5 20:21:23 2002=0A= @@ -58,7 +58,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= extern krb5_keyblock master_keyblock;=0A= extern krb5_principal master_princ;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kadmin/v4server/acl_files.c = krb5-1.2.3/src/kadmin/v4server/acl_files.c=0A= --- krb5-1.2.3-orig/src/kadmin/v4server/acl_files.c Wed Jan 9 17:27:22 = 2002=0A= +++ krb5-1.2.3/src/kadmin/v4server/acl_files.c Tue Feb 5 20:21:41 2002=0A= @@ -50,7 +50,11 @@=0A= =0A= #define COR(a,b) ((a!=3DNULL)?(a):(b))=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= #ifndef HAVE_STDLIB_H=0A= extern char *malloc(), *calloc();=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kadmin/v4server/admin_server.c = krb5-1.2.3/src/kadmin/v4server/admin_server.c=0A= --- krb5-1.2.3-orig/src/kadmin/v4server/admin_server.c Wed Jan 9 = 17:27:22 2002=0A= +++ krb5-1.2.3/src/kadmin/v4server/admin_server.c Tue Feb 5 20:22:02 = 2002=0A= @@ -269,7 +269,9 @@=0A= */=0A= kadm_listen()=0A= {=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= int found;=0A= int admin_fd;=0A= int peer_fd;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kdc/kerberos_v4.c = krb5-1.2.3/src/kdc/kerberos_v4.c=0A= --- krb5-1.2.3-orig/src/kdc/kerberos_v4.c Wed Jan 9 17:27:28 2002=0A= +++ krb5-1.2.3/src/kdc/kerberos_v4.c Tue Feb 5 20:22:08 2002=0A= @@ -66,7 +66,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= static int compat_decrypt_key PROTOTYPE((krb5_key_data *, C_Block,=0A= krb5_keyblock *, int));=0A= diff -u -r -b -H krb5-1.2.3-orig/src/kdc/network.c = krb5-1.2.3/src/kdc/network.c=0A= --- krb5-1.2.3-orig/src/kdc/network.c Wed Jan 9 17:27:28 2002=0A= +++ krb5-1.2.3/src/kdc/network.c Tue Feb 5 20:22:13 2002=0A= @@ -55,7 +55,11 @@=0A= #include =0A= #endif=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= static int *udp_port_fds =3D (int *) NULL;=0A= static u_short *udp_port_nums =3D (u_short *) NULL;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/des425/quad_cksum.c = krb5-1.2.3/src/lib/des425/quad_cksum.c=0A= --- krb5-1.2.3-orig/src/lib/des425/quad_cksum.c Wed Jan 9 17:27:42 2002=0A= +++ krb5-1.2.3/src/lib/des425/quad_cksum.c Tue Feb 5 20:22:25 2002=0A= @@ -102,7 +102,11 @@=0A= /* Externals */=0A= extern char *errmsg();=0A= #ifndef HAVE_ERRNO=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= extern int des_debug;=0A= =0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/des425/verify.c = krb5-1.2.3/src/lib/des425/verify.c=0A= --- krb5-1.2.3-orig/src/lib/des425/verify.c Wed Jan 9 17:27:42 2002=0A= +++ krb5-1.2.3/src/lib/des425/verify.c Tue Feb 5 20:22:32 2002=0A= @@ -37,7 +37,11 @@=0A= #include "./des.h"=0A= =0A= extern char *errmsg();=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= extern int des_string_to_key();=0A= extern int des_key_sched();=0A= extern int des_ecb_encrypt();=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/dest_tkt.c = krb5-1.2.3/src/lib/krb4/dest_tkt.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/dest_tkt.c Wed Jan 9 17:27:49 2002=0A= +++ krb5-1.2.3/src/lib/krb4/dest_tkt.c Tue Feb 5 20:22:48 2002=0A= @@ -69,7 +69,9 @@=0A= {=0A= char *file =3D TKT_FILE;=0A= int i,fd;=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= int ret;=0A= struct stat statpre, statpost;=0A= char buf[BUFSIZ];=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/in_tkt.c = krb5-1.2.3/src/lib/krb4/in_tkt.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/in_tkt.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/in_tkt.c Tue Feb 5 20:27:47 2002=0A= @@ -35,7 +35,9 @@=0A= #ifdef HAVE_UNISTD_H=0A= #include =0A= #endif=0A= -=0A= +#ifdef __CYGWIN__=0A= +#include =0A= +#endif=0A= extern int krb_debug;=0A= =0A= /*=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/netread.c = krb5-1.2.3/src/lib/krb4/netread.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/netread.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/netread.c Tue Feb 5 20:22:54 2002=0A= @@ -12,7 +12,11 @@=0A= #define DEFINE_SOCKADDR=0A= #include "krb.h"=0A= #ifndef _WINDOWS=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= /*=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/netwrite.c = krb5-1.2.3/src/lib/krb4/netwrite.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/netwrite.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/netwrite.c Tue Feb 5 20:23:01 2002=0A= @@ -12,7 +12,11 @@=0A= #define DEFINE_SOCKADDR=0A= #include "krb.h"=0A= #ifndef _WINDOWS=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= /*=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/recvauth.c = krb5-1.2.3/src/lib/krb4/recvauth.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/recvauth.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/recvauth.c Tue Feb 5 20:23:08 2002=0A= @@ -26,7 +26,11 @@=0A= */=0A= =0A= #ifndef _WINDOWS=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= /*=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/send_to_kdc.c = krb5-1.2.3/src/lib/krb4/send_to_kdc.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/send_to_kdc.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/send_to_kdc.c Tue Feb 5 23:10:50 2002=0A= @@ -19,6 +19,10 @@=0A= #include =0A= #endif=0A= =0A= +#ifdef __CYGWIN__=0A= +#include =0A= +#endif=0A= +=0A= #define S_AD_SZ sizeof(struct sockaddr_in)=0A= =0A= #ifdef HAVE_STDLIB_H=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb4/tf_util.c = krb5-1.2.3/src/lib/krb4/tf_util.c=0A= --- krb5-1.2.3-orig/src/lib/krb4/tf_util.c Wed Jan 9 17:27:50 2002=0A= +++ krb5-1.2.3/src/lib/krb4/tf_util.c Tue Feb 5 20:23:14 2002=0A= @@ -46,7 +46,11 @@=0A= #define TF_LCK_RETRY ((unsigned)2) /* seconds to sleep before=0A= * retry if ticket file is=0A= * locked */=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= extern int krb_debug;=0A= =0A= void tf_close();=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/keytab/file/ktf_util.c = krb5-1.2.3/src/lib/krb5/keytab/file/ktf_util.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/keytab/file/ktf_util.c Wed Jan 9 = 17:27:55 2002=0A= +++ krb5-1.2.3/src/lib/krb5/keytab/file/ktf_util.c Tue Feb 5 20:23:23 = 2002=0A= @@ -98,7 +98,11 @@=0A= #endif=0A= =0A= #ifndef HAVE_ERRNO=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= static krb5_error_code=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/keytab/srvtab/kts_util.c = krb5-1.2.3/src/lib/krb5/keytab/srvtab/kts_util.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/keytab/srvtab/kts_util.c Wed Jan 9 = 17:27:56 2002=0A= +++ krb5-1.2.3/src/lib/krb5/keytab/srvtab/kts_util.c Tue Feb 5 20:23:29 = 2002=0A= @@ -53,7 +53,12 @@=0A= #define INST_SZ 40=0A= =0A= #ifndef HAVE_ERRNO=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= +=0A= #endif=0A= =0A= static krb5_error_code=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/os/c_ustime.c = krb5-1.2.3/src/lib/krb5/os/c_ustime.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/os/c_ustime.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/krb5/os/c_ustime.c Tue Feb 5 20:23:34 2002=0A= @@ -325,7 +325,11 @@=0A= =0A= /* We're a Unix machine -- do Unix time things. */=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= static struct timeval last_tv =3D {0, 0};=0A= =0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/os/localaddr.c = krb5-1.2.3/src/lib/krb5/os/localaddr.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/os/localaddr.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/krb5/os/localaddr.c Tue Feb 5 20:23:39 2002=0A= @@ -77,7 +77,11 @@=0A= * Add more address families here.=0A= */=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /*=0A= * Return all the protocol addresses of this host.=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/os/timeofday.c = krb5-1.2.3/src/lib/krb5/os/timeofday.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/os/timeofday.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/krb5/os/timeofday.c Tue Feb 5 20:23:45 2002=0A= @@ -33,7 +33,11 @@=0A= #include =0A= =0A= #ifndef HAVE_ERRNO=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= KRB5_DLLIMP krb5_error_code KRB5_CALLCONV=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/posix/syslog.c = krb5-1.2.3/src/lib/krb5/posix/syslog.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/posix/syslog.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/krb5/posix/syslog.c Tue Feb 5 20:23:56 2002=0A= @@ -89,7 +89,9 @@=0A= const register char *fmt;=0A= va_list ap;=0A= {=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= register int cnt;=0A= register char *p;=0A= time_t now, time();=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/krb5/rcache/rc_io.c = krb5-1.2.3/src/lib/krb5/rcache/rc_io.c=0A= --- krb5-1.2.3-orig/src/lib/krb5/rcache/rc_io.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/krb5/rcache/rc_io.c Tue Feb 5 20:24:03 2002=0A= @@ -40,7 +40,11 @@=0A= #endif=0A= =0A= #ifndef HAVE_ERRNO=0A= -extern int errno; /* this should be in errno.h, but isn't on some = systems */=0A= +#ifndef __CYGWIN__=0A= +extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= #endif=0A= =0A= #define FREE(x) ((void) free((char *) (x)))=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/bindresvport.c = krb5-1.2.3/src/lib/rpc/bindresvport.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/bindresvport.c Wed Jan 9 17:27:58 2002=0A= +++ krb5-1.2.3/src/lib/rpc/bindresvport.c Tue Feb 5 20:24:13 2002=0A= @@ -48,7 +48,9 @@=0A= int res;=0A= static short port;=0A= struct sockaddr_in myaddr;=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= int i;=0A= =0A= #define STARTPORT 600=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/clnt_tcp.c = krb5-1.2.3/src/lib/rpc/clnt_tcp.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/clnt_tcp.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/clnt_tcp.c Tue Feb 5 20:24:19 2002=0A= @@ -59,7 +59,11 @@=0A= =0A= #define MCALL_MSG_SIZE 24=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= static int readtcp();=0A= static int writetcp();=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/clnt_udp.c = krb5-1.2.3/src/lib/rpc/clnt_udp.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/clnt_udp.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/clnt_udp.c Tue Feb 5 20:24:23 2002=0A= @@ -48,7 +48,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /*=0A= * UDP bases client side rpc operations=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/pmap_getmaps.c = krb5-1.2.3/src/lib/rpc/pmap_getmaps.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/pmap_getmaps.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/pmap_getmaps.c Tue Feb 5 20:24:28 2002=0A= @@ -55,7 +55,11 @@=0A= #define NAMELEN 255=0A= #define MAX_BROADCAST_SIZE 1400=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /*=0A= * Get a copy of the current port maps.=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/pmap_rmt.c = krb5-1.2.3/src/lib/rpc/pmap_rmt.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/pmap_rmt.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/pmap_rmt.c Tue Feb 5 20:24:33 2002=0A= @@ -58,7 +58,11 @@=0A= #include =0A= #define MAX_BROADCAST_SIZE 1400=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= static struct timeval timeout =3D { 3, 0 };=0A= =0A= =0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/svc.c = krb5-1.2.3/src/lib/rpc/svc.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/svc.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/svc.c Tue Feb 5 20:24:38 2002=0A= @@ -46,7 +46,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= #ifdef FD_SETSIZE=0A= static SVCXPRT **xports;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/svc_auth_gssapi.c = krb5-1.2.3/src/lib/rpc/svc_auth_gssapi.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/svc_auth_gssapi.c Wed Jan 9 17:27:59 = 2002=0A= +++ krb5-1.2.3/src/lib/rpc/svc_auth_gssapi.c Tue Feb 5 20:24:45 2002=0A= @@ -115,7 +115,11 @@=0A= =0A= static client_list *clients =3D NULL;=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= enum auth_stat _svcauth_gssapi(rqst, msg, no_dispatch)=0A= register struct svc_req *rqst;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/svc_run.c = krb5-1.2.3/src/lib/rpc/svc_run.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/svc_run.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/svc_run.c Tue Feb 5 20:24:58 2002=0A= @@ -47,7 +47,9 @@=0A= #else=0A= int readfds;=0A= #endif /* def FD_SETSIZE */=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= =0A= for (;;) {=0A= #ifdef FD_SETSIZE=0A= diff -u -r -b -H krb5-1.2.3-orig/src/lib/rpc/svc_udp.c = krb5-1.2.3/src/lib/rpc/svc_udp.c=0A= --- krb5-1.2.3-orig/src/lib/rpc/svc_udp.c Wed Jan 9 17:27:59 2002=0A= +++ krb5-1.2.3/src/lib/rpc/svc_udp.c Tue Feb 5 20:25:04 2002=0A= @@ -72,7 +72,11 @@=0A= svcudp_destroy=0A= };=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /*=0A= * kept in xprt->xp_p2=0A= diff -u -r -b -H krb5-1.2.3-orig/src/tests/dejagnu/t_inetd.c = krb5-1.2.3/src/tests/dejagnu/t_inetd.c=0A= --- krb5-1.2.3-orig/src/tests/dejagnu/t_inetd.c Wed Jan 9 17:28:18 2002=0A= +++ krb5-1.2.3/src/tests/dejagnu/t_inetd.c Tue Feb 5 20:25:09 2002=0A= @@ -55,7 +55,12 @@=0A= =0A= #include "com_err.h"=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= +=0A= =0A= char *progname;=0A= =0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/db2/clib/mkstemp.c = krb5-1.2.3/src/util/db2/clib/mkstemp.c=0A= --- krb5-1.2.3-orig/src/util/db2/clib/mkstemp.c Wed Jan 9 17:28:29 2002=0A= +++ krb5-1.2.3/src/util/db2/clib/mkstemp.c Tue Feb 5 20:25:19 2002=0A= @@ -61,7 +61,9 @@=0A= char *path;=0A= register int *doopen;=0A= {=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#endif=0A= register char *start, *trv;=0A= struct stat sbuf;=0A= u_int pid;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/db2/test/SEQ_TEST/t.c = krb5-1.2.3/src/util/db2/test/SEQ_TEST/t.c=0A= --- krb5-1.2.3-orig/src/util/db2/test/SEQ_TEST/t.c Wed Jan 9 17:28:33 = 2002=0A= +++ krb5-1.2.3/src/util/db2/test/SEQ_TEST/t.c Tue Feb 5 20:25:25 2002=0A= @@ -8,7 +8,11 @@=0A= #include =0A= #include =0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= void main(int argc, char *argv[]) {=0A= char id1[] =3D {" "}, id2[] =3D {" "};=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/et/compile_et.c = krb5-1.2.3/src/util/et/compile_et.c=0A= --- krb5-1.2.3-orig/src/util/et/compile_et.c Wed Jan 9 17:28:36 2002=0A= +++ krb5-1.2.3/src/util/et/compile_et.c Tue Feb 5 20:25:29 2002=0A= @@ -29,7 +29,11 @@=0A= =0A= /* C library */=0A= extern char *malloc();=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /* lex stuff */=0A= extern FILE *yyin;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/pty/update_utmp.c = krb5-1.2.3/src/util/pty/update_utmp.c=0A= --- krb5-1.2.3-orig/src/util/pty/update_utmp.c Wed Jan 9 17:28:37 2002=0A= +++ krb5-1.2.3/src/util/pty/update_utmp.c Tue Feb 5 23:22:37 2002=0A= @@ -344,6 +344,18 @@=0A= #define PTY_ENDUTXENT endutent=0A= #endif=0A= =0A= +#ifdef __CYGWIN__=0A= +#include =0A= +/* JALONSO: Don't have pututline, so make one up... */=0A= +void pututline (struct utmp * newUtmp) {=0A= + FILE *utmpFile;=0A= +=0A= + utmpFile =3D fopen( UTMP_FILE, "a" );=0A= + fwrite( ( void * ) newUtmp, sizeof( struct utmp ), 1, utmpFile );=0A= + fclose( utmpFile );=0A= +}=0A= +#endif=0A= +=0A= static int better(const PTY_STRUCT_UTMPX *, const PTY_STRUCT_UTMPX *,=0A= const PTY_STRUCT_UTMPX *);=0A= static int match_pid(const PTY_STRUCT_UTMPX *,=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/ss/help.c = krb5-1.2.3/src/util/ss/help.c=0A= --- krb5-1.2.3-orig/src/util/ss/help.c Wed Jan 9 17:28:37 2002=0A= +++ krb5-1.2.3/src/util/ss/help.c Tue Feb 5 20:25:34 2002=0A= @@ -12,7 +12,11 @@=0A= #include "ss_internal.h"=0A= #include "copyright.h"=0A= =0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= void ss_help (argc, argv, sci_idx, info_ptr)=0A= int argc;=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/ss/pager.c = krb5-1.2.3/src/util/ss/pager.c=0A= --- krb5-1.2.3-orig/src/util/ss/pager.c Wed Jan 9 17:28:38 2002=0A= +++ krb5-1.2.3/src/util/ss/pager.c Tue Feb 5 20:25:39 2002=0A= @@ -17,7 +17,11 @@=0A= static char MORE[] =3D "more";=0A= extern char *_ss_pager_name;=0A= extern char *getenv();=0A= +#ifndef __CYGWIN__=0A= extern int errno;=0A= +#else=0A= +#include =0A= +#endif=0A= =0A= /*=0A= * this needs a *lot* of work....=0A= diff -u -r -b -H krb5-1.2.3-orig/src/util/ss/parse.c = krb5-1.2.3/src/util/ss/parse.c=0A= --- krb5-1.2.3-orig/src/util/ss/parse.c Wed Jan 9 17:28:38 2002=0A= +++ krb5-1.2.3/src/util/ss/parse.c Tue Feb 5 23:09:26 2002=0A= @@ -7,6 +7,9 @@=0A= #include "ss_internal.h"=0A= #include "copyright.h"=0A= =0A= +#ifdef __CYGWIN__=0A= +#include =0A= +#endif=0A= =0A= enum parse_mode { WHITESPACE, TOKEN, QUOTED_STRING };=0A= =0A= ------=_NextPart_000_0024_01C1AEAE.1405C6F0-- From hartmans@MIT.EDU Wed Feb 6 09:15:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA18967 for ; Wed, 6 Feb 2002 09:15:47 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13282 for ; Wed, 6 Feb 2002 09:15:47 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA29258; Wed, 6 Feb 2002 09:15:46 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13182; Wed, 6 Feb 2002 09:15:46 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id JAA23714; Wed, 6 Feb 2002 09:15:46 -0500 (EST) To: "Jason B. Alonso" Cc: Subject: Re: Port of Kerberos to Cygwin References: <002301c1aed7$fcdbcef0$3b03f712@mit.edu> From: Sam Hartman In-Reply-To: "Jason B. Alonso"'s message of "Wed, 6 Feb 2002 01:32:01 -0500" Message-ID: Lines: 7 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Feb 6 09:16:01 2002 X-Original-Date: 06 Feb 2002 09:15:46 -0500 Actually, it's always wrong to declare errno. On the 4.3BSD vax I have access to, errno is declared in sys/errno.h. I don't have an account on any machines older than that now, but really Kerberos wouldn't even build on that. So a patch to fix cases where errno is declared would be fairly likely to be accepted. From hartmans@MIT.EDU Thu Feb 7 14:35:44 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA25019 for ; Thu, 7 Feb 2002 14:35:43 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02340 for ; Thu, 7 Feb 2002 14:35:43 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA13573; Thu, 7 Feb 2002 14:35:43 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12434; Thu, 7 Feb 2002 14:35:43 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id OAA24382; Thu, 7 Feb 2002 14:35:42 -0500 (EST) Message-Id: <200202071935.OAA24382@tir-na-nogth.mit.edu> From: Sam Hartman To: krbdev@MIT.EDU CC: amu@MIT.EDU Subject: krb5_rd_cred checks IP address. Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 7 14:36:01 2002 X-Original-Date: Thu, 7 Feb 2002 14:35:42 -0500 (EST) amu recently filed a Debian bug against my ssh-krb5 package complaining that when he forwarded addressless tickets from behind a NAT using ssh protocol version 1 to a new server, it didn't work. It turns out all of those qualifiers are necessary to reproduce the bug; change one and it works fine. Well, OK, if you get addressful tickets behind a NAT, it fails much earlier Here's the problem. Our implementation of krb5_rd_cread checks the source address to make sure it matches the source address in the KRB-CRED structure. It turns out it only does this if the krb-cred structure is encrypted. It turns out that you'll only encrypt the structure under the ssh v1 forwarding mechanism when a new client talks to a new server. I'm not really sure what good this check does other than to screw over NAT users. Even if we pretend that we actually still care about IP address authentication what is the harm of accepting tickets from someone provided that they work? I'm really not sure how to go about fixing this problem. I could see solving in several ways and am not sure which one the community prefers. Do we remove the check on the source address? Do we do something special if you are forwarding addressless tickets? From smch@midway.uchicago.edu Thu Feb 7 16:26:55 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA25361 for ; Thu, 7 Feb 2002 16:26:54 -0500 (EST) Received: from kilroy.uchicago.edu (kilroy.uchicago.edu [128.135.99.99]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA09290; Thu, 7 Feb 2002 16:26:39 -0500 (EST) Received: from localhost (smch@localhost) by kilroy.uchicago.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA01916; Thu, 7 Feb 2002 15:26:38 -0600 (CST) X-Authentication-Warning: kilroy.uchicago.edu: smch owned process doing -bs From: Steven Michaud X-Sender: smch@kilroy.uchicago.edu To: Sam Hartman cc: krbdev@mit.edu, amu@mit.edu Subject: Re: krb5_rd_cred checks IP address. In-Reply-To: <200202071935.OAA24382@tir-na-nogth.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 7 16:27:01 2002 X-Original-Date: Thu, 7 Feb 2002 15:26:37 -0600 (CST) Why not figure out a way to leave the address-checking decision up to the application server? (I.e. why not let whoever runs the application server use a command-line parameter to determine whether or not address-checking will be done?) GSSAPI application servers use gss_accept_sec_context(). Currently (release 1.2.3) krb5_rd_cred() doesn't do any address checking unless at least one of the following members of its second parameter (krb5_auth_context auth_context) is non-null -- auth_context->local_addr or auth_context->remote_addr. When krb5_rd_cred() is called from gss_accept_sec_context(), auth_context->local_addr is always null (as you'd expect). (It's set by the call to krb5_auth_con_setaddrs() just beforehand.) But when gss_accept_sec_context() has been called with its input_chan_bindings parameter set to GSS_C_NO_CHANNEL_BINDINGS, auth_context->remote_addr is also null. (Otherwise it gets set to the address specified in input_chan_bindings.) If this is OK for GSSAPI application servers, why not also for ssh-krb5? Of course GSSAPI application servers have _other_ problems with NAT -- they still fail if the _client_ sends any channel bindings (the failure takes place at line 423 -- the call to kg_checksum_channel_bindings() -- accept_sec_context.c). But that's another story :-) By the way, for those who might be interested, I've ported my NAT fixes from release 1.2.2 to 1.2.3. I've tested them for about a week and they seem to work fine. When I get a chance I'll post them here. On Thu, 7 Feb 2002, Sam Hartman wrote: > > > amu recently filed a Debian bug against my ssh-krb5 package > complaining that when he forwarded addressless tickets from behind a > NAT using ssh protocol version 1 to a new server, it didn't work. It > turns out all of those qualifiers are necessary to reproduce the bug; > change one and it works fine. Well, OK, if you get addressful tickets > behind a NAT, it fails much earlier > > > Here's the problem. Our implementation of krb5_rd_cread checks the > source address to make sure it matches the source address in the > KRB-CRED structure. It turns out it only does this if the krb-cred > structure is encrypted. It turns out that you'll only encrypt the > structure under the ssh v1 forwarding mechanism when a new client > talks to a new server. > > I'm not really sure what good this check does other than to screw over > NAT users. Even if we pretend that we actually still care about IP > address authentication what is the harm of accepting tickets from > someone provided that they work? > > I'm really not sure how to go about fixing this problem. I could see > solving in several ways and am not sure which one the community > prefers. Do we remove the check on the source address? Do we do > something special if you are forwarding addressless tickets? > _______________________________________________ > krbdev mailing list krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev > From hartmans@MIT.EDU Thu Feb 7 16:31:04 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA25415 for ; Thu, 7 Feb 2002 16:31:04 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA27346; Thu, 7 Feb 2002 16:31:04 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA09529; Thu, 7 Feb 2002 16:31:03 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11771; Thu, 7 Feb 2002 16:31:03 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id QAA24501; Thu, 7 Feb 2002 16:31:03 -0500 (EST) To: Steven Michaud Cc: krbdev@MIT.EDU, amu@MIT.EDU Subject: Re: krb5_rd_cred checks IP address. References: From: Sam Hartman In-Reply-To: Steven Michaud's message of "Thu, 7 Feb 2002 15:26:37 -0600 (CST)" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 7 16:32:00 2002 X-Original-Date: 07 Feb 2002 16:31:03 -0500 >>>>> "Steven" == Steven Michaud writes: Steven> Why not figure out a way to leave the address-checking decision up to Steven> the application server? (I.e. why not let whoever runs the Steven> application server use a command-line parameter to determine whether Steven> or not address-checking will be done?) OK, I think my argument would be that address checking is even less useful for rd_cred than for rd_req. From P2blackjack@netscape.net Thu Feb 7 17:34:53 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA25707 for ; Thu, 7 Feb 2002 17:34:52 -0500 (EST) From: P2blackjack@netscape.net Received: from station.blackjackstation.com ([196.40.46.164]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA09222 for ; Thu, 7 Feb 2002 17:34:52 -0500 (EST) Received: from CAMPAIGN ([196.40.15.212]) by station.blackjackstation.com with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 7 Feb 2002 16:22:16 -0800 To: Subject: Worlds FIRST Player vs Player Blackjack MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ Boundary 1-KTwEv4jY84Hk" Message-ID: <07b681622000822STATION@station.blackjackstation.com> Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 7 17:35:01 2002 X-Original-Date: Thu, 07 Feb 2002 16:28:19 --=_ Boundary 1-KTwEv4jY84Hk Content-Type: text/plain; charset = "ISO-8859-1" Content-Transfer-Encoding: 7bit This message can only be viewed in HTML --=_ Boundary 1-KTwEv4jY84Hk Content-Type: text/html; charset = "ISO-8859-1" Content-Transfer-Encoding: 7bit

 




NEW 25 cent tables!

Blackjack Shack eliminates the traditional casino House and transfers the House advantage to players. Players compete in one-on-one sessions against each other and never play against the House. Our game is similar to a poker room where the House only serves as host and never competes against players. This is the only blackjack game in existence where player skill determines the advantage. Success is measured by how well you play, not how lucky you are.

Test our game today and you'll see why we have the most fair and credible blackjack game on the planet.

Come join other blackjack enthusiasts from all over the world and play for fun or for real money.

"Highly recommended" - Smartergaming.com

Blackjackshack.com

To unsubscribe please reply to: offshack@hotmail.com








--=_ Boundary 1-KTwEv4jY84Hk-- --=_ Boundary 1-KTwEv4jY84Hk-- From smch@midway.uchicago.edu Fri Feb 8 11:10:02 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA28814 for ; Fri, 8 Feb 2002 11:10:01 -0500 (EST) Received: from kilroy.uchicago.edu (kilroy.uchicago.edu [128.135.99.99]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20420; Fri, 8 Feb 2002 11:10:01 -0500 (EST) Received: from localhost (smch@localhost) by kilroy.uchicago.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA02866; Fri, 8 Feb 2002 10:10:01 -0600 (CST) X-Authentication-Warning: kilroy.uchicago.edu: smch owned process doing -bs From: Steven Michaud X-Sender: smch@kilroy.uchicago.edu To: Sam Hartman cc: Steven Michaud , krbdev@MIT.EDU, amu@MIT.EDU Subject: Re: krb5_rd_cred checks IP address. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 11:11:00 2002 X-Original-Date: Fri, 8 Feb 2002 10:10:00 -0600 (CST) Yes, if you take address checking out of krb5_rd_req() (and its relatives), there's no point leaving it in krb5_rd_cred(). Are you really thinking of doing that? Then even a KDC couldn't check the addresses in a (addressful) TGT when a request came in for a service ticket. Actually, I'd be happy to see all address checking disappear except that done by the KDC. Including GSSAPI's channel bindings. Like you said with respect to krb5_rd_cred(), non-KDC address checking just makes life miserable for NAT users without appreciably increasing security. But GSSAPI is a published standard, and people may (for whatever reason) still want to use the other non-KDC address checking. If they want to wear this particular hair shirt, why not let them do so, if they choose? :-) On 7 Feb 2002, Sam Hartman wrote: > >>>>> "Steven" == Steven Michaud writes: > > Steven> Why not figure out a way to leave the address-checking decision up > Steven> to the application server? (I.e. why not let whoever runs the > Steven> application server use a command-line parameter to determine whether > Steven> or not address-checking will be done?) > > OK, I think my argument would be that address checking is even less > useful for rd_cred than for rd_req. > > From bbense@shred.stanford.edu Fri Feb 8 11:15:30 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA28920 for ; Fri, 8 Feb 2002 11:15:30 -0500 (EST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA04985; Fri, 8 Feb 2002 11:15:29 -0500 (EST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g18GFSk13508; Fri, 8 Feb 2002 08:15:28 -0800 (PST) From: "Booker C. Bense" To: Sam Hartman cc: krbdev@mit.edu, Subject: Re: krb5_rd_cred checks IP address. In-Reply-To: <200202071935.OAA24382@tir-na-nogth.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 11:16:01 2002 X-Original-Date: Fri, 8 Feb 2002 08:15:28 -0800 (PST) On Thu, 7 Feb 2002, Sam Hartman wrote: > > > amu recently filed a Debian bug against my ssh-krb5 package > complaining that when he forwarded addressless tickets from behind a > NAT using ssh protocol version 1 to a new server, it didn't work. It > turns out all of those qualifiers are necessary to reproduce the bug; > change one and it works fine. Well, OK, if you get addressful tickets > behind a NAT, it fails much earlier > > > Here's the problem. Our implementation of krb5_rd_cread checks the > source address to make sure it matches the source address in the > KRB-CRED structure. It turns out it only does this if the krb-cred > structure is encrypted. It turns out that you'll only encrypt the > structure under the ssh v1 forwarding mechanism when a new client > talks to a new server. > > I'm not really sure what good this check does other than to screw over > NAT users. Even if we pretend that we actually still care about IP > address authentication what is the harm of accepting tickets from > someone provided that they work? - I can't see one. The whole rational for the IP check is to make replay attacks harder, but I don't grok how that would even apply in this situation. > > I'm really not sure how to go about fixing this problem. I could see > solving in several ways and am not sure which one the community > prefers. Do we remove the check on the source address? - I would vote for this option. The IP checks have always seemed to me to be the wrong solution to replay attacks, it doesn't really solve the problem. A session key cache does. - Booker C. Bense From bbense@shred.stanford.edu Fri Feb 8 11:30:13 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA29028 for ; Fri, 8 Feb 2002 11:30:13 -0500 (EST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29637 for ; Fri, 8 Feb 2002 11:30:12 -0500 (EST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g18GUC113580 for ; Fri, 8 Feb 2002 08:30:12 -0800 (PST) From: "Booker C. Bense" To: krbdev@mit.edu Subject: Re: krb5_rd_cred checks IP address. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 11:31:00 2002 X-Original-Date: Fri, 8 Feb 2002 08:30:12 -0800 (PST) On Fri, 8 Feb 2002, Steven Michaud wrote: > Yes, if you take address checking out of krb5_rd_req() (and its > relatives), there's no point leaving it in krb5_rd_cred(). Are you > really thinking of doing that? Then even a KDC couldn't check the > addresses in a (addressful) TGT when a request came in for a service > ticket. > > Actually, I'd be happy to see all address checking disappear except > that done by the KDC. Including GSSAPI's channel bindings. Like you > said with respect to krb5_rd_cred(), non-KDC address checking just > makes life miserable for NAT users without appreciably increasing > security. But GSSAPI is a published standard, and people may (for > whatever reason) still want to use the other non-KDC address checking. > If they want to wear this particular hair shirt, why not let them do > so, if they choose? :-) > - What I did in our copy of the MIT code in the K4 tree was to key IP address checking in krb_rd_req on an environmental variable. Yes, this is evil, but at least when the hair shirt people show up I have a switch to give them. - You can see this and a lot of other patches at http://www.stanford.edu/~bbense/stanford_krb_patches - I was waiting to announce this until I could put some comments about what these various things do and I updated the tree to 1.2.3, but those things don't seem to be happening and since things are pretty up in the air at Stanford these days, I can't guarantee how long they'll be available. - Booker C. Bense From Nicolas.Williams@ubsw.com Fri Feb 8 11:30:26 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA29033 for ; Fri, 8 Feb 2002 11:30:26 -0500 (EST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29734; Fri, 8 Feb 2002 11:30:25 -0500 (EST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id LAB24224; Fri, 8 Feb 2002 11:33:28 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma018013; Fri, 8 Feb 2002 11:31:46 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id LAA12078; Fri, 8 Feb 2002 11:28: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 LAA07832; Fri, 8 Feb 2002 11:28:36 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id LAA02832; Fri, 8 Feb 2002 11:27:41 -0500 (EST) From: Nicolas Williams To: "Booker C. Bense" Cc: Sam Hartman , krbdev@mit.edu, amu@mit.edu Subject: Re: krb5_rd_cred checks IP address. Message-ID: <20020208112740.U27171@sm2p1386swk.wdr.com> Mail-Followup-To: "Booker C. Bense" , Sam Hartman , krbdev@mit.edu, amu@mit.edu References: <200202071935.OAA24382@tir-na-nogth.mit.edu> 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 Fri, Feb 08, 2002 at 08:15:28AM -0800 Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 11:31:10 2002 X-Original-Date: Fri, 8 Feb 2002 11:27:41 -0500 On Fri, Feb 08, 2002 at 08:15:28AM -0800, Booker C. Bense wrote: > On Thu, 7 Feb 2002, Sam Hartman wrote: > > > I'm not really sure what good this check does other than to screw over > > NAT users. Even if we pretend that we actually still care about IP > > address authentication what is the harm of accepting tickets from > > someone provided that they work? > > - I can't see one. The whole rational for the IP check is to make > replay attacks harder, but I don't grok how that would even apply > in this situation. I thought limiting the use of stolen creds was one of the rationales for having those IP address checks... Of course, if you steal forwardable creds you probably have access to the host where they must be used and then you can do whatever you want... > > > > I'm really not sure how to go about fixing this problem. I could see > > solving in several ways and am not sure which one the community > > prefers. Do we remove the check on the source address? > > - I would vote for this option. The IP checks have always seemed to > me to be the wrong solution to replay attacks, it doesn't really > solve the problem. A session key cache does. > > - Booker C. Bense Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tlyu@MIT.EDU Fri Feb 8 16:06:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA00240 for ; Fri, 8 Feb 2002 16:06:34 -0500 (EST) Received: from saint-elmos-fire.mit.edu (SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08639 for ; Fri, 8 Feb 2002 16:06:34 -0500 (EST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id QAA12582; Fri, 8 Feb 2002 16:06:35 -0500 (EST) To: krbdev@MIT.EDU Subject: krb5-1.2.4-beta1 available From: Tom Yu Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 16:07:01 2002 X-Original-Date: 08 Feb 2002 16:06:34 -0500 I've posted krb5-1.2.4-beta1 on the MIT Kerberos web page, http://web.mit.edu/kerberos/www/ This is primarily a bugfix release; the final 1.2.4 release will probably happen in a week or two. Please test this beta release and report any critical bugs in the next week. The major changes include fixes to the off-by-one error in login.krb5 that prevented users with 8-character usernames from logging in, as well as a fix to work around the 8-bit kvno problem. ---Tom From mjv@MIT.EDU Fri Feb 8 16:34:33 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA00377 for ; Fri, 8 Feb 2002 16:34:33 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20243; Fri, 8 Feb 2002 16:34:32 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA16926; Fri, 8 Feb 2002 16:34:32 -0500 (EST) Received: from [18.18.1.144] (ETTLINGER-TOR.MIT.EDU [18.18.1.144]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08892; Fri, 8 Feb 2002 16:34:32 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@hesiod (Unverified) Message-Id: To: krbdev@MIT.EDU From: Marshall Vale Subject: Kerberos for Macintosh 4.0fc1 released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 16:35:00 2002 X-Original-Date: Fri, 8 Feb 2002 16:34:11 -0500 The MIT MacDev team is pleased to announce the availability of Kerberos for Macintosh 4.0fc1. This release is available from the MIT Kerberos site: Follow the "Getting Kerberos from MIT" link. All feedback and bug reports for Kerberos for Macintosh 4.0fc1 should be sent to Kerberos for Macintosh 4.0 has now reached the final candidate stage, which means the end of the testing cycle is near. If you discover any problems, please report them *immediately*. Overview -------- Kerberos for Macintosh 4.0 expands and improves native support for Mac OS X as well as including the new UI elements for Mac OS 9 introduced in KfM 3.5. NOTE: This is a time-limited test release of Kerberos for Macintosh. It will expire after April 4, 2002. An updated release should be available before April 4, 2002, check at that time. Kerberos for Macintosh 4.0fc1 requires a Power Macintosh with Mac OS X 10.1.2 or later for the Mac OS X version, or Mac OS 8.1 or later for the Mac OS 8 & 9 version. The installer read mes are slightly out of date and contain a few inaccuracies: Mac OS X 10.1.2 or later is now required for KfM 4.0 on OS X. Installs on UFS volumes are now supported on OS X. Changes since Kerberos For Macintosh 4.0b7 ------------------------------------------ * Mac OS X: now requires Mac OS X 10.1.2 or later * Mac OS X: Kerberos Login dialog floats above all windows * Mac OS X: Authenticator will now get v4 tickets for non-admin users * Mac OS X: Kerberos application icon now distinctly different from the ticket status icons * Mac OS X: New "show ticket list window at startup" preference in Kerberos application * Mac OS X: Installer installs /usr/include headers again (only if OS X developer tools are installed) * Mac OS X: Installer now forces restart at end of the install * Mac OS X/9: Classic ticket sharing won't get out of sync with OS X * Mac OS X/9: Auto-detect string-to-key type * Mac OS X/9: Spinning cursor displayed while waiting for OS X Kerberos Login dialog to come up from Classic * Mac OS X/9: Applications that immediately request a Kerberos login will display login dialog when launching Classic with the app * Mac OS X/9: Applications that immediately request a Kerberos login don't prompt unnecessarily for tickets when launching Classic with the app * Mac OS X/9: krb_get_tf_realm() doesn't crash when there's no TGT (instead returns "no ticket" error) * Mac OS X/9: get_ad_tkt() and krb_get_ticket_for_service() now display Kerberos Login dialog * Mac OS X/9: krb_get_cred() will not display Kerberos Login dialog when asking for a TGT * Mac OS X/9: Fixed profile library handling of unreadable files * Mac OS X/9: Fixed CFM version numbers of UtilitiesLib and MoreFilesLib (back to being compatible with previous releases) * Mac OS X/9: Classic Idle event handlers called by OS X Kerberos Login dialog * Mac OS X/9: Kerberos Login dialog slider now supports lifetimes > 99 hours and ranges > 1000 hours Known problems in this release ------------------------------ * Mac OS 8: Not functional on Mac OS 8.1 * Mac OS X: Installer does not enforce 10.1.2 minimum requirement * Mac OS X/9: When acquiring initial tickets in a realm with Kerberos 4 support, all Kerberos 4 errors are reported at "password incorrect" We have added extra debugging code that may cause asserts or errors to happen when using the Classic/Mac OS X ticket sharing feature. Please report any errors you may receive with a description of what you were doing when they happened to aid us in debugging. If you built an application that linked against the /usr/lib dylibs in KfM 4.0b2 or earlier, or the ones included with Mac OS X 10.1, you will need to re-link your application to work with the KfM 4.0b3 dylibs. Your application will no longer work with pre-4.0b3 releases, however. Ticket Sharing Between Mac OS X and Classic ------------------------------------------- In order for Kerberos tickets to be shared between Mac OS X and Classic, the same version of KfM 4.0 must be installed on both the OS X and Classic systems. When updating from a previous release, you should install the Classic KfM first, then the OS X KfM to prevent possible conflicts. When an application running under Classic needs to display the Kerberos Login dialog, the Mac OS X dialog will appear. The Mac OS 9 version of KfM 4.0 detects whether it is running under Mac OS X/Classic or regular Mac OS 9.x and automatically enables support for ticket sharing when possible. Distribution Info ----------------- At this point in time, this release is available as a single package which includes both installers and SDKs. The installers install binaries for people to use with their applications in their environments. The SDKs are for application and library programmers to add Kerberos functionality to their code or update to newer versions of the various Kerberos APIs. Source code for this release will not be made available. From deengert@anl.gov Fri Feb 8 17:38:22 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA00652 for ; Fri, 8 Feb 2002 17:38:22 -0500 (EST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA14366; Fri, 8 Feb 2002 17:38:20 -0500 (EST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA03165; Fri, 8 Feb 2002 16:38:20 -0600 (CST) Message-ID: <3C645359.A04058C6@anl.gov> From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Yu CC: krbdev@mit.edu Subject: Re: krb5-1.2.4-beta1 available References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 17:39:00 2002 X-Original-Date: Fri, 08 Feb 2002 16:38:17 -0600 Tom Yu wrote: > > I've posted krb5-1.2.4-beta1 on the MIT Kerberos web page, > http://web.mit.edu/kerberos/www/ What! I just got 1.2.3 running, you can't come out with a new one this soon! :-) > > This is primarily a bugfix release; the final 1.2.4 release will > probably happen in a week or two. Please test this beta release and > report any critical bugs in the next week. > > The major changes include fixes to the off-by-one error in login.krb5 > that prevented users with 8-character usernames from logging in, as > well as a fix to work around the 8-bit kvno problem. Have you ever considered a send it your favorite patch release? There are lots of people, including myself, who have some favorite changes they would like to see in the release.Some of us hav be caring these forward for years, even though they have been submitted but never picked. > > ---Tom > _______________________________________________ > krbdev mailing list krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hartmans@MIT.EDU Fri Feb 8 17:47:32 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA00700 for ; Fri, 8 Feb 2002 17:47:32 -0500 (EST) Received: from industrial-algebra.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28238 for ; Fri, 8 Feb 2002 17:47:32 -0500 (EST) Received: by industrial-algebra.mit.edu (Postfix, from userid 8042) id 72249151D07; Fri, 8 Feb 2002 17:47:30 -0500 (EST) To: krbdev@MIT.EDU Subject: Character set conversion Message-Id: <20020208224730.72249151D07@industrial-algebra.mit.edu> From: hartmans@MIT.EDU (Sam Hartman) Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 17:48:00 2002 X-Original-Date: Fri, 8 Feb 2002 17:47:30 -0500 (EST) Hi. Within the IETF working group on Kerberos, we are currently considering various internationalization issues. The intent is to move the Kerberos protocol to use UTF-8 internally. We can do that, but we need to provide backward compatibility for some sites that already have non-US-ASCII principals deployed. We have received a strong request for this backward compatibility from the DCE community. I'm wondering if there are sites currently using multiple different encodings for principal names within the same realm. I believe that this situations could result for example using KFM because the GUI tools use a different encoding than the command line tools. We ask this question in part because most of our solutions require that the KDC be able to map between encodings. This is much easier to set up if you have one encoding for the entire realm. --Sam From hartmans@MIT.EDU Fri Feb 8 17:55:10 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA00745 for ; Fri, 8 Feb 2002 17:55:09 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01120; Fri, 8 Feb 2002 17:55:09 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA25567; Fri, 8 Feb 2002 17:55:09 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA05280; Fri, 8 Feb 2002 17:55:09 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id RAA24986; Fri, 8 Feb 2002 17:55:08 -0500 (EST) To: "Douglas E. Engert" Cc: Tom Yu , krbdev@MIT.EDU Subject: Re: krb5-1.2.4-beta1 available References: <3C645359.A04058C6@anl.gov> From: Sam Hartman In-Reply-To: "Douglas E. Engert"'s message of "Fri, 08 Feb 2002 16:38:17 -0600" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 8 17:56:00 2002 X-Original-Date: 08 Feb 2002 17:55:08 -0500 >>>>> "Douglas" == Douglas E Engert writes: Douglas> Have you ever considered a send it your favorite patch release? There Douglas> are lots of people, including myself, who have some favorite changes they Douglas> would like to see in the release.Some of us hav be caring these forward Douglas> for years, even though they have been submitted but never picked. Note that it has been years since we've cut a new branch off our trunk. We do try to go through the outstanding bug reports before a branch cut. We actually need to get better about applying patches to the mainline in between all out bug dealing-with events. I am working on evaluating various improvements to how we track bugs. Universally present in everything we are considering is the ability for people to go check on the status of their patches. I also have some ideas on mechanisms we could use to get customer feedback on what bugs would be important for people to pull into the release. These ideas are just mine and I haven't run them by powers-that-be yet, so no telling what will actually happen. It is clear though that we are interested in better mechanisms to know what people who use our software care about. Note that we'll still probably reject a lot of patches. We're running with somewhat different of a philosophy than some other open-source projects. For example the OpenAFS people claim they haven't rejected a patch yet; we have a different approach. m From akosut@Stanford.EDU Sat Feb 9 19:20:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA05113 for ; Sat, 9 Feb 2002 19:20:35 -0500 (EST) Received: from fable8.Stanford.EDU (fable8.Stanford.EDU [171.64.15.201]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA20390 for ; Sat, 9 Feb 2002 19:20:34 -0500 (EST) Received: (from akosut@localhost) by fable8.Stanford.EDU (8.11.6/8.11.6) id g1A0KYM08910 for krbdev@mit.edu; Sat, 9 Feb 2002 16:20:34 -0800 (PST) From: Alexei Kosut To: krbdev@mit.edu Subject: Re: Kerberos for Macintosh 4.0fc1 released Message-ID: <20020209162033.A8853@stanford.edu> Mail-Followup-To: krbdev@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mjv@mit.edu on Fri, Feb 08, 2002 at 04:34:11PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Sat Feb 9 19:21:00 2002 X-Original-Date: Sat, 9 Feb 2002 16:20:34 -0800 One note on KfM 4.0fc1: It seems like CCacheClassicServer.app may have a memory leak. I woke up this morning to find that it was using 318 megs of virtual memory, and seems to be growing at a rate of a little over 3k per second! I restarted my Mac, started Classic, and it seemed to be growing at the same rate. Other that that, though, I'm very happy with 4.0fc1; I haven't found any other problems with it. -- Alexei Kosut From bbense@shred.stanford.edu Mon Feb 11 11:29:29 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA12541 for ; Mon, 11 Feb 2002 11:29:29 -0500 (EST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25732 for ; Mon, 11 Feb 2002 11:29:28 -0500 (EST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g1BGTR608851 for ; Mon, 11 Feb 2002 08:29:27 -0800 (PST) From: "Booker C. Bense" To: krbdev@mit.edu Subject: Interesting experiment In-Reply-To: <20020209162033.A8853@stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 11 11:30:00 2002 X-Original-Date: Mon, 11 Feb 2002 08:29:27 -0800 (PST) - Recently, while helping a vendor install some kerberized software, a interesting experiment took place by accident. In the start up file for the deamon, KRB5_CONFIG was set to point to the keytab rather than the krb5.conf file. - In one sense, the results were pretty encouraging. The application actually ran just fine with garbage data in krb5.conf. It didn't work, but it didn't dump core either. In another sense, it was sort of discouraging in that the library didn't report any kind of meaningful error. Basically it was saying it couldn't find the service principal in the keytab file. - I'm not sure where I'm going with this, but it was sort of interesting to see what actually happened. - Booker C. Bense From Nicolas.Williams@ubsw.com Mon Feb 11 14:28:09 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA13247 for ; Mon, 11 Feb 2002 14:28:09 -0500 (EST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA10121 for ; Mon, 11 Feb 2002 14:28:08 -0500 (EST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id OAA10441 for ; Mon, 11 Feb 2002 14:28:02 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma010108; Mon, 11 Feb 2002 14:27:46 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id OAA19395 for ; Mon, 11 Feb 2002 14:29:36 -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 OAA07722 for ; Mon, 11 Feb 2002 14:27:28 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id OAA15206 for krbdev@mit.edu; Mon, 11 Feb 2002 14:26:26 -0500 (EST) From: Nicolas Williams To: krbdev@mit.edu Subject: v5passwdd story? Message-ID: <20020211142624.N27171@sm2p1386swk.wdr.com> Mail-Followup-To: krbdev@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 11 14:29:00 2002 X-Original-Date: Mon, 11 Feb 2002 14:26:26 -0500 What is the history behind v5passwdd, and, is it deprecated? From what I can see it's a poor-man's kadmin/kadmind that has been stripped of anything but password changing functionality, or perhaps it never had anything but password changing functionality. It seems like it used to use the same port as kadmind, it used to use a service principal name of "changepw/REALM@REALM" and other oddities. Its usage() still claims to be kadmind and it still tries using the "kpasswd" service name, though in an earlier past it used kerberos-adm, apparently. Does anyone actually use v5passwd/v5passwdd? Thanks, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From crawdad@gungnir.fnal.gov Mon Feb 11 17:33:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA14005 for ; Mon, 11 Feb 2002 17:33:50 -0500 (EST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02763 for ; Mon, 11 Feb 2002 17:33:50 -0500 (EST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GRE0093640EKU@smtp.fnal.gov> for krbdev@mit.edu; Mon, 11 Feb 2002 16:33:50 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1BMXnZ22205; Mon, 11 Feb 2002 16:33:49 -0600 (CST) From: Matt Crawford Subject: Re: v5passwdd story? In-reply-to: "11 Feb 2002 14:26:26 EST." <20020211142624.N27171@sm2p1386swk.wdr.com> To: Nicolas Williams Cc: krbdev@mit.edu Message-id: <200202112233.g1BMXnZ22205@gungnir.fnal.gov> Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 11 17:34:00 2002 X-Original-Date: Mon, 11 Feb 2002 16:33:48 -0600 > What is the history behind v5passwdd, and, is it deprecated? > > Does anyone actually use v5passwd/v5passwdd? I discovered that I had to turn on this service to allow WRQ/Reflection Kerberos users to change passwords. They are turning out software updates relatively often now, so perhaps I'll be able to drop this service in the foreseeable future. From majortom@doar.math.uic.edu Tue Feb 12 16:15:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA18374 for ; Tue, 12 Feb 2002 16:15:27 -0500 (EST) Received: from doar2.rfc-holdings.com ([67.36.111.145]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id QAA02868 for ; Tue, 12 Feb 2002 16:15:05 -0500 (EST) Received: (qmail 14359 invoked from network); 12 Feb 2002 21:14:56 -0000 Received: from unknown (HELO CAESARIA2) (192.168.254.230) by 192.168.254.230 with SMTP; 12 Feb 2002 21:14:56 -0000 Message-ID: <02dd01c1b40d$eb2eec60$89e01ad1@rfcholdings.com> From: "Carmi Weinzweig" To: Subject: Problems with Kerberos for Mac OS X and FreeBSD Kerberos 5 server. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02D9_01C1B3CA.1A5A8470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 12 16:16:01 2002 X-Original-Date: Tue, 12 Feb 2002 13:35:11 -0800 This is a multi-part message in MIME format. ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02DA_01C1B3CA.1A622590" ------=_NextPart_001_02DA_01C1B3CA.1A622590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. I am trying to set up a small Kerberos testbed (using my home = systems) in advance of a deployment for several labs of Mac OS X = machines. I went through the Oakridge guide on how to Kerberize my site = but seem to be having problems somewhere (I assume that I have a = configuration file wrong some where, but I can't really figure out = where. Since I am using the Mac OS X beta on an OS X system running UFS = (instead of the guaranteed insecure HFS), I am not sure exactly what the = problem is. Scott McGuire suggested that I send this list mail for some = help. My testbed is very simple: 1 FreeBSD server (Version 4.5) running the krb5 package that = installs Kerberos 5-1.2.3 which acts as the KDC. It is listed in DNS as = yavneh.wg.rfc-holdings.com with an IP address of 209.26.224.131 1 G4 running Mac OS 10.1.2 with the Kfm 4.0b7 installed. It is not = listed in DNS although it is locally known as = massada.wg.rfc-holdings.com with an IP address of 209.26.224.133 I have included the two configuration files from the FreeBSD system and = the configuration file from the Mac, as well as the two log files from = the FreeBSD system. Finally, here is the session log from typing the kinit on the mac: [massada:/Library/Preferences] majortom% kinit majortom/admin kinit(v5): Cannot contact any KDC for requested realm while getting = initial credentials Password for majortom/admin@wg.rfc-holdings.com:=20 kinit(v4): Can't send request (send_to_kdc) [massada:/Library/Preferences] majortom%=20 I am sure that I have made a simple configuration error, but I can't = figure out what it is. Any help I can get would much appreciated. Thanks in advance. /carmi ------=_NextPart_001_02DA_01C1B3CA.1A622590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello. I am trying to set up a small = Kerberos=20 testbed (using my home systems) in advance of a deployment for several = labs of=20 Mac OS X machines. I went through the Oakridge guide on how to Kerberize = my site=20 but seem to be having problems somewhere (I assume that I have a = configuration=20 file wrong some where, but I can't really figure out where. Since I am = using the=20 Mac OS X beta on an OS X system running UFS (instead of the guaranteed = insecure=20 HFS), I am not sure exactly what the problem is. Scott McGuire suggested = that I=20 send this list mail for some help.
 
My testbed is very simple:
 
    1 FreeBSD server = (Version 4.5)=20 running the krb5 package that installs Kerberos 5-1.2.3 which acts as = the KDC.=20 It is listed in DNS as yavneh.wg.rfc-holdings.com with an IP address of=20 209.26.224.131
 
    1 G4 running Mac OS = 10.1.2 with=20 the Kfm 4.0b7 installed. It is not listed in DNS although it is locally = known as=20 massada.wg.rfc-holdings.com with an IP address of = 209.26.224.133
 
I have included the two configuration = files from=20 the FreeBSD system and the configuration file from the Mac, as well as = the two=20 log files from the FreeBSD system.
 
Finally, here is the session log from = typing the=20 kinit on the mac:
[massada:/Library/Preferences] = majortom% kinit=20 majortom/admin
kinit(v5): Cannot contact any KDC for requested realm = while=20 getting initial credentials
Password for majortom/admin@wg.rfc-= holdings.com:=20
kinit(v4): Can't send request=20 (send_to_kdc)
[massada:/Library/Preferences] majortom%
 
 
 
I am sure that I have made a simple = configuration=20 error, but I can't figure out what it is. Any help I can get would much=20 appreciated.
 
Thanks in advance.
 
/carmi
 
------=_NextPart_001_02DA_01C1B3CA.1A622590-- ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: application/octet-stream; name="krb5.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="krb5.conf" [libdefaults]=0A= ticket_lifetime =3D 600=0A= default_realm =3D wg.rfc-holdings.com=0A= kdc_req_checksum_type =3D 2=0A= checksum_type =3D 2=0A= ccache_type =3D 1=0A= default_tkt_enctypes =3D des-cbc-crc=0A= default_tgs_enctypes =3D des-cbc-crc=0A= =0A= [kdc]=0A= profile =3D /usr/local/var/krb5kdc/kdc.conf=0A= =0A= [logging]=0A= kdc =3D FILE:/usr/local/var/krb5kdc/kdc.log=0A= admin_server =3D FILE:/usr/local/var/krb5kdc/adm.log=0A= default =3D FILE:/usr/local/var/krb5kdc/log.log=0A= =0A= [realms]=0A= wg.rfc-holdings.com =3D {=0A= kdc =3D yavneh.wg.rfc-holdings.com:88=0A= admin_server =3D yavneh.wg.rfc-holdings.com:749=0A= default_domain =3D wg.rfc-holdings.com=0A= }=0A= [domain_realm]=0A= .wg.rfc-holdings.com =3D wg.rfc-holdings.com=0A= wg.rfc-holdings.com =3D wg.rfc-holdings.com=0A= =0A= [capaths]=0A= =0A= [login]=0A= krb4_convert =3D 0=0A= ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: application/octet-stream; name="kdc.conf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kdc.conf" [kdcdefaults]=0A= kdc_ports =3D 88=0A= =0A= [realms]=0A= wg.rfc-holdings.com =3D {=0A= profile =3D /etc/krb5.conf=0A= database_name =3D /usr/local/var/krb5kdc/principal=0A= admin_database_name =3D /usr/local/var/krb5kdc/kadm5_adb=0A= admin_database_lockfile =3D /usr/local/var/krb5kdc/kadm5_adb.lock=0A= admin_keytab =3D FILE:/usr/local/var/krb5kdc/kadm5.keytab=0A= acl_file =3D /usr/local/var/krb5kdc/kadm5.acl=0A= key_stash_file =3D /usr/local/var/krb5kdc/.k5stash=0A= kdc_ports =3D 88=0A= kadmind_port =3D 749=0A= max_life =3D 10h 0m 0s=0A= max_renewable_life =3D 7d 0h 0m 0s=0A= master_key_type =3D des-cbc-crc=0A= supported_enctypes =3D des-cbc-crc:normal des:v4 =0A= }=0A= ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: application/octet-stream; name="kdc.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="kdc.log" Oct 26 08:20:19 yavneh.wg.rfc-holdings.com krb5kdc[73725](info): setting = up network...=0A= Oct 26 08:20:19 yavneh.wg.rfc-holdings.com krb5kdc[73725](info): = listening on fd 7: 209.26.224.131 port 88=0A= Oct 26 08:20:19 yavneh.wg.rfc-holdings.com krb5kdc[73725](info): set up = 1 sockets=0A= Oct 26 08:20:19 yavneh.wg.rfc-holdings.com krb5kdc[73726](info): = commencing operation=0A= Feb 10 21:24:12 yavneh.wg.rfc-holdings.com krb5kdc[42484](info): setting = up network...=0A= Feb 10 21:24:12 yavneh.wg.rfc-holdings.com krb5kdc[42484](info): = listening on fd 7: 209.26.224.131 port 88=0A= Feb 10 21:24:12 yavneh.wg.rfc-holdings.com krb5kdc[42484](info): set up = 1 sockets=0A= Feb 10 21:24:12 yavneh.wg.rfc-holdings.com krb5kdc[42485](info): = commencing operation=0A= Feb 10 22:56:23 yavneh.wg.rfc-holdings.com krb5kdc[42485](info): AS_REQ = (1 etypes {1}) 209.26.224.133(88): CLIENT_NOT_FOUND: = majortom/admin@wg.rfc-holdings.com for = krbtgt/wg.rfc-holdings.com@wg.rfc-holdings.com, Client not found in = Kerberos database=0A= Feb 10 22:56:24 yavneh.wg.rfc-holdings.com krb5kdc[42485](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 22:56:28 yavneh.wg.rfc-holdings.com krb5kdc[42485](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 23:06:53 yavneh.wg.rfc-holdings.com krb5kdc[42568](info): setting = up network...=0A= Feb 10 23:06:53 yavneh.wg.rfc-holdings.com krb5kdc[42568](info): = listening on fd 7: 209.26.224.131 port 88=0A= Feb 10 23:06:53 yavneh.wg.rfc-holdings.com krb5kdc[42568](info): set up = 1 sockets=0A= Feb 10 23:06:53 yavneh.wg.rfc-holdings.com krb5kdc[42569](info): = commencing operation=0A= Feb 10 23:11:49 yavneh.wg.rfc-holdings.com krb5kdc[42569](info): AS_REQ = (1 etypes {1}) 209.26.224.133(88): CLIENT_NOT_FOUND: = majortom/admin@wg.rfc-holdings.com for = krbtgt/wg.rfc-holdings.com@wg.rfc-holdings.com, Client not found in = Kerberos database=0A= Feb 10 23:11:50 yavneh.wg.rfc-holdings.com krb5kdc[42569](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 23:11:54 yavneh.wg.rfc-holdings.com krb5kdc[42569](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= krb5kdc: Cannot find/read stored master key - while fetching master key = K/M for realm rfc-holdings.com=0A= krb5kdc: Cannot find master key record in database - while verifying = master key for realm wg.rfc-holdings.com=0A= Feb 10 23:23:01 yavneh.wg.rfc-holdings.com krb5kdc[42593](info): setting = up network...=0A= Feb 10 23:23:01 yavneh.wg.rfc-holdings.com krb5kdc[42593](info): = listening on fd 7: 209.26.224.131 port 88=0A= Feb 10 23:23:01 yavneh.wg.rfc-holdings.com krb5kdc[42593](info): set up = 1 sockets=0A= Feb 10 23:23:01 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = commencing operation=0A= Feb 10 23:24:39 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): AS_REQ = (1 etypes {1}) 209.26.224.133(88): ISSUE: authtime 1013401479, etypes = {rep=3D1 tkt=3D1 ses=3D1}, majortom/admin@wg.rfc-holdings.com for = krbtgt/wg.rfc-holdings.com@wg.rfc-holdings.com=0A= Feb 10 23:24:40 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 23:24:44 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 23:25:17 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): AS_REQ = (1 etypes {1}) 209.26.224.133(88): ISSUE: authtime 1013401517, etypes = {rep=3D1 tkt=3D1 ses=3D1}, majortom/admin@wg.rfc-holdings.com for = krbtgt/wg.rfc-holdings.com@wg.rfc-holdings.com=0A= Feb 10 23:25:18 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 10 23:25:22 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 11 07:58:57 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): AS_REQ = (1 etypes {1}) 209.26.224.133(88): ISSUE: authtime 1013432337, etypes = {rep=3D1 tkt=3D1 ses=3D1}, majortom/admin@wg.rfc-holdings.com for = krbtgt/wg.rfc-holdings.com@wg.rfc-holdings.com=0A= Feb 11 07:58:58 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 11 07:59:02 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): = DISPATCH: repeated (retransmitted?) request from 209.26.224.133 port 88, = resending previous response=0A= Feb 12 15:02:45 yavneh.wg.rfc-holdings.com krb5kdc[42594](info): AS_REQ = (1 etypes {1}) 209.26.224.131(88): ISSUE: authtime 1013544165, etypes = {rep=3D1 tkt=3D1 ses=3D1}, majortom/admin@wg.rfc-holdings.com for = kadmin/admin@wg.rfc-holdings.com=0A= ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: application/octet-stream; name="adm.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="adm.log" Oct 26 08:24:24 yavneh.wg.rfc-holdings.com kadmind[73744](info): starting=0A= Feb 10 21:24:19 yavneh.wg.rfc-holdings.com kadmind[42487](info): starting=0A= Feb 10 23:07:02 yavneh.wg.rfc-holdings.com kadmind[42571](info): starting=0A= Feb 10 23:23:11 yavneh.wg.rfc-holdings.com kadmind[42596](info): starting=0A= ------=_NextPart_000_02D9_01C1B3CA.1A5A8470 Content-Type: application/octet-stream; name="edu.mit.Kerberos" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="edu.mit.Kerberos" [domain_realm]=0D .wg.rfc-holdings.com =3D wg.rfc-holdings.com=0D = wg.rfc-holdings.com =3D wg.rfc-holdings.com=0D=0D[libdefaults]=0D = default_realm =3D wg.rfc-holdings.com=0D ticket_lifetime =3D 600=0D = default_tkt_enctypes =3D des-cbc-crc=0D default_tgs_enctypes =3D = des-cbc-crc=0D=0D[realms]=0D wg.rfc-holdings.com =3D {=0D kdc =3D = yavneh.wg.rfc-holdings.com:88=0D admin_server =3D = yavneh.wg.rfc-holdings.com=0D default_domain =3D wg.rfc-holdings.com=0D = }=0D=0D[v4 realms]=0D[v4 domain_realm]=0D ------=_NextPart_000_02D9_01C1B3CA.1A5A8470-- From bbense@shred.stanford.edu Tue Feb 12 16:34:37 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA18490 for ; Tue, 12 Feb 2002 16:34:37 -0500 (EST) Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11214 for ; Tue, 12 Feb 2002 16:34:36 -0500 (EST) Received: from localhost (bbense@localhost) by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g1CLYXq02471; Tue, 12 Feb 2002 13:34:33 -0800 (PST) From: "Booker C. Bense" To: Carmi Weinzweig cc: krbdev@mit.edu Subject: Re: Problems with Kerberos for Mac OS X and FreeBSD Kerberos 5 server. In-Reply-To: <02dd01c1b40d$eb2eec60$89e01ad1@rfcholdings.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 12 16:35:00 2002 X-Original-Date: Tue, 12 Feb 2002 13:34:33 -0800 (PST) > > Finally, here is the session log from typing the kinit on the mac: > [massada:/Library/Preferences] majortom% kinit majortom/admin > kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials > Password for majortom/admin@wg.rfc-holdings.com: ^- Case is important in realm names. By default realm names are upper case. If you have wg.rfc-holdings.com in any of the config files, try changing it to WG.RFC-HOLDINGS.COM - Booker C. Bense From tcz3@cornell.edu Thu Feb 14 12:18:37 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA26726 for ; Thu, 14 Feb 2002 12:18:37 -0500 (EST) Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA12079 for ; Thu, 14 Feb 2002 12:18:37 -0500 (EST) Received: from BIARRITZ.cornell.edu (asdt128253114192.cit.cornell.edu [128.253.114.192]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA17689 for ; Thu, 14 Feb 2002 12:18:34 -0500 (EST) Message-Id: <5.1.0.14.2.20020214113235.00a8f438@postoffice2.mail.cornell.edu> X-Sender: tcz3@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: krbdev@mit.edu From: Todd Zino Subject: de facto inline mutual auth via krb5_mk_req / krb5_rd_req? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 14 12:19:00 2002 X-Original-Date: Thu, 14 Feb 2002 12:18:01 -0500 In the process of porting our low-level stateless protocol libraries from K4 to K5, I've had trouble preserving the notion of inline mutual auth that was tailored to krb4's use of explicit integer checksums in the AP_REQ calls. In the krb4 version, the dataflow was: client generates int_32 'mutual' from time() client calls krb_mk_req, providing 'mutual' as 5th arg ----authdat blob is passed to server through library protocol from client---- server calls krb_rd_req, pulls 'mutual' from checksum member of AUTH_DAT struct returned server increments 'mutual', calls krb_mk_priv with this checksum as the inbuf ----authdat blob is passed back to client through library protocol from server----- client calls krb_rd_priv and verifies that decrypted outbuf is checkum +1 In translating this to krb5, while the mk_priv and rd_priv are straightforward, I have not been able to fathom the analog for mk_req and rd_req. I'm basically looking for any piece of data, preferably a long number but maybe a short char* glob, that can be "known" by both client and server after their krb5_mk_req() and krb5_rd_req() calls are made, respectively. I do not want to create any other network exchange other than the 2 above, due to the nature of our specific protocol. I initially thought the krb5_authenticator (as authentp member of auth context) would contain this info, but a call to krb5_auth_con_getauthenticator() after a krb5_mk_req() will seg fault, because the 'client', 'checksum', and 'authorization_data' members of the authenticator are explicitly nulled out within the mk_req_call (and auth_con_get_authenticator calls copy_authenticator which expects data in the client field when it does its memset), so I have no way for the client to recover anything there to store locally after it is done krb5_mk_req() and has the AP_REQ blob. I also tried just doing myAuthContext->authentp->ctime on both sides, but the struct definition of krb5_auth_context is hidden outside of the API headers, and I don't want the unkosher effects of trying to duplicate it locally for a dubious pointer dereferencing. I'm also experimenting with providing some token in_data to krb5_mk_req(), but I can't quite figure out what happens to it on the other side when krb5_rd_req() is done. The src for krb_mk_req_extended() appears to only use it for generating the checksum binary (which it then nulls out locally) for the authdat blob. Is there any way to decrypt/recover the "in_data" in the krb5_ticket struct that comes out of krb5_rd_req? Or do I have another way of getting at the checksum locally by calling an explicit decryption of the blob before sending it out, the same checksum the server will have when it is done rd_req? Let me know your ideas... -Todd From hartmans@MIT.EDU Thu Feb 14 12:25:30 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA26780 for ; Thu, 14 Feb 2002 12:25:30 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14239; Thu, 14 Feb 2002 12:25:30 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07028; Thu, 14 Feb 2002 12:25:29 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11876; Thu, 14 Feb 2002 12:25:29 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id MAA27603; Thu, 14 Feb 2002 12:25:28 -0500 (EST) To: Todd Zino Cc: krbdev@MIT.EDU Subject: Re: de facto inline mutual auth via krb5_mk_req / krb5_rd_req? References: <5.1.0.14.2.20020214113235.00a8f438@postoffice2.mail.cornell.edu> From: Sam Hartman In-Reply-To: Todd Zino's message of "Thu, 14 Feb 2002 12:18:01 -0500" Message-ID: Lines: 5 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 14 12:26:00 2002 X-Original-Date: 14 Feb 2002 12:25:28 -0500 There's a perfectly fine mutual authentication mechanism provided by the krb_ap_rep message in the Kerberos protocol. Use that; it has the same number of messages as your current scheme. If you pass in the mutual flag to krb5_mk_req you should get an ap_rep out of krb5_rd_req. From tcz3@cornell.edu Thu Feb 14 13:29:51 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA26989 for ; Thu, 14 Feb 2002 13:29:50 -0500 (EST) Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA11958 for ; Thu, 14 Feb 2002 13:29:50 -0500 (EST) Received: from BIARRITZ.cornell.edu (asdt128253114192.cit.cornell.edu [128.253.114.192]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id NAA02853 for ; Thu, 14 Feb 2002 13:29:49 -0500 (EST) Message-Id: <5.1.0.14.2.20020214131703.030dd168@postoffice2.mail.cornell.edu> X-Sender: tcz3@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: krbdev@mit.edu From: Todd Zino Subject: Re: de facto inline mutual auth via krb5_mk_req / krb5_rd_req? In-Reply-To: References: <5.1.0.14.2.20020214113235.00a8f438@postoffice2.mail.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 14 13:30:01 2002 X-Original-Date: Thu, 14 Feb 2002 13:29:25 -0500 >There's a perfectly fine mutual authentication mechanism provided by >the krb_ap_rep message in the Kerberos protocol. Use that; it has the >same number of messages as your current scheme. Would this mean doing mk_rep / rd_rep in place of mk_req / rd_req for those two messages? The main thing the server is doing with the rd_req is simply getting the client's principal fullname and discarding the rest of the kTicket; can/should this be done with a different set of messages than AP_REQ if I want to have the mutual part included? I don't see a ticket or principal included in the ap_rep struct. >If you pass in the mutual flag to krb5_mk_req you should get an ap_rep out >of krb5_rd_req. What would the client pull from this after the mk_req is done locally, in order to compare with what the server eventually sends back? The only place I see the AP_OPTS_MUTUAL_REQUIRED flag explicitly used in the AP_REQ src's is on the rd_req_decode() where it determines whether or not to ^ the sequence number (can/should I set these manually to that random number on the client beforehand as a 'checksum' of sorts?). I don't see the krb5_ap_rep struct linked to the returned krb5_ticket struct in krb5.h Let me know if I'm barking up the wrong tree in envisioning the optimal solution, --Todd From hartmans@MIT.EDU Fri Feb 15 13:09:23 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA01361 for ; Fri, 15 Feb 2002 13:09:23 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA02480; Fri, 15 Feb 2002 13:09:22 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA24072; Fri, 15 Feb 2002 13:09:22 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA23247; Fri, 15 Feb 2002 13:09:22 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id NAA28235; Fri, 15 Feb 2002 13:09:21 -0500 (EST) To: Todd Zino Cc: krbdev@MIT.EDU Subject: Re: de facto inline mutual auth via krb5_mk_req / krb5_rd_req? References: <5.1.0.14.2.20020214113235.00a8f438@postoffice2.mail.cornell.edu> <5.1.0.14.2.20020214131703.030dd168@postoffice2.mail.cornell.edu> From: Sam Hartman In-Reply-To: Todd Zino's message of "Thu, 14 Feb 2002 13:29:25 -0500" Message-ID: Lines: 5 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 13:10:01 2002 X-Original-Date: 15 Feb 2002 13:09:21 -0500 You should call krb5_mk_rep after krb5_RD_REQ on the server side. Send the result to the client, which calls krb5_rd_rep to read the result and verify it. You do want to pass in the mutual flag into krb5_mk_req on the client. From jpark7@exchange.calstatela.edu Fri Feb 15 15:44:17 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA02192 for ; Fri, 15 Feb 2002 15:44:08 -0500 (EST) Received: from calstatela.edu ([130.182.1.1]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA13705; Fri, 15 Feb 2002 15:43:52 -0500 (EST) Received: from exchange2.calstatela.edu (exchange2 [130.182.195.12]) by calstatela.edu (8.11.6/8.11.6) with ESMTP id g1FKhpH24864; Fri, 15 Feb 2002 12:43:51 -0800 (PST) Received: by exchange2.calstatela.edu with Internet Mail Service (5.5.2653.19) id <1001TZPA>; Fri, 15 Feb 2002 12:44:42 -0800 Message-ID: <494550328DDDD311BA570090279C1B8C6BCD39@exchange2.calstatela.edu> From: "Park, Jae Hyen" To: "'macdev@mit.edu'" , "'krbdev@mit.edu'" Subject: Question about Mac OS X 10.1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B661.978A49F0" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 15:45:01 2002 X-Original-Date: Fri, 15 Feb 2002 12:44:41 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B661.978A49F0 Content-Type: text/plain; charset="iso-8859-1" Greetings, My name is Jae Park and I am a novice in Kerberos (in fact, Unix in general). The reason I am sending this e-mail is to say "thanks for this wonderful tool" for Mac and ask a question about the problem I am having. If anyone can answer me this question, I will do anything to promote Kerberos implementation for other people. The problem is that I can not compile krb-1.2.3 or krb-1.2.4.beta under Mac OS X 10.1 (Darwin 1.4 on PPC) workstation (not server version). Sadly, I don't have access to Mac OS X 10 server. My spec are the following: - Mac OS X 10.1 (workstation version) with Developer Tools instaleld. - File System - UFS Volume Things that I did so far: 1) ./configure --with-ccopts=-I/usr/include/Kerberos Inside /usr/include/Kerberos directory, there are couple of symbolic links to Kerberos.Framework. I had added couple more .. KerberosPreferences, KerberosWrappers, KerberosComErr etc. Without this entry, cc can not locate Kerberos header files that come with Mac OS, I guess. 2) then, after creating Makefile, I had included option '-flat_namespace' as cc option in Makefile generated by configure script, as indicated in Mac OS X Bug report. Also, I had corrected libdes425.dylib to libdes524 as indicated in Mac OS X bug report. 3) Then, I types: make but, the following error occurred: ... .... making all in lib/krb5util... making all in lib/kdb... cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_UNISTD_H=1 -DHAVE_SRAND=1 -DHAVE_SRANDOM=1 -DHAVE_UMASK=1 -DKRB5_KRB4_COMPAT -I../../include -I./../../include -I../../include/krb5 -I./../../include/krb5 -I/usr/include/Kerberos -c keytab.c keytab.c:97: undefined type, found `krb5_key_data' keytab.c:98: undefined type, found `krb5_db_entry' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode keytab.c: In function `krb5_ktkdb_get_entry': keytab.c:97: `krb5_key_data' undeclared (first use in this function) keytab.c:97: (Each undeclared identifier is reported only once keytab.c:97: for each function it appears in.) keytab.c:97: `key_data' undeclared (first use in this function) keytab.c:98: `krb5_db_entry' undeclared (first use in this function) keytab.c:98: parse error before `db_entry' keytab.c:109: `db_entry' undeclared (first use in this function) keytab.c:109: `n' undeclared (first use in this function) keytab.c:109: `more' undeclared (first use in this function) make[2]: *** [keytab.o] Error 1 make[1]: *** [all-recurse] Error 1 make: *** [all-recurse] Error 1 4) Well, guess what.. with tears in my eyes, I tried something that I shoudn't do... I modified the source. I thought the errors showed above is something that (maybe) data type were not defined or visible during compilation. So, I traced down to a point where: my tracing: - keytab.c has a line #include "kdb_kt.h" - Inside "kdb_kt.h" has a line that include "kdb.h" - "kdb.h" has data_type definitions, but there is a problem: ... .... #if !defined(macintosh) && !defined(_MSDOS) && !defined(_WIN32) && !defined(__MACH__) // --- data definition --- #endif ... .... So, I deleted "#if !defined(...) and #endif" from kdb.h and make it again. 5) then, I passed the error message above and it compiled more, but still an error occurred. In this time, "Linking Error". ... .... ranlib libgssrpc.a ranlib: file: libgssrpc.a(xdr_float.o) has no symbols rm -f ../../lib/libgssrpc.a (cd ../../lib && ln -s rpc/libgssrpc.a .) making all in lib/rpc/unit-test... cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DPOSIX_SIGNALS=1 -DKRB5_KRB4_COMPAT -I../../../include -I./../../../include -I../../../include/krb5 -I./../../../include/krb5 -I. -I/usr/include/Kerberos -c client.c cc: -flat_namespace: linker input file unused since linking not done cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DPOSIX_SIGNALS=1 -DKRB5_KRB4_COMPAT -I../../../include -I./../../../include -I../../../include/krb5 -I./../../../include/krb5 -I. -I/usr/include/Kerberos -c rpc_test_clnt.c cc: -flat_namespace: linker input file unused since linking not done cc -flat_namespace -L../../../lib -o client client.o rpc_test_clnt.o \ -lgssrpc -ldyn -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err /usr/bin/ld: Undefined symbols: _krb5_gss_dbg_client_expcreds _gss_mech_krb5 _gss_mech_krb5_old make[3]: *** [client] Error 1 make[2]: *** [all-recurse] Error 1 make[1]: *** [all-recurse] Error 1 make: *** [all-recurse] Error 1 I couldn't do anymore since then. It occurred with both krb5-1.2.3 and krb5-1.2.4-beta. Please, someone give me a hand with this problem. I will be really appreciated it. Thanks in advance... Jae H. Park Software Integration Engineer Academic Technology Support California State University, Los Angeles Tel. (323)343-2778 Fax. (323)343-4575 e-mail: jpark7@calstatela.edu ------_=_NextPart_001_01C1B661.978A49F0 Content-Type: text/html; charset="iso-8859-1"
Greetings,
 
My name is Jae Park and I am a novice in Kerberos (in fact, Unix in general). The reason I am sending this e-mail is to say "thanks for this wonderful tool" for Mac and ask a question about the problem I am having. If anyone can answer me this question, I will do anything to promote Kerberos implementation for other people.
 
The problem is that I can not compile krb-1.2.3 or krb-1.2.4.beta under Mac OS X 10.1 (Darwin 1.4 on PPC) workstation (not server version). Sadly, I don't have access to Mac OS X 10 server. 
My spec are the following:
- Mac OS X 10.1 (workstation version) with Developer Tools instaleld.
- File System - UFS Volume
 
Things that I did so far:
 
1) ./configure --with-ccopts=-I/usr/include/Kerberos
     Inside /usr/include/Kerberos directory, there are couple of symbolic links to Kerberos.Framework. I had added couple more .. KerberosPreferences, KerberosWrappers, KerberosComErr etc.
Without this entry, cc can not locate Kerberos header files that come with Mac OS, I guess.
 
2) then, after creating Makefile, I had included option '-flat_namespace' as cc option in Makefile generated by configure script, as indicated in Mac OS X Bug report. Also, I had corrected  libdes425.dylib to libdes524 as indicated in Mac OS X bug report.
 
3) Then, I types: make but, the following error occurred:
 
<excerpt>
...
....
making all in lib/krb5util...
making all in lib/kdb...
cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DHAVE_UNISTD_H=1 -DHAVE_SRAND=1 -DHAVE_SRANDOM=1 -DHAVE_UMASK=1   -DKRB5_KRB4_COMPAT -I../../include -I./../../include -I../../include/krb5 -I./../../include/krb5  -I/usr/include/Kerberos -c keytab.c
keytab.c:97: undefined type, found `krb5_key_data'
keytab.c:98: undefined type, found `krb5_db_entry'
cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode
keytab.c: In function `krb5_ktkdb_get_entry':
keytab.c:97: `krb5_key_data' undeclared (first use in this function)
keytab.c:97: (Each undeclared identifier is reported only once
keytab.c:97: for each function it appears in.)
keytab.c:97: `key_data' undeclared (first use in this function)
keytab.c:98: `krb5_db_entry' undeclared (first use in this function)
keytab.c:98: parse error before `db_entry'
keytab.c:109: `db_entry' undeclared (first use in this function)
keytab.c:109: `n' undeclared (first use in this function)
keytab.c:109: `more' undeclared (first use in this function)
make[2]: *** [keytab.o] Error 1
make[1]: *** [all-recurse] Error 1
make: *** [all-recurse] Error 1
4) Well, guess what.. with tears in my eyes, I tried something that I shoudn't do... I modified the source.
I thought the errors showed above is something that (maybe) data type were not defined or visible during compilation. So, I traced down to a point where:
 
my tracing:
 
- keytab.c has a line #include "kdb_kt.h"
- Inside "kdb_kt.h" has a line that include "kdb.h"
- "kdb.h" has data_type definitions, but there is a problem:
 
<excerpt>
...
....
#if !defined(macintosh) && !defined(_MSDOS) && !defined(_WIN32) && !defined(__MACH__)
 
// --- data definition ---
 
#endif
...
....
 
 
So, I deleted "#if !defined(...) and #endif" from kdb.h and make it again.
 
5) then, I passed the error message above and it compiled more, but still an error occurred. In this time, "Linking Error".
<excerpt>
...
....
ranlib libgssrpc.a
ranlib: file: libgssrpc.a(xdr_float.o) has no symbols
rm -f ../../lib/libgssrpc.a
(cd ../../lib && ln -s rpc/libgssrpc.a .)
making all in lib/rpc/unit-test...
cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DPOSIX_SIGNALS=1   -DKRB5_KRB4_COMPAT -I../../../include -I./../../../include -I../../../include/krb5 -I./../../../include/krb5 -I. -I/usr/include/Kerberos -c client.c
cc: -flat_namespace: linker input file unused since linking not done
cc -flat_namespace -DKRB5_DNS_LOOKUP_KDC=1 -DKRB5_DNS_LOOKUP=1 -DPOSIX_SIGNALS=1   -DKRB5_KRB4_COMPAT -I../../../include -I./../../../include -I../../../include/krb5 -I./../../../include/krb5 -I. -I/usr/include/Kerberos -c rpc_test_clnt.c
cc: -flat_namespace: linker input file unused since linking not done
cc -flat_namespace -L../../../lib -o client client.o rpc_test_clnt.o \
        -lgssrpc -ldyn -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err 
/usr/bin/ld: Undefined symbols:
_krb5_gss_dbg_client_expcreds
_gss_mech_krb5
_gss_mech_krb5_old
make[3]: *** [client] Error 1
make[2]: *** [all-recurse] Error 1
make[1]: *** [all-recurse] Error 1
make: *** [all-recurse] Error 1
I couldn't do anymore since then. It occurred with both krb5-1.2.3 and krb5-1.2.4-beta.
 
Please, someone give me a hand with this problem. I will be really appreciated it.
 
Thanks in advance...
 

Jae H. Park
Software Integration Engineer
Academic Technology Support
California State University, Los Angeles
Tel. (323)343-2778    Fax. (323)343-4575
e-mail: jpark7@calstatela.edu

 
------_=_NextPart_001_01C1B661.978A49F0-- From Nicolas.Williams@ubsw.com Fri Feb 15 16:18:19 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA02318 for ; Fri, 15 Feb 2002 16:18:14 -0500 (EST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA27474 for ; Fri, 15 Feb 2002 16:18:03 -0500 (EST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id QAA23646 for ; Fri, 15 Feb 2002 16:17:58 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma023509; Fri, 15 Feb 2002 16:17:44 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA06567 for ; Fri, 15 Feb 2002 16:19:48 -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 QAA19742 for ; Fri, 15 Feb 2002 16:17:41 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id QAA09759 for krbdev@mit.edu; Fri, 15 Feb 2002 16:16:32 -0500 (EST) From: Nicolas Williams To: krbdev@mit.edu Subject: krb5_rd_req() server argument should be optional Message-ID: <20020215161630.S27171@sm2p1386swk.wdr.com> Mail-Followup-To: krbdev@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 16:52:00 2002 X-Original-Date: Fri, 15 Feb 2002 16:16:32 -0500 Yes, I have a need for a form of krb5_rd_req() whose server princ name argument is optional and, if not provided, is obtained straight from the decoded AP-REQ and returned to the caller. This probably means a new API call based on rd_req() with a server argument that is a pointer to a krb5_principal, and this function will have to search the given keytab for a key for the principal name extracted from the AP-REQ. This, I think, is how rd_req() should have worked from the get-go. Similarly the verify_creds() function should have an optional service principal argument which, if not given, should cause verify_creds() to try every SPN given in the keytab. In either case the caller could check the actual SPN used and would take that into account, if applicable, in any authorization decisions. Would such a feature be welcome? Comments? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mjv@MIT.EDU Fri Feb 15 15:53:10 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA02230 for ; Fri, 15 Feb 2002 15:53:05 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA17150; Fri, 15 Feb 2002 15:52:08 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24757; Fri, 15 Feb 2002 15:52:07 -0500 (EST) Received: from [18.18.1.144] (ETTLINGER-TOR.MIT.EDU [18.18.1.144]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id PAA26526; Fri, 15 Feb 2002 15:52:07 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@hesiod (Unverified) Message-Id: In-Reply-To: <494550328DDDD311BA570090279C1B8C6BCD39@exchange2.calstatela.edu> References: <494550328DDDD311BA570090279C1B8C6BCD39@exchange2.calstatela.edu> To: "Park, Jae Hyen" From: Marshall Vale Subject: Re: Question about Mac OS X 10.1 Cc: "'macdev@mit.edu'" , "'krbdev@mit.edu'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 17:15:56 2002 X-Original-Date: Fri, 15 Feb 2002 15:52:04 -0500 At 12:44 PM -0800 2/15/02, Park, Jae Hyen wrote: >The problem is that I can not compile krb-1.2.3 or krb-1.2.4.beta >under Mac OS X 10.1 (Darwin 1.4 on PPC) workstation (not server >version). >I couldn't do anymore since then. It occurred with both >krb5-1.2.3 and krb5-1.2.4-beta. > >Please, someone give me a hand with this problem. I will be really >appreciated it. The base distribution of Kerberos does not include all of the components used in Kerberos for Macintosh. We currently do not have a source distribution available for Kerberos for Macintosh 4.0. If you feel that there are additions that you would like to see to Kerberos for Macintosh, we would prefer to hear your requests or bug reports at this time. Thanks, Marshall -- Marshall Vale | mjv@mit.edu | Information Systems MacDev Control Panel | Massachusetts Institute of Technology From cesarg@ms.com Fri Feb 15 17:25:11 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA02597 for ; Fri, 15 Feb 2002 17:24:56 -0500 (EST) Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22290 for ; Fri, 15 Feb 2002 17:24:46 -0500 (EST) Received: from pivsbh2-idmz.ms.com (localhost [127.0.0.1]) by pivsbh2.ms.com (Postfix) with SMTP id D28BE9274; Fri, 15 Feb 2002 17:24:45 -0500 (EST) Received: from sasmh3.ms.com (unknown [144.14.193.98]) by pivsbh2-idmz.ms.com (Postfix) with ESMTP id B99CFA44D; Fri, 15 Feb 2002 17:24:45 -0500 (EST) Received: from imus.morgan.com (imus.morgan.com [144.14.15.156]) by sasmh3.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id RAA05245; Fri, 15 Feb 2002 17:24:45 -0500 (EST) Received: (cesarg@localhost) by imus.morgan.com (8.8.5/sendmail.cf.client v1.05) id RAA21132; Fri, 15 Feb 2002 17:24:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.35500.763759.116753@imus.ms.com> From: Cesar Garcia To: Nicolas Williams Cc: krbdev@mit.edu Subject: Re: krb5_rd_req() server argument should be optional In-Reply-To: <20020215161630.S27171@sm2p1386swk.wdr.com> References: <20020215161630.S27171@sm2p1386swk.wdr.com> X-Mailer: VM 6.72 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 17:28:06 2002 X-Original-Date: Fri, 15 Feb 2002 17:24:44 -0500 (EST) Yes! Would also like to see this make it's way to gssapi and, the kerberized apps that ship with the distribution. This would facilitate our migration from NIS (where we happen to use shortnames) to DNS, as a target host/application may then accept AP requests as either appname/shortname or appname/FQDN depending on how the client naming is configured. This would also useful in environment where one may be running VCS, but not necessarily using VCS service names consistently, i.e., using both VCS service names and proper hostnames. >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Yes, I have a need for a form of krb5_rd_req() whose server princ name Nicolas> argument is optional and, if not provided, is obtained straight from the Nicolas> decoded AP-REQ and returned to the caller. Nicolas> This probably means a new API call based on rd_req() with a server Nicolas> argument that is a pointer to a krb5_principal, and this function will Nicolas> have to search the given keytab for a key for the principal name Nicolas> extracted from the AP-REQ. Nicolas> This, I think, is how rd_req() should have worked from the get-go. Nicolas> Similarly the verify_creds() function should have an optional service Nicolas> principal argument which, if not given, should cause verify_creds() to Nicolas> try every SPN given in the keytab. Nicolas> In either case the caller could check the actual SPN used and would take Nicolas> that into account, if applicable, in any authorization decisions. Nicolas> Would such a feature be welcome? Nicolas> Comments? Nicolas> Nico Nicolas> -- Nicolas> -DISCLAIMER: an automatically appended disclaimer may follow. By posting- Nicolas> -to a public e-mail mailing list I hereby grant permission to distribute- Nicolas> -and copy this message.- Nicolas> Visit our website at http://www.ubswarburg.com Nicolas> This message contains confidential information and is intended only Nicolas> for the individual named. If you are not the named addressee you Nicolas> should not disseminate, distribute or copy this e-mail. Please Nicolas> notify the sender immediately by e-mail if you have received this Nicolas> e-mail by mistake and delete this e-mail from your system. Nicolas> E-mail transmission cannot be guaranteed to be secure or error-free Nicolas> as information could be intercepted, corrupted, lost, destroyed, Nicolas> arrive late or incomplete, or contain viruses. The sender therefore Nicolas> does not accept liability for any errors or omissions in the contents Nicolas> of this message which arise as a result of e-mail transmission. If Nicolas> verification is required please request a hard-copy version. This Nicolas> message is provided for informational purposes and should not be Nicolas> construed as a solicitation or offer to buy or sell any securities or Nicolas> related financial instruments. Nicolas> _______________________________________________ Nicolas> krbdev mailing list krbdev@mit.edu Nicolas> http://mailman.mit.edu/mailman/listinfo/krbdev From crawdad@gungnir.fnal.gov Fri Feb 15 17:30:42 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA02631 for ; Fri, 15 Feb 2002 17:30:37 -0500 (EST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA11961 for ; Fri, 15 Feb 2002 17:30:27 -0500 (EST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GRL00765IIQMX@smtp.fnal.gov> for krbdev@mit.edu; Fri, 15 Feb 2002 16:30:26 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id g1FMUQZ06255; Fri, 15 Feb 2002 16:30:26 -0600 (CST) From: Matt Crawford Subject: Re: krb5_rd_req() server argument should be optional In-reply-to: "15 Feb 2002 16:16:32 EST." <20020215161630.S27171@sm2p1386swk.wdr.com> To: Nicolas Williams Cc: krbdev@mit.edu Message-id: <200202152230.g1FMUQZ06255@gungnir.fnal.gov> Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 18:09:01 2002 X-Original-Date: Fri, 15 Feb 2002 16:30:26 -0600 > Yes, I have a need for a form of krb5_rd_req() whose server princ name > argument is optional and, if not provided, is obtained straight from the > decoded AP-REQ and returned to the caller. Eh? You can already pass a NULL server principal. It will get the service name from the ticket and so can you. From hartmans@MIT.EDU Fri Feb 15 16:27:16 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA02354 for ; Fri, 15 Feb 2002 16:27:11 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19155 for ; Fri, 15 Feb 2002 16:27:01 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA01142; Fri, 15 Feb 2002 16:27:01 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA28835; Fri, 15 Feb 2002 16:27:00 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id QAA28274; Fri, 15 Feb 2002 16:27:00 -0500 (EST) To: dalmeida@MIT.EDU, krbdev@MIT.EDU Subject: [Todd Kover ] KfW and triple des problems From: Sam Hartman Message-ID: Lines: 81 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 18:26:21 2002 X-Original-Date: 15 Feb 2002 16:27:00 -0500 I'm somewhat bothered that this doesn't work. I can't think of anything obvious the user is doing wrong. We should test this on Windows. I can help with test realms that do 3des. ------- Start of forwarded message ------- Message-Id: <200202132230.g1DMUtmO025236@guiness.omniscient.com> To: kerberos@mit.edu Subject: KfW and triple des problems From: Todd Kover Date: Wed, 13 Feb 2002 17:30:55 -0500 is anyone aware of problems with KfW 2.1.2 and triple des encryption? [ This is all krb5. I have no krb4 support turned on anymore. ] I'm attempting to get WinCVS/cvs working with gserver against the 2.1.2 sdk and have been successful using keys in my age-old kdc (migrated over from v4) which only has a des-cbc-crc key for the relevent service principal: kadmin: getprinc cvs/saidin.omniscient.com [ ... ] Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, no salt (The kdc is running 1.2.2 now but that's a change since the abovementioned principal was created). I'm able to interact with a cvs server linked against 1.2.2 sources using this service key just fine. Using the same cvs binary, but against a relatively newly configured cvs server (initially installed under 1.2) the service side is complaining: "could not verify credentials" with a cvs server similiarly linked against 1.2.2 libraries but with a cvs/hostname principal in the kdc with key types: Number of keys: 2 Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 2, DES cbc mode with CRC-32, no salt The odd thing is that when I have the windows box's krb5.ini file set with: default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc I can kinit against it fine from the windows box. If I change this to: default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc kinit's fail. This leads me to believe something is awry with the des3-hmac-sha1 support. It seems that the .ini file is ignored when grabbing service tickets because the credentials cache on the windows box has both keys in it when I attempt to use cvs, regardless of the config file. (this isn't surprising). Does this ring any bells for anyone? I haven't dug deeply into the code just yet. I figured I'd ask before I started to try to parse it and get the encryption-induced headache I expect. :-) windows 2000+sp2 if that makes a difference. Everything's built with Visual C++&&sp5. thanks, -Todd _______________________________________________ Kerberos mailing list Kerberos@mit.edu http://mailman.mit.edu/mailman/listinfo/kerberos ------- End of forwarded message ------- From Nicolas.Williams@ubsw.com Fri Feb 15 16:30:47 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA02384 for ; Fri, 15 Feb 2002 16:30:36 -0500 (EST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20321 for ; Fri, 15 Feb 2002 16:30:26 -0500 (EST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id QAA29740 for ; Fri, 15 Feb 2002 16:30:20 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma029617; Fri, 15 Feb 2002 16:29:58 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA13435 for ; Fri, 15 Feb 2002 16:32:07 -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 QAA29190 for ; Fri, 15 Feb 2002 16:30:00 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id QAA09962 for krbdev@mit.edu; Fri, 15 Feb 2002 16:28:51 -0500 (EST) From: Nicolas Williams To: krbdev@mit.edu Subject: Extending rd_req() to handle tkt authz/ext data? Message-ID: <20020215162850.T27171@sm2p1386swk.wdr.com> Mail-Followup-To: krbdev@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 18:37:36 2002 X-Original-Date: Fri, 15 Feb 2002 16:28:51 -0500 The MIT krb5 ought to have an API for enumerating and accessing the authorization data elements in the ticket of an AP-REQ being accepted. Similarly with ticket extensions (though that won't be applicable until Purple comes along the API probably ought to be designed now). In fact, all typed holes should be coupled with an API for getting at them where that's applicable. Me-thinks. The more interesting question is how to represent these things to apps. Here the fact that DER and explicit tagging are used could work in the favor of the API designer. I.e., for unknown authz/extension data types provide the app with a type/value interface to such things and include type names where they are known, but also the type integer and tags as they appear. For known authz/extension data types more comfortable structures could be defined. Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams@ubsw.com Fri Feb 15 16:49:24 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA02438 for ; Fri, 15 Feb 2002 16:49:18 -0500 (EST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08842 for ; Fri, 15 Feb 2002 16:49:03 -0500 (EST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id QAA02375 for ; Fri, 15 Feb 2002 16:52:12 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma002319; Fri, 15 Feb 2002 16:51:58 -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 QAA06887 for ; Fri, 15 Feb 2002 16:47:20 -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 QAA13592 for ; Fri, 15 Feb 2002 16:48:45 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id QAA10558 for krbdev@mit.edu; Fri, 15 Feb 2002 16:47:36 -0500 (EST) From: Nicolas Williams To: krbdev@mit.edu Subject: Baseline authz data criticality in MIT krb5? Message-ID: <20020215164735.U27171@sm2p1386swk.wdr.com> Mail-Followup-To: krbdev@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 18:50:31 2002 X-Original-Date: Fri, 15 Feb 2002 16:47:36 -0500 From what I can see there is no check for critical authorization data in the baseline rd_req() functions in the MIT krb5 distro. There ought to be. This means adding code to check for AD-IF-RELEVANT and friends at the very least and causing rd_req() to return an error if any critical authz data elements are present that are also not understood by MIT krb5. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams@ubsw.com Fri Feb 15 17:32:10 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA02644 for ; Fri, 15 Feb 2002 17:32:05 -0500 (EST) Received: from gate.stm.swissbank.com (gate.stm.ubswarburg.com [151.191.1.10]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA24431 for ; Fri, 15 Feb 2002 17:31:49 -0500 (EST) Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id RAA25757; Fri, 15 Feb 2002 17:34:59 -0500 (EST) Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma025676; Fri, 15 Feb 2002 17:34:26 -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 RAA23904; Fri, 15 Feb 2002 17:29:49 -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 RAA15765; Fri, 15 Feb 2002 17:31:12 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id RAA11050; Fri, 15 Feb 2002 17:30:02 -0500 (EST) From: Nicolas Williams To: Cesar Garcia Cc: krbdev@mit.edu Subject: Re: krb5_rd_req() server argument should be optional Message-ID: <20020215173001.V27171@sm2p1386swk.wdr.com> Mail-Followup-To: Cesar Garcia , krbdev@mit.edu References: <20020215161630.S27171@sm2p1386swk.wdr.com> <15469.35500.763759.116753@imus.ms.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <15469.35500.763759.116753@imus.ms.com>; from Cesar.Garcia@morganstanley.com on Fri, Feb 15, 2002 at 05:24:44PM -0500 Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 19:02:22 2002 X-Original-Date: Fri, 15 Feb 2002 17:30:02 -0500 Wow, you saw right through to my actual goal :) Let me go a step further: ALL kerberized apps ought to use this modified rd_req() API. I have to wonder why it wasn't like this all along, but hey, let's just fix it. Cheers, Nico On Fri, Feb 15, 2002 at 05:24:44PM -0500, Cesar Garcia wrote: > Yes! > > Would also like to see this make it's way to gssapi and, > the kerberized apps that ship with the distribution. > > This would facilitate our migration from NIS (where we happen > to use shortnames) to DNS, as a target host/application may then accept > AP requests as either appname/shortname or appname/FQDN depending > on how the client naming is configured. > > This would also useful in environment where one may be running VCS, but not > necessarily using VCS service names consistently, i.e., using both VCS > service names and proper hostnames. -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams@ubsw.com Fri Feb 15 17:35:51 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA02661 for ; Fri, 15 Feb 2002 17:35:46 -0500 (EST) Received: from gate2.stm.ubswarburg.com (gate2.stm.ubswarburg.com [151.191.1.12]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA25603 for ; Fri, 15 Feb 2002 17:35:31 -0500 (EST) Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id RAA02032; Fri, 15 Feb 2002 17:35:24 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate2 via smap (V2.0/ubsw) id xma001980; Fri, 15 Feb 2002 17:35: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 RAA29000; Fri, 15 Feb 2002 17:31:40 -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 RAA18080; Fri, 15 Feb 2002 17:35:07 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id RAA11139; Fri, 15 Feb 2002 17:33:59 -0500 (EST) From: Nicolas Williams To: Matt Crawford Cc: krbdev@mit.edu Subject: Re: krb5_rd_req() server argument should be optional Message-ID: <20020215173357.W27171@sm2p1386swk.wdr.com> Mail-Followup-To: Matt Crawford , krbdev@mit.edu References: <20020215161630.S27171@sm2p1386swk.wdr.com> <200202152230.g1FMUQZ06255@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200202152230.g1FMUQZ06255@gungnir.fnal.gov>; from crawdad@fnal.gov on Fri, Feb 15, 2002 at 04:30:26PM -0600 Precedence: list X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 15 19:15:50 2002 X-Original-Date: Fri, 15 Feb 2002 17:33:58 -0500 On Fri, Feb 15, 2002 at 04:30:26PM -0600, Matt Crawford wrote: > > Yes, I have a need for a form of krb5_rd_req() whose server princ name > > argument is optional and, if not provided, is obtained straight from the > > decoded AP-REQ and returned to the caller. > > Eh? You can already pass a NULL server principal. It will get the > service name from the ticket and so can you. Oh, look at that. Right you are. Boy, I jumped the gun on that. Sigh. Thanks, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From akosut@Stanford.EDU Sat Feb 16 02:25:20 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id CAA04310 for ; Sat, 16 Feb 2002 02:25:04 -0500 (EST) Received: from epic17.Stanford.EDU (epic17.Stanford.EDU [171.64.15.52]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA29816 for ; Sat, 16 Feb 2002 02:24:49 -0500 (EST) Received: (from akosut@localhost) by epic17.Stanford.EDU (8.11.6/8.11.6) id g1G7OmQ07807 for krbdev@mit.edu; Fri, 15 Feb 2002 23:24:48 -0800 (PST) From: Alexei Kosut To: krbdev@mit.edu Subject: Re: Kerberos for Macintosh 4.0fc1 released Message-ID: <20020215232448.A7644@stanford.edu> Mail-Followup-To: krbdev@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mjv@mit.edu on Fri, Feb 08, 2002 at 04:34:11PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Sat Feb 16 02:26:00 2002 X-Original-Date: Fri, 15 Feb 2002 23:24:48 -0800 On Fri, Feb 08, 2002 at 04:34:11PM -0500, Marshall Vale wrote: > Kerberos for Macintosh 4.0 has now reached the final candidate stage, > which means the end of the testing cycle is near. If you discover > any problems, please report them *immediately*. I suppose this means I should get around to asking a question that I've been wondering about for a while: What is the help button in the corner of the Kerberos Login dialog supposed to do when clicked on Mac OS X? I've never been able to make it do anything. -- Alexei Kosut From lxs@MIT.EDU Sat Feb 16 15:29:25 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA06624 for ; Sat, 16 Feb 2002 15:29:17 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA13709; Sat, 16 Feb 2002 15:29:01 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28078; Sat, 16 Feb 2002 15:29:00 -0500 (EST) Received: from [18.18.1.18] (DUG-HAUT.MIT.EDU [18.101.1.25]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20764; Sat, 16 Feb 2002 15:29:00 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: <20020215232448.A7644@stanford.edu> References: <20020215232448.A7644@stanford.edu> To: Alexei Kosut From: Alexandra Ellwood Subject: Re: Kerberos for Macintosh 4.0fc1 released Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Sat Feb 16 15:38:23 2002 X-Original-Date: Sat, 16 Feb 2002 15:29:03 -0500 >On Fri, Feb 08, 2002 at 04:34:11PM -0500, Marshall Vale wrote: >> Kerberos for Macintosh 4.0 has now reached the final candidate stage, >> which means the end of the testing cycle is near. If you discover >> any problems, please report them *immediately*. > >I suppose this means I should get around to asking a question that >I've been wondering about for a while: > >What is the help button in the corner of the Kerberos Login dialog >supposed to do when clicked on Mac OS X? I've never been able to make >it do anything. It actually doesn't do anything. We thought about adding tool tips support to replace the Mac OS 9 balloon help, but then you'd end up with things like a "Basic/Advanced" menu with a tool tip that says "Basic or Advanced mode". Tool tips really don't want to display large amounts of text. What it should do is launch some Kerberos Help for the user. If we'd written it yet, it would... ;-) Thanks, --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From deengert@anl.gov Mon Feb 18 09:50:57 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA13914 for ; Mon, 18 Feb 2002 09:50:52 -0500 (EST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA02119; Mon, 18 Feb 2002 09:50:37 -0500 (EST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.64.60]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA03337; Mon, 18 Feb 2002 08:50:36 -0600 (CST) Message-ID: <3C7114BA.DC7B5D2D@anl.gov> From: "Douglas E. Engert" X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Hartman CC: dalmeida@mit.edu, krbdev@mit.edu Subject: Re: [Todd Kover ] KfW and triple des problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 18 09:52:00 2002 X-Original-Date: Mon, 18 Feb 2002 08:50:34 -0600 This sounds somewhat familiar to the problm I had wuth 3des on windows. I tracked it down to what looked like uninitilized enctypes. Ken had looked at these changes before. I still think it is a problem. Here are diffs for 1.2.3 in lib/crypto/dk *** ,derive.c Wed Jan 9 16:27:37 2002 --- derive.c Fri Jan 11 14:33:59 2002 *************** *** 98,103 **** --- 98,104 ---- inblock.length = keybytes; (*(enc->make_key))(&inblock, outkey); + outkey->enctype = inkey->enctype; /* clean memory, free resources and exit */ *** ,stringtokey.c Wed Jan 9 16:27:37 2002 --- stringtokey.c Fri Jan 11 14:32:16 2002 *************** *** 72,77 **** --- 72,78 ---- indata.data = foldstring; foldkey.length = keylength; foldkey.contents = foldkeydata; + foldkey.enctype = key->enctype; (*(enc->make_key))(&indata, &foldkey); Sam Hartman wrote: > > I'm somewhat bothered that this doesn't work. I can't think of > anything obvious the user is doing wrong. We should test this on > Windows. I can help with test realms that do 3des. > > ------- Start of forwarded message ------- > Message-Id: <200202132230.g1DMUtmO025236@guiness.omniscient.com> > To: kerberos@mit.edu > Subject: KfW and triple des problems > From: Todd Kover > Date: Wed, 13 Feb 2002 17:30:55 -0500 > > is anyone aware of problems with KfW 2.1.2 and triple des encryption? > > [ This is all krb5. I have no krb4 support turned on anymore. ] > > I'm attempting to get WinCVS/cvs working with gserver against the 2.1.2 > sdk and have been successful using keys in my age-old kdc (migrated > over from v4) which only has a des-cbc-crc key for the relevent service > principal: > > kadmin: getprinc cvs/saidin.omniscient.com > [ ... ] > Number of keys: 1 > Key: vno 2, DES cbc mode with CRC-32, no salt > > (The kdc is running 1.2.2 now but that's a change since the > abovementioned principal was created). > > I'm able to interact with a cvs server linked against 1.2.2 sources > using this service key just fine. > > Using the same cvs binary, but against a relatively newly configured cvs > server (initially installed under 1.2) the service side is complaining: > > "could not verify credentials" > > with a cvs server similiarly linked against 1.2.2 libraries but with a > cvs/hostname principal in the kdc with key types: > > Number of keys: 2 > Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt > Key: vno 2, DES cbc mode with CRC-32, no salt > > The odd thing is that when I have the windows box's krb5.ini file set > with: > > default_tkt_enctypes = des-cbc-crc > default_tgs_enctypes = des-cbc-crc > > I can kinit against it fine from the windows box. If I change this to: > > default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc > default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc > > kinit's fail. > > This leads me to believe something is awry with the des3-hmac-sha1 > support. > > It seems that the .ini file is ignored when grabbing service tickets > because the credentials cache on the windows box has both keys in it > when I attempt to use cvs, regardless of the config file. (this isn't > surprising). > > Does this ring any bells for anyone? I haven't dug deeply into the code > just yet. I figured I'd ask before I started to try to parse it and get > the encryption-induced headache I expect. :-) > > windows 2000+sp2 if that makes a difference. Everything's built with > Visual C++&&sp5. > > thanks, > -Todd > _______________________________________________ > Kerberos mailing list > Kerberos@mit.edu > http://mailman.mit.edu/mailman/listinfo/kerberos > ------- End of forwarded message ------- > _______________________________________________ > krbdev mailing list krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hartmans@MIT.EDU Mon Feb 18 16:41:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA15280 for ; Mon, 18 Feb 2002 16:41:09 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19394; Mon, 18 Feb 2002 16:40:59 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA16695; Mon, 18 Feb 2002 16:40:57 -0500 (EST) Received: from tir-na-nogth.mit.edu (TIR-NA-NOGTH.MIT.EDU [18.18.1.6]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25620; Mon, 18 Feb 2002 16:40:56 -0500 (EST) Received: (from hartmans@localhost) by tir-na-nogth.mit.edu (8.9.3) id QAA29503; Mon, 18 Feb 2002 16:40:55 -0500 (EST) To: Nicolas Williams Cc: krbdev@MIT.EDU Subject: Re: Baseline authz data criticality in MIT krb5? References: <20020215164735.U27171@sm2p1386swk.wdr.com> From: Sam Hartman In-Reply-To: Nicolas Williams's message of "Fri, 15 Feb 2002 16:47:36 -0500" Message-ID: Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 18 16:42:00 2002 X-Original-Date: 18 Feb 2002 16:40:55 -0500 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> From what I can see there is no check for critical Nicolas> authorization data in the baseline rd_req() functions in Nicolas> the MIT krb5 distro. There ought to be. This means adding Nicolas> code to check for AD-IF-RELEVANT and friends at the very Nicolas> least and causing rd_req() to return an error if any Nicolas> critical authz data elements are present that are also Nicolas> not understood by MIT krb5. Yeah, didn't we talk about this Tuesday in the SIPB office? From youcherry@yahoo.com Mon Feb 18 18:09:43 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id SAA15547 for ; Mon, 18 Feb 2002 18:09:38 -0500 (EST) From: youcherry@yahoo.com Received: from yahoo.com ([211.185.42.2]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id SAA11916 for ; Mon, 18 Feb 2002 18:09:08 -0500 (EST) Message-Id: <200202182309.SAA11916@fort-point-station.mit.edu> Reply-To: youcherry@yahoo.com To: krbdev@mit.edu Subject: Take me. MIME-Version: 1.0 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 18 18:10:01 2002 X-Original-Date: 18 Feb 2002 23:41:39 GMT


Can you break my cherry?

Click Here and give it a try...

Little sluts are waiting for your big dick!
What are you waiting for?

HERE
















Note: this is not a spam email. This email was sent to you because your email was entered in on a website requesting to be a registered subscriber. If you did not request this email, please just answer on this mail.


From hua-ying@usa.net Mon Feb 18 20:35:30 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id UAA16033 for ; Mon, 18 Feb 2002 20:35:24 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA11808 for ; Mon, 18 Feb 2002 20:35:09 -0500 (EST) Received: from quantum.unity.ncsu.edu (quantum.unity.ncsu.edu [152.1.10.162]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id UAA00591 for ; Mon, 18 Feb 2002 20:35:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: diff prototype for krb5_write_message? From: Hua Ying Ling To: krbdev@mit.edu Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.480) Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 18 20:36:01 2002 X-Original-Date: Mon, 18 Feb 2002 20:35:08 -0500 I'm trying to compile LPRNG with Kerberos support for MacOS X but I'm getting an undefined symbols for _krb5_read_message _krb5_write_message _krb5_xfree _valid_cksumtype. I have included the Kerberos5Core framework which seems to have these symbols defined. This is the prototype found in the code, are they different from the version of Kerberos for the Mac? extern krb5_error_code krb5_write_message KRB5_PROTOTYPE((krb5_context, krb5_pointer, krb5_data *)); Thanks ~Hua Ying From lxs@MIT.EDU Tue Feb 19 10:40:07 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA18717 for ; Tue, 19 Feb 2002 10:40:02 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24874; Tue, 19 Feb 2002 10:39:44 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14542; Tue, 19 Feb 2002 10:38:55 -0500 (EST) Received: from [18.101.1.25] (RAGNA-BLADE.MIT.EDU [18.18.1.18]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07253; Tue, 19 Feb 2002 10:38:55 -0500 (EST) Mime-Version: 1.0 X-Sender: lxs@po12.mit.edu (Unverified) Message-Id: In-Reply-To: References: To: Hua Ying Ling From: Alexandra Ellwood Subject: Re: diff prototype for krb5_write_message? Cc: krbdev@MIT.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 19 10:41:00 2002 X-Original-Date: Tue, 19 Feb 2002 10:38:57 -0500 >I'm trying to compile LPRNG with Kerberos support for MacOS X but >I'm getting an undefined symbols for _krb5_read_message >_krb5_write_message _krb5_xfree _valid_cksumtype. I have included >the Kerberos5Core framework which seems to have these symbols >defined. This is the prototype found in the code, are they >different from the version of Kerberos for the Mac? krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype are private functions internal to the Kerberos 5 library. As a result, they are not exported by the Kerberos framework, and you should not be calling them. Yes, I realize that they are in the krb5.h header file, but they shouldn't be. krb5_read_message and krb5_write_message just send and receive data on the network. You should be able to replace these functions with your own versions fairly easily. krb5_xfree is deprecated because there are now krb5_free_ functions for all krb5 types allocated inside the library. You should check the krb5 type you are passing into krb5_xfree and find the appropriate free function in krb5.h. valid_cksumtype is a krb5 crypto API. I'm not sure how you should go about replacing this function. I'll leave that to other folks on the krbdev list. Hope this helps, --lxs -- ----------------------------------------------------------------------------- Alexandra Ellwood MIT Information Systems http://mit.edu/lxs/www/ ----------------------------------------------------------------------------- -- From rjgoyette@anl.gov Tue Feb 19 12:17:06 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA19012 for ; Tue, 19 Feb 2002 12:17:01 -0500 (EST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06899 for ; Tue, 19 Feb 2002 12:16:50 -0500 (EST) Received: from cardini.pns.anl.gov (cardini.pns.anl.gov [146.139.157.118]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id LAA23762; Tue, 19 Feb 2002 11:16:50 -0600 (CST) Received: from [146.139.156.47] (voyager.pns.anl.gov [146.139.156.47]) by cardini.pns.anl.gov with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 107QZ53P; Tue, 19 Feb 2002 11:16:50 -0600 Mime-Version: 1.0 X-Sender: ipns_nt/goyette/rgoyette@cardini.pns.anl.gov Message-Id: To: krbdev@mit.edu From: Rick Goyette Subject: problem with kerberos 5 telnet plugin Cc: rjgoyette@anl.gov, "Engert, Douglas E." Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 19 12:18:00 2002 X-Original-Date: Tue, 19 Feb 2002 11:16:49 -0600 Here is an interesting problem. We recently moved our kerberos server to a Windows 2000 machine. I use a mac and KfM 4.0 fc1 and kerberized betterTelnet to get a forwardable ticket. Connecting to the first machine works fine, but if I try to connect to a second machine I get this error: "kerberos 5 telnet Plug in (a bunch of giberish) nstructing service name: Server not found in Kerberos database failure on credentials." This persists until I quit betterTelnet and restart. Then whatever machine I connect to first works again, but any additional machine fails as above, even if the requested node shows up in the kerberos control panel as having been forwarded the ticket. Pointing back to our old DCE server still works correctly. -- R. J. Goyette Argonne National Laboratory rjgoyette@anl.gov (630) 252-4328 http://www.pns.anl.gov From papowell@astart.com Wed Feb 20 08:25:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA23057 for ; Wed, 20 Feb 2002 08:25:39 -0500 (EST) Received: from astart2.astart.com (tcubed-gw.customer.nethere.net [216.188.53.211]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA19156 for ; Wed, 20 Feb 2002 08:25:23 -0500 (EST) Received: from h110.private (h110.private [10.0.0.110]) by astart2.astart.com (8.11.6/8.11.6) with ESMTP id g1KDPMs01846; Wed, 20 Feb 2002 05:25:22 -0800 (PST) (envelope-from papowell@astart.com) Received: (from papowell@localhost) by h110.private (8.11.3/8.11.3) id g1KDPMY11942; Wed, 20 Feb 2002 05:25:22 -0800 (PST) (envelope-from papowell) From: Patrick Powell Message-Id: <200202201325.g1KDPMY11942@h110.private> To: hua-ying@usa.net, krbdev@mit.edu, lprng@lprng.com Subject: Re: lprng uses private Kerberos Functions? In-Reply-To: <3C734EE9.F3E4CE31@usa.net> Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Feb 20 08:27:01 2002 X-Original-Date: Wed, 20 Feb 2002 05:25:22 -0800 (PST) > From hua-ying@usa.net Tue Feb 19 23:23:33 2002 > Date: Wed, 20 Feb 2002 02:23:31 -0500 > From: Hua Ying Ling > To: papowell@lprng.com > Subject: lprng uses private Kerberos Functions? > > Hi, > > I got several link errors while compiling LPRNG for Mac OS X. > I've attached the response from krbdev about these errors. Any > thoughts on the best, most portable solution for these > problems? > > PS. Tried posting to the lprng@egroups.com > > Thanks > ~Hua Ying > > http://diswww.mit.edu:8008/menelaus.mit.edu/krb5dev/6890 > Your original email ended up in my Spam Collection Sack, and this is not the best place for it. This could be due to that fact that you sent it directly to me, or you sent it to the LPRng mailing list and you were not subscribed to it. Or you might be trying to beat the list security and were sending to lprng-owner and expecting to spam the list :-) If you are subscribed to the mailing list, then you might have sent it from a site or address different than the one that you registered with. If the latter is the case and you want to post from this address then send me, Patrick Powell , email describing the problem with: LPRNGMAIL in the SUBJECT line so my junk mail purging system will not toss it into the bit shredder (we shred our email for security reasons). In fact, if you have any problems with the list, send me email with LPRNGMAIL in the header. The best way to get answers is via the LPRng mailing list, which I peruse on a fairly frequent basis. To subscribe, send mail to: lprng-request@lprng.com with the single line: subscribe in the body. This reply is sent by a semiautomatic system, and the real person may be drinking coffee at the present time... so my apologies for the one-size-fits-all message. Patrick Powell Astart Technologies, papowell@lprng.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.lprng.com) > incase link doesn't work ... > ============================== > > >I'm trying to compile LPRNG with Kerberos support for MacOS X but > >I'm getting an undefined symbols for _krb5_read_message > >_krb5_write_message _krb5_xfree _valid_cksumtype. I have included > >the Kerberos5Core framework which seems to have these symbols > >defined. This is the prototype found in the code, are they > >different from the version of Kerberos for the Mac? Try downloading the latest Kerberos release from MIT, install it, then use: ./configure --with-ldopts="-L/usr/local/lib" \ --with-cppopts="-I/usr/local/include" --enable-kerberos > krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype > are private functions internal to the Kerberos 5 library. As a > result, they are not exported by the Kerberos framework, and you > should not be calling them. Yes, I realize that they are in the > krb5.h header file, but they shouldn't be. Ummm... have you heard of 'legacy software support?' The various kerberized utilities use them, and I ripped the code out of the kerberos utilities :-) > > > krb5_read_message and krb5_write_message just send and receive data > on the network. You should be able to replace these functions with > your own versions fairly easily. > > krb5_xfree is deprecated because there are now krb5_free_ > functions for all krb5 types allocated inside the library. You > should check the krb5 type you are passing into krb5_xfree and find > the appropriate free function in krb5.h. Right. Good idea! I will look at this. > > valid_cksumtype is a krb5 crypto API. I'm not sure how you should go > about replacing this function. I'll leave that to other folks on the > krbdev list. > > > Hope this helps, > > --lxs > -- > ----------------------------------------------------------------------------- > > Alexandra Ellwood > > MIT Information Systems > http://mit.edu/lxs/www/ > ----------------------------------------------------------------------------- > > -- > _______________________________________________ > krbdev mailing list krbdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/krbdev > > From meeroh@MIT.EDU Wed Feb 20 08:51:24 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA23163 for ; Wed, 20 Feb 2002 08:51:19 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA25957; Wed, 20 Feb 2002 08:50:57 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA03724; Wed, 20 Feb 2002 08:50:56 -0500 (EST) Received: from [18.101.0.199] (TITANIUM-48.MIT.EDU [18.101.0.199]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA17230; Wed, 20 Feb 2002 08:50:54 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <200202201325.g1KDPMY11942@h110.private> References: <200202201325.g1KDPMY11942@h110.private> To: Patrick Powell , hua-ying@usa.net, krbdev@MIT.EDU, lprng@lprng.com From: Miro Jurisic Subject: Re: lprng uses private Kerberos Functions? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Wed Feb 20 08:52:01 2002 X-Original-Date: Wed, 20 Feb 2002 08:49:23 -0500 > > >I'm trying to compile LPRNG with Kerberos support for MacOS X but > > >I'm getting an undefined symbols for _krb5_read_message > > >_krb5_write_message _krb5_xfree _valid_cksumtype. I have included > > >the Kerberos5Core framework which seems to have these symbols >> >defined. This is the prototype found in the code, are they >> >different from the version of Kerberos for the Mac? > >Try downloading the latest Kerberos release from MIT, install >it, then use: > >./configure --with-ldopts="-L/usr/local/lib" \ > --with-cppopts="-I/usr/local/include" --enable-kerberos This is not a useful answer. It is not helpful to tell him to replace a component with his own, because a. it will be blown away the next time he upgrades the OS b. his users won't have the 'fixed' version anyway c. your suggestion wouldn't even work correctly because you would end up with /usr/lib binaries which work differently from /System/Library/Frameworks binaries, which is a recipe for disaster. > > krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype >> are private functions internal to the Kerberos 5 library. As a >> result, they are not exported by the Kerberos framework, and you >> should not be calling them. Yes, I realize that they are in the >> krb5.h header file, but they shouldn't be. > >Ummm... have you heard of 'legacy software support?' Yes, we have. This is one of the cases in which we consciously decided to break it. This API has been wrong to use for years, and that didn't have any influence on whether people use it or not. Now that we removed it, finally people are fixing their code. Since they have to recompile for Mac OS X _anyway_, it was a reasonable point to force them to fix their code in our opinion. >The various kerberized utilities use them, and I ripped the >code out of the kerberos utilities :-) That is what we recommend in general -- it is not the responsibility of Kerberos libraries to provide you with network send and receive code, but if you need an example of how to do it, you should feel free to look at our code which does it. Sounds like that's exactly what you are doing :-) hth meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From tlyu@MIT.EDU Thu Feb 21 23:56:21 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id XAA00368 for ; Thu, 21 Feb 2002 23:56:15 -0500 (EST) Received: from saint-elmos-fire.mit.edu (SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA07015 for ; Thu, 21 Feb 2002 23:56:00 -0500 (EST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id XAA04145; Thu, 21 Feb 2002 23:56:00 -0500 (EST) To: krbdev@MIT.EDU Subject: krb5-1.2.4-beta2 available From: Tom Yu Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Thu Feb 21 23:57:01 2002 X-Original-Date: 21 Feb 2002 23:56:00 -0500 I've posted krb5-1.2.4-beta2 on the MIT Kerberos web page, http://web.mit.edu/kerberos/www/ This is primarily a bugfix release; the final 1.2.4 release will probably happen in a week or two. Please test this beta release and report any critical bugs in the next week. The only real change since 1.2.4-beta1 is to fix a problem with mutiple enctype support in the gss library that was introduced in the 1.2.3 release. ---Tom From papowell@astart.com Fri Feb 22 10:57:12 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA02270 for ; Fri, 22 Feb 2002 10:57:07 -0500 (EST) Received: from astart2.astart.com (tcubed-gw.customer.nethere.net [216.188.53.211]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA11116; Fri, 22 Feb 2002 10:56:51 -0500 (EST) Received: from h110.private (h110.private [10.0.0.110]) by astart2.astart.com (8.11.6/8.11.6) with ESMTP id g1MFuos33164; Fri, 22 Feb 2002 07:56:50 -0800 (PST) (envelope-from papowell@astart.com) Received: (from papowell@localhost) by h110.private (8.11.3/8.11.3) id g1MFunE89158; Fri, 22 Feb 2002 07:56:49 -0800 (PST) (envelope-from papowell) From: Patrick Powell Message-Id: <200202221556.g1MFunE89158@h110.private> To: hua-ying@usa.net, krbdev@MIT.EDU, lprng@lprng.com, meeroh@MIT.EDU, papowell@astart.com Subject: Re: lprng uses private Kerberos Functions? In-Reply-To: Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 10:58:00 2002 X-Original-Date: Fri, 22 Feb 2002 07:56:49 -0800 (PST) > From meeroh@MIT.EDU Wed Feb 20 05:50:59 2002 > Date: Wed, 20 Feb 2002 08:49:23 -0500 > To: Patrick Powell , hua-ying@usa.net, krbdev@MIT.EDU, > lprng@lprng.com > From: Miro Jurisic > Subject: Re: lprng uses private Kerberos Functions? > > > > >I'm trying to compile LPRNG with Kerberos support for MacOS X but > > > >I'm getting an undefined symbols for _krb5_read_message > > > >_krb5_write_message _krb5_xfree _valid_cksumtype. I have included > > > >the Kerberos5Core framework which seems to have these symbols > >> >defined. This is the prototype found in the code, are they > >> >different from the version of Kerberos for the Mac? > > > >Try downloading the latest Kerberos release from MIT, install > >it, then use: > > > >./configure --with-ldopts="-L/usr/local/lib" \ > > --with-cppopts="-I/usr/local/include" --enable-kerberos > > This is not a useful answer. It is not helpful to tell him to replace > a component with his own, because a. it will be blown away the next > time he upgrades the OS b. his users won't have the 'fixed' version > anyway c. your suggestion wouldn't even work correctly because you > would end up with /usr/lib binaries which work differently from > /System/Library/Frameworks binaries, which is a recipe for disaster. > > > > krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype > >> are private functions internal to the Kerberos 5 library. As a > >> result, they are not exported by the Kerberos framework, and you > >> should not be calling them. Yes, I realize that they are in the > >> krb5.h header file, but they shouldn't be. > > > >Ummm... have you heard of 'legacy software support?' > > Yes, we have. This is one of the cases in which we consciously > decided to break it. This API has been wrong to use for years, and > that didn't have any influence on whether people use it or not. Now > that we removed it, finally people are fixing their code. Since they > have to recompile for Mac OS X _anyway_, it was a reasonable point to > force them to fix their code in our opinion. OK, this is reasonable. Of course, you realize that this will break compatibility with the OLDER versions of LPRng that use these functions. So, I suggest you wander down the hall (at MIT) and brace the folks there with the suggestion that they redeploy all of the printing software currently in use. Sigh... I will make you a deal: Send me a sample set of program with makefiles, etc. that (Note the critical stuff): Client: a) opens a connection to the Server b) does the authenication step ** using KRB stuff ** c) opens a 'send this' file for reading , and a 'got this' file for writing d) reads from the 'send this' file descriptor and copies input to destionation. ** using KRB stuff ** note: you may need to send the file length first so you can tell how many bytes that will be sent... e) reads from the connection, copies input to the 'got this' file descriptor ** using KRB stuff ** (same thing about length) f) sends a string "OK, all done, bye" to the Server ** using KRB stuff ** (same thing about length) g) reads from the connection, copies input to the 'got this' file descriptor ** using KRB stuff ** (same thing about length) h) closes, etc. files, exits. Server: Does the inverse a) opens a listening socket and b) does the authenication step ** using KRB stuff ** c) opens a 'send this' file for reading , and a 'got this' file for writing d) reads from the connection, copies input to the 'got this' file descriptor e) reads from the 'send this' file descriptor and copies input to destionation. f) reads from the connection, copies input to the 'got this' file descriptor g) sends a string "OK, all done, bye" to the Client ** using KRB stuff ** h) closes, etc. I will massage the stuff into the next release. > > >The various kerberized utilities use them, and I ripped the > >code out of the kerberos utilities :-) > > That is what we recommend in general -- it is not the responsibility > of Kerberos libraries to provide you with network send and receive > code, but if you need an example of how to do it, you should feel > free to look at our code which does it. Sounds like that's exactly > what you are doing :-) > > hth > > meeroh > -- > > | MIT I/S Mac developer | KB1FMP > > "Well, I must endure the presence of two or three caterpillars if I > wish to become acquainted with the butterflies." -- Antoine de > Saint-Exupery, "The Little Prince" > From kenh@cmf.nrl.navy.mil Fri Feb 22 11:31:35 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA02379 for ; Fri, 22 Feb 2002 11:31:30 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.12.161]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA26632; Fri, 22 Feb 2002 11:31:21 -0500 (EST) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id g1MGV3G27196; Fri, 22 Feb 2002 11:31:03 -0500 (EST) Message-Id: <200202221631.g1MGV3G27196@ginger.cmf.nrl.navy.mil> To: Patrick Powell cc: hua-ying@usa.net, krbdev@mit.edu, lprng@lprng.com, meeroh@mit.edu Subject: Re: lprng uses private Kerberos Functions? In-reply-to: Your message of "Fri, 22 Feb 2002 07:56:49 PST." <200202221556.g1MFunE89158@h110.private> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 11:32:01 2002 X-Original-Date: Fri, 22 Feb 2002 11:31:01 -0500 >> > > krb5_read_message, krb5_write_message, krb5_xfree, valid_cksumtype >> >> are private functions internal to the Kerberos 5 library. As a >> >> result, they are not exported by the Kerberos framework, and you >> >> should not be calling them. Yes, I realize that they are in the >> >> krb5.h header file, but they shouldn't be. While I understand about krb5_xfree() and the whole crypto library thing with valid_cksumtype(), I don't feel it's fair to call krb5_{read,write}_message an internal function. I don't believe it's used by any code in Kerberos other than the examples, _and_ it's even mentioned in the Kerberos API document. It's reasonable for a developer to conclude that it's a public function. I don't think it _should_ be a public function (and it's not like you couldn't replicate it with 5-10 lines of code), but I think it's better to call it a mistake and yank it out of the library completely with perhaps some notes saying, "If you were using this function, here's what you need to do". And removing it from the API document might not be a bad idea, since that's what many people out here have been living and dying by for years. --Ken From meeroh@MIT.EDU Fri Feb 22 12:29:20 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA02559 for ; Fri, 22 Feb 2002 12:29:14 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21046; Fri, 22 Feb 2002 12:28:55 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25704; Fri, 22 Feb 2002 12:28:55 -0500 (EST) Received: from [18.101.0.201] (NEON-20.MIT.EDU [18.101.0.201]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA16019; Fri, 22 Feb 2002 12:28:54 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <200202221556.g1MFunE89158@h110.private> References: <200202221556.g1MFunE89158@h110.private> To: Patrick Powell , hua-ying@usa.net, krbdev@MIT.EDU, lprng@lprng.com From: Miro Jurisic Subject: Re: lprng uses private Kerberos Functions? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 12:30:01 2002 X-Original-Date: Fri, 22 Feb 2002 12:28:40 -0500 > > >Ummm... have you heard of 'legacy software support?' >> >> Yes, we have. This is one of the cases in which we consciously >> decided to break it. This API has been wrong to use for years, and >> that didn't have any influence on whether people use it or not. Now >> that we removed it, finally people are fixing their code. Since they >> have to recompile for Mac OS X _anyway_, it was a reasonable point to >> force them to fix their code in our opinion. > >OK, this is reasonable. Of course, you realize that this will >break compatibility with the OLDER versions of LPRng that use >these functions. It will? How so? We haven't removed the API from regular UNIX distributions (yet), so that code will continue to work fine. We've never exported this API from our Mac OS X distributions, so Mac OS X code has always had to provide its own versions of those functions in order to link against our libraries. I don't see how this will break anything. All it will do is force people to fix their code when they port it to Mac OS X. Since this fix will also fix their code on other platforms, after a while, the code will be correct on all platforms. Then we can yank the functions completely; in the meanwhile, we can deprecate them in the documentation, and we can deprecate them in the headers. >Send me a sample set of program with makefiles, etc. that >(Note the critical stuff): As a team, we should and will do this. As an individual, this is not where my expertise is, so rather than writing more incorrect sample code, I am going to leave this to someone else. meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From meeroh@MIT.EDU Fri Feb 22 12:36:27 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA02605 for ; Fri, 22 Feb 2002 12:36:22 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA23940; Fri, 22 Feb 2002 12:36:02 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA26963; Fri, 22 Feb 2002 12:36:01 -0500 (EST) Received: from [18.101.0.201] (NEON-20.MIT.EDU [18.101.0.201]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA18724; Fri, 22 Feb 2002 12:35:58 -0500 (EST) Mime-Version: 1.0 X-Sender: meeroh@po12 (Unverified) Message-Id: In-Reply-To: <200202221631.g1MGV3G27196@ginger.cmf.nrl.navy.mil> References: <200202221631.g1MGV3G27196@ginger.cmf.nrl.navy.mil> To: Ken Hornstein , Patrick Powell From: Miro Jurisic Subject: Re: lprng uses private Kerberos Functions? Cc: hua-ying@usa.net, krbdev@MIT.EDU, lprng@lprng.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 12:46:11 2002 X-Original-Date: Fri, 22 Feb 2002 12:34:42 -0500 >While I understand about krb5_xfree() and the whole crypto library >thing with valid_cksumtype(), I don't feel it's fair to call >krb5_{read,write}_message an internal function. I don't believe it's >used by any code in Kerberos other than the examples, _and_ it's even >mentioned in the Kerberos API document. It's reasonable for a developer >to conclude that it's a public function. > >I don't think it _should_ be a public function (and it's not like you >couldn't replicate it with 5-10 lines of code), but I think it's better >to call it a mistake and yank it out of the library completely with >perhaps some notes saying, "If you were using this function, here's >what you need to do". And removing it from the API document might not be >a bad idea, since that's what many people out here have been living and >dying by for years. I don't think I ever blamed anyone for using them; I understand how people got into that state, and it is our fault, and we're fixing it. Of course, there's bound to be complaining -- noone's ever happy when you tell them one thing and then go "oh, oops, nevermind" a few years later. We will update documentation, we will update sample code, we will deprecate these functions, we will not make them disappear overnight on platforms where they have been used. However, we will also _not_ provide them on Mac OS X, because we don't want to perpetuate the mistake, and because it gives us a lot of leverage to make people fix the code when they port it to Mac OS X. If you like, you can think of it as Mac OS X being ahead of the other platforms by some amount of time -- it can ditch those functions right now, whereas other platforms have to provide them until most clients' code is updated. meeroh -- | MIT I/S Mac developer | KB1FMP "Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies." -- Antoine de Saint-Exupery, "The Little Prince" From eichin-krb@thok.org Fri Feb 22 13:05:40 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA02740 for ; Fri, 22 Feb 2002 13:05:35 -0500 (EST) From: eichin-krb@thok.org Received: from swat.thok.org (swat.thok.org [4.36.43.84]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id NAA02858 for ; Fri, 22 Feb 2002 13:01:20 -0500 (EST) Received: (qmail 22134 invoked by uid 3382); 22 Feb 2002 18:01:20 -0000 To: krbdev@mit.edu Subject: Re: lprng uses private Kerberos Functions? References: <200202221631.g1MGV3G27196@ginger.cmf.nrl.navy.mil> In-Reply-To: Ken Hornstein's message of "Fri, 22 Feb 2002 11:31:01 -0500" Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 13:10:04 2002 X-Original-Date: 22 Feb 2002 13:01:19 -0500 I was going to point out krb5/src/appl/sample/sclient/sclient.c since it is a standard reference client, but *IT STILL USES krb5_net_read* And sample/sserver/sserver.c uses krb5_net_write. sigh. (all hands raised in favor of "cvs rm appl" because it is such a botch?) From mjv@MIT.EDU Fri Feb 22 15:45:08 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA03429 for ; Fri, 22 Feb 2002 15:45:03 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA09680; Fri, 22 Feb 2002 15:44:53 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28720; Fri, 22 Feb 2002 15:44:51 -0500 (EST) Received: from [18.18.1.144] (ETTLINGER-TOR.MIT.EDU [18.18.1.144]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA04757; Fri, 22 Feb 2002 15:44:51 -0500 (EST) Mime-Version: 1.0 X-Sender: mjv@hesiod (Unverified) Message-Id: To: krbdev@MIT.EDU From: Marshall Vale Subject: Kerberos for Macintosh 4.0 Released Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 15:46:00 2002 X-Original-Date: Fri, 22 Feb 2002 15:44:47 -0500 The MIT MacDev team is pleased to announce the availability of Kerberos for Macintosh 4.0, final release. This release is available from the MIT Kerberos site: Follow the "Getting Kerberos from MIT" link. All feedback and bug reports for Kerberos for Macintosh 4.0 should be sent to Overview -------- Kerberos for Macintosh 4.0 expands and improves native support for Mac OS X as well as including the new UI elements for Mac OS 9 introduced in KfM 3.5. Kerberos for Macintosh 4.0 requires a Power Macintosh with Mac OS X 10.1.2 or later for the Mac OS X version, or Mac OS 8.1 or later for the Mac OS 8 & 9 version. This is a final release, and does not expire. Changes since Kerberos For Macintosh 4.0fc1 ------------------------------------------ * Mac OS X: Fixed UID security hole where other users could see your tickets if they SSH into your Macintosh. * Mac OS X: Fixed memory leak in CCacheClassicServer.app * Mac OS X: Removed nonfunctional help button from Kerberos Login dialog * Mac OS X: Installer now enforces Mac OS X 10.1.2 minimum requirement * Mac OS X/9: Kerberos Login dialog now returns correct error messages again. * Mac OS X/9: Classic ticket sharing is disabled when KfM is installed only on the Classic system and not OS X. * Mac OS X/9: Classic ticket sharing is disabled when the versions of KfM on OS X and the Classic system do not match. * Mac OS X/9: Fixed various bugs in Classic ticket sharing AE handling * Mac OS X/9: Kerberos Menu 'Open Kerberos Control Panel' item now enabled under Classic * Mac OS 8: Now works under Mac OS 8.1 again. If you built an application that linked against the /usr/lib dylibs in KfM 4.0b2 or earlier, or the ones included with Mac OS X 10.1, you will need to re-link your application to work with the KfM 4.0 dylibs. Ticket Sharing Between Mac OS X and Classic ------------------------------------------- In order for Kerberos tickets to be shared between Mac OS X and Classic, the same version of KfM 4.0 must be installed on both the OS X and Classic systems. When updating from a previous release, you should install the Classic KfM first, then the OS X KfM to prevent possible conflicts. When an application running under Classic needs to display the Kerberos Login dialog, the Mac OS X dialog will appear. The Mac OS 9 version of KfM 4.0 detects whether it is running under Mac OS X/Classic or regular Mac OS 9.x and automatically enables support for ticket sharing when possible. Distribution Info ----------------- At this point in time, this release is available as a single package which includes both installers and SDKs. The installers install binaries for people to use with their applications in their environments. The SDKs are for application and library programmers to add Kerberos functionality to their code or update to newer versions of the various Kerberos APIs. We will be releasing separate binaries and installer sources at a later date. "One chapter closes, another opens." Marshall -- Marshall Vale | mjv@mit.edu | Information Systems MacDev Control Panel | Massachusetts Institute of Technology From dalmeida@MIT.EDU Fri Feb 22 21:10:53 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id VAA04346 for ; Fri, 22 Feb 2002 21:10:48 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id VAA01093 for ; Fri, 22 Feb 2002 21:10:33 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id VAA00893 for ; Fri, 22 Feb 2002 21:10:32 -0500 (EST) Received: from perseverance (PERSEVERANCE.MIT.EDU [18.18.1.27]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id VAA19947 for ; Fri, 22 Feb 2002 21:10:32 -0500 (EST) From: "Danilo Almeida" To: Subject: Kerberos PAC info on MSDN Library Message-ID: <007701c1bc0f$40c813f0$1b011212@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 21:11:01 2002 X-Original-Date: Fri, 22 Feb 2002 21:10:23 -0500 Looks like MS has now published their PAC format on MSDN: http://msdn.microsoft.com/library/en-us/dnkerb/html/MSDN_PAC.asp?frame=t rue - Danilo From tytso@thunk.org Fri Feb 22 22:23:49 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA04584 for ; Fri, 22 Feb 2002 22:23:44 -0500 (EST) Received: from thunk.org (THANK.THUNK.ORG [216.175.175.163]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA09186; Fri, 22 Feb 2002 22:23:28 -0500 (EST) Received: from think.thunk.org ([216.175.175.162]) by thunk.org with asmtp (Exim 3.33 #1 (Debian)) id 16eSmV-0002lJ-00; Fri, 22 Feb 2002 22:23:27 -0500 Received: from tytso by think.thunk.org with local (Exim 3.34 #1 (Debian)) id 16eSmT-0002z2-00; Fri, 22 Feb 2002 22:23:25 -0500 From: Theodore Tso To: Danilo Almeida Cc: krbdev@MIT.EDU Subject: Re: Kerberos PAC info on MSDN Library Message-ID: <20020222222324.C9851@thunk.org> References: <007701c1bc0f$40c813f0$1b011212@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <007701c1bc0f$40c813f0$1b011212@mit.edu>; from dalmeida@MIT.EDU on Fri, Feb 22, 2002 at 09:10:23PM -0500 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 22:24:00 2002 X-Original-Date: Fri, 22 Feb 2002 22:23:24 -0500 On Fri, Feb 22, 2002 at 09:10:23PM -0500, Danilo Almeida wrote: > Looks like MS has now published their PAC format on MSDN: > http://msdn.microsoft.com/library/en-us/dnkerb/html/MSDN_PAC.asp?frame=t > rue Wow. Note the section at the end: >Microsoft grants you a perpetual, nonexclusive, royalty-free, >world-wide right and license under any Microsoft copyrights in this >specification to copy, publish and distribute this specification, and >to implement this specification in your products. > >Microsoft is not currently aware of the existence of patent(s) and/or >pending application(s) that are essential to the implementation of >this specification. However, if Microsoft becomes aware or has any >patent(s) and/or pending applications that are essential to implement >this specification, Microsoft will grant you a royalty-free license >under applicable Microsoft intellectual property rights essential to >implement this specification for the sole purpose of implementing this >specification.... What's the NDR encoding mentioned in the document? I assume this is some kind of standard Microsoft XDR-like thing? - Ted From mdw@umich.edu Fri Feb 22 23:13:13 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id XAA04782 for ; Fri, 22 Feb 2002 23:12:58 -0500 (EST) Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.213.229.138]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id XAA13992 for ; Fri, 22 Feb 2002 23:12:42 -0500 (EST) Received: from pepper-pot (pepper-pot.ifs.umich.edu [141.213.229.91]) by quince.ifs.umich.edu (8.6.13/8.6.12) with ESMTP id XAA27236 for ; Fri, 22 Feb 2002 23:12:42 -0500 Message-Id: <200202230412.XAA27236@quince.ifs.umich.edu> To: krbdev@mit.edu Subject: Re: Kerberos PAC info on MSDN Library In-reply-to: Your message of "Fri, 22 Feb 2002 22:23:24 EST." <20020222222324.C9851@thunk.org> From: Marcus Watts Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Fri Feb 22 23:14:01 2002 X-Original-Date: Fri, 22 Feb 2002 23:12:42 -0500 Theodore Tso asked: ... > What's the NDR encoding mentioned in the document? I assume this is > some kind of standard Microsoft XDR-like thing? ... I think NDR is actually from DCE, and is their "network data representation". Yup, it's an XDR-like thing, but different than both XDR and ASN.1. Since DCE it seems to have got all wound up with corba and com/dcom, so it looks like there are multiple versions floating around today, with different features. http://www.advogato.org/article/232.html looks like it might be a good place to start to sort this out. -Marcus Watts UM ITCS Umich Systems Group From sommerfeld@orchard.arlington.ma.us Sat Feb 23 14:07:14 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA07405 for ; Sat, 23 Feb 2002 14:07:08 -0500 (EST) Received: from stack.hamachi.org (sommerfeld.ne.mediaone.net [66.31.126.43]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA23948; Sat, 23 Feb 2002 14:06:53 -0500 (EST) Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id C42F4271B; Sat, 23 Feb 2002 14:06:52 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id g1NJ5sA00487; Sat, 23 Feb 2002 14:05:54 -0500 (EST) Message-Id: <200202231905.g1NJ5sA00487@syn.hamachi.org> From: Bill Sommerfeld To: Theodore Tso Cc: Danilo Almeida , krbdev@mit.edu Subject: Re: Kerberos PAC info on MSDN Library In-Reply-To: Message from Theodore Tso of "Fri, 22 Feb 2002 22:23:24 EST." <20020222222324.C9851@thunk.org> Reply-To: sommerfeld@orchard.arlington.ma.us Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Sat Feb 23 14:08:00 2002 X-Original-Date: Sat, 23 Feb 2002 14:05:53 -0500 > What's the NDR encoding mentioned in the document? I assume this is > some kind of standard Microsoft XDR-like thing? If it's what I think it is, NDR is the apollo NCS data representation, akin to XDR but more complex. It made its way to microsoft either by way of DCE RPC or by way of Paul Leach (former apollo fellow who was the NCS architect who is now at microsoft), or both. - Bill From lkcl@samba-tng.org Mon Feb 25 06:41:05 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA14600 for ; Mon, 25 Feb 2002 06:41:00 -0500 (EST) Received: from localhost (host62-7-6-55.in-addr.btopenworld.com [62.7.6.55]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id GAA05047 for ; Mon, 25 Feb 2002 06:40:56 -0500 (EST) Received: from lkcl by localhost with local (Exim 3.32 #1 (Debian)) id 16fKSp-0000JP-00; Mon, 25 Feb 2002 12:42:43 +0000 From: Luke Kenneth Casson Leighton To: krbdev@mit.edu Cc: assar@sics.de Subject: Kerberos PAC info on MSDN Library Message-ID: <20020225124243.F944@samba-tng.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 25 06:42:00 2002 X-Original-Date: Mon, 25 Feb 2002 12:42:43 +0000 i got this from luke howard. if you examine samba TNG source code (http://www.samba-tng.org) you will find that it contains code that is capable of generating and decoding packets very, very similar or identical (i.e. the difference is a few bytes) to the packet format shown in this URL. the samba tng project also actually contains more info (i.e. all of those "reserved" fields that's bullshit, they're well-known fields!) in some areas than is outlined in this microsoft document. if the licensing is not okay for your project, please contact me and i will identify and suitably license appropriate parts of the code for your use in your project. ... as long as your project does not require that i have to relinquish copyright. all best, luke p.s. to mr brezak and others at microsoft: WELL DONE! ----- Forwarded message from Luke Howard ----- Envelope-to: lkcl@localhost Delivered-To: lkcl@angua.rince.de Date: Sun, 24 Feb 2002 23:12:55 +1100 (EST) From: Luke Howard Organization: PADL Software Pty Ltd Matched: Sat, 23 Feb 2002 13:30:00 +1100 X----------From: "Danilo Almeida" X----------To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-BeenThere: krbdev@mit.edu X-Original-Date: Fri, 22 Feb 2002 21:10:23 -0500 X----------Date: Fri, 22 Feb 2002 21:10:23 -0500 Versions: resend 2.8/makemail 2.9a To: xad@PADL.COM Subject: [xad] (fwd) Kerberos PAC info on MSDN Library Precedence: bulk Looks like MS has now published their PAC format on MSDN: http://msdn.microsoft.com/library/en-us/dnkerb/html/MSDN_PAC.asp?frame=t rue - Danilo _______________________________________________ krbdev mailing list krbdev@mit.edu http://mailman.mit.edu/mailman/listinfo/krbdev ----- End forwarded message ----- -- ---------------------------------------------------------- this message is private, confidential, and is intented for the specified recipients only. if you received, altered, deleted, modified, destroyed or interfered with the contents of this message, in whole or in part, please inform the sender (that's me), immediately. if you, the recipient, reply to this message, and do not then receive a response, please consider your reply to have been lost or deliberately destroyed: i *always* acknowledge personal email received. please therefore take appropriate action to ensure effective communication. thank you. From lukeh@au.padl.com Mon Feb 25 07:17:57 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA14716 for ; Mon, 25 Feb 2002 07:17:55 -0500 (EST) Received: from au.padl.com ([210.15.222.250]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id HAA09318 for ; Mon, 25 Feb 2002 07:17:54 -0500 (EST) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id XAA80584; Mon, 25 Feb 2002 23:17:09 +1100 (EST) From: Luke Howard Message-Id: <200202251217.XAA80584@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lkcl@samba-tng.org Subject: Re: Kerberos PAC info on MSDN Library Cc: krbdev@mit.edu, assar@sics.de Reply-To: lukeh@padl.com Versions: dmail (bsd44) 2.2g/makemail 2.9a Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 25 07:19:00 2002 X-Original-Date: Mon, 25 Feb 2002 23:17:08 +1100 The FreeDCE CVS repository (on dcerpc.net) already contained a guess (based on SAMBA code) of the PAC. I have updated this to include the released PAC: see freedce/include/dce/id_base.idl and freedce/ncklib/com/sec_id.c. You should be able to use sec_id_pac_pickle() to NDR encode DCE or Win2K PACs. We have some patches for Heimdal which enable the backend to return an unsigned, NDR-encoded PAC to the KDC, and for the KDC to wrap the PAC with the signatures. We were stalled on completing this code due to the lack of a published PAC specification, but we be able to finish it off now. It should be noted that providing the authorization data component of the PAC is but a small part of providing a Win2K-compatible domain controller service. regards, -- Luke P.S. lkcl: The reference I sent you actually came from the krbdev@mit.edu list, so you don't need to point it out! -- Luke Howard | lukehoward.com PADL Software | www.padl.com From lkcl@samba-tng.org Mon Feb 25 07:48:49 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA14827 for ; Mon, 25 Feb 2002 07:48:49 -0500 (EST) Received: from localhost (host62-7-6-55.in-addr.btopenworld.com [62.7.6.55]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA23545 for ; Mon, 25 Feb 2002 07:48:47 -0500 (EST) Received: from lkcl by localhost with local (Exim 3.32 #1 (Debian)) id 16fLWP-0000KZ-00; Mon, 25 Feb 2002 13:50:29 +0000 From: Luke Kenneth Casson Leighton To: Luke Howard Cc: krbdev@mit.edu, assar@sics.de Subject: Re: [xad] Re: Kerberos PAC info on MSDN Library Message-ID: <20020225135025.G944@samba-tng.org> References: <200202251217.XAA80584@au.padl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202251217.XAA80584@au.padl.com>; from lukeh@PADL.COM on Mon, Feb 25, 2002 at 11:17:08PM +1100 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 25 07:49:00 2002 X-Original-Date: Mon, 25 Feb 2002 13:50:25 +0000 On Mon, Feb 25, 2002 at 11:17:08PM +1100, Luke Howard wrote: > > The FreeDCE CVS repository (on dcerpc.net) already contained a > guess (based on SAMBA code) of the PAC. I have updated this to > include the released PAC: see freedce/include/dce/id_base.idl > and freedce/ncklib/com/sec_id.c. You should be able to use > sec_id_pac_pickle() to NDR encode DCE or Win2K PACs. using this method requires that you strip out or create a "header" - including a unique identifier (uuid) as defined in the idl file that you must create to do the picking/unpickling. example test code is in a dce rfc, which you can cross-reference from dcerpc.net/url. > We have some patches for Heimdal which enable the backend > to return an unsigned, NDR-encoded PAC to the KDC, and for > the KDC to wrap the PAC with the signatures. We were stalled > on completing this code due to the lack of a published PAC > specification, but we be able to finish it off now. hooray! > P.S. lkcl: The reference I sent you actually came from the > krbdev@mit.edu list, so you don't need to point it out! *slightly confused* - i was including the reference such that people can see that in the message i sent and then refer to the rest of the message and see what i am talking about. sending the message without the reference they wouldn't know why i was sending to that list. hope this helps explain why i sent the reference. From lukeh@au.padl.com Mon Feb 25 07:50:57 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id HAA14863 for ; Mon, 25 Feb 2002 07:50:57 -0500 (EST) Received: from au.padl.com (au.padl.com [210.15.222.250]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA23771 for ; Mon, 25 Feb 2002 07:50:55 -0500 (EST) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id XAA80974; Mon, 25 Feb 2002 23:50:13 +1100 (EST) From: Luke Howard Message-Id: <200202251250.XAA80974@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lkcl@samba-tng.org Subject: Re: [xad] Re: Kerberos PAC info on MSDN Library Cc: krbdev@mit.edu, assar@sics.de Reply-To: lukeh@PADL.COM References: <200202251217.XAA80584@au.padl.com> <20020225135025.G944@samba-tng.org> Versions: dmail (bsd44) 2.2g/makemail 2.9a Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 25 07:51:00 2002 X-Original-Date: Mon, 25 Feb 2002 23:50:12 +1100 > using this method requires that you strip out or create > a "header" - including a unique identifier (uuid) as > defined in the idl file that you must create to do the > picking/unpickling. Ah. This should be fixed in sec_id.c, then. I'll look into it. >*slightly confused* - i was including the reference such >that people can see that in the message i sent and then >refer to the rest of the message and see what i am >talking about. sending the message without the reference >they wouldn't know why i was sending to that list. hope >this helps explain why i sent the reference. Sure, but the reference I forwarded you in the first instance was one of the most recent mails to the krbdev list. And your message was sent to the krbdev list. :-) -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com From jjacocks@mac.com Mon Feb 25 18:43:50 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id SAA16842 for ; Mon, 25 Feb 2002 18:43:50 -0500 (EST) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.85]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA06607 for ; Mon, 25 Feb 2002 18:43:49 -0500 (EST) Received: from smtp-relay01.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g1PNhnFD013817 for ; Mon, 25 Feb 2002 15:43:49 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GS44L000.PZU for ; Mon, 25 Feb 2002 15:43:48 -0800 Received: from hyperion.northhampton.org ([164.109.8.244]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GS44L000.02I for ; Mon, 25 Feb 2002 15:43:48 -0800 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: KfM v4.0 Clients From: "J. Alexander Jacocks" To: krbdev@mit.edu Content-Transfer-Encoding: 7bit Message-Id: <84D574B5-2A49-11D6-A4E6-0003930F2444@mac.com> X-Mailer: Apple Mail (2.481) Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Mon Feb 25 18:44:00 2002 X-Original-Date: Mon, 25 Feb 2002 18:43:50 -0500 I'm sure that this question has been asked before, and therefore I apologize in advance. =) Does anyone know if work is being done on command-line clients for MacOS X 10.1.x? I have attempted to compile the source distribution, without success (as expected, given the notes on the website) but I can't seem to find anything else anywhere. Apple has a note on their APSL development page, stating that their bundled tools (ftp, telnet, rlogin, etc.) aren't compiled for kerberos support. Any help would be appreciated, especially as it relates to k5'ed telnet and rlogin. Thanks! From lukeh@au.padl.com Tue Feb 26 03:33:29 2002 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id DAA18742 for ; Tue, 26 Feb 2002 03:33:28 -0500 (EST) Received: from au.padl.com ([210.15.222.250]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id DAA24445 for ; Tue, 26 Feb 2002 03:33:27 -0500 (EST) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id TAA89468; Tue, 26 Feb 2002 19:32:43 +1100 (EST) From: Luke Howard Message-Id: <200202260832.TAA89468@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lkcl@samba-tng.org Subject: Re: [xad] Re: Kerberos PAC info on MSDN Library Cc: krbdev@mit.edu, assar@sics.de Reply-To: lukeh@PADL.COM References: <200202251217.XAA80584@au.padl.com> <20020225135025.G944@samba-tng.org> Versions: dmail (bsd44) 2.2g/makemail 2.9a Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 26 03:34:01 2002 X-Original-Date: Tue, 26 Feb 2002 19:32:42 +1100 > using this method requires that you strip out or create > a "header" - including a unique identifier (uuid) as > defined in the idl file that you must create to do the > picking/unpickling. > > example test code is in a dce rfc, which you can > cross-reference from dcerpc.net/url. Looking at idl_es_put_encoding_header() in idllib/pickling.c, it appears that this header is 56 bytes; the KDC (HDB) backend can pickle the PAC, move past the header, and return it to the KDC. The KDC itself can avoid pulling in idllib as the signatures and other framing information do not contain complex data types. BTW, it was necessary add support for the BOOLEAN ASN.1 data type to Heimdal's ASN.1 parser to support the KERB_PA_PAC_REQUEST. (Assar: any progress on your SPNEGO implementation for Heimdal?) -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com From lkcl@samba-tng.org Tue Feb 26 10:10:54 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA19983 for ; Tue, 26 Feb 2002 10:10:53 -0500 (EST) Received: from localhost (host213-123-54-133.in-addr.btopenworld.com [213.123.54.133]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA27970 for ; Tue, 26 Feb 2002 10:10:52 -0500 (EST) Received: from lkcl by localhost with local (Exim 3.32 #1 (Debian)) id 16fiew-00013q-00; Tue, 26 Feb 2002 14:32:50 +0000 From: Luke Kenneth Casson Leighton To: Luke Howard Cc: krbdev@mit.edu Subject: Re: [xad] Re: Kerberos PAC info on MSDN Library Message-ID: <20020226143250.Y944@samba-tng.org> References: <200202251217.XAA80584@au.padl.com> <20020225135025.G944@samba-tng.org> <200202260832.TAA89468@au.padl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202260832.TAA89468@au.padl.com>; from lukeh@PADL.COM on Tue, Feb 26, 2002 at 07:32:42PM +1100 Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 26 10:11:01 2002 X-Original-Date: Tue, 26 Feb 2002 14:32:50 +0000 On Tue, Feb 26, 2002 at 07:32:42PM +1100, Luke Howard wrote: > > > using this method requires that you strip out or create > > a "header" - including a unique identifier (uuid) as > > defined in the idl file that you must create to do the > > picking/unpickling. > > > > example test code is in a dce rfc, which you can > > cross-reference from dcerpc.net/url. > > Looking at idl_es_put_encoding_header() in idllib/pickling.c, > it appears that this header is 56 bytes; the KDC (HDB) backend > can pickle the PAC, move past the header, and return it to > the KDC. that's the stuff! later on it will be a simple job to add additional functions to pickling.c that will not require the 56 byte header. this was something that rich et al intended to do but didn't get round to: there was no requirement for it at the time. lkcl From lukeh@au.padl.com Tue Feb 26 17:52:04 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA21527 for ; Tue, 26 Feb 2002 17:52:02 -0500 (EST) Received: from au.padl.com ([210.15.222.250]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08728 for ; Tue, 26 Feb 2002 17:51:58 -0500 (EST) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id JAA97556; Wed, 27 Feb 2002 09:51:22 +1100 (EST) From: Luke Howard Message-Id: <200202262251.JAA97556@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: lkcl@samba-tng.org Subject: Re: [xad] Re: Kerberos PAC info on MSDN Library Cc: krbdev@mit.edu Reply-To: lukeh@PADL.COM References: <200202251217.XAA80584@au.padl.com> <20020225135025.G944@samba-tng.org> <200202260832.TAA89468@au.padl.com> <20020226143250.Y944@samba-tng.org> Versions: dmail (bsd44) 2.2g/makemail 2.9a Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 26 17:53:00 2002 X-Original-Date: Wed, 27 Feb 2002 09:51:21 +1100 >later on it will be a simple job to add additional functions >to pickling.c that will not require the 56 byte header. > >this was something that rich et al intended to do but didn't >get round to: there was no requirement for it at the time. Hmm, do you know if the original OSF DCE PAC included the encoding header? Or did their Kerberos implementation special-case that as well? -- Luke -- Luke Howard | lukehoward.com PADL Software | www.padl.com From tlyu@MIT.EDU Tue Feb 26 17:54:01 2002 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA21550 for ; Tue, 26 Feb 2002 17:54:00 -0500 (EST) Received: from saint-elmos-fire.mit.edu (SAINT-ELMOS-FIRE.MIT.EDU [18.18.0.248]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA09515 for ; Tue, 26 Feb 2002 17:54:00 -0500 (EST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id RAA19654; Tue, 26 Feb 2002 17:53:50 -0500 (EST) To: Luke Kenneth Casson Leighton Cc: krbdev@MIT.EDU, assar@sics.de Subject: Re: Kerberos PAC info on MSDN Library References: <20020225124243.F944@samba-tng.org> From: Tom Yu In-Reply-To: <20020225124243.F944@samba-tng.org> Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: krbdev-admin@mit.edu Errors-To: krbdev-admin@mit.edu X-BeenThere: krbdev@mit.edu X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Kerberos Developers Mailing List List-Unsubscribe: , List-Archive: Date: Tue Feb 26 17:55:01 2002 X-Original-Date: 26 Feb 2002 17:53:50 -0500 >>>>> "lkcl" == Luke Kenneth Casson Leighton writes: lkcl> the samba tng project also actually contains lkcl> more info (i.e. all of those "reserved" fields lkcl> that's bullshit, they're well-known fields!) lkcl> in some areas than is outlined in this microsoft lkcl> document. Are these well-known fields that are claimed to be "res