From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 3 10:53:08 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA18344; Tue, 3 Mar 98 10:53:08 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA05683 for cat-ietf-redist; Tue, 3 Mar 1998 09:24:36 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F8012766012110E3@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Subject: Update/discussion/presentation plans for LA CAT meeting? Date: Tue, 3 Mar 1998 09:26:24 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk CAT fanciers: I'd like to reiterate a request for information about pending submissions/updates of CAT-related I-Ds, and to ask anyone wishing to lead discussions about particular I-Ds or WG-related issues to make their intentions known. Given the general scarcity of meeting slots as an IETF-wide resource, I believe that it's appropriate to retain the two slots (one full-length, one half-length) currently assigned to CAT only if intended and identified discussion warrants, and will plan to evaluate one week from today (Tuesday, 10 March) whether to return a slot to the assignment pool based on discussion requests received by that point. Thanks, ... --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 5 17:57:56 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15804; Thu, 5 Mar 98 17:57:56 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA19720 for cat-ietf-redist; Thu, 5 Mar 1998 17:05:08 -0500 (EST) From: Martin Rex Message-Id: <199803052204.XAA02174@hw1464.wdf.sap-ag.de> Subject: full-duplex message protection services To: cat-ietf@mit.edu Date: Thu, 5 Mar 1998 23:04:56 +0100 (MET) Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk I was recently surprised when I tried to use protect a full duplex communication between to peers with gssapi message protection services and the gssapi mechanism constantly returned verification errors from the message unprotection calls. There is no explicit "full-duplex requirement" in any of the gssapi documents, HOWEVER, there is also NO side effect or restriction mentioned for the message protection calls (gss_wrap,gss_get_mic) that would require an application to limit itself to half-duplex communication. Therefore I consider a gssapi mechanism that is limited to half-duplex message protection services incompliant with both specs (v1/v2). The two pitfalls for a hasty gssapi mechanism designer that come to my mind are (1) using a single sequence number for both directions and (2) using a stream cipher (like RC4) and a single keystream for both directions. (OTOH, using another instance of the same keystream could likely support full-duplex, but would open a severe vulnerability...) Although I think the full-duplex message protection is implied by the specification of the message protection calls, a short explicit notice in rfc2078bis, either "Section 1.1.3 Security Contexts", par 2 or 3 and/or Section 1.2.2/1.2.3. Comments? Proposals? (1or2 sentences) If I read the spec correctly, TLS avoids this problem by using different keys for both directions -- independent of the cryptographic algorithms that are used. rfc2078bis is currently in WG last call, and I really want to see the document advance, so if the sense of the WG is that the implicit requirement is sufficient -- oh well, then I will accept it. Checking for full-duplex is rather easy: establish a security context with yourself and first call gss_wrap() once for each (acceptor, initiator) context with a different(!) message and after that gss_unwrap() for each of the two tokens on the respective peer context. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 5 19:03:34 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA16912; Thu, 5 Mar 98 19:03:34 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA22856 for cat-ietf-redist; Thu, 5 Mar 1998 17:36:39 -0500 (EST) From: Martin Rex Message-Id: <199803052236.XAA02288@hw1464.wdf.sap-ag.de> Subject: Re: Exportable encryption & Kerberos To: tytso@MIT.EDU, Michael.Eisler@Eng.Sun.CO, mikesw@microsoft.com Date: Thu, 5 Mar 1998 23:36:28 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <199801210307.WAA00819@rsts-11.mit.edu> from "tytso@MIT.EDU" at Jan 20, 98 10:07:49 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk tytso@MIT.EDU wrote: > > Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST) > From: Mike Eisler > > The practical reality is that these laws exist. Without some written > definition of weak cryto, what will happen is various implementers will > implement non-interoperable schemes. An Informational RFC on 40 bit > Kerberos V5 privacy would be useful for that reason. > > Well, if we're going to do weak crypto, we should at least do it right, > which means defining a new Kerberos V5 encryption type, instead of using > the kludge which Mike was suggesting. (Mike, speaking of which, I need > to talk to you off-line; the hack you guys are using in NT 5.0 Beta 1 to > indicate a NTLM string-to-key algorithm with an unregistered, > undocumented encryption type is *really* not the best way to do > things...) > > It's not clear wheather or not the IESG will published such an > Informational RFC, but I do understand the argument that there should be > one broken way of doing insecure crypto. > > However, we should all note that an implementation can't be called > Kerberos-compliant unless it implements the mandatory-to-implement > encryption algorithms --- and this position *is* consistent with the > stand that the IESG has taken in the past on IPSEC, TLS, etc. I have no experience with US crypto export and I'm not familiar with the Kerberos protocol details, but I'm really curious about the following: Does the export restriction apply to "encryption" only, or is it also mandated to restrict decryption to keys that are known to be weak. i.e. if the Kerberos protocol is changed/updated (that is necessary to accomodate *any* crpyto-export scheme, right?) how about the possibility to use independent keys for each direction? So both peers have the opportunity to specify a subsession key that they will use for protecting outgoing messages. An "exportable" peer would only generate "weak" subsession keys, always send them along and always use them for protecting outgoing messages. With this scheme, you wouldn't even have to tag keys as weak or strong. Now would you be able to get export approval on software that is still able to successfully receive information with strong encryption, but applies only weak encryption itself? -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 5 23:44:52 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA21758; Thu, 5 Mar 98 23:44:52 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id WAA20653 for cat-ietf-redist; Thu, 5 Mar 1998 22:27:56 -0500 (EST) To: Martin.Rex@sap-ag.de Cc: tytso@MIT.EDU, Michael.Eisler@Eng.Sun.CO, mikesw@microsoft.com, cat-ietf@MIT.EDU Subject: Re: Exportable encryption & Kerberos References: <199803052236.XAA02288@hw1464.wdf.sap-ag.de> X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 06 Mar 1998 04:27:10 +0100 In-Reply-To: Martin Rex's message of Thu, 5 Mar 1998 23:36:28 +0100 (MET) Message-Id: Lines: 11 X-Mailer: Gnus v5.4.52/Emacs 19.34 Precedence: bulk Martin Rex writes: > An "exportable" peer would only generate "weak" subsession keys, > always send them along and always use them for protecting outgoing > messages. With this scheme, you wouldn't even have to tag keys as > weak or strong. This is exactly what you don't want. Weak keys should be clearly labeled as such. /Johan From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 11:45:11 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA04438; Fri, 6 Mar 98 11:45:11 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA23761 for cat-ietf-redist; Fri, 6 Mar 1998 10:16:14 -0500 (EST) From: John_Wray@iris.com X-Lotus-Fromdomain: IRIS To: Martin.Rex@sap-ag.de Cc: cat-ietf@MIT.EDU Message-Id: <852565BF.004A86DB.00@arista.iris.com> Date: Fri, 6 Mar 1998 09:06:52 -0500 Subject: Re: Exportable encryption & Kerberos Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk Martin writes: >Does the export restriction apply to "encryption" only, or is it >also mandated to restrict decryption to keys that are known to >be weak. If there's any logic at all to the export restrictions (and I know that that's a big if), they'd have to require weak encryption in both directions, because allowing strong encryption in one direction enables strong encryption in both directions. If you allow a strongly encrypted channel from A->B, then A & B can easily conspire to create a strongly encrypted channel from B->A by having A generate a random key-stream, send it to B over the strongly-protected A->B channel, at which point B simply XORs his data with the key-stream and sends the results back to A. I think you'd be extremely lucky if you were to get an export ruling that allowed this. John From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 12:47:46 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05501; Fri, 6 Mar 98 12:47:46 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA26042 for cat-ietf-redist; Fri, 6 Mar 1998 10:39:28 -0500 (EST) Message-Id: From: "Mike Swift (NT)" To: cat-ietf@MIT.EDU Subject: FW: Exportable encryption & Kerberos Date: Fri, 6 Mar 1998 07:38:28 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precedence: bulk I would like to propose extending the Authenticator structure in Kerberos in include a list of keys. By placing it at the end existing code should skip over it (or so I'm told). This would allow a client to propose a number of encryption types and for the server to choose among them. Currently, the client can only propose one subkey. This makes it difficult both to negotiate to a weaker encryption mechanism and to a stronger encryption mechanism. The general idea would be that the client can propose a set of keys for different encryption types and the server can respond, in the AP-REPLY, with either one of those keys, or a new key from the same list of encryption types. This would require a new weakened encryption types, which could be accomplished by sending just a limited number of bits of keying material and then running that through the string-to-key function (or perhaps an MD5 of that material) to generate the DES key. Any thoughts? - Mike -----Original Message----- From: Martin Rex [mailto:martin.rex@sap-ag.de] Sent: Thursday, March 05, 1998 2:36 PM To: tytso@MIT.EDU; Michael.Eisler@Eng.Sun.CO; Mike Swift (NT) Cc: cat-ietf@MIT.EDU Subject: Re: Exportable encryption & Kerberos tytso@MIT.EDU wrote: > > Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST) > From: Mike Eisler > > The practical reality is that these laws exist. Without some written > definition of weak cryto, what will happen is various implementers will > implement non-interoperable schemes. An Informational RFC on 40 bit > Kerberos V5 privacy would be useful for that reason. > > Well, if we're going to do weak crypto, we should at least do it right, > which means defining a new Kerberos V5 encryption type, instead of using > the kludge which Mike was suggesting. (Mike, speaking of which, I need > to talk to you off-line; the hack you guys are using in NT 5.0 Beta 1 to > indicate a NTLM string-to-key algorithm with an unregistered, > undocumented encryption type is *really* not the best way to do > things...) > > It's not clear wheather or not the IESG will published such an > Informational RFC, but I do understand the argument that there should be > one broken way of doing insecure crypto. > > However, we should all note that an implementation can't be called > Kerberos-compliant unless it implements the mandatory-to-implement > encryption algorithms --- and this position *is* consistent with the > stand that the IESG has taken in the past on IPSEC, TLS, etc. I have no experience with US crypto export and I'm not familiar with the Kerberos protocol details, but I'm really curious about the following: Does the export restriction apply to "encryption" only, or is it also mandated to restrict decryption to keys that are known to be weak. i.e. if the Kerberos protocol is changed/updated (that is necessary to accomodate *any* crpyto-export scheme, right?) how about the possibility to use independent keys for each direction? So both peers have the opportunity to specify a subsession key that they will use for protecting outgoing messages. An "exportable" peer would only generate "weak" subsession keys, always send them along and always use them for protecting outgoing messages. With this scheme, you wouldn't even have to tag keys as weak or strong. Now would you be able to get export approval on software that is still able to successfully receive information with strong encryption, but applies only weak encryption itself? -Martin From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 13:48:43 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA06554; Fri, 6 Mar 98 13:48:43 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA10225 for cat-ietf-redist; Fri, 6 Mar 1998 13:01:59 -0500 (EST) Message-Id: <199803061801.SAA16688@orchard.arlington.ma.us> To: "Mike Swift (NT)" Cc: cat-ietf@MIT.EDU Subject: Re: FW: Exportable encryption & Kerberos In-Reply-To: Your message of "Fri, 6 Mar 1998 09:53:29 -0800 ." Date: Fri, 06 Mar 1998 13:01:53 -0500 From: Bill Sommerfeld Precedence: bulk > Dropping this idea means that US vendors can't ship Kerberos outside the > U.S. Are you asking us to write off 90% of the world population from using > products implemented in the US? I'm not writing them off; the US government's export controls are. Moreover: - I am aware that other US vendors have received permission to export full-strength DES-based kerberos v5 in binary form based on the key recovery "deal with the devil" exemption. - there are implementations of kerberos available outside the US from non-US sources, which means that the ~95% of the world population outside the US can still get access to the technology; the only folks being hurt by this are US vendors, and they're hurt by US regulations.. - Bill From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 14:42:32 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA07466; Fri, 6 Mar 98 14:42:32 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA07939 for cat-ietf-redist; Fri, 6 Mar 1998 12:38:20 -0500 (EST) Message-Id: <199803061738.RAA16592@orchard.arlington.ma.us> To: "Mike Swift (NT)" Cc: cat-ietf@MIT.EDU Subject: Re: FW: Exportable encryption & Kerberos In-Reply-To: Your message of "Fri, 6 Mar 1998 07:38:28 -0800 ." Date: Fri, 06 Mar 1998 12:38:15 -0500 From: Bill Sommerfeld Precedence: bulk > This would require a new weakened encryption types, which could be > accomplished by sending just a limited number of bits of keying material and > then running that through the string-to-key function (or perhaps an MD5 of > that material) to generate the DES key. Time and time again, the subject of a weakened encryption type for kerberos has been brought up here. DES is pitifully weak as it is; Why are we bothering with anything weaker? While I'm not the WG chair and am thus not in the position to judge the presence or absence of consensus, I think it's been clear from past discussion that there are very few other members of the WG who think that this is a good idea. Can't we just drop the idea? Vendors who want to implement weakened methods are always free to, but I don't think the community as a whole is served by having an interoperable weak encryption method... we shouldn't be standardizing something which is fundamentally broken.. - Bill From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 14:45:56 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA07563; Fri, 6 Mar 98 14:45:56 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA09353 for cat-ietf-redist; Fri, 6 Mar 1998 12:53:39 -0500 (EST) Message-Id: From: "Mike Swift (NT)" To: Bill Sommerfeld Cc: cat-ietf@MIT.EDU Subject: RE: FW: Exportable encryption & Kerberos Date: Fri, 6 Mar 1998 09:53:29 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precedence: bulk Dropping this idea means that US vendors can't ship Kerberos outside the U.S. Are you asking us to write off 90% of the world population from using products implemented in the US? This is not an option - we have to find a solution. - Mike -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@orchard.arlington.ma.us] Sent: Friday, March 06, 1998 9:38 AM To: Mike Swift (NT) Cc: cat-ietf@mit.edu Subject: Re: FW: Exportable encryption & Kerberos > This would require a new weakened encryption types, which could be > accomplished by sending just a limited number of bits of keying material and > then running that through the string-to-key function (or perhaps an MD5 of > that material) to generate the DES key. Time and time again, the subject of a weakened encryption type for kerberos has been brought up here. DES is pitifully weak as it is; Why are we bothering with anything weaker? While I'm not the WG chair and am thus not in the position to judge the presence or absence of consensus, I think it's been clear from past discussion that there are very few other members of the WG who think that this is a good idea. Can't we just drop the idea? Vendors who want to implement weakened methods are always free to, but I don't think the community as a whole is served by having an interoperable weak encryption method... we shouldn't be standardizing something which is fundamentally broken.. - Bill From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 15:44:55 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08514; Fri, 6 Mar 98 15:44:55 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA22488 for cat-ietf-redist; Fri, 6 Mar 1998 15:05:41 -0500 (EST) From: Martin Rex Message-Id: <199803062005.VAA05871@hw1464.wdf.sap-ag.de> Subject: Re: FW: Exportable encryption & Kerberos To: mikesw@microsoft.com (Mike Swift) Date: Fri, 6 Mar 1998 21:05:24 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: from "Mike Swift" at Mar 6, 98 09:53:29 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Mike Swift wrote: > > Dropping this idea means that US vendors can't ship Kerberos outside the > U.S. Are you asking us to write off 90% of the world population from using > products implemented in the US? This is not an option - we have to find a > solution. Dropping this idea means that 90% of the world population will have a much stronger incentive to use strong crypto, because it will be much harder for (certain) vendors to spread interoperable weak crypto. But the main point acutally is: if those that currently have implemented stronger crypto would have to add weak crypto to become compliant and fully interoperable with an updated Kerberos 5 specification, then this it is indeed a very bad idea. I'm sorry for having launched another round of "beating the dead horse". -Martin From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 16:44:24 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09565; Fri, 6 Mar 98 16:44:24 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA23029 for cat-ietf-redist; Fri, 6 Mar 1998 15:12:07 -0500 (EST) Message-Id: From: "Mike Swift (NT)" To: Martin.Rex@sap-ag.de Cc: cat-ietf@MIT.EDU Subject: RE: FW: Exportable encryption & Kerberos Date: Fri, 6 Mar 1998 12:11:55 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precedence: bulk True. However, adding a mechanism to the AP request to negotiate an encryption type would be useful both to upgrade the encryption type to a stronger mechanism as well as downgrade it to a weaker mechanism. - Mike -----Original Message----- From: Martin Rex [mailto:martin.rex@sap-ag.de] Sent: Friday, March 06, 1998 12:05 PM To: Mike Swift (NT) Cc: cat-ietf@mit.edu Subject: Re: FW: Exportable encryption & Kerberos Mike Swift wrote: > > Dropping this idea means that US vendors can't ship Kerberos outside the > U.S. Are you asking us to write off 90% of the world population from using > products implemented in the US? This is not an option - we have to find a > solution. Dropping this idea means that 90% of the world population will have a much stronger incentive to use strong crypto, because it will be much harder for (certain) vendors to spread interoperable weak crypto. But the main point acutally is: if those that currently have implemented stronger crypto would have to add weak crypto to become compliant and fully interoperable with an updated Kerberos 5 specification, then this it is indeed a very bad idea. I'm sorry for having launched another round of "beating the dead horse". -Martin From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 16:53:54 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09744; Fri, 6 Mar 98 16:53:54 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA19722 for cat-ietf-redist; Fri, 6 Mar 1998 14:39:17 -0500 (EST) Message-Id: <199803061939.OAA20024@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-ftpdsaauth-02.txt Date: Fri, 06 Mar 1998 14:39:07 -0500 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 : FTP Authentication Using DSA Author(s) : P. Yee, R. Housley, W. Nace Filename : draft-ietf-cat-ftpdsaauth-02.txt Pages : 8 Date : 05-Mar-98 This document defines a method to secure file transfers using the FTP specification RFC 959, ''FILE TRANSFER PROTOCOL (FTP)'' (October 1985) and RFC 2228 ''FTP Security Extensions'' (October 1997) [1]. This method will use the extensions proposed in the ''FTP Security Extensions'' along with a public/private digital signature. Internet-Drafts are 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-ftpdsaauth-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-ftpdsaauth-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-ftpdsaauth-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: <19980305115202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-ftpdsaauth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-ftpdsaauth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980305115202.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 6 17:37:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10503; Fri, 6 Mar 98 17:37:23 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA19652 for cat-ietf-redist; Fri, 6 Mar 1998 14:38:28 -0500 (EST) Message-Id: <199803061938.OAA19981@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-snego-08.txt Date: Fri, 06 Mar 1998 14:38:19 -0500 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 Simple and Protected GSS-API Negotiation Mechanism Author(s) : D. Pinkas, E. Baize Filename : draft-ietf-cat-snego-08.txt Pages : 14 Date : 05-Mar-98 This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms. Internet-Drafts are 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-snego-08.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-snego-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-snego-08.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: <19980305114757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-snego-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-snego-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980305114757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Sat Mar 7 11:46:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA29192; Sat, 7 Mar 98 11:46:00 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA09872 for cat-ietf-redist; Sat, 7 Mar 1998 10:34:04 -0500 (EST) To: "Mike Swift (NT)" Cc: Bill Sommerfeld , cat-ietf@mit.edu Subject: Re: Exportable encryption & Kerberos References: X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 07 Mar 1998 16:33:04 +0100 In-Reply-To: "Mike Swift's message of Fri, 6 Mar 1998 09:53:29 -0800 Message-Id: Lines: 10 X-Mailer: Gnus v5.4.52/Emacs 19.34 Precedence: bulk "Mike Swift (NT)" writes: > Dropping this idea means that US vendors can't ship Kerberos outside > the U.S. This is what your government has decided. Go and beat on them instead of us. The argument that you are losing lots of money because you aren't allowed to export won't hold if you export anyway. /Johan From owner-cat-ietf@pad-thai.cam.ov.com Sat Mar 7 12:43:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00242; Sat, 7 Mar 98 12:43:00 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA08970 for cat-ietf-redist; Sat, 7 Mar 1998 10:24:27 -0500 (EST) To: "Mike Swift (NT)" Cc: Martin.Rex@sap-ag.de, cat-ietf@MIT.EDU Subject: Re: FW: Exportable encryption & Kerberos References: X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 07 Mar 1998 16:20:40 +0100 In-Reply-To: "Mike Swift's message of Fri, 6 Mar 1998 12:11:55 -0800 Message-Id: Lines: 12 X-Mailer: Gnus v5.4.52/Emacs 19.34 Precedence: bulk "Mike Swift (NT)" writes: > True. However, adding a mechanism to the AP request to negotiate an > encryption type would be useful both to upgrade the encryption type > to a stronger mechanism as well as downgrade it to a weaker > mechanism. Not true. You can't ever upgrade an ongoing session to something stronger (without involving the KDC). Why this is the case is left as an exercise to the reader. /Johan From owner-cat-ietf@pad-thai.cam.ov.com Sat Mar 7 21:42:40 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09440; Sat, 7 Mar 98 21:42:40 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id UAA05895 for cat-ietf-redist; Sat, 7 Mar 1998 20:26:18 -0500 (EST) To: joda@pdc.kth.se (Johan Danielsson) Cc: "Mike Swift (NT)" , Martin.Rex@sap-ag.de, cat-ietf@mit.edu Subject: Re: FW: Exportable encryption & Kerberos References: From: Sam Hartman Date: 07 Mar 1998 20:26:11 -0500 In-Reply-To: joda@pdc.kth.se's message of 07 Mar 1998 16:20:40 +0100 Message-Id: Lines: 28 X-Mailer: Gnus v5.2.37/Emacs 19.34 Precedence: bulk >>>>> "Johan" == Johan Danielsson writes: Johan> "Mike Swift (NT)" writes: >> True. However, adding a mechanism to the AP request to >> negotiate an encryption type would be useful both to upgrade >> the encryption type to a stronger mechanism as well as >> downgrade it to a weaker mechanism. Johan> Not true. You can't ever upgrade an ongoing session to Johan> something stronger (without involving the KDC). Why this is Johan> the case is left as an exercise to the reader. There might be some slight advantages for long-lived sessions in terms of reducing the window in which a passive attack on the weak key would be successful, but the benefits would be minimal. I would also like to point out that Kerberos already allows a client to request a strong session key in the kdc_req message's etypes sequence. Even if it did add some real security to upgrade a subsession key, I'm unconvinced that the additional complexity would be worthwhile in the presence of a similar feature in the KDC exchange. I am somewhat concerned about interoperability if some vendors go off and add fields to the end of the authenticator structure. It would make it difficult for the IETF to extend the structure in the future, forcing a potentially unnecessary increase in the protocol version number. Johan> /Johan From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 02:42:25 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10142; Mon, 9 Mar 98 02:42:25 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id BAA12677 for cat-ietf-redist; Mon, 9 Mar 1998 01:30:50 -0500 (EST) Date: Mon, 9 Mar 1998 01:30:44 -0500 From: jtrostle@world.std.com (Jonathan Trostle) Message-Id: <199803090630.AA18569@world.std.com> To: cat-ietf@MIT.EDU Subject: CAT pk recovery internet draft summary Precedence: bulk I recently submitted the internet draft draft-ietf-cat-kerberos -pk-recovery-00.txt to the cat group internet drafts. Here is a summary: The motivation comes in an environment where smart cards are not ubiquitous and the pk-init extensions are being used. Thus users are likely to have their private keys encrypted on the KDC. Users thus share a long term secret with the KDC. If the KDC is compromised, a big problem results. The goal of the draft is to enable the secret keys to be updated with a minimum amount of administration work, and for the process to be transparent to users. The recovery protocols are designed to work in either an environment where the KDC public keys are signed as keys in a PKI, or where the KDC public keys are self-signed. For a recovery operation, the KDC is cleaned up and reloaded from backup media. In the case of self-signed certificates, the KDC sends new self-signed certificates to clients using a KRB_ERROR message with error code KDC_ERR_RECOVERY_HOST_NEEDED. Secret keys can also be updated with this exchange. The exchange uses Diffie Hellman with signed public parameters. Users also engage in a subsequent Diffie Hellman based exchange if they store secrets on the KDC. New user secrets are created by OWF(salt + password); the salt is changed for each new recovery operation. The recovery protocol improves the security of Kerberos V5 by using public key cryptography to enable easy cleanup of compromised KDC's. -Jonathan From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 03:44:33 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11213; Mon, 9 Mar 98 03:44:33 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id CAA18153 for cat-ietf-redist; Mon, 9 Mar 1998 02:39:08 -0500 (EST) Message-Id: <35041B15.5383@bull.net> Date: Mon, 09 Mar 1998 08:38:45 -0800 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: CAT-IETF WG Subject: SPNEGO-8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk I have edited the SPNEGO document and made some changes to it: 1) preferredToken has been changed to mechToken, since this field now carries mechanism tokens and not only the initial preferred token, as it was originally the case. 2) Since the status GSS_S_BAD_SIG is defined, it is now used when a MIC is incorrect or missing (instead of GSS_S_BAD_MECH). 3) Additional explanations have been added here or there. The document can be downloaded at: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-08.txt If changes are necessary, please provide alternative text and the rational. Denis -- *** Please note that the E-mail address has changed ! Update it. *** Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 13:09:26 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA20888; Mon, 9 Mar 98 13:09:26 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA03939 for cat-ietf-redist; Mon, 9 Mar 1998 11:10:05 -0500 (EST) Message-Id: From: "Mike Swift (NT)" To: joda@pdc.kth.se Cc: Bill Sommerfeld , cat-ietf@mit.edu Subject: RE: Exportable encryption & Kerberos Date: Mon, 9 Mar 1998 08:09:57 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precedence: bulk Let's rephrase the problem then. Microsoft is going to ship a product containing Kerberos outside of the United States, and it will use weakened encryption. Given that fact, I can either make up my own scheme for weakened encryption or the CAT list can come up with a solution. As it now stands, I have a complete hack that uses the standard encryption types but changes the keytype in the AP request authenticator to indicate that the key is weak. I would prefer a better solution, but the only option I've heard so far is to extend the authenticator to include multiple sub session keys, and that action would require support of the CAT group. - Mike -----Original Message----- From: joda@pdc.kth.se [mailto:joda@pdc.kth.se] Sent: Saturday, March 07, 1998 7:33 AM To: Mike Swift (NT) Cc: Bill Sommerfeld; cat-ietf@mit.edu Subject: Re: Exportable encryption & Kerberos "Mike Swift (NT)" writes: > Dropping this idea means that US vendors can't ship Kerberos outside > the U.S. This is what your government has decided. Go and beat on them instead of us. The argument that you are losing lots of money because you aren't allowed to export won't hold if you export anyway. /Johan From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 14:42:36 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA22962; Mon, 9 Mar 98 14:42:36 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA09274 for cat-ietf-redist; Mon, 9 Mar 1998 12:03:30 -0500 (EST) Date: Mon, 9 Mar 1998 09:03:13 -0800 (PST) From: Gene Tsudik Message-Id: <199803091703.JAA20213@pollux.usc.edu> To: cat-ietf@MIT.EDU Subject: Final CFP: 5th ACM Conference on Computer and Communications Security Precedence: bulk Final Call for Papers Fifth ACM Conference on Computer and Communications Security San Francisco, California November 3-5, 1998 Sponsored by ACM SIGSAC Papers offering novel research contributions in any aspect of computer security are solicited for submission to the Fifth ACM Conference on Computer and Communications Security. Papers may present theory, technique, applications, or practical experience on topics including but not limited to access control authentication accounting and audit mobile code security applied cryptography data/system integrity cryptographic electronic commerce intrusion detection protocols key management privacy and anonymity intellectual property protection information warfare secure networking secure operating systems viruses and worms security management distributed systems security database security smart-cards and secure security verification PDAs Accepted papers will be presented at the conference and published by the ACM in a conference proceedings. Outstanding papers will be invited for possible publication in ACM Transactions on Information and System Security. Instructions for paper submissions: Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with a proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font and reasonable margins on 8.5'x11' paper), and at most 20 pages total. Committee members are not required to read the appendices, and so the paper should be intelligible without them. Papers should be submitted in a form suitable for anonymous review (no author names or affiliations). * Send via email to reiter@research.att.com a plain ASCII text message containing the title and abstract of your paper, the authors' names, email and postal addresses, phone and fax numbers, and identification of the contact author. * In addition, submit your paper using ONE of the following two methods. o Electronic submission (preferred): Instructions for submitting your Postscript paper by e-mail can be obtained from http://www.research.att.com/~reiter/ccs5/esub.html or by sending email to ccs98@research.att.com with the Subject line containing "HELP". It is strongly recommended that you electronically submit your paper at least five days in advance of the submission deadline, to allow us adequate time to verify that we can print your paper (and if not, to allow you to submit your paper in hardcopy to be received by the submission deadline). We cannot be held responsible for papers that we cannot print. OR o Hardcopy submission: Send eighteen (18) copies of your paper to the program chair at the address below with a cover letter indicating that your paper is a submission for the 5th ACM Conference on Computer and Communications Security, and listing the authors' names, email and postal addresses, phone and fax numbers, and identifying the contact author. Submissions received after the submission deadline will be rejected without review. Where possible all further communications to authors will be via email. Paper submissions due: April 3, 1998 Acceptance notification: June 5, 1998 Final papers due: July 16, 1998 Instructions for panel proposals The conference may include panel sessions addressing topics of interest to the computer security community. Proposals for panels should be no longer than five (5) pages in length and should include possible panelists and an indication of which of those panelists have confirmed participation. Send two (2) hardcopies of your proposal to the program chair at the address below with a cover letter indicating that your proposal is for the 5th ACM Conference on Computer and Communications Security, and listing the proposers' names, email and postal addresses, and phone and fax numbers. Panel proposals due: May 1, 1998 Acceptance notification: June 5, 1998 Steering committee chair: Ravi Sandhu, George Mason University General chair: Li Gong, JavaSoft Program chair: Mike Reiter AT&T Labs, Room A269, 180 Park Avenue Florham Park, NJ 07932-0971 USA phone: +973-360-8349 Awards chair: Jacques Stern, ENS/DMI Publication chair: Stuart Stubblebine, AT&T Labs Publicity chair: Gene Tsudik, USC ISI Program committee: Martin Abadi, DEC SRC David Naccache, Gemplus Bill Cheswick, Lucent/Bell Labs Hilarie Orman, DARPA/ITO Carl Ellison, Cybercash Avi Rubin, AT&T Labs--Research Ed Felten, Princeton University Pierangela Samarati, Universita di Milano Paul Karger, IBM T.J. Watson Gene Tsudik, USC ISI Steve Kent, BBN Corporation Paul Van Oorschot, Entrust Technologies Ueli Maurer, ETH Zurich Bennet Yee, UCSD Cathy Meadows, Naval Res. Lab Moti Yung, CertCo For more information, visit http://www.research.att.com/~reiter/ccs5 or http://www.isi.edu/~gts/cfp.html From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 16:20:58 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA24675; Mon, 9 Mar 98 16:20:58 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA20947 for cat-ietf-redist; Mon, 9 Mar 1998 14:01:09 -0500 (EST) Message-Id: <9803091901.AA09971@MIT.EDU> To: "Mike Swift (NT)" Cc: joda@pdc.kth.se, Bill Sommerfeld , cat-ietf@mit.edu Subject: Re: Exportable encryption & Kerberos In-Reply-To: Your message of "Mon, 09 Mar 1998 08:09:57 PST." Date: Mon, 09 Mar 1998 11:00:52 -0800 From: "Derrell D. Piper" Precedence: bulk For purposes of concensus only... I have the highest respect for Mike, but I would prefer that the CAT group not help standardize weakend encryption technology. That's not the way to fix the problem. Derrell From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 17:18:47 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA25644; Mon, 9 Mar 98 17:18:47 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA16753 for cat-ietf-redist; Mon, 9 Mar 1998 13:19:13 -0500 (EST) Message-Id: <199803091817.SAA26065@orchard.arlington.ma.us> To: "Mike Swift (NT)" Cc: joda@pdc.kth.se, cat-ietf@MIT.EDU Subject: Re: Exportable encryption & Kerberos In-Reply-To: Your message of "Mon, 9 Mar 1998 08:09:57 -0800 ." Date: Mon, 09 Mar 1998 13:17:40 -0500 From: Bill Sommerfeld Precedence: bulk > Let's rephrase the problem then. Microsoft is going to ship a product > containing Kerberos outside of the United States, and it will use weakened > encryption. Given that fact, I can either make up my own scheme for weakened > encryption or the CAT list can come up with a solution. You have a number of other options. You could use the "temporary single DES exemption" which everyone seems to think won't ever be ended.. Or you could create the opportunity for folks overseas to enhance your product for you.. - Bill From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 9 19:42:07 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA28130; Mon, 9 Mar 98 19:42:07 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA19734 for cat-ietf-redist; Mon, 9 Mar 1998 18:53:33 -0500 (EST) Message-Id: <35048053.6F14D9B@cybersafe.com> Date: Mon, 09 Mar 1998 15:50:43 -0800 From: David Margrave Organization: CyberSafe Corporation X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i586) Mime-Version: 1.0 To: cat-ietf@MIT.EDU Subject: RE: Exportable encryption & Kerberos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Some possible options for discussion: 1) continue to use the DES etypes and keytypes but the exportable KDC, client, and app-server will make 24 of the 64 key bits deterministic. Then an exportable app-server can tell when an AP-REQ contains a weakened key, but older clients should work fine. If we introduce new keytypes and etypes for 40-bit DES then a we'd have to worry about supporting legacy clients. 2) Go ahead and create new keytypes and etypes for 40-bit DES. All new exportable clients that understand this won't have any problem. And the exportable KDC would need to respond to a legacy client using one of the 56-bit DES etypes with 24 deterministic bits as above, but return the DES etype that the legacy client expects. Of course this is a sensitive issue and there are varying opinions about the appropriate forum for working it out. But the reality is that there is a lot of 40-bit DES in many commercial products, just like 56-bit DES and 112-bit 3DES. Ideally there would be some general way to handle all of these. Dave Margrave From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 10 09:50:45 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA12959; Tue, 10 Mar 98 09:50:45 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA04081 for cat-ietf-redist; Tue, 10 Mar 1998 09:01:38 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211103@exna01.securitydynamics.com> From: "Linn, John" To: "cat-ietf@MIT.EDU" Subject: RE: Exportable encryption & Kerberos Date: Tue, 10 Mar 1998 09:03:29 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk My sense of this discussion is that it appears highly improbable for a document specifying means for sub-56-bit level keying to achieve consensus and therefore become advanceable from the WG. Given that the goal of discussion within this (or any) WG is to contribute to advanceable specifications through the IETF process, it's therefore not clear to me that proceeding with this discussion is likely to yield effective results. Were such a document (including newly-defined facilities for sub-56-level keying, in contrast, e.g., to the TLS specification's inclusion of such facilities for compatibility with widespread deployed practice) to be advanced from the WG, its acceptability would (and, I believe, appropriately should) be a matter of IETF-level policy and IESG determination, not a matter for independent determination within different WGs. I'm not sure at this moment whether there's an established higher-level precedent on this issue (but will try to find out), but consider this a broader-scope policy question than can be resolved within the CAT (or any other) WG. --jl From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 10 20:31:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA23955; Tue, 10 Mar 98 20:31:00 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id TAA26010 for cat-ietf-redist; Tue, 10 Mar 1998 19:31:14 -0500 (EST) To: David Margrave Cc: cat-ietf@mit.edu Subject: Re: Exportable encryption & Kerberos References: <35048053.6F14D9B@cybersafe.com> X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 11 Mar 1998 01:30:57 +0100 In-Reply-To: David Margrave's message of Mon, 09 Mar 1998 15:50:43 -0800 Message-Id: Lines: 47 X-Mailer: Gnus v5.4.52/Emacs 19.34 Precedence: bulk David Margrave writes: > Some possible options for discussion: Neither of these are acceptable. If you necessarily have to standardize on something it should be clear to all involved parties that a key is weak. Under no circumstances should a weakened key be used without clearly marking it as such. I suggest that some wording to this effect be added to 1510++. To move this discussion forward I propose the following. The etype of an EncryptedData is an INTEGER, which with current implementations give us a maximum of 32 bits. The possible values for this field are defined in section 8.3 "Protocol constants and associated values". I propose that this integer instead should be interpreted as a `bit-field' looking something like: specification bits -------------------- type 10 mode 10 checksum 10 weak key 1 new format 1 Type is an encryption type like DES or DES3, mode is which particular mode should be used, like CBC or CFB, and checksum is the checksum to use. Some of these values could be common to all encryption types, and other could be specific (this could be done via some internal structure in these fields). The weak key flag should be set if the key has been weakened in any way. The highest bit specifies that this is an encryption type of this new type. The new value for des3-cbc-sha1 might then be 0x80A00402, indicating checksum type 10 (SHA1), mode 1 (CBC) and encryption type 2 (DES3). This is compatible with old clients, and old KDCs (if the clients send both new new and old enctypes). This does not solve the problem of knowing which enctypes the server supports, but this is something that has to be handled by the application protocol anyway (or by something like the crude support-md5 hack in the MIT KDC). It also makes it possible to both emit and reject weak keys (either by explicitly looking at the weak key bit, or by just not recognizing the enctype). /Johan From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 10 21:28:39 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA24917; Tue, 10 Mar 98 21:28:39 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id UAA02828 for cat-ietf-redist; Tue, 10 Mar 1998 20:42:37 -0500 (EST) Date: Tue, 10 Mar 1998 20:42:33 -0500 (EST) Message-Id: <199803110142.UAA23562@luminous.mit.edu> From: Sam Hartman To: cat-ietf@MIT.EDU Subject: Ways of dealing with exportable encryption within the existing protocol. Precedence: bulk [While I agree with John that this discussion is not likely to lead to an advancable standard, I am concerned that vendors implementing their own solutions may inadvertantly cause an interoperability problem for future standards from this group. As such, I propose some mechanisms for dealing with exportable encryption that require no action from this group in order to demonstrate that standards conformance is a reasonable option.] Over the past few days, I have been thinking about how weak crypto could be added without Mike's proposed authenticator extension and have run a few ideas by other Kerberos developers. Here are some strategies for implementing weak crypto within the scope of the existing Kerberos protocol. What the Enctype Does First, it is important to realize that the enctype does not actually have to be as simple as des40-cbc-crc. In general, a Kerberos enctype can be fairly complex and can potentially choose to use a stronger algorithm for its checksum than for encryption. For example, it would be reasonable to use a 56-or-greater bit key for the checksum and to remove or leak 16 bits of the key for the encryption. In his proposed 3DES crypto system, Marc Horowitz takes this somewhat farther and actually assigns key usages to the keys, bringing the key usage type as a parameter into the encryption routines. In addition, Marc proposes a method for deriving usage keys from a primary key stored in the database and known by the principal. Because keys are derived, leaking information about one of the derived keys should ideally not compromise the primary key. In an implementation that had the key usage information available to the crypto routines, options for a weak crypto system are much more flexible. You could cause derived keys for checksums or for encryption of authentication information that did not include arbitrary user data to be strong, while making keys for app_priv messages weak. In general, you can define the weak crypto system to be as weak as necessary, but no weaker. Thus, you can use the weak system all the time in an international environment, instead of playing games using a strong crypto system when the law allows and a weak crypto system otherwise. This could simplify the Kerberos protocol interactions a lot. Simple Model for Integration The client of a KDC request specifies a set of enctypes that should be used for the encrypted parts of the response. The KDC can store along with each principal a set of keys for the enctypes that principal supports. A strong client requests all its strong enctypes followed by weak enctypes. If the server is international, the server will only have weak enctypes available for its database key,so the KDC will respond with a session key from a weak enctype. If the server is domestic, then it will have both strong and weak keys, so a strong session key will be chosen. If a weak client wants a ticket, it only requests weak enctypes. Thus, the KDC will have to respond with a weak session key. The only remaining question is how to deal with international KDCs. You may be able to convince the US government that a KDC only does authentication and not confidentiality, so that it is OK to use strong crypto; I know of at least one vendor who is currently pursuing exporting Kerberos with privacy options disabled. Assuming this is workable, then you can establish a strong connection between a US client and US server even if the KDC is outside thee US. If the government won't let you export strong crypto for the KDC, then I see no way to add security by using strong crypto between two principals within the US. Since the weak crypto system can provide all the strong authentication that the laws allow, having the KDC store which principals support strong vs weak encryption is sufficient to solve the problem of integrating weak encryption into Kerberos. However, it might be hard to add into some implementations. It would be fairly easy to add to the MIT implementation, but it may be difficult to add to other code bases. On the assumption that this strategy may be unworkable, I will look at other strategies. Authenticator Weakening In this strategy, the KDC always deals with strong keys. An authentication key used for everything up to the app_req message is always strong. The weak clients and servers are responsible for downgrading this key. In the case where the client is weak, this is fairly simple. The client chooses a weak subsession key; the server uses it. The more complex case--the case that I assume motivates Mike's option is that the client may be a strong client talking to a weak server. Without mutual authentication, there is no way of handling this case within the current protocol. However, the app_rep message allows a server to choose its own subsession key different from the one chosen by the client. Assuming that mutual authentication is always used (a reasonable requirement for many situations), then the server could simply downgrade the key if it is weak. This strategy allows any two US principals to communicate using strong encryption regardless of the location of the KDC. Conclusion There are several options for dealing with weak cryptography within the Kerberos protocol. Even if the consensus of this working group were that a weak encryption type should be standardized, changes to the Kerberos protocol are not necessary. From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 07:42:54 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05757; Wed, 11 Mar 98 07:42:54 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id GAA25470 for cat-ietf-redist; Wed, 11 Mar 1998 06:48:04 -0500 (EST) From: Martin Rex Message-Id: <199803111147.MAA21694@hw1464.wdf.sap-ag.de> Subject: Re: Ways of dealing with exportable encryption within the existing protocol. To: hartmans@mit.edu (Sam Hartman) Date: Wed, 11 Mar 1998 12:47:49 +0100 (MET) Cc: cat-ietf@mit.edu In-Reply-To: <199803110142.UAA23562@luminous.mit.edu> from "Sam Hartman" at Mar 10, 98 08:42:33 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sam Hartman wrote: > > A strong client requests all its strong enctypes followed by > weak enctypes. If the server is international, the server will only > have weak enctypes available for its database key,so the KDC will > respond with a session key from a weak enctype. If the server is > domestic, then it will have both strong and weak keys, so a strong > session key will be chosen. It was already mentioned in the previous round of the discussion that developers from North America tend to use invalid terminology. "International" versions of Kerberos will certainly have full strength crypto including 3DES confidentiality without any problems. US export-crippled software from US companies may have to restrict itself to weak crypto for confidentiality. Any standardization effort must ensure that international implementations with strong crypto can interoperate using strong crypto confidentiality with non-crippled US domestic implementations. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 08:39:20 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA06721; Wed, 11 Mar 98 08:39:20 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id HAA01850 for cat-ietf-redist; Wed, 11 Mar 1998 07:55:36 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211109@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" , "'Martin Rex'" Subject: FW: context expiration and import_context() Date: Wed, 11 Mar 1998 07:57:27 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk [I sent this to the list yesterday but it may not have made it outbound from my local mail system and I haven't seen a return copy through the list, so I'm re-Txing. Apologies if this is a duplicate for anyone.] > ---------- > From: Linn, John > Sent: Tuesday, March 10, 1998 9:36 AM > To: cat-ietf@MIT.EDU; 'Martin.Rex@sap-ag.de' > Subject: RE: context expiration and import_context() > > I think this argument seems reasonable, and propose to drop > GSS_S_CONTEXT_EXPIRED as a return value from gss_import_sec_context() > as requested. Objections or further discussion, anyone? > > --jl > > ---------- > From: Martin Rex[SMTP:martin.rex@sap-ag.de] > Reply To: Martin.Rex@sap-ag.de > Sent: Thursday, February 26, 1998 11:50 AM > To: cat-ietf@MIT.EDU > Subject: context expiration and import_context() > > I'm still looking for a modification of the required semantics > of gss_import_sec_context() regarding security context expiration. > > This only affects mechanisms like Kerberos that implement (mandatory) > security context expiration. Currently the description lists > GSS_S_CONTEXT_EXPIRED as an allowable major status code. I'd like > to see this major status code removed from gss_import_sec_context() > for similar reason(s) that I didn't want it from > gss_inquire_context(): > it severely complicates security context refresh at the application > level. > > When gss_import_sec_context() encounters an expired security context, > it should still create a context handle that can be passed to > gss_inquire_context() for examination of peers and attributes, > even though the context may no longer be valid for message protection > and unprotection calls. > > > The issue with gss_export_sec_context() is different -- although > personally, I would really like to see the possibility to transfer > expired security as well, so that the context refresh can be done in > a different process. It is not an issue for our application, but > it may be for others. For a reliable security context refresh, > one will have to check each time before *protecting* a message if > there is enough context lifetime left so that the receiver will > be able to successfully unprotect it, and attempt a security > context refresh if there's less than 5-10 minutes left or the > security context is already expired. > > -Martin > > > From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 12:40:10 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10905; Wed, 11 Mar 98 12:40:10 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA21130 for cat-ietf-redist; Wed, 11 Mar 1998 11:14:52 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F80127660121110D@exna01.securitydynamics.com> From: "Linn, John" To: cat-ietf@mit.edu, "'Martin.Rex@sap-ag.de'" Subject: RE: full-duplex message protection services Date: Wed, 11 Mar 1998 11:16:35 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Martin, all: I hadn't envisioned the prospect that a GSS-API mechanism's per-message protection services might be constructed so as to support only half-duplex communications (or, I believe, to paraphrase: that the interpretation of a mechanism's sequence number might not be qualified by the direction in which a particular message is being transferred on a context), and so am not surprised that there's no specific statement about this point in 2078bis. My personal preference would be to eliminate the ambiguity with a statement in 1.1.3 (Security Contexts) of the form, "Messages may be protected and transferred in both directions on a GSS-API security context concurrently; protection of messages in one direction does not interfere with protection of messages in the reverse direction", but Martin's experience suggests that at least one mechanism implementation has not assumed this interpretation. At this point, I can see three choices, and solicit comment from the WG: (1) Introduce a requirement for concurrent protection in both directions (2) State that mechanism definitions should identify whether or not their mechanisms support concurrent protection in both directions (3) Add no explicit statement on the issue It seems to me that the absence of any statement about this topic is a defect which should desirably be reconciled in some way, so I'd recommend against (3). Given possible impact to implementors, however, I don't believe it would be appropriate to incorporate (1) without strong demonstrated consensus of interested WG members; if no such strong consensus becomes visibly apparent, I propose to include a statement per (2). Discussion? --jl > ---------- > From: Martin Rex[SMTP:martin.rex@sap-ag.de] > Reply To: Martin.Rex@sap-ag.de > Sent: Thursday, March 05, 1998 5:04 PM > To: cat-ietf@mit.edu > Subject: full-duplex message protection services > > I was recently surprised when I tried to use protect a full duplex > communication between to peers with gssapi message protection services > and the gssapi mechanism constantly returned verification errors from > the > message unprotection calls. > > There is no explicit "full-duplex requirement" in any of the gssapi > documents, HOWEVER, there is also NO side effect or restriction > mentioned > for the message protection calls (gss_wrap,gss_get_mic) that would > require an application to limit itself to half-duplex communication. > Therefore I consider a gssapi mechanism that is limited to half-duplex > message protection services incompliant with both specs (v1/v2). > > The two pitfalls for a hasty gssapi mechanism designer that come > to my mind are (1) using a single sequence number for both directions > and (2) using a stream cipher (like RC4) and a single keystream > for both directions. (OTOH, using another instance of the same > keystream could likely support full-duplex, but would open > a severe vulnerability...) > > > Although I think the full-duplex message protection is implied by > the specification of the message protection calls, a short explicit > notice in rfc2078bis, either "Section 1.1.3 Security Contexts", par 2 > or 3 > and/or Section 1.2.2/1.2.3. Comments? Proposals? (1or2 sentences) > > > If I read the spec correctly, TLS avoids this problem by using > different keys for both directions -- independent of the cryptographic > algorithms that are used. > > > rfc2078bis is currently in WG last call, and I really want to see > the document advance, so if the sense of the WG is that the implicit > requirement is sufficient -- oh well, then I will accept it. > > > Checking for full-duplex is rather easy: > establish a security context with yourself and first call > gss_wrap() once for each (acceptor, initiator) context with > a different(!) message and after that gss_unwrap() for each > of the two tokens on the respective peer context. > > -Martin > From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 15:33:52 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA13816; Wed, 11 Mar 98 15:33:52 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA09685 for cat-ietf-redist; Wed, 11 Mar 1998 14:11:44 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F80127660121110F@exna01.securitydynamics.com> From: "Linn, John" To: CAT-IETF WG , "'Denis.Pinkas@bull.net'" Subject: CAT-WG Final-Call: draft-ietf-cat-snego-08.txt [Was: RE: SPNEGO-8] Date: Wed, 11 Mar 1998 12:00:06 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk With this message, I'll place the recently revised draft-ietf-cat-snego-08.txt into a 2-week CAT-WG Final-Call (one or more predecessor drafts having already been through WG Last-Call), to extend through Wednesday, 25 March, anticipating subsequent submission to the IESG with a WG recommendation for advancement to Proposed Standard. If anyone has comments to be made about recent changes to the document, or on their sufficiency to reconcile the issue identified in the DC CAT minutes as then-pending, please make them within this period. Thanks, regards, ... --jl > ---------- > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > Reply To: Denis.Pinkas@bull.net > Sent: Monday, March 09, 1998 11:38 AM > To: CAT-IETF WG > Subject: SPNEGO-8 > > I have edited the SPNEGO document and made some changes to it: > > 1) preferredToken has been changed to mechToken, since this field now > carries mechanism tokens and not only the initial preferred token, as > it > was originally the case. > > 2) Since the status GSS_S_BAD_SIG is defined, it is now used when a > MIC > is incorrect or missing (instead of GSS_S_BAD_MECH). > > 3) Additional explanations have been added here or there. > > The document can be downloaded at: > > ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-08.txt > > If changes are necessary, please provide alternative text and the > rational. > > Denis > > > -- > *** Please note that the E-mail address has changed ! Update it. > *** > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 > From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 16:38:09 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA14981; Wed, 11 Mar 98 16:38:09 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA13321 for cat-ietf-redist; Wed, 11 Mar 1998 14:49:10 -0500 (EST) Message-Id: From: "Mike Swift (NT)" To: joda@pdc.kth.se, David Margrave Cc: cat-ietf@mit.edu Subject: RE: Exportable encryption & Kerberos Date: Wed, 11 Mar 1998 11:49:02 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Precedence: bulk This is the approach I'm currently taking - I've defined a bit in the key type to indicate that it is a weak key. Rather than introducing new encryption types, I prefer the approach of introducing a new key type that indicates that the key is weak. I tend to think that introducing new encryption types isn't necessary - just a new keytype indicating that the key is weak. As Sam points out, we also need to define the semantics associated with weak keys. If the client proposes a weak key, the server needs to either respond with the same weak key or fail the connection. Otherwise the client can't be assured that the server is using a weak key. If the server proposes a weak key, the client needs to either use that key or fail the connection. - Mike -----Original Message----- From: joda@pdc.kth.se [mailto:joda@pdc.kth.se] Sent: Tuesday, March 10, 1998 4:31 PM To: David Margrave Cc: cat-ietf@mit.edu Subject: Re: Exportable encryption & Kerberos David Margrave writes: > Some possible options for discussion: Neither of these are acceptable. If you necessarily have to standardize on something it should be clear to all involved parties that a key is weak. Under no circumstances should a weakened key be used without clearly marking it as such. I suggest that some wording to this effect be added to 1510++. To move this discussion forward I propose the following. The etype of an EncryptedData is an INTEGER, which with current implementations give us a maximum of 32 bits. The possible values for this field are defined in section 8.3 "Protocol constants and associated values". I propose that this integer instead should be interpreted as a `bit-field' looking something like: specification bits -------------------- type 10 mode 10 checksum 10 weak key 1 new format 1 Type is an encryption type like DES or DES3, mode is which particular mode should be used, like CBC or CFB, and checksum is the checksum to use. Some of these values could be common to all encryption types, and other could be specific (this could be done via some internal structure in these fields). The weak key flag should be set if the key has been weakened in any way. The highest bit specifies that this is an encryption type of this new type. The new value for des3-cbc-sha1 might then be 0x80A00402, indicating checksum type 10 (SHA1), mode 1 (CBC) and encryption type 2 (DES3). This is compatible with old clients, and old KDCs (if the clients send both new new and old enctypes). This does not solve the problem of knowing which enctypes the server supports, but this is something that has to be handled by the application protocol anyway (or by something like the crude support-md5 hack in the MIT KDC). It also makes it possible to both emit and reject weak keys (either by explicitly looking at the weak key bit, or by just not recognizing the enctype). /Johan From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 11 17:34:59 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15966; Wed, 11 Mar 98 17:34:59 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA22783 for cat-ietf-redist; Wed, 11 Mar 1998 16:24:06 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211116@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Cc: "'agenda@ietf.org'" Subject: CAT-WG LA Agenda, Draft 1 Date: Wed, 11 Mar 1998 16:25:48 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk CAT-WG LA Agenda, Draft 1 as of 11 March 1998 Here's a Draft 1 agenda for the CAT LA meetings; requests for changes or additional topics are welcome. I'll look to document editors or their designees (hereby offering thanks in advance) to lead needed discussion of their respective drafts, summarizing recent changes, resolutions for previously-identified issues, and currently active issues relevant to the drafts as appropriate. Meeting slots: Monday, 30 March, 1300-1500: 1300-1310: Opening discussion WG Last-Call reviews: discussion to clear issues if needed and confirm actions (cited subslots may run short if feasible): - 1310-1330: rfc2078bis-03 - 1330-1350: spnego-08 - 1350-1400: ftpdsaauth-03, ftpkeasj-00 Other drafts pending revision and with discussion requests: - 1400-1420: kerberos-revisions-xx - 1420-1440: pk-init-xx - 1440-1500: pk-cross-xx Tuesday, 31 March, 1015-1115: 1015-1025: pk-recovery 1025-1115: continuing discussion and/or other topics as needed --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 12 04:46:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27546; Thu, 12 Mar 98 04:46:23 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id DAA22803 for cat-ietf-redist; Thu, 12 Mar 1998 03:33:12 -0500 (EST) Message-Id: <199803120915.JAA07866@ns0.zergo.com> From: Graham Bland Date: Thu, 12 Mar 1998 8:34:19 +0000 To: cat-ietf@mit.edu Subject: RE:full-duplex message protection Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id DAA22801 Precedence: bulk All: John Linn wrote >At this >point, I can see three choices, and solicit comment from the WG: > >(1) Introduce a requirement for concurrent protection in both directions > >(2) State that mechanism definitions should identify whether or not >their mechanisms support concurrent protection in both directions > >(3) Add no explicit statement on the issue > >It seems to me that the absence of any statement about this topic is a >defect which should desirably be reconciled in some way, so I'd >recommend against (3). Given possible impact to implementors, however, >I don't believe it would be appropriate to incorporate (1) without >strong demonstrated consensus of interested WG members; if no such >strong consensus becomes visibly apparent, I propose to include a >statement per (2). Discussion? May I suggest a combination of (2) and (1) It is recommended that mechanisms support full duplex operation, mechanism definitions should identify whether or not their mechanisms support concurrent protection in both directions. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 12 06:34:46 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA29347; Thu, 12 Mar 98 06:34:46 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id FAA01002 for cat-ietf-redist; Thu, 12 Mar 1998 05:12:07 -0500 (EST) From: Martin Rex Message-Id: <199803121011.LAA25838@hw1464.wdf.sap-ag.de> Subject: Re: full-duplex message protection services To: jlinn@securitydynamics.com (Linn John) Date: Thu, 12 Mar 1998 11:11:53 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <6B5344C210C7D011835C0000F80127660121110D@exna01.securitydynamics.com> from "Linn, John" at Mar 11, 98 11:16:35 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Linn, John wrote: > > (1) Introduce a requirement for concurrent protection in both directions > > (2) State that mechanism definitions should identify whether or not > their mechanisms support concurrent protection in both directions > > (3) Add no explicit statement on the issue Since I personally think (1) has always been there implicitly, I mainly wanted to find out if there is actually a significant installed base of half-duplex restricted mechanisms that is actively used and can not be fixed/migrated. There is no rocket-science involved in making a gssapi mechanism capable of full-duplex message protection, so personally I really don't like to see the mandatory-to-implement usability lowered by that much just for the sake of the fun of it. For the one mech that I encountered with this restriction, it has been acknowledged as an (unintentional) defect. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 12 09:53:10 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA02866; Thu, 12 Mar 98 09:53:10 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA20945 for cat-ietf-redist; Thu, 12 Mar 1998 08:35:19 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211117@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Subject: rfc2078bis-03: observed misalignment, proposed defect resolution Date: Thu, 12 Mar 1998 08:37:04 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk CAT/2078bis fanciers: It was pointed out to me that rfc2078bis-03's description of gss_wrap_size_limit() is misaligned with the C bindings' call signature for this routine: rfc2078bis-03 doesn't specify an input conf_req_flag, but the C bindings do. I believe that this is useful and appropriate input information to the size determination operation, and hereby propose to add this parameter to the description in 2078bis, thereby aligning with the C bindings. Any objections? --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 12 10:43:43 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03737; Thu, 12 Mar 98 10:43:43 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA23431 for cat-ietf-redist; Thu, 12 Mar 1998 09:02:27 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211119@exna01.securitydynamics.com> From: "Linn, John" To: "cat-ietf@MIT.EDU" Subject: RE: Exportable encryption & Kerberos Date: Thu, 12 Mar 1998 09:04:18 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk I wrote, excerpting: > I'm not sure at this moment whether there's an > established higher-level precedent on this issue (but will try to find > out), but consider this a broader-scope policy question than can be > resolved within the CAT (or any other) WG. > I checked with Jeff Schiller, the Security AD, on this question. He pointed out that there's been a premise informally called the Danvers Doctrine, dating back to the plenary session at the IETF meeting held at that location in April 1995, establishing a general principle that the IETF will not standardize facilities for "export-grade" cryptography. Also, RFC-1984 sets out the IAB/IESG position on several cryptographically-related policy topics, including but not limited to this issue. --jl From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 12 15:42:16 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08956; Thu, 12 Mar 98 15:42:16 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA28269 for cat-ietf-redist; Thu, 12 Mar 1998 14:49:14 -0500 (EST) Date: Thu, 12 Mar 1998 14:48:54 -0500 Message-Id: <199803121948.OAA23712@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Martin.Rex@sap-ag.de Cc: jlinn@securitydynamics.com, cat-ietf@mit.edu In-Reply-To: Martin Rex's message of Thu, 12 Mar 1998 11:11:53 +0100 (MET), <199803121011.LAA25838@hw1464.wdf.sap-ag.de> Subject: Re: full-duplex message protection services Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Martin Rex Date: Thu, 12 Mar 1998 11:11:53 +0100 (MET) Since I personally think (1) has always been there implicitly, I mainly wanted to find out if there is actually a significant installed base of half-duplex restricted mechanisms that is actively used and can not be fixed/migrated. I agree with Martin. The requirement for concurrent processing has always been in the draft, however implicitly. My impression is that there isn't an installed base of half-duplex restricted mechanisms, so my preference would be to make this requirement explicit instead of implicit. There is no rocket-science involved in making a gssapi mechanism capable of full-duplex message protection, so personally I really don't like to see the mandatory-to-implement usability lowered by that much just for the sake of the fun of it. For the one mech that I encountered with this restriction, it has been acknowledged as an (unintentional) defect. Agreed. That mech wasn't technically really a GSSAPI mechanism anyway, right? So it hardly counts... - Ted From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 16 09:39:30 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA12297; Mon, 16 Mar 98 09:39:30 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA11081 for cat-ietf-redist; Mon, 16 Mar 1998 08:42:24 -0500 (EST) Message-Id: <199803161340.IAA15143@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-kerb-chg-password-01.txt Date: Mon, 16 Mar 1998 08:40:59 -0500 Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Kerberos Change Password Protocol Author(s) : M. Horowitz Filename : draft-ietf-cat-kerb-chg-password-01.txt Pages : 4 Date : 13-Mar-98 The Kerberos V5 protocol [RFC1510] does not describe any mechanism for users to change their own passwords. In order to promote interoperability between workstations, personal computers, terminal servers, routers, and KDC's from multiple vendors, a common password changing protocol is required. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerb-chg-password-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19980313133808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerb-chg-password-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313133808.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 17 11:51:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10649; Tue, 17 Mar 98 11:51:23 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA08541 for cat-ietf-redist; Tue, 17 Mar 1998 10:15:41 -0500 (EST) Message-Id: <199803171515.KAA02333@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-06.txt Date: Tue, 17 Mar 1998 10:15:24 -0500 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) : C. Neuman, J. Wray, B. Tung, J. Trostle, M. Hur, A. Medvinsky Filename : draft-ietf-cat-kerberos-pk-init-06.txt Pages : 15 Date : 16-Mar-98 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. Internet-Drafts are 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-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980316140815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-init-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316140815.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 17 12:37:55 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11430; Tue, 17 Mar 98 12:37:55 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA08544 for cat-ietf-redist; Tue, 17 Mar 1998 10:15:41 -0500 (EST) Message-Id: <199803171515.KAA02372@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-cross-04.txt Date: Tue, 17 Mar 1998 10:15:30 -0500 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Cross-Realm Authentication in Kerberos Author(s) : G. Tsudik, C. Neuman, B. Sommerfeld, B. Tung, M. Hur, T. Ryutov, A. Medvinsky Filename : draft-ietf-cat-kerberos-pk-cross-04.txt Pages : 5 Date : 16-Mar-98 This document defines extensions to the Kerberos protocol specification (RFC 1510, ''The Kerberos Network Authentication Service (V5)'', September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-pk-cross-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-cross-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-04.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: <19980316141200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-cross-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316141200.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 17 13:00:11 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA11793; Tue, 17 Mar 98 13:00:11 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA08381 for cat-ietf-redist; Tue, 17 Mar 1998 10:14:10 -0500 (EST) Message-Id: <199803171514.KAA01955@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-idup-gss-10.txt Date: Tue, 17 Mar 1998 10:14:00 -0500 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 : Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) Author(s) : C. Adams Filename : draft-ietf-cat-idup-gss-10.txt Pages : 61 Date : 16-Mar-98 The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated ''receivers'' of the data unit. Thus, it is suitable for applications such as secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. The protection offered by IDUP includes services such as data origin authentication with data integrity, data confidentiality with data integrity, and support for non-repudiation services. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed (''unprotected'') only days or years later. Throughout the remainder of this document, the ''unit'' of data described in the above paragraph will be referred to as an IDU (Independent Data Unit). The IDU can be of any size (the application may, if it wishes, split the IDU into pieces and have the protection computed a piece at a time, but the resulting protection token applies to the entire IDU). However, the primary characteristic of an IDU is that it represents a stand-alone unit of data whose protection is entirely independent of any other unit of data. If an application protects several IDUs and sends them all to a single receiver, the IDUs may be unprotected by that receiver in any order over any time span; no logical connection of any kind is implied by the protection process itself. Internet-Drafts are 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-idup-gss-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-idup-gss-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-idup-gss-10.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: <19980316131923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-idup-gss-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-idup-gss-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980316131923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 17 14:35:27 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA13491; Tue, 17 Mar 98 14:35:27 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA26438 for cat-ietf-redist; Tue, 17 Mar 1998 13:17:12 -0500 (EST) Message-Id: <199803171816.NAA11887@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-kerb-chg-password-01.txt Date: Tue, 17 Mar 1998 13:16:34 -0500 Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Kerberos Change Password Protocol Author(s) : M. Horowitz Filename : draft-ietf-cat-kerb-chg-password-01.txt Pages : 4 Date : 13-Mar-98 The Kerberos V5 protocol [RFC1510] does not describe any mechanism for users to change their own passwords. In order to promote interoperability between workstations, personal computers, terminal servers, routers, and KDC's from multiple vendors, a common password changing protocol is required. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerb-chg-password-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19980313133808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerb-chg-password-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313133808.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 17 16:36:45 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15561; Tue, 17 Mar 98 16:36:45 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA08956 for cat-ietf-redist; Tue, 17 Mar 1998 15:21:06 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211137@exna01.securitydynamics.com> From: "Linn, John" To: "Martin.Rex@sap-ag.de" , "'Ted Ts'o'" Cc: "Linn, John" , "cat-ietf@MIT.EDU" Subject: RE: full-duplex message protection services Date: Tue, 17 Mar 1998 15:22:57 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk Ted wrote, replying to Martin: > From: Martin Rex > Date: Thu, 12 Mar 1998 11:11:53 +0100 (MET) > > Since I personally think (1) has always been there implicitly, > I mainly wanted to find out if there is actually a significant > installed > base of half-duplex restricted mechanisms that is actively used and > can > not be fixed/migrated. > > I agree with Martin. The requirement for concurrent processing has > always been in the draft, however implicitly. My impression is that > there isn't an installed base of half-duplex restricted mechanisms, so > my preference would be to make this requirement explicit instead of > implicit. > I've now heard three commentators preferring a requirement for concurrent protection in both directions (Martin, Ted, and my own comment (wearing personal hat as individual, not as document editor) earlier on the thread); it has also been asserted that such a requirement has been assumed implicitly. Before Martin's and Ted's messages (at least in the order they arrived at my desktop), Graham Bland had also suggested upgrading the statement, but to the level of recommendation rather than requirement, also stating that mechanism definitions should specify whether or not concurrent protection is provided. Given this discussion, I'll now revise my proposed approach towards closure. Absent further debate, I suggest that we adopt the requirement. If anyone comments to the list that this appears too strong, we'll step to Graham's intermediate recommendation instead. Discussion? --jl From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 18 10:51:16 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA04974; Wed, 18 Mar 98 10:51:16 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA22556 for cat-ietf-redist; Wed, 18 Mar 1998 09:47:20 -0500 (EST) Message-Id: <199803181447.JAA26981@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ns.ietf.org Reply-To: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-cat-pktapp-01.txt Date: Wed, 18 Mar 1998 09:47:12 -0500 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 Utilizing Tickets for Application Servers (PKTAPP) Author(s) : C. Neuman, M. Hur, A. Medvinsky, A. Medvinsky Filename : draft-ietf-cat-pktapp-01.txt Pages : 5 Date : 17-Mar-98 Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. Internet-Drafts are 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-pktapp-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-pktapp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-pktapp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980317162931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-pktapp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-pktapp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980317162931.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 06:31:34 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA25680; Thu, 19 Mar 98 06:31:34 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id FAA12037 for cat-ietf-redist; Thu, 19 Mar 1998 05:32:17 -0500 (EST) Message-Id: <199803191116.LAA23801@ns0.zergo.com> From: Graham Bland Date: Thu, 19 Mar 1998 10:33:37 +0000 To: cat-ietf@mit.edu Subject: full-duplex message protection Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id FAA12035 Precedence: bulk Let me expand on the reasoning for my suggestion that a recommendation be made regarding full duplex use. I quote from the abstract "The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms" Why should the framework define mechanism behaviour which has nothing to do with the security services provided. There are many aspects of mechanism behaviour which could be mandated, however I believe there are very few that should as this reduces the appeal of the generic framework that GSS provides. Interoperability is only provided when a mechanism is shared between callers. If this is to work then a detailed mechanism design must be developed and implemented which must address issues like this. Really it boils down to, If I want to want to implement a half duplex based mechanism, why can't I. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 08:31:09 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27760; Thu, 19 Mar 98 08:31:09 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id HAA20498 for cat-ietf-redist; Thu, 19 Mar 1998 07:03:14 -0500 (EST) Message-Id: <199803191247.MAA23940@ns0.zergo.com> From: Graham Bland Date: Thu, 19 Mar 1998 12:04:28 +0000 To: cat-ietf@MIT.EDU Subject: IDUP-GSS idup_name_set definition Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id HAA20496 Precedence: bulk idup_name_set is defined as typedef struct idup_name_set_desc_struct { int count ; gss_name_t elements ; } idup_name_set_desc, *idup_name_set; Where gss_name_t is an implementation defined type. This definition does not work for all definitions of gss_name_t. In particular it will not work for any which are either not pointer types or where the sizeof() operator does not evaluate to a constant. For binary compatibility only, GSS imposes the restriction that it should be a pointer type (Section B.4) and discourages, but does not preclude the use of void*. For source compatibility, GSS does not impose any restriction on the implementation of gss_name_t. With a rather simplistic view of the implementation of gss_name_t (e.g. precluding opaque types, non-pointers, void *, derived classes and extensible structures), the above would work. However I don't believe that this restriction is intentional, nor practical. We would probably implement gss_name_t as a pointer to an opaque type and thus you cannot apply the sizeof() operator to it. In particular, expressions such as elements[1] cannot correctly be evaluated since the sizeof(elements[0]) would depend on the actual implementation the type. Additionally we would not be able to expose the implementation as it is C++ specific and would not compile in C. I suggest therefore re-defining idup_name_set as typedef struct idup_name_set_desc_struct { int count ; gss_name_t* elements ; } idup_name_set_desc, *idup_name_set; This should not have a significant impact on source level compatibility, since most of the manipulation of name sets is via API functions (idup_add_name_set_member etc). Obviously this would have implications for idup_release_name() and idup_release_name_content() The other choice is to implement gss_name_t as a double pointer, but this would impose an, otherwise unnecessary, overhead in development, execution, and maintenance. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 09:33:52 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA28818; Thu, 19 Mar 98 09:33:52 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA28924 for cat-ietf-redist; Thu, 19 Mar 1998 08:33:48 -0500 (EST) Message-Id: <199803191417.OAA24038@ns0.zergo.com> From: Graham Bland Date: Thu, 19 Mar 1998 13:35:01 +0000 To: cat-ietf@MIT.EDU Subject: IDUP: get_token_details for unknown valu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id IAA28922 Precedence: bulk Get token details is described as returning the OID of the of the mechanism which constructed the token (in particular, if the token is framed using the Mechanism Independent Token format, it should be able to return the mechanism OID even if the mechanism is not supported by this implementation). However OIDs are "... read-only. In particular, the application should not attempt to deallocate them with free()." Everywhere else, for an OID to be returned, the framework will inherently have an internal constant OID to which a pointer can be returned. This poses no memory management issues. However, in the case of get_token_details for an unsupported mechanism, no internal constant OID exists. I suggest that this be modified to return an OID set (with a single element) which can be dynamically released. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 10:45:55 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00207; Thu, 19 Mar 98 10:45:55 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA06757 for cat-ietf-redist; Thu, 19 Mar 1998 09:54:16 -0500 (EST) Message-Id: <199803191538.PAA24104@ns0.zergo.com> From: Graham Bland Date: Thu, 19 Mar 1998 14:55:34 +0000 To: cat-ietf@mit.edu Subject: IDUP: idup_get_policy_info usage Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id JAA06754 Precedence: bulk Calling idup_get_policy_info in a multi mechanism environment will result in a set of mechanisms each implementing one or more services. As the services returned are independent of the set of Mechanism_Descriptors should the services be the union or intersection of the services provided by the mechanisms? Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 11:45:32 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA01217; Thu, 19 Mar 98 11:45:32 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA06466 for cat-ietf-redist; Thu, 19 Mar 1998 09:50:49 -0500 (EST) From: Martin Rex Message-Id: <199803191449.PAA25834@hw1464.wdf.sap-ag.de> Subject: Re: full-duplex message protection To: gbland@zergo.com (Graham Bland) Date: Thu, 19 Mar 1998 15:49:11 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <199803191116.LAA23801@ns0.zergo.com> from "Graham Bland" at Mar 19, 98 10:33:37 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Graham Bland wrote: > > Let me expand on the reasoning for my suggestion that a recommendation be > made regarding full duplex use. > > Why should the framework define mechanism behaviour which has nothing to do > with the security services provided. Because we want to make it useful. Look, all of the transport protocols defined by the IETF are full duplex; how could we convince application programmers to use security protocols in their applications if this would seriously impact and restrict their communication paradigms. Really, if we don't want to get a really bad reputation in the IETF, we either leave it as it is or add an explicit requirement for full-duplex. > > There are many aspects of mechanism behaviour which could be mandated, > however I believe there are very few that should as this reduces the appeal > of the generic framework that GSS provides. > Interoperability is only provided when a mechanism is shared between > callers. If this is to work then a detailed mechanism design must be > developed and implemented which must address issues like this. > > Really it boils down to, If I want to want to implement a half duplex based > mechanism, why can't I. Noone is keeping you from doing it. It will just not be called rfc-2xxx -compliant (whatever rfc2078bis will be). We're not outlawing a half-duplex mechanism by mandating full-duplex in the spec, we just set a certain level of usability for compliant gssapi mechanisms. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 12:46:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA02349; Thu, 19 Mar 98 12:46:23 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA14019 for cat-ietf-redist; Thu, 19 Mar 1998 11:04:52 -0500 (EST) Message-Id: <199803191649.QAA24191@ns0.zergo.com> From: Graham Bland Date: Thu, 19 Mar 1998 16:06:16 +0000 To: cat-ietf@mit.edu Subject: Re: full-duplex message protection Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id LAA14017 Precedence: bulk Martin wrote: I think you are missing my point somewhat, I am not arguing about the specification of duplex or half duplex. (In fact I would not think of implementing a half duplex mechanism unless I had a compelling reason not to) but that having defined as one of the basic goals of the GSS API as protocol independence, and achieved a very good split between the API framework and the mechanisms why start making statements about mandatory mechanism behavior no matter what they are. I could suggest that we could make the API more useful by defining all sorts of things that a mechanism should and should not do but only by sacrificing the flexibility of the API both for now and in the future. > >Graham Bland wrote: >> >> Let me expand on the reasoning for my suggestion that a recommendation be >> made regarding full duplex use. >> >> Why should the framework define mechanism behaviour which has nothing to do >> with the security services provided. > >Because we want to make it useful. Look, all of the transport protocols >defined by the IETF are full duplex; how could we convince application >programmers to use security protocols in their applications if this would >seriously impact and restrict their communication paradigms. > It doesn't restrict them at all 1. they can only use security protocols using GSS with the implementation of a security mechanism, this must be selected by the default implementation or specifically by the application programmer and must be appropriate for the purpose for which it is to be used. 2. I see no restriction in GSS mandating the use of IETF defined transport protocols > >Really, if we don't want to get a really bad reputation in the IETF, >we either leave it as it is or add an explicit requirement for full-duplex. > >> >> There are many aspects of mechanism behaviour which could be mandated, >> however I believe there are very few that should as this reduces the appeal >> of the generic framework that GSS provides. >> Interoperability is only provided when a mechanism is shared between >> callers. If this is to work then a detailed mechanism design must be >> developed and implemented which must address issues like this. >> >> Really it boils down to, If I want to want to implement a half duplex based >> mechanism, why can't I. > >Noone is keeping you from doing it. It will just not be called >rfc-2xxx -compliant (whatever rfc2078bis will be). > I did mean within the context of rfc2078bis. Lots of things fall outside the scope of the standard, I still see no viable reason for forbidding it as long as the application developer knows what he or she is getting. > >We're not outlawing a half-duplex mechanism by mandating full-duplex >in the spec, we just set a certain level of usability for compliant >gssapi mechanisms. > If you mandate behaviour in a mechanism and a mechanism does not meet the test then it is outlawed otherwise what is the point. Example: Server application wishes to identify a user on a client machine, this is achieved by a challenge/response. This is to operate as a mechanism within GSS called via the GSS API. I wont detail the flows but they are entirely sequential i.e. half duplex. If implemented as such by the application and mechanism designers and developers is this compliant with rfc2078bis. or should it be outlawed. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 13:43:27 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03304; Thu, 19 Mar 98 13:43:27 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA25221 for cat-ietf-redist; Thu, 19 Mar 1998 12:53:37 -0500 (EST) Date: Thu, 19 Mar 1998 12:53:24 -0500 Message-Id: <199803191753.MAA26544@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Graham Bland Cc: cat-ietf@MIT.EDU In-Reply-To: Graham Bland's message of Thu, 19 Mar 1998 10:33:37 +0000, <199803191116.LAA23801@ns0.zergo.com> Subject: Re: full-duplex message protection Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Graham Bland Date: Thu, 19 Mar 1998 10:33:37 +0000 Really it boils down to, If I want to want to implement a half duplex based mechanism, why can't I. Because someone who writes an application which uses full-duplex messaging will break when they link against your mechanism. The whole point of the GSSAPI is to provide a set of services where an application writer doesn't need to worry about the vagrancies of a particular security system's implementation. Given that the difference between implementing a this correctly and incorrectly is keeping an extra 4-byte variable (so that you keep track of sequence numbers in both directions, not just one), mandating a standard behaviour for mechanisms which application writers can count on seems like a good thing to me. - Ted From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 19 14:36:51 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA04268; Thu, 19 Mar 98 14:36:51 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA01571 for cat-ietf-redist; Thu, 19 Mar 1998 13:54:26 -0500 (EST) From: Martin Rex Message-Id: <199803191852.TAA27098@hw1464.wdf.sap-ag.de> Subject: Re: full-duplex message protection To: gbland@zergo.com (Graham Bland) Date: Thu, 19 Mar 1998 19:52:48 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <199803191649.QAA24191@ns0.zergo.com> from "Graham Bland" at Mar 19, 98 04:06:16 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Graham Bland wrote: > > >> however I believe there are very few that should as this reduces the > appeal > >> of the generic framework that GSS provides. > >> Interoperability is only provided when a mechanism is shared between > >> callers. If this is to work then a detailed mechanism design must be > >> developed and implemented which must address issues like this. > >> > >> Really it boils down to, If I want to want to implement a half duplex > based > >> mechanism, why can't I. > > > >Noone is keeping you from doing it. It will just not be called > >rfc-2xxx -compliant (whatever rfc2078bis will be). > > > I did mean within the context of rfc2078bis. Lots of things fall outside > the scope of the standard, I still see no viable reason for forbidding it > as long as the application developer knows what he or she is getting. That is actually the point, the application developer wouldn't know right now. The only "clean" way to permit (IMHO flawed) half duplex message protection restrictions is to add a context-flag that will be returned from initiate_sec_context()/accept_sec_context(). This would have to be added to SPNEGO as well, of course -- otherwise the half-duplex stuff wouldn't scale anyway. However I consider adding such a flag completely out-of-scope for our GSS-API v2. Really, right now a gssapi mechanism with half-duplex message protection is a landmine. Many protocols are full-duplex by design, but operate half duplex most of the time. There such a problem wouldn't show up immediately -- in the worst case it would show up "randomly". > > > > >We're not outlawing a half-duplex mechanism by mandating full-duplex > >in the spec, we just set a certain level of usability for compliant > >gssapi mechanisms. > > > > If you mandate behaviour in a mechanism and a mechanism does not meet the > test then it is outlawed otherwise what is the point. Than your test is broken, because it doesn't test for the requirements of *YOUR* special application, but for a non-related piece of paper. > > Server application wishes to identify a user on a client machine, this is > achieved by a challenge/response. This is to operate as a mechanism within > GSS called via the GSS API. > I wont detail the flows but they are entirely sequential i.e. half duplex. > If implemented > as such by the application and mechanism designers and developers is this > compliant with rfc2078bis. or should it be outlawed. The topic of our discussion was half-duplex *message protection*. Your confusing security context establishment and message protection. Security context establishment has always been documented as a handshake of atomic context-level tokens, which means it is half-duplex. Note however, that we have "cleanly" defined the possibility of interleaving security context establishment with message protection when this request came up (around Stockholm IETF, July 1995) from Bob Blakley. Making assumptions as an application programmer or using meta knowledge about the characteristics of a specific implementation is a bad idea for the specification of a *standard*. I really don't like to continue a religious war here. The task of the working group is to come up with a useful standard. If we lower the applicability of the standard without strong *technical* necessity, then we're failing our task. As I said in my first mail: I can accept the document as it is, but I am strongly opposed to blessing a restriction that I personally consider flawed. I haven't seen any valid technical issues against an explicit full-duplex requirement on the list so far, and I have neither seen any proof of a large installed based that we would break. Really -- this addition will NOT BREAK anything, it will just deny rubber-stamping (i.e. the "compliance" tag). -Martin From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 20 15:38:43 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00270; Fri, 20 Mar 98 15:38:43 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA19748 for cat-ietf-redist; Fri, 20 Mar 1998 14:27:11 -0500 (EST) Date: Fri, 20 Mar 1998 14:27:06 -0500 Message-Id: <199803201927.OAA26926@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Graham Bland Cc: cat-ietf@mit.edu In-Reply-To: Graham Bland's message of Thu, 19 Mar 1998 12:04:28 +0000, <199803191247.MAA23940@ns0.zergo.com> Subject: Re: IDUP-GSS idup_name_set definition Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Graham Bland Date: Thu, 19 Mar 1998 12:04:28 +0000 We would probably implement gss_name_t as a pointer to an opaque type and thus you cannot apply the sizeof() operator to it. In particular, expressions such as elements[1] cannot correctly be evaluated since the sizeof(elements[0]) would depend on the actual implementation the type. Err... no. A pointer to an incomplete type is a complete type. Hence, you can take the sizeof() a pointer to an opaque type. The ANSI C specification only defines two sorts of types as being incomplete types, and they are arrays and structures with certain characteristics (indefinite length, being an undefined structure, or containing an undefined structure). A pointer is not one of those sorts of types. If you think about this, this makes sense. All pointers must be castable in and out of a void *, so pointers can't be arbitrarily large, even assuming you were working on some broken architecture where the sizeof of a pointer to a short was different from the sizeof a pointer to a structure, or something similarly insane.... - Ted From owner-cat-ietf@pad-thai.cam.ov.com Sun Mar 22 00:34:14 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA04655; Sun, 22 Mar 98 00:34:14 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id XAA20933 for cat-ietf-redist; Sat, 21 Mar 1998 23:10:34 -0500 (EST) Message-Id: X-Ms-Tnef-Correlator: From: "Odom, Jeff" To: "'tytso@mit.edu'" , "'gbland@zergo.com'" Cc: "'cat-ietf@mit.edu'" Subject: Re: IDUP-GSS idup_name_set definition Date: Sat, 21 Mar 1998 20:11:43 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD5504.C36EA380" Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD5504.C36EA380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Graham Bland > > Date: Thu, 19 Mar 1998 >12:04:28 +0000 > > We would probably >implement gss_name_t as a >pointer to an opaque type >and > thus you cannot apply the >sizeof() operator to it. In >particular, > expressions such as >elements[1] cannot >correctly be evaluated since >the > sizeof(elements[0]) would >depend on the actual >implementation the type. > >Err... no. A pointer to an >incomplete type is a >complete type. Hence, >you can take the sizeof() a >pointer to an opaque type. >The ANSI C >specification only defines >two sorts of types as being >incomplete types, >and they are arrays and >structures with certain >characteristics >(indefinite length, being an >undefined structure, or >containing an >undefined structure). A >pointer is not one of those >sorts of types. > >If you think about this, this >makes sense. All pointers >must be >castable in and out of a void >*, so pointers can't be >arbitrarily large, >even assuming you were >working on some broken >architecture where the >sizeof of a pointer to a short >was different from the >sizeof a pointer >to a structure, or something >similarly insane.... (please excuse me if this is already specified - I'm writing this offline) Since gss_name_t is implementation-defined, wouldn't it be prudent to require the size of the structure to be specified in the structure itself? I.e. typedef struct { int size; /* Implementation specifics go here */ } That way, *((int *) elements) would give the size, w/o knowing the implementation details. - Jeff ------ =_NextPart_000_01BD5504.C36EA380 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjsEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQuAAQAhAAAAMDRFMzlEQTUwN0MwRDExMUEzQzIwMDgwNUZDQzVB MTgAEQcBBYADAA4AAADOBwMAFQAUAAsAKwAGAD0BASCAAwAOAAAAzgcDABUAFAAFADkABgBFAQEJ gAEAIQAAADA0RTM5REE1MDdDMEQxMTFBM0MyMDA4MDVGQ0M1QTE4ABEHAQ2ABAACAAAAAgACAAEE gAEAJgAAAFJlOiBJRFVQLUdTUyBpZHVwX25hbWVfc2V0IGRlZmluaXRpb24AIw0BA5AGAJAHAAAZ AAAAQAA5APANC59IVb0BAwDxPwkEAAADAAYQ7Is4bQMABxC5BAAAHgAIEAEAAABlAAAARlJPTTpH UkFIQU1CTEFORDxHQkxBTkRAWkVSR09DT01EQVRFOlRIVSwxOU1BUjE5OTgxMjowNDoyOCswMDAw V0VXT1VMRFBST0JBQkxZSU1QTEVNRU5UR1NTTkFNRVRBU0FQTwAAAAADABAQAQAAAAMAERAAAAAA AgEJEAEAAACxBAAArQQAAJgIAABMWkZ1Ltg8cYcACgENA0N0ZXh0Aff/AqQD5AXrAoMAUALzBrQC gyYyA8UCAGNoCsBzZdh0MCAHEwKAfQqACM9/CdkCgAqECzcSwgHQCuMgKQqAPiAYUEYDYTogiEdy YRNwbSBCC2BkbmQXxzxnAmAZcUAiegSQZ28uBaBtPhkX2URhDvAYwFRodXAsIDE5BdAKwRywOQI4 F8cxMjowNDpyMh1QKzAekRfWF9lXqGUgdwhgbBmQcANgcmIBoGx5F8cHcAtQZZMHgAIwIGcEEF9u GSBUZV8FQGEEIGEXx3DObwuADvAFwHRvIuADoJpvCrBxClAkMHlwIBC3F9YZehhRdBxwBCB5CGCk IGMAcG5vItFwC1AfIQAm0CVIAJAasG9mKD4pJJEEkBwQBbEkQWl0Oi4YUEkDoSNWCsB0af5jIFAK wByQF9kPACCQB5DnAJACIAQgc3UTYCLiF9bCZSHUc1sxXSdWF9ZTBaEVQGN0IPFiIBBlOnYHQHUc ERmQAJBuY58lSCg6GFEo9S53MF0pYP8gNBfWAQAlMBmBAiAoIwDQ/nQxMAMhIT4cEC0hKCMlEqsq YB7eRTBALjoQICeQ/SphQSCAI9s21zGwA3Ahwb8O8CUEBAAjGTxLKmFICfCdMcAsF9YnJSQwYWsk 8f8oQSj3Iy8kPz6yF9YcYCAQwEFOU0kgQyh3JTD+YwaQK4A35AIgIPEBAQuA/weRMfcgMC1gFOEE ICkwJQNvIwEEIDDAC4BnO588pXN/P0cZcigxIQAKwDZBMEBhxnkjARmJc3RyLYA2gP8s4SAgKkAt oDHAACALcS+YfxNxNmEGcU1wK4ATMBflKP8LgEajKkAgECHQSTAm0ByQ+0kEO3l1UQQxYk2GHJAF sb8vqDfBUUFSU1K/U8gpOnM/QZ49ISeSAiAgEEhCaG/XE6AoaEf7Lh7eSUhQJyLbJtALgGsi4Abg dQVAXTH/StBd4xfHAMBAcC1RCfAToP06cmwDIEIVXokm8AVAMMD/L6ci8AGRIdAqMAOgGXJdsttI QUFwdkIgGZgqHJBH4JtgOCdhJ2GCJVhyYipA7xjwBRAg8SuxZz84MPAJ8Nsi4S1wbUkiJyJ3BJAl SPkgMHJrSSI18UfgB4AwsP8DYEBwKqgKwBNgUWFNsyAg/yhATBEoMSh8Y3RCGi1gWgDXACBpqCLx ZAaQZmlxIhH/A1IoL256MfdvU1PrauJdMr9JSACQaNArsSDxC4BzAHDvOLA6ERfVF9UoIcEi8DDR fngrkFohawEGkF5EPSJsuRVAYWQhAEV1MWEtKoD6JxkwdwUQK3BJMV5TKTDUZmxG0Sl3fFMxoyJJ +3nCN2stVqUckCAzZbIqQPswsiCQdQEAIhFCkRVAJND+aW0kM1NZtEDBTYZCgjDBH3qoTsGDfCpA E6BsZj/9KnEuOLB3fCUSAQFTxQMwXwAAF+RiwQVAKPI7iSYvfioqgDdsRXZQVhhRGuAg6W0DKi93 dn13fBxgHBBnICBMcByQKihQ4QVAKucpYC52NIZnaWhQQJeAcfovJFBrJ5AD8HvzPQE3bLsBAE6h bFunF9V7QEoBEQUX1X2WcAAAAAIBcQABAAAAFgAAAAG9VUifC6Wd4wXABxHRo8IAgF/MWhgAAAMA JgAAAAAAAwA2AAAAAAAeAHAAAQAAACIAAABJRFVQLUdTUyBpZHVwX25hbWVfc2V0IGRlZmluaXRp b24AAAACAUcAAQAAACsAAABjPVVTO2E9IDtwPVREUztsPVREUy1GRi05ODAzMjIwNDExNDNaLTU3 NTgAAAIB+T8BAAAASQAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1URFMvT1U9RkFJ UkZBWC9DTj1SRUNJUElFTlRTL0NOPUpFRkZfT0RPTQAAAAAeAPg/AQAAAAsAAABPZG9tLCBKZWZm AAACAfs/AQAAAEkAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089VERTL09VPUZBSVJG QVgvQ049UkVDSVBJRU5UUy9DTj1KRUZGX09ET00AAAAAHgD6PwEAAAALAAAAT2RvbSwgSmVmZgAA QAAHMIiEAZ9IVb0BQAAIMMg6Q9FHVb0BAwANNP0/AAACARQ0AQAAABAAAABUlKHAKX8QG6WHCAAr KiUXHgA9AAEAAAAFAAAAUmU6IAAAAAALACkAAAAAAAsAIwAAAAAAAgF/AAEAAAA8AAAAPGM9VVMl YT1fJXA9VERTJWw9VERTLUZGLTk4MDMyMjA0MTE0M1otNTc1OEB0ZHMtbGEudGRzLmNvbT4AIDM= ------ =_NextPart_000_01BD5504.C36EA380-- From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 23 05:38:58 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA04748; Mon, 23 Mar 98 05:38:58 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id EAA28416 for cat-ietf-redist; Mon, 23 Mar 1998 04:34:16 -0500 (EST) Message-Id: <199803231019.KAA04034@ns0.zergo.com> From: Graham Bland Date: Mon, 23 Mar 1998 9:35:10 +0000 To: cat-ietf@mit.edu Subject: Full Duplex Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id EAA28414 Precedence: bulk Can I suggest a compromise The problem only arises where a default mechanism is requested within gss_init_sec_context(). Where an application specifies the mechanism or selects a specific mechanism from the return of gss_indicate_mechs() the application must be aware of the mechanism and therefore be satisfied that it meets its specific requirements. How about the mandating of full duplex for default or negotiated mechanisms. This would seem to meet all the objections I have heard and still allow a specific half duplex mechanism to exist within the framework. There are some points I would like to clarify: 1. It is essential to a commercial developer to obtain the 'Rubber stamp" of compliance. Therefore not implementing a mandatory requirement is not an option. I do not think it is in anybody's interest to create 'GSS like' implementations. 2. In the Smartcard scenario I mentioned the challenge and response occurs after context establishment and not as part of it. There are many other examples of application to application message flows which are inherently half duplex even after context establishment. Graham Bland -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 23 09:39:23 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08842; Mon, 23 Mar 98 09:39:23 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA17270 for cat-ietf-redist; Mon, 23 Mar 1998 08:26:22 -0500 (EST) From: John_Wray@iris.com X-Lotus-Fromdomain: IRIS To: "Odom, Jeff" Cc: cat-ietf@mit.edu Message-Id: <852565D0.0046C08A.00@elektra.iris.com> Date: Mon, 23 Mar 1998 08:23:33 -0500 Subject: Re: IDUP-GSS idup_name_set definition Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Jeff Odom writes: > Since gss_name_t is implementation-defined, wouldn't it be > prudent to require the size of the structure to be > specified in the structure itself? I.e. > > typedef struct { > int size; > /* Implementation specifics > go here */ > } > > That way, *((int *) elements) would give the size, > w/o knowing the implementation details. What problem are you trying to solve? gss_name_t already has to have a size that the compiler can calculate (since it's passed by value to several API routines). The GSSAPI C-bindings says that gss_name_t should be implemented as a pointer-type (discouraging the use of void *). Maybe that "should" should be upgraded to a "SHALL" (and a reference to RFC 2119 added). Actually, I should go through the entire C-bindings and draw up a list of things that need to have 2119 keywords added. Application code shouldn't care about the size of the object that a gss_name_t references. Such objects are implementation-defined - there's no requirement that they even be contiguous. For example, a mechanism operating with X.500 names that uses the X/Open XDS interface internally might well decide to implement gss_name_t as a pointer to an XDS-format name, which is a horribly complicated tree-structured data-type. The "size" of such a beast isn't much use to anyone, and making a size available will just encourage people to write broken applications that try to copy (*gss_name_t) values with memcpy(). John From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 23 16:42:37 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA16157; Mon, 23 Mar 98 16:42:37 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA26167 for cat-ietf-redist; Mon, 23 Mar 1998 15:23:06 -0500 (EST) Date: Mon, 23 Mar 1998 15:23:00 -0500 Message-Id: <199803232023.PAA28146@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Graham Bland Cc: cat-ietf@mit.edu In-Reply-To: Graham Bland's message of Mon, 23 Mar 1998 9:35:10 +0000, <199803231019.KAA04034@ns0.zergo.com> Subject: Re: Full Duplex Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Graham Bland Date: Mon, 23 Mar 1998 9:35:10 +0000 The problem only arises where a default mechanism is requested within gss_init_sec_context(). Where an application specifies the mechanism or selects a specific mechanism from the return of gss_indicate_mechs() the application must be aware of the mechanism and therefore be satisfied that it meets its specific requirements. How about the mandating of full duplex for default or negotiated mechanisms. This would seem to meet all the objections I have heard and still allow a specific half duplex mechanism to exist within the framework. Why put in all of this complexity when it is utterly trivial to make a mechanism support full-duplex communications? Using a separate sequence number for each direction is a good design principle, anyway --- and that's that you need to do in order to support this. - Ted From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 23 17:38:18 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA17099; Mon, 23 Mar 98 17:38:18 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA24972 for cat-ietf-redist; Mon, 23 Mar 1998 15:10:33 -0500 (EST) From: Martin Rex Message-Id: <199803232010.VAA20302@hw1464.wdf.sap-ag.de> Subject: Re: Full Duplex Orig-To: gbland@zergo.com (Graham Bland) To: cat-ietf@MIT.EDU Date: Mon, 23 Mar 1998 21:09:37 +0100 (MET) In-Reply-To: <199803231019.KAA04034@ns0.zergo.com> from "Graham Bland" at Mar 23, 98 09:35:10 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Graham Bland wrote: > > Can I suggest a compromise > > The problem only arises where a default mechanism is requested within > gss_init_sec_context(). Where an application specifies the mechanism or > selects a specific mechanism from the return of gss_indicate_mechs() the > application must be aware of the mechanism and therefore be satisfied that > it meets its specific requirements. (1) for portability purposes applications are recommended to request the default mechanism from gss_init_sec_context() (2) The assumption that an application knows about a mechanisms characteristics when supplying an explicit mech OID is plain wrong. (3) There are no side effects listed for applications requesting specific mechanism OIDs instead of the default mechanism, so your proposal would mean a clear change in the specification and backwards incompatible to GSS-API v1. I think it's a bad idea and I am stongly opposed to side-effect requests for explicit mechanisms. > > How about the mandating of full duplex for default or negotiated mechanisms. > > This would seem to meet all the objections I have heard and still allow a > specific half duplex mechanism to exist within the framework. > > > There are some points I would like to clarify: > > 1. It is essential to a commercial developer to obtain the 'Rubber stamp" of > compliance. Therefore not implementing a mandatory requirement is not an > option. I do not think it is in anybody's interest to create 'GSS like' > implementations. There's no problem in attributing compliance to commercial products. There is however a real problem with attributing compliance for broken designs. > > 2. In the Smartcard scenario I mentioned the challenge and response occurs > after context establishment and not as part of it. There are many other > examples of application to application message flows which are inherently > half duplex even after context establishment. What is it that you have there: a gss-api mechanism or an application using gssapi? Our discussion about a full duplex message protection does only increase the usability of gssapi mechanisms, it will NOT break any applications. I'm really confused by your above statement, since you refer only to application level issues which are completely irrelevant here. But in case that you have actually a *gss-api mechanism* and that tries to do/continue negotiation by piggy-backing the tokens of protected messages, then it is very likely broken and non-compliant anyway. A gssapi mechanism can not dictate the flow of information of the application once the security context is established. They application may well decide to send data only unidirectional for the rest of the lifetime of the connection or security context (afaik the FTP-data channel is one such example). This is the main reason why a security context refresh can not be hidden within the gssapi mechanism, it has to be done at the application level. So I'm still waiting for at least one valid technical issue against the explicit requirement ... -Martin From owner-cat-ietf@pad-thai.cam.ov.com Mon Mar 23 19:38:45 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA19149; Mon, 23 Mar 98 19:38:45 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA14042 for cat-ietf-redist; Mon, 23 Mar 1998 18:24:58 -0500 (EST) Message-Id: From: Carlisle Adams To: "'cat-ietf@mit.edu'" , "'Graham Bland'" Subject: RE: GSS and IDUP Date: Mon, 23 Mar 1998 18:20:50 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Hi Graham, >---------- >From: Graham Bland[SMTP:gbland@zergo.com] >Sent: Wednesday, January 14, 1998 9:12 AM >To: cat-ietf@mit.edu >Subject: GSS and IDUP > >Firstly apology on two counts. >The timing of these comments is poor following last call, however at that >time I had no comments. > >Secondly the length, this is a collection of comments and issues rather than >sending each as a seperate email I have collated them together. > >The background from most of these has come from looking at an environment >which will support both GSS and GSS-IDUP. All are based on the latest >documents. Thank you for the comments! I eventually did manage to get a revision to the spec. completed and submitted, but only at 4:52 EST on the deadline date, so I had no idea whether or not it would actually make the cut-off for submissions (as it turns out, it did). Below are responses to your comments from January. I believe that the latest draft addresses most of your concerns. Carlisle. ------------------------------------- >IDUP_Get_token_details > ------------------------------------ >When Data encapsulation has been requested the application must pass >sufficient data from the start of the P_IDU to include the token to the >call. The application has no way of determining how much data this is. A >return code of IDUP_S_MORE_PIDU_NEEDED should be allowed to enable the >application to pass more data to the call. >The other option would be to require a minimum data size of for example 4kb >or the entire token to be passed. This would constrain the mechanism >implementors to include all the required data within the first 4kb of a >token. > >The call returns the idu_size, however where data encapsulation and multiple >buffers are used a mechanism cannot determine this from the start of the >P_IDU as the mechanism does not know the IDU length until the IDU has been >fully processed (see later comment on IDU Length on multi buffer calls) as >indicated by the end protect call by which time the token at the start of >the P_IDU has already been emitted and cannot be changed. >Suggested behaviour here would be to return UNKNOWN as the idu_size with a >status of GSS_S_COMPLETE for encapsulated data. See pp.45-46 of the new draft. This discusses the 4Kb rule and the use of UNKNOWN idu_size. >IDUP Multibuffer processing > -------------------------------- >While examining some of the SE Start/Process/End sequences of calls We have >noted the following; > >A mechanism (directly or indirectly via the environment) will need to >preserve state information from one call to the next in a sequence of >(SE/EV/GP) Start/Process/End calls. This state information will almost >certainly involve dynamic memory allocation. If for some reason (e.g. an >I/O error or user abort) an application calls a Start followed by zero or >more Process calls but fails to call End, that memory will not be released >in the normal way (i.e. on the End call). > >Currently we have assumed, that, for a single instance of an environment, it >is only valid to be performing a single multi-step operation at one time >(e.g. a sequence such as SEStart, EVStart, SEProcess, EVProcess, SEEnd, >EVEnd is not allowed). We have further specified that an environment should >only be used in the thread that created it. > >At a specification level, it may be appropriate to suggest a 'cancel' >function for each of the multi-step operations (for example >IDUP_SE_MultiBuffer_Cancel), which would allow the application to indicate >to IDUP that it was unable to make the additional Process calls due to some >application level difficulty. There is now an IDUP_Cancel_multibuffer_op call. >A further point is the possibility of including an 'operation' handle within >the multi-step calls (i.e. an handle that is returned from the Start >operation and must be passed to each subsequent matching process/end or >cancel call). This would allow state information to be associated with a >series of calls and not bound to the environment. This would remove the >sequence and thread restrictions above. At the moment any >multi-thread/fibre application will have to establish an environment for >each operation it will perform (and this may be expensive). An alternative >would be to provide a 'duplicate environment' function which should be able >to avoid some aspects of environment establishment (e.g. certificate >validation) and thus be less expensive that establishing a new environment. In the interest of not introducing major changes at this point (and of keeping some level of similarity between the IDUP and GSS calls), I have not put in an "operation" handle. We can certainly re-visit this issue (if there is further interest in this from the WG) if/when there is a "version 2" of the IDUP specification. >IDUP_ev_singlebuffer_verify > ------------------------------------------ >The idu_buffer is described in the API spec as an input and an output, in >the "C" bindings this is implemented as two parameters one input buffer and >one output buffer. Both however have the same name of idu_buffer. I >suggest renaming these to external_idu_buffer for the input buffer and >encapsulated_idu_buffer for the output. Done (see p.28). >IDUP_establish_env > ------------------------------ This is a C-bindings (not a base spec.) issue, and will be addressed there. >Status Codes > -------------------- This is a C-bindings (not a base spec.) issue, and will be addressed there. >Credential Usage Type > ----------------------------------- >GSS C-Bindings Defines credential usage as an INT. Latest IDUP draft >defines it as a BIT-STRING. >The spec states "The calls given in Section 2.1 of GSS-API (including all >associated parameters) are unchanged, although the interpretation of the >cred_usage parameter in the GSS_API calls for IDUP purposes is as follows. >..." >However the determination of the usage of the credential (i.e. for GSS usage > - context establishment, or for IDUP usage - environment establishment) >does not occur until later - possibly after credential elements have been >instantiated. >While it is possible to overload the use of the parameter, it would ease >matters if the parameter was defined as a bit string in both cases. For >example > >GSS_C_INITIATE 1 >GSS_C_ACCEPT 2 >IDUP_C_ENCRYPT_ONLY 8 >IDUP_C_DECRYPT_ONLY 16 >IDUP_C_SIGN_ONLY 32 >IDUP_C_VERIFY_ONLY 64 > >GSS_C_BOTH (GSS_C_INITIATE | GSS_C_ACCEPT) >IDUP_C_NO_RESTRICTION (IDUP_C_ENCRYPT_ONLY | > IDUP_C_DECRYPT_ONLY | > IDP_C_SIGN_ONLY | > > IDUP_C_VERIFY_ONLY) > > it is unclear as to what is intended in an environment with a mechanism >which implements both GSS and IDUP. > >This is proposed as a change to both IDUP and GSS C-bindings. Done (see pp.13, 44). >Parameter Types > -------------------------- This is a C-bindings (not a base spec.) issue, and will be addressed there. >Case usage > ------------------ This is a C-bindings (not a base spec.) issue, and will be addressed there. >Idup_name_set > ----------------------- This is a C-bindings (not a base spec.) issue, and will be addressed there. >idup_acquire_cred_with_auth > ------------------------------------------- This is a C-bindings (not a base spec.) issue, and will be addressed there. >Appendix IDUP-GSS-API example > --------------------------------------------------- This is a C-bindings (not a base spec.) issue, and will be addressed there. >IDU Length on multi buffer calls > --------------------------------------------- >The IDUP calls IDUP_SE_MultiBuffer_StartProtect, >IDUP_EV_MultiBuffer_Generate (with include_data_in_token TRUE) and >IDUP_Protect all create a PIDU which contains an encapsulated IDU. > >The total length of the IDU is not available at any point prior to the >matching IDUP_xxxEndxxx call. > >Thus the beginning of the PIDU cannot contain the length of the IDU (or >related length) without the mechanism buffering the entire IDU. This may be >impractical due to the potential size of the IDU. > >IDUP mechanisms are therefore constrained to use either > - chaining (where the data is broken into blocks and the length of each >block prefixes the block and the last block is marked - this requires >buffering up to one block length or more at the receiver), or, > - an 'end of data' marker (this marker must be guarantee never to occur in >either the IDU or encrypted IDU - this requires buffering up to the length >of the EOD marker at the receiver). > >To resolve this issue, and allow mechanisms to store the size of the IDU at >the start of the PIDU, the three calls listed above should have an >additional parameter 'idu_size' which is required when encapsulation is >required. >The idu_size should have a value 'UNKNOWN' (for example where encapsulating >data from a pipe, or compressing on the fly) - some mechanisms may not >support encapsulation if this value is UNKNOWN. It seems to me that calling applications will not typically know the idu_size beforehand (for the multi-buffer case) and will therefore typically use a value of UNKNOWN. Since this seems of little practical benefit, I did not include this change. Again, this issue can be re-visited if/when there is IDUPv2 work. >Return Codes > -------------------- >I suggest that an additional return code be added both to GSS and IDUP >specifications to cover a case of inconsistent parameters, for example in >idup_start_unprotect where only one of single_idu_buffer and >final_pidu_buffer may have a zero length and the caller has passed both. >Currently GSS_S_FAILURE must be returned which is not particularly >informative to the application developer. Done (see pp.8, 20, 26, 39, 43). >Idup_establish_env > ----------------------------- >Passing GSS_C_NO_OID_SET as the req_services parameter to idup_establish_env >should be defined as requesting the full set of available services for that >mechanism. > >There is no point in establishing an environment with no services (hence >GSS_C_NO_OID_SET is not really a valid input parameter), and given that the >services are mechanism specific and may grow over time, there is no way for >an application to discover which services are available without >pre-knowledge (OK - how it then uses these services is another matter...). > It also simplifies the application developers job as they do not have to >create an OID set to start with. Done (see p.14). >Credentials and Usage > ---------------------------------- >1. >The GSS C Bindings define 'cred_usage' as input only for both >gss_acquire_cred and gss_add_cred. It does not comment on what should happen >if only a subset of the usage is available (e.g, if BOTH is requested and >only INITIATE is available, should that generate a GSS_C_NO_CRED?). (This is a GSS C-bindings issue.) >2. >The language API Specification (rfc2078bis-01) state that for >gss_acquire_cred, that it should fail if the requested usage is not >available, but gss_add_cred has an additional output parameter (with the >same name as an input parameter) which suggests that add cred should return >the set of usage"s available and succeed if any requested usage was >available. I say 'suggests' since the interpretation depends entirely on >which 'cred_usage' the paragraph is referring to (i.e. the input or output). > >The reason that I question this is that in the case of gss_acquire_cred, >this would mean that the application programmer would basically have to >acquire separate credentials for each operation type, since they could not >be guaranteed that any combination would succeed (without making >installation specific assumptions) and they would thus have to perform an >exhaustive call search to find the best available. Note that this is >compounded by IDUPs 4 additional 'cred_usage' values. > >For the above reason I believe that we should take the approach used by GSS >everywhere else - i.e. request a set of features, but the onus is on >application programmer to ensure that a sufficient subset was provided. > Thus, both acquire_cred and add_cred should have 'actual_cred_usage' output >parameters. The latter is a change to the c-bindings only, bringing it in >line with the GSS spec, the former deviates from both. However without some >sort of resolution in this area, any application that wishes use GSS and >IDUP would have to maintain separate credentials for each, negating much of > the value of a core set of credential management functions. Done (see p.44). >Note that I am currently making the assumption that in a multi-mechanism >environment, credential acquisition succeeds if any combination of >mechanisms satisfies the cred_usage. > >3. >For credential acquisition within IDUP, you are allowed to define a >restricted use for the credential (e.g. ENCRYPT_ONLY, DECRYPT_ONLY, >SIGN_ONLY, VERIFY_ONLY and combinations thereof). >Additionally, when establishing the environment you can request an OID set >of services to request (e.g PER_CONF, REC_CONF, PER_POO, REC_POO, ... and >combinations thereof). >Can you see any value in having both? Any of the IDUP 'cred_usage' bits >appears to indicate that we require an IDUP credential element and thus I >see no reason why service requirements are duplicated at both levels. Can >we suggest that the credential usage should therefore be IDUP_C_ENVIRONMENT >(in addition to GSS_C_INITIATE and GSS_C_ACCEPT) and that restricted service >requirements are only made at the environment establishment phase. This is >more in line with the GSS model - as per the service flags (deleg_req_flag, >mutual_req_flag, ...) given at gss_init_sec_context call. > >This does not negate the previous comments, but would rather simplify the >credential usage concept - i.e. a credential can be used for initiating >contexts, accepting contexts or creating environments or combinations >thereof (all lying in the same dimension). The application programmer >should request the desired features and check to see if the required subset >is available. Interesting suggestion. Again, I ask that we defer this to IDUPv2 (if there is interest within the WG) in order to minimize major changes to this spec. The only other change to the spec. that I can think of at the moment is clarifying language (and a new flag) regarding mechanism-independent token wrapping. This comes about as a response to discussion from Martin, Denis, Bengt, John Linn, and myself on this issue. (See pp.19, 25, 34, 51.) I believe that this draft is ready (again!) for Last Call. Thanks to everyone who has shown an interest in this specification! -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 24 09:31:35 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03596; Tue, 24 Mar 98 09:31:35 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA28150 for cat-ietf-redist; Tue, 24 Mar 1998 08:26:07 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F80127660121114B@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Cc: "'agenda@ietf.org'" Subject: CAT-WG LA agenda, draft 2 Date: Tue, 24 Mar 1998 08:28:06 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk Here's a Draft 2 agenda for the CAT LA meetings, responding to requests and with only slight revisions from Draft 1; requests for changes or additional topics are welcome and can be reconciled at the session next week. Again, I'll look to document editors or their designees (hereby offering thanks in advance) to lead needed discussion of their respective drafts, summarizing recent changes, resolutions for previously-identified issues, and currently active issues relevant to the drafts as appropriate. Monday, 30 March, 1300-1500: 1300-1310: Opening discussion and agenda review WG Last-Call reviews: discussion to clear issues if needed and confirm actions (cited subslots may run short if feasible): - 1310-1330: rfc2078bis-03 - 1330-1350: spnego-08 - 1350-1400: ftpdsaauth-03, ftpkeasj-00 Other drafts revised or pending revision and with discussion requests: - 1400-1420: pk-init-06 - 1420-1440: pk-cross-04 - 1440-1500: kerberos-revisions-xx Tuesday, 31 March, 1015-1115: 1015-1025: pk-recovery-00 1025-1040: pktapp-01 1025-1115: continuing discussion and/or other topics as needed --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 24 21:34:36 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15911; Tue, 24 Mar 98 21:34:36 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id UAA06451 for cat-ietf-redist; Tue, 24 Mar 1998 20:12:40 -0500 (EST) From: "David Miller" Message-Id: <9803241709.ZM13103@engsol01.cybersafe.com> Date: Tue, 24 Mar 1998 17:09:47 -0800 X-Mailer: Z-Mail (3.2.1 10apr95) To: cat-ietf@MIT.EDU Subject: generic nametypes and gss_import_name() Cc: david.miller@CyberSafe.COM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk CAT list: I'm looking to resolve what seems a basic issue with gss_import_name() and generic nametypes. That is, without a mechanism OID parameter in gss_import_name(), how do I know what mechanism a name will be imported under? It seems with the old mechanism-specific nametypes, e.g. GSS_KRB5_NT_MACHINE_UID_NAME, it of course is clear. But what if I call gss_import_name() with GSS_C_NT_MACHINE_UID_NAME? Thanks for any elucidation. David S. Miller CyberSafe Corporation -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Tue Mar 24 22:33:08 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA16974; Tue, 24 Mar 98 22:33:08 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id VAA15734 for cat-ietf-redist; Tue, 24 Mar 1998 21:53:09 -0500 (EST) From: Martin Rex Message-Id: <199803250251.DAA01991@hw1464.wdf.sap-ag.de> Subject: Re: generic nametypes and gss_import_name() To: david.miller@CyberSafe.COM (David Miller) Date: Wed, 25 Mar 1998 03:51:44 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <9803241709.ZM13103@engsol01.cybersafe.com> from "David Miller" at Mar 24, 98 05:09:47 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk David Miller wrote: > > CAT list: > > I'm looking to resolve what seems a basic issue with gss_import_name() > and generic nametypes. That is, without a mechanism OID parameter in > gss_import_name(), how do I know what mechanism a name will be imported > under? It seems with the old mechanism-specific nametypes, e.g. > GSS_KRB5_NT_MACHINE_UID_NAME, it of course is clear. But what if I > call gss_import_name() with GSS_C_NT_MACHINE_UID_NAME? The labels GSS_KRB5_NT_MACHINE_UID_NAME and GSS_C_NT_MACHINE_UID_NAME may be syntactically different, but they refer both to the same OID (always have), so I don't think it's any clearer or unclearer. A name may or may not be mapped to a mechanism immediately when imported. That is completely implementation defined. It would even be ok for an SPKM implementation to accept names of the type GSS_KRB5_NT_PRINCIPAL_NAME. I'm not sure, but I think that even when a GSS-API v2 application calls gss_canonicalize_name() with a explicit mech_oid1, the mechanism would still be allowed to accept this name when passing it to gss_acuire_cred() with mech_oid2! For which purpose do you want to link a name to a mechanism? -Martin From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 09:38:17 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA28722; Wed, 25 Mar 98 09:38:17 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id IAA11748 for cat-ietf-redist; Wed, 25 Mar 1998 08:23:34 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F801276601211155@exna01.securitydynamics.com> From: "Linn, John" To: david.miller@CyberSafe.COM, "'Martin.Rex@sap-ag.de'" Cc: "cat-ietf@MIT.EDU" Subject: RE: generic nametypes and gss_import_name() Date: Wed, 25 Mar 1998 08:25:20 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk Martin wrote, replying to David: > A name may or may not be mapped to a mechanism immediately when > imported. > That is completely implementation defined. It would even be ok for an > SPKM > implementation to accept names of the type GSS_KRB5_NT_PRINCIPAL_NAME. > I'd like to echo, generalize, and strengthen this statement. Not only is it OK for mechanisms to accept names as defined by other mechanisms, I think this is a Good Thing. If the set of supported nametypes can overlap across mechanisms, this can only help application portability. For the case of a multi-mechanism implementation, it's entirely possible and appropriate that the internal, implementation-defined form output from gss_import_name() may contain internal elements corresponding to more than one mechanism. > I'm not sure, but I think that even when a GSS-API v2 application > calls > gss_canonicalize_name() with a explicit mech_oid1, the mechanism would > still be allowed to accept this name when passing it to > gss_acuire_cred() > with mech_oid2! > I agree. > For which purpose do you want to link a name to a mechanism? > I can't speak for what motivation David had in mind here, but one argument I've heard voiced in the past is a desire to write ACLs where the name connotes the mechanism which was used to authenticate it (so that, e.g., my Kerberos-authenticated identity might receive greater or lesser rights than my SPKM-authenticated identity, even if the name syntaxes are interchangeable). I believe, however, that unnecessarily constraining cross-mechanism supportability of name types to this end undesirably conflicts with portability as noted above; if this information is desired as input to an authorization policy, it's always available through the context's mechanism OID. > -Martin > --jl From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 11:37:10 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00929; Wed, 25 Mar 98 11:37:10 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA24323 for cat-ietf-redist; Wed, 25 Mar 1998 10:37:05 -0500 (EST) From: Martin Rex Message-Id: <199803251536.QAA06642@hw1464.wdf.sap-ag.de> Subject: Re: generic nametypes and gss_import_name() To: jlinn@securitydynamics.com (Linn John) Date: Wed, 25 Mar 1998 16:36:49 +0100 (MET) Cc: cat-ietf@mit.edu In-Reply-To: <6B5344C210C7D011835C0000F801276601211155@exna01.securitydynamics.com> from "Linn, John" at Mar 25, 98 08:25:20 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk David, Linn, John wrote: > > > I'm not sure, but I think that even when a GSS-API v2 application > > calls > > gss_canonicalize_name() with a explicit mech_oid1, the mechanism would > > still be allowed to accept this name when passing it to > > gss_acuire_cred() > > with mech_oid2! > > > I agree. > > > For which purpose do you want to link a name to a mechanism? > > > I can't speak for what motivation David had in mind here, but one > argument I've heard voiced in the past is a desire to write ACLs where > the name connotes the mechanism which was used to authenticate it (so > that, e.g., my Kerberos-authenticated identity might receive greater or > lesser rights than my SPKM-authenticated identity, even if the name > syntaxes are interchangeable). I believe, however, that unnecessarily > constraining cross-mechanism supportability of name types to this end > undesirably conflicts with portability as noted above; if this > information is desired as input to an authorization policy, it's always > available through the context's mechanism OID. For the purpose of authorization based on ((the strength of)) the mechanism that was used, GSS-API has an offical way to pair a name and a mech-oid for ACL usage: gss_canonicalize_name() + gss_export_name(). gss_import_name()+gss_canonicalize_name()+gss_export_name() can be used to populate an ACL; the output "src_name" from gss_accpept_sec_context() when passed to gss_export_name() will give the "authenticated name" relative to the mechanism of the security context. This one of the reasons why there is a mech_oid in the outer/generic framing of gss_export_name(). (Section 3.2 in rfc2078/bis) -Martin From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 14:34:47 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA03976; Wed, 25 Mar 98 14:34:47 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA10045 for cat-ietf-redist; Wed, 25 Mar 1998 13:12:26 -0500 (EST) From: "David Miller" Message-Id: <9803251009.ZM15926@engsol01.cybersafe.com> Date: Wed, 25 Mar 1998 10:09:25 -0800 In-Reply-To: "Linn, John" "RE: generic nametypes and gss_import_name()" (Mar 25, 8:25am) References: <6B5344C210C7D011835C0000F801276601211155@exna01.securitydynamics.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: "Linn, John" , david.miller@CyberSafe.COM, "'Martin.Rex@sap-ag.de'" Subject: Re: generic nametypes and gss_import_name() Cc: "cat-ietf@MIT.EDU" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 25, 8:25am, Linn, John wrote: > Subject: RE: generic nametypes and gss_import_name() > Martin wrote, replying to David: > > > A name may or may not be mapped to a mechanism immediately when > > imported. > > That is completely implementation defined. It would even be ok for an > > SPKM > > implementation to accept names of the type GSS_KRB5_NT_PRINCIPAL_NAME. > > > I'd like to echo, generalize, and strengthen this statement. Not only > is it OK for mechanisms to accept names as defined by other mechanisms, > I think this is a Good Thing. If the set of supported nametypes can > overlap across mechanisms, this can only help application portability. > For the case of a multi-mechanism implementation, it's entirely possible > and appropriate that the internal, implementation-defined form output > from gss_import_name() may contain internal elements corresponding to > more than one mechanism. > I agree with all this. It seems we're alluding to the possibility that internal name forms may be identical over greater than one mechanism. But they may not be, right? I'd like to get back to the original question, which is simply how do I know what mechanism I'm importing a name under when I use a generic nametype? There is no mechanism information in the parameter list, and none can be gleaned from the nametype symbol itself. I also don't feel I can assume that, e.g., all mechanisms importing a name using nametype GSS_C_NT_STRING_UID_NAME will result in the same internal name form. Four thoughts come to mind when I think about this, none of which are really attractive: 1. I'll get the name imported under every mechanism the implementation supports. This doesn't seem right, especially in an environment in which users can only be expected to be authorized to use a proper subset of the available mechanisms. 2. I'd have to avoid using generic nametypes so as to have the mechanism information by virtue of the nametype. This nullifies what seems to be a very worthy goal of generic nametypes, that being increased application portability. 3. Add a parameter to gss_import_name() for the mechanism OID to import a name under. This would seem impossible to consider, as it would break all past applications. 4. Add a gss_import_name_by_mech() call? Am I getting further out on the limb? Comments? > > > -Martin > > > --jl > > > >-- End of excerpt from Linn, John -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 15:33:42 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05023; Wed, 25 Mar 98 15:33:42 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA19011 for cat-ietf-redist; Wed, 25 Mar 1998 14:44:31 -0500 (EST) From: John_Wray@iris.com X-Lotus-Fromdomain: IRIS To: "David Miller" Cc: cat-ietf@mit.edu Message-Id: <852565D2.006B621B.00@arista.iris.com> Date: Wed, 25 Mar 1998 14:41:52 -0500 Subject: Re: generic nametypes and gss_import_name() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk David Miller writes: > I'd like to get back to the original question, which is simply > how do I know what mechanism I'm importing a name under when I > use a generic nametype? I think you need to explain what you mean by importing a name "under a mechanism", and what this concept would buy you? John From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 16:28:44 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA06008; Wed, 25 Mar 98 16:28:44 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA26008 for cat-ietf-redist; Wed, 25 Mar 1998 15:57:07 -0500 (EST) Date: Wed, 25 Mar 1998 15:56:27 -0500 Message-Id: <199803252056.PAA29129@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "David Miller" Cc: "Linn, John" , david.miller@CyberSafe.COM, "'Martin.Rex@sap-ag.de'" , "cat-ietf@MIT.EDU" In-Reply-To: David Miller's message of Wed, 25 Mar 1998 10:09:25 -0800, <9803251009.ZM15926@engsol01.cybersafe.com> Subject: Re: generic nametypes and gss_import_name() Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk David, It's clear you're trying deal with issues that come up when you implement a multi-mechanism adaptor mechanism, presumably which interfaces to a number of mechanism's GSSAPI interfaces, and exports a GSSAPI interface with the comabined mechanisms. Am I right? There are a number of things you might consider. The two which I find most promising is to either try calling gss_import_name for all mechanisms which your GSSAPI adaptor has registered, or possibly doing lazy evaluation. Don't actually try to call the underlying gss_import_name until you know for which mechanism you will be using the gss_name. The problem with the latter is you won't know about errors in gss_import name until very late in the game. There is a partially completed mechanism multi-mechanism adaptor in the Krb5 sources. (It was donated to us by Sun.) I worked on this for a while, but it turns out to be a tough problem to get right, especially if you assume that the underlying low-level mechanisms are completely independent. Still, if you're working on this project, it might be worth taking a look at that effort. The approach taken in that code was that there was a configuration file that listed certain name types as being "mechanism-specific". If you called gss_import_name with one of those name types, it would call the lower layer gss_import_name directly, so that any errors would be returned right away. Otherwise, it would do lazy evaluation, and simply store the passed-in name type and string. Trying to make such a multi-mechanism adaptor is an interesting project, but please remember that the original design goal of the GSSAPI did *not* include the requirement that it be possible to compose disparate GSSAPI mechanisms together using only the GSSAPI mechanism interfaces. It almost works, but there may be some tiny glitches, and if you find any, please remember that this is outside GSSAPI's design envelope before you start criticizing. :-) - Ted From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 17:16:08 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA06793; Wed, 25 Mar 98 17:16:08 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id PAA26178 for cat-ietf-redist; Wed, 25 Mar 1998 15:58:46 -0500 (EST) From: "David Miller" Message-Id: <9803251255.ZM16621@engsol01.cybersafe.com> Date: Wed, 25 Mar 1998 12:55:53 -0800 In-Reply-To: John_Wray@iris.com "Re: generic nametypes and gss_import_name()" (Mar 25, 2:41pm) References: <852565D2.006B621B.00@arista.iris.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: John_Wray@iris.com Subject: Re: generic nametypes and gss_import_name() Cc: cat-ietf@MIT.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 25, 2:41pm, John_Wray@iris.com wrote: > Subject: Re: generic nametypes and gss_import_name() > David Miller writes: > > > I'd like to get back to the original question, which is simply > > how do I know what mechanism I'm importing a name under when I > > use a generic nametype? > > I think you need to explain what you mean by importing a name "under a > mechanism", and what this concept would buy you? > I'm under the impression that GSS internal names are capable of having multiple components - one for each mechanism supported by an implementation. If I have a multimechanism implementation that supports mechs A and B, I would expect that there is a way to call gss_import_name() so that I communicate whether I want the internal name generated by mech A, or the one generated by mech B. There has been some suggestion in previous messages that they could be the same, but I'm imagining that they might be different. For example, with SPKM, there might be an X.500 name within the internal name, and with Kerberos 5, there wouldn't be. To answer directly, "importing a name under a mechanism" could be rephrased as "importing a name according to the rules of a mechanism." This would seem to buy me control over the use of one of several mechanisms within an implementation. I could perhaps write an application to, e.g., 1. indicate mechanisms supported by the implementation 2. query something to determine the ones I'm authorized for 3. get an indication from the user as to the one desired out of those 4. import the user's name for the mechanism chosen 5. acquire credentials for that mechanism 5. establish a security context using that mechanism 6. protect data I hope this makes my question clearer. If there is a reason that the internal name is independent of mechanisms, I'd like to come to some understanding of that. Thanks. David > John > > >-- End of excerpt from John_Wray@iris.com -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 17:31:29 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA07064; Wed, 25 Mar 98 17:31:29 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA29551 for cat-ietf-redist; Wed, 25 Mar 1998 16:33:28 -0500 (EST) Date: Wed, 25 Mar 1998 16:32:52 -0500 Message-Id: <199803252132.QAA29188@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: bcn@isi.edu Cc: cat-ietf@MIT.EDU, krb-protocol@MIT.EDU Subject: [Mike Swift: RE: Bug in kerb5 asn.1 encoding] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk This reflects an editing issue to the kerberos-revisions draft to make our ASN.1 representation be "ISO"ly correct, while maintaining backwards compatibility with the currently deployed code. (The problem is that DER-encoded ASN.1 named bitstrings are specified as suppressing trailing zero's, and although kerberos-revision states that Krb5 bitstrings must be a multiple of 32 bits long, ASN.1 purists will claim that by using named-bitstrings, we're not allowed to make such statements.) - Ted ------- Forwarded Message From: "Mike Swift (NT)" To: "Theodore Y. Ts'o" Cc: Tom Yu , Bill Sommerfeld , krbdev@MIT.EDU Subject: RE: Bug in kerb5 asn.1 encoding Date: Tue, 24 Mar 1998 10:06:32 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) I have tried out the approach suggested by Ted and it seems to work. Removing the named bit notation & setting the standard to be that clients always send 32 bits is probably the cleanest way to resolve this issue. - Mike -----Original Message----- From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU] Sent: Friday, March 20, 1998 1:39 PM To: Mike Swift (NT) Cc: Tom Yu; Bill Sommerfeld; krbdev@MIT.EDU Subject: Re: Bug in kerb5 asn.1 encoding This is one of the reasons why I've always claimed that using ASN.1 was a mistake for Kerberos, and I still believe that using ASN.1 is a mistake in general. The spec is simply far too complicated for what it's trying to do, and the value it adds is dubious at best --- after all, what's the value of being able to send arbitrary length integer if most implementations will blow up if you send a value bigger than some implementation-defined value? Or you could require that internally, all implementations that use ASN.1 have to use a bignum package, but then you throw your performance out the door..... But I digress. Quite frankly, I don't really care about ASN.1 "correctness". Interoperability with the installed base is far more important. I would have to back into the mists of pre-history to determine this for sure, but I believe that the bug goes back to when we were using ISODE ASN.1 encoders, and the programmer who wrote our hand-coded C ASN.1 encoders and decoders made it bug-for-bug compatible. (He probably didn't understand enough about the fine points of ASN.1 to realize this was actually an ASN.1 spec violation, or he would have flagged it, and least made our code be able to accept correct ASN.1.) However, for the sake of making the draft a standard, I suppose that we should fix our ASN.1 notation. I believe we can do this without breaking all of the existing implementations, by omitting the use of the named bit notation. If we change the spec to say this: APOptions ::= BIT STRING instead of this: APOptions ::= BIT STRING { reserved(0), use-session-key(1), mutual-required(2) } and then simply state in the draft that all ASN.1 BIT STRING's must be a multiple of 32 bits, we should be OK according ASN.1 rules. ISO 8824 states that the named bit notation should not be used if the presence or absense of trailing zero bits is significant. By just simply using a plain BIT STRING, then we string of bits that has a length, and a BIT STRING that is all zeros and is 15 bits long is distinct from a BIT STRING which is is all zeros and 32 bits long. We just simply state (outside of the ASN.1 notation), what the meaning of the various bits mean, and that our BIT STRINGS must be a multiple of 32 bits. (And note that sending a BIT STRING longer than 32 bits may cause some implementations to blow up, just as as sending integers larger than 2**32 may cause some implementations to blow up, and SHOULD be avoided.) And remember --- friends don't make friends use ASN.1..... - Ted ------- End Forwarded Message From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 18:32:17 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08182; Wed, 25 Mar 98 18:32:17 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA07138 for cat-ietf-redist; Wed, 25 Mar 1998 17:49:06 -0500 (EST) From: Martin Rex Message-Id: <199803252139.WAA08023@hw1464.wdf.sap-ag.de> Subject: Re: generic nametypes and gss_import_name() To: david.miller@CyberSafe.COM (David Miller) Date: Wed, 25 Mar 1998 22:39:59 +0100 (MET) Cc: cat-ietf@MIT.EDU In-Reply-To: <9803251009.ZM15926@engsol01.cybersafe.com> from "David Miller" at Mar 25, 98 10:09:25 am Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk David Miller wrote: > > I agree with all this. It seems we're alluding to the possibility > that internal name forms may be identical over greater than one > mechanism. But they may not be, right? > > I'd like to get back to the original question, which is simply > how do I know what mechanism I'm importing a name under when I > use a generic nametype? There is no mechanism information in > the parameter list, and none can be gleaned from the nametype > symbol itself. I also don't feel I can assume that, e.g., all > mechanisms importing a name using nametype GSS_C_NT_STRING_UID_NAME > will result in the same internal name form. What do you mean by "I" in "how do I know what mechanism ..."? Does it matter to you as an application writer? how/why? An application may bother about the message protection services that are available (or not) from certain mechanisms, and it may influence the selection of a specific mechanism by passing a mechanism oid to gss_init_sec_context() or using credentials for a specific mechanism. Why should an application bother about the relation of mechanisms and names? (other than the authorization issue based on the strength of the selected/negotiated mechanism -- but this is already defined, see my last mail). Does it matter to you as a gss-api mechanism implementor? how/why? If one wants to implement a multi-mechanism and wonders about how to implement a name that fits the spec? IMHO multi-mechanisms are significantly more complex than single-mechanisms. And they're much more difficult to deal with at the application level *IF* the application wants to conciously support it. Anyway, I think that names are quite easy -- multimechanism credentials and the mechanism negotiation is much harder if you implement generic and flexible. > > Four thoughts come to mind when I think about this, > none of which are really attractive: > > 1. I'll get the name imported under every mechanism the > implementation supports. This doesn't seem right, especially > in an environment in which users can only be expected to be > authorized to use a proper subset of the available mechanisms. It *definitely* should be imported to become usable for as many mechanisms as possible (of the mechanisms supported by the implementation). If you require an application (and ultimately a user) to use different target names depending on the mechanism, they will not like or use it. For the application, such a multimechanism will have no added value over seperate single-mechanisms. > > 2. I'd have to avoid using generic nametypes so as to have the > mechanism information by virtue of the nametype. This nullifies > what seems to be a very worthy goal of generic nametypes, that > being increased application portability. It's quite hard to prohibit reuse of a nametype by somebody else, and acutally we recommend to reuse as many nametypes as possible, so such behaviour would be *extremely* implementation specific to both applications and mechanisms ... > > 3. Add a parameter to gss_import_name() for the mechanism OID > to import a name under. This would seem impossible to consider, > as it would break all past applications. > > 4. Add a gss_import_name_by_mech() call? Am I getting further > out on the limb? This sounds extremely bogus to me. I'm still totally clueless what you expect to gain from this? Could you elaborate a little closer to a real world example. -Martin From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 19:26:40 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09120; Wed, 25 Mar 98 19:26:40 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA05160 for cat-ietf-redist; Wed, 25 Mar 1998 17:30:10 -0500 (EST) From: "David Miller" Message-Id: <9803251426.ZM16949@engsol01.cybersafe.com> Date: Wed, 25 Mar 1998 14:26:26 -0800 In-Reply-To: "Theodore Y. Ts'o" "Re: generic nametypes and gss_import_name()" (Mar 25, 3:56pm) References: <199803252056.PAA29129@dcl.MIT.EDU> X-Mailer: Z-Mail (3.2.1 10apr95) To: "Theodore Y. Ts'o" , "David Miller" Subject: Re: generic nametypes and gss_import_name() Cc: "Linn, John" , "'Martin.Rex@sap-ag.de '" , "cat-ietf@MIT.EDU" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 25, 3:56pm, Theodore Y. Ts'o wrote: > Subject: Re: generic nametypes and gss_import_name() > David, > It's clear you're trying deal with issues that come up when you > implement a multi-mechanism adaptor mechanism, presumably which > interfaces to a number of mechanism's GSSAPI interfaces, and exports a > GSSAPI interface with the comabined mechanisms. Am I right? > Ted, Yes, I am concerned with a multimech implementation, most likely architected in the way you describe. > There are a number of things you might consider. The two which > I find most promising is to either try calling gss_import_name for all > mechanisms which your GSSAPI adaptor has registered, or possibly doing > lazy evaluation. Don't actually try to call the underlying > gss_import_name until you know for which mechanism you will be using the > gss_name. The problem with the latter is you won't know about errors in > gss_import name until very late in the game. > > There is a partially completed mechanism multi-mechanism adaptor > in the Krb5 sources. (It was donated to us by Sun.) I worked on this > for a while, but it turns out to be a tough problem to get right, > especially if you assume that the underlying low-level mechanisms are > completely independent. Still, if you're working on this project, it > might be worth taking a look at that effort. > > The approach taken in that code was that there was a > configuration file that listed certain name types as being > "mechanism-specific". If you called gss_import_name with one of those > name types, it would call the lower layer gss_import_name directly, so > that any errors would be returned right away. Otherwise, it would do > lazy evaluation, and simply store the passed-in name type and string. > > Trying to make such a multi-mechanism adaptor is an interesting > project, but please remember that the original design goal of the GSSAPI > did *not* include the requirement that it be possible to compose > disparate GSSAPI mechanisms together using only the GSSAPI mechanism > interfaces. It almost works, but there may be some tiny glitches, and > if you find any, please remember that this is outside GSSAPI's design > envelope before you start criticizing. :-) > These are the possibilities I was imagining. Thanks for pointing them out. Absent trying to implement mechanism authorization on a per-user basis, I might opt to just import names for all mechs. Next, I'd drop to your suggestion of using the mech-specific names. But again my thought there is that it obviates the purpose of having the generic nametypes in the first place. I'm still a bit puzzled on your comments on the GSS design goals though. I thought it was a goal to have GSS accommodate multiple mechanisms. (Be that by composition of disparate mechanisms, or by original multimech design. Is there an essential difference?) This is not such a burning issue for me in the next few days, but I thought I'd bring it up while I was thinking about it. I'm interested in knowing whether anyone thinks there could be merit (perhaps in V2+ if not V2) in an additional call that allows multimech names to be built. There seems to be all the functionality to build multimech creds in gss_add_cred(). Is there any sense in a call that imports names by mechanism, e.g. a "gss_import_name_by_mech()"? This would allow an arbitrary set of names (corresponding to some set of mechs) to be present in an internal name. At any rate, thank you for your explanation of possibilities to handle the present situation. David > - Ted >-- End of excerpt from Theodore Y. Ts'o -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 19:32:47 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09215; Wed, 25 Mar 98 19:32:47 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA12320 for cat-ietf-redist; Wed, 25 Mar 1998 18:44:26 -0500 (EST) Date: Wed, 25 Mar 1998 18:43:56 -0500 Message-Id: <199803252343.SAA29344@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "David Miller" Cc: "Theodore Y. Ts'o" , "David Miller" , "Linn, John" , "'Martin.Rex@sap-ag.de '" , "cat-ietf@MIT.EDU" In-Reply-To: David Miller's message of Wed, 25 Mar 1998 14:26:26 -0800, <9803251426.ZM16949@engsol01.cybersafe.com> Subject: Re: generic nametypes and gss_import_name() Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: "David Miller" Date: Wed, 25 Mar 1998 14:26:26 -0800 I'm still a bit puzzled on your comments on the GSS design goals though. I thought it was a goal to have GSS accommodate multiple mechanisms. (Be that by composition of disparate mechanisms, or by original multimech design. Is there an essential difference?) Yes, there is. If you consider the following architecture: GSSAPI Application ^ | GSSAPI Interface V GSSAPI Library ^ | +===============================+ Service Interface | | V V Mechanism 1 Mechanism 2 ... the goal of the GSSAPI was to serve as interface between the application and the GSSAPI library. I remember (a long time ago at this point) asking John Linn and the GSSAPI team at Digital, when the GSSAPI was first being designed, whether the GSSAPI was intended to service as the Application/Library interface, or also as the interface between the library and the lower-level mechanisms. The answer I got at the time was that the primary focus was the Application/Library interface, *not* the internal service interface between the library and the lower-level mechanisms. There have been claims made that the GSSAPI can also serve as the mechanism service interface in a multi-mechanism library. However, I've never been quite convinced that it works particularly well. The worst case appears on Windows platforms, where different mechanisms (located in DLL's) may link against different malloc() routines, such that an OID allocated by one mechanism's OID allocation routine may not be freeably by another mechanism's OID release function. It is certainly possible to implement GSSAPI libraries that provide support for multiple mechanisms, especially if there is a certain amount of incestuousness between the actual mechanism implementation and the high-level GSSAPI library glue. And while the service interface will look a lot like the GSSAPI, it may need to be extended to be able to cope with some of the fine details of supporting a multiple-mechanism GSSPI library. I'm interested in knowing whether anyone thinks there could be merit (perhaps in V2+ if not V2) in an additional call that allows multimech names to be built. There seems to be all the functionality to build multimech creds in gss_add_cred(). Is there any sense in a call that imports names by mechanism, e.g. a "gss_import_name_by_mech()"? This would allow an arbitrary set of names (corresponding to some set of mechs) to be present in an internal name. I'm not at all convinced. A credential being mechanism-specific is well understood. But what it means to have a name that is mechanism specific is not at all clear. Names have types; to introduce an orthognal typing system that is related to mechanisms seems to add a lot of complexity for an unclear gain. - Ted From owner-cat-ietf@pad-thai.cam.ov.com Wed Mar 25 20:33:40 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA10246; Wed, 25 Mar 98 20:33:40 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id TAA17676 for cat-ietf-redist; Wed, 25 Mar 1998 19:41:25 -0500 (EST) From: "David Miller" Message-Id: <9803251637.ZM17969@engsol01.cybersafe.com> Date: Wed, 25 Mar 1998 16:37:44 -0800 In-Reply-To: "Theodore Y. Ts'o" "Re: generic nametypes and gss_import_name()" (Mar 25, 6:43pm) References: <199803252343.SAA29344@dcl.MIT.EDU> X-Mailer: Z-Mail (3.2.1 10apr95) To: "Theodore Y. Ts'o" , "David Miller" Subject: Re: generic nametypes and gss_import_name() Cc: "Linn, John" , "'Martin.Rex@sap-ag.de '" , "cat-ietf@MIT.EDU" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 25, 6:43pm, Theodore Y. Ts'o wrote: > Subject: Re: generic nametypes and gss_import_name() > From: "David Miller" > Date: Wed, 25 Mar 1998 14:26:26 -0800 > I'm interested in knowing whether anyone thinks there could > be merit (perhaps in V2+ if not V2) in an additional call that > allows multimech names to be built. There seems to be all > the functionality to build multimech creds in gss_add_cred(). > Is there any sense in a call that imports names by mechanism, > e.g. a "gss_import_name_by_mech()"? This would allow an > arbitrary set of names (corresponding to some set of mechs) > to be present in an internal name. > > I'm not at all convinced. A credential being mechanism-specific is well > understood. But what it means to have a name that is mechanism specific > is not at all clear. Names have types; to introduce an orthognal typing > system that is related to mechanisms seems to add a lot of complexity > for an unclear gain. > The specs indicate that a gss_name_t, i.e. an internal name, may have multiple components. It's not that a name is mechanism-specific, it's that it holds multiple components, one per mechanism. These two paragraphs are from cbind-05: A single gss_name_t object may contain multiple names from different namespaces, but all names should refer to the same entity. An example of such an internal name would be the name returned from a call to the gss_inquire_cred routine, when applied to a credential containing credential elements for multiple authentication mechanisms employing different namespaces. This gss_name_t object will contain a distinct name for the entity for each authentication mechanism. For GSSAPI implementations supporting multiple namespaces, objects of type gss_name_t must contain sufficient information to determine the namespace to which each primitive name belongs. I can only assume that "namespace" here refers more accurately to "mechanism" rather than "nametype." Anyway, if an internal name does have multiple components, those components would be indexed, so to speak, by mechanism. For instance, component 1 is the internal Kerberos 5 name and component 2 is the internal SPKM name. They're not indexed by nametype, are they? The nametype only serves to describe the flat name so that it can be translated to a mechanism-unique internal form. After that, nametype information can be discarded. If this holds any water, then there is some concept of a name being imported for a particular mechanism. For that reason, I don't necessarily see association of names with mechanisms as an orthogonal typing, but the only typing. That's why I saw the necessity for specifying a mechanism when importing a name. (Unless, as in a previous note from Martin, that the correct tack on this is to import names for all mechanisms an implementation supports.) David > - Ted >-- End of excerpt from Theodore Y. Ts'o -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 26 10:44:41 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA25064; Thu, 26 Mar 98 10:44:41 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA00537 for cat-ietf-redist; Thu, 26 Mar 1998 09:20:06 -0500 (EST) Message-Id: <6B5344C210C7D011835C0000F80127660121115C@exna01.securitydynamics.com> From: "Linn, John" To: "'David Miller'" Cc: "cat-ietf@MIT.EDU" Subject: RE: generic nametypes and gss_import_name() Date: Thu, 26 Mar 1998 09:21:58 -0500 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk David wrote, excerpting: > That's why I saw the necessity for specifying a mechanism > when importing a name. (Unless, as in a previous note from Martin, > that > the correct tack on this is to import names for all mechanisms an > implementation supports.) > I agree with Martin's assessment on this. Selectively importing name components for only an application-specified subset of a GSS implementation's supported mechanisms would add complexity to caller applications, while (I believe) allowing optimization of only a small amount of underlying processing. --jl From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 26 11:39:17 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA26017; Thu, 26 Mar 98 11:39:17 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA00663 for cat-ietf-redist; Thu, 26 Mar 1998 09:20:48 -0500 (EST) From: John_Wray@iris.com X-Lotus-Fromdomain: IRIS To: "David Miller" Cc: cat-ietf@MIT.EDU Message-Id: <852565D3.0049ACEB.00@elektra.iris.com> Date: Thu, 26 Mar 1998 09:12:13 -0500 Subject: Re: generic nametypes and gss_import_name() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk David miller writes: >The specs indicate that a gss_name_t, i.e. an internal name, may have >multiple components. It's not that a name is mechanism-specific, it's >that it holds multiple components, one per mechanism. These two >paragraphs are from cbind-05: > > A single gss_name_t object may contain multiple names from > different namespaces, but all names should refer to the same > entity. An example of such an internal name would be the name > returned from a call to the gss_inquire_cred routine, when > applied to a credential containing credential elements for > multiple authentication mechanisms employing different > namespaces. This gss_name_t object will contain a distinct > name for the entity for each authentication mechanism. > > For GSSAPI implementations supporting multiple namespaces, > objects of type gss_name_t must contain sufficient information > to determine the namespace to which each primitive name > belongs. > >I can only assume that "namespace" here refers more accurately to >"mechanism" rather than "nametype." Anyway, if an internal name does >have multiple components, those components would be indexed, so to >speak, by mechanism. For instance, component 1 is the internal Kerberos >5 name and component 2 is the internal SPKM name. They're not indexed >by nametype, are they? The nametype only serves to describe the flat >name so that it can be translated to a mechanism-unique internal form. >After that, nametype information can be discarded. No, names are categorized according to namespace, not mechanism. Some namespaces are specific to a given mechanism (for example, a Kerberos name is probably meaningful only to Kerberos). However, some name types might be useful to multiple mechanisms (for example, a given GSSAPI might be capable of authenticating an X.500 name, or an RFC822 name via more than one mechanism). Assume I have a GSSAPI that supports two authentication mechanisms, both of which authenticate X.500 names. A reasonable GSSAPI implementation decision would be to support two namespaces for printable-format names: X.500 and local OS account name. If presented with an X.500 name, gss_import_name() would either convert it to a form suitable for presentation to either mechanism (which might be an XDS-format name), or could simply store it in string-form. If presented with a local OS name, the GSSAPI layer would use configuration data to map this into an X.500 name. The sort of configuration data that could be used might be a default mapping for the entire machine (e.g. account maps to /C=us/O=org/OU=users/CN=) or an explicit mapping given in a per-user record retrieved from the machine registry or the local directory service. The internal name-form might retain information about both namespaces (for a name presented as a local OS name), but it is also permissible for the GSSAPI to discard the local OS name (it's never actually going to be passed to a mechanism). Neither name-form is particularly associated with one of the two mechanisms rather than the other. If a GSSAPI suppports multiple very different mechanisms, you're probably going to end up with one name-space per mechanism (plus a handful of other namespaces for things like local names, if you decide to support them). However, if there is some similarity between supported mechanisms (and especially if mechanisms share credentials), there are likely to be fewer namespaces than mechanisms (which is goodness, since users don't want to have to deal with multiple names, but security people want to be able to choose the most appropriate mechanism for the situation). For example, I expect many distinct public key mechanisms to use a private key and X.509 certificate as an initiator credential, and a set of certificates for trusted CAs as an acceptor credential. All such mechanisms are likely to agree on the namespace(s): it's those things that can appear in the subjectName or altSubjectName field(s) of a certificate. Where there's this level of commonality between mechanisms, there's no reason to store multiple identical "mechanism-specific" versions of a single name. John From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 26 15:32:36 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00412; Thu, 26 Mar 98 15:32:36 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA03205 for cat-ietf-redist; Thu, 26 Mar 1998 14:54:34 -0500 (EST) From: "David Miller" Message-Id: <980326115349.ZM7220@engsol01.cybersafe.com> Date: Thu, 26 Mar 1998 11:53:49 -0800 In-Reply-To: "Linn, John" "RE: generic nametypes and gss_import_name()" (Mar 26, 9:21am) References: <6B5344C210C7D011835C0000F80127660121115C@exna01.securitydynamics.com> X-Mailer: Z-Mail (5.0.0 30July97) To: "Linn, John" , "'David Miller'" Subject: Re: generic nametypes and gss_import_name() Cc: "cat-ietf@MIT.EDU" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 26, 9:21am, Linn, John wrote: > Subject: RE: generic nametypes and gss_import_name() > David wrote, excerpting: > > > That's why I saw the necessity for specifying a mechanism > > when importing a name. (Unless, as in a previous note from Martin, > > that > > the correct tack on this is to import names for all mechanisms an > > implementation supports.) > > > I agree with Martin's assessment on this. Selectively importing name > components for only an application-specified subset of a GSS > implementation's supported mechanisms would add complexity to caller > applications, while (I believe) allowing optimization of only a small > amount of underlying processing. > John and others, Thank you all for your discussion of this; I will rest with the resolution that John described. I'm satisfied that I at least know that there is an issue of names and the mechanism that they are imported for. I will assume that a gss_import_name() attempts to import the name for each mechanism implemented, and that results in an internal name that has at most one component for each supported mechanism, and perhaps less when mechanisms can share internal name forms. David > --jl > > >-- End of excerpt from Linn, John -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Thu Mar 26 19:32:14 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05016; Thu, 26 Mar 98 19:32:14 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA22387 for cat-ietf-redist; Thu, 26 Mar 1998 18:13:16 -0500 (EST) From: "David Miller" Message-Id: <980326151248.ZM9008@engsol01.cybersafe.com> Date: Thu, 26 Mar 1998 15:12:48 -0800 X-Mailer: Z-Mail (5.0.0 30July97) To: jlinn@securitydynamics.com Subject: Re: generic nametypes and gss_import_name() Cc: david.miller@CyberSafe.COM, cat-ietf@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Mar 26, 9:21am, Linn, John wrote: > Subject: RE: generic nametypes and gss_import_name() > David wrote, excerpting: > > > That's why I saw the necessity for specifying a mechanism > > when importing a name. (Unless, as in a previous note from Martin, > > that > > the correct tack on this is to import names for all mechanisms an > > implementation supports.) > > > I agree with Martin's assessment on this. Selectively importing name > components for only an application-specified subset of a GSS > implementation's supported mechanisms would add complexity to caller > applications, while (I believe) allowing optimization of only a small > amount of underlying processing. > John and others, Thank you all for your discussion of this topic. I'm satisfied that I at least know that there is an issue of names and the mechanism that they are imported for. I will assume that a gss_import_name() using a generic nametype attempts to import the name for each mechanism implemented, and that results in an internal name that has at most one component for each supported mechanism, and perhaps less when mechanisms can share internal name forms. David > --jl > > >-- End of excerpt from Linn, John -- David S. Miller david.miller@cybersafe.com CyberSafe Corporation 425.391.6000 Disclaimer: Opinions expressed here do not necessarily reflect those of the Cybersafe Corporation. From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 27 17:29:18 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27908; Fri, 27 Mar 98 17:29:18 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA24930 for cat-ietf-redist; Fri, 27 Mar 1998 16:20:20 -0500 (EST) From: Brian Tung Date: Fri, 27 Mar 1998 13:20:12 -0800 (PST) Message-Id: <199803272120.NAA12987@dot.isi.edu> To: cat-ietf@mit.edu Subject: a note about PKINIT and PKCROSS Precedence: bulk In a pair of forthcoming notes, I will post PKINIT and PKCROSS. Here are some short notes concerning these drafts (neither of which have changed much). PKINIT: The principal technical change has been the modification of the Signature data structure to align itself more closely with PKCS-1. There is a new Security Considerations section, at the behest of Denis. There are some other minor textual changes. PKCROSS: There are no technical changes. A comment about KDC-to-KDC communications has been added. The authors feel that there is a trade-off between having the KDC-to-KDC exchange and thereby buying a guarantee, so to speak, that the remote KDC will accept the ticket, and not having that exchange and possibly having tickets rejected after being issued. We choose the former so that the operation from the client's perspective is unchanged. b From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 27 18:19:21 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA28781; Fri, 27 Mar 98 18:19:21 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA24963 for cat-ietf-redist; Fri, 27 Mar 1998 16:20:40 -0500 (EST) Date: Fri, 27 Mar 1998 13:23:54 -0800 From: Brian Tung Message-Id: <199803272123.NAA18668@blt.isi.edu> To: cat-ietf@mit.edu Subject: PKCROSS as it appeared on I-D servers Precedence: bulk INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-cross-04.txt Tatyana Ryutov Updates: RFC 1510 Clifford Neuman expires September 15, 1998 Gene Tsudik ISI Bill Sommerfeld Hewlett-Packard Ari Medvinsky Matthew Hur CyberSafe Corporation Public Key Cryptography for Cross-Realm Authentication in Kerberos 0. Status Of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (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-cross-04.txt, and expires September 15, 1998. Please send comments to the authors. 1. Abstract This document defines extensions to the Kerberos protocol specification (RFC 1510, "The Kerberos Network Authentication Service (V5)", September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. 2. Introduction The advantages provided by public key cryptography have produced a demand for use by the Kerberos authentication protocol. A draft describing the use of public key cryptography in the initial authentication exchange in Kerberos has already been submitted. This draft describes its use in cross-realm authentication. The principal advantage provided by public key cryptography in cross-realm authentication lies in the ability to leverage the existing public key infrastructure. It frees the Kerberos realm administrator from having to maintain separate keys for each other realm with which it wishes to exchange authentication information, or from having to utilize a hierarchical arrangement, which may pose problems of trust. Even with the multi-hop cross-realm authentication, there must be some way to locate the path by which separate realms are to be transited. The current method, which makes use of the DNS-like realm names typical to Kerberos, requires trust of the intermediate KDCs. The methods described in this draft allow a realm to specify, at the time of authentication, which certification paths it will trust. A shared key for cross-realm authentication can be established for a set period of time. Furthermore, these methods are transparent to the client; therefore, only the KDCs need to be modified to use them. It is not necessary to implement the changes described in the "Public Key Cryptography for Initial Authentication" draft to make use of the changes in this draft. We solicit comments about the interaction between the two protocol changes, but as of this writing, the authors do not perceive any obstacles to using both. 3. Protocol Specification We assume that the client has already obtained a TGT. To perform cross-realm authentication, the client does exactly what it does with ordinary (i.e., non-public-key-enabled) Kerberos; the only changes are in the KDC; although the ticket which the client forwards to the remote realm may be changed. This is acceptable since the client treats the ticket as opaque. The revised PKCROSS protocol makes use of a proposed field in the Kerberos response, namely a TicketExtension. This field is not part of the encrypted part of the ticket (although it may have been encrypted earlier), but it accompanies the ticket and should be passed along by unaware clients with the rest of the ticket in an opaque fashion. Using this field allows us to achieve the following objectives: * Avoid modification of clients and application servers. * Allow remote KDC to control its policy on cross-realm keys shared between KDCs, and on cross-realm tickets presented by clients. * Remove any need for KDCs to maintain state about keys shared with other KDCs. * Leverage work already done for PKINIT. 3.1. Overview of Protocol Changes The basic operation of the revised PKCROSS protocol is as follows: 1. The client submits a request to the local KDC for credentials for the remote realm. 2. The local KDC submits a PKINIT request to the remote KDC. This request has a flag set to indicate that the request is a special cross-realm key request. 3. The remote KDC responds as per PKINIT, except that the ticket contains a TicketExtension which indicates that this is a cross-realm key response. The TicketExtension may also contain policy information, which the local KDC must reflect in the credentials it forwards to the client. Call this ticket TGT_{L,R}. 4. The local KDC passes a ticket, TGT_{C,R}, to the client. This ticket contains in its TicketExtension field the cross-realm key ticket, TGT_{L,R}. This ticket is encrypted using the key sealed in TGT_{L,R}. (The TicketExtension field is not encrypted.) The local KDC may optionally include another TicketExtension type that indicates the hostname and/or IP address for the remote KDC. 5. The client submits the request directly to the remote KDC, as before. Sections 3.2 through 3.4 describe in detail steps 2 through 4 above. Section 3.5 describes the conditions under which steps 2 and 3 may be skipped. A comment about the KDC-to-KDC communication present in these protocol changes. If there is no such exchange between the KDCs, then the local KDC will have to issue a ticket with the expectation that the remote KDC will accept it, but no guarantee. This is a simple trade-off: non-repudiability of the ticket, so to speak, or avoiding KDC-to-KDC communication. As a matter of principle, we choose the former, so that operation from the client's perspective is unchanged. 3.2. Local KDC's PKINIT Request to Remote KDC When the local KDC receives a request for cross-realm authentication, it sends a request to the remote KDC for a ticket, denoted by TGT_{L,R}. This request is in fact a PKINIT request as described in Section 3.2 of the PKINIT draft; i.e., it consists of an AS-REQ, with a PA-PK-AS-REQ included as a preauthentication field. In addition, the local KDC indicates that this request is for a PKCROSS cross-realm key, by setting bit 9 in the kdc-options field of the AS-REQ. We propose to call this bit the PKCROSSKEY flag. Otherwise, this exchange exactly follows the description given by Section 3.2 of the PKINIT draft. 3.3. Remote KDC's PKINIT Response to Local KDC When the remote KDC receives the PKINIT/CROSS request from the local KDC, it sends back a PKINIT response as described in Section 3.2 of the PKINIT draft, with the following changes: The remote KDC does not encrypt the encryptedTktPart with a random key, as described in the PKINIT draft, but instead encrypts it with a special symmetric key it uses for validating PKCROSS requests. This key, instead of a random key, is then placed in an envelope as described in the PKINIT draft. In addition, a TicketExtension field of type 2 (TE-TYPE-PKCROSS) is included with the ticket (as a non-encrypted part): TicketExtension ::= SEQUENCE OF SEQUENCE { te-type[0] INTEGER, te-data[1] OCTET STRING } -- per the revised Kerberos specification where te-type equals 2 for TE-TYPE-PKCROSS-KDC and te-data is ASN.1 encoding of CrossRealmTktData. CrossRealmTktData ::= SEQUENCE OF SEQUENCE { type [0] INTEGER, data [1] OCTET STRING } where types and the corresponding data are to be interpreted as follows: type interpretation data is ASN.1 encoding of ---- -------------- ------------------------- 1 lifetime (in seconds) INTEGER Further types may be added to this table. 3.4. Local KDC's Response to Client Upon receipt of the PKINIT/CROSS response from the remote KDC, the local KDC formulates a response to the client. This reply is constructed exactly as in the Kerberos specification, except for the following: * The local KDC places TGT_{L,R} in the TicketExtension field of the client's ticket for the remote realm (denoted here by TGT_{C,R}). * The local KDC adds the name of its CA to the transited field of TGT_(C,R). TicketExtension ::= SEQUENCE OF SEQUENCE { te-type[0] INTEGER, te-data[1] OCTET STRING } -- per the revised Kerberos specification where te-type equals 3 for TE-TYPE-PKCROSS-CLIENT and te-data is ASN.1 encoding of TGT_(L,R). Optionally, the local KDC may add another TicketExtention where te-type equals 5 for TE-TYPE-DEST-HOST and te-data is ASN.1 encoding of DestHost. A client could then rely on the local KDC to provide a referral to the remote KDC, thus removing the need for the client to maintain local host/realm mapping information. DestHost ::= SEQUENCE { DNSHostname [0] OCTET STRING, -- authoritative DNS hostname HostAddr [1] HostAddress OPTIONAL -- as defined by RFC 1510 } 3.5. Short-Circuiting the KDC-to-KDC Exchange Under certain circumstances, the KDC-to-KDC exchange described in Sections 3.2 and 3.3 may be skipped. The local KDC has a known lifetime for TGT_{C,R} (which may in part be determined by the policy sent along with TGT_{L,R}). If the local KDC already has a ticket TGT_{L,R}, and the start time plus the lifetime for TGT_{C,R} does not exceed the expiration time for TGT_{L,R}, then the local KDC may skip the exchange with the remote KDC, and issue a cross-realm ticket to the client as described in Section 3.4. Since the remote KDC may change the special cross-realm symmetric key (referred to in Section 3.2) while there are cross-realm key tickets (the TGT_{L,R}) still active, it is obligated to cache those tickets until they expire. 4. Transport Issues Because the messages between the KDCs involve PKINIT exchanges, and PKINIT recommends TCP as a transport mechanism (due to the length of the messages and the likelihood that they will fragment), the same recommendation for TCP applies to PKCROSS as well. 5. Expiration Date This Internet-Draft will expire on September 15, 1998. 6. Authors' Addresses Brian Tung Tatyana Ryutov Clifford Neuman Gene Tsudik USC/Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey, CA 90292-6695 Phone: +1 310 822 1511 E-Mail: {brian, tryutov, bcn, gts}@isi.edu Bill Sommerfeld Hewlett Packard 300 Apollo Drive Chelmsford MA 01824 Phone: +1 508 436 4352 E-Mail: sommerfeld@apollo.hp.com Ari Medvinsky Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah WA 98027-5378 Phone: +1 206 391 6000 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com From owner-cat-ietf@pad-thai.cam.ov.com Fri Mar 27 18:33:08 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA29029; Fri, 27 Mar 98 18:33:08 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA24971 for cat-ietf-redist; Fri, 27 Mar 1998 16:21:03 -0500 (EST) Date: Fri, 27 Mar 1998 13:24:13 -0800 From: Brian Tung Message-Id: <199803272124.NAA18673@blt.isi.edu> To: cat-ietf@MIT.EDU Subject: PKINIT as it appeared on I-D servers Precedence: bulk INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-init-05.txt Clifford Neuman Updates: RFC 1510 ISI expires September 15, 1998 John Wray Digital Equipment Corporation Ari Medvinsky Matthew Hur CyberSafe Corporation Jonathan Trostle Novell Public Key Cryptography for Initial Authentication in Kerberos 0. Status Of This Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (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-05.txt, and expires September 15, 1998. 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. One of the guiding principles in the design of PKINIT is that changes should be as minimal as possible. As a result, the basic mechanism of PKINIT is as follows: The user sends a request to the KDC as before, except that if that user is to use public key cryptography in the initial authentication step, his certificate accompanies 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 in a randomly-generated key, instead of the user's long-term key (which is derived from a password). This random key is in turn encrypted using the public key from the certificate that came with the request and signed using the KDC's private key, and accompanies the reply, in the preauthentication fields. PKINIT also allows for users with only digital signature keys to authenticate using those keys, and for users to store and retrieve private keys on the KDC. The PKINIT specification may also be used for direct peer to peer authentication without contacting a central KDC. This application of PKINIT is described in PKTAPP [4] and is based on concepts introduced in [5, 6]. 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 SSL [7] 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 [8]). 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 changes to RFC 1510 are 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. * Users may store private keys on the KDC for retrieval during Kerberos initial authentication. This proposal addresses two ways that users may use public key cryptography for initial authentication. Users may present public key certificates, or they may generate their own session key, signed by their digital signature key. In either case, the end result is that the user 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 and 3.3 describe the extensions for the two initial authentication methods. Section 3.4 describes a way for the user to store and retrieve his private key on the KDC, as an adjunct to the initial authentication. 3.1. Definitions The extensions involve new encryption methods; we propose the addition of the following types: dsa-sign 8 rsa-priv 9 rsa-pub 10 rsa-pub-md5 11 rsa-pub-sha1 12 The proposal of these encryption types notwithstanding, we do not mandate the use of any particular public key encryption method. The extensions involve new preauthentication fields; we propose the addition of the following types: PA-PK-AS-REQ 14 PA-PK-AS-REP 15 PA-PK-AS-SIGN 16 PA-PK-KEY-REQ 17 PA-PK-KEY-REP 18 The extensions also involve new error types; we propose the addition of 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 In addition, PKINIT does not define, but does permit, the following algorithm identifiers for use with the Signature data structure: md4WithRSAEncryption (as defined in PKCS 1) md5WithRSAEncryption (as defined in PKCS 1) sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2) dsaWithSHA1(27) } where OIW ::= iso(1) identifiedOrganization(3) oIW(14) In many cases, PKINIT requires the encoding of an X.500 name as a Realm. In these cases, the realm will be represented using a different style, specified in RFC 1510 with the following example: NAMETYPE:rest/of.name=without-restrictions For a realm derived from an X.500 name, NAMETYPE will have the value X500-RFC1779. The full realm name will appear as follows: X500-RFC1779:RFC1779Encode(DistinguishedName) where DistinguishedName is an X.500 name, and RFC1779Encode is a readable ASCII encoding of an X.500 name, as defined by RFC 1779. To ensure that this encoding is unique, we add the following rules to those specified by RFC 1779: * The optional spaces specified in RFC 1779 are not allowed. * The character that separates relative distinguished names must be ',' (i.e., it must never be ';'). * Attribute values must not be enclosed in double quotes. * Attribute values must not be specified as hexadecimal numbers. * When an attribute name is specified in the form of an OID, it must start with the 'OID.' prefix, and not the 'oid.' prefix. * The order in which the attributes appear in the RFC 1779 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, because RFC 1779 requires that the least significant relative distinguished name appear first. The order of the relative distinguished names, as well as the order of the attributes within each relative distinguished name, will be reversed. Similarly, PKINIT may require the encoding of an X.500 name as a PrincipalName. In these cases, the name-type of the principal name shall be set to NT-X500-PRINCIPAL. This new name type is defined as: #define CSFC5c_NT_X500_PRINCIPAL 6 The name-string shall be set as follows: RFC1779Encode(DistinguishedName) as described above. 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. All additional symmetric keys specified in this draft shall use the same encryption type as the session key in the response from the KDC. These include the temporary keys used to encrypt the signed random key encrypting the response, as well as the key derived from Diffie-Hellman agreement. 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. RFC 1510, Section 6.1, defines EncryptedData as follows: EncryptedData ::= SEQUENCE { etype [0] INTEGER, kvno [1] INTEGER OPTIONAL, cipher [2] OCTET STRING -- is CipherText } RFC 1510 also defines how CipherText is to be composed. It is not an ASN.1 data structure, but rather an octet string which is the encryption of a plaintext string. This plaintext string is in turn a concatenation of the following octet strings: a confounder, a checksum, the message, and padding. Details of how these components are arranged can be found in RFC 1510. The PKINIT protocol introduces several new types of encryption. Data that is encrypted with a public key will allow only the check optional field, as it is defined above. This type of the checksum will be specified in the etype field, together with the encryption type. In order to identify the checksum type, etype will have the following values: rsa-pub-MD5 rsa-pub-SHA1 In the case that etype is set to rsa-pub, the optional 'check' field will not be provided. Data that is encrypted with a private key will not use any optional fields. PKINIT uses private key encryption only for signatures, which are encrypted checksums. Therefore, the optional check field is not needed. 3.2. Standard Public Key Authentication Implementation of the changes in this section is REQUIRED for compliance with PKINIT. It is assumed that all public keys are signed by some certification authority (CA). 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] SignedAuthPack userCert [1] SEQUENCE OF Certificate OPTIONAL, -- the user's certificate chain trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, -- CAs that the client trusts serialNumber [3] CertificateSerialNumber OPTIONAL -- specifying a particular -- certificate if the client -- already has it; -- must be accompanied by -- a single trustedCertifier } CertificateSerialNumber ::= INTEGER -- as specified by PKCS 6 SignedAuthPack ::= SEQUENCE { authPack [0] AuthPack, authPackSig [1] Signature, -- of authPack -- using user's private key } AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL -- if client is using Diffie-Hellman } PKAuthenticator ::= SEQUENCE { kdcName [0] PrincipalName, kdcRealm [1] Realm, cusec [2] INTEGER, -- for replay prevention ctime [3] KerberosTime, -- for replay prevention nonce [4] INTEGER } Signature ::= SEQUENCE { signatureAlgorithm [0] SignatureAlgorithmIdentifier, pkcsSignature [1] BIT STRING -- octet-aligned big-endian bit -- string (encrypted with signer's -- private key) } SignatureAlgorithmIdentifier ::= AlgorithmIdentifier AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id, -- for DH, equals -- dhKeyAgreement -- ({iso(1) member-body(2) US(840) -- rsadsi(113549) pkcs(1) pkcs-3(3) -- 1}) parameters ALGORITHM.&type -- for DH, is DHParameter } -- as specified by the X.509 recommendation [9] SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING -- for DH, equals -- public exponent (INTEGER encoded -- as payload of BIT STRING) } -- as specified by the X.509 recommendation [9] DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER, -- g privateValueLength INTEGER OPTIONAL } -- as specified by the X.509 recommendation [9] Certificate ::= SEQUENCE { certType [0] INTEGER, -- type of certificate -- 1 = X.509v3 (DER encoding) -- 2 = PGP (per PGP specification) certData [1] OCTET STRING -- actual certificate -- type determined by certType } If the client passes a certificate 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 PKAuthenticator carries information to foil replay attacks, to bind the request and response, and to optionally pass the client's Diffie-Hellman public value (i.e. for using DSA in combination with Diffie-Hellman). The PKAuthenticator is signed with the private key corresponding to the public key in the certificate found in userCert (or cached by the KDC). In the PKAuthenticator, the client may specify the KDC name in one of two ways: * The Kerberos principal name krbtgt/@, where is replaced by the applicable realm name. * The name in the KDC's certificate (e.g., an X.500 name, or a PGP name). Note that the first case requires that the certificate name and the Kerberos principal name be bound together (e.g., via an X.509v3 extension). The userCert field is a sequence of certificates, the first of which must be the user's public key certificate. Any subsequent certificates will be certificates of the certifiers of the user's certificate. These cerificates may be used by the KDC to verify the user's public key. This field may be left empty if the KDC already has the user's certificate. 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_CERTIFICATE_MISMATCH. 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 verification of the user's certificate fails, the KDC sends back an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. The e-data field contains additional information pertaining to this error, and is formatted as follows: METHOD-DATA ::= SEQUENCE { method-type [0] INTEGER, -- 1 = cannot verify public key -- 2 = invalid certificate -- 3 = revoked certificate -- 4 = invalid KDC name -- 5 = client name mismatch method-data [1] OCTET STRING OPTIONAL } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510) The values for the method-type and method-data fields are described in Section 3.2.1. If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC verifies that it has a certificate issued by one of the certifiers trusted by the client. If it does not have a suitable certificate, the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the client. 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 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. 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. Assuming no errors, the KDC replies as per RFC 1510, except as follows: The user's name in the ticket is as represented in the certificate, unless a Kerberos principal name is bound to the name in the certificate (e.g., via an X.509v3 extension). The user's realm in the ticket shall be the name of the Certification Authority that issued the user's public key certificate. The KDC encrypts the reply not with the user's long-term key, but with a random key generated only for this particular response. This random key is sealed in the preauthentication field: PA-PK-AS-REP ::= SEQUENCE { -- PA TYPE 15 encSignedReplyKeyPack [0] EncryptedData, -- of type SignedReplyKeyPack -- using the temporary key -- in encTmpKey encTmpKeyPack [1] EncryptedData, -- of type TmpKeyPack -- using either the client public -- key or the Diffie-Hellman key -- specified by SignedDHPublicValue signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL -- if one was passed in the request kdcCert [3] SEQUENCE OF Certificate OPTIONAL, -- the KDC's certificate chain } SignedReplyKeyPack ::= SEQUENCE { replyKeyPack [0] ReplyKeyPack, replyKeyPackSig [1] Signature, -- of replyEncKeyPack -- using KDC's private key } ReplyKeyPack ::= SEQUENCE { replyKey [0] EncryptionKey, -- used to encrypt main reply -- of same ENCTYPE as session key nonce [1] INTEGER -- binds response to the request -- must be same as the nonce -- passed in the PKAuthenticator } TmpKeyPack ::= SEQUENCE { tmpKey [0] EncryptionKey, -- used to encrypt the -- SignedReplyKeyPack -- of same ENCTYPE as session key } SignedKDCPublicValue ::= SEQUENCE { kdcPublicValue [0] SubjectPublicKeyInfo, -- as described above kdcPublicValueSig [1] Signature -- of kdcPublicValue -- using KDC's private key } The kdcCert field is a sequence of certificates, the first of which must be the KDC's public key certificate. Any subsequent certificates will be certificates of the certifiers of the KDC's certificate. The last of these must have as its certifier one of the certifiers sent to the KDC in the PA-PK-AS-REQ. These cerificates may be used by the client to verify the KDC's public key. This field is empty if the client did not send to the KDC a list of trusted certifiers (the trustedCertifiers field was empty). Since each certifier in the certification path of a user's certificate is essentially a separate realm, the name of each certifier shall 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 must bind the public key to a name derivable from the name of the realm for that KDC. For an X.509 certificate, this is done as follows. The name of the KDC will be represented as an OtherName, encoded as a GeneralString: GeneralName ::= CHOICE { otherName [0] KDCPrincipalName, ... } KDCPrincipalNameTypes OTHER-NAME ::= { { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } } KDCPrincipalName ::= SEQUENCE { nameType [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ), name [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes } { @nameType } ) } PrincipalNameSrvInst ::= GeneralString where (from the Kerberos specification) we have krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) } principalName OBJECT IDENTIFIER ::= { krb5 2 } principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 } 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. 3.2.1. Additional Information for Errors This section describes the interpretation of the method-type and method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error. If method-type=1, the client's public key certificate chain does not contain a certificate that is signed by a certification authority trusted by the KDC. The format of the method-data field will be an ASN.1 encoding of a list of trusted certifiers, as defined above: TrustedCertifiers ::= SEQUENCE OF PrincipalName If method-type=2, the signature on one of the certificates in the chain cannot be verified. The format of the method-data field will be an ASN.1 encoding of the integer index of the certificate in question: CertificateIndex ::= INTEGER -- 0 = 1st certificate, -- 1 = 2nd certificate, etc If method-type=3, one of the certificates in the chain has been revoked. The format of the method-data field will be an ASN.1 encoding of the integer index of the certificate in question: CertificateIndex ::= INTEGER -- 0 = 1st certificate, -- 1 = 2nd certificate, etc If method-type=4, the KDC name or realm in the PKAuthenticator does not match the principal name of the KDC. There is no method-data field in this case. If method-type=5, the client name or realm in the certificate does not match the principal name of the client. There is no method-data field in this case. 3.3. Digital Signature Implementation of the changes in this section are OPTIONAL for compliance with PKINIT. We offer this option with the warning that it requires the client to generate a random key; the client may not be able to guarantee the same level of randomness as the KDC. If the user registered, or presents a certificate for, a digital signature key with the KDC instead of an encryption key, then a separate exchange must be used. The client sends a request for a TGT as usual, except that it (rather than the KDC) generates the random key that will be used to encrypt the KDC response. This key is sent to the KDC along with the request in a preauthentication field, encrypted with the KDC's public key: PA-PK-AS-SIGN ::= SEQUENCE { -- PA TYPE 16 encSignedRandomKeyPack [0] EncryptedData, -- of type SignedRandomKeyPack -- using the key in encTmpKeyPack encTmpKeyPack [1] EncryptedData, -- of type TmpKeyPack -- using the KDC's public key userCert [2] SEQUENCE OF Certificate OPTIONAL -- the user's certificate chain } SignedRandomKeyPack ::= SEQUENCE { randomkeyPack [0] RandomKeyPack, randomkeyPackSig [1] Signature -- of keyPack -- using user's private key } RandomKeyPack ::= SEQUENCE { randomKey [0] EncryptionKey, -- will be used to encrypt reply randomKeyAuth [1] PKAuthenticator -- nonce copied from AS-REQ } If the KDC does not accept client-generated random keys as a matter of policy, then it sends back an error message of type KDC_ERR_KEY_TOO_WEAK. Otherwise, it extracts the random key as follows. Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies the randomKey. It then replies as per RFC 1510, except that the reply is encrypted not with a password-derived user key, but with the randomKey sent in the request. Since the client already knows this key, there is no need to accompany the reply with an extra preauthentication field. The transited field of the ticket should specify the certification path as described in Section 3.2. 3.4. Retrieving the User's Private Key from the KDC Implementation of the changes described in this section are OPTIONAL for compliance with PKINIT. When the user's private key is not stored local to the user, he may choose to store the private key (normally encrypted using a password-derived key) on the KDC. In this case, the client makes a request as described above, except that instead of preauthenticating with his private key, he uses a symmetric key shared with the KDC. For simplicity's sake, this shared key is derived from the password- derived key used to encrypt the private key, in such a way that the KDC can authenticate the user with the shared key without being able to extract the private key. We provide this option to present the user with an alternative to storing the private key on local disk at each machine where he expects to authenticate himself using PKINIT. It should be noted that it replaces the added risk of long-term storage of the private key on possibly many workstations with the added risk of storing the private key on the KDC in a form vulnerable to brute-force attack. Denote by K1 the symmetric key used to encrypt the private key. Then construct symmetric key K2 as follows: * Perform a hash on K1. * Truncate the digest to Length(K1) bytes. * Rectify parity in each byte (if necessary) to obtain K2. The KDC stores K2, the public key, and the encrypted private key. This key pair is designated as the "primary" key pair for that user. This primary key pair is the one used to perform initial authentication using the PA-PK-AS-REP preauthentication field. If he desires, he may also store additional key pairs on the KDC; these may be requested in addition to the primary. When the client requests initial authentication using public key cryptography, it must then include in its request, instead of a PA-PK-AS-REQ, the following preauthentication sequence: PA-PK-KEY-REQ ::= SEQUENCE { -- PA TYPE 17 signedPKAuth [0] SignedPKAuth, trustedCertifiers [1] SEQUENCE OF PrincipalName OPTIONAL, -- CAs that the client trusts keyIDList [2] SEQUENCE OF Checksum OPTIONAL -- payload is hash of public key -- corresponding to desired -- private key -- if absent, KDC will return all -- stored private keys } Checksum ::= SEQUENCE { cksumtype [0] INTEGER, checksum [1] OCTET STRING } -- as specified by RFC 1510 SignedPKAuth ::= SEQUENCE { pkAuth [0] PKAuthenticator, pkAuthSig [1] Signature -- of pkAuth -- using the symmetric key K2 } If a keyIDList is present, the first identifier should indicate the primary private key. No public key certificate is required, since the KDC stores the public key along with the private key. If there is no keyIDList, all the user's private keys are returned. Upon receipt, the KDC verifies the signature using K2. If the verification fails, the KDC sends back an error of type KDC_ERR_INVALID_SIG. If the signature verifies, but the requested keys are not found on the KDC, then the KDC sends back an error of type KDC_ERR_PREAUTH_FAILED. If all checks out, the KDC responds as described in Section 3.2, except that in addition, the KDC appends the following preauthentication sequence: PA-PK-KEY-REP ::= SEQUENCE { -- PA TYPE 18 encKeyRep [0] EncryptedData -- of type EncKeyReply -- using the symmetric key K2 } EncKeyReply ::= SEQUENCE { keyPackList [0] SEQUENCE OF KeyPack, -- the first KeyPair is -- the primary key pair nonce [1] INTEGER -- binds reply to request -- must be identical to the nonce -- sent in the SignedAuthPack } KeyPack ::= SEQUENCE { keyID [0] Checksum, encPrivKey [1] OCTET STRING } Upon receipt of the reply, the client extracts the encrypted private keys (and may store them, at the client's option). The primary private key, which must be the first private key in the keyPack SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP; this key in turn is used to decrypt the main reply as described in Section 3.2. 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 that use either the Standard Public Key Authentication or Public Key Authentication with a Digital Signature. However, if these users are registered with the KDC, it is recommended that the database record for these users be modified to include three additional flags in the attributes field. The first flag, use_standard_pk_init, indicates that the user should authenticate using standard PKINIT as described in Section 3.2. The second flag, use_digital_signature, indicates that the user should authenticate using digital signature PKINIT as described in Section 3.3. The third flag, store_private_key, indicates that the user has stored his private key on the KDC and should retrieve it using the exchange described in Section 3.4. If one of the preauthentication fields defined above is included in the request, then the KDC shall respond as described in Sections 3.2 through 3.4, ignoring the aforementioned database flags. If more than one of the preauthentication fields is present, the KDC shall respond with an error of type KDC_ERR_PREAUTH_FAILED. In the event that none of the preauthentication fields defined above are included in the request, the KDC checks to see if any of the above flags are set. If the first flag is set, then it sends back an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of type PA-PK-AS-REQ must be included in the request. Otherwise, if the first flag is clear, but the second flag is set, then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of type PA-PK-AS-SIGN must be included in the request. Lastly, if the first two flags are clear, but the third flag is set, then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of type PA-PK-KEY-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 order to simplify key management, 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. 5. 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. 6. 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] A. Medvinsky, M. Hur. Addition of Kerberos Cipher Suites to Transport Layer Security (TLS). draft-ietf-tls-kerb-cipher-suites-00.txt [4] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-cat-pktapp-00.txt [5] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed System Security, 1997. [6] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, July 1995. [7] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL Protocol, Version 3.0 - IETF Draft. [8] B.C. Neuman, Proxy-Based Authorization and Accounting for Distributed Systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, May 1993. [9] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8 7. Acknowledgements Sasha Medvinsky contributed several ideas to the protocol changes and specifications in this document. His additions have been most appreciated. 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. 8. Expiration Date This draft expires September 15, 1998. 9. 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 John Wray Digital Equipment Corporation 550 King Street, LKG2-2/Z7 Littleton, MA 01460 Phone: +1 508 486 5210 E-mail: wray@tuxedo.enet.dec.com Ari Medvinsky Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah WA 98027-5378 Phone: +1 206 391 6000 E-mail: {ari.medvinsky, matt.hur}@cybersafe.com Jonathan Trostle Novell Corporation Provo UT E-mail: jtrostle@novell.com From owner-cat-ietf@pad-thai.cam.ov.com Sat Mar 28 15:29:13 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA20736; Sat, 28 Mar 98 15:29:13 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA26834 for cat-ietf-redist; Sat, 28 Mar 1998 14:31:22 -0500 (EST) Message-Id: <351D4EB6.6D47B63F@dascom.com> Date: Sat, 28 Mar 1998 11:25:42 -0800 From: Greg Clark X-Mailer: Mozilla 4.01 [en] (WinNT; I) Mime-Version: 1.0 To: cat-ietf@mit.edu Cc: "'Dave Hemsath'" Subject: Using Cryptographic Message Format (CMS) in PKINIT X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk IETF CAT Working Group Folks, I'd like to propose a extension to PKINIT for discussion. We have been working on an method of using CMS (PKCS#7) to build the messages that are sent in the PKINIT flows. The motivation is that S/MIME is becoming very popular and most PKI vendors supply CMS toolkits for S/MIME (Entrust, RSA, VDA S/MIME Freeware Lib, etc). Interoperability test are in place, some configurations are exportable and S/MIME is widely deployed. Basically, a CMS format message would be used to define public key authentication related messages passed in the PKINIT protocol. The messages would mirror the function of the PA-PK-AS-REQ and PA-PK-AS-REP except in a CMS format. We want to consider including a PA-CMS-AS-REQ and PA-CMS-AS-REP as at least place holders in the PKINIT spec. We are working on this approach within the DCE community but feel that the method is also valuable within PKINIT world. Below I have provided an FTP pointer to an MS-Word document that provides more detail on the approach. The document has some DCE specific issues that are relevant to a current movement to integrate modern PK support into DCE using PKINIT. Sections 4, 5 and 6 are most relevant to this discussion. Please cc any comments to me (greg@dascom.com) as I'm not sure if my subscription to the cat-ietf mail list worked. The document is available for anon FTP at: ftp://dascom.com/pub/DCE-CMS-10.doc I'll be at the meeting in LA on Monday if anyone would like to discuss further. Thanks for your time. Best regards, Greg Clark. CTO DASCOM Inc. www.dascom.com From owner-cat-ietf@pad-thai.cam.ov.com Sun Mar 29 15:39:28 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15624; Sun, 29 Mar 98 15:39:28 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA08009 for cat-ietf-redist; Sun, 29 Mar 1998 14:44:38 -0500 (EST) From: rem@bitsmart.com Date: Sun, 29 Mar 98 14:45:14 EST Message-Id: <9803291945.AA20600@MIT.EDU> To: Subject: Being a Better Educator Precedence: bulk Being a Better Educator Dear educator: Today, more than ever, we need innovative new solutions to educational problems. "Kevin Kirchman's book Aspirations is an answer to education questions such as 'How do we teach students to think for themselves, fulfill their potential, be creative, gain self esteem, and be ready for this productive world?' "His book is a must for all educators from pre-school through graduate school. I wish his book had been available during my 42 year teaching career." Norma Silver Retired teacher, Fort Lee, NJ Introducing, Aspirations: The Rational Foundations of Achievement. The reason it is possible to have an entirely new perspective on educational issues is because the theory behind education, called epistemology, or the theory of knowledge, has _not_ been an empirical science. Epistemology is to education what physics is to engineering-- but until the basis was discovered for _principles_ of understanding, there could be no science, and no applications that would radically transform educational practices. That is until now. "If knowledge of the humanities is subjective, that is, only valid for the person who holds it, of what value is education? "Knowledge is not subjective. There are some conceptual models that are better--more accurate and enlightening-- than others." Aspirations Aspirations will show you why, and teach you precisely how to tell the difference. "[Aspirations] lays out the foundations of clear, critical thinking, that can help us to better understand ourselves, others, and the world around us. In the final analysis, we are all decision makers. Don't make many more important decisions before you read and grasp Aspirations." Frank L. David Co-Principal, Business Learning Centers Murrieta, CA Perhaps the last earthly frontier, the mind, has been finally penetrated by this wonderful new book. Aspirations won't give you old ideas about the mind that you've seen before. It's radically new. Aspirations shows how, because of an old philosophical problem, educators are unwittingly discouraging idea forming habits that occur through the mental process of induction, or generalization. The book shows how these inductive concepts are the basis of all abilities and character. Deterring concept formation has the effects of hindering individuality, stifling general competency and causing people to be more dependent upon the ideas formed by others (being less able to form them themselves). The book presents a new solution to this dilemma which describes the mental events that occur during concept formation that can be practiced and made habit. Aspirations makes it clear that if you are less able to form concepts of your own, you necessarily have to borrow those formed by others. This discourages individuality, creativity, and self-reliance. It is also the basis for a host of psychological problems, from prejudice and intolerance to low self-esteem. Set within the context of human intellectual history, Aspirations stands out as a unique and controversial contribution to our understanding of ourselves. Fascinating reading. A journey deep into the corners of the mind and down the paths of civilization s philosophical development. The author of Aspirations, Kevin Kirchman, a Cornell University educated Artificial Intelligence scientist, lecturer and businessman, has actually utilized his new understanding of innovation to develop original perspectives on * deduction, or what reasoning is * induction, the basis of all innovation and creativity * character formation and these new ideas genuinely will aid you not only in teaching better mental habits, but in improving your own. "[Aspirations] is a self-motivational book for intelligent people." Stan Irwin The Producer of the Tonight Show with Johnny Carson for 15 years Rarely in human history is a book produced which has as important implications. Rarely is a book offered which gives us such hope and inspiration. Aspirations will soon be promoted nationally by Rogers & Cowan, America s largest public relations firm. Be the first to learn and apply these revolutionary new insights. Table of Contents: 1 Introduction 2 The Problem -- Why Educational Philosophy is Psychologically Debilitating 3 Concepts -- The Key to Understanding the Mind 4 Descriptive Concepts -- The Foundation of Clear Thinking 5 Creating Ideas -- Concept Formation is Induction 6 Character -- The Conceptual Origins of Personal Qualities 7 Motivation -- A Theoretical Defense of the Principles of Achievement 8 Reasoning -- A New and Practical Overview 9 Goal Setting and Decision Making -- Giving Yourself a Purpose 10 Deduction -- The Connection Between Logic and Common Sense 11 Reasoning Well -- Applying the New Science of Logic 12 The Principles of Induction -- New Solutions to a Classical Challenge 13 Conceptual Modeling -- Coming Up with the Best Concepts 14 Teaching Induction -- Overcoming the Fear of Abstractions 15 Philosophical Clarifications -- Understanding the Breakthrough and Replacing Outdated Technology 16 The New Science of Logic -- Clearing the Way for a Revolution in Rationality 17 Historical Background and Philosophical Comparison -- Putting the Conceptual Model Theory Into Perspective If, after receiving "Aspirations", you are not completely satisfied, return it for a prompt and full refund. Only $18.95 plus: $3.50 US $4.00 Canada $4.00 Overseas surface $10.00 Overseas air for postage and handling ORDER Aspirations NOW by calling USA International 1 310 289-2394, or faxing to 1 310 854-1840 any time with your credit card details. Or, Mail Check, Money Order, or Credit Card details to: Breakthrough Publishing, Inc. 291 S. La Cienega Blvd., Suite 107 Beverly Hills, CA 90211 YES! __ I would like ____ copies of Aspirations * $18.95 = __________ + (above postage rate for first book) = ________ Name ________________________________________ Title __________________ Organization_________________________________ Mailing Addr ________________________________ _____________________________________________ City ___________________ State ______________ Post Code ____________ Country ___________________________ VISA ___ MasterCard ___ American Express ___ Discovery ___ Card # __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ Expiration Date __________ Signature _________________________________