From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 3 08:55:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26861 for ; Fri, 3 Mar 2000 08:55:34 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id FAA01732 for ietf-cat-wg-out720680; Fri, 3 Mar 2000 05:21:26 -0800 (PST) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [130.237.221.147]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id FAA01727 for ; Fri, 3 Mar 2000 05:21:23 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12Qs0x-0000QX-00; Fri, 3 Mar 2000 14:21:07 +0100 To: ietf-cat-wg@lists.Stanford.EDU Subject: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200002251132.GAA04976@ietf.org> From: joda@pdc.kth.se (Johan Danielsson) Date: 03 Mar 2000 14:21:07 +0100 In-Reply-To: Internet-Drafts@ietf.org's message of "Fri, 25 Feb 2000 06:32:01 -0500" Message-ID: Lines: 25 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > KRB-PRIV message (see [3]) This KRB-PRIV message must be generated > using the subkey from the authenticator in the AP-REQ data. > > The user-data component of the message consists of the following > ASN.1 structure encoded as an OCTET STRING: I feel very strongly that ASN.1 shouldn't be used for new protocols defined by the IETF. Especially so, since this defines a new construct (CHOICE) that is not part of RFC1510. Btw, what does `encoded as an OCTET STRING' mean? > In the cleartext password case, if the old password is sent in the > request, the request is defined to be a change password request. Why do you want the old password? > result string - from [4]: > This field is a UTF-8 encoded string which should be displayed > to the user by the client. Why suddenly UTF-8? All strings in RFC1510 are of type GeneralString. /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 3 11:34:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02651 for ; Fri, 3 Mar 2000 11:34:33 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA04521 for ietf-cat-wg-out720680; Fri, 3 Mar 2000 08:07:13 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA04511 for ; Fri, 3 Mar 2000 08:07:10 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 3 Mar 2000 16:03:53 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA24000; Fri, 3 Mar 2000 11:04:57 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Mar 2000 11:08:19 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Cc: "'agenda@ietf.org'" Subject: Draft 2, CAT-WG Adelaide agenda, reflecting time shift Date: Fri, 3 Mar 2000 11:14:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk In the current draft of the IETF Adelaide agenda, the CAT-WG session has been shifted from Monday AM, 0930-1130 to Monday PM, 1530-1730. This Draft 2 agenda reflects this shift, but includes no other changes. CAT-WG Adelaide Agenda, Draft 2 as of 3 March February 2000 Session on Monday, 27 March, 1530-1730 1530-1540: Opening remarks 1540-1605: Kerberos-Revisions (Cliff Neuman) 1605-1620: Kerberos PK-Init (Cliff Neuman) 1620-1640: Kerberos DNS-Locate (Ken Hornstein) 1640-1650: GAA-API (Cliff Neuman) 1650-1720: Other business as needed 1720-1730: Status review and closing remarks --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Mar 7 07:05:46 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07216 for ; Tue, 7 Mar 2000 07:05:45 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA26632 for ietf-cat-wg-out720680; Tue, 7 Mar 2000 03:28:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA26627 for ; Tue, 7 Mar 2000 03:28:13 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28716; Tue, 7 Mar 2000 06:28:09 -0500 (EST) Message-Id: <200003071128.GAA28716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-krb5gss-mech2-03.txt Date: Tue, 07 Mar 2000 06:28:08 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The Kerberos Version 5 GSSAPI Mechanism, Version 2 Author(s) : T. Yu Filename : draft-ietf-cat-krb5gss-mech2-03.txt Pages : 23 Date : 06-Mar-00 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFC 2743) when using Kerberos Version 5 technology (as specified in RFC 1510). This obsoletes RFC 1964. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-krb5gss-mech2-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-krb5gss-mech2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-krb5gss-mech2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-krb5gss-mech2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-krb5gss-mech2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120224.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Mar 7 14:22:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11537 for ; Tue, 7 Mar 2000 14:22:38 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA07939 for ietf-cat-wg-out720680; Tue, 7 Mar 2000 10:51:23 -0800 (PST) Received: from mail.campuspipeline.com ([206.81.132.105]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA07930 for ; Tue, 7 Mar 2000 10:51:20 -0800 (PST) Received: from cadbury ([206.81.132.94]) by mail.campuspipeline.com (Netscape Messaging Server 3.62) with SMTP id 525 for ; Tue, 7 Mar 2000 11:49:37 -0700 Message-ID: <052701bf8866$8d62fe20$e601010a@cadbury.in.teamp.com> From: "Vishal Goenka" To: Subject: Single Sign-On Date: Tue, 7 Mar 2000 11:54:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Does anyone know if there is a working group that has single sign-on (sso) as its area of interest? I haven't seen much discussion about sso in this WG so far. If anyone is interested, I have posted an internet-draft on sso architecture, which I would like to have to relevant WG take a look at. The draft is named draft-goenka-single-sign-on-arch-00.txt -Vishal -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Mar 7 21:42:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22964 for ; Tue, 7 Mar 2000 21:42:47 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA06142 for ietf-cat-wg-out720680; Tue, 7 Mar 2000 18:13:11 -0800 (PST) Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA06137 for ; Tue, 7 Mar 2000 18:13:08 -0800 (PST) Received: from jtrostle-nt2 (dhcp-171-71-229-175.cisco.com [171.71.229.175]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA18847; Tue, 7 Mar 2000 18:11:56 -0800 (PST) Message-Id: <4.1.20000307180917.00bb9310@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 07 Mar 2000 18:15:50 -0800 To: joda@pdc.kth.se (Johan Danielsson), ietf-cat-wg@lists.Stanford.EDU From: Jonathan Trostle Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt In-Reply-To: References: <200002251132.GAA04976@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 02:21 PM 3/3/00 +0100, Johan Danielsson wrote: > >> KRB-PRIV message (see [3]) This KRB-PRIV message must be generated >> using the subkey from the authenticator in the AP-REQ data. >> >> The user-data component of the message consists of the following >> ASN.1 structure encoded as an OCTET STRING: > >I feel very strongly that ASN.1 shouldn't be used for new protocols >defined by the IETF. Especially so, since this defines a new construct >(CHOICE) that is not part of RFC1510. Other people feel strongly that ASN.1 is a good choice since it's standard and there are many commercial compilers for it now. > >Btw, what does `encoded as an OCTET STRING' mean? That's a mistake that I will fix. Thanks for catching it. > >> In the cleartext password case, if the old password is sent in the >> request, the request is defined to be a change password request. > >Why do you want the old password? The old password can be used for additional password policy checking - e.g., to make sure the new and old passwords are sufficiently different. > >> result string - from [4]: >> This field is a UTF-8 encoded string which should be displayed >> to the user by the client. > >Why suddenly UTF-8? All strings in RFC1510 are of type GeneralString. It's a carryover from change password version 1, if I recall correctly. Jonathan > >/Johan >-++**==--++**==--++**==--++**==--++**==--++**==--++**== >This message was posted through the Stanford campus mailing list >server. If you wish to unsubscribe from this mailing list, send the >message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 01:24:05 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24465 for ; Wed, 8 Mar 2000 01:24:05 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA15320 for ietf-cat-wg-out720680; Tue, 7 Mar 2000 21:56:17 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id VAA15315 for ; Tue, 7 Mar 2000 21:56:14 -0800 (PST) Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id AAA03108 for ; Wed, 8 Mar 2000 00:56:11 -0500 (EST) Message-Id: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt In-reply-to: Your message of "Tue, 07 Mar 2000 18:15:50 PST." <4.1.20000307180917.00bb9310@nsm-mail2> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 08 Mar 2000 00:56:10 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>I feel very strongly that ASN.1 shouldn't be used for new protocols >>defined by the IETF. Especially so, since this defines a new construct >>(CHOICE) that is not part of RFC1510. > >Other people feel strongly that ASN.1 is a good choice since it's standard >and there are many commercial compilers for it now. Didn't Ted T'so post a long message about the use of ASN.1 for Kerberos that ended with the line, "Friends don't let friends use ASN.1"? :-) I would have to agree with Johan on this one. I don't know if there was ever a formal IETF statement on the use of ASN.1 for new protocols, but I always thought it was "discouraged". --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 15:52:04 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02167 for ; Wed, 8 Mar 2000 15:52:03 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA08750 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 12:19:27 -0800 (PST) Received: from blubb.pdc.kth.se (asynk43.modempool.kth.se [130.237.10.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA08735 for ; Wed, 8 Mar 2000 12:19:23 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12Smuo-000059-00; Wed, 8 Mar 2000 21:18:42 +0100 To: Jonathan Trostle Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200002251132.GAA04976@ietf.org> <4.1.20000307180917.00bb9310@nsm-mail2> From: joda@pdc.kth.se (Johan Danielsson) Date: 08 Mar 2000 21:18:40 +0100 In-Reply-To: Jonathan Trostle's message of "Tue, 07 Mar 2000 18:15:50 -0800" Message-ID: Lines: 26 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Jonathan Trostle writes: > Other people feel strongly that ASN.1 is a good choice since it's > standard and there are many commercial compilers for it now. It's a horribly complicated standard that also isn't freely available. There are various crash-course documents describing small subsets of it, but I don't think that it's a good idea to build public standards on them. The fact that someone is selling compilers is only a proof that there are consumers, not that it's a good idea. I'd rather see the use of something like XDR that has a wide acceptance (you'll find a compiler for it on the nearest unix machine), and is trivial to implement (and it still has all the features we want). I personally think that ASN.1 is evil. > It's a carryover from change password version 1, if I recall correctly. You're right, I must have completely missed that. Anyhow I'm not sure it's a good idea to start using UTF-8 here, if the rest of the Kerberos standard is using 10646 (I believe this is the implication of the use of GeneralString, right?). /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 16:15:21 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09278 for ; Wed, 8 Mar 2000 16:15:20 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA09102 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 12:27:09 -0800 (PST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.177.1.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA09097 for ; Wed, 8 Mar 2000 12:27:06 -0800 (PST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id PAA29736; Wed, 8 Mar 2000 15:26:55 -0500 (EST) To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> From: Tom Yu Date: 08 Mar 2000 15:26:54 -0500 In-Reply-To: Ken Hornstein's message of "Wed, 08 Mar 2000 00:56:10 -0500" Message-ID: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "kenh" == Ken Hornstein writes: >>> I feel very strongly that ASN.1 shouldn't be used for new >>> protocols defined by the IETF. Especially so, since this defines a >>> new construct (CHOICE) that is not part of RFC1510. >> >> Other people feel strongly that ASN.1 is a good choice since it's >> standard and there are many commercial compilers for it now. Commercial compilers are often not a viable option for low-budget projects and open-source code. kenh> Didn't Ted T'so post a long message about the use of ASN.1 for kenh> Kerberos that ended with the line, "Friends don't let friends kenh> use ASN.1"? :-) I seem to recall that... kenh> I would have to agree with Johan on this one. I don't know if kenh> there was ever a formal IETF statement on the use of ASN.1 for kenh> new protocols, but I always thought it was "discouraged". Perhaps a working group should be formed to discuss the lack of an IETF presentation layer... I'm only partially joking. I have been contemplating the wisdom of using ASN.1 or any other of various encodings that has the function of a "presentation layer". There seems to have a fair amount of near-religious fervor against ASN.1, and some not-quite-as-fervent support for ASN.1. There are a number of valid reasons both for and against the use of ASN.1 in IETF protocols. Most IETF protocols do not need the complexity that ASN.1 comes with, and can be addressed by XDR, line-oriented ASCII, XML (yuck), etc. One could argue that Kerberos and related protocols aren't really deserving of the capabilities of ASN.1, but it is kind of a toss-up in my opinion. The main issues that I see are that the primary standards documents relating to ASN.1 aren't widely available, and there is no extensive guids on how to avoid certain common pitfalls associated with using ASN.1. The latter point I intend to address by writing an Informational or BCP RFC about it. The former isn't likely to get fixed until we can convince the ITU-T or the ISO (less likely) to release certain documents that IETF standards depend on for free to the IETF community. ---Tom -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 16:23:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11604 for ; Wed, 8 Mar 2000 16:23:09 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA09948 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 12:46:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA09943 for ; Wed, 8 Mar 2000 12:46:28 -0800 (PST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10219 for ; Wed, 8 Mar 2000 13:46:25 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA00813; Wed, 8 Mar 2000 12:46:25 -0800 (PST) Received: from teal (awe8-124.Central.Sun.COM [129.147.8.124]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e28KkNQ203047; Wed, 8 Mar 2000 12:46:23 -0800 (PST) Date: Wed, 8 Mar 2000 12:49:16 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt To: Johan Danielsson Cc: ietf-cat-wg@lists.Stanford.EDU In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > I'd rather see the use of something like XDR that has a wide > acceptance (you'll find a compiler for it on the nearest unix > machine), and is trivial to implement (and it still has all the > features we want). Might as well go the full distance and use ONC RPC too. The MIT krb5 1.0 wad includes a complete RPC-based protocol to allow administrators to set passwords, and more, and lets users change their password as well. -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 16:47:12 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18298 for ; Wed, 8 Mar 2000 16:47:11 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA11853 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 13:21:03 -0800 (PST) Received: from blubb.pdc.kth.se (asynk43.modempool.kth.se [130.237.10.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA11846 for ; Wed, 8 Mar 2000 13:20:59 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12Snsg-00007R-00; Wed, 8 Mar 2000 22:20:34 +0100 To: Mike Eisler Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: From: joda@pdc.kth.se (Johan Danielsson) Date: 08 Mar 2000 22:20:32 +0100 In-Reply-To: Mike Eisler's message of "Wed, 8 Mar 2000 12:49:16 -0800 (PST)" Message-ID: Lines: 10 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Mike Eisler writes: > The MIT krb5 1.0 wad includes a complete RPC-based protocol to allow > administrators to set passwords, and more, and lets users change > their password as well. Yes, but it's complex and at least somewhat undocumented. These drafts are attempts at simpler interfaces. /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 17:11:21 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25555 for ; Wed, 8 Mar 2000 17:11:20 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA13200 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 13:37:20 -0800 (PST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.177.1.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA13194 for ; Wed, 8 Mar 2000 13:37:16 -0800 (PST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id QAA29955; Wed, 8 Mar 2000 16:37:06 -0500 (EST) To: joda@pdc.kth.se (Johan Danielsson) Cc: Jonathan Trostle , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200002251132.GAA04976@ietf.org> <4.1.20000307180917.00bb9310@nsm-mail2> From: Tom Yu Date: 08 Mar 2000 16:37:05 -0500 In-Reply-To: joda@pdc.kth.se's message of "08 Mar 2000 21:18:40 +0100" Message-ID: Lines: 45 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "joda" == Johan Danielsson writes: joda> It's a horribly complicated standard that also isn't freely joda> available. There are various crash-course documents describing joda> small subsets of it, but I don't think that it's a good idea to joda> build public standards on them. I will agree that the crash-course documents are no substitute for reading the actual spec, if you can find it or afford it. I don't think anyone should be allowed to use ASN.1 in an IETF protocol unless they've read and *understood* the actual spec, as opposed to random crash-course documents that may be misleading in ways. joda> I'd rather see the use of something like XDR that has a wide joda> acceptance (you'll find a compiler for it on the nearest unix joda> machine), and is trivial to implement (and it still has all the joda> features we want). XDR is likely more useful than ASN.1 for many things, though I suspect that there may be some existing sentiment against XDR due to its use in RPC, which people may dislike due to security holes in its implementations. For what it's worth, I don't think that I've found many security problems in XDR, and the bulk of the nasty bugs I've found have been within the RPC framework itself or within the implementations of RPC services. joda> You're right, I must have completely missed that. Anyhow I'm not joda> sure it's a good idea to start using UTF-8 here, if the rest of joda> the Kerberos standard is using 10646 (I believe this is the joda> implication of the use of GeneralString, right?). It's worse than that. GeneralString isn't ISO-10646. It's ISO-2022, I believe, with associated things like 7 or 8 bits of encoding per character, locking and non-locking shifts, G0, C0, G1, C1, etc. Just think back to the way VT100 terminals handle character sets. yuck. I believe there's a movement to use UTF8String tagged as GeneralString for the 1510 revision, though the notation "[UNIVERAL 27] IMPLICIT UTF8String" isn't compliant, technically. I think the original idea was to use UniversalString or BMPString which are ISO-10646, but someone perhaps got confused with the plethora of character string types in ASN.1. *sigh* ---Tom -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 17:19:22 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27759 for ; Wed, 8 Mar 2000 17:19:22 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA14092 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 13:52:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA14086 for ; Wed, 8 Mar 2000 13:52:07 -0800 (PST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16144 for ; Wed, 8 Mar 2000 14:52:06 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA14479; Wed, 8 Mar 2000 13:52:06 -0800 (PST) Received: from teal (awe8-124.Central.Sun.COM [129.147.8.124]) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) with SMTP id e28Lq4Q214140; Wed, 8 Mar 2000 13:52:04 -0800 (PST) Date: Wed, 8 Mar 2000 13:54:57 -0800 (PST) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt To: Johan Danielsson Cc: ietf-cat-wg@lists.Stanford.EDU In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > The MIT krb5 1.0 wad includes a complete RPC-based protocol to allow > > administrators to set passwords, and more, and lets users change > > their password as well. > > Yes, but it's complex and at least somewhat undocumented. These drafts > are attempts at simpler interfaces. It's more complex than a protocol to let admin or users change a user's password, which in turn is more complex than a protocol to let a user change his own password. It also is complete solution. The set-passwd protocol is simply a step down the road to more remote administration. If an admin wants to set a password, won't he also want to set other attributes of a principal? If so, will he use the proposed protocol, or will he used whatever proprietary protocol his vendor (possibly based on or equal to the MIT protocol) the system vendor provides? > [...] and at least somewhat undocumented. So document it, or something that else that is equivalent. -mre -mre -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 17:25:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29341 for ; Wed, 8 Mar 2000 17:25:33 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id NAA14427 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 13:57:29 -0800 (PST) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA14398 for ; Wed, 8 Mar 2000 13:57:23 -0800 (PST) Received: from dstc.qut.edu.au (eruption.dstc.qut.edu.au [131.181.71.5]) by typhoon.dstc.qut.edu.au (8.9.3/8.9.3) with ESMTP id HAA22766; Thu, 9 Mar 2000 07:57:12 +1000 (EST) Message-ID: <38C6CCB7.1EA72A55@dstc.qut.edu.au> Date: Thu, 09 Mar 2000 07:57:11 +1000 From: Geoff Elgey Organization: DSTC X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tom Yu , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit G'day, Tom Yu wrote: > The main issues that I see are that the primary standards documents > relating to ASN.1 aren't widely available, and there is no extensive > guids on how to avoid certain common pitfalls associated with using > ASN.1. The latter point I intend to address by writing an > Informational or BCP RFC about it. The former isn't likely to get > fixed until we can convince the ITU-T or the ISO (less likely) to > release certain documents that IETF standards depend on for free to > the IETF community. I agree about the standards not being freely available -- I *desparately* need to look at the semantic model for ASN.1 types (as type equivalency is not defined in the latest X.680 specification), and that document is only available "for subscription holders only". Here's my credit card, there's the document, but I cannot get it. I've got a good idea about what's in the semantic model, but no way of confirming it unless I get a subscription to the ITU-T :-( There's also the issue of some parts of the specification being "a guide to tool implementors", rather than being clearly defined (as I have since found out). I'm trying to wrangle an airfare to Geneva for the next ASN.1 standards meeting, and I will (hopefully) be raising the points you mention (especially about protocols being written by people who have no real understanding of the standards, as the standards cost money). There is a downloadable ASN.1 textbook available though -- John Larmouth's "ASN.1 Complete" (see http://www.nokalva.com/asn1/larmouth.html) which supplements the X.680-X.683 specifications quite well. However, it does not mention how to avoid the "common pitfalls" of using ASN.1. Publishing a document on this topic is an excellent idea. Cheers, Geoff -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 17:53:26 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06128 for ; Wed, 8 Mar 2000 17:53:26 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA16161 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 14:22:07 -0800 (PST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.177.1.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA16146 for ; Wed, 8 Mar 2000 14:22:00 -0800 (PST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id RAA00004; Wed, 8 Mar 2000 17:21:54 -0500 (EST) To: joda@pdc.kth.se (Johan Danielsson) Cc: Jonathan Trostle , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200002251132.GAA04976@ietf.org> <4.1.20000307180917.00bb9310@nsm-mail2> From: Tom Yu Date: 08 Mar 2000 17:21:53 -0500 In-Reply-To: Tom Yu's message of "08 Mar 2000 16:37:05 -0500" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk following up to my own post. :-) >>>>> "tlyu" == Tom Yu writes: tlyu> For what it's worth, I don't think that I've found many security tlyu> problems in XDR Sorry, I meant I don't think I've found *any* security problems in XDR, but I haven't looked all that closely yet. ---Tom -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 21:36:01 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12611 for ; Wed, 8 Mar 2000 21:36:00 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id SAA29475 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 18:07:18 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA29467 for ; Wed, 8 Mar 2000 18:07:14 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id VAA04596; Wed, 8 Mar 2000 21:07:09 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: Mime-Version: 1.0 From: Ken Raeburn Date: 08 Mar 2000 21:07:09 -0500 In-Reply-To: Mike Eisler's message of "Wed, 8 Mar 2000 13:54:57 -0800 (PST)" Message-ID: Lines: 31 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Mike Eisler writes: >> [...kadmin protocol...] > It's more complex than a protocol to let admin or users change a user's > password, which in turn is more complex than a protocol to let a user change > his own password. It also is complete solution. Taking the kadmin code, regenerating a .x file for it, and putting it on top of RPCSEC_GSS might be a good start for standardizing an admin protocol. > The set-passwd protocol is simply a step down the road to more remote > administration. If an admin wants to set a password, won't he also want to > set other attributes of a principal? If so, will he use the proposed This is why I'd be opposed to the set-passwd changes. The change-passwd spec as is fills a gap required by the basic Kerberos protocol (the "must change password" response); it's not a remote administration tool. Well, maybe it's borderline, but set-passwd is clearly on the admin-tool side, and not directly needed by anything in the core protocol. Let's do it right, and not tack it on the side of the basic change-passwd protocol. Maybe we could alter the change-passwd spec to support other administrative functions, but it needs to have the right extensibility hook, which IIRC it didn't. (But I'm on a bad net connection at connectathon right now and can't easily check, sorry.) I don't think altering it to support *one* admin function, and still requiring a separate protocol for the others, makes much sense. Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 8 23:06:45 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08079 for ; Wed, 8 Mar 2000 23:06:45 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id TAA04579 for ietf-cat-wg-out720680; Wed, 8 Mar 2000 19:40:44 -0800 (PST) Received: from saint-elmos-fire.mit.edu (tlyu@SAINT-ELMOS-FIRE.MIT.EDU [18.177.1.43]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id TAA04564 for ; Wed, 8 Mar 2000 19:40:37 -0800 (PST) Received: (from tlyu@localhost) by saint-elmos-fire.mit.edu (8.9.3) id WAA00278; Wed, 8 Mar 2000 22:40:18 -0500 (EST) To: Geoff Elgey Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> <38C6CCB7.1EA72A55@dstc.qut.edu.au> From: Tom Yu Date: 08 Mar 2000 22:40:17 -0500 In-Reply-To: Geoff Elgey's message of "Thu, 09 Mar 2000 07:57:11 +1000" Message-ID: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "elgey" == Geoff Elgey writes: elgey> I'm trying to wrangle an airfare to Geneva for the next ASN.1 elgey> standards meeting, and I will (hopefully) be raising the points elgey> you mention (especially about protocols being written by people elgey> who have no real understanding of the standards, as the elgey> standards cost money). You know, this is one thing that the supposed new alliance between the IETF and the ITU-T should help with, in theory. :-) I really wish that some practical benefit would arrise from the cooperation of the IETF and the ITU-T. elgey> There is a downloadable ASN.1 textbook available though -- John elgey> Larmouth's "ASN.1 Complete" (see elgey> http://www.nokalva.com/asn1/larmouth.html) which supplements elgey> the X.680-X.683 specifications quite well. However, it does not elgey> mention how to avoid the "common pitfalls" of using elgey> ASN.1. Publishing a document on this topic is an excellent elgey> idea. I have skimmed John Larmouth's book, which seems to be reasonably well written. I am in the process of writing up a document describing the common pitfalls that I have encountered in the use of ASN.1 in IETF protocols. Hopefully I can get it in before the draft cut-off for Adelaide. ---Tom -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 04:53:30 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29345 for ; Thu, 9 Mar 2000 04:53:30 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id BAA16927 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 01:28:25 -0800 (PST) Received: from blubb.pdc.kth.se (async64.modempool.kth.se [130.237.10.64]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id BAA16922 for ; Thu, 9 Mar 2000 01:28:22 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12SzEN-0000Ir-00; Thu, 9 Mar 2000 10:27:43 +0100 To: Geoff Elgey Cc: Tom Yu , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> <38C6CCB7.1EA72A55@dstc.qut.edu.au> From: joda@pdc.kth.se (Johan Danielsson) Date: 09 Mar 2000 10:27:43 +0100 In-Reply-To: Geoff Elgey's message of "Thu, 09 Mar 2000 07:57:11 +1000" Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Geoff Elgey writes: > There is a downloadable ASN.1 textbook available though -- John > Larmouth's "ASN.1 Complete" (see > http://www.nokalva.com/asn1/larmouth.html) which supplements the > X.680-X.683 specifications quite well. However, it does not mention how > to avoid the "common pitfalls" of using ASN.1. Publishing a document on > this topic is an excellent idea. It's also more of a technical overview than a document you can use to implement anything. It only helps you a small amount if you want to implement a ASN.1 parser. /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 04:53:51 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29422 for ; Thu, 9 Mar 2000 04:53:50 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id BAA16819 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 01:23:47 -0800 (PST) Received: from blubb.pdc.kth.se (async64.modempool.kth.se [130.237.10.64]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id BAA16811 for ; Thu, 9 Mar 2000 01:23:42 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12SzA7-00009y-00; Thu, 9 Mar 2000 10:23:19 +0100 To: Ken Raeburn Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: From: joda@pdc.kth.se (Johan Danielsson) Date: 09 Mar 2000 10:23:19 +0100 In-Reply-To: Ken Raeburn's message of "08 Mar 2000 21:07:09 -0500" Message-ID: Lines: 13 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Raeburn writes: > This is why I'd be opposed to the set-passwd changes. The > change-passwd spec as is fills a gap required by the basic Kerberos > protocol (the "must change password" response); it's not a remote > administration tool. I agree. Are you (as in someone at MIT) going to brush up the OV kadmin spec and submit it as a draft? /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 11:27:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28195 for ; Thu, 9 Mar 2000 11:27:58 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id IAA25785 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 08:00:54 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA25779 for ; Thu, 9 Mar 2000 08:00:47 -0800 (PST) Received: from cisco.com (dhcp-o-38-159.cisco.com [171.71.38.159]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA00732; Thu, 9 Mar 2000 07:59:43 -0800 (PST) Message-ID: <38C7CB4F.53D98040@cisco.com> Date: Thu, 09 Mar 2000 08:03:27 -0800 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Yu CC: Ken Hornstein , ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt References: <200003080556.AAA03108@ginger.cmf.nrl.navy.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Tom, Tom Yu wrote: > > >>>>> "kenh" == Ken Hornstein writes: > > >>> I feel very strongly that ASN.1 shouldn't be used for new > >>> protocols defined by the IETF. Especially so, since this defines a > >>> new construct (CHOICE) that is not part of RFC1510. > >> > >> Other people feel strongly that ASN.1 is a good choice since it's > >> standard and there are many commercial compilers for it now. > > Commercial compilers are often not a viable option for low-budget > projects and open-source code. > from http://oscar.dstc.qut.edu.au/ "DSTC modified version of SNACC released. We have released a modified version of the SNACC ASN.1 compiler which supports Big Integers and DER. This compiler has been released under the GPL and is available for download." This work was done so that SNACC could support X.509. > kenh> Didn't Ted T'so post a long message about the use of ASN.1 for > kenh> Kerberos that ended with the line, "Friends don't let friends > kenh> use ASN.1"? :-) I'd be interested in seeing that message. Is there a web archive of this list that is available? thanks, David mcgrew@cisco.com -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 11:47:41 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04131 for ; Thu, 9 Mar 2000 11:47:38 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA26212 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 08:20:39 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA26201 for ; Thu, 9 Mar 2000 08:20:35 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 9 Mar 2000 16:17:12 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA18372; Thu, 9 Mar 2000 11:18:13 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 9 Mar 2000 11:21:41 -0500 Message-ID: From: "Linn, John" To: "'David A. McGrew'" Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: comments on draft-ietf-cat-kerberos-set-passwd-02.txt Date: Thu, 9 Mar 2000 11:29:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk David writes, excerpting: > > I'd be interested in seeing that message. Is there a web archive of > this list that is available? The currently live archive of the CAT WG list can be found at the IETF secretariat, in ftp://ftp.ietf.org/ietf-mail-archive/cat/. It's subdivided by months, and has been backfilled to the beginning of 1998. Earlier archive spools are available at ftp://bitsy.mit.edu/cat-ietf/archive. --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 12:00:01 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08536 for ; Thu, 9 Mar 2000 12:00:00 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA26282 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 08:23:22 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA26277 for ; Thu, 9 Mar 2000 08:23:14 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 9 Mar 2000 16:19:51 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA18490; Thu, 9 Mar 2000 11:20:46 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 9 Mar 2000 11:24:14 -0500 Message-ID: From: "Linn, John" To: "'Vishal Goenka'" , ietf-cat-wg@lists.Stanford.EDU Subject: RE: Single Sign-On Date: Thu, 9 Mar 2000 11:31:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Vishal, I don't believe that single sign-on, per se, is included within the charter of any current IETF working groups. --jl > -----Original Message----- > From: Vishal Goenka [mailto:vgoenka@campuspipeline.com] > Sent: Tuesday, March 07, 2000 1:54 PM > To: ietf-cat-wg@lists.Stanford.EDU > Subject: Single Sign-On > > > Does anyone know if there is a working group that has single > sign-on (sso) > as its area of interest? I haven't seen much discussion about > sso in this WG > so far. If anyone is interested, I have posted an > internet-draft on sso > architecture, which I would like to have to relevant WG take > a look at. > > The draft is named draft-goenka-single-sign-on-arch-00.txt > > -Vishal > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 13:37:33 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09954 for ; Thu, 9 Mar 2000 13:37:32 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id KAA00241 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 10:07:42 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id KAA00236 for ; Thu, 9 Mar 2000 10:07:39 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Mar 2000 09:56:46 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 09:56:46 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690716F636@SIT.platinum.corp.microsoft.com> From: John Brezak To: "'joda@pdc.kth.se'" , Ken Raeburn Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: comments on draft-ietf-cat-kerberos-set-passwd-02.txt Date: Thu, 9 Mar 2000 09:56:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Why invent another admin protocol for dealing with account admin? LDAP can be used for this. There are already examples of this both commercially and opensource (LDAP+Heimdal). Given the wide availability of LDAP based account management tools, it would seem that the most useful admin protocol would follow along the lines of LDAP. This missing part would be to define a LDAP schema definition that includes the needed principal attributes for dealing with Kerberos. The one problem with LDAP is that it isn't good for setting passwords due to the general nature of the protocol with regard to encryption. This is a reason for having a specific password management protocol. This would allow an implementor to be able to use the strongest encryption available to protect the user's passwords independant of what general encryption can be used for general account management. > -----Original Message----- > From: joda@pdc.kth.se [mailto:joda@pdc.kth.se] > Sent: Thursday, March 09, 2000 1:23 AM > To: Ken Raeburn > Cc: ietf-cat-wg@lists.stanford.edu > Subject: Re: comments on draft-ietf-cat-kerberos-set-passwd-02.txt > > > Ken Raeburn writes: > > > This is why I'd be opposed to the set-passwd changes. The > > change-passwd spec as is fills a gap required by the basic Kerberos > > protocol (the "must change password" response); it's not a remote > > administration tool. > > I agree. > > Are you (as in someone at MIT) going to brush up the OV kadmin spec > and submit it as a draft? > > /Johan > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 17:08:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09181 for ; Thu, 9 Mar 2000 17:08:04 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA11356 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 13:36:46 -0800 (PST) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA11350 for ; Thu, 9 Mar 2000 13:36:44 -0800 (PST) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA16238; Thu, 9 Mar 2000 13:36:44 -0800 (PST) Message-Id: <200003092136.NAA16238@breakaway.Stanford.EDU> X-Mailer: exmh version 2.0.2 2/24/98 Subject: TLS/SSL implementation support for RFC2712? To: ietf-cat-wg@lists.Stanford.EDU cc: Jeff.Hodges@stanford.edu From: Jeff.Hodges@stanford.edu Reply-to: ietf-cat-wg@lists.Stanford.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Mar 2000 13:36:44 -0800 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I'm curious about who all's TLS/SSL implementations support RFC2712 "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Anyone know of any that do off-hand? thanks, JeffH -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 17:35:49 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18742 for ; Thu, 9 Mar 2000 17:35:45 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA13627 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 14:08:41 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA13622 for ; Thu, 9 Mar 2000 14:08:38 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id RAA16465 for ; Thu, 9 Mar 2000 17:08:35 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id RAA27955 for ; Thu, 9 Mar 2000 17:08:33 -0500 Message-Id: <200003092208.RAA27955@elvis.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: TLS/SSL implementation support for RFC2712? In-reply-to: Your message of "Thu, 09 Mar 2000 13:36:44 PST." <200003092136.NAA16238@breakaway.Stanford.EDU> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 09 Mar 2000 17:08:33 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >I'm curious about who all's TLS/SSL implementations support RFC2712 "Addition >of Kerberos Cipher Suites to Transport Layer Security (TLS)". > >Anyone know of any that do off-hand? thanks, I have a distribution (that I keep meaning to put up on an FTP site) that does one for OpenSSL. I didn't do the work (just saying that up front, so everyone understands I'm not trying to take credit for it). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 18:23:26 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01759 for ; Thu, 9 Mar 2000 18:23:25 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA15944 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 14:49:21 -0800 (PST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA15938 for ; Thu, 9 Mar 2000 14:49:17 -0800 (PST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA25938; Thu, 9 Mar 2000 17:49:15 -0500 (EST) Date: Thu, 9 Mar 2000 17:49:15 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: TLS/SSL implementation support for RFC2712? In-Reply-To: Your message of Thu, 09 Mar 2000 17:08:33 -0500 Message-ID: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > >I'm curious about who all's TLS/SSL implementations support RFC2712 "Addition > >of Kerberos Cipher Suites to Transport Layer Security (TLS)". > > > >Anyone know of any that do off-hand? thanks, > > I have a distribution (that I keep meaning to put up on an FTP site) that > does one for OpenSSL. I didn't do the work (just saying that up front, > so everyone understands I'm not trying to take credit for it). Please forward me this code so that I can get it added to 0.9.6 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 18:32:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04310 for ; Thu, 9 Mar 2000 18:32:50 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA16449 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 14:58:47 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA16444 for ; Thu, 9 Mar 2000 14:58:44 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id RAA16765; Thu, 9 Mar 2000 17:58:42 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id RAA28148; Thu, 9 Mar 2000 17:58:40 -0500 Message-Id: <200003092258.RAA28148@elvis.cmf.nrl.navy.mil> To: jaltman@columbia.edu cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: TLS/SSL implementation support for RFC2712? In-reply-to: Your message of "Thu, 09 Mar 2000 17:49:15 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` Date: Thu, 09 Mar 2000 17:58:40 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Please forward me this code so that I can get it added to 0.9.6 According to the author, the code isn't in the best shape (and I'm not 100% sure it's interoperable with the spec). Let me check with him to see if he's got something newer first. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 18:35:09 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05251 for ; Thu, 9 Mar 2000 18:35:08 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA16744 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 15:03:27 -0800 (PST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA16736 for ; Thu, 9 Mar 2000 15:03:24 -0800 (PST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id SAA28318; Thu, 9 Mar 2000 18:03:22 -0500 (EST) Date: Thu, 9 Mar 2000 18:03:22 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: TLS/SSL implementation support for RFC2712? In-Reply-To: Your message of Thu, 09 Mar 2000 17:58:40 -0500 Message-ID: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > >Please forward me this code so that I can get it added to 0.9.6 > > According to the author, the code isn't in the best shape (and I'm not > 100% sure it's interoperable with the spec). Let me check with him to see > if he's got something newer first. Let me have it anyway. I can always fix the code to match the spec. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 9 18:40:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06800 for ; Thu, 9 Mar 2000 18:40:10 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA17159 for ietf-cat-wg-out720680; Thu, 9 Mar 2000 15:07:44 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA17147 for ; Thu, 9 Mar 2000 15:07:40 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id SAA16833; Thu, 9 Mar 2000 18:07:37 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id SAA28218; Thu, 9 Mar 2000 18:07:36 -0500 Message-Id: <200003092307.SAA28218@elvis.cmf.nrl.navy.mil> To: jaltman@columbia.edu cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: TLS/SSL implementation support for RFC2712? In-reply-to: Your message of "Thu, 09 Mar 2000 18:03:22 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` Date: Thu, 09 Mar 2000 18:07:36 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Let me have it anyway. I can always fix the code to match the spec. Well, I can't give it to you and not give it to everyone else, now can I? :-) ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/kssl-0.1a.tgz --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 11:51:36 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17717 for ; Fri, 10 Mar 2000 11:51:34 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA18235 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 08:21:00 -0800 (PST) Received: from corp.tivoli.com ([216.140.178.60]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA18230 for ; Fri, 10 Mar 2000 08:20:57 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id KAA01552; Fri, 10 Mar 2000 10:20:53 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625689E.004C4991 ; Fri, 10 Mar 2000 07:53:15 -0600 X-Lotus-FromDomain: TIVOLI SYSTEMS To: "Vishal Goenka" cc: ietf-cat-wg@lists.Stanford.EDU Message-ID: <8625689E.004C455C.00@tivmta4.tivoli.com> Date: Fri, 10 Mar 2000 10:17:26 -0600 Subject: Re: Single Sign-On Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Vishal, The Open Group has published a standard for SSO architecture and API which is based on Sun's PAM technology. You can find it at: http://www.opengroup.org/online-pubs?DOC=008329799 --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit "Vishal Goenka" on 03/07/2000 12:54:22 PM To: ietf-cat-wg@lists.Stanford.EDU cc: (bcc: George Robert Blakley III/Tivoli Systems) Subject: Single Sign-On Does anyone know if there is a working group that has single sign-on (sso) as its area of interest? I haven't seen much discussion about sso in this WG so far. If anyone is interested, I have posted an internet-draft on sso architecture, which I would like to have to relevant WG take a look at. The draft is named draft-goenka-single-sign-on-arch-00.txt -Vishal -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 12:00:54 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20951 for ; Fri, 10 Mar 2000 12:00:52 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id IAA18736 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 08:36:05 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA18731 for ; Fri, 10 Mar 2000 08:36:03 -0800 (PST) Received: from phobos ([13.2.118.23]) by alpha.xerox.com with SMTP id <67797(2)>; Fri, 10 Mar 2000 08:36:01 PST From: "Mike Spreitzer" To: "IETF CAT fanciers \(E-mail\)" Cc: "Mike Spreitzer \(E-mail\)" Subject: 1510bis? Message-ID: <005f01bf8aae$b31bf640$1776020d@parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Date: Fri, 10 Mar 2000 08:36:01 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit What's the deal on 1510bis? Can I see a current draft? With deltas from RFC 1510 highlighted? Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 12:39:32 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03458 for ; Fri, 10 Mar 2000 12:39:32 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA20517 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 09:07:06 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA20504 for ; Fri, 10 Mar 2000 09:07:01 -0800 (PST) Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA29058; Fri, 10 Mar 2000 09:06:59 -0800 (PST) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id JAA08378; Fri, 10 Mar 2000 09:06:59 -0800 (PST) Date: Fri, 10 Mar 2000 09:06:59 -0800 (PST) Message-Id: <200003101706.JAA08378@cayman-islands.isi.edu> From: Clifford Neuman To: spreitze@parc.xerox.com CC: ietf-cat-wg@lists.Stanford.EDU, spreitze@parc.xerox.com In-reply-to: <005f01bf8aae$b31bf640$1776020d@parc.xerox.com> (spreitze@parc.xerox.com) Subject: Re: 1510bis? Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk A new draft will be submitted today before the deadline. Clifford Neuman From: "Mike Spreitzer" Cc: "Mike Spreitzer \(E-mail\)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Date: Fri, 10 Mar 2000 08:36:01 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk What's the deal on 1510bis? Can I see a current draft? With deltas from RFC 1510 highlighted? Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 14:57:45 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23456 for ; Fri, 10 Mar 2000 14:57:44 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA26673 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 11:11:19 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA26668 for ; Fri, 10 Mar 2000 11:11:16 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id OAA22506 for ; Fri, 10 Mar 2000 14:11:13 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id OAA29682 for ; Fri, 10 Mar 2000 14:11:11 -0500 Message-Id: <200003101911.OAA29682@elvis.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Single Sign-On In-reply-to: Your message of "Fri, 10 Mar 2000 10:17:26 CST." <8625689E.004C455C.00@tivmta4.tivoli.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 10 Mar 2000 14:11:11 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >The Open Group has published a standard for SSO architecture and API which is >based on Sun's PAM technology. You can find it at: I think you've got it a bit backwards .... There was an original OSF RFC which specified PAM, which Sun based _their_ PAM implementation on. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 15:58:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14660 for ; Fri, 10 Mar 2000 15:58:48 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA00489 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 12:28:09 -0800 (PST) Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA00482 for ; Fri, 10 Mar 2000 12:28:07 -0800 (PST) Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id A6C5215534; Fri, 10 Mar 2000 15:27:32 -0500 (EST) Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 0CAA27C0E8; Fri, 10 Mar 2000 15:27:32 -0500 (EST) Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 15:27:54 -0500 Message-ID: From: "Salz, Rich" To: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU Subject: RE: Single Sign-On Date: Fri, 10 Mar 2000 15:27:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >There was an original OSF >RFC which specified PAM, which Sun based _their_ PAM implementation on. No, Bob has it correct. (He usually does for all values of "it" :) The CDE project realized they needed an extensible login mechanism. One that would allow a single "login screen" to look basically the same on all machines, yet be extensible (via dynamic libs or whatever) to handle /etc/passwd, YP/NIS/NIS+, KRB5, etc. The vendors all sat around and said "I've got one." Sun had PAM, Digital had something like /etc/svc.order, and I forgot what the other CDE members had. They met, evaluated, and chose PAM. Sun agreed to contribute the technology, including public documentation. You can find the Oct 95 "OSF RFC" (deliberately modelled after the IETF RFC's) at: http://www.opengroup.org/rfc/index.html#rfc86 One of the co-authors of that document is Roland Schemers, a (past?) contributor to this WG. Hope this helps. /r$ -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 16:23:57 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23789 for ; Fri, 10 Mar 2000 16:23:56 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA02041 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 12:47:38 -0800 (PST) Received: from tree0.Stanford.EDU (tree0.Stanford.EDU [171.64.14.231]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA02036 for ; Fri, 10 Mar 2000 12:47:36 -0800 (PST) Received: (from schemers@localhost) by tree0.Stanford.EDU (8.9.3/8.9.3) id MAA01236; Fri, 10 Mar 2000 12:47:28 -0800 (PST) Date: Fri, 10 Mar 2000 12:47:28 -0800 (PST) Message-Id: <200003102047.MAA01236@tree0.Stanford.EDU> From: schemers@stanford.edu To: Ken Hornstein Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Single Sign-On In-Reply-To: <200003101911.OAA29682@elvis.cmf.nrl.navy.mil> References: <8625689E.004C455C.00@tivmta4.tivoli.com> <200003101911.OAA29682@elvis.cmf.nrl.navy.mil> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Hornstein writes: > >The Open Group has published a standard for SSO architecture and API which is > >based on Sun's PAM technology. You can find it at: > > I think you've got it a bit backwards .... There was an original OSF > RFC which specified PAM, which Sun based _their_ PAM implementation on. > Its been while since I worked on this stuff, but here is my recollection: - versions of Solaris < 2.6 had a variant of PAM in them that wasn't for public consumption and didn't offer the "stacking" features of current versions of PAM - while working on DCE at SunSoft, I helped the security group at SunSoft add features like stacking, etc. - the OSF was looking to add PAM-like functionality to CDE, and PAM beat out other proposals by Digital and IBM. We then started working on PAM with HP for the CDE project. - Vipin Sumar and I wrote the OSF RFC at some point during all this - I left SunSoft and worked continued on PAM and it ended up being used in the SSO stuff. I've never looked at the SSO spec so I'm not sure how much it looks like the PAM that is in use in Solaris >2.6, Linux, etc. roland -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 16:29:00 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25757 for ; Fri, 10 Mar 2000 16:28:59 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA02953 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 13:03:47 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA02948 for ; Fri, 10 Mar 2000 13:03:44 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id QAA23413; Fri, 10 Mar 2000 16:03:41 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id QAA29959; Fri, 10 Mar 2000 16:03:39 -0500 Message-Id: <200003102103.QAA29959@elvis.cmf.nrl.navy.mil> To: "Salz, Rich" cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Single Sign-On In-reply-to: Your message of "Fri, 10 Mar 2000 15:27:48 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` Date: Fri, 10 Mar 2000 16:03:39 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>There was an original OSF >>RFC which specified PAM, which Sun based _their_ PAM implementation on. > >No, Bob has it correct. (He usually does for all values of "it" :) (Open mouth, remove foot). My apologies! --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 18:04:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28671 for ; Fri, 10 Mar 2000 18:04:33 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA07503 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 14:34:28 -0800 (PST) Received: from corp.tivoli.com ([216.140.178.60]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA07492 for ; Fri, 10 Mar 2000 14:34:24 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id QAA06176; Fri, 10 Mar 2000 16:34:17 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625689E.006E827A ; Fri, 10 Mar 2000 14:07:03 -0600 X-Lotus-FromDomain: TIVOLI SYSTEMS To: Ken Hornstein cc: ietf-cat-wg@lists.Stanford.EDU Message-ID: <8625689E.006E71BB.00@tivmta4.tivoli.com> Date: Fri, 10 Mar 2000 16:26:03 -0600 Subject: Re: Single Sign-On Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken, Thanks for the correction. What I meant was that TOG XSSO took as its base document the Sun PAM specification; I don't know the previous history of the technology. --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit Ken Hornstein on 03/10/2000 01:11:11 PM To: ietf-cat-wg@lists.Stanford.EDU cc: (bcc: George Robert Blakley III/Tivoli Systems) Subject: Re: Single Sign-On >The Open Group has published a standard for SSO architecture and API which is >based on Sun's PAM technology. You can find it at: I think you've got it a bit backwards .... There was an original OSF RFC which specified PAM, which Sun based _their_ PAM implementation on. --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 10 18:36:05 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09829 for ; Fri, 10 Mar 2000 18:36:04 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA09696 for ietf-cat-wg-out720680; Fri, 10 Mar 2000 15:04:49 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA09691 for ; Fri, 10 Mar 2000 15:04:47 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id RAA24243; Fri, 10 Mar 2000 17:56:22 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id RAA00204; Fri, 10 Mar 2000 17:56:19 -0500 Message-Id: <200003102256.RAA00204@elvis.cmf.nrl.navy.mil> To: George_Robert_Blakley_III@tivoli.com cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Single Sign-On In-reply-to: Your message of "Fri, 10 Mar 2000 16:26:03 CST." <8625689E.006E71BB.00@tivmta4.tivoli.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 10 Mar 2000 17:56:18 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >Thanks for the correction. What I meant was that TOG XSSO took as its base >document the Sun PAM specification; I don't know the previous history of >the technology. Well, it turns out you were more "right" than I was anyway :-) --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun Mar 12 16:35:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10564 for ; Sun, 12 Mar 2000 16:35:38 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA11871 for ietf-cat-wg-out720680; Sun, 12 Mar 2000 12:54:36 -0800 (PST) Received: from mail.campuspipeline.com ([206.81.132.105]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA11866 for ; Sun, 12 Mar 2000 12:54:34 -0800 (PST) Received: from cadbury ([206.81.132.94]) by mail.campuspipeline.com (Netscape Messaging Server 3.62) with SMTP id 502; Sun, 12 Mar 2000 13:52:43 -0700 Message-ID: <00b801bf8c65$97834010$e601010a@cadbury.in.teamp.com> From: "Vishal Goenka" To: Cc: Subject: Re: Single Sign-On Date: Sun, 12 Mar 2000 13:57:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Bob, Thanks for pointing it out. I have been aware of the Open Group's work, and infact, I have discussed the PAM based approach to SSO in my paper as well. I agree that a industry standard API for SSO (the approach taken by the Open Group) is the right way to go, as long as, every application developer is writing to an API like that. Unfortunately, most applications around are either not SSO enabled for lack of a standard API set, or still written to a vendor specific API. In my paper I have presented an alternative approach for applications that are NOT written to a standard API set for whatever reasons, or are not SSO enabled. I therefore, believe that my paper compliments the Open Group's work, instead of competing with it. -Vishal -----Original Message----- From: George_Robert_Blakley_III@tivoli.com To: Vishal Goenka Cc: ietf-cat-wg@lists.Stanford.EDU Date: Friday, March 10, 2000 9:19 AM Subject: Re: Single Sign-On > > >Vishal, > >The Open Group has published a standard for SSO architecture and API which is >based on Sun's >PAM technology. You can find it at: > > http://www.opengroup.org/online-pubs?DOC=008329799 > >--bob > >Bob Blakley >Chief Scientist >Tivoli SecureWay Business Unit > > >"Vishal Goenka" on 03/07/2000 12:54:22 PM > >To: ietf-cat-wg@lists.Stanford.EDU >cc: (bcc: George Robert Blakley III/Tivoli Systems) >Subject: Single Sign-On > > > > >Does anyone know if there is a working group that has single sign-on (sso) >as its area of interest? I haven't seen much discussion about sso in this WG >so far. If anyone is interested, I have posted an internet-draft on sso >architecture, which I would like to have to relevant WG take a look at. > >The draft is named draft-goenka-single-sign-on-arch-00.txt > >-Vishal > >-++**==--++**==--++**==--++**==--++**==--++**==--++**== >This message was posted through the Stanford campus mailing list >server. If you wish to unsubscribe from this mailing list, send the >message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Mar 13 17:10:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26012 for ; Mon, 13 Mar 2000 17:10:32 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA08627 for ietf-cat-wg-out720680; Mon, 13 Mar 2000 13:30:03 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA08610 for ; Mon, 13 Mar 2000 13:29:59 -0800 (PST) Received: from mail.tohno-pre.co.jp (root@rt-tonopre.echna.ne.jp [210.175.54.61]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA01866 for ; Mon, 13 Mar 2000 16:29:56 -0500 (EST) From: marvin@asheville.com Received: from localhost ([216.24.27.204]) by mail.tohno-pre.co.jp (8.7.6/3.4W4) with SMTP id GAA09756; Tue, 14 Mar 2000 06:29:32 +0900 (JST) Message-Id: <200003132129.GAA09756@mail.tohno-pre.co.jp> Date: Mon, 13 Mar 2000 16:40:03 To: Content-Type: text/html MessageID: <5dilh5lyjc4d73c.130320001640@localhost> Subject: Email Advertising Special -- Ends Tuesday! X-Accept-Language: en Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk E-MAIL-IT SPECIAL(Ends March 14/00) ADVERTISING THAT WORKS FOR YOU Call Ins Receive 25,000 Additional Emails at No Cost! For More information call 919-839-2942 or include your name and number in an email CLICK HERE For removal see link below. We Will Assist You in Developing Your Entire Campaign WE CAN CREATE YOUR AD FOR YOU Whether You Are Looking For Sales, Leads or Exposure OBC OFFERS Targeted or General Mailings With Fresh Addresses Always We GUARANTEE response ! We accept credit cards !SPECIAL Ends March 14, 2000 250,000 $250500,000 $450 1 MILLION $7752 MILLION $1395 Targeted Rates Upon Request For More Information Call: 919-839-2942 or include your name and number in an email and CLICK HERE subject=info for removal utilize link below. Call Ins Receive 25,000 Additional Emails at No Cost! +++++++++++++++++++++++++++++++++++++++++++ For Removal Mailto:leadtrash@mailcity.com?subject=remove -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Mar 14 06:54:47 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03879 for ; Tue, 14 Mar 2000 06:54:46 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09656 for ietf-cat-wg-out720680; Tue, 14 Mar 2000 03:16:45 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09651 for ; Tue, 14 Mar 2000 03:16:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18181; Tue, 14 Mar 2000 06:16:38 -0500 (EST) Message-Id: <200003141116.GAA18181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-gaa-cbind-03.txt Date: Tue, 14 Mar 2000 06:16:37 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Authorization and Access control Application Program Interface C-bindings Author(s) : T. Ryutov, C. Neuman Filename : draft-ietf-cat-gaa-cbind-03.txt Pages : 14 Date : 13-Mar-00 The Generic Authorization and Access control Application Programming Interface (GAA API) provides access control services to calling applications. It facilitates access control decisions for applications and allows applications to discover access control policies associated with a targeted resource. The GAA API is usable by multiple applications supporting different kinds of protected objects. The GAA API design supports: - a variety of security mechanisms based on public or secret key cryptosystems - different authorization models - heterogeneous security policies - various access rights This document specifies C language bindings for the GAA API, which is described at a language-independent conceptual level in draft-ietf-cat-acc-cntrl-frmw-01.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-gaa-cbind-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-gaa-cbind-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-gaa-cbind-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gaa-cbind-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gaa-cbind-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135220.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Mar 14 06:58:04 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04988 for ; Tue, 14 Mar 2000 06:58:03 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09649 for ietf-cat-wg-out720680; Tue, 14 Mar 2000 03:16:41 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09644 for ; Tue, 14 Mar 2000 03:16:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18148; Tue, 14 Mar 2000 06:16:33 -0500 (EST) Message-Id: <200003141116.GAA18148@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-acc-cntrl-frmw-03.txt Date: Tue, 14 Mar 2000 06:16:33 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Access Control Framework for Distributed Applications Author(s) : T. Ryutov, C. Neuman Filename : draft-ietf-cat-acc-cntrl-frmw-03.txt Pages : 14 Date : 13-Mar-00 This document describes a unified model to support authorization in a wide range of applications, including metacomputing, remote printing, video conference, and any other application which will require interactions between entities across autonomous security domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-acc-cntrl-frmw-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-acc-cntrl-frmw-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-acc-cntrl-frmw-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000313135209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-acc-cntrl-frmw-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-acc-cntrl-frmw-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000313135209.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 07:00:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13063 for ; Wed, 15 Mar 2000 07:00:34 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA22150 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 03:21:39 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA22145 for ; Wed, 15 Mar 2000 03:21:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27953; Wed, 15 Mar 2000 06:21:31 -0500 (EST) Message-Id: <200003151121.GAA27953@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-krb-dns-locate-02.txt Date: Wed, 15 Mar 2000 06:21:31 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Distributing Kerberos KDC and Realm Information with DNS Author(s) : K. Hornstein, J. Altman Filename : draft-ietf-cat-krb-dns-locate-02.txt Pages : 6 Date : 14-Mar-00 Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- col [RFC????] describe any mechanism for clients to learn critical configuration information necessary for proper operation of the pro- tocol. Such information includes the location of Kerberos key dis- tribution centers or a mapping between DNS domains and Kerberos realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-krb-dns-locate-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-krb-dns-locate-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-krb-dns-locate-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000314132329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-krb-dns-locate-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-krb-dns-locate-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314132329.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 15:23:25 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11060 for ; Wed, 15 Mar 2000 15:23:20 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA12202 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 11:41:08 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA12196 for ; Wed, 15 Mar 2000 11:41:05 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id OAA17377; Wed, 15 Mar 2000 14:35:57 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: comments on draft-ietf-cat-krb-dns-locate-02.txt References: <200003151121.GAA27953@ietf.org> Mime-Version: 1.0 From: Ken Raeburn Date: 15 Mar 2000 14:35:57 -0500 In-Reply-To: Internet-Drafts@ietf.org's message of "Wed, 15 Mar 2000 06:21:31 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Regarding case sensitivity: The first thing that comes to mind is, "aaahh!!" :-) The second is, would the administrator of foobar.ibm.com really have the ability to create entries under "=i=b=m.=c=o=m." for other sites to see? I don't think so. And, as you say, TXT response data is case-preserving, so it's only in the query that this matters. I still think the right answer is just to assert that this method won't work for sites that bend the guidelines so far as to have two realm names differing only in case and having different servers, and even then, I can think of at least one way to try to work around it. The special case of two realm names differing only by case might make sense if a site is attempting to transition from DCE lower-case mode to "real" krb5, for example. But in that case, it might still be possible for a single server to serve up both realms, though maybe not with the DCE KDC itself. Security issues: The second exploit described is an exploit of the MIT implementation, not the Kerberos design. The Kerberos model itself provides no way of determining the realm of a host. In fact, I don't think it makes any requirement that multiple services running on a single host (even without multiple hostnames etc) use the same local realm. A random thought: You mention both krb4 and krb5 in the abstract, but do we have any way of distinguishing a v4-only vs v5-only vs v4+v5 site without having the info stored locally? Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 16:14:40 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02055 for ; Wed, 15 Mar 2000 16:14:37 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA15877 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 12:46:05 -0800 (PST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA15872 for ; Wed, 15 Mar 2000 12:46:03 -0800 (PST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA04355; Wed, 15 Mar 2000 15:46:01 -0500 (EST) Date: Wed, 15 Mar 2000 15:46:01 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Ken Raeburn Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt In-Reply-To: Your message of 15 Mar 2000 14:35:57 -0500 Message-ID: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > The second is, would the administrator of foobar.ibm.com really have > the ability to create entries under "=i=b=m.=c=o=m." for other sites > to see? I don't think so. And, as you say, TXT response data is > case-preserving, so it's only in the query that this matters. You know. That is a very good point. This is what I get for drinking too much DrPepper in order to counter balance the lack of sleep. Clearly, this won't work, and yes. I now agree with you. Upper case realm names only. Of course, this is going to break the default names that Windows 2000 generates, but .... > Security issues: The second exploit described is an exploit of the MIT > implementation, not the Kerberos design. The Kerberos model itself > provides no way of determining the realm of a host. In fact, I don't > think it makes any requirement that multiple services running on a > single host (even without multiple hostnames etc) use the same local > realm. The problem is that there needs to be a way for the realm of a host to be determined. That is why the DNS TXT record is used; and why MIT placed host/domain to realm mappings into the config files. Of course, the Kerberos model does not provide any description of how this should be done because from the authentication perspective it is not necessary. But because these mappings are necessary and we do not have secure way of performing them, the exploit is an issue for all Kerberos implementations. Of course, if no host to realm mappings provided the exploit goes away. > > A random thought: You mention both krb4 and krb5 in the abstract, but > do we have any way of distinguishing a v4-only vs v5-only vs v4+v5 > site without having the info stored locally? No. There is nothing to distinguish a K4 KDC from a K5 KDC, and from my experience at Columbia there is no need to. We distributed 10,000 clients last Fall to users that supported K4 and K5 when our KDC was K4 only. In December, we switched from K4 to K5 1.1 without the users even noticing. The only thing that changed was that they now got both K4 and K5 tickets when they used Leash32. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 16:56:55 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19261 for ; Wed, 15 Mar 2000 16:56:53 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA18674 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 13:34:23 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA18669 for ; Wed, 15 Mar 2000 13:34:20 -0800 (PST) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.9.3/8.9.3) with ESMTP id QAA06307; Wed, 15 Mar 2000 16:34:15 -0500 (EST) Received: from elvis.cmf.nrl.navy.mil (kenh@localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) with ESMTP id QAA03641; Wed, 15 Mar 2000 16:34:13 -0500 Message-Id: <200003152134.QAA03641@elvis.cmf.nrl.navy.mil> To: Ken Raeburn cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt In-reply-to: Your message of "15 Mar 2000 14:35:57 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` Date: Wed, 15 Mar 2000 16:34:13 -0500 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >The second is, would the administrator of foobar.ibm.com really have >the ability to create entries under "=i=b=m.=c=o=m." for other sites >to see? I don't think so. And, as you say, TXT response data is >case-preserving, so it's only in the query that this matters. Urrrk, good point. >I still think the right answer is just to assert that this method >won't work for sites that bend the guidelines so far as to have two >realm names differing only in case and having different servers, and >even then, I can think of at least one way to try to work around it. >The special case of two realm names differing only by case might make >sense if a site is attempting to transition from DCE lower-case mode >to "real" krb5, for example. But in that case, it might still be >possible for a single server to serve up both realms, though maybe not >with the DCE KDC itself. I think Jeff covered that one; I think that we _can_ do either uppercase, lowercase, or some mixed case if you really want it; the limitation is that there is room for only _one_ realm in any case within the DNS. >Security issues: The second exploit described is an exploit of the MIT >implementation, not the Kerberos design. The Kerberos model itself >provides no way of determining the realm of a host. In fact, I don't >think it makes any requirement that multiple services running on a >single host (even without multiple hostnames etc) use the same local >realm. I'm sure we all recall the big flamewar on this, but I can only say that perhaps it is an "unspecified" area of the specification. You certainly have to do something. >A random thought: You mention both krb4 and krb5 in the abstract, but >do we have any way of distinguishing a v4-only vs v5-only vs v4+v5 >site without having the info stored locally? No ... and I know we had the big meta-discussion about the amount of V4 out there versus V5-only sites. I would agree with Jeff: "Not necessary" (besides, are people going to do that much reengineering on V4 clients to make them support this stuff?). --Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 18:52:08 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01396 for ; Wed, 15 Mar 2000 18:52:04 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA23101 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 15:14:12 -0800 (PST) Received: from zot.isi.edu (IDENT:root@zot.isi.edu [128.9.128.118]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA23096 for ; Wed, 15 Mar 2000 15:14:09 -0800 (PST) Received: (from brian@localhost) by zot.isi.edu (8.9.3/8.9.3) id PAA13694 for ietf-cat-wg@lists.stanford.edu; Wed, 15 Mar 2000 15:13:48 -0800 Date: Wed, 15 Mar 2000 15:13:48 -0800 From: Brian Tung Message-Id: <200003152313.PAA13694@zot.isi.edu> To: ietf-cat-wg@lists.Stanford.EDU Subject: draft-ietf-cat-kerberos-pk-init-11.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the draft, almost precisely as it went out to ietf.org last Friday at about 12:30 PST. The one change is to correct Sasha Medvinsky's phone number at the end of the draft. We would like to push for working group last call. The active parties have reached consensus. b ***** INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-init-11.txt Clifford Neuman Updates: RFC 1510 USC/ISI expires September 15, 2000 Matthew Hur CyberSafe Corporation Ari Medvinsky Keen.com, Inc. Sasha Medvinsky Motorola John Wray Iris Associates, Inc. Jonathan Trostle Cisco Public Key Cryptography for Initial Authentication in Kerberos 0. Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15, 2000. Please send comments to the authors. 1. Abstract This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. 2. Introduction The popularity of public key cryptography has produced a desire for its support in Kerberos [2]. The advantages provided by public key cryptography include simplified key management (from the Kerberos perspective) and the ability to leverage existing and developing public key certification infrastructures. Public key cryptography can be integrated into Kerberos in a number of ways. One is to associate a key pair with each realm, which can then be used to facilitate cross-realm authentication; this is the topic of another draft proposal. Another way is to allow users with public key certificates to use them in initial authentication. This is the concern of the current document. PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in combination with digital signature keys as the primary, required mechanism. It also allows for the use of RSA keys and/or (static) Diffie-Hellman certificates. Note in particular that PKINIT supports the use of separate signature and encryption keys. PKINIT enables access to Kerberos-secured services based on initial authentication utilizing public key cryptography. PKINIT utilizes standard public key signature and encryption data formats within the standard Kerberos messages. The basic mechanism is as follows: The user sends an AS-REQ message to the KDC as before, except that if that user is to use public key cryptography in the initial authentication step, his certificate and a signature accompany the initial request in the preauthentication fields. Upon receipt of this request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as before, except that the encPart from the AS-REP message carrying the TGT is now encrypted utilizing either a Diffie-Hellman derived key or the user's public key. This message is authenticated utilizing the public key signature of the KDC. Note that PKINIT does not require the use of certificates. A KDC may store the public key of a principal as part of that principal's record. In this scenario, the KDC is the trusted party that vouches for the principal (as in a standard, non-cross realm, Kerberos environment). Thus, for any principal, the KDC may maintain a secret key, a public key, or both. The PKINIT specification may also be used as a building block for other specifications. PKCROSS [3] utilizes PKINIT for establishing the inter-realm key and associated inter-realm policy to be applied in issuing cross realm service tickets. As specified in [4], anonymous Kerberos tickets can be issued by applying a NULL signature in combination with Diffie-Hellman in the PKINIT exchange. Additionally, the PKINIT specification may be used for direct peer to peer authentication without contacting a central KDC. This application of PKINIT is described in PKTAPP [5] and is based on concepts introduced in [6, 7]. For direct client-to-server authentication, the client uses PKINIT to authenticate to the end server (instead of a central KDC), which then issues a ticket for itself. This approach has an advantage over TLS [8] in that the server does not need to save state (cache session keys). Furthermore, an additional benefit is that Kerberos tickets can facilitate delegation (see [9]). 3. Proposed Extensions This section describes extensions to RFC 1510 for supporting the use of public key cryptography in the initial request for a ticket granting ticket (TGT). In summary, the following change to RFC 1510 is proposed: * Users may authenticate using either a public key pair or a conventional (symmetric) key. If public key cryptography is used, public key data is transported in preauthentication data fields to help establish identity. The user presents a public key certificate and obtains an ordinary TGT that may be used for subsequent authentication, with such authentication using only conventional cryptography. Section 3.1 provides definitions to help specify message formats. Section 3.2 describes the extensions for the initial authentication method. 3.1. Definitions The extensions involve new preauthentication fields; we introduce the following preauthentication types: PA-PK-AS-REQ 14 PA-PK-AS-REP 15 The extensions also involve new error types; we introduce the following types: KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_KDC_NOT_TRUSTED 63 KDC_ERR_INVALID_SIG 64 KDC_ERR_KEY_TOO_WEAK 65 KDC_ERR_CERTIFICATE_MISMATCH 66 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 KDC_ERR_INVALID_CERTIFICATE 71 KDC_ERR_REVOKED_CERTIFICATE 72 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 KDC_ERR_CLIENT_NAME_MISMATCH 75 KDC_ERR_KDC_NAME_MISMATCH 76 We utilize the following typed data for errors: TD-PKINIT-CMS-CERTIFICATES 101 TD-KRB-PRINCIPAL 102 TD-KRB-REALM 103 TD-TRUSTED-CERTIFIERS 104 TD-CERTIFICATE-INDEX 105 We utilize the following encryption types (which map directly to OIDs): dsaWithSHA1-CmsOID 9 md5WithRSAEncryption-CmsOID 10 sha1WithRSAEncryption-CmsOID 11 rc2CBC-EnvOID 12 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 des-ede3-cbc-Env-OID 15 These mappings are provided so that a client may send the appropriate enctypes in the AS-REQ message in order to indicate support for the corresponding OIDs (for performing PKINIT). In many cases, PKINIT requires the encoding of the X.500 name of a certificate authority as a Realm. When such a name appears as a realm it will be represented using the "other" form of the realm name as specified in the naming constraints section of RFC1510. For a realm derived from an X.500 name, NAMETYPE will have the value X500-RFC2253. The full realm name will appear as follows: + ":" + where nametype is "X500-RFC2253" and string is the result of doing an RFC2253 encoding of the distinguished name, i.e. "X500-RFC2253:" + RFC2253Encode(DistinguishedName) where DistinguishedName is an X.500 name, and RFC2253Encode is a function returing a readable UTF encoding of an X.500 name, as defined by RFC 2253 [14] (part of LDAPv3 [18]). To ensure that this encoding is unique, we add the following rule to those specified by RFC 2253: The order in which the attributes appear in the RFC 2253 encoding must be the reverse of the order in the ASN.1 encoding of the X.500 name that appears in the public key certificate. The order of the relative distinguished names (RDNs), as well as the order of the AttributeTypeAndValues within each RDN, will be reversed. (This is despite the fact that an RDN is defined as a SET of AttributeTypeAndValues, where an order is normally not important.) Similarly, in cases where the KDC does not provide a specific policy based mapping from the X.500 name or X.509 Version 3 SubjectAltName extension in the user's certificate to a Kerberos principal name, PKINIT requires the direct encoding of the X.500 name as a PrincipalName. In this case, the name-type of the principal name shall be set to KRB_NT-X500-PRINCIPAL. This new name type is defined in RFC 1510 as: KRB_NT_X500_PRINCIPAL 6 The name-string shall be set as follows: RFC2253Encode(DistinguishedName) as described above. When this name type is used, the principal's realm shall be set to the certificate authority's distinguished name using the X500-RFC2253 realm name format described earlier in this section RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString } For the purposes of encoding an X.500 name as a Kerberos name for use in Kerberos structures, the name-string shall be encoded as a single GeneralString. The name-type should be KRB_NT_X500_PRINCIPAL, as noted above. All Kerberos names must conform to validity requirements as given in RFC 1510. Note that name mapping may be required or optional, based on policy. We also define the following similar ASN.1 structure: CertPrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF UTF8String } When a Kerberos PrincipalName is to be placed within an X.509 data structure, the CertPrincipalName structure is to be used, with the name-string encoded as a single UTF8String. The name-type should be as identified in the original PrincipalName structure. The mapping between the GeneralString and UTF8String formats can be found in [19]. The following rules relate to the the matching of PrincipalNames (or corresponding CertPrincipalNames) with regard to the PKI name constraints for CAs as laid out in RFC 2459 [15]. In order to be regarded as a match (for permitted and excluded name trees), the following must be satisfied. 1. If the constraint is given as a user plus realm name, or as a user plus instance plus realm name (as specified in RFC 1510), the realm name must be valid (see 2.a-d below) and the match must be exact, byte for byte. 2. If the constraint is given only as a realm name, matching depends on the type of the realm: a. If the realm contains a colon (':') before any equal sign ('='), it is treated as a realm of type Other, and must match exactly, byte for byte. b. Otherwise, if the realm contains an equal sign, it is treated as an X.500 name. In order to match, every component in the constraint MUST be in the principal name, and have the same value. For example, 'C=US' matches 'C=US/O=ISI' but not 'C=UK'. c. Otherwise, if the realm name conforms to rules regarding the format of DNS names, it is considered a realm name of type Domain. The constraint may be given as a realm name 'FOO.BAR', which matches any PrincipalName within the realm 'FOO.BAR' but not those in subrealms such as 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' matches PrincipalNames in subrealms of the form 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. d. Otherwise, the realm name is invalid and does not match under any conditions. 3.1.1. Encryption and Key Formats In the exposition below, we use the terms public key and private key generically. It should be understood that the term "public key" may be used to refer to either a public encryption key or a signature verification key, and that the term "private key" may be used to refer to either a private decryption key or a signature generation key. The fact that these are logically distinct does not preclude the assignment of bitwise identical keys for RSA keys. In the case of Diffie-Hellman, the key shall be produced from the agreed bit string as follows: * Truncate the bit string to the appropriate length. * Rectify parity in each byte (if necessary) to obtain the key. For instance, in the case of a DES key, we take the first eight bytes of the bit stream, and then adjust the least significant bit of each byte to ensure that each byte has odd parity. 3.1.2. Algorithm Identifiers PKINIT does not define, but does permit, the algorithm identifiers listed below. 3.1.2.1. Signature Algorithm Identifiers The following signature algorithm identifiers specified in [11] and in [15] shall be used with PKINIT: id-dsa-with-sha1 (DSA with SHA1) md5WithRSAEncryption (RSA with MD5) sha-1WithRSAEncryption (RSA with SHA1) 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier The following algorithm identifier shall be used within the SubjectPublicKeyInfo data structure: dhpublicnumber This identifier and the associated algorithm parameters are specified in RFC 2459 [15]. 3.1.2.3. Algorithm Identifiers for RSA Encryption These algorithm identifiers are used inside the EnvelopedData data structure, for encrypting the temporary key with a public key: rsaEncryption (RSA encryption, PKCS#1 v1.5) id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) Both of the above RSA encryption schemes are specified in [16]. Currently, only PKCS#1 v1.5 is specified by CMS [11], although the CMS specification says that it will likely include PKCS#1 v2.0 in the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext vulnerability discovered in PKCS#1 v1.5.) 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys These algorithm identifiers are used inside the EnvelopedData data structure in the PKINIT Reply, for encrypting the reply key with the temporary key: des-ede3-cbc (3-key 3-DES, CBC mode) rc2-cbc (RC2, CBC mode) The full definition of the above algorithm identifiers and their corresponding parameters (an IV for block chaining) is provided in the CMS specification [11]. 3.2. Public Key Authentication Implementation of the changes in this section is REQUIRED for compliance with PKINIT. 3.2.1. Client Request Public keys may be signed by some certification authority (CA), or they may be maintained by the KDC in which case the KDC is the trusted authority. Note that the latter mode does not require the use of certificates. The initial authentication request is sent as per RFC 1510, except that a preauthentication field containing data signed by the user's private key accompanies the request: PA-PK-AS-REQ ::= SEQUENCE { -- PA TYPE 14 signedAuthPack [0] SignedData -- Defined in CMS [11]; -- AuthPack (below) defines the -- data that is signed. trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, -- This is a list of CAs that the -- client trusts and that certify -- KDCs. kdcCert [2] IssuerAndSerialNumber OPTIONAL -- As defined in CMS [11]; -- specifies a particular KDC -- certificate if the client -- already has it. encryptionCert [3] IssuerAndSerialNumber OPTIONAL -- For example, this may be the -- client's Diffie-Hellman -- certificate, or it may be the -- client's RSA encryption -- certificate. } TrustedCas ::= CHOICE { principalName [0] KerberosName, -- as defined below caName [1] Name -- fully qualified X.500 name -- as defined by X.509 issuerAndSerial [2] IssuerAndSerialNumber -- Since a CA may have a number of -- certificates, only one of which -- a client trusts } Usage of SignedData: The SignedData data type is specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. The following describes how to fill in the fields of this data: 1. The encapContentInfo field must contain the PKAuthenticator and, optionally, the client's Diffie Hellman public value. a. The eContentType field shall contain the OID value for pkdata: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkdata (1) b. The eContent field is data of the type AuthPack (below). 2. The signerInfos field contains the signature of AuthPack. 3. The Certificates field, when non-empty, contains the client's certificate chain. If present, the KDC uses the public key from the client's certificate to verify the signature in the request. Note that the client may pass different certificate chains that are used for signing or for encrypting. Thus, the KDC may utilize a different client certificate for signature verification than the one it uses to encrypt the reply to the client. For example, the client may place a Diffie-Hellman certificate in this field in order to convey its static Diffie Hellman certificate to the KDC to enable static-ephemeral Diffie-Hellman mode for the reply; in this case, the client does NOT place its public value in the AuthPack (defined below). As another example, the client may place an RSA encryption certificate in this field. However, there must always be (at least) a signature certificate. AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL -- if client is using Diffie-Hellman -- (ephemeral-ephemeral only) } PKAuthenticator ::= SEQUENCE { kdcName [0] PrincipalName, kdcRealm [1] Realm, cusec [2] INTEGER, -- for replay prevention as in RFC1510 ctime [3] KerberosTime, -- for replay prevention as in RFC1510 nonce [4] INTEGER } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, -- dhKeyAgreement subjectPublicKey BIT STRING -- for DH, equals -- public exponent (INTEGER encoded -- as payload of BIT STRING) } -- as specified by the X.509 recommendation [10] AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id, parameters ALGORITHM.&type } -- as specified by the X.509 recommendation [10] If the client passes an issuer and serial number in the request, the KDC is requested to use the referred-to certificate. If none exists, then the KDC returns an error of type KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the other hand, the client does not pass any trustedCertifiers, believing that it has the KDC's certificate, but the KDC has more than one certificate. The KDC should include information in the KRB-ERROR message that indicates the KDC certificate(s) that a client may utilize. This data is specified in the e-data, which is defined in RFC 1510 revisions as a SEQUENCE of TypedData: TypedData ::= SEQUENCE { data-type [0] INTEGER, data-value [1] OCTET STRING, } -- per Kerberos RFC 1510 revisions where: data-type = TD-PKINIT-CMS-CERTIFICATES = 101 data-value = CertificateSet // as specified by CMS [11] The PKAuthenticator carries information to foil replay attacks, and to bind the request and response. The PKAuthenticator is signed with the client's signature key. 3.2.2. KDC Response Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication type, the KDC attempts to verify the user's certificate chain (userCert), if one is provided in the request. This is done by verifying the certification path against the KDC's policy of legitimate certifiers. This may be based on a certification hierarchy, or it may be simply a list of recognized certifiers in a system like PGP. If the client's certificate chain contains no certificate signed by a CA trusted by the KDC, then the KDC sends back an error message of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) whose data-value is an OCTET STRING which is the DER encoding of TrustedCertifiers ::= SEQUENCE OF PrincipalName -- X.500 name encoded as a principal name -- see Section 3.1 If while verifying a certificate chain the KDC determines that the signature on one of the certificates in the CertificateSet from the signedAuthPack fails verification, then the KDC returns an error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING which is the DER encoding of the index into the CertificateSet ordered as sent by the client. CertificateIndex ::= INTEGER -- 0 = 1st certificate, -- (in order of encoding) -- 1 = 2nd certificate, etc The KDC may also check whether any of the certificates in the client's chain has been revoked. If one of the certificates has been revoked, then the KDC returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the certificate's revocation status is unknown or not available, then if required by policy, the KDC returns the appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three cases, the affected certificate is identified by the accompanying e-data, which contains a CertificateIndex as described for KDC_ERR_INVALID_CERTIFICATE. If the certificate chain can be verified, but the name of the client in the certificate does not match the client's name in the request, then the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data field in this case. Finally, if the certificate chain is verified, but the KDC's name or realm as given in the PKAuthenticator does not match the KDC's actual principal name, then the KDC returns an error of type KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET STRING whose data-value is the DER encoding of a PrincipalName or Realm as defined in RFC 1510 revisions. Even if all succeeds, the KDC may--for policy reasons--decide not to trust the client. In this case, the KDC returns an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is the presence or absence of an Enhanced Key Usage (EKU) OID within the certificate extensions. The rules regarding acceptability of an EKU sequence (or the absence of any sequence) are a matter of local policy. For the benefit of implementers, we define a PKINIT EKU OID as the following: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). If a trust relationship exists, the KDC then verifies the client's signature on AuthPack. If that fails, the KDC returns an error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the timestamp (ctime and cusec) in the PKAuthenticator to assure that the request is not a replay. The KDC also verifies that its name is specified in the PKAuthenticator. If the clientPublicValue field is filled in, indicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to see that the parameters satisfy its policy. If they do not (e.g., the prime size is insufficient for the expected encryption type), then the KDC sends back an error message of type KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and private values for the response. The KDC also checks that the timestamp in the PKAuthenticator is within the allowable window and that the principal name and realm are correct. If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew, then the KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. Assuming no errors, the KDC replies as per RFC 1510, except as follows. The user's name in the ticket is determined by the following decision algorithm: 1. If the KDC has a mapping from the name in the certificate to a Kerberos name, then use that name. Else 2. If the certificate contains the SubjectAltName extention and the local KDC policy defines a mapping from the SubjectAltName to a Kerberos name, then use that name. Else 3. Use the name as represented in the certificate, mapping mapping as necessary (e.g., as per RFC 2253 for X.500 names). In this case the realm in the ticket shall be the name of the certifier that issued the user's certificate. Note that a principal name may be carried in the subject alt name field of a certificate. This name may be mapped to a principal record in a security database based on local policy, for example the subject alt name may be kerberos/principal@realm format. In this case the realm name is not that of the CA but that of the local realm doing the mapping (or some realm name chosen by that realm). If a non-KDC X.509 certificate contains the principal name within the subjectAltName version 3 extension , that name may utilize KerberosName as defined below, or, in the case of an S/MIME certificate [17], may utilize the email address. If the KDC is presented with an S/MIME certificate, then the email address within subjectAltName will be interpreted as a principal and realm separated by the "@" sign, or as a name that needs to be canonicalized. If the resulting name does not correspond to a registered principal name, then the principal name is formed as defined in section 3.1. The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client does not possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. KDCs should try to (in order of preference): 1. Use the KDC certificate identified by the serialNumber included in the client's request. 2. Use a certificate issued to the KDC by the client's CA (if in the middle of a CA key roll-over, use the KDC cert issued under same CA key as user cert used to verify request). 3. Use a certificate issued to the KDC by one of the client's trustedCertifier(s); If the KDC is unable to comply with any of these options, then the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the client. The KDC encrypts the reply not with the user's long-term key, but with the Diffie Hellman derived key or a random key generated for this particular response which is carried in the padata field of the TGS-REP message. PA-PK-AS-REP ::= CHOICE { -- PA TYPE 15 dhSignedData [0] SignedData, -- Defined in CMS and used only with -- Diffie-Hellman key exchange (if the -- client public value was present in the -- request). -- This choice MUST be supported -- by compliant implementations. encKeyPack [1] EnvelopedData, -- Defined in CMS -- The temporary key is encrypted -- using the client public key -- key -- SignedReplyKeyPack, encrypted -- with the temporary key, is also -- included. } Usage of SignedData: When the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP provides authenticated Diffie-Hellman parameters of the KDC. The reply key used to encrypt part of the KDC reply message is derived from the Diffie-Hellman exchange: 1. Both the KDC and the client calculate a secret value (g^ab mod p), where a is the client's private exponent and b is the KDC's private exponent. 2. Both the KDC and the client take the first N bits of this secret value and convert it into a reply key. N depends on the reply key type. 3. If the reply key is DES, N=64 bits, where some of the bits are replaced with parity bits, according to FIPS PUB 74. 4. If the reply key is (3-key) 3-DES, N=192 bits, where some of the bits are replaced with parity bits, according to FIPS PUB 74. 5. The encapContentInfo field must contain the KdcDHKeyInfo as defined below. a. The eContentType field shall contain the OID value for pkdata: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkdata (1) b. The eContent field is data of the type KdcDHKeyInfo (below). 6. The certificates field must contain the certificates necessary for the client to establish trust in the KDC's certificate based on the list of trusted certifiers sent by the client in the PA-PK-AS-REQ. This field may be empty if the client did not send to the KDC a list of trusted certifiers (the trustedCertifiers field was empty, meaning that the client already possesses the KDC's certificate). 7. The signerInfos field is a SET that must contain at least one member, since it contains the actual signature. KdcDHKeyInfo ::= SEQUENCE { -- used only when utilizing Diffie-Hellman nonce [0] INTEGER, -- binds responce to the request subjectPublicKey [2] BIT STRING -- Equals public exponent (g^a mod p) -- INTEGER encoded as payload of -- BIT STRING } Usage of EnvelopedData: The EnvelopedData data type is specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. It contains a temporary key encrypted with the PKINIT client's public key. It also contains a signed and encrypted reply key. 1. The originatorInfo field is not required, since that information may be presented in the signedData structure that is encrypted within the encryptedContentInfo field. 2. The optional unprotectedAttrs field is not required for PKINIT. 3. The recipientInfos field is a SET which must contain exactly one member of the KeyTransRecipientInfo type for encryption with an RSA public key. a. The encryptedKey field (in KeyTransRecipientInfo) contains the temporary key which is encrypted with the PKINIT client's public key. 4. The encryptedContentInfo field contains the signed and encrypted reply key. a. The contentType field shall contain the OID value for id-signedData: iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) b. The encryptedContent field is encrypted data of the CMS type signedData as specified below. i. The encapContentInfo field must contains the ReplyKeyPack. * The eContentType field shall contain the OID value for pkdata: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkdata (1) * The eContent field is data of the type ReplyKeyPack (below). ii. The certificates field must contain the certificates necessary for the client to establish trust in the KDC's certificate based on the list of trusted certifiers sent by the client in the PA-PK-AS-REQ. This field may be empty if the client did not send to the KDC a list of trusted certifiers (the trustedCertifiers field was empty, meaning that the client already possesses the KDC's certificate). iii. The signerInfos field is a SET that must contain at least one member, since it contains the actual signature. ReplyKeyPack ::= SEQUENCE { -- not used for Diffie-Hellman replyKey [0] EncryptionKey, -- used to encrypt main reply -- ENCTYPE is at least as strong as -- ENCTYPE of session key nonce [1] INTEGER, -- binds response to the request -- must be same as the nonce -- passed in the PKAuthenticator } Since each certifier in the certification path of a user's certificate is equivalent to a separate Kerberos realm, the name of each certifier in the certificate chain must be added to the transited field of the ticket. The format of these realm names is defined in Section 3.1 of this document. If applicable, the transit-policy-checked flag should be set in the issued ticket. The KDC's certificate(s) must bind the public key(s) of the KDC to a name derivable from the name of the realm for that KDC. X.509 certificates shall contain the principal name of the KDC (defined in section 8.2 of RFC 1510) as the SubjectAltName version 3 extension. Below is the definition of this version 3 extension, as specified by the X.509 standard: subjectAltName EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName } GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] OtherName, ... } OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id } For the purpose of specifying a Kerberos principal name, the value in OtherName shall be a KerberosName as defined in RFC 1510, but with the PrincipalName replaced by CertPrincipalName as mentioned in Section 3.1: KerberosName ::= SEQUENCE { realm [0] Realm, principalName [1] CertPrincipalName -- defined above } This specific syntax is identified within subjectAltName by setting the type-id in OtherName to krb5PrincipalName, where (from the Kerberos specification) we have krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) } krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } (This specification may also be used to specify a Kerberos name within the user's certificate.) The KDC's certificate may be signed directly by a CA, or there may be intermediaries if the server resides within a large organization, or it may be unsigned if the client indicates possession (and trust) of the KDC's certificate. The client then extracts the random key used to encrypt the main reply. This random key (in encPaReply) is encrypted with either the client's public key or with a key derived from the DH values exchanged between the client and the KDC. The client uses this random key to decrypt the main reply, and subsequently proceeds as described in RFC 1510. 3.2.3. Required Algorithms Not all of the algorithms in the PKINIT protocol specification have to be implemented in order to comply with the proposed standard. Below is a list of the required algorithms: * Diffie-Hellman public/private key pairs * utilizing Diffie-Hellman ephemeral-ephemeral mode * SHA1 digest and DSA for signatures * 3-key triple DES keys derived from the Diffie-Hellman Exchange * 3-key triple DES Temporary and Reply keys 4. Logistics and Policy This section describes a way to define the policy on the use of PKINIT for each principal and request. The KDC is not required to contain a database record for users who use public key authentication. However, if these users are registered with the KDC, it is recommended that the database record for these users be modified to an additional flag in the attributes field to indicate that the user should authenticate using PKINIT. If this flag is set and a request message does not contain the PKINIT preauthentication field, then the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of type PA-PK-AS-REQ must be included in the request. 5. Security Considerations PKINIT raises a few security considerations, which we will address in this section. First of all, PKINIT introduces a new trust model, where KDCs do not (necessarily) certify the identity of those for whom they issue tickets. PKINIT does allow KDCs to act as their own CAs, in the limited capacity of self-signing their certificates, but one of the additional benefits is to align Kerberos authentication with a global public key infrastructure. Anyone using PKINIT in this way must be aware of how the certification infrastructure they are linking to works. Secondly, PKINIT also introduces the possibility of interactions between different cryptosystems, which may be of widely varying strengths. Many systems, for instance, allow the use of 512-bit public keys. Using such keys to wrap data encrypted under strong conventional cryptosystems, such as triple-DES, is inappropriate; it adds a weak link to a strong one at extra cost. Implementors and administrators should take care to avoid such wasteful and deceptive interactions. Lastly, PKINIT calls for randomly generated keys for conventional cryptosystems. Many such systems contain systematically "weak" keys. PKINIT implementations MUST avoid use of these keys, either by discarding those keys when they are generated, or by fixing them in some way (e.g., by XORing them with a given mask). These precautions vary from system to system; it is not our intention to give an explicit recipe for them here. 6. Transport Issues Certificate chains can potentially grow quite large and span several UDP packets; this in turn increases the probability that a Kerberos message involving PKINIT extensions will be broken in transit. In light of the possibility that the Kerberos specification will require KDCs to accept requests using TCP as a transport mechanism, we make the same recommendation with respect to the PKINIT extensions as well. 7. Bibliography [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments 1510. [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9):33-38. September 1994. [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman. Public Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-cat-pktapp-02.txt [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed System Security, 1997. [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, July 1995. [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 Request for Comments 2246, January 1999. [9] B.C. Neuman, Proxy-Based Authorization and Accounting for Distributed Systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, May 1993. [10] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8 [11] R. Housley. Cryptographic Message Syntax. draft-ietf-smime-cms-13.txt, April 1999, approved for publication as RFC. [12] PKCS #7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note Version 1.5 Revised November 1, 1993 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data Security, Inc. A Description of the RC2(r) Encryption Algorithm March 1998. Request for Comments 2268. [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. Request for Comments 2253. [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, January 1999. Request for Comments 2459. [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography Specifications, October 1998. Request for Comments 2437. [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME Version 2 Certificate Handling, March 1998. Request for Comments 2312. [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access Protocol (v3), December 1997. Request for Comments 2251. [19] ITU-T (formerly CCITT) Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) Rec. X.680 ISO/IEC 8824-1 8. Acknowledgements Some of the ideas on which this proposal is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos and SPX. Some ideas have also been drawn from the DASS system. These changes are by no means endorsed by these groups. This is an attempt to revive some of the goals of those groups, and this proposal approaches those goals primarily from the Kerberos perspective. Lastly, comments from groups working on similar ideas in DCE have been invaluable. 9. Expiration Date This draft expires September 15, 2000. 10. Authors Brian Tung Clifford Neuman USC Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: {brian, bcn}@isi.edu Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Issaquah WA 98027-5378 Phone: +1 425 391 6000 E-mail: matt.hur@cybersafe.com Ari Medvinsky Keen.com, Inc. 150 Independence Drive Menlo Park CA 94025 Phone: +1 650 289 3134 E-mail: ari@keen.com Sasha Medvinsky Motorola 6450 Sequence Drive San Diego, CA 92121 +1 858 404 2367 [this is correct--changed from the submitted version] E-mail: smedvinsky@gi.com John Wray Iris Associates, Inc. 5 Technology Park Dr. Westford, MA 01886 E-mail: John_Wray@iris.com Jonathan Trostle 170 W. Tasman Dr. San Jose, CA 95134 E-mail: jtrostle@cisco.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBONAZLPxWUiHQcCAeEQIOiACg+xhrncJNUe3GJfAg2NNDCH3Csc4AoIWs VaJLBMubduDM+eAxnjgjzyB8 =w2eP -----END PGP SIGNATURE----- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 19:43:54 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21358 for ; Wed, 15 Mar 2000 19:43:54 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA28650 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 16:19:16 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA28639 for ; Wed, 15 Mar 2000 16:19:13 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id TAA17518; Wed, 15 Mar 2000 19:19:06 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt References: <200003152134.QAA03641@elvis.cmf.nrl.navy.mil> Mime-Version: 1.0 From: Ken Raeburn Date: 15 Mar 2000 19:19:06 -0500 In-Reply-To: Ken Hornstein's message of "Wed, 15 Mar 2000 16:34:13 -0500" Message-ID: Lines: 89 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Hornstein writes: > I think Jeff covered that one; I think that we _can_ do either uppercase, > lowercase, or some mixed case if you really want it; the limitation is > that there is room for only _one_ realm in any case within the DNS. Room for one domain name entry, you mean. What if I start with: myrealm.foobar.com = { kdc = dce-1.foobar.com:88 kdc = dce-2.foobar.com:88 } MYREALM.FOOBAR.COM = { kdc = kerberos-1.foobar.com:88 } and produce $ORIGIN foobar.com. _kerberos._udp.myrealm IN SRV 0 0 88 dce-1 IN SRV 0 0 88 dce-2 IN SRV 0 0 88 kerberos-1 and configure the servers to each handle the "other" realm by throwing away the packet, so that the client will time out and try another server? That last part may be difficult, if the KDC comes without sources. But if I can make that happen, it's a workable solution during a transition period, even if response may be a bit slow on average. Yeah, it's bending the rules a little, but once kerberos-revisions becomes the new spec, the non-upper-case realm will already be in outright violation of other rules, so bending the rules a little more, and largely transparently (except that it looks like a server is down), to make SRV actually work correctly in that bizarre case doesn't really bother me... Really, the only situations I can see for two separately-served realms of the same name are: (a) v4->v5 transitions (b) transitioning to upper-case realm name for compliance, a special case of renaming a realm, which we ought to have a way of addressing (elsewhere!) anyways (c) one organization running two realms because, for example, some of their clients need special authorization data provided by a KDC, and they're unwilling to be locked into a proprietary solution for the rest of their environment, *and* they couldn't be bothered to set up a non-confusing naming scheme for the two realms; just slap 'em upside the head and make 'em rename one of the realms... > I'm sure we all recall the big flamewar on this, but I can only say > that perhaps it is an "unspecified" area of the specification. You > certainly have to do something. Yes, it was just nitpicking: The server name canonicalization handling is not so much a bug in the way the "Kerberos model" works, as something outside its scope. (Though perhaps I choose to define that term more narrowly than some do.) For example, if you do secure lookups in your Active Directory for the canonical hostname and reject anything not listed, that's not at all at odds with the Kerberos model, and it's probably reasonably secure. It's "merely" opposite much of the past experience of UNIX and DNS users (in general, and of Kerberos), except for those that remember the bad old days of host tables. > No ... and I know we had the big meta-discussion about the amount of > V4 out there versus V5-only sites. I would agree with Jeff: "Not > necessary" (besides, are people going to do that much reengineering on > V4 clients to make them support this stuff?). It wouldn't be V4 applications, but library implementations like MIT's, that want to -- or need to -- support v4 compatibility, which would automatically update applications that shared libraries or get re-linked. *IF* we (library maintainers) want to make the no-config-file situation work, we may need to address this...or at least decide what our defaults are going to be regarding v4. If krb-dns-locate isn't intended to address this, the reference to v4 should probably be dropped from the abstract. Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 20:25:28 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06721 for ; Wed, 15 Mar 2000 20:25:27 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA02628 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 16:57:48 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA02623 for ; Wed, 15 Mar 2000 16:57:46 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 Mar 2000 16:48:08 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 16:48:07 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690716F70B@SIT.platinum.corp.microsoft.com> From: John Brezak To: "'jaltman@columbia.edu'" , Ken Raeburn Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: comments on draft-ietf-cat-krb-dns-locate-02.txt Date: Wed, 15 Mar 2000 16:48:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk All Kerberos realm names for Windows 2000 domains are uppercase because they are DNS names. > -----Original Message----- > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > Sent: Wednesday, March 15, 2000 12:46 PM > To: Ken Raeburn > Cc: ietf-cat-wg@lists.Stanford.EDU > Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt > > > > > The second is, would the administrator of foobar.ibm.com really have > > the ability to create entries under "=i=b=m.=c=o=m." for other sites > > to see? I don't think so. And, as you say, TXT response data is > > case-preserving, so it's only in the query that this matters. > > You know. That is a very good point. This is what I get for drinking > too much DrPepper in order to counter balance the lack of sleep. > > Clearly, this won't work, and yes. I now agree with you. Upper case > realm names only. Of course, this is going to break the default names > that Windows 2000 generates, but .... > > > > Security issues: The second exploit described is an exploit > of the MIT > > implementation, not the Kerberos design. The Kerberos model itself > > provides no way of determining the realm of a host. In > fact, I don't > > think it makes any requirement that multiple services running on a > > single host (even without multiple hostnames etc) use the same local > > realm. > > The problem is that there needs to be a way for the realm of a host to > be determined. That is why the DNS TXT record is used; and why MIT > placed host/domain to realm mappings into the config files. Of > course, the Kerberos model does not provide any description of how > this should be done because from the authentication perspective it is > not necessary. But because these mappings are necessary and we do not > have secure way of performing them, the exploit is an issue for all > Kerberos implementations. Of course, if no host to realm mappings > provided the exploit goes away. > > > > > A random thought: You mention both krb4 and krb5 in the > abstract, but > > do we have any way of distinguishing a v4-only vs v5-only vs v4+v5 > > site without having the info stored locally? > > No. There is nothing to distinguish a K4 KDC from a K5 KDC, and from > my experience at Columbia there is no need to. We distributed 10,000 > clients last Fall to users that supported K4 and K5 when our KDC was > K4 only. In December, we switched from K4 to K5 1.1 without the users > even noticing. The only thing that changed was that they now got both > K4 and K5 tickets when they used Leash32. > > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for > Win32 and OS/2 > The Kermit Project * Columbia University > 612 West 115th St #716 * New York, NY * 10025 > http://www.kermit-project.org/k95.html * > kermit-support@kermit-project.org > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 20:25:33 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06764 for ; Wed, 15 Mar 2000 20:25:32 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA02759 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 17:00:34 -0800 (PST) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA02752 for ; Wed, 15 Mar 2000 17:00:31 -0800 (PST) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id UAA05669; Wed, 15 Mar 2000 20:00:28 -0500 (EST) Date: Wed, 15 Mar 2000 20:00:28 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: John Brezak Cc: Ken Raeburn , ietf-cat-wg@lists.Stanford.EDU Subject: RE: comments on draft-ietf-cat-krb-dns-locate-02.txt In-Reply-To: Your message of Wed, 15 Mar 2000 16:48:06 -0800 Message-ID: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > All Kerberos realm names for Windows 2000 domains are uppercase because they > are DNS names. I'm not sure I understand this. How does a name being a DNS name result in it being an upper case realm name? I made my comment based on the fact that when I installed Win2000 it defaulted to a realm name with only upper cased first characters of each segment. But perhaps that was just the user presentation and you always uppercase behind the scenes. > > -----Original Message----- > > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > > Sent: Wednesday, March 15, 2000 12:46 PM > > To: Ken Raeburn > > Cc: ietf-cat-wg@lists.Stanford.EDU > > Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt > > > > > > > > > The second is, would the administrator of foobar.ibm.com really have > > > the ability to create entries under "=i=b=m.=c=o=m." for other sites > > > to see? I don't think so. And, as you say, TXT response data is > > > case-preserving, so it's only in the query that this matters. > > > > You know. That is a very good point. This is what I get for drinking > > too much DrPepper in order to counter balance the lack of sleep. > > > > Clearly, this won't work, and yes. I now agree with you. Upper case > > realm names only. Of course, this is going to break the default names > > that Windows 2000 generates, but .... > > > > > > > Security issues: The second exploit described is an exploit > > of the MIT > > > implementation, not the Kerberos design. The Kerberos model itself > > > provides no way of determining the realm of a host. In > > fact, I don't > > > think it makes any requirement that multiple services running on a > > > single host (even without multiple hostnames etc) use the same local > > > realm. > > > > The problem is that there needs to be a way for the realm of a host to > > be determined. That is why the DNS TXT record is used; and why MIT > > placed host/domain to realm mappings into the config files. Of > > course, the Kerberos model does not provide any description of how > > this should be done because from the authentication perspective it is > > not necessary. But because these mappings are necessary and we do not > > have secure way of performing them, the exploit is an issue for all > > Kerberos implementations. Of course, if no host to realm mappings > > provided the exploit goes away. > > > > > > > > A random thought: You mention both krb4 and krb5 in the > > abstract, but > > > do we have any way of distinguishing a v4-only vs v5-only vs v4+v5 > > > site without having the info stored locally? > > > > No. There is nothing to distinguish a K4 KDC from a K5 KDC, and from > > my experience at Columbia there is no need to. We distributed 10,000 > > clients last Fall to users that supported K4 and K5 when our KDC was > > K4 only. In December, we switched from K4 to K5 1.1 without the users > > even noticing. The only thing that changed was that they now got both > > K4 and K5 tickets when they used Leash32. > > > > > > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for > > Win32 and OS/2 > > The Kermit Project * Columbia University > > 612 West 115th St #716 * New York, NY * 10025 > > http://www.kermit-project.org/k95.html * > > kermit-support@kermit-project.org > > > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to > > majordomo@lists.stanford.edu > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Mar 15 21:14:16 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22615 for ; Wed, 15 Mar 2000 21:14:15 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA04894 for ietf-cat-wg-out720680; Wed, 15 Mar 2000 17:32:06 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id RAA04889 for ; Wed, 15 Mar 2000 17:32:04 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 Mar 2000 17:21:57 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 17:21:57 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A5690716F70E@SIT.platinum.corp.microsoft.com> From: John Brezak To: "'jaltman@columbia.edu'" Cc: Ken Raeburn , ietf-cat-wg@lists.Stanford.EDU Subject: RE: comments on draft-ietf-cat-krb-dns-locate-02.txt Date: Wed, 15 Mar 2000 17:21:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk As per kerberos-revisions, "... (DNS) Domain names must be converted to uppersace when used as realm names." Since a Windows 2000 domain name is a DNS domain name, we follow this rule. When using a Windows 2000 domain name as a realm, it is always used in its uppercase form. Internally we preserve the case that was typed when it was created, but we aren't case sensitive. When using the domain name in UI, we use the "typed" case. > -----Original Message----- > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > Sent: Wednesday, March 15, 2000 5:00 PM > To: John Brezak > Cc: Ken Raeburn; ietf-cat-wg@lists.Stanford.EDU > Subject: RE: comments on draft-ietf-cat-krb-dns-locate-02.txt > > > > All Kerberos realm names for Windows 2000 domains are > uppercase because they > > are DNS names. > > I'm not sure I understand this. How does a name being a DNS name > result in it being an upper case realm name? > > I made my comment based on the fact that when I installed Win2000 > it defaulted to a realm name with only upper cased first characters of > each segment. But perhaps that was just the user presentation and you > always uppercase behind the scenes. > > > > > -----Original Message----- > > > From: Jeffrey Altman [mailto:jaltman@columbia.edu] > > > Sent: Wednesday, March 15, 2000 12:46 PM > > > To: Ken Raeburn > > > Cc: ietf-cat-wg@lists.Stanford.EDU > > > Subject: Re: comments on draft-ietf-cat-krb-dns-locate-02.txt > > > > > > > > > > > > > The second is, would the administrator of > foobar.ibm.com really have > > > > the ability to create entries under "=i=b=m.=c=o=m." > for other sites > > > > to see? I don't think so. And, as you say, TXT > response data is > > > > case-preserving, so it's only in the query that this matters. > > > > > > You know. That is a very good point. This is what I get > for drinking > > > too much DrPepper in order to counter balance the lack of sleep. > > > > > > Clearly, this won't work, and yes. I now agree with you. > Upper case > > > realm names only. Of course, this is going to break the > default names > > > that Windows 2000 generates, but .... > > > > > > > > > > Security issues: The second exploit described is an exploit > > > of the MIT > > > > implementation, not the Kerberos design. The Kerberos > model itself > > > > provides no way of determining the realm of a host. In > > > fact, I don't > > > > think it makes any requirement that multiple services > running on a > > > > single host (even without multiple hostnames etc) use > the same local > > > > realm. > > > > > > The problem is that there needs to be a way for the realm > of a host to > > > be determined. That is why the DNS TXT record is used; > and why MIT > > > placed host/domain to realm mappings into the config files. Of > > > course, the Kerberos model does not provide any description of how > > > this should be done because from the authentication > perspective it is > > > not necessary. But because these mappings are necessary > and we do not > > > have secure way of performing them, the exploit is an > issue for all > > > Kerberos implementations. Of course, if no host to realm mappings > > > provided the exploit goes away. > > > > > > > > > > > A random thought: You mention both krb4 and krb5 in the > > > abstract, but > > > > do we have any way of distinguishing a v4-only vs > v5-only vs v4+v5 > > > > site without having the info stored locally? > > > > > > No. There is nothing to distinguish a K4 KDC from a K5 > KDC, and from > > > my experience at Columbia there is no need to. We > distributed 10,000 > > > clients last Fall to users that supported K4 and K5 when > our KDC was > > > K4 only. In December, we switched from K4 to K5 1.1 > without the users > > > even noticing. The only thing that changed was that they > now got both > > > K4 and K5 tickets when they used Leash32. > > > > > > > > > > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for > > > Win32 and OS/2 > > > The Kermit Project * Columbia University > > > 612 West 115th St #716 * New York, NY * 10025 > > > http://www.kermit-project.org/k95.html * > > > kermit-support@kermit-project.org > > > > > > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > > > This message was posted through the Stanford campus mailing list > > > server. If you wish to unsubscribe from this mailing > list, send the > > > message body of "unsubscribe ietf-cat-wg" to > > > majordomo@lists.stanford.edu > > > > > > > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for > Win32 and OS/2 > The Kermit Project * Columbia University > 612 West 115th St #716 * New York, NY * 10025 > http://www.kermit-project.org/k95.html * > kermit-support@kermit-project.org > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 16 16:10:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19864 for ; Thu, 16 Mar 2000 16:10:49 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA09828 for ietf-cat-wg-out720680; Thu, 16 Mar 2000 12:43:42 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA09823 for ; Thu, 16 Mar 2000 12:43:39 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 16 Mar 2000 20:40:10 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA02567; Thu, 16 Mar 2000 15:41:04 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 16 Mar 2000 15:44:41 -0500 Message-ID: From: "Linn, John" To: "'Brian Tung'" , ietf-cat-wg@lists.Stanford.EDU Subject: RE: draft-ietf-cat-kerberos-pk-init-11.txt Date: Thu, 16 Mar 2000 15:52:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Brian wrote, excerpting: > > We would like to push for working group last call. The active parties > have reached consensus. > > b > The WG position of record has been that pk-init and kerberos-revisions are interrelated documents and therefore should be considered in a parallel WG last call once they're both ready, so (assuming these premises still hold) we should probably assess the readiness of both. BTW, newly revised versions of both of these documents appear to be available now, at http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-11.txt and http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-05.txt , though I haven't yet seen the corresponding I-D action messages announcing them. --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 16 16:33:19 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28053 for ; Thu, 16 Mar 2000 16:33:18 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA10871 for ietf-cat-wg-out720680; Thu, 16 Mar 2000 13:08:39 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA10862 for ; Thu, 16 Mar 2000 13:08:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18869; Thu, 16 Mar 2000 16:08:24 -0500 (EST) Message-Id: <200003162108.QAA18869@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-revisions-05.txt Date: Thu, 16 Mar 2000 16:08:23 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The Kerberos Network Authentication Service (V5) Author(s) : C. Neuman, G. Kohl, T. Ts'o Filename : draft-ietf-cat-kerberos-revisions-05.txt Pages : 103 Date : 15-Mar-00 This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], are available elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-revisions-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-revisions-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-revisions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-revisions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132129.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 16 16:39:35 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00459 for ; Thu, 16 Mar 2000 16:39:34 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA10852 for ietf-cat-wg-out720680; Thu, 16 Mar 2000 13:08:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA10843 for ; Thu, 16 Mar 2000 13:08:22 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18804; Thu, 16 Mar 2000 16:08:16 -0500 (EST) Message-Id: <200003162108.QAA18804@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-11.txt Date: Thu, 16 Mar 2000 16:08:16 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos Author(s) : B. Tung et.al Filename : draft-ietf-cat-kerberos-pk-init-11.txt Pages : 18 Date : 15-Mar-00 This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-pk-init-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-init-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132120.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 16 18:16:27 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07386 for ; Thu, 16 Mar 2000 18:16:26 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA14650 for ietf-cat-wg-out720680; Thu, 16 Mar 2000 14:48:05 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA14645 for ; Thu, 16 Mar 2000 14:48:02 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id RAA22701; Thu, 16 Mar 2000 17:48:01 -0500 (EST) Date: Thu, 16 Mar 2000 17:48:01 -0500 (EST) Message-Id: <200003162248.RAA22701@dcl.mit.edu> From: Ken Raeburn To: ietf-cat-wg@lists.Stanford.EDU Subject: comments on kerberos-revisions-05.txt Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Mostly without even looking at Kerberos stuff per se, some initial complaints: This tome has no table of contents or index, making it hard to find anything in printed copy. (Okay, call me old-fashioned, I print some of these suckers out.) There's no change history, indicating what's changed from the previous draft, or more importantly, from RFC1510. I'm starting to do some diffs against -04, filtering out formatting changes... Starting in section 6, everything is indented too far. (A minor thing, but it's messing up my diffs beyond that point.) It still refers to draft-horowitz-key-derivation-02.txt, but that has long since expired. Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 16 19:19:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01617 for ; Thu, 16 Mar 2000 19:19:10 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA17385 for ietf-cat-wg-out720680; Thu, 16 Mar 2000 15:52:18 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA17380 for ; Thu, 16 Mar 2000 15:52:16 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id SAA22935; Thu, 16 Mar 2000 18:52:15 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: the changes in kerberos-revisions-05.txt References: <200003162248.RAA22701@dcl.mit.edu> Mime-Version: 1.0 From: Ken Raeburn Date: 16 Mar 2000 18:52:14 -0500 In-Reply-To: Ken Raeburn's message of "Thu, 16 Mar 2000 17:48:01 -0500 (EST)" Message-ID: Lines: 84 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk After a couple hours or so of reindenting, refilling, filtering of whitespace changes, and manual edits, I've finally got a description of what's changed since -04. All hail Emacs! :-) Of course, a description of what's changed since RFC 1510 would be good too, but I don't feel up to trying that today. Here are what I consider the semantically significant changes to the text: In 1.2 (Authorization): Added: "Separately authenticated authorization credentials may be embedded in a tickets authorization data when encapsulated by the kdc-issued authorization data element." In 5.3.1 (Tickets): The addition of the "extensions" field is no longer "still subject to discussion". Authorization-data field can now be used to amplify privileges "when an entry is separately authenticated by encap[s]ulation in the kdc-issued element". As an alternative to the authorization grantor using authorization_data to add restrictions to authority delegated to a proxy, "such authorization credentials may be embedded in the ticket authenticating the authorized entity, when the authorization is separately authenticated using the kdc-issued authorization data element (see B.4)". (Section B.4 hasn't changed.) In 5.9.1 (KRB_ERROR definition): Optional field e-typed-data of KRB_ERROR, previously marked for deletion, has been deleted. In 6 (Encryption and Checksum Specifications): The description of using block ciphers to simulate stream ciphers now mentions "triple DES variants" as well as DES. In 6.1 (Encryption Specifications): The format of the data to be encrypted is no longer required to be the one given, but any other "methods" (meaning encryption mechanisms, I assume) that do otherwise must indicate the layout they use as part of their definitions. In 6.3.5 (Triple DES...): Incorporates revisions by David Miller. Not using key derivation is now an option. The previously assigned numbers are for the KD form, new numbers assigned for non-KD. String-to-key conversion is now specified. Input string is UNICODE. HMAC is required, not merely recommended, as the hash. Lots of changes; look it up yourself. :-) In 8.3 (Protocol constants and associated values): Encryption types: sign-dsa-generate deleted, des3 and rc4 values assigned. Checksum types: RSA values commented with "(drop rsa?)", added non-kd des3. Preauth data types: PA-ENC-UNIX-TYPE commented as deprecated, "PA-" prefix added to several entries, PA-SAM-ETYPE-INFO and several PA-PK values added. Authorization-data types: AD-OSF-DCE-PKI-CERTID added. Several entries now "" numbers were previously just badly formatted table entries. (Broken HTML source?) In 9.1 (Specification 2): Added "one triple des variant (tbd)" to required encryption types. Added "(tbd)" to required checksum types? -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun Mar 19 03:18:34 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06361 for ; Sun, 19 Mar 2000 03:18:33 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id XAA16452 for ietf-cat-wg-out720680; Sat, 18 Mar 2000 23:53:28 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id XAA16447 for ; Sat, 18 Mar 2000 23:53:25 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id CAA25925; Sun, 19 Mar 2000 02:53:24 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: comments on kerberos-revisions-05 References: <200003162248.RAA22701@dcl.mit.edu> Mime-Version: 1.0 From: Ken Raeburn Date: 19 Mar 2000 02:53:24 -0500 In-Reply-To: Ken Raeburn's message of "Thu, 16 Mar 2000 17:48:01 -0500 (EST)" Message-ID: Lines: 10 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.6 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Is the key-derivation draft going to get re-issued? Marc? Considering the operations described in draft-ietf-cat-kerberos-passwords-04 (is this gonna get updated?), perhaps we should also add descriptions on how to generate keys given two independent keys as input, rather than a key and a small-integer usage value? I.e., make it part of the complete specification of a Kerberos cryptosystem? Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Mar 20 18:26:06 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24412 for ; Mon, 20 Mar 2000 18:26:05 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id OAA07473 for ietf-cat-wg-out720680; Mon, 20 Mar 2000 14:55:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA07313 for ; Mon, 20 Mar 2000 14:54:43 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02747; Mon, 20 Mar 2000 09:47:24 -0500 (EST) Message-Id: <200003201447.JAA02747@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-cat-wg@lists.Stanford.EDU From: The IESG Subject: Protocol Action: LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM to Proposed Standard Date: Mon, 20 Mar 2000 09:47:24 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk The IESG has approved the Internet-Draft 'LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM' as a Proposed Standard. This document is the product of the Common Authentication Technology Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary The Simple Public Key Mechanism (SPKM) is a GSSAPI mechanism that makes use of public/private key pairs to provide authentication within the context of the GSSAPI. LIPKEY is an extension that requires only one side of the association (nominally the server) to have a public key certificate. The client side can use a password, which will be encrypted, for authentication. LIPKEY provides the GSSAPI equivalent of going to a Web Site via TLS and performing client authentication via a password (which is encrypted by TLS). This approach has the property that only servers have to obtain and deal with public key certificates. Working Group Summary The working group supports this document. Protocol Quality Jeff Schiller has reviewed this document for the IESG and found no flaws in the protocol. Note to RFC Editor: Please arrange with the IANA for the assignment of three OIDs under the IETF arc and edit this document (sections 2.1, 2.3.1, and 4.1) to include the newly assigned OIDs" Also change the following references: From: [RSA-IP] Unidentified member of IETF's Public-Key Infrastructure (X.509) Working Group (Undated, but no later than 1999). "RSA's unofficial statement pertaining to PKIX." http://www.ietf.org/ietf/IPR/PKIX-RSA To: [RSA-IP] All statements received by the IETF Secretariat are places on-line in http://www.ietf.org/ipr.html. Please check this web page to see any IPR information received about this and other technology. From: [Young] Young, E.A. (1997). "Index of /archives/net/Crypto/libeay." http://ring.crl.go.jp/archives/net/Crypto/libeay/ To: [Young] Young, E.A. (1997). Collected timing results from the SSLeay source code distribution. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Mar 20 18:26:40 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24646 for ; Mon, 20 Mar 2000 18:26:39 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id OAA07476 for ietf-cat-wg-out720680; Mon, 20 Mar 2000 14:55:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA07328 for ; Mon, 20 Mar 2000 14:54:48 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11040; Mon, 20 Mar 2000 07:50:25 -0500 (EST) Message-Id: <200003201250.HAA11040@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-cat-wg@lists.Stanford.EDU From: The IESG Subject: Protocol Action: Generic Security Service API Version 2 : Java bindings to Proposed Standard Date: Mon, 20 Mar 2000 07:50:25 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk The IESG has approved the Internet-Draft 'Generic Security Service API Version 2 : Java bindings' as a Proposed Standard. This document is the product of the Common Authentication Technology Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary The GSSAPI provides uniform access to security services layered on top of a variety of underlying cryptographic mechanisms. The GSSAPI and a set of "C" Language bindings already exist. This document provides for the Java language bindings for Java programmers to make use of GSSAPI facilities. Working Group Summary The working group supports this document. Significant discussion was had about various alternatives to this implementation. This document represents the consensus view reached after weighing the benefits and costs of the various alternatives. Protocol Quality Jeff Schiller has reviewed this document for the IESG and found no flaws in the protocol. It was also reviewed from the standpoint of how it would fit into the Java platform architecture. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Mar 20 19:31:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19501 for ; Mon, 20 Mar 2000 19:31:58 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA17825 for ietf-cat-wg-out720680; Mon, 20 Mar 2000 16:04:51 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA17820 for ; Mon, 20 Mar 2000 16:04:49 -0800 (PST) From: bps11@ureach.com Received: from 01-025.011.popsite.net by MIT.EDU with SMTP id AA26274; Mon, 20 Mar 00 02:03:13 EST Subject: your imaging supplies Date: Mon, 20 Mar 2000 02:00:33 Message-Id: <31.561891.383703@> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk BENCHMARK SUPPLY 5334 LAKE VIEW CLUB ATLANTA GA 30338 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-494-8597**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Mar 24 02:04:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28603 for ; Fri, 24 Mar 2000 02:04:47 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id WAA03877 for ietf-cat-wg-out720680; Thu, 23 Mar 2000 22:37:59 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id WAA03872 for ; Thu, 23 Mar 2000 22:37:57 -0800 (PST) Received: from [151.196.157.2] by MIT.EDU with SMTP id AA17268; Fri, 24 Mar 00 01:37:45 EST Received: (from root@localhost) by hamster.com (8.9.3/8.9.3) id BAA21688; Fri, 24 Mar 2000 01:31:53 -0500 Date: Fri, 24 Mar 2000 01:31:53 -0500 Message-Id: <200003240631.BAA21688@hamster.com> To: cat-ietf@mit.edu From: Subject: Your website and HAMSTER.COM! Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hey! I just visited your site http://www.cis.ohio-state.edu/htbin/rfc/rfc2228.html , and found it quite interesting :> I'm running this program called -Hamster ADS- which pays up to 20 cents per unique visitor & 5 cents per click on TEXT ADS which can fit right into your site perfectly. We cut checks to our webmasters EVERY friday and I'm sure you will be very interested :> Check us out @ http://www.hamster.com If you have any questions email me at jack@hamster.com Hope to see you on our program soon! Thanks for your time. Jack http://www.hamster.com jack@hamster.com -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Mar 30 15:24:43 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21283 for ; Thu, 30 Mar 2000 15:24:42 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA17876 for ietf-cat-wg-out720680; Thu, 30 Mar 2000 11:56:33 -0800 (PST) Received: from telemark.stanford.edu (telemark.Stanford.EDU [171.64.12.100]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA17871 for ; Thu, 30 Mar 2000 11:56:31 -0800 (PST) Received: from localhost by telemark.stanford.edu (8.10.0.Beta3/8.10.0.PreAlpha1) with ESMTP id e2UJuUh06495 for ; Thu, 30 Mar 2000 11:56:30 -0800 (PST) Date: Thu, 30 Mar 2000 11:56:30 -0800 (PST) From: Booker Bense To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: comments on kerberos-revisions-05.txt In-Reply-To: <200003162248.RAA22701@dcl.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk - I have some quibble with Section 7.1 realm names. Domain names must look like domain names: they consist of components separated by periods (.) and they contain neither colons (:) nor slashes (/). Domain names must be converted to upper case when used as realm names. - This is going to make my life very difficult, ( and perhaps other sites foolish enough to get trapped in DCE ). I think that there is a pretty strong case that for user inaction, a principal should just "look like an email address". 99.99999% of the world is used to using lower case for the domain part of email addresses. - It's a whole lot easier to tell some one over the phone "just type in your email address" than to explain the oddities of some RFC. While this issue can be addressed in software, I think it would be better to simply state that "Domain based realm names are case-insentive and follow the rules for DNS names (see RFCXXXX)". - This halfway position (i.e. realm names are case-sensitive, but you can't use lower case ) makes very little sense to me. - Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu