From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 1 15:34:03 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA20295; Tue, 1 Sep 98 15:34:03 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA27722 for ietf-cat-wg-out720680; Tue, 1 Sep 1998 12:05:04 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA27716 for ; Tue, 1 Sep 1998 12:05:01 -0700 (PDT) Received: from smtp3.ny.us.ibm.com by MIT.EDU with SMTP id AA04795; Tue, 1 Sep 98 15:04:57 EDT Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id OAA18194; Tue, 1 Sep 1998 14:49:53 -0400 Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id PAA52700; Tue, 1 Sep 1998 15:04:25 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU014 id 5040300019876677; Tue, 1 Sep 1998 15:01:23 -0400 From: David Hemsath To: Subject: Signed and enveloped data in draft-ietf-cat-kerberos-pk-init Message-Id: <5040300019876677000002L072*@MHS> Date: Tue, 1 Sep 1998 15:01:23 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk It appears that the S/MIME WG has made signifcant progress on the Cryptographic Message Standard (CMS) I-D, with the only outstanding issue (mandatory algorithms) close to being resolved at the S/MIME WG session last week. Given this progress, and the willingness of the PKIX folks to depend on CMS, could we possibly reopen the discussion of the use of the actual CMS signed-data and enveloped-data ASN.1 definitions by the pk-init I-D? While doing this would cause some short-term inconvenience/rework to those of us who have implemented from previous levels of the pk-init I-D, in the long run it would better align Kerberos w/ other standards and enable implementors to make use of the multiple providers of S/MIME SDKs. Thanks. Dave Hemsath, IBM Corporation ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 1 20:42:14 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA24379; Tue, 1 Sep 98 20:42:14 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id RAA10421 for ietf-cat-wg-out720680; Tue, 1 Sep 1998 17:18:15 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id RAA10416 for ; Tue, 1 Sep 1998 17:18:13 -0700 (PDT) Received: from SAINT-ELMOS-FIRE.MIT.EDU by MIT.EDU with SMTP id AA08606; Tue, 1 Sep 98 20:18:11 EDT Received: by saint-elmos-fire.mit.edu (SMI-8.6/4.7) id UAA06462; Tue, 1 Sep 1998 20:18:11 -0400 Date: Tue, 1 Sep 1998 20:18:11 -0400 Message-Id: <199809020018.UAA06462@saint-elmos-fire.mit.edu> To: ietf-cat-wg@lists.stanford.edu From: Tom Yu Subject: kerberos-revisions-01: DES3 discussion Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I have problems with the triple-DES spec in the current kerberos-revisions I-D. There is a length encoding that is inserted between the confounder and the plaintext prior to encryption. This violates the precedent of the other cryptosystem. Do other people feel that it is the place of a Kerberos cryptosystem to encode the length of the plaintext prior to padding? Certainly this design assumption is not stated explicitly in the specifications to date, or if it is, then I must be missing it. Also, almost all data that are encrypted by a Kerberos cryptosystem are themselves first encoded in ASN.1, which inherently contains a length encoding. Thus, the length encoding within the data-to-be-encrypted is redundant. Also, Marc Horowitz's in-progress implementation of des3-cbc-sha1 uses an explicit 32-bit length encoding, while the draft does not specify how the length is to be encoded. An explicit fixed limit on the length of application data should not be imposed. While currently it is inconceivable that an application would want to encrypt more than 4 gigabytes of data at once, it may be feasible at some future date, and we should not impose an arbitrary limit at such a fundamental layer of the protocol. Explicit length encoding is only going to benefit application software that will use cryptosystems defined by Kerberos. It is possible that some application writer will depend on a Kerberos cryptosystem and make the erroneous assumption that all cryptosystems will inherently include a length encoding of the plaintext prior to padding and encryption. This could potentially cause confusion. For these reasons, I recommend that the explicit length encoding of the plaintext be removed from the kerberos-revisions draft when the section on DES3 is rewritten. Are there any objections? Other comments? ---Tom ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 1 22:14:25 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA25019; Tue, 1 Sep 98 22:14:25 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id SAA13508 for ietf-cat-wg-out720680; Tue, 1 Sep 1998 18:45:05 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id SAA13500 for ; Tue, 1 Sep 1998 18:45:02 -0700 (PDT) From: joes@wrq.com Received: from ursula.wrq.com (root@ursula.wrq.com [150.215.11.58]) by smaug.wrq.com (8.8.6/8.8.6) with ESMTP id SAA25251; Tue, 1 Sep 1998 18:45:01 -0700 (PDT) Received: from localhost (root@localhost) by ursula.wrq.com with SMTP (8.7.6/8.7.3) id SAA11720; Tue, 1 Sep 1998 18:45:00 -0700 (PDT) X-Openmail-Hops: 1 Date: Tue, 1 Sep 1998 18:44:53 -0700 Message-Id: In-Reply-To: <199809020018.UAA06462@saint-elmos-fire.mit.edu> Subject: Re: kerberos-revisions-01: DES3 discussion To: tlyu@mit.edu Cc: ietf-cat-wg@lists.Stanford.EDU Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Item Subject: kerberos-revisions-01: DES3 discussion If the length is always part of the data then including it in the cryptosystem definition seems redundant. Another, perhaps equally troublesome, option is to define a padding scheme that always pads with the padding character equal to the length of padding. It seems the thing to avoid is sending the length of the cleartext in cleartext. When is a Kerberos cryptosystem used without ASN.1 encoded cleartext data? Joe ______________________________ Reply Separator _________________________________ Subject: kerberos-revisions-01: DES3 discussion Author: tlyu (tlyu@mit.edu) at internet,shar Date: 9/1/98 5:18 PM I have problems with the triple-DES spec in the current kerberos-revisions I-D. There is a length encoding that is inserted between the confounder and the plaintext prior to encryption. This violates the precedent of the other cryptosystem. Do other people feel that it is the place of a Kerberos cryptosystem to encode the length of the plaintext prior to padding? Certainly this design assumption is not stated explicitly in the specifications to date, or if it is, then I must be missing it. Also, almost all data that are encrypted by a Kerberos cryptosystem are themselves first encoded in ASN.1, which inherently contains a length encoding. Thus, the length encoding within the data-to-be-encrypted is redundant. Also, Marc Horowitz's in-progress implementation of des3-cbc-sha1 uses an explicit 32-bit length encoding, while the draft does not specify how the length is to be encoded. An explicit fixed limit on the length of application data should not be imposed. While currently it is inconceivable that an application would want to encrypt more than 4 gigabytes of data at once, it may be feasible at some future date, and we should not impose an arbitrary limit at such a fundamental layer of the protocol. Explicit length encoding is only going to benefit application software that will use cryptosystems defined by Kerberos. It is possible that some application writer will depend on a Kerberos cryptosystem and make the erroneous assumption that all cryptosystems will inherently include a length encoding of the plaintext prior to padding and encryption. This could potentially cause confusion. For these reasons, I recommend that the explicit length encoding of the plaintext be removed from the kerberos-revisions draft when the section on DES3 is rewritten. Are there any objections? Other comments? ---Tom ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Sep 2 09:52:11 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA01728; Wed, 2 Sep 98 09:52:11 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id GAA28714 for ietf-cat-wg-out720680; Wed, 2 Sep 1998 06:22:38 -0700 (PDT) Received: from urquan-kohr-ah.mesas.com (urquan-kohr-ah.mesas.com [207.8.16.3]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id GAA28707 for ; Wed, 2 Sep 1998 06:22:35 -0700 (PDT) Received: (from hartmans@localhost) by urquan-kohr-ah.mesas.com (8.8.8/8.7.3) id IAA18218; Wed, 2 Sep 1998 08:22:32 -0500 (CDT) To: joes@wrq.com Cc: tlyu@mit.edu, ietf-cat-wg@lists.Stanford.EDU Subject: Re: kerberos-revisions-01: DES3 discussion References: From: Sam Hartman Date: 02 Sep 1998 08:22:31 -0500 In-Reply-To: joes@wrq.com's message of "Tue, 1 Sep 1998 18:44:53 -0700" Message-Id: Lines: 13 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "joes" == joes writes: joes> When is a Kerberos cryptosystem used without ASN.1 joes> encoded cleartext data? It is certainly a desire of the MIT implementation and I believe other implementations to be able to allow applications such as GSSAPI, the BSD r-utilities, custom third party applications, etc, to use the Kerberos cryptosystems as they see fit. We had talked about extending this to telnet at MIT when a draft was written to do 3DES support for telnet. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Sep 2 12:12:43 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA02922; Wed, 2 Sep 98 12:12:43 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id IAA02178 for ietf-cat-wg-out720680; Wed, 2 Sep 1998 08:21:43 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id IAA02165 for ; Wed, 2 Sep 1998 08:21:39 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 2 Sep 1998 15:30:29 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id LAA20898 for ; Wed, 2 Sep 1998 11:27:10 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Wed, 2 Sep 1998 11:25:20 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" Subject: DRAFT minutes for Chicago IETF CAT-WG meeting Date: Wed, 2 Sep 1998 11:23:00 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT fanciers: Attached are the draft minutes for the Chicago IETF CAT-WG session. Corrections from attendees are welcome and solicited; please provide any such NLT next Tuesday, 8 September, in order to allow timely submission to the IETF secretariat. --jl Common Authentication Technology (CAT) WG summary, Chicago IETF, reported by John Linn (RSA Laboratories). SUMMARY The CAT WG met for one session at the Chicago IETF, with approximately 130 attendees. The SNEGO document, which has been through IETF Last-Call, will be issued for ballot within the IESG shortly. Final alignment changes to RFC2078bis and the GSS-V2 C bindings were agreed, and versions of this pair of documents are to be submitted to the IESG following the meeting to be considered for advancement to Proposed Standards. The Kerberos PKINIT and PKCROSS drafts were discussed. A revised version of PKINIT is to be issued after the meeting reflecting evaluation of a patent issue concerning KDC private key storage and (consistent with the Munich Doctrine) removal of the specified requirement for mandatory (vs. optional) RSA support. Following these changes, the PKINIT draft is to be considered for WG Last-Call. A revised version of the Kerberos-Revisions document is expected soon after the meeting week for working group review, reflecting results of a focus group discussion scheduled after the CAT session. The recently reactivated Kerberos-Passwords draft was presented briefly. Two prospective new work areas were presented: significant attendee interest appeared in a proposal on GSS Java bindings and moderate interest appeared in authorization interface proposals (GAA); ongoing review and discussion of these documents was solicited on the WG mailing list. GENERAL AND ADMINISTRATIVE DISCUSSION According to information available at the meeting, the SNEGO draft is to be balloted within the IESG shortly. The IDUP draft was in discussion within the IESG, with no status to be reported. The current WG mailing list administrators at Stanford University were thanked for their efforts and support; list-targeted traffic can now be addressed directly to ietf-cat-wg@lists.stanford.edu with Majordomo list management facilities accessible at ietf-cat-wg-request@lists.stanford.edu. (The existing addresses at mit.edu now autoforward to these addresses.) RFC2078BIS AND C BINDINGS John Linn led brief discussion on these documents (which have already been through WG Last-Calls), in advance of their planned submission to the IESG. Two specific changes, resulting from alignment review between the documents, were agreed. It was accepted (despite a recognized backward incompatibility, which will be documented) that integ_req_flag and conf_req_flag inputs to GSS_Init_sec_context() will operate as currently specified in RFC2078bis. Per-message tokens are not to be emitted along with an error major_status value. Security considerations will be added to the documents, including: the fact that no security is provided by GSS itself rather than the underlying mechanism, that applications must check status indicators to be cognizant of what security services are being provided, and concerning the security implications of context transfer. A revised pair of RFC2078bis and C bindings documents, reflecting these edits, is to be prepared and submitted to the IESG following the meeting. KERBEROS-REVISIONS UPDATE Cliff Neuman (ISI) summarized status of the Kerberos-Revisions (RFC1510bis) draft, indicating a desire to clean up final topics during the meeting week. An informal session was scheduled later during the week for this purpose, with issues to include the following: - ticket extensions and how they should be included (point: whether old implementations would drop them or treat them incompatibly or inappropriately), - authorization data for required ticket extensions - triple-DES string-to-key transform to achieve MIT compatibility - possible mandated support for TCP transport - PKINIT-driven issue re mapping of X.509 names to principals - name referrals (topic of a draft authored by Mike Swift). Approximately 10 WG attendees indicated interest in attending this informal session, and Cliff is to circulate notes from that discussion to the WG mailing list. KERBEROS-PASSWORDS Ken Hornstein (NRL) presented a brief discussion on the kerberos-passwords draft ("Integrating Single-Use Authentication Mechanisms with Kerberos"), which defines means for using challenge-response and authenticator token technologies with Kerberos preauthentication. Ken had recently revised and reissued this document, which was originally co-authored by Cliff Neuman, Glen Zorn, and Jonathan Trostle. Ken observed that there are several deployed realms with significant user sets making use of this protocol. Approximately 14 attendees indicated interest in progressing the document. Marc Horowitz (Stonecast) pointed out that the currently-specified checksumming procedure for PA-SAM-CHALLENGE is anomalous, as its coverage is unclear and its method implies violation of ASN.1 conventions. It was proposed that a new ASN.1 type be defined in order to make checksum computation more straightforward. PKINIT AND PKCROSS Brian Tung (ISI) led discussion on the Kerberos PKINIT and PKCROSS drafts. New aspects in PKINIT include: - PKCS-7/CMS have been copied in by value, with appropriate algorithm identifiers added - servers now see the same name for both PKINIT and non-PKINIT clients - added text on key requirements. Issues to resolve: - patent issue on the optional KDC private key storage facility; reportedly, Charlie Kaufman (Iris) is to attempt to identify a Compaq contact who would be able to address intellectual property concerns regarding the relevant patent, originally issued to Digital Equipment Corporation - possibly mandating support for signature-only users (intent is already to make it mandatory for PKINIT KDCs). Denis Pinkas (Bull) noted that signature-only usage is important to contemplated DCE usage of PKINIT in OpenGroup. - Password changing [EDITOR'S NOTE: I didn't get the scope of this issue in the notes: can any attendees elaborate?] The removal of a mandatory requirement for RSA support, for conformance with the Munich Doctrine, was also discussed. It was noted that existing implementations have been RSA-based. Brian proposed that Diffie-Hellman be made mandatory, RSA optional; this proposal was carried unanimously within a straw poll of about 10 attendees. Frank Seibenlist (Dascom) noted that he was working on an X/Open (Open Group) activity related to PKINIT, needed access to data on ongoing revision plans, and was concerned about the limited amount of PKINIT discussion on the public WG mailing list. Denis Pinkas noted that Open Group discussion was scheduled to progress through 15 September, so it would be undesirable for any WG Last-Call on PKINIT to close before that point. Following resolution on the identified patent issue, Brian proposes to submit a revised PKINIT draft, adding mandatory Diffie-Hellman support, with the result to be targeted for a working group Last-Call. PKCROSS is dependent on PKINIT, so cannot advance before it. The most recent PKCROSS revision added clarifying text about ASN.1 parsers and ticket extensions. PROPOSED NEW WORK: GSS-API JAVA BINDINGS Jack Kabat (Sun) led discussion on a recently submitted draft for GSS-API Java bindings. Its objectives include satisfying functionality defined in RFC-2078 and 2078bis, providing Java orientation, and allowing easier usage within a Java environment. Defined classes include GSSCredential, GSSContext (encapsulates context management), GSSName (encapsulates name representations), Oid, GSSManager (general class, no constructors), GSSException, and other utility classes. Initiator-side and acceptor-side code examples were shown. Jack noted the following areas in which the Java draft deviates from RFC-2078: error handling is accommodated via GSSExceptions; memory management relies on garbage collection; calling conventions differ; java.io stream classes are supported. In defining Java bindings for GSS, he encountered the following challenges: adapting functional API into an object-oriented model, hiding complexity, and integration with existing Java security classes (observation: most Java classes assume certificate-based). Ted Ts'o (MIT) commented that it would be interesting to explore RMI integration. Sam Hartman (FundsXpress) observed that it would be nice to have a shim between a C GSS implementation and exporting the Java API, but was concerned about possible conflicts with OID representations. Bob Morgan (Stanford) stated that the Open Group is working on a Kerberos V5 implementation in Java, which might merit investigation. About 18 attendees indicated interest in progressing this draft within the CAT WG, if this can be accommodated within the WG charter. Further review and comment on the draft was solicited. PROPOSED NEW WORK: AUTHORIZATION INTERFACE Tatyana Ryutov (ISI) led discussion on two documents related to authorization services and interfaces. The work was motivated by the following goals: a need for fine-grained AC to resources, integrating local and distributed models, user and domain-level policies, support for various authorization models and authentication policies, and of facilitating authorization decisions. In the proposed approach, local policies are expressed via ACLs, and distributed policies via credentials. Optional conditions fields can be added to both ACLs and credentials. Once obtained, credentials (which may be based on GSS or other forms of authentication) are placed into a GAA security context. The Check_authorization call returns one of "authorized", "not authorized", or "more info needed". Several principal types are defined: user, group, host, application, and anybody. A GAA context is composed of credentials and per-connection information reflecting attributes of the would-be accessor. Several generic conditions are proposed, some of which occur only in credentials rather than ACLs; review and comment was particularly solicited on the condition constructs. ISI has implemented a GAA prototype based on Kerberos. A discussion list was announced specifically for these documents: g3api@isi.edu; further information is available on url http://gost.isi.edu/info/gaa_api.html. Proposed areas for future work include refinements to the evaluation facility. Group discussion on GAA followed. Marc Horowitz didn't see that GAA can support a distributed authorization server model, where ACLs don't reside at the application. Cliff Neuman responded that some models of this nature could be supported, invisibly to the caller; alternatively, a client could request a particular set of operations and corresponding credentials could be forwarded. Cliff indicated a belief that, in any case, standardizing ACL formats would be valuable. John Wray (Iris) asked whether and how container ACLs could be supported. Another question: Has work been done to layer over existing ACLs (e.g., POSIX, NT), as this would affect the practical value of GAA? Mary Ellen Zurko (Iris) asked whether multi-personal control was supported; Cliff responded that this support was possible. About 8 attendees endorsed progressing GAA within the CAT group, if this can be accommodated within the WG charter; discussion was encouraged on the WG mailing list. Cliff observed that there was a significant relationship between GSS and GAA security contexts. Several attendees commented that a number of other WGs and BOFs were considering ACLs and authorization, including (as examples) webdav, LDAP extensions, and a trust management BOF taking place later in the meeting week. OTHER TOPICS Richard Ward (Microsoft) noted that Kerberos tickets are becoming increasingly larger as more elements are carried, and larger, and that some protocols have fixed limits. He posed the prospect that token reassembly might be considered below the GSS interface. Ted Ts'o and John Wray opposed this suggestion, given compatibility and protocol layering concerns. Cliff Neuman noted that GAA has upcall functions to obtain information incrementally as needed, but this was recognized as a separate and longer term consideration. Bob Morgan observed that the SASL framework is being incorporated in a number of protocols, and that SASL allows GSS. Ambiguities had been observed about what service principal names are to be used; the SASL recommendation is that names of the host-based service form be used. John Linn recalled discussion with Chris Newman some months prior, which had led to tightened specification of host-based service name usage in rfc2078bis. Ted Ts'o observed that this handles some cases, but not those which are truly application-specific. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Sep 4 00:30:48 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA04165; Fri, 4 Sep 98 00:30:48 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id VAA07543 for ietf-cat-wg-out720680; Thu, 3 Sep 1998 21:00:19 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id VAA07533 for ; Thu, 3 Sep 1998 21:00:16 -0700 (PDT) From: janet689@hotmail.com Received: from hex.de.uu.net by MIT.EDU with SMTP id AA01117; Fri, 4 Sep 98 00:00:07 EDT Date: Fri, 4 Sep 1998 05:55:17 +0200 (MET DST) Message-Id: <199809040355.FAA23395@hex.de.uu.net> Received: from x (1Cust215.tnt5.nyc3.da.uu.net [153.37.117.215]:1070) by hex.de.uu.net with SMTP (5.65+:004/3.0.2) id FAA23395; Fri, 4 Sep 1998 05:55:17 +0200 (MET DST) Subject: They Can Even Steal Your Identity! Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk ARE YOU BEING INVESTIGATED? Has your personal and credit information been stolen? Has someone assumed your identity? Would you like to locate an old friend, relative, military buddy or sweetheart? Do you want to find a person's assets to collect a debt or judgement? Would you like to check a person's criminal record before renting them space or giving them employment? Would you like to fix up your credit bureau report, create a new identity or even disappear? Are you going to have surgery? Would you like to know how many malpractice suits have been filed against your doctor? Now you can learn all this plus much, much more with our brand new 45 page report "INTERNET SLEUTH"! Learn the Internet tools and resources that are used to investigate you, your relatives, friends, neighbors, enemies, employees or anyone else! We will give you thousands of Internet locations to look up people, credit, social security, current or past employment, driving records, criminal records, medical information, military records, addresses, phone numbers, immigration, divorce, labor and criminal laws! We will also give you sources to find missing children and parents, hazardous waste sites, how to do Freedom of Information Act information searches, how to do skip tracing and backround checks on prospective dates, brides or grooms, employees, renters, vendors, new clients and competitors! You will also learn about and where to get surveillance and spy devices, private mail forwarding and annonymous email forwarding sites, search for copyrights, patents and court cases and how to make your assets untraceable! We will show you how to get copies of credit reports, adoption databases, information on drugs, poisons and how to get your share of government programs and benefits! Can you find this information by using the Internet Search Engines? The answer is MAYBE if you get lucky and if you want to spend many hours going through 25,000 plus hits per subject! We and our staff have spent hundreds of hours and many thousands of dollars compiling this information for you! Now you can have it on a silver platter for LESS THAN TWENTY BUCKS during this special email promotion! You frequently hear over the media, television, radio, the newspapers, how personal information is being used, traded and sold over the Internet...usually without your permission or knowledge. Our report will show you HOW IT IS DONE!!! Would you like to find that old romantic flame...find telephone, address or email information on almost anyone...even unlisted phone numbers? How about your family "tree"? We will teach you how to turn years of work into hours of fun! Military? Check Army, Navy, Air Force and Marine records. extensive Vietnamese war records, MIA info, much more! Looking for a job? Find the job you are seeking...even in another state or another country! We will teach you how! Looking for a new love interest or spouse or even sex partner? We will show you where to look for fast results! Want up-to-the-minute health and medical information? Learn how to cure fears and phoebias, the latest drugs and treatments for almost any ailment or desease from the drug companies themselves as well as from universities and the Center for Desease Control. Want to learn the most effective way to loose weight? It's all here in our report! If you believe that the information compiled about you should be as available to you as to the people that compile it about you without your knowledge or permission than you must order "THE INTERNET SLEUTH REPORT" immediately! Our "INTERNET SLEUTH REPORT" is normally sold by direct mail for $39.95 and will soon be in book stores for $29.95. However, to generate publicity and "get the word out" we are making this 10 day Email Special Offer of our Complete 45 Page Report for only $19.95 plus $3 for shipping and handling [total $22.95]. Sold with our 10 Day Money Back Guarantee! This is the biggest bargain on the Internet and the information it will give to you will give you great power! It can really change your life in a positive way. Order Now! The Complete 45 page "INTERNET SLEUTH REPORT" only $19.95 plus $3 shipping and handling - total $22.95. Shipped in plain wrapper by First Class Mail. Add $5 for priority mail delivery. Add $20 for overnight Express! We accept Visa, MasterCard, American Express or Discover. We can also accept your check by phone or Fax. You may order by phone 9 am to 10 pm [NY Time] by phoning [718] 287-3800 You may order by fax 24 hours per day by phoning our fax line at [718] 462-5920. You can fax your credit card information or your check To Email your order - DO NOT HIT REPLY ON YOUR KEYBOARD Send email to our special email address below: learnquick98@juno.com [Note: If you order by email and do not receive an email confirmation within 24 hours, please phone our office at 718-287-3800] You can also order by mail by sending $22.95 cash, check, money order or major credit card [Visa, MasterCard, American Express or Discover] to TCPS, INC. 4718 18th Ave. Suite 135 Brooklyn, NY 11204 Make Checks & Money Orders Payable to TCPS, Inc. New York State Residents Please Add $1.70 for Sales Tax The Following Order Form is for Your Convenience! Use it by Mail, Fax or Email! ................................................................................ ............................. Please ship me ________copies of the INTERNET SLEUTH Report at $19.95 each plus $3.00 for shipping and handling [$22.95] Signature______________________________________________ Credit Card #____________________________Exp date______ Ship to: Name_________________________________________ Address________________________________________________ City________________________State___________Zip________ Area Code and Home Phone [ ]___________________________ Fax # [ ]______________________________________________ Email Address___________________________________________ To remove your name from our mailing list, send us an email with remove in the subject line. This is a one time offer and you should not hear from us again! TCPS,Inc., 4718 18th Ave., Suite 135, Brooklyn, NY 11204 Office [718] 287-3800 Fax [718] 462-5920 24 hours [9am to 10pm NY Time] [c] Copyright 1998 TCPS, Inc. All Rights Reserved. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 8 11:31:40 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA06362; Tue, 8 Sep 98 11:31:40 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id IAA28464 for ietf-cat-wg-out720680; Tue, 8 Sep 1998 08:02:22 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id IAA28459 for ; Tue, 8 Sep 1998 08:02:20 -0700 (PDT) Received: from odin.ietf.org by MIT.EDU with SMTP id AA07733; Tue, 8 Sep 98 11:02:18 EDT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04623; Tue, 8 Sep 1998 11:02:14 -0400 (EDT) Message-Id: <199809081502.LAA04623@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-07.txt Date: Tue, 08 Sep 1998 11:02:13 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Security Service Application Program Interface Version 2, Update 1 Author(s) : J. Linn Filename : draft-ietf-cat-rfc2078bis-07.txt Pages : 101 Date : 04-Sep-98 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 This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. 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-rfc2078bis-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-07.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: ftp.ietf.org 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-rfc2078bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980904162619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-rfc2078bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-rfc2078bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980904162619.I-D@ietf.org> --OtherAccess-- --NextPart-- ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 8 12:38:26 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA06787; Tue, 8 Sep 98 12:38:26 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id IAA00136 for ietf-cat-wg-out720680; Tue, 8 Sep 1998 08:55:53 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id IAA00125 for ; Tue, 8 Sep 1998 08:55:50 -0700 (PDT) Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 8 Sep 1998 15:55:18 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id MAA17821 for ; Tue, 8 Sep 1998 12:01:27 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Tue, 8 Sep 1998 11:59:36 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" Subject: FW: I-D ACTION:draft-ietf-cat-rfc2078bis-07.txt Date: Tue, 8 Sep 1998 11:57:16 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDDB41.ACE46B90" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDDB41.ACE46B90 Content-Type: text/plain; charset="iso-8859-1" CAT/2078bis fanciers: The scope of changes made in this version was confined to the final points as discussed in the draft minutes from the Chicago meeting: - documenting the recognized backward incompatibility with GSS-V1 re the integ_req_flag and conf_req_flag inputs to gss_init_sec_context(), primarily within Sec. 2.2.1 and also cited within the changes appendices; Sec. 1.2.1.2 now also lists per-message integrity and confidentiality among the services which may be requested for a context - clarified (in sec. 1.1.2, and in discussions of gss_wrap() and gss_getmic()) that per-message tokens aren't emitted in conjunction with failure major_status - augmented Security Considerations (Sec. 6) I believe that this should be the final version of the 2078bis draft, and that it's ready to go to the IESG on behalf of the WG along with an upcoming corresponding version of the C bindings. --jl > ---------- > From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org] > Reply To: Internet-Drafts@ietf.org > Sent: Tuesday, September 08, 1998 11:02 AM > To: IETF-Announce; @ns.cnri.reston.va.us > Cc: cat-ietf@mit.edu > Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-07.txt > > <<...>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Authentication Technology Working > Group > of the IETF. > > Title : Generic Security Service Application Program > Interface Version 2, Update 1 > Author(s) : J. Linn > Filename : draft-ietf-cat-rfc2078bis-07.txt > Pages : 101 > Date : 04-Sep-98 > > 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 > > This Internet-Draft revises [RFC-2078], making specific, incremental > changes in response to implementation experience and liaison > requests. It is intended, therefore, that this draft or a successor > version thereto will become the basis for subsequent progression of > the GSS-API specification on the standards track. > > 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-rfc2078bis-07.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-07.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: ftp.ietf.org > > 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-rfc2078bis-07.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------ =_NextPart_000_01BDDB41.ACE46B90 Content-Type: message/rfc822 To: Subject: Date: Tue, 8 Sep 1998 11:59:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: multipart/mixed; boundary="---- =_NextPart_002_01BDDB41.ACE46B90" ------ =_NextPart_002_01BDDB41.ACE46B90 Content-Type: text/plain ------ =_NextPart_002_01BDDB41.ACE46B90 Content-Type: application/octet-stream; name="ATT52819.txt" Content-Disposition: attachment; filename="ATT52819.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980904162619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-rfc2078bis-07.txt ------ =_NextPart_002_01BDDB41.ACE46B90 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-cat-rfc2078bis-07.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------ =_NextPart_002_01BDDB41.ACE46B90-- ------ =_NextPart_000_01BDDB41.ACE46B90-- ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 8 19:11:05 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA16874; Tue, 8 Sep 98 19:11:05 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id PAA14337 for ietf-cat-wg-out720680; Tue, 8 Sep 1998 15:37:54 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id PAA14329 for ; Tue, 8 Sep 1998 15:37:51 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA18381; Tue, 8 Sep 98 18:37:45 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id SAA22974; Tue, 8 Sep 1998 18:37:47 - 0400 Date: Tue, 8 Sep 1998 18:37:47 -0400 Message-Id: <199809082237.SAA22974@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: joes@wrq.com Cc: tlyu@mit.edu, ietf-cat-wg@lists.Stanford.EDU In-Reply-To: joes@wrq.com's message of Tue, 1 Sep 1998 18:44:53 -0700, Subject: Re: kerberos-revisions-01: DES3 discussion Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk From: joes@wrq.com Date: Tue, 1 Sep 1998 18:44:53 -0700 If the length is always part of the data then including it in the cryptosystem definition seems redundant. I would agree.... Another, perhaps equally troublesome, option is to define a padding scheme that always pads with the padding character equal to the length of padding. It seems the thing to avoid is sending the length of the cleartext in cleartext. We could do this, although it means that with an crypto algorithm with a block size of 8, there is a 1 in 8 chance that the padded message will increase in size by 8 bytes unnecessarily (since there must be at least one pad character to determine the length of the padding). This scheme also falls apart if we ever have a cipher with a blocksize of 256 bytes or greater. Not very likely at the moment, I know! When is a Kerberos cryptosystem used without ASN.1 encoded cleartext data? Never; that's why I would argue for not trying to include the length coutn into the Kerberos 3DES crypto-encoding. None of the other Kerberos crypto suites (des-cbc-md5, des-cbc-crc, etc.) include a length count, and so including one only for triple-DES adds no value. - Ted ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 8 21:45:46 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA18191; Tue, 8 Sep 98 21:45:46 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id SAA18602 for ietf-cat-wg-out720680; Tue, 8 Sep 1998 18:15:27 -0700 (PDT) Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.238.1.107]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id SAA18597 for ; Tue, 8 Sep 1998 18:15:25 -0700 (PDT) Received: (from hartmans@localhost) by luminous.mit.edu (8.8.8/8.6.12) id VAA08162; Tue, 8 Sep 1998 21:15:22 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: joes@wrq.com, tlyu@mit.edu, ietf-cat-wg@lists.Stanford.EDU Subject: Re: kerberos-revisions-01: DES3 discussion References: <199809082237.SAA22974@dcl.MIT.EDU> From: Sam Hartman Date: 08 Sep 1998 21:15:21 -0400 In-Reply-To: "Theodore Y. Ts'o"'s message of Tue, 8 Sep 1998 18:37:47 -0400 Message-Id: Lines: 4 X-Mailer: Gnus v5.2.37/Emacs 19.34 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Because Marc and I would like to compromise on the padding solution. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Sep 9 16:47:46 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA02396; Wed, 9 Sep 98 16:47:46 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA13743 for ietf-cat-wg-out720680; Wed, 9 Sep 1998 13:09:18 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id NAA13738 for ; Wed, 9 Sep 1998 13:09:15 -0700 (PDT) Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 9 Sep 1998 20:08:43 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id QAA16358; Wed, 9 Sep 1998 16:14:23 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Wed, 9 Sep 1998 16:12:32 -0400 Message-Id: From: "Linn, John" To: "'minutes@ietf.org'" Cc: "'CAT-WG List'" Subject: Minutes, CAT-WG Chicago meeting Date: Wed, 9 Sep 1998 16:10:11 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk [CAT-WG members: this corrects a misspelling reported in the version previously sent to the WG mailing list, and removes an embedded editorial question, but its content is otherwise unchanged.] Common Authentication Technology (CAT) WG minutes, Chicago IETF, reported by John Linn (RSA Laboratories). SUMMARY The CAT WG met for one session at the Chicago IETF, with approximately 130 attendees. The SNEGO document, which has been through IETF Last-Call, will be issued for ballot within the IESG shortly. Final alignment changes to RFC2078bis and the GSS-V2 C bindings were agreed, and versions of this pair of documents are to be submitted to the IESG following the meeting to be considered for advancement to Proposed Standards. The Kerberos PKINIT and PKCROSS drafts were discussed. A revised version of PKINIT is to be issued after the meeting reflecting evaluation of a patent issue concerning KDC private key storage and (consistent with the Munich Doctrine) removal of the specified requirement for mandatory (vs. optional) RSA support. Following these changes, the PKINIT draft is to be considered for WG Last-Call. A revised version of the Kerberos-Revisions document is expected soon after the meeting week for working group review, reflecting results of a focus group discussion scheduled after the CAT session. The recently reactivated Kerberos-Passwords draft was presented briefly. Two prospective new work areas were presented: significant attendee interest appeared in a proposal on GSS Java bindings and moderate interest appeared in authorization interface proposals (GAA); ongoing review and discussion of these documents was solicited on the WG mailing list. GENERAL AND ADMINISTRATIVE DISCUSSION According to information available at the meeting, the SNEGO draft is to be balloted within the IESG shortly. The IDUP draft was in discussion within the IESG, with no status to be reported. The current WG mailing list administrators at Stanford University were thanked for their efforts and support; list-targeted traffic can now be addressed directly to ietf-cat-wg@lists.stanford.edu with Majordomo list management facilities accessible at ietf-cat-wg-request@lists.stanford.edu. (The existing addresses at mit.edu now autoforward to these addresses.) RFC2078BIS AND C BINDINGS John Linn led brief discussion on these documents (which have already been through WG Last-Calls), in advance of their planned submission to the IESG. Two specific changes, resulting from alignment review between the documents, were agreed. It was accepted (despite a recognized backward incompatibility, which will be documented) that integ_req_flag and conf_req_flag inputs to GSS_Init_sec_context() will operate as currently specified in RFC2078bis. Per-message tokens are not to be emitted along with an error major_status value. Security considerations will be added to the documents, including: the fact that no security is provided by GSS itself rather than the underlying mechanism, that applications must check status indicators to be cognizant of what security services are being provided, and concerning the security implications of context transfer. A revised pair of RFC2078bis and C bindings documents, reflecting these edits, is to be prepared and submitted to the IESG following the meeting. KERBEROS-REVISIONS UPDATE Cliff Neuman (ISI) summarized status of the Kerberos-Revisions (RFC1510bis) draft, indicating a desire to clean up final topics during the meeting week. An informal session was scheduled later during the week for this purpose, with issues to include the following: - ticket extensions and how they should be included (point: whether old implementations would drop them or treat them incompatibly or inappropriately), - authorization data for required ticket extensions - triple-DES string-to-key transform to achieve MIT compatibility - possible mandated support for TCP transport - PKINIT-driven issue re mapping of X.509 names to principals - name referrals (topic of a draft authored by Mike Swift). Approximately 10 WG attendees indicated interest in attending this informal session, and Cliff is to circulate notes from that discussion to the WG mailing list. KERBEROS-PASSWORDS Ken Hornstein (NRL) presented a brief discussion on the kerberos-passwords draft ("Integrating Single-Use Authentication Mechanisms with Kerberos"), which defines means for using challenge-response and authenticator token technologies with Kerberos preauthentication. Ken had recently revised and reissued this document, which was originally co-authored by Cliff Neuman, Glen Zorn, and Jonathan Trostle. Ken observed that there are several deployed realms with significant user sets making use of this protocol. Approximately 14 attendees indicated interest in progressing the document. Marc Horowitz (Stonecast) pointed out that the currently-specified checksumming procedure for PA-SAM-CHALLENGE is anomalous, as its coverage is unclear and its method implies violation of ASN.1 conventions. It was proposed that a new ASN.1 type be defined in order to make checksum computation more straightforward. PKINIT AND PKCROSS Brian Tung (ISI) led discussion on the Kerberos PKINIT and PKCROSS drafts. New aspects in PKINIT include: - PKCS-7/CMS have been copied in by value, with appropriate algorithm identifiers added - servers now see the same name for both PKINIT and non-PKINIT clients - added text on key requirements. Issues to resolve: - patent issue on the optional KDC private key storage facility; reportedly, Charlie Kaufman (Iris) is to attempt to identify a Compaq contact who would be able to address intellectual property concerns regarding the relevant patent, originally issued to Digital Equipment Corporation - possibly mandating support for signature-only users (intent is already to make it mandatory for PKINIT KDCs). Denis Pinkas (Bull) noted that signature-only usage is important to contemplated DCE usage of PKINIT in OpenGroup. - Password changing The removal of a mandatory requirement for RSA support, for conformance with the Munich Doctrine, was also discussed. It was noted that existing implementations have been RSA-based. Brian proposed that Diffie-Hellman be made mandatory, RSA optional; this proposal was carried unanimously within a straw poll of about 10 attendees. Frank Siebenlist (Dascom) noted that he was working on an X/Open (Open Group) activity related to PKINIT, needed access to data on ongoing revision plans, and was concerned about the limited amount of PKINIT discussion on the public WG mailing list. Denis Pinkas noted that Open Group discussion was scheduled to progress through 15 September, so it would be undesirable for any WG Last-Call on PKINIT to close before that point. Following resolution on the identified patent issue, Brian proposes to submit a revised PKINIT draft, adding mandatory Diffie-Hellman support, with the result to be targeted for a working group Last-Call. PKCROSS is dependent on PKINIT, so cannot advance before it. The most recent PKCROSS revision added clarifying text about ASN.1 parsers and ticket extensions. PROPOSED NEW WORK: GSS-API JAVA BINDINGS Jack Kabat (Sun) led discussion on a recently submitted draft for GSS-API Java bindings. Its objectives include satisfying functionality defined in RFC-2078 and 2078bis, providing Java orientation, and allowing easier usage within a Java environment. Defined classes include GSSCredential, GSSContext (encapsulates context management), GSSName (encapsulates name representations), Oid, GSSManager (general class, no constructors), GSSException, and other utility classes. Initiator-side and acceptor-side code examples were shown. Jack noted the following areas in which the Java draft deviates from RFC-2078: error handling is accommodated via GSSExceptions; memory management relies on garbage collection; calling conventions differ; java.io stream classes are supported. In defining Java bindings for GSS, he encountered the following challenges: adapting functional API into an object-oriented model, hiding complexity, and integration with existing Java security classes (observation: most Java classes assume certificate-based). Ted Ts'o (MIT) commented that it would be interesting to explore RMI integration. Sam Hartman (FundsXpress) observed that it would be nice to have a shim between a C GSS implementation and exporting the Java API, but was concerned about possible conflicts with OID representations. Bob Morgan (Stanford) stated that the Open Group is working on a Kerberos V5 implementation in Java, which might merit investigation. About 18 attendees indicated interest in progressing this draft within the CAT WG, if this can be accommodated within the WG charter. Further review and comment on the draft was solicited. PROPOSED NEW WORK: AUTHORIZATION INTERFACE Tatyana Ryutov (ISI) led discussion on two documents related to authorization services and interfaces. The work was motivated by the following goals: a need for fine-grained AC to resources, integrating local and distributed models, user and domain-level policies, support for various authorization models and authentication policies, and of facilitating authorization decisions. In the proposed approach, local policies are expressed via ACLs, and distributed policies via credentials. Optional conditions fields can be added to both ACLs and credentials. Once obtained, credentials (which may be based on GSS or other forms of authentication) are placed into a GAA security context. The Check_authorization call returns one of "authorized", "not authorized", or "more info needed". Several principal types are defined: user, group, host, application, and anybody. A GAA context is composed of credentials and per-connection information reflecting attributes of the would-be accessor. Several generic conditions are proposed, some of which occur only in credentials rather than ACLs; review and comment was particularly solicited on the condition constructs. ISI has implemented a GAA prototype based on Kerberos. A discussion list was announced specifically for these documents: g3api@isi.edu; further information is available on url http://gost.isi.edu/info/gaa_api.html. Proposed areas for future work include refinements to the evaluation facility. Group discussion on GAA followed. Marc Horowitz didn't see that GAA can support a distributed authorization server model, where ACLs don't reside at the application. Cliff Neuman responded that some models of this nature could be supported, invisibly to the caller; alternatively, a client could request a particular set of operations and corresponding credentials could be forwarded. Cliff indicated a belief that, in any case, standardizing ACL formats would be valuable. John Wray (Iris) asked whether and how container ACLs could be supported. Another question: Has work been done to layer over existing ACLs (e.g., POSIX, NT), as this would affect the practical value of GAA? Mary Ellen Zurko (Iris) asked whether multi-personal control was supported; Cliff responded that this support was possible. About 8 attendees endorsed progressing GAA within the CAT group, if this can be accommodated within the WG charter; discussion was encouraged on the WG mailing list. Cliff observed that there was a significant relationship between GSS and GAA security contexts. Several attendees commented that a number of other WGs and BOFs were considering ACLs and authorization, including (as examples) webdav, LDAP extensions, and a trust management BOF taking place later in the meeting week. OTHER TOPICS Richard Ward (Microsoft) noted that Kerberos tickets are becoming increasingly larger as more elements are carried, and larger, and that some protocols have fixed limits. He posed the prospect that token reassembly might be considered below the GSS interface. Ted Ts'o and John Wray opposed this suggestion, given compatibility and protocol layering concerns. Cliff Neuman noted that GAA has upcall functions to obtain information incrementally as needed, but this was recognized as a separate and longer term consideration. Bob Morgan observed that the SASL framework is being incorporated in a number of protocols, and that SASL allows GSS. Ambiguities had been observed about what service principal names are to be used; the SASL recommendation is that names of the host-based service form be used. John Linn recalled discussion with Chris Newman some months prior, which had led to tightened specification of host-based service name usage in rfc2078bis. Ted Ts'o observed that this handles some cases, but not those which are truly application-specific. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Sep 9 20:09:03 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA03684; Wed, 9 Sep 98 20:09:03 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA22103 for ietf-cat-wg-out720680; Wed, 9 Sep 1998 16:42:17 -0700 (PDT) Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.211.168.138]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id QAA22098 for ; Wed, 9 Sep 1998 16:42:15 -0700 (PDT) Received: from llama.ifs.umich.edu (llama.ifs.umich.edu [141.211.168.86]) by quince.ifs.umich.edu (8.6.13/8.6.12) with SMTP id TAA17204 for ; Wed, 9 Sep 1998 19:35:03 -0400 Message-Id: <199809092335.TAA17204@quince.ifs.umich.edu> To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: kerberos-revisions-01: DES3 discussion In-Reply-To: Your message of "Tue, 08 Sep 98 18:37:47 EDT." <199809082237.SAA22974@dcl.MIT.EDU> Date: Wed, 09 Sep 98 19:35:14 -0400 From: Marcus Watts Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Varous people have written about mesage padding of encrypted text: > If the length is always part of the data then including it in the > cryptosystem definition seems redundant. , > We could do this, although it means that with an crypto algorithm with a > block size of 8, there is a 1 in 8 chance that the padded message will etc. Why not use ciphertext stealing instead? I think these are true statements: (1) it's not possible to cheaply hide the length of arbitrarily large messages (2) a proper integrity check (sha, md5, etc) should be sufficient to protect the length of a message with no need to explicitly include the length Other things worthy of note: (3) when krb5-current (or at least krb5-current-19980804) decrypt data (krb5_decrypt), using des3-cbc-sha, des-cbc-crc, or the other crypto systems that use a confounder and message integrity check, the "plaintext" length returned is actually the input ciphertext length and the very tail end of the plaintext is duplicated twice (the last confonder size + checksum size bytes.) (4) krb5_encrypt_tkt_part contains logic that is very careful to copy the encoded ticket to a larger piece of memory and to zero the memory past the end of the ticket. This appears to be pointless, the actual cbc encrypt routines contain their own logic to to supply zero pad data past the end of the plaintext, and shouldn't care about any extra data. [ Also, since realloc can move memory, an unencrypted copy of the ticket may be left in memory despite krb5_encrypt_tkt_part's evident interest in destroying the plaintext when it is through! ] -Marcus Watts UM ITD PD&D Umich Systems Group ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Sep 10 21:05:04 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA14326; Thu, 10 Sep 98 21:05:04 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id RAA03916 for ietf-cat-wg-out720680; Thu, 10 Sep 1998 17:36:16 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id RAA03907 for ; Thu, 10 Sep 1998 17:36:13 -0700 (PDT) Received: from LUMINOUS.MIT.EDU by MIT.EDU with SMTP id AA04703; Thu, 10 Sep 98 20:36:09 EDT Received: (from hartmans@localhost) by luminous.mit.edu (8.8.8/8.6.12) id UAA06522; Thu, 10 Sep 1998 20:36:12 -0400 (EDT) Date: Thu, 10 Sep 1998 20:36:12 -0400 (EDT) Message-Id: <199809110036.UAA06522@luminous.mit.edu> From: Sam Hartman To: cat-ietf@mit.edu Subject: Kerberos revisions: plaintext length Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ted, Marc and I met to discuss the encoding of plaintext issue. We came up with a compromise we would like to bring forward. While all current Kerberos cryptosystems do require the application to know the length of the plaintext, we agree that from a software design point of view, requiring the over-the-wire representation of the encrypted data to encode the plaintext length is desirable. It makes debugging easier. In addition, it is not unreasonable to assume there will be future consumers of the Kerberos cryptosystems outside the strict Kerberos protocol; we allow for such use by registering several keyusage types. So, in the case of 3DES, we will encode the number of pad bytes in the last byte of padding, requiring an extra block of padding in cases where the data falls on an even block boundary. This is consistent with the consensus reached from those who attended the Kerberos breakout meeting at the Chicago IETF, and hopefully will meet with the approval of the list. For future cryptosystems, we do expect to require that the cryptosystem encode the plaintext length somehow. I think that suggesting using self-describing padding would be reasonable, but requiring it would not, partially for the reason Ted described: there may be cyphers with large blocksizes. I would be happy to write text if requested by the document editor. --Sam ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Sep 17 14:51:15 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA21771; Thu, 17 Sep 98 14:51:15 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA04251 for ietf-cat-wg-out720680; Thu, 17 Sep 1998 11:20:36 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id LAA04239 for ; Thu, 17 Sep 1998 11:20:32 -0700 (PDT) From: joes@wrq.com Received: from smaug.wrq.com by MIT.EDU with SMTP id AA24056; Thu, 17 Sep 98 14:20:22 EDT Received: from ursula.wrq.com (root@ursula.wrq.com [150.215.11.58]) by smaug.wrq.com (8.8.6/8.8.6) with ESMTP id LAA28792; Thu, 17 Sep 1998 11:20:27 -0700 (PDT) Received: from localhost (root@localhost) by ursula.wrq.com with SMTP (8.7.6/8.7.3) id LAA24300; Thu, 17 Sep 1998 11:20:26 -0700 (PDT) X-Openmail-Hops: 1 Date: Thu, 17 Sep 1998 11:20:22 -0700 Message-Id: In-Reply-To: <199809110036.UAA06522@luminous.mit.edu> Subject: Re: Kerberos revisions: plaintext length To: hartmans@mit.edu Cc: cat-ietf@mit.edu Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Item Subject: Kerberos revisions: plaintext length It would be good to explicitly allow for overpadding to obfuscate the length of the message. This would allow for 1 - 255 bytes of padding (to a block size boundary of course) this would be especially useful if applications other than Kerberos are going to use this cryptosystem (although it could be useful with Kerberos as well). Joe ______________________________ Reply Separator _________________________________ Subject: Kerberos revisions: plaintext length Author: hartmans (hartmans@mit.edu) at internet,shar Date: 9/10/98 5:36 PM Ted, Marc and I met to discuss the encoding of plaintext issue. We came up with a compromise we would like to bring forward. While all current Kerberos cryptosystems do require the application to know the length of the plaintext, we agree that from a software design point of view, requiring the over-the-wire representation of the encrypted data to encode the plaintext length is desirable. It makes debugging easier. In addition, it is not unreasonable to assume there will be future consumers of the Kerberos cryptosystems outside the strict Kerberos protocol; we allow for such use by registering several keyusage types. So, in the case of 3DES, we will encode the number of pad bytes in the last byte of padding, requiring an extra block of padding in cases where the data falls on an even block boundary. This is consistent with the consensus reached from those who attended the Kerberos breakout meeting at the Chicago IETF, and hopefully will meet with the approval of the list. For future cryptosystems, we do expect to require that the cryptosystem encode the plaintext length somehow. I think that suggesting using self-describing padding would be reasonable, but requiring it would not, partially for the reason Ted described: there may be cyphers with large blocksizes. I would be happy to write text if requested by the document editor. --Sam ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sun Sep 20 18:50:30 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA21333; Sun, 20 Sep 98 18:50:30 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id PAA01904 for ietf-cat-wg-out720680; Sun, 20 Sep 1998 15:22:48 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id PAA01899 for ; Sun, 20 Sep 1998 15:22:45 -0700 (PDT) Received: from rover.cygnus.com by MIT.EDU with SMTP id AA03444; Sun, 20 Sep 98 18:22:15 EDT Received: (from marc@localhost) by rover.cygnus.com (8.8.8/8.6.12) id SAA01717; Sun, 20 Sep 1998 18:22:36 -0400 (EDT) To: joes@wrq.com Cc: hartmans@mit.edu, cat-ietf@mit.edu Subject: Re: Kerberos revisions: plaintext length References: From: Marc Horowitz Date: 20 Sep 1998 18:22:36 -0400 In-Reply-To: joes@wrq.com's message of Thu, 17 Sep 1998 11:20:22 -0700 Message-Id: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk joes@wrq.com writes: >> It would be good to explicitly allow for overpadding to obfuscate the >> length of the message. This would allow for 1 - 255 bytes of padding >> (to a block size boundary of course) this would be especially useful >> if applications other than Kerberos are going to use this cryptosystem >> (although it could be useful with Kerberos as well). I think that overpadding is best done by the application, not by the encryption mechanism. Marc ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Sep 21 16:09:27 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA29981; Mon, 21 Sep 98 16:09:27 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA15210 for ietf-cat-wg-out720680; Mon, 21 Sep 1998 12:15:18 -0700 (PDT) Received: from debbie.dascom.com (debbie.dascom.com [12.7.226.1]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA15203 for ; Mon, 21 Sep 1998 12:15:15 -0700 (PDT) Received: (qmail 1606 invoked from network); 21 Sep 1998 19:15:14 -0000 Received: from server.cruz.dascom.com (HELO dascom.com) (10.0.0.171) by debbie.dascom.com with SMTP; 21 Sep 1998 19:15:14 -0000 Received: from dascom.com (mokum.cruz.dascom.com [10.0.0.106]) by dascom.com for ; Mon, 21 Sep 1998 12:15:14 -0700 (PDT) Message-Id: <3606A5C9.123E443D@dascom.com> Date: Mon, 21 Sep 1998 12:15:21 -0700 From: Frank Siebenlist Organization: DASCOM, Inc. X-Mailer: Mozilla 4.06 [en] (WinNT; U) Mime-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: pkinit progress? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Could we please get an update on the progress of the pkinit draft from the authors? Believe we were "promised" a final draft for last call in a matter of weeks at Chicago... We would like to base our related work for the Open Group on the RFC and are eagerly awaiting its acceptance. Thanks, Frank. -- Frank Siebenlist DASCOM, Inc. Chief Architect 3004 Mission Street Email: frank@dascom.com Santa Cruz, CA 95060, USA Phone: +1 831/460-3600 Fax: +1 831/460-0255 ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 22 19:24:19 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA10655; Tue, 22 Sep 98 19:24:19 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id PAA05589 for ietf-cat-wg-out720680; Tue, 22 Sep 1998 15:43:58 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id PAA05582 for ; Tue, 22 Sep 1998 15:43:56 -0700 (PDT) From: joes@wrq.com Received: from smaug.wrq.com by MIT.EDU with SMTP id AA14231; Tue, 22 Sep 98 18:42:42 EDT Received: from ursula.wrq.com (root@ursula.wrq.com [150.215.11.58]) by smaug.wrq.com (8.8.6/8.8.6) with ESMTP id PAA20285; Tue, 22 Sep 1998 15:43:47 -0700 (PDT) Received: from localhost (root@localhost) by ursula.wrq.com with SMTP (8.7.6/8.7.3) id PAA13216; Tue, 22 Sep 1998 15:43:46 -0700 (PDT) X-Openmail-Hops: 1 Date: Tue, 22 Sep 1998 15:43:34 -0700 Message-Id: In-Reply-To: Subject: Re: Kerberos revisions: plaintext length To: marc@cygnus.com Cc: hartmans@mit.edu, cat-ietf@mit.edu, joes@wrq.com Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I think this depends on the situation. If the application is intimately involved in the underlying security mechanism then it makes sense for the application to provide overpadding. For an application that uses Kerberos ciphersuites directly this is probably true. (in this case the application has to keep track of the length) If the application is somewhat abstracted from the security mechanism then it makes sense for the mechanism to provide a facility for overpadding. This is more the case of GSSAPI. The current draft for GSSAPI-Kerberos v2 provides for plaintext length to be encrypted with the data. (the length is limited to a 32 bit integer in the draft, is this a problem?) Anyway, it seems that the padding scheme is pretty harmless, although it may be somewhat redundant. Joe ______________________________ Reply Separator _________________________________ Subject: Re: Kerberos revisions: plaintext length Author: marc (marc@cygnus.com) at internet,shar Date: 9/20/98 3:22 PM joes@wrq.com writes: >> It would be good to explicitly allow for overpadding to obfuscate the >> length of the message. This would allow for 1 - 255 bytes of padding >> (to a block size boundary of course) this would be especially useful >> if applications other than Kerberos are going to use this cryptosystem >> (although it could be useful with Kerberos as well). I think that overpadding is best done by the application, not by the encryption mechanism. Marc ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Sep 28 16:39:43 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA04564; Mon, 28 Sep 98 16:39:43 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA08123 for ietf-cat-wg-out720680; Mon, 28 Sep 1998 13:06:38 -0700 (PDT) Received: from moe.gf.org (moe.gf.org [207.86.8.75]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id NAA08116 for ; Mon, 28 Sep 1998 13:06:34 -0700 (PDT) Received: from foobar (jlefevre.dialup.access.net [166.84.194.85]) by moe.gf.org (8.8.5/8.8.5) with SMTP id QAA02723 for ; Mon, 28 Sep 1998 16:35:22 -0400 Message-Id: <199809282035.QAA02723@moe.gf.org> X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Sep 1998 16:08:30 -0400 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: output token with 'accept' failure: OK? Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Is it un-kosher for GSS_Accept_sec_context to return an output token if the major result is other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE -- if, say, it's GSS_S_DEFECTIVE_TOKEN or GSS_S_FAILURE? --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Sep 28 17:13:20 1998 Received: from [171.64.14.232] by bitsy.MIT.EDU with SMTP id AA04774; Mon, 28 Sep 98 17:13:20 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA11586 for ietf-cat-wg-out720680; Mon, 28 Sep 1998 13:41:21 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id NAA11575 for ; Mon, 28 Sep 1998 13:41:17 -0700 (PDT) Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 28 Sep 1998 20:40:23 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id QAA07326; Mon, 28 Sep 1998 16:47:16 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Mon, 28 Sep 1998 16:45:18 -0400 Message-Id: From: "Linn, John" To: "ietf-cat-wg@lists.Stanford.EDU" , "'Michael Smith'" Subject: RE: output token with 'accept' failure: OK? Date: Mon, 28 Sep 1998 16:42:57 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk GSS_Init_sec_context() and GSS_Accept_sec_context() may return output tokens no matter what major_status is returned, indicating whether or not an output token is present by whether or not the returned value is non-null. Per recent discussion as reflected in 2078bis-07, section 1.1.2 on Tokens, we've now stated that per-message calls are not to return tokens along with error major_status, but context-level calls continue to be permitted (though not required) to do so. --jl > ---------- > From: Michael Smith[SMTP:ms@gf.org] > Sent: Monday, September 28, 1998 4:08 PM > To: ietf-cat-wg@lists.Stanford.EDU > Subject: output token with 'accept' failure: OK? > > Is it un-kosher for GSS_Accept_sec_context to > return an output token if the major result is > other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE > -- if, say, it's GSS_S_DEFECTIVE_TOKEN or > GSS_S_FAILURE? > > > --Michael Smith > ms@gf.org > > ========================================================================== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Sep 28 19:15:42 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA05526; Mon, 28 Sep 98 19:15:42 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id PAA24281 for ietf-cat-wg-out720680; Mon, 28 Sep 1998 15:45:27 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id PAA24272 for ; Mon, 28 Sep 1998 15:45:24 -0700 (PDT) Received: from tnt.isi.edu by MIT.EDU with SMTP id AA29598; Mon, 28 Sep 98 18:45:22 EDT Received: from cayman-islands.isi.edu (cayman-islands.isi.edu [128.9.160.140]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA28931; Mon, 28 Sep 1998 15:45:21 -0700 (PDT) Received: (from bcn@localhost) by cayman-islands.isi.edu (8.8.7/8.8.6) id PAA08624; Mon, 28 Sep 1998 15:45:21 -0700 (PDT) Date: Mon, 28 Sep 1998 15:45:21 -0700 (PDT) Message-Id: <199809282245.PAA08624@cayman-islands.isi.edu> From: Clifford Neuman To: cat-ietf@mit.edu Subject: Kerberos discussions subequent to CAT meeting Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk My apologies for taking so long to get this out. This is a summary of the meeting that took place Tuesday afternoon at the IETF to discuss the detailed revisions to. Those who were interested in the detailed revisions to 1510 met on Tuesday afternoon at 3:45. This message summarizes the results of that meeting, and also lists those changes to be made or issues that still need resultion regarding the revision to e draft. Issue (1) TCP as a required transport In LA it was decided that this would be mandatory. The question was raised whether it was to be mandatory for the KDC, or for all clients too, and there were arguments on both sides of the issue relating to making installed base non-conformant, but also the need to support extensions for things like pk-init, authorization data, etc. At first we decided that it should be must support for the KDC and should support for the clent. With further discussion, with Jeff Schiller present, we decided on an alternative (for ratification by the full CAT group) of "should support" for both, but including a note pointing out that specific extensions will not work if any implementation not supporting the TCP transport is involved (client or KDC) and also noting that the "should" will likely be changed to a "must" in the future. (2) For the TCP transport, issues discussed were: When do we close the stream Decided that KDC can close the stream after sending a response, but may leave the stream open if it expects a followup - in which case it may close the stream at any time if resource constratints or other factors make it desirable to do so. Client may close the stream after receiving response, and should close the stream if it does not expect to send followup messages. Client must be prepared to have the stream closed by the KDC at anytime, in which case it must simply connect again when it is ready to send subsequent messages. How to distingish one message from next Currently 4 octet length field is included in message, indicating end of message and start of next (with another length field). There was debate about the length of this field, and the necessity of it, given that ASN.1 encoding specifies the length up front anyway. There was feeling by some that the ASN.1 lengths were hard to parse, and that a simpler (extra) encoding was needed so that the transport could easily read complete messages before passing to the ASN.1 parsing routine. Decided to make length field variable, minimum 4 octets, with a sign bit that if set means that the next 4 bytes should be read, extending the length field by another 4 octets less 1 bit. How to prevent dinial of service (at least one kind of attack) KDC is free to drop connections after initial response has been sent, at which point the client would need to establish a new connection for any subsequent messages with the KDC. Other issue to be resolved: How to fallback to alternate KDC with TCP Issues of simultaneous connection to multiple KDC's (It was noted that Microsoft is using multimaster KDC's) (3) Ticket extensions No concensus reached Though there had seemed to be consensus reached at the LA meeting regarding the inclusion of ticket extensions outside the ticket, that consensus seems to have dissapeared at this meeting. I will try to dig up the details from the LA CAT meeting, and we will try to rebuild consensus on this issue on the CAT list. ADATA for required ticket extensions Resolution pending resolution of topic above. (4) Error checksum The error checksum specified in the latest revision is to be calculated over the KRB-ERROR message with the checksum absent, and is then to be inserted in the message before transmission. When reencoding, must be sure to do ASN.1 right. For optional fields, must indicate that certain values are not allowed because they are always defaulted. For example, one would not send a microsecond zero value (or other default values) because one wants to make sure there is only one way to encode the fields. This is only important for optional integer value and date fields, where a default value has been specified. (5) Ranges - explicit on assigned numbers A must support range will be specified for assigned numbers to that implementations can be built with an understanding that they will not break should a number outside this range be received. If numbers are received that are outside this range, then it will be OK for implementations that do not understand the meaning of the assigned number to reject the request (but they can't die). This is not an intrinsic protocol number, since the protocol will support large numbers. It will be specified for a particular "specification" for conformance. We will set the range to be based on 32 bit types (signed or unsigned) for the initial specification. For sequence numbers, we will define to wrap after 32 bits. (6) Additional fields in ASN.1 sequences We will specify that any additional field in ASN.1 seuquences should be carried through if not understood. That they should not be dropped when the sequence is reencoded (per Tom Yu). (7) Bit string of unnamed bits This was agreed to in LA. That the specification of Bitstrings will be changed to a string of unnamed bits, with the meanings of the bits then defined in the spec. This is how it is implemented now. Such strings will always have at least 32 bits. If no bits set above 32, then exactly 32 bits sent. If a bit above the 32nd is set, then will send the actual number of bits up to that point. (6) A last_req type of (6) will indicate when password will expire. (7) Triple-DES activity The spec will be brought up to date when I receive the new string-to-key and encoding specification from Marc Horowitz. I received these Documents from Marc on the 24th and will proceed based on his input. Due to existing implementations based on older MIT code, a new encryption type will be defined for the new methods, which will include the Key derivation extensions discussed briefly in LA. As part of this we will also address the ciphertext padding issues that have been discussed on the list. (8) Mapping of X.500 names to Kerberos principals and transited field. The new specification will use the RFC2253 mapping, and will specify this mapping is to be used. (9) The mechanism to support name referrals will be documented in more detail. (10) A section will be added with differences from the original 1510 specification. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Sep 29 17:54:42 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA14389; Tue, 29 Sep 98 17:54:42 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id OAA13207 for ietf-cat-wg-out720680; Tue, 29 Sep 1998 14:11:23 -0700 (PDT) Received: from ude.isi.edu (ude.isi.edu [128.9.128.53]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id OAA13185 for ; Tue, 29 Sep 1998 14:11:17 -0700 (PDT) Received: (from brian@localhost) by ude.isi.edu (8.8.5/8.8.5) id OAA32393 for ietf-cat-wg@lists.stanford.edu; Tue, 29 Sep 1998 14:13:20 -0700 Date: Tue, 29 Sep 1998 14:13:20 -0700 From: Brian Tung Message-Id: <199809292113.OAA32393@ude.isi.edu> To: ietf-cat-wg@lists.stanford.edu Subject: PKINIT (-07.txt) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Two changes: made DH the mandatory crypto algorithm, and added a comment about the (still inconclusive) patent issue regarding private key storage. b ***** INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-init-07.txt Clifford Neuman Updates: RFC 1510 ISI expires May 15, 1999 John Wray Digital Equipment Corporation Ari Medvinsky Matthew Hur Sasha Medvinsky 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-07.txt, and expires May 15, 1999. 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 as a building block for other specifications. PKCROSS [3] utilizes PKINIT for establishing the inter-realm key and associated inter-realm policy to be applied in issuing cross realm service tickets. As specified in [4], anonymous Kerberos tickets can be issued by applying a NULL signature in combination with Diffie-Hellman in the PKINIT exchange. Additionally, The PKINIT specification may be used for direct peer to peer authentication without contacting a central KDC. This application of PKINIT is described in PKTAPP [5] and is based on concepts introduced in [6, 7]. For direct client-to-server authentication, the client uses PKINIT to authenticate to the end server (instead of a central KDC), which then issues a ticket for itself. This approach has an advantage over SSL [8] in that the server does not need to save state (cache session keys). Furthermore, an additional benefit is that Kerberos tickets can facilitate delegation (see [9]). 3. Proposed Extensions This section describes extensions to RFC 1510 for supporting the use of public key cryptography in the initial request for a ticket granting ticket (TGT). In summary, the following 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 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 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-RFC2253. The full realm name will appear as follows: X500-RFC2253:RFC2253Encode(DistinguishedName) where DistinguishedName is an X.500 name, and RFC2253Encode is a readable ASCII encoding of an X.500 name, as defined by RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which is not supported by this version of PKINIT.) To ensure that this encoding is unique, we add the following rule to those specified by RFC 2253: The order in which the attributes appear in the RFC 2253 encoding must be the reverse of the order in the ASN.1 encoding of the X.500 name that appears in the public key certificate. The order of the relative distinguished names (RDNs), as well as the order of the AttributeTypeAndValues within each RDN, will be reversed. (This is despite the fact that an RDN is defined as a SET of AttributeTypeAndValues, where an order is normally not important.) Similarly, 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: RFC2253Encode(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. 3.1.2. Algorithm Identifiers PKINIT does not define, but does permit, the algorithm identifiers listed below. 3.1.2.1. Signature Algorithm Identifiers These are the algorithm identifiers for use in the Signature data structure: sha-1WithRSAEncryption ALGORITHM PARAMETER NULL ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } dsaWithSHA1 ALGORITHM PARAMETER NULL ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) oIWSecAlgorithm(2) dsaWithSHA1(27) } md4WithRsaEncryption ALGORITHM PARAMETER NULL ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) oIWSecAlgorithm(2) md4WithRSAEncryption(4) } md5WithRSAEncryption ALGORITHM PARAMETER NULL ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) md5WithRSAEncryption(4) } 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier This algorithm identifier is used inside the SubjectPublicKeyInfo data structure: dhKeyAgreement ALGORITHM PARAMETER DHParameters ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-3(3) dhKeyAgreement(1) } DHParameters ::= SEQUENCE { prime INTEGER, -- p base INTEGER, -- g privateValueLength INTEGER OPTIONAL } -- as specified by the X.509 recommendation [9] 3.1.2.3. Algorithm Identifiers for RSA Encryption These algorithm identifiers are used inside the EnvelopedData data structure, for encrypting the temporary key with a public key: rsaEncryption ALGORITHM PARAMETER NULL ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1) 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys These algorithm identifiers are used inside the EnvelopedData data structure, for encrypting the temporary key with a Diffie-Hellman- derived key, or for encrypting the reply key: desCBC ALGORITHM PARAMETER IV8 ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3) oIWSecAlgorithm(2) desCBC(7) } DES-EDE3-CBC ALGORITHM PARAMETER IV8 ::= { iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) desEDE3(7) } IV8 ::= OCTET STRING (SIZE(8)) -- initialization vector rc2CBC ALGORITHM PARAMETER RC2-CBCParameter ::= { iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) rc2CBC(2) } The rc2CBC algorithm parameters (RC2-CBCParameter) are defined in the following section. rc4 ALGORITHM PARAMETER NULL ::= { iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) rc4(4) } The rc4 algorithm cannot be used with the Diffie-Hellman-derived keys, because its parameters do not specify the size of the key. 3.1.2.5. rc2CBC Algorithm Parameters This definition of the RC2 parameters is taken from a paper by Ron Rivest [13]. Refer to [13] for the complete description of the RC2 algorithm. RC2-CBCParameter ::= CHOICE { iv IV, params SEQUENCE { version RC2Version, iv IV } } where IV ::= OCTET STRING -- 8 octets RC2Version ::= INTEGER -- 1-1024 RC2 in CBC mode has two parameters: an 8-byte initialization vector (IV) and a version number in the range 1-1024 which specifies in a roundabout manner the number of effective key bits to be used for the RC2 encryption/decryption. The correspondence between effective key bits and version number is as follows: 1. If the number EKB of effective key bits is in the range 1-255, then the version number is given by Table[EKB], where the 256-byte translation table is specified below. It specifies a permutation on the numbers 0-255. 2. If the number EKB of effective key bits is in the range 256-1024, then the version number is simply EKB. The default number of effective key bits for RC2 is 32. If RC2-CBC is being performed with 32 effective key bits, the parameters should be supplied as a simple IV, rather than as a SEQUENCE containing a version and an IV. 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0 10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a 20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36 30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c 40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60 50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa 60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e 70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf 80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6 90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3 a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2 c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5 d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5 e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab 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; -- if present, the KDC must use -- the public key from this -- particular certificate chain to -- verify the signature in the -- request trustedCertifiers [2] SEQUENCE OF PrincipalName OPTIONAL, -- CAs that the client trusts serialNumber [3] CertificateSerialNumber OPTIONAL -- specifying a particular KDC -- certificate if the client -- already has it; -- must be accompanied by -- a single trustedCertifier } CertificateSerialNumber ::= INTEGER -- as specified by PKCS #6 [15] 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, parameters ALGORITHM.&type } -- as specified by the X.509 recommendation [10] SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, -- dhKeyAgreement subjectPublicKey BIT STRING -- for DH, equals -- public exponent (INTEGER encoded -- as payload of BIT STRING) } -- as specified by the X.509 recommendation [9] Certificate ::= SEQUENCE { certType [0] INTEGER, -- type of certificate -- 1 = X.509v3 (DER encoding) -- 2 = PGP (per PGP specification) -- 3 = PKIX (per PKCS #6 [15]) 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). 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 determined by the following decision algorithm: 1. If the KDC has a mapping from the name in the certificate to a Kerberos name, then use that name. Else 2. If the certificate contains a Kerberos name in an extension field, and local KDC policy allows, then use that name. Else 3. Use the name as represented in the certificate, mapping as necessary (e.g., as per RFC 2253 for X.500 names). In this case the realm in the ticket shall be the name of the certification authority that issued the user's 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 encKeyPack [1] EnvelopedKeyPack, -- temporary key is encrypted -- using either the client public -- key or the Diffie-Hellman key -- specified by SignedKDCPublicValue. -- SignedReplyKeyPack, encrypted -- with the temporary key, is also -- included. signedKDCPublicValue [2] SignedKDCPublicValue OPTIONAL, -- if one was passed in the request kdcCert [3] SEQUENCE OF Certificate OPTIONAL -- the KDC's certificate chain } The EnvelopedKeyPack data type below contains an encrypted temporary key (either with the PKINIT client's public key or with a symmetric key, resulting from the Diffie-Hellman exchange). It also contains a signed and encrypted reply key. This data structure is similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12]. EnvelopedKeyPack ::= SEQUENCE { version Version, -- Always set to 0. recipientInfos RecipientInfos, -- This is a SET, which must contain -- exactly one member. Contains a -- temporary key, encrypted with the -- client's public key. This -- temporary key is used to encrypt -- the reply key. encryptedContentInfo EncryptedContentInfo -- contains the signed and encrypted -- reply key } Version ::= INTEGER RecipientInfos ::= SET OF RecipientInfo RecipientInfo ::= SEQUENCE { version Version, -- shall be 0 rid RecipientIdentifier, -- Since this is an optional field, -- it supports both CMS and PKCS #7 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, EncryptedKey OCTET STRING -- the temporary key, encrypted with -- the PKINIT client's public key } KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier RecipientIdentifier ::= IssuerAndSerialNumber -- Corresponds to the X.509 V3 extension -- SubjectKeyIdentifier. IssuerAndSerialNumber ::= SEQUENCE { issuer Name, -- a distinguished name, as defined -- by X.509 serialNumber CertificateSerialNumber } CertificateSerialNumber ::= INTEGER EncryptedContentInfo ::= SEQUENCE { contentType ContentType, -- shall be: -- iso(1) member-body(2) us(840) -- rsadsi(113549) pkcs(1) pkcs7(7) -- EnvelopedData(3) contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier -- Algorithm used to encrypt the -- SignedReplyKeyPack. encryptedContent OCTET STRING -- The encrypted data is of the type -- SignedReplyKeyPack. } ContentType ::= OBJECT IDENTIFIER ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier SignedReplyKeyPack ::= SEQUENCE { replyKeyPack [0] ReplyKeyPack, replyKeyPackSig [1] Signature, -- of replyKeyPack -- 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 } 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. X.509 certificates shall contain the principal name of the KDC as the SubjectAltName version 3 extension. Below is the definition of this version 3 extension, as specified by the X.509 standard: subjectAltName EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName } GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, ... } OTHER-NAME ::= TYPE-IDENTIFIER In this definition, otherName is a name of any form defined as an instance of the OTHER-NAME information object class. For the purpose of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will be replaced by the type KerberosPrincipalName: KerberosPrincipalName ::= SEQUENCE { nameType [0] OTHER-NAME.&id ( { PrincipalNameTypes } ), name [1] OTHER-NAME.&type ( { PrincipalNameTypes } { @nameType } ) } PrincipalNameTypes OTHER-NAME ::= { { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst } } 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 } (This specification can also be used to specify a Kerberos name within the user's certificate.) The client then extracts the random key used to encrypt the main reply. This random key (in encPaReply) is encrypted with either the client's public key or with a key derived from the DH values exchanged between the client and the KDC. 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.2.2. Required Algorithms and Data Formats Not all of the algorithms in the PKINIT protocol specification have to be implemented in order to comply with the proposed standard. Below is a list of the required algorithms and data formats: - Diffie-Hellman public/private key pairs - SHA1 digest and DSA for signatures - X.509 version 3 certificates - 3-key triple DES keys derived from the Diffie-Hellman Exchange - 3-key triple DES Temporary and Reply keys 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 encKeyPack [1] EnvelopedKeyPack, -- temporary key is encrypted -- using the KDC public -- key. -- SignedRandomKeyPack, encrypted -- with the temporary key, is also -- included. userCert [2] SEQUENCE OF Certificate OPTIONAL -- the user's certificate chain; -- if present, the KDC must use -- the public key from this -- particular certificate chain to -- verify the signature in the -- request } In the above message, the content of the encKeyPack is similar to the content of the encKeyPack field in the PA-PK-AS-REP message, except that it is the KDC's public key and not the client's public key that is used to encrypt the temporary key. And, the encryptedContentInfo field inside the EnvelopedKeyPack contains encrypted data of the type SignedRandomKeyPack instead of the SignedReplyKeyPack. 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 } 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. (This section may or may not fall under the purview of a patent for private key storage; please see Section 8 for more information.) 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. Lastly, PKINIT calls for randomly generated keys for conventional cryptosystems. Many such systems contain systematically "weak" keys. PKINIT implementations MUST avoid use of these keys, either by discarding those keys when they are generated, or by fixing them in some way (e.g., by XORing them with a given mask). These precautions vary from system to system; it is not our intention to give an explicit recipe for them here. 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] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-cat-pktapp-00.txt [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed System Security, 1997. [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, July 1995. [8] Alan O. Freier, Philip Karlton and Paul C. Kocher. The SSL Protocol, Version 3.0 - IETF Draft. [9] B.C. Neuman, Proxy-Based Authorization and Accounting for Distributed Systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, May 1993. [10] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8 [11] R. Hously. Cryptographic Message Syntax. draft-ietf-smime-cms-04.txt, March 1998. [12] PKCS #7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note Version 1.5 Revised November 1, 1993 [13] Ron Rivest, MIT Laboratory for Computer Science and RSA Data Security, Inc. A Description of the RC2(r) Encryption Algorithm, November 1997. [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. Request for Comments 2253. [15] PKCS #6: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note Version 1.5 Revised November 1, 1993 7. Patent Issues The private key storage and retrieval process described in Section 3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of Digital Corporation). At this time, inquiries into this patent are inconclusive. We solicit discussion from any party who can illuminate the coverage of this particular patent. 8. Acknowledgements Some of the ideas on which this proposal is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos and SPX. Some ideas have also been drawn from the DASS system. These changes are by no means endorsed by these groups. This is an attempt to revive some of the goals of those groups, and this proposal approaches those goals primarily from the Kerberos perspective. Lastly, comments from groups working on similar ideas in DCE have been invaluable. 9. Expiration Date This draft expires May 15, 1999. 10. Authors Brian Tung Clifford Neuman USC Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: {brian, bcn}@isi.edu 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 Sasha Medvinsky CyberSafe Corporation 1605 NW Sammamish Road Suite 310 Issaquah WA 98027-5378 Phone: +1 206 391 6000 E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com Jonathan Trostle 170 W. Tasman Dr. San Jose, CA 95134 E-mail: jtrostle@cisco.com ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu