From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 2 14:39:35 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27254; Thu, 2 Apr 98 14:39:35 EST Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA22405 for cat-ietf-redist; Thu, 2 Apr 1998 13:16:16 -0500 (EST) From: David Hemsath To: , Subject: CMS API standard Message-Id: <5040300014520053000002L032*@MHS> Date: Thu, 2 Apr 1998 13:14:16 -0500 Mime-Version: 1.0 Content-Type: text/plain Precedence: bulk By way of introduction, I've been working with Greg Clark of DASCOM, Inc., who spoke with the CAT-WG last Monday on the use of CMS (Cryptographic Message Syntax) with Kerberos PK-INIT. I couldn't help but notice, when looking at the upcoming S/MIME Freeware Library, that its CMS APIs bear a striking resemblence to IDUP-GSS-API. Is there any joint work planned between the CAT and S/MIME WGs to make IDUP-GSS-API the standard APIs for generating and consuming CMS messages? David K. Hemsath, IBM Security Architecture From owner-cat-ietf@pad-thai.cam.ov.com Mon Apr 6 10:42:37 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA02644; Mon, 6 Apr 98 10:42:37 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA11927 for cat-ietf-redist; Mon, 6 Apr 1998 09:16:19 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 06 Apr 1998 08:15:41 -0500 From: Peter Lindstrom To: cat-ietf@mit.edu Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Precedence: bulk subscribe lindstp@war.wyeth.com From owner-cat-ietf@pad-thai.cam.ov.com Mon Apr 6 13:46:53 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05801; Mon, 6 Apr 98 13:46:53 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA00422 for cat-ietf-redist; Mon, 6 Apr 1998 12:24:37 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F801276601211167@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Subject: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Mon, 6 Apr 1998 12:26:44 -0400 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk This message is to initiate a CAT WG Last-Call on the most recently updated version of the IDUP draft, draft-ietf-cat-idup-gss-10.txt, considering potential submission to the IESG on behalf of the CAT WG with a request for advancement to Proposed Standard. Any reviewers with comments pending on this version are hereby requested to indicate them to the list NLT Friday, 24 April. Regards, ... --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 9 08:01:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA16144; Thu, 9 Apr 98 08:01:00 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id GAA08194 for cat-ietf-redist; Thu, 9 Apr 1998 06:21:37 -0400 (EDT) Message-Id: <9804091022.AA05229@MIT.EDU> From: GIC To: Date: Thu, 09 Apr 1998 10:20:10 "GMT" X-Msmail-Priority: Normal X-Mailer: AspMail 2.4 (SMTP669585) Subject: GKB FREE SERVICES UPDATE (4/98) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Precedence: bulk Update on Global KnowledgeBase (http://gkb.com) free internet services. (4/98) Dear gkb user, Thanks to you, our campaign for Global KnowledgeBase (http://gkb.com) is continues to be a great success attracting more than 4000 unique users/daily. Continue to Explore and Contribute to create the accumulated knowledge in gkb.com, for the benefit of all. To login to the GKB applications please use the gkb login as follows: Your login ID : cat-ietf@mit.edu GKB User Code : 4230 New features ============ Global Journal - The newest and most dynamic meduim to exchange internet knowledge, in Global Journal, you, the GKB user, have the opportunity to express your opinion, provide newsworthy internet links, or cite facts. GlobalShop - best source of information on over 60,000 products listed, giving direct access to the price lists of the best known, compare prices, look for new models and benefit from special offers. Build your e-commerce, integrate your own catalog in Global Shop for free. Global Free - Explore and Contribute to the free Internet services knowledgebase Web messaging - if you have an email address @gkb.com (which is free), explore your Email directly on the web. Personal&Email KB - If you are looking for users sharing the your area of interests, or simply email of users in your area. GlobalChat - web based chat for all The old and successful free features are always there. ===================================================== Interactive Classifieds - Free interactive classifieds segmented by marketplace and criteria (more than 8000 ads in Geneva area only) Press Releases - Free press release publication. Business Guide - Free business internet site application GlobalJob - Free job listing for companies, and free CV listing for individuals. Business Opportunities - Free business opporrtunities publication by marketplace/industry Free email addresses at gkb.com are always available. Global Finance - gkb financial knowledgebase Global Events - free events listing in the events knowledgeBase We hope you will find the new and old feature useful. Regards Gkb team From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 9 11:50:33 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA20110; Thu, 9 Apr 98 11:50:33 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA00642 for cat-ietf-redist; Thu, 9 Apr 1998 10:19:54 -0400 (EDT) Message-Id: <352D57AF.5E2B@bull.net> Date: Thu, 09 Apr 1998 16:20:15 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: CAT-IETF WG Subject: Final clean up of SPNEGO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk CAT fanciers, Following some discussions with Marc Horowitz and John Linn here are the final changes made to SPNEGO before sending it to IESG for publication. Page 4: Previous text: If a proposed mechanism other than the preferred mechanism is accepted, the negotiation token response may contain also an initial security token from that mechanism (e.g. to transmit a certificate). New text: If a proposed mechanism is accepted, and it was not the preferred mechanism, or if the first negotiation token sent by the initiator did not included a mechToken, then the negotiation token response sent by the target may contain also a response token from that mechanism which transmits mechanism-specific information (e.g. to transmit a certificate). The initiator may ignore such an initial token if it is not prepared to process it. Page 4: GSS_S_BAD_SIG replaced by GSS_S_BAD_MIC. Page 6: Previous text: the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the BER/DER encoding conventions. New text: the "innerContextToken" field contains the ASN.1 structure "NegociationToken" given below, encoded using the DER encoding conventions. Page 9: Previous text: Three cases may then be considered: 1) If the mechListMIC is present and correct the context is established by the target. 2) If the mechList is present but corrupted, then the context establishment must fail. 3) If the mechListMIC is not included in the final NegTokenInit, then GSS_S_CONTINUE_NEEDED must be returned to the target. The MIC must then be included in the NegTokenTarg as described above, and the NegTokenTarg must be sent back to the initiator, which must verify that the mechListMIC field is present and valid. New text: Three cases may then be considered: 1) If the mechListMIC is present and correct, then GSS_S_COMPLETE is returned to the target with no token; the context is established by the target. 2) If the mechListMIC is present but invalid, then the context establishment must fail. An error major status code is returned to the target. 3) If the mechListMIC is not included in the final NegTokenInit, then GSS_S_COMPLETE must be returned to the target with a token. This token must be a NegTokenTarg, with a MIC included as described above, and no responseToken. The application will then send this token back to the initiator, which must verify that the mechListMIC field is present and valid. Regards, Denis. Editor of SPNEGO -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 9 14:51:13 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA23235; Thu, 9 Apr 98 14:51:13 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA17722 for cat-ietf-redist; Thu, 9 Apr 1998 13:15:07 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F801276601211184@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Subject: Draft minutes for CAT LA meetings Date: Thu, 9 Apr 1998 13:17:11 -0400 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Here are the draft minutes for the CAT-WG LA sessions. Any attendees with additions or corrections should send them to the list NLT Thursday, 16 April, to allow their reflection within a timely submission to the secretariat. Thanks, ... --jl DRAFT minutes for Common Authentication Technology (CAT) WG meeting, Los Angeles IETF, compiled by John Linn (RSA Laboratories). SUMMARY The CAT WG met for 1.5 sessions at the Los Angeles IETF, with a total of 138 attendees. RFC2078bis final editing changes were agreed by the attendees; following corresponding edits, it will be forwarded to the IESG. Agreement among attendees was also reached to recommend SPNEGO for advancement. IDUP was not discussed in detail, but its most recent update is to be placed into WG Last-Call subsequent to the meeting. Revised PKINIT and PKCROSS drafts were discussed; one particular issue concerned alignment potential between PKINIT and S/MIME's CMS, and a proposal was made to replicate a subset of CMS material within PKINIT. A number of issues were discussed with regard to the kerberos-revisions draft, as input to editing during the meeting week; following subsequent WG Last-Call, it is intended that this draft will be targeted to succeed RFC-1510 at the Proposed Standard level. Given limited demonstrated constituency within the WG, it was proposed that FTPDSAAUTH be considered for Experimental or Informational status. Mike Swift (Microsoft) proposed and led an exploratory discussion on potential futures for CAT technologies and group activities. The updated PKTAPP draft was presented; follow-up discussion is to consider whether to target it (with some revisions as discussed) for Informational status or to combine its material with other drafts. The new PKRECOVERY draft was presented; it was observed that such facilities, if required and specified, might be placed more appropriately within a management protocol. A new version of the kerberos-password-chg draft, responsive to recent comments, will be prepared and submitted for WG Last-Call. WG LAST-CALLED DOCUMENTS Discussion began with review and consideration of documents which had been through one or more WG Last-Calls, including 2078bis, spnego, ftpdsaauth, and idup. WG LAST-CALLED DOCUMENTS: RFC2078BIS: Regarding rfc2078bis-03, specific edits were agreed, and the resulting document is to be sent to the IESG with a request for advancement to Proposed Standard. The following changes are to be made: addition of a changes section relative to RFC-2078, removal of the CONTEXT_EXPIRED status from gss_import_sec_context(), and inclusion of a conf_req_flag to gss_wrap_size_limit() in order to align with the C bindings. A statement will be added to the citation of GSS_C_NO_NAME within Section 4, underscoring the fact that it is not truly a name type and is applicable as a name reference to only a small and specific set of GSS- API calls. Following discussion, it was agreed without dissent among the set of several participating attendees to state a requirement for full- duplex per-message protection support by mechanisms; given one on-list commentator's request to instead recommend rather than require such support, this working decision as reached at the meeting was considered to constitute rough consensus. WG LAST-CALLED DOCUMENTS: SPNEGO Denis Pinkas (Bull) led discussion on SPNEGO: draft-ietf-cat-snego-08 is the current version of this document. Changes were summarized: the preferredToken element has been changed to mechToken, since it now carries mechanism tokens and not just the initial preferred token, as was originally the case. GSS_S_BAD_SIG, now defined, is used to reflect an incorrect or missing MIC instead of GSS_S_BAD_MECH. Some additional explanations have been added. The document's WG Final-Call had completed quietly, and attendees confirmed group intent to send the document to the IESG with a request for advancement to Proposed Standard. Subsequent to the meeting, the document editor indicated intent to incorporate specific final cleanup edits to the draft, which are to be posted to the list. WG LAST-CALLED DOCUMENTS: IDUP Only limited discussion took place on IDUP at this session, as the document's editor was not available. Re IDUP-10, Denis Pinkas cited one comment which is to be detailed to the list, concerning possible addition of an attribute to represent a user's role. It is planned to initiate a new WG Last-Call on this document within approximately one week after the meeting. PKINIT AND PKCROSS: Brian Tung (ISI) led discussion on Kerberos PKINIT (Public-Key Cryptography for Initial Authentication) and PKCROSS (Public-Key Cryptography for Cross-Realm Authentication). The primary reported changes in pkinit-06 were as follows: a new signature structure definition, aligned with PKCS-1 and discussion in the security considerations section about different trust models and interactions with various levels of cryptographic strength. Reported changes in PKCROSS were minimal, adding commentary about the use of KDC-KDC communications but intending to retain this aspect of the protocol. ISI intends to implement PKINIT by the end of April, subsequently to be incorporated into the MIT Kerberos distribution if accepted by MIT; ISI also plans to release a beta version of PKCROSS (based on PKINIT) sometime after the PKINIT distribution is released. Information is available on http://gost.isi.edu/info/kerberos/, or from Brian at brian@isi.edu. Greg Clark (Dascom)'s comment re PKINIT: suggested changes (as included within a document which he had posted to the list) to use CMS structures as defined by the S/MIME WG in pre-authentication fields. Greg commented that the DCE community has been working to integrate Kerberos clients with messaging-based PKI toolkits (indicating specific interest in the Entrust implementation and its API), and that it is believed that use of a CMS abstraction layer facilitates exportability. Marc Horowitz (Stonecast) reminded attendees of the pre-existing IETF assumption that protocols should not be perturbed specifically for export purposes. Brian Tung believed that a similar question to prospective CMS usage had been visited previously (ca. Munich) when Mike Swift suggested PKCS-7, at which point such an approach was rejected as heavyweight and outside IETF control. Greg observed that CMS is within IETF control, and believed that it should be easy to incorporate CMS structures as optional elements, and that this would simplify or enable support of PKINIT over existing toolkits; Mike Swift observed that PKINIT already provides for optional elements. Matt Hur (CyberSafe) noted that inclusion of CMS elements within the PKINIT specification would imply either that all implementations must support them, or else would impact interoperability. Ari Medvinsky (CyberSafe) commented that PKCS-11 could be accommodated with less significant impact on the PKINIT specification. Mike Swift argued that it would be appropriate to make a general decision as to whether or not to apply PKCS within PKINIT; Brian Tung disagreed, believing that such decisions should be made on a case- by-case, per-object basis. A side discussion involving 6 interested attendees was proposed at the first session and held between the CAT sessions to discuss PKCS/PKINIT objects. Matt Hur reported the results of this discussion at the second session as follows: its proposal is to define and use portions of PKCS7 (excluding, e.g., CRLs) in PKINIT, but not to reference PKCS7 or CMS so as to avoid dependencies on them as they evolve. Other PKINIT-related technical issues as noted from the DC meeting, some of which have not yet been addressed, are follows: a goal that an application server should see the same name for PKINIT and non-PKINIT accessors, a potential patent issue regarding encrypted private key storage on a server, and the intended approach for supporting a user with a signature-only key. Newly identified issues include omission of weak keys, key infrastructure requirements, and designation of algorithm identifiers to indicate PKCS objects. Brian intends to issue a new PKINIT draft addressing these issues. PKCROSS: Mike Swift asserted that if KDC-KDC communication was good for PKCROSS purposes, it would probably also be useful to apply more generally, serving to formalize a general cross-realm approach. It was noted that clients should be aware when shortcuts are applied. Mike also noted that not all ASN.1 toolkits can accommodate use of extensions as specified. An additional PKCROSS-related issues, recorded from the DC meeting, concerned the appropriateness of using a TGT to transport a session key. KERBEROS-REVISIONS: Following further revision, this document is targeted to cycle in grade, obsoleting RFC-1510 at the level of Proposed Standard. The document can be found on the ISI Kerberos web page (http://gost.isi.edu/info/kerberos -> open issues -> Kerberos revisions), which navigates both to working draft and most recent I-D. Cliff Neuman (ISI) sought to get consensus on changes and make changes between the sessions, targeting WG Last-Call thereafter. A new error was added for RESPONSE_TOO_BIG, in recognition that a KDC may now be returning bigger things than had previously been anticipated. The document has a new description of the DES string-to- key algorithm, which may not match some existing implementations. Some more work is needed with 3DES and string-to-key. MIT's implemented 3DES is unofficial, so conformance with it isn't considered an issue. Name canonicalization has been discussed privately, but needs to be raised to the list. Mike Swift had raised issues to the Kerberos list concerning name referrals; these also need to be raised to the CAT list. There had been requests that more preauthentication types be discussed within the basic kerberos-revisions spec; Cliff Neuman believes that this is a good idea. Issue re bitstring encoding, raised by Mike Swift: should ASN-named bits be used, or instead should bits be referenced within a bit vector of specified length? Mike noted that the current specification isn't conformant to ASN.1, and suggested that we should resolve the issue by using a fixed number of bits. It was noted that any existing implementations which truncate the number of bits won't interoperate with MIT's implementation. Cliff proposed that at least 32 bits should always be sent, and that receivers of less than 32 bits should assume zero padding for the missing bits. John Wray (Iris) proposed that, if more than 32 bits are needed, valid ASN.1 should be generated per the originally-specified approach. Matt Hur stated that he would like to be able to checksum sub-elements of ticket extensions (per type) rather than, as at present, just the entire extension; thereby, only a subset would need to be carried intact across intermediaries. Mike Swift asked whether DES-MAC-K could be dropped as the mandatory checksum, in the belief that it is not widely used. A need to clarify relation between key types and encryption types was noted. Cliff Neuman led discussion on the kerberos-revisions draft at the second session: citing the following new url: http://www.kerberos.isi.edu/revisions.html. Various changes were discussed. Implementations must generate at least 32 bits in flag vector, may not generate more unless needed; further interoperability rules were specified and discussed. Mike Swift suggested that ASN-DER be used if more than 32 bits are to be represented, consistent with John Wray's recommendation at the previous session. Revision work is continuing. Name referral discussion is pending, as are string-to-key examples. A new Internet-Draft is to follow, for which Cliff requested informal last-call by interested WG members. FTPDSSAUTH The FTPDSAAUTH draft is at version 3, with only minor editorial changes made since the previous version. It was noted that an additional editorial change appeared to be needed in order to eliminate references to the FTP Security document as an Internet-Draft rather than its current RFC status. The chair stated that, given limited review participation and demonstrated constituency within the WG (on the list, and with two attendees indicating readership of the FTPDSAAUTH draft) and per guidance received from the AD and RFC-2026, that it appeared appropriate to consider seeking Experimental or Informational status for FTPDSAAUTH. It was observed that this course of action is not prejudicial to later standards-track consideration, should enlarged constituency become apparent. The KEA/Skipjack document is intended for Informational status, and no comments or issues were identified on it. FUTURES FOR GSS-API AND CAT-WG: Mike Swift led discussion on some general questions, including: "What's the future of GSS-API?" He observed that many groups think it's too complex or are not using it for other reasons; for WG deliverables to offer value, they should satisfy other groups' needs. Mike also observed that a variety of schemes are being presented and discussed within the CAT-WG, some of which aren't GSS-based, and suggested that the group might appropriately apply more emphasis to the relation between mechanism facilities under discussion and GSS-API. Marc Horowitz noted that some of the schemes under discussion are for initial authentication, which is explicitly outside GSS-API's scope (though, e.g., it is within the scope of the PAM interface); he noted further that a GSS-API explanatory document would be valuable to provide. John Wray concurred with Marc that an informational RFC on how to use GSS would be valuable; someone noted that IBM had presented such a document within another forum. John Linn pointed out that it was necessary to distinguish interface complexity vs. mechanism availability issues, either or both of which could contribute to limited usage, but which would be appropriately addressed through different means. He also noted that potentially GSS- relevant audiences can be subdivided on two dimensions: integrators vs. veneer users vs. encapsulators and those who are vs. are not concerned with mechanism independence. In terms of mechanism availability, Mike Swift suggested that CRAM-MD5 might be a good mechanism, observing that most users want authentication primarily and key exchange as a possible additional option. Ted Ts'o (MIT) recalled that OTP was suggested in the past as a candidate mechanism, but that it would be limited in terms of function. Marc Horowitz argued for trying to train people to want something better than existing password practice, and observed that GSS- API is often more useful in a veneer (ONCRPC, sockets) than for access natively and directly from applications. One attendee stated that his company had built and offered GSS toolkits, but that customers preferred to apply and use SSL. It was noted that SSL is probably the most widely used authentication protocol on the Internet, even though it only provides authentication under certain circumstances and configurations. It was also noted that "GSS isn't part of the picture for IMAP's SASL profiles". Three areas of rationale were stated for interest in SASL vs. GSS-API: simplicity of usage, availability of mechanisms, and scope spanning more broadly into initial authentication facilities; Matt Hur commented, however, a perception that SASL's facilities might be inadequate to satisfy comprehensive needs. The following ideas were suggested, and any WG members interested in undertaking them are invited to propose specific contributions: a tutorial document with sample code, a "how-to" document for protocol integrators (possibly combinable with the first document), and work on provision of a simple mechanism under GSS-API. PKTAPP: Alexander (Sasha) Medvinsky (CyberSafe) led discussion on PKTAPP, reviewing the basis for pktapp and the clarifications added to the most recent revision. PKTAPP's described motivation is to create an authentication solution that combines the advantages of public key and Kerberos, retaining the benefits of Kerberos tickets while avoiding the need to contact on-line authorities. The PKTAPP approach uses PKINIT (based on a certificate, acquiring a TGT or an end service ticket) for direct client-to-server authentication, without modification to the PKINIT protocol. PKTAPP defines the construct of a Local Ticket Granting Service (LTGS), which can either be a standalone server (effectively a scaled-down KDC) serving applications on a host [Q: Is the scope of a standalone LTGS necessarily confined to applications on no more than one host?], or which can be integrated with each application service. When LTGSs are used with PKTAPP for authentication to application services, a central KDC is optional for backward compatibility. An LTGS may, but need not, itself be a Kerberos principal. It was stated that the standalone LTGS approach offers a convenient migration path, and the following attributes were described: client ticket policies can be assigned based on the issuing CA; no LTGS service key is used, but a Kerberos principal entry for the LTGS can still be associated with global restrictions on tickets; the Kerberos principal database must contain application server entries and may also contain client entries shared with the central KDC for backward compatibility. When the LTGS function is implemented within an application server, direct client-to-server authentication is achieved at the cost of application server modification. The following attributes were described for this approach: application servers would not normally share a distributed principal database; ticket policy can be stored in a directory service and accessed via LDAP; for compatibility with traditional Kerberos, supporting non-PKTAPP clients, it is desirable (though not required) for the application server to also be able to accept tickets issued by a central KDC. PKTAPP cross-realm authentication was described as follows: an LTGS can issue end service tickets where the client and server reside in different realms, so no cross-realm TGT is required. Application servers also supporting traditional Kerberos are assigned to realms based on a traditional Kerberos model; application servers supporting only PKTAPP clients rely on a different trust model, based on servers' and clients' certifying authorities. Realms can be associated with CA names. Recognizing the large number of configuration alternatives, Mike Swift asked how clients determine the destination to which AS_REQ requests should be sent. It was noted that the answer depends on configuration; Ted Ts'o observed that this implies a need for coordination facilities not specified within the draft in order to achieve interoperability. Mike Swift asked a further question: Could PKTAPP be framed within GSS- API? This was considered possible, and the prospect could motivate integrating several drafts (pktapp, u2u, iakerb). Ted Ts'o opened the question of how to proceed, observing that PKTAPP could have its interoperability issues resolved, could be merged with other drafts, and that the result could comprise an informational RFC. Further off-line consideration and a proposal to the list is needed. Ted noted further that discussions are underway for Tom Yu of MIT to assume editorial responsibilities for RFC-1964bis, and that this document might also be a candidate for the alignment activity. PK-RECOVERY: Jonathan Trostle (cisco) led discussion on the pk-recovery draft which he had authored. He observed that a Kerberos KDC compromise destroys shared secrets, which are hard to recreate out-of-band. The proposed solution: update KDC root public keys if needed (facilities are proposed so that clients would already have the next KDC root public key to be used), and then recreate shared user secrets by changing salt. The user secret recovery procedure includes a PKINIT-derived exchange. It was further proposed that the protocol be slightly modified in order to also allow user the private key which encrypts secret key to be salted and updated within the protocol. It was noted that the approach assumes that application servers must initiate contact with the KDC, following a KDC solicitation therefor. Jeff Schiller (MIT) noted that MIT's KDC has never been compromised, and that this proposal entails significant complexity in order to accommodate; Cliff Neuman concurred with this observation, and further asserted that any recovery provisions shouldn't complicate the common authentication protocol. John Wray asked, given the fact that PKINIT is needed for this facility to work, why not use PKINIT in preference uniformly? Generally, the attendees appeared hesitant to pursue standardization of a protocol facility in this area; potentially, such functions might be recastable as or within an administrative protocol. Denis Pinkas suggested that the set of attack scenarios be re-evaluated. KERBEROS-CHG-PASSWORDS: Marc Horowitz has received two sets of comments re the kerberos-chg- passwords draft. He will process the comments and then reissue a new draft before WG Last-Call is initiated. 2 implementations exist. Denis Pinkas would like to be able to change a PKINIT private key in a consistent fashion; the question of whether or not to merge such a facility into the chg-passwords document was deferred to offline discussion. John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 9 18:52:03 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27350; Thu, 9 Apr 98 18:52:03 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id RAA14030 for cat-ietf-redist; Thu, 9 Apr 1998 17:44:44 -0400 (EDT) Message-Id: <3.0.3.32.19980409174509.00b065b0@geek.grf.ov.com> X-Sender: prasadj@geek.grf.ov.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 09 Apr 1998 17:45:09 -0400 To: Peter Lindstrom From: Prasad Jonnalagadda Subject: Re: Cc: cat-ietf@MIT.EDU In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk We've subscribed you to the CAT-IETF mailing list. Frank D'Urso Prasad Jonnalagadda List Admins CAT-IETF Veritas Software At 08:15 AM 4/6/98 -0500, Peter Lindstrom wrote: >subscribe lindstp@war.wyeth.com > > From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 10 10:51:17 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA14324; Fri, 10 Apr 98 10:51:17 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA11572 for cat-ietf-redist; Fri, 10 Apr 1998 09:52:38 -0400 (EDT) Message-Id: <352EA2D1.55B4@bull.net> Date: Fri, 10 Apr 1998 15:53:05 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: "Linn, John" Cc: "'CAT-WG List'" Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt References: <6B5344C210C7D011835C0000F801276601211167@exna01.securitydynamics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk > This message is to initiate a CAT WG Last-Call on the most recently > updated version of the IDUP draft, draft-ietf-cat-idup-gss-10.txt, > considering potential submission to the IESG on behalf of the CAT WG > with a request for advancement to Proposed Standard. Any reviewers with > comments pending on this version are hereby requested to indicate them > to the list NLT Friday, 24 April. During the last IETF meting in LA, I proposed an addition to the current text. I was then requested to detail my proposal to the WG. Here it is: In commercial and governmental environments the role or position within the organisation of the sender of a document is a crucial information (e.g., when verifying a document using the IDUP_EV_SingleBuffer_Verify call, we may currently know that Mr. Smith sent it ; it makes a difference if that routine call may also indicate that Mr. Smith is the Sales Director from Delta Corporation. It would therefore be convenient to be able to carry this datum as part of the originator's information. The Originator_Information parameter bundle defined in section 2.3.3.2. of draft-ietf-cat-idup-gss-10.txt (page 25) could be modified in order to include the originator's role, where the role would be defined as : o Originator_Role PARAMETER BUNDLE o domain_name PRINTABLE NAME OPTIONAL, o role PRINTABLE STRING Thus the Originator_Information PARAMETER BUNDLE would become: o Originator_Information PARAMETER BUNDLE o token_generator_name INTERNAL NAME, -- obtained from the credentials of the originator -- (e.g., from its public key certificate) o token_generator_role Originator_role OPTIONAL, -- originator's role in the organisation -- obtained from the credentials of the originator -- (e.g., from attributes in a public key certificate) o protection_time INTEGER OPTIONAL I feel sorry with Carlisle because this will mandate to repaginate the document, but I think that the change is worthwhile. :-( Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Tue Apr 14 13:51:27 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27431; Tue, 14 Apr 98 13:51:27 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA12933 for cat-ietf-redist; Tue, 14 Apr 1998 12:31:59 -0400 (EDT) Date: Tue, 14 Apr 1998 18:33:17 +0200 (EET) From: Tamer Mostafa Abou_Elfadl To: cat-ietf-request@MIT.EDU, cat-ietf@MIT.EDU Subject: Message from a friend of mine Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Dear Sir, This is a message from a friend of mine who have some questions on one of your papers, and he doesn't have an Internet access. So he asked me to send it on his behave. If you please could you answer it through me, and I will give your answer to him. Here is his messsage: ---------------------- Hi sirs; this is Mohamed Soliman a Msc degree student in a faculty of Engineering Cairo university Egypt. in fact i have some questions concerning GSS-API 1- how can-in details- GSS-API interface with kerberos and SPX as an example, how can TGT put into credential structure for the client. 2-what is the value added using GSS-API with kerberos as underlying mechanism over using kerberos alone. 3-in fact there is no source available to me describing the token format can you recommend a source or even can you mention a sumarized describtion for the token. 4-is there a practical product implementing GSS-API using kerberos as an underlying mechanism 5 -i am waiting for a reply taking into account that i read the 3 rfcs of GSS-API , rfc1508.1509,2078. ========== e-mail: cat-ietf-request@mit.edu e-mail:cat-ietf@mit.edu ========== -------------------------------------------------- Tamer Mostafa Abu-elfadl Electrical Engineering Department Faculty of Engineering, Cairo University --------------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 15 06:53:48 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15426; Wed, 15 Apr 98 06:53:48 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id FAA15079 for cat-ietf-redist; Wed, 15 Apr 1998 05:22:43 -0400 (EDT) Message-Id: <199804150922.NAA08622@r1.safe.inkom.ru> From: "Alexander M. Sizov" To: Subject: About Example Header file. Date: Wed, 15 Apr 1998 13:22:02 +0400 X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Precedence: bulk Excuse me for my bad English. If you prefer I will be written by Russian language :-). I read document "Internet Draft S. Klump, Entrust Technologies Ltd. draft-ietf-cat-idup-cbind-03.txt D. Thakkar, Entrust Technologies Ltd. Expires: November 1, 1997 May 1, 1997 Independent Data Unit Protection Generic Security Service Application Program Interface: C-bindings" And I try to use example header file in end of this document and compile it using MS DevStadio 5.00 I propouse you to change definition next structure in Internet Draft on page 133. -------------------------------------------- typedef struct { gss_OID service_id; IDUP_Quality Quality; } IDUP_Service_Creation_Info_desc, *IDUP_Service_Creation_Info, IDUP_Service_Verification_Info_desc, *IDUP_Service_Verification_Info; typedef struct { OM_uint32 qop_algs; OM_uint32 validity; gss_OID policy_id; BOOL allow_policy_mapping; } IDUP_Quality_desc, *IDUP_Quality; -------------------------------- Becouse you using 'IDUP_Quality' before you describe it. I think that next order more convinient for using your example of header C- file. ------------------------------ typedef struct { OM_uint32 qop_algs; OM_uint32 validity; gss_OID policy_id; BOOL allow_policy_mapping; } IDUP_Quality_desc, *IDUP_Quality; typedef struct { gss_OID service_id; IDUP_Quality Quality; } IDUP_Service_Creation_Info_desc, *IDUP_Service_Creation_Info, IDUP_Service_Verification_Info_desc, *IDUP_Service_Verification_Info; Also I have trouble to compile this header file becouse I receive redifinition message on structure IDUP_requested_evidence_type. typedef enum { no_evidence, proof_of_receipt, proof_of_delivery, proof_of_approval, proof_of_retrieval, proof_of_creation, proof_of_sender, proof_of_origin } IDUP_evidence_type; typedef enum { no_evidence, proof_of_receipt, proof_of_delivery, proof_of_approval, proof_of_retrieval, } IDUP_requested_evidence_type; Also I need redefine "IDUP_requested_evidence_type" to "IDUP_evidence_type" in structure definition "IDUP_Request_Features_desc". See later -> typedef struct { /* IDUP_requested_evidence_type requested_evidence_type; */ IDUP_evidence_type requested_evidence_type; gss_OID nr_req_policy; IDUP_Target_Info evidence_from; IDUP_Target_Info evidence_to; int include_received_token_in_evidence; } IDUP_Request_Features_desc, *IDUP_Request_Features; ------------------------- Thank you for advance. -------- Alexander M. Sizov Information Security Division JSB INKOMBANK E-Mail : sizov@inkom.ru Phone: (095) 281-1827, 281-0914 From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 15 11:50:29 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA20594; Wed, 15 Apr 98 11:50:29 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA14344 for cat-ietf-redist; Wed, 15 Apr 1998 10:33:50 -0400 (EDT) Message-Id: <199804151433.KAA00448@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@MIT.EDU From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-snego-09.txt Date: Wed, 15 Apr 1998 10:33:48 -0400 Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The Simple and Protected GSS-API Negotiation Mechanism Author(s) : D. Pinkas, E. Baize Filename : draft-ietf-cat-snego-09.txt Pages : 15 Date : 14-Apr-98 This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms. This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms. Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-snego-09.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-snego-09.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-snego-09.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: <19980414160242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-snego-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-snego-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980414160242.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 16 07:50:31 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA11700; Thu, 16 Apr 98 07:50:31 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id GAA04742 for cat-ietf-redist; Thu, 16 Apr 1998 06:31:27 -0400 (EDT) Message-Id: <35365CA2.D24@bull.net> Date: Thu, 16 Apr 1998 12:31:47 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: CAT-IETF WG Subject: INFOSEC'COM 98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk INFOSEC'COM 98 International Congress on Information Systems and Telecommunications Security 4 - 5 June 1998 - CNIT Paris-La Defense - FRANCE The International Congress on Information Systems and Telecommunications Security presents the state of the art, innovations, prospects and new openings in the fields of information systems and telecommunications security. The information presented is novel and the presentations by the speakers are both diversified and of a high standard. As such, they are mostly intended for specialists in the field (information systems security managers, computer manufacturers, software publishers, consultants, etc). This Congress will take place in Paris (CNIT La Defense) alongside the INFOSEC trade fair (from June 3 to June 5) where the exhibitors will demonstrate their know-how in the area of information systems security products and services. To make things even more attractive, June happens to be the most pleasant period of the year to visit Paris. Thursday June, 4 1998 Opening session General Strategy in terms of information systems security General Jean-Louis DESVIGNES, SCSSI Trusted Third Parties Chairman : Jean-Philippe JOUAS - President of CLUSIF * The use of PKIX profiles to support various application paradigms John HUGHES - ENTEGRITY SOLUTIONS (UK) * Questions raised by key escrow systems Valerie SEDAILLIAN - Attorney (F) * Certificate Authority System and e-comm project Pierre CHASSIGNEUX - GEMPLUS (F) Evaluation Chairman : Michel DUPUY - France Telecom * Smartcard integrated circuit protection profile overview Jean-Paul THOMASSON - SGS-THOMSON Microelectronics (F) * Protection profile for a European certification architecture Jean-Pierre LACOMBE - SETICS (F) * Common criteria Carlos MARTIN - SCSSI Certification Center (F) Networks Chairman : Serge SAGHROUNE - Groupe ACCOR * Secured connection of nomad stations : Dassault Electronique's experience Yves MEYER - DASSAULT ELECTRONIQUE (F) * Tentative classification of digital attacks and Internet incidents Didier GRAS - XP Conseil - LEFEBVRE Consultants (F) * Protection of transfering medical on the Internet : an application of the Montpellier University Hospital Stephane NATKIN - CESIR (F) * Firewalls for ATM Networks Uwe ELLERMANN - HAMBURG UNIVERSITY (D) * Security in electronic commerce Pascal LAGARDE - Industry Minister, Postal Telecommunication - SERICS (F) Friday June 5, 1998 Entreprise Chairman : Andre GRISSONNANCHE - AGC * Information systems security networks in major compagnies : a new function, a new job, career development prospects Rene HANOUZ - CLUSIF (F) * Risk management of contracted activities Gerard REMY - ALCATEL TELECOM (F) * Management of crise situations : both a necessity and an opportunity Andre GRISSONNANCHE - AGC (F) * Security flaws in a Year 2000 project : a case study Pascal LOINTIER - CIGNA (F) * ROUND TABLE : The future of the security market Facilitator : Philippe ROSE - LE MONDE INFORMATIQUE Herve SCHAUER - HSC (F) / Andre GRISSONNANCHE - AGC (F) / Pierre-Luc REFALO - CEGETEL (F) / Jean-Luc JAMAUX - LA FRANCAISE DES JEUX (F) Digital documents Chairman : Benoit TIRARD - SYLAB FRANCE (F) * Document marking legal value * Electronic documents : the guarantee of integrity * Protection of digital works on the web * The sealing functionality : identification and tracking of the works in the market Participants : Nicole TORTELLO, Editions Albin Michel, Representative of the National Union of Publishers (F) - Bruno COUDERC, BJC Consultants, Representative of APROGRED, association of professionals in electronic document management (F) Viruses Chairman : Pascal LOINTIER - CIGNA (F) * Virus writers / Enterprises / Anti-virus software publishers : dangerous liaisons Danielle KAMINSKY - Investigative Journalist (F) * The new technology to replace anti-virus systems Eyal DOTAN - TEGAM International (US) GENERAL INFORMATION Schedules : from 9:00 AM to 6:00 PM Simultaneous translation French / English and English / French Registration Fee: 4.980 French Francs (VAT inc.) For more information, please contact : M.C.I. 19, Rue d'Athenes - 75009 PARIS - FRANCE Tel : +33 1.44.53.72.20 - Fax : +33 1.44.53.72.22 or the CLUSIF by email : clusif@clusif.asso.fr http://www.clusif.asso.fr/ -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 16 11:53:24 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15885; Thu, 16 Apr 98 11:53:24 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA25896 for cat-ietf-redist; Thu, 16 Apr 1998 10:17:52 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F80127660121119D@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" Subject: CAT WG Last-Call: draft-ietf-cat-gssv2-cbind-05 Date: Thu, 16 Apr 1998 10:20:08 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Precedence: bulk CAT/GSSV2 fanciers: Given that we've now agreed the small number of changes to RFC2078bis which will render it sufficient to represent WG consensus for submission to the IESG, I believe that it would be useful if possible to be able to submit the C bindings as well as a combined package, targeting recommendation for a related pair of Proposed Standards. To this end, I'd like to open a WG Last-Call on draft-ietf-cat-gssv2-cbind-05, to extend through Friday, 1 May. Since the C bindings have evolved and become relatively stable over some time, and a significant proportion of the changes made to 2078bis were made for the purpose of alignment with the bindings document, it's my hope that this can be a smooth and straightforward process. Comments or discussion? --jl John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 16 19:50:26 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA24131; Thu, 16 Apr 98 19:50:26 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA12639 for cat-ietf-redist; Thu, 16 Apr 1998 18:15:21 -0400 (EDT) Date: Thu, 16 Apr 1998 18:15:57 -0400 Message-Id: <199804162215.SAA00305@rsts-11.mit.edu> To: jlinn@securitydynamics.com Cc: cat-ietf@MIT.EDU In-Reply-To: <6B5344C210C7D011835C0000F801276601211184@exna01.securitydynamics.com> (jlinn@securitydynamics.com) Subject: Re: Draft minutes for CAT LA meetings From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 References: <6B5344C210C7D011835C0000F801276601211184@exna01.securitydynamics.com> Precedence: bulk From: "Linn, John" Date: Thu, 9 Apr 1998 13:17:11 -0400 more work is needed with 3DES and string-to-key. MIT's implemented 3DES is unofficial, so conformance with it isn't considered an issue. One quick clarification for the minutes: MIT's 3DES code is not enabled in the current releases, and there is a warning in the release note that what was there was a work in progress. In fact, I'm not even sure if the 3DES code in the 1.0 release was in a consistent state to even work if it were enabled. - Ted From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 16 21:44:04 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA26036; Thu, 16 Apr 98 21:44:04 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id UAA26274 for cat-ietf-redist; Thu, 16 Apr 1998 20:41:07 -0400 (EDT) Date: Thu, 16 Apr 1998 20:41:02 -0400 Message-Id: <199804170041.UAA14500@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Tamer Mostafa Abou_Elfadl Cc: cat-ietf@MIT.EDU In-Reply-To: Tamer Mostafa Abou_Elfadl's message of Tue, 14 Apr 1998 18:33:17 +0200 (EET), Subject: Re: Message from a friend of mine Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk Date: Tue, 14 Apr 1998 18:33:17 +0200 (EET) From: Tamer Mostafa Abou_Elfadl This is a message from a friend of mine who have some questions on one of your papers, and he doesn't have an Internet access. So he asked me to send it on his behave. If you please could you answer it through me, and I will give your answer to him. Sure, here you go. 1- how can-in details- GSS-API interface with kerberos and SPX as an example, how can TGT put into credential structure for the client. The GSSAPI does not cover the initial authentication problem --- i.e., how you prompt the user for a password, or SecureID number, or retina scan, etc. in order to establish the initial credentials. The gss_acquire_creds call returns a handle to the credentials, but the question of how the credentials are created are not part of the problem which GSSAPI solves. So in the case of Kerberos, that's done using the Kerberos API's. 2-what is the value added using GSS-API with kerberos as underlying mechanism over using kerberos alone. The advantage is that the GSS-API is a more stable interface, and it's one which is standardized across multiple different authentication systems, not just Kerberos. So if you ever want to port your application to SPX, or some other system, it is much easier if it is written to the GSS-API. 3-in fact there is no source available to me describing the token format can you recommend a source or even can you mention a sumarized describtion for the token. See RFC 1964 for the specification of the Kerberos GSS-API mechanism. 4-is there a practical product implementing GSS-API using kerberos as an underlying mechanism There are quite a few of them. All of the commercial products using Kerberos provide GSSAPI interfaces. Of course there may be export control problems which may prevent some of the commercial vendors from selling their product to the global market, although at least a few of these vendors have obtained export licenses. 5 -i am waiting for a reply taking into account that i read the 3 rfcs of GSS-API , rfc1508.1509,2078. ... but not RFC 1964, I assume. :-) - Ted From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 17 09:47:00 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08618; Fri, 17 Apr 98 09:47:00 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id JAA29320 for cat-ietf-redist; Fri, 17 Apr 1998 09:01:34 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F8012766012111A1@exna01.securitydynamics.com> From: "Linn, John" To: "'IETF Minutes'" Cc: "'CAT-WG List'" Subject: Minutes, CAT-WG LA meetings Date: Fri, 17 Apr 1998 09:03:50 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Minutes for Common Authentication Technology (CAT) WG meeting, Los Angeles IETF, compiled by John Linn (RSA Laboratories). SUMMARY The CAT WG met for 1.5 sessions at the Los Angeles IETF, with a total of 138 attendees. RFC2078bis final editing changes were agreed by the attendees; following corresponding edits, it will be forwarded to the IESG. Agreement among attendees was also reached to recommend SPNEGO for advancement. IDUP was not discussed in detail, but its most recent update is to be placed into WG Last-Call subsequent to the meeting. Revised PKINIT and PKCROSS drafts were discussed; one particular issue concerned alignment potential between PKINIT and S/MIME's CMS, and a proposal was made to replicate a subset of CMS material within PKINIT. A number of issues were discussed with regard to the kerberos-revisions draft, as input to editing during the meeting week; following subsequent WG Last-Call, it is intended that this draft will be targeted to succeed RFC-1510 at the Proposed Standard level. Given limited demonstrated constituency within the WG, it was proposed that FTPDSAAUTH be considered for Experimental or Informational status. Mike Swift (Microsoft) proposed and led an exploratory discussion on potential futures for CAT technologies and group activities. The updated PKTAPP draft was presented; follow-up discussion is to consider whether to target it (with some revisions as discussed) for Informational status or to combine its material with other drafts. The new PKRECOVERY draft was presented; it was observed that such facilities, if required and specified, might be placed more appropriately within a management protocol. A new version of the kerberos-password-chg draft, responsive to recent comments, will be prepared and submitted for WG Last-Call. WG LAST-CALLED DOCUMENTS Discussion began with review and consideration of documents which had been through one or more WG Last-Calls, including 2078bis, spnego, ftpdsaauth, and idup. WG LAST-CALLED DOCUMENTS: RFC2078BIS: Regarding rfc2078bis-03, specific edits were agreed, and the resulting document is to be sent to the IESG with a request for advancement to Proposed Standard. The following changes are to be made: addition of a changes section relative to RFC-2078, removal of the CONTEXT_EXPIRED status from gss_import_sec_context(), and inclusion of a conf_req_flag to gss_wrap_size_limit() in order to align with the C bindings. A statement will be added to the citation of GSS_C_NO_NAME within Section 4, underscoring the fact that it is not truly a name type and is applicable as a name reference to only a small and specific set of GSS-API calls. Following discussion, it was agreed without dissent among the set of several participating attendees to state a requirement for full-duplex per-message protection support by mechanisms; given one on-list commentator's request to instead recommend rather than require such support, this working decision as reached at the meeting was considered to constitute rough consensus. WG LAST-CALLED DOCUMENTS: SPNEGO Denis Pinkas (Bull) led discussion on SPNEGO: draft-ietf-cat-snego-08 is the current version of this document. Changes were summarized: the preferredToken element has been changed to mechToken, since it now carries mechanism tokens and not just the initial preferred token, as was originally the case. GSS_S_BAD_SIG, now defined, is used to reflect an incorrect or missing MIC instead of GSS_S_BAD_MECH. Some additional explanations have been added. The document's WG Final-Call had completed quietly, and attendees confirmed group intent to send the document to the IESG with a request for advancement to Proposed Standard. Subsequent to the meeting, the document editor indicated intent to incorporate specific final cleanup edits to the draft, which are to be posted to the list. WG LAST-CALLED DOCUMENTS: IDUP Only limited discussion took place on IDUP at this session, as the document's editor was not available. Re IDUP-10, Denis Pinkas cited one comment which is to be detailed to the list, concerning possible addition of an attribute to represent a user's role. It is planned to initiate a new WG Last-Call on this document within approximately one week after the meeting. PKINIT AND PKCROSS: Brian Tung (ISI) led discussion on Kerberos PKINIT (Public-Key Cryptography for Initial Authentication) and PKCROSS (Public-Key Cryptography for Cross-Realm Authentication). The primary reported changes in pkinit-06 were as follows: a new signature structure definition, aligned with PKCS-1 and discussion in the security considerations section about different trust models and interactions with various levels of cryptographic strength. Reported changes in PKCROSS were minimal, adding commentary about the use of KDC-KDC communications but intending to retain this aspect of the protocol. ISI intends to implement PKINIT by the end of April, subsequently to be incorporated into the MIT Kerberos distribution if accepted by MIT; ISI also plans to release a beta version of PKCROSS (based on PKINIT) sometime after the PKINIT distribution is released. Information is available on http://gost.isi.edu/info/kerberos/, or from Brian at brian@isi.edu. Greg Clark (Dascom)'s comment re PKINIT: suggested changes (as included within a document which he had posted to the list) to use CMS structures as defined by the S/MIME WG in pre-authentication fields. Greg commented that the DCE community has been working to integrate Kerberos clients with messaging-based PKI toolkits (indicating specific interest in the Entrust implementation and its API), and that it is believed that use of a CMS abstraction layer facilitates exportability. Marc Horowitz (Stonecast) reminded attendees of the pre-existing IETF assumption that protocols should not be perturbed specifically for export purposes. Brian Tung believed that a similar question to prospective CMS usage had been visited previously (ca. Munich) when Mike Swift suggested PKCS-7, at which point such an approach was rejected as heavyweight and outside IETF control. Greg observed that CMS is within IETF control, and believed that it should be easy to incorporate CMS structures as optional elements, and that this would simplify or enable support of PKINIT over existing toolkits; Mike Swift observed that PKINIT already provides for optional elements. Matt Hur (CyberSafe) noted that inclusion of CMS elements within the PKINIT specification would imply either that all implementations must support them, or else would impact interoperability. Ari Medvinsky (CyberSafe) commented that PKCS-11 could be accommodated with less significant impact on the PKINIT specification. Mike Swift argued that it would be appropriate to make a general decision as to whether or not to apply PKCS within PKINIT; Brian Tung disagreed, believing that such decisions should be made on a case-by-case, per-object basis. A side discussion involving 6 interested attendees was proposed at the first session and held between the CAT sessions to discuss PKCS/PKINIT objects. Matt Hur reported the results of this discussion at the second session as follows: its proposal is to define and use portions of PKCS7 (excluding, e.g., CRLs) in PKINIT, but not to reference PKCS7 or CMS so as to avoid dependencies on them as they evolve. Other PKINIT-related technical issues as noted from the DC meeting, some of which have not yet been addressed, are follows: a goal that an application server should see the same name for PKINIT and non-PKINIT accessors, a potential patent issue regarding encrypted private key storage on a server, and the intended approach for supporting a user with a signature-only key. Newly identified issues include omission of weak keys, key infrastructure requirements, and designation of algorithm identifiers to indicate PKCS objects. Brian intends to issue a new PKINIT draft addressing these issues. PKCROSS: Mike Swift asserted that if KDC-KDC communication was good for PKCROSS purposes, it would probably also be useful to apply more generally, serving to formalize a general cross-realm approach. It was noted that clients should be aware when shortcuts are applied. Mike also noted that not all ASN.1 toolkits can accommodate use of extensions as specified. An additional PKCROSS-related issues, recorded from the DC meeting, concerned the appropriateness of using a TGT to transport a session key. KERBEROS-REVISIONS: Following further revision, this document is targeted to cycle in grade, obsoleting RFC-1510 at the level of Proposed Standard. The document can be found on the ISI Kerberos web page (http://gost.isi.edu/info/kerberos -> open issues -> Kerberos revisions), which navigates both to working draft and most recent I-D. Cliff Neuman (ISI) sought to get consensus on changes and make changes between the sessions, targeting WG Last-Call thereafter. A new error was added for RESPONSE_TOO_BIG, in recognition that a KDC may now be returning bigger things than had previously been anticipated. The document has a new description of the DES string-to-key algorithm, which may not match some existing implementations. Some more work is needed with 3DES and string-to-key. MIT's currently-implemented 3DES is unofficial, has not been enabled, and may not be fully functional, so conformance with it isn't considered an issue. Name canonicalization has been discussed privately, but needs to be raised to the list. Mike Swift had raised issues to the Kerberos list concerning name referrals; these also need to be raised to the CAT list. There had been requests that more preauthentication types be discussed within the basic kerberos-revisions spec; Cliff Neuman believes that this is a good idea. Issue re bitstring encoding, raised by Mike Swift: should ASN-named bits be used, or instead should bits be referenced within a bit vector of specified length? Mike noted that the current specification isn't conformant to ASN.1, and suggested that we should resolve the issue by using a fixed number of bits. It was noted that any existing implementations which truncate the number of bits won't interoperate with MIT's implementation. Cliff proposed that at least 32 bits should always be sent, and that receivers of less than 32 bits should assume zero padding for the missing bits. John Wray (Iris) proposed that, if more than 32 bits are needed, valid ASN.1 should be generated per the originally-specified approach. Matt Hur stated that he would like to be able to checksum sub-elements of ticket extensions (per type) rather than, as at present, just the entire extension; thereby, only a subset would need to be carried intact across intermediaries. Mike Swift asked whether DES-MAC-K could be dropped as the mandatory checksum, in the belief that it is not widely used. A need to clarify relation between key types and encryption types was noted. Cliff Neuman led discussion on the kerberos-revisions draft at the second session: citing the following new url: http://www.kerberos.isi.edu/revisions.html. Various changes were discussed. Implementations must generate at least 32 bits in flag vector, may not generate more unless needed; further interoperability rules were specified and discussed. Mike Swift suggested that ASN-DER be used if more than 32 bits are to be represented, consistent with John Wray's recommendation at the previous session. Revision work is continuing. Name referral discussion is pending, as are string-to-key examples. A new Internet-Draft is to follow, for which Cliff requested informal last-call by interested WG members. FTPDSSAUTH The FTPDSAAUTH draft is at version 3, with only minor editorial changes made since the previous version. It was noted that an additional editorial change appeared to be needed in order to eliminate references to the FTP Security document as an Internet-Draft rather than its current RFC status. The chair stated that, given limited review participation and demonstrated constituency within the WG (on the list, and with two attendees indicating readership of the FTPDSAAUTH draft) and per guidance received from the AD and RFC-2026, that it appeared appropriate to consider seeking Experimental or Informational status for FTPDSAAUTH. It was observed that this course of action is not prejudicial to later standards-track consideration, should enlarged constituency become apparent. The KEA/Skipjack document is intended for Informational status, and no comments or issues were identified on it. FUTURES FOR GSS-API AND CAT-WG: Mike Swift led discussion on some general questions, including: "What's the future of GSS-API?" He observed that many groups think it's too complex or are not using it for other reasons; for WG deliverables to offer value, they should satisfy other groups' needs. Mike also observed that a variety of schemes are being presented and discussed within the CAT-WG, some of which aren't GSS-based, and suggested that the group might appropriately apply more emphasis to the relation between mechanism facilities under discussion and GSS-API. Marc Horowitz noted that some of the schemes under discussion are for initial authentication, which is explicitly outside GSS-API's scope (though, e.g., it is within the scope of the PAM interface); he noted further that a GSS-API explanatory document would be valuable to provide. John Wray concurred with Marc that an informational RFC on how to use GSS would be valuable; someone noted that IBM had presented such a document within another forum. John Linn pointed out that it was necessary to distinguish interface complexity vs. mechanism availability issues, either or both of which could contribute to limited usage, but which would be appropriately addressed through different means. He also noted that potentially GSS-relevant audiences can be subdivided on two dimensions: integrators vs. veneer users vs. encapsulators and those who are vs. are not concerned with mechanism independence. In terms of mechanism availability, Mike Swift suggested that CRAM-MD5 might be a good mechanism, observing that most users want authentication primarily and key exchange as a possible additional option. Ted Ts'o (MIT) recalled that OTP was suggested in the past as a candidate mechanism, but that it would be limited in terms of function. Marc Horowitz argued for trying to train people to want something better than existing password practice, and observed that GSS-API is often more useful in a veneer (ONCRPC, sockets) than for access natively and directly from applications. One attendee stated that his company had built and offered GSS toolkits, but that customers preferred to apply and use SSL. It was noted that SSL is probably the most widely used authentication protocol on the Internet, even though it only provides authentication under certain circumstances and configurations. It was also noted that "GSS isn't part of the picture for IMAP's SASL profiles". Three areas of rationale were stated for interest in SASL vs. GSS-API: simplicity of usage, availability of mechanisms, and scope spanning more broadly into initial authentication facilities; Matt Hur commented, however, a perception that SASL's facilities might be inadequate to satisfy comprehensive needs. The following ideas were suggested, and any WG members interested in undertaking them are invited to propose specific contributions: a tutorial document with sample code, a "how-to" document for protocol integrators (possibly combinable with the first document), and work on provision of a simple mechanism under GSS-API. PKTAPP: Alexander (Sasha) Medvinsky (CyberSafe) led discussion on PKTAPP, reviewing the basis for pktapp and the clarifications added to the most recent revision. PKTAPP's described motivation is to create an authentication solution that combines the advantages of public key and Kerberos, retaining the benefits of Kerberos tickets while avoiding the need to contact on-line authorities. The PKTAPP approach uses PKINIT (based on a certificate, acquiring a TGT or an end service ticket) for direct client-to-server authentication, without modification to the PKINIT protocol. PKTAPP defines the construct of a Local Ticket Granting Service (LTGS), which can either be a standalone server (effectively a scaled-down KDC) serving applications on a host [Q: Is the scope of a standalone LTGS necessarily confined to applications on no more than one host?], or which can be integrated with each application service. When LTGSs are used with PKTAPP for authentication to application services, a central KDC is optional for backward compatibility. An LTGS may, but need not, itself be a Kerberos principal. It was stated that the standalone LTGS approach offers a convenient migration path, and the following attributes were described: client ticket policies can be assigned based on the issuing CA; no LTGS service key is used, but a Kerberos principal entry for the LTGS can still be associated with global restrictions on tickets; the Kerberos principal database must contain application server entries and may also contain client entries shared with the central KDC for backward compatibility. When the LTGS function is implemented within an application server, direct client-to-server authentication is achieved at the cost of application server modification. The following attributes were described for this approach: application servers would not normally share a distributed principal database; ticket policy can be stored in a directory service and accessed via LDAP; for compatibility with traditional Kerberos, supporting non-PKTAPP clients, it is desirable (though not required) for the application server to also be able to accept tickets issued by a central KDC. PKTAPP cross-realm authentication was described as follows: an LTGS can issue end service tickets where the client and server reside in different realms, so no cross-realm TGT is required. Application servers also supporting traditional Kerberos are assigned to realms based on a traditional Kerberos model; application servers supporting only PKTAPP clients rely on a different trust model, based on servers' and clients' certifying authorities. Realms can be associated with CA names. Recognizing the large number of configuration alternatives, Mike Swift asked how clients determine the destination to which AS_REQ requests should be sent. It was noted that the answer depends on configuration; Ted Ts'o observed that this implies a need for coordination facilities not specified within the draft in order to achieve interoperability. Mike Swift asked a further question: Could PKTAPP be framed within GSS-API? This was considered possible, and the prospect could motivate integrating several drafts (pktapp, u2u, iakerb). Ted Ts'o opened the question of how to proceed, observing that PKTAPP could have its interoperability issues resolved, could be merged with other drafts, and that the result could comprise an informational RFC. Further off-line consideration and a proposal to the list is needed. Ted noted further that discussions are underway for Tom Yu of MIT to assume editorial responsibilities for RFC-1964bis, and that this document might also be a candidate for the alignment activity. PK-RECOVERY: Jonathan Trostle (cisco) led discussion on the pk-recovery draft which he had authored. He observed that a Kerberos KDC compromise destroys shared secrets, which are hard to recreate out-of-band. The following environmental assumptions were stated: use of a PKINIT environment, with shared secrets still existing due to older clients and the option for storing encrypted user private keys on the KDC. Optimally, the KDC public key is certified in a PKI with revocation capability; the recovery protocol also works if KDC public keys are root keys. The proposed solution: update KDC root public keys if needed (facilities are proposed so that clients can obtain the next KDC root public key to be used), and then recreate shared user secrets by changing salts: Sha1(salt + RFC1510 shared user key) is the new shared key between the user and the KDC. The user secret recovery procedure includes a PKINIT-derived exchange. It was further proposed that the protocol be slightly modified in order to also allow the private key which encrypts secret key to be salted and updated within the protocol. It was noted that the approach assumes that application servers must initiate contact with the KDC, following a KDC solicitation therefor. Jeff Schiller (MIT) noted that MIT's KDC has never been compromised, and that this proposal entails significant complexity in order to accommodate; Cliff Neuman concurred with this observation, and further asserted that any recovery provisions shouldn't complicate the common authentication protocol. John Wray asked, given the fact that PKINIT is needed for this facility to work, why not use PKINIT in preference uniformly? Generally, the attendees appeared hesitant to pursue standardization of a protocol facility in this area; potentially, such functions might be recastable as or within an administrative protocol. Denis Pinkas suggested that the set of attack scenarios be re-evaluated. KERBEROS-CHG-PASSWORDS: Marc Horowitz has received two sets of comments re the kerberos-chg-passwords draft. He will process the comments and then reissue a new draft before WG Last-Call is initiated. 2 implementations exist. Denis Pinkas would like to be able to change a PKINIT private key in a consistent fashion; the question of whether or not to merge such a facility into the chg-passwords document was deferred to offline discussion. John Linn (linn@rsa.com) RSA Laboratories East, Bedford, MA, USA From owner-cat-ietf@pad-thai.cam.ov.com Sat Apr 18 19:46:43 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA13587; Sat, 18 Apr 98 19:46:43 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id SAA23425 for cat-ietf-redist; Sat, 18 Apr 1998 18:25:35 -0400 (EDT) To: bcn@isi.edu Cc: cat-ietf@MIT.EDU Subject: Re: Minutes, CAT-WG LA meetings References: <6B5344C210C7D011835C0000F8012766012111A1@exna01.securitydynamics.com> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 19 Apr 1998 00:25:45 +0200 In-Reply-To: "Linn, John"'s message of "Fri, 17 Apr 1998 09:03:50 -0400" Message-Id: <5l1zuu3gye.fsf@assaris.sics.se> Lines: 28 X-Mailer: Gnus v5.5/Emacs 19.34 Precedence: bulk "Linn, John" writes: > Cliff Neuman led discussion on the kerberos-revisions draft at the second > session: citing the following new url: > http://www.kerberos.isi.edu/revisions.html. Is this URL correct? I'm unable to resolve `www.kerberos.isi.edu'. (Assuming that there's a dot missing in the zone file, the intended host is `cayman-islands.isi.edu', www.kerberos.isi.edu.isi.edu. 43200 CNAME cayman-islands.isi.edu. but that host gives back the following error messages to all my HTTP requests: HTTP/1.0 200 OK Content-type: text/html Requested URL not in table

Requested URL not in table

You have requested a URL for which no mapping is presently defined. ) Where do I find the revised draft? /assar From owner-cat-ietf@pad-thai.cam.ov.com Tue Apr 21 07:31:46 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15347; Tue, 21 Apr 98 07:31:46 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id GAA24665 for cat-ietf-redist; Tue, 21 Apr 1998 06:45:02 -0400 (EDT) Message-Id: <199804211045.GAA19464@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: The IESG Subject: Last Call: The Simple and Protected GSS-API Negotiation Mechanism to Proposed Standard Reply-To: iesg@ietf.org Date: Tue, 21 Apr 1998 06:45:00 -0400 Precedence: bulk The IESG has received a request from the Common Authentication Technology Working Group to consider The Simple and Protected GSS-API Negotiation Mechanism as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 5, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat- snego-09.txt From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 22 03:23:54 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA07528; Wed, 22 Apr 98 03:23:54 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id CAA14346 for cat-ietf-redist; Wed, 22 Apr 1998 02:17:39 -0400 (EDT) To: cat-ietf@MIT.EDU Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.cat-ietf Subject: A thought on 40-bit DES keys Date: Tue, 21 Apr 1998 23:17:22 -0700 Organization: Netscape Communications Corporation Lines: 8 Message-Id: <353D8B71.393DAC25@netscape.com> Nntp-Posting-Host: 198.93.95.181 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) Precedence: bulk A thought occured to me that draft-hoffman-des40 may be useful in an IETF standard. It may be a good idea to revise the Kerberos V5 specification to state that keys conforming to draft-hoffman-des40 MUST NOT be used in the des-* enctypes, just like keys which are "weak" or "semiweak" per the DES specification shall not be used. That way, a host with a policy of using 56 bits will not be fooled into communicating with an implementation with an incompatible policy. From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 22 12:32:45 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA17188; Wed, 22 Apr 98 12:32:45 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id LAA06852 for cat-ietf-redist; Wed, 22 Apr 1998 11:44:10 -0400 (EDT) Date: Wed, 22 Apr 1998 08:43:43 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: A thought on 40-bit DES keys To: cat-ietf@MIT.EDU In-Reply-To: "Your message with ID" <353D8B71.393DAC25@netscape.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Precedence: bulk "John Gardiner Myers" writes: > A thought occured to me that draft-hoffman-des40 may be useful in an IETF > standard. It may be a good idea to revise the Kerberos V5 specification to > state that keys conforming to draft-hoffman-des40 MUST NOT be used in the > des-* enctypes, just like keys which are "weak" or "semiweak" per the DES > specification shall not be used. > > That way, a host with a policy of using 56 bits will not be fooled into > communicating with an implementation with an incompatible policy. 56bit DES is already weak, why spent more cycles perfecting Kerberos V5's use it? I'd rather see energy spent on 3DES for Kerberos V5. -mre From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 22 15:27:59 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA20205; Wed, 22 Apr 98 15:27:59 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id OAA22714 for cat-ietf-redist; Wed, 22 Apr 1998 14:32:07 -0400 (EDT) Message-Id: <353E35EF.12E30469@sectra.se> Date: Wed, 22 Apr 1998 20:24:47 +0200 From: "Johan Otterstrvm" X-Mailer: Mozilla 4.01 [en] (WinNT; I) Mime-Version: 1.0 To: cat-ietf@mit.edu Subject: Bad_Target_Names X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 X-Mime-Autoconverted: from 8bit to quoted-printable by desmond.sectra.se id OAA27403 X-Mime-Autoconverted: from quoted-printable to 8bit by pad-thai.cam.ov.com id OAA22699 Precedence: bulk Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by pad-thai.cam.ov.com id OAA22714 Hello, I have been implementing parts of the IDUP API and I have a few comments/questions about the specification: In chapter 2.3.2.2 the Target_Info parameter bundle is described. The bundle has a set of target names, the number of bad targets and a Bad_Target_Name. Shouldn't this be a set of Bad_Target_Name? The discussion in the following chapter heads in that direction. It might be possible to make the parameter bundle Bad_Target_Name to contain all the bad names but I suppose that each name could have a different status code. In chapter 2.3.2.3 the status code IDUP_S_MORE_OUTBUFFER_NEEDED is valid for all the SE calls, but what is expected if the single operations gets a buffer that is to small? Will the operation fail or should it be possible to call it again to get the rest of the data? I suppose that the first alternative is the better one and thus the no data is returned and the call must be made once more with a larger buffer. Is there any work going on with the c-bindings document? Version 0.3 is not very up to date... Regards /jo -- ---------------------------------------------------------------- Johan Otterstr=F6m Sectra AB Phone +46 13 23 52 46 Teknikringen 2 Telefax +46 13 21 21 85 S-583 30 Link=F6ping Mail mailto:jo@sectra.se SWEDEN WWW http://www.sectra.se ---------------------------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 22 17:27:25 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA22281; Wed, 22 Apr 98 17:27:25 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA04116 for cat-ietf-redist; Wed, 22 Apr 1998 16:32:49 -0400 (EDT) Message-Id: From: Carlisle Adams To: cat-ietf@MIT.EDU, "'Johan Otterstrvm'" Subject: RE: Bad_Target_Names Date: Wed, 22 Apr 1998 16:30:41 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Precedence: bulk Hi Johan, > ---------- > From: Johan Otterstrvm[SMTP:jo@sectra.se] > Sent: Wednesday, April 22, 1998 2:24 PM > To: cat-ietf@mit.edu > Subject: Bad_Target_Names > > Hello, > > I have been implementing parts of the IDUP API and I have a few > comments/questions about the specification: > > In chapter 2.3.2.2 the Target_Info parameter bundle is described. The > bundle has a set of target names, the number of bad targets and a > Bad_Target_Name. Shouldn't this be a set of Bad_Target_Name? The > discussion in the following chapter heads in that direction. It might be > possible to make the parameter bundle Bad_Target_Name to contain all the > bad names but I suppose that each name could have a different status > code. > You're right: it should be "SET OF Bad_Target_Name". Thanks for catching this! [Looks like there will be one last update to this draft after all...] > In chapter 2.3.2.3 the status code IDUP_S_MORE_OUTBUFFER_NEEDED is valid > for all the SE calls, but what is expected if the single operations gets > a buffer that is to small? Will the operation fail or should it be > possible to call it again to get the rest of the data? I suppose that > the first alternative is the better one and thus the no data is returned > and the call must be made once more with a larger buffer. > The wording of the status code description (the table in Section 1.2.1) uses the phrase "remaining data". The intention here is that the operation does not fail, but the caller only gets back whatever data will hold in the (too small) buffer and needs to keep calling (until GSS_S_COMPLETE) to get successive portions of the output data. > Is there any work going on with the c-bindings document? Version 0.3 is > not very up to date... > I am currently unaware of anyone working on the C-bindings document (though I'd love to hear from any volunteers!). -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 23 15:34:14 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15807; Thu, 23 Apr 98 15:34:14 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA03500 for cat-ietf-redist; Thu, 23 Apr 1998 13:59:55 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F8012766012111AE@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" , "Linn, John" Subject: RE: CAT WG Last-Call: draft-ietf-cat-gssv2-cbind-05 Date: Thu, 23 Apr 1998 14:01:37 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Precedence: bulk CAT/GSSV2 fanciers: I've just sent a revised 2078bis I-D to the secretariat, to become draft-ietf-cat-rfc2078bis-04.txt and capturing the agreed final changes in the high-level document for GSS-V2, Update 1. Unless issues are raised to the list regarding draft-ietf-cat-gssv2-cbind-05 within the WG Last-Call period thereon extending through Friday, 1 May, I'll assume that the pair of high-level and bindings documents are ready for submission to the IESG on behalf of the WG thereafter, requesting consideration for advancement to Proposed Standards. --jl > ---------- > From: Linn, John[SMTP:jlinn@securitydynamics.com] > Sent: Thursday, April 16, 1998 10:20 AM > To: 'CAT-WG List' > Subject: CAT WG Last-Call: draft-ietf-cat-gssv2-cbind-05 > > CAT/GSSV2 fanciers: > > Given that we've now agreed the small number of changes to RFC2078bis > which > will render it sufficient to represent WG consensus for submission to the > IESG, I believe that it would be useful if possible to be able to submit > the > C bindings as well as a combined package, targeting recommendation for a > related pair of Proposed Standards. To this end, I'd like to open a WG > Last-Call on draft-ietf-cat-gssv2-cbind-05, to extend through Friday, 1 > May. > Since the C bindings have evolved and become relatively stable over some > time, and a significant proportion of the changes made to 2078bis were > made > for the purpose of alignment with the bindings document, it's my hope that > this can be a smooth and straightforward process. > > Comments or discussion? > > --jl > > > John Linn (linn@rsa.com) > RSA Laboratories East, Bedford, MA, USA > From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 24 02:29:31 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA27220; Fri, 24 Apr 98 02:29:31 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id BAA06251 for cat-ietf-redist; Fri, 24 Apr 1998 01:21:08 -0400 (EDT) From: Bob Blakley To: Cc: Subject: Denis' suggested IDUP change Message-Id: <5040300015348410000002L002*@MHS> Date: Fri, 24 Apr 1998 01:18:57 -0400 Mime-Version: 1.0 Content-Type: text/plain Precedence: bulk Denis Pinkas wrote: >In commercial and governmental environments the role or position >within the organisation of the sender of a document is a crucial >information (e.g., when verifying a document using the >IDUP_EV_SingleBuffer_Verify call, we may currently know that Mr. Smith >sent it ; it makes a difference if that routine call may also >indicate that Mr. Smith is the Sales Director from Delta Corporation. > >It would therefore be convenient to be able to carry this datum as part >of the originator's information. > I think this is a good proposal and should be adopted (though the time is late...), perhaps with two small amendments >The Originator_Information parameter bundle defined in section >2.3.3.2. of draft-ietf-cat-idup-gss-10.txt (page 25) could be modified >in order to include the originator's role, where the role would be >defined as : > >o Originator_Role PARAMETER BUNDLE > o domain_name PRINTABLE NAME OPTIONAL, I don't understand why this is a PRINTABLE NAME while the token generator name is an INTERNAL NAME. It seems more logical to me to use the following declaration instead: o Originator_Role PARAMETER BUNDLE o domain_name INTERNAL NAME OPTIONAL, > o role PRINTABLE STRING The other modification I'd suggest is some text suggesting whether the Originator_Role parameter is authenticated or not; in the example Denis gave it was derived from a certificate extension, which suggests that it is authentic information. I can imagine systems in which it is only asserted by the sender and not authenticated to the receiver. It ought to be made clear in the text whether this parameter, if present, "must" or "may" be authenticated; this will help implementers understand their obligations in supporting this feature. --bob Bob Blakley IBM Lead Security Architect Voice: +1 (512) 838-8133 Fax: +1 (512) 838-0156 Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA Internet: blakley@us.ibm.com From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 24 04:30:50 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA29352; Fri, 24 Apr 98 04:30:50 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id DAA15750 for cat-ietf-redist; Fri, 24 Apr 1998 03:19:41 -0400 (EDT) Message-Id: <35403CF1.B7659E48@bull.net> Date: Fri, 24 Apr 1998 09:19:13 +0200 From: Jacques Lebastard Organization: BULL SA - ISM/AccessMaster X-Mailer: Mozilla 4.03 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: IETF CAT Group Subject: Re: Denis' suggested IDUP change References: <5040300015348410000002L002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Bob Blakley wrote: > > Denis Pinkas wrote: > >o Originator_Role PARAMETER BUNDLE > > o domain_name PRINTABLE NAME OPTIONAL, > > I don't understand why this is a PRINTABLE NAME while the token generator > name is an INTERNAL NAME. It seems more logical to me to use the following > declaration instead: > > o Originator_Role PARAMETER BUNDLE > o domain_name INTERNAL NAME OPTIONAL, The printable name was my initial suggestion to Denis, but on second thought it was clear that the internal name syntax was more appropriate. I also sent a text to Denis to be added to the C binding document (where I used 'gss_name_t' for the domain_name and gss_buffer_t for the role). That text reads as follows : > This also means that draft-ietf-cat-idup-cbind-03.txt should be > aligned to reflect this additional parameter bundle. The following text > should be added to section 2.1.6.3 (page 17) : > > --> Start of additional text > > o Originator_Role > > An Originator_Role parameter bundle keeps information about > the originator's role in his organisation. > > An Originator_Role parameter bundle has the following structure : > > typedef struct { > gss_name_t domain_name; /* GSS_C_NO_NAME if not present */ > gss_buffer_t role_name; > } IDUP_Originator_Role_desc, *IDUP_Originator_Role; > > <-- End of additional text > > The Originator_Information parameter bundle definition should also > be modified to include the above. That parameter bundle should therefore > have the following structure : > > typedef struct { > gss_name_t token_generator_name; > IDUP_Originator_Role token_generator_role; /* NULL if not present */ > time_t protection_time; > } IDUP_Originator_Information_desc, *IDUP_Originator_Information; > > > > It is to be noted that draft-ietf-cat-idup-cbind-03.txt contains > many C code syntax mistakes in parameter bundles definitions (such > as the above IDUP_Originator_Information which misses a few ';')... -- Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net BULL SA - ISM AccessMaster http://www.openmaster.com/ Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86 F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99 From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 24 05:36:52 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00853; Fri, 24 Apr 98 05:36:52 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id EAA22188 for cat-ietf-redist; Fri, 24 Apr 1998 04:39:48 -0400 (EDT) Message-Id: <3540CE62.45DF@bull.net> Date: Fri, 24 Apr 1998 10:39:46 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: Bob Blakley Cc: cat-ietf@MIT.EDU Subject: Re: Denis' suggested IDUP change References: <5040300015348410000002L002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Bob, Thank you for your comment. > >In commercial and governmental environments the role or position > >within the organisation of the sender of a document is a crucial > >information (e.g., when verifying a document using the > >IDUP_EV_SingleBuffer_Verify call, we may currently know that Mr. Smith > >sent it ; it makes a difference if that routine call may also > >indicate that Mr. Smith is the Sales Director from Delta Corporation. > >It would therefore be convenient to be able to carry this datum as part > >of the originator's information. > I think this is a good proposal and should be adopted (though * > the time is late...), perhaps with two small amendments > >The Originator_Information parameter bundle defined in section > >2.3.3.2. of draft-ietf-cat-idup-gss-10.txt (page 25) could be modified > >in order to include the originator's role, where the role would be > >defined as : > >o Originator_Role PARAMETER BUNDLE > > o domain_name PRINTABLE NAME OPTIONAL, > I don't understand why this is a PRINTABLE NAME while the token generator > name is an INTERNAL NAME. It seems more logical to me to use the following > declaration instead: > o Originator_Role PARAMETER BUNDLE > o domain_name INTERNAL NAME OPTIONAL, I agree. > > o role PRINTABLE STRING > The other modification I'd suggest is some text suggesting whether > the Originator_Role parameter is authenticated or not; in the > example Denis gave it was derived from a certificate extension, > which suggests that it is authentic information. I can imagine > systems in which it is only asserted by the sender and not > authenticated to the receiver. It ought to be made clear in the > text whether this parameter, if present, "must" or "may" be > authenticated; this will help implementers understand their > obligations in supporting this feature. I share your concern. However you don't make a proposal :-) I would figure out that some people would like to support either an authenticated role or an asserted role. In practice this would mean to support two optional parameters. This would lead to a structure like this: o Originator_Role PARAMETER BUNDLE o domain_name INTERNAL NAME OPTIONAL, o auth_role PRINTABLE STRING OPTIONAL, o assert_role PRINTABLE STRING OPTIONAL, Would this be O.K. ? Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 24 10:33:20 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05930; Fri, 24 Apr 98 10:33:20 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA22850 for cat-ietf-redist; Fri, 24 Apr 1998 10:02:33 -0400 (EDT) Message-Id: <199804241402.KAA11190@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-04.txt Date: Fri, 24 Apr 1998 10:02:26 -0400 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-04.txt Pages : 100 Date : 23-Apr-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-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: 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-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980423153658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-rfc2078bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-rfc2078bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980423153658.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-cat-ietf@pad-thai.cam.ov.com Fri Apr 24 13:33:44 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA09093; Fri, 24 Apr 98 13:33:44 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA08959 for cat-ietf-redist; Fri, 24 Apr 1998 12:47:44 -0400 (EDT) From: Bob Blakley To: Cc: Subject: Re: Denis' suggested IDUP change Message-Id: <5040300015368525000002L052*@MHS> Date: Fri, 24 Apr 1998 12:44:49 -0400 Mime-Version: 1.0 Content-Type: text/plain Precedence: bulk Denis, Thanks for the quick reply; regarding my second suggestion you wrote: >> The other modification I'd suggest is some text suggesting whether >> the Originator_Role parameter is authenticated or not; in the >> example Denis gave it was derived from a certificate extension, >> which suggests that it is authentic information. I can imagine >> systems in which it is only asserted by the sender and not >> authenticated to the receiver. It ought to be made clear in the >> text whether this parameter, if present, "must" or "may" be >> authenticated; this will help implementers understand their >> obligations in supporting this feature. > >I share your concern. However you don't make a proposal :-) > >I would figure out that some people would like to support either an >authenticated role or an asserted role. In practice this would mean to >support two optional parameters. > >This would lead to a structure like this: > > o Originator_Role PARAMETER BUNDLE > o domain_name INTERNAL NAME OPTIONAL, > o auth_role PRINTABLE STRING OPTIONAL, > o assert_role PRINTABLE STRING OPTIONAL, > >Would this be O.K. ? This would be OK with me, though my personal taste is to use a boolean flag to indicate whether the role name is asserted or authenticated, rather than adding an extra parameter. --bob Bob Blakley IBM Lead Security Architect Voice: +1 (512) 838-8133 Fax: +1 (512) 838-0156 Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA Internet: blakley@us.ibm.com From owner-cat-ietf@pad-thai.cam.ov.com Sat Apr 25 17:30:37 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA08567; Sat, 25 Apr 98 17:30:37 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA13474 for cat-ietf-redist; Sat, 25 Apr 1998 16:14:49 -0400 (EDT) To: cat-ietf@MIT.EDU Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.cat-ietf Subject: Re: A thought on 40-bit DES keys Date: Sat, 25 Apr 1998 13:14:48 -0700 Organization: Netscape Communications Corporation Lines: 14 Message-Id: <35424435.C09EA51C@netscape.com> References: <353D8B71.393DAC25@netscape.com> Nntp-Posting-Host: 198.93.95.101 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) Precedence: bulk Mike Eisler wrote: > > That way, a host with a policy of using 56 bits will not be fooled into > > communicating with an implementation with an incompatible policy. > > 56bit DES is already weak, why spent more cycles perfecting Kerberos V5's use > it? I'd rather see energy spent on 3DES for Kerberos V5. Because DES-CBC-MD5 is the mandatory-to-implement cipher for Kerberos V5. For different Kerberos implementations to interoperate, the mandatory-to-implement cipher must interoperate. In a security context, allowing communication with a peer using security much weaker than policy allows is non-interoperation. If Kerberos V5 were to switch to using 3DES as the mandatory-to-implement cipher, I would agree with you. From owner-cat-ietf@pad-thai.cam.ov.com Tue Apr 28 13:36:29 1998 Received: from [192.231.148.11] by bitsy.MIT.EDU with SMTP id AA19411; Tue, 28 Apr 98 13:36:29 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id MAA28514 for cat-ietf-redist; Tue, 28 Apr 1998 12:06:19 -0400 (EDT) X-Sender: cynthia@mail.surfnetusa.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ARPANET-BBOARDS@MC.LCS.MIT.EDU, sig-dce-security@osf.org, sig-security@osf.org, ids@uow.edu.au, ietf-otp@bellcore.com, ipsec@ans.net, pem-dev@tis.com, virus-l@lehigh.edu, Sneakers@CS.Yale.EDU, cat-ietf@MIT.EDU, cypherpunks-announce@toad.com, www-security@ns2.rutgers.edu, burt@RSA.COM, security@CSCI.ca, ntsecurity@iss.net, cat-ietf@MIT.EDU, ietf@cnri.reston.va.us, ietf-announce@cnri.reston.va.us From: cynthia@usenix.org (Cynthia Deno) Subject: Announcement: Call for Papers - 8th USENIX Security Symposium Date: Tue, 28 Apr 1998 09:09:30 -0700 Precedence: bulk The Program Chair, Win Treese of Open Market, Inc., and the Program Committee announce the availability of the Call for Papers for: 8th USENIX Security Symposium August 23-26, 1999 Marriott Hotel, Washington, D.C. Sponsored by USENIX, the Advanced Computing Systems Association In cooperation with The CERT Coordination Center ================================================ IMPORTANT DATES FOR REFEREED PAPERS Paper submissions due: March 16, 1999 Author notification: April 21, 1999 Camera-ready final papers due: July 12, 1999 ================================================ If you are interested in submitting a paper to the committee, proposing an Invited Talk, or proposing a tutorial, you can find the Call for Papers at http://www.usenix.org/events/sec99/cfp.html. The USENIX Security Symposium brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in security and applications of cryptography. Symposium topics include: Adaptive security and system management Analysis of malicious code Applications of cryptographic techniques Attacks against networks and machines Authentication & authorization of users, systems & applications Detecting attacks, intrusions, and computer misuse Developing secure systems File and file system security Network security New firewall technologies Public key infrastructure Security in heterogeneous environments Security incident investigation and response Security of agents and mobile code Technology for rights management & copyright protection World Wide Web security ============================================================= USENIX is the Advanced Computing Systems Association. Its members are the computer technologists responsible for many of the innovations in computing we enjoy today. To find out more about USENIX, visit its web site: http://www.usenix.org. From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 29 04:36:08 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA05669; Wed, 29 Apr 98 04:36:08 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id DAA22728 for cat-ietf-redist; Wed, 29 Apr 1998 03:37:24 -0400 (EDT) Message-Id: <3546D86D.39C0204B@bull.net> Date: Wed, 29 Apr 1998 09:36:13 +0200 From: Jacques Lebastard Organization: BULL SA - ISM/AccessMaster X-Mailer: Mozilla 4.03 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: IETF CAT Group Subject: DCE 1.2 GSS-API token Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk I have a question regarding the GSS-API token produced by gss_init_sec_context with DCE version 1.2. Scanning the token produced (using an ASN.1 dump), it seems to be conformant to Kerberos RFC 1964 (with a different Mechanism OID) : 0 60 1392: [APPLICATION 0] { 4 06 4: OBJECT IDENTIFIER '1 3 24 9 8' 10 01 0: BOOLEAN TRUE <-- the 2-byte TOK_ID : 01 00 13 80 48: [0] : 80 A0 03 02 01 05 A1 03 02 01 0E A2 07 03 05 00 : 00 00 00 00 A3 80 61 80 30 80 A0 03 02 01 05 A1 : 16 1B 14 64 63 65 74 6F 6D 65 2E 66 72 63 6C 2E 63 62 117: [APPLICATION 2] { 65 6C 108: [APPLICATION 12] { 67 2E 102: Unknown (Reserved) { Error: Object length field 34 too large. My main concern is about the way the DCE 1.2 EPAC is transmitted to the target system. The Kerberos V5 AP-REQ message only includes encrypted information (either in the Ticket or the Authenticator). However, printing the hex. contents of the GSS-API Initial token produced by DCE 1.2, it is obvious that the EPAC is transmitted to the target system in clear (ie. not encrypted), at the end of the token. Would anyone know how the EPAC fits in the GSS-API initial token ? Does a << DCE 1.2 GSS-API Mechanism >> RFC or ID exist ??? Thanks for your help, -- Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net BULL SA - ISM AccessMaster http://www.openmaster.com/ Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86 F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99 From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 29 11:31:45 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA12819; Wed, 29 Apr 98 11:31:45 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA03511 for cat-ietf-redist; Wed, 29 Apr 1998 10:45:34 -0400 (EDT) Date: Wed, 29 Apr 1998 10:41:42 -0400 (EDT) From: Rich Salz Message-Id: <199804291441.KAA00613@fwma.certco.com> To: cat-ietf@MIT.EDU, Jacques.Lebastard@bull.net Subject: Re: DCE 1.2 GSS-API token Precedence: bulk >I have a question regarding the GSS-API token produced by >gss_init_sec_context with DCE version 1.2. John Wray is on this list, and while he's changed jobs, he's probably still the best qualified to answer... But I'll give it a shot. :) >Scanning the token produced (using an ASN.1 dump), it seems to be >conformant to Kerberos RFC 1964 (with a different Mechanism OID) : At one point the DCE/Kerberos GSSAPI was not completely interoperable with the MIT/Kerberos GSSAPI. Fortunately, DCE/Krb used an earlier mech OID, so users wouldn't be caught. It's possible thing were fixed, and someone just forgot to change the OID. PLEASE NOTE: we DCE vendors always considered it a bug/misfeature that we didn't totally interoperate with MIT/Krb, and breathed a sigh of relief when the MIT released a Krb GSSAPI with the official OID that was different. :) > it is obvious that the EPAC is transmitted >to the target system in clear (ie. not encrypted), at the end >of the token. Right. The EPAC checksum is encrypted. The EPAC itself could not be encrypted because it can contain user-specified data, and therefore would not be exportable from the US -- DCE security would then be a general encryption system, not one that just uses encryption for authentication. The DCE EPAC is glued onto the end of the KRB REP packet; I forget the field name, but it's the app-data place. >Would anyone know how the EPAC fits in the GSS-API initial token ? >Does a << DCE 1.2 GSS-API Mechanism >> RFC or ID exist ??? I don't recall an RFC. You can always download the DCE 1.2 release and read the source (http://www.opengroup.org/dce), but that is probably *MUCH* more work than you want to do. :) Hope this helps. /r$ From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 29 14:29:20 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA15873; Wed, 29 Apr 98 14:29:20 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id NAA18719 for cat-ietf-redist; Wed, 29 Apr 1998 13:24:49 -0400 (EDT) From: John_Wray@iris.com X-Lotus-Fromdomain: IRIS To: Jacques Lebastard Cc: cat-ietf@mit.edu, rsalz@certco.com Message-Id: <852565F5.005D0E4D.00@elektra.iris.com> Date: Wed, 29 Apr 1998 13:27:00 -0400 Subject: Re: DCE 1.2 GSS-API token Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Jacques Lebastard wrote: >Rich Salz wrote: >> Right. The EPAC checksum is encrypted. The EPAC itself could not >> be encrypted because it can contain user-specified data, and therefore >> would not be exportable from the US -- DCE security would then be >> a general encryption system, not one that just uses encryption for >> authentication. The DCE EPAC is glued onto the end of the KRB REP >> packet; I forget the field name, but it's the app-data place. > >That's what I don't understand : according to RFC 1964 (Kerberos V5 >GSS-API >Mechanism) : > > The innerContextToken of the initial context token will consist of a > Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id > (TOK_ID) field, which shall contain the value 01 00. > >where KRB_AP_REQ is defined (RFC 1510) as : > > AP-REQ ::= [APPLICATION 14] SEQUENCE { > pvno[0] INTEGER, > msg-type[1] INTEGER, > ap-options[2] APOptions, > ticket[3] Ticket, > authenticator[4] EncryptedData > } > >both ticket and authenticator may contain (multiple) a-data fields ; >however >those fields are encrypted when building the AP-REQ message. >So the EPAC has to be added after the AP-REQ is built. Don't be misled into thinking that the DCE GSSAPI implements the Kerberos GSSAPI spec. Actually, it was more the other way around :-) The DCE GSSAPI was designed and implemented before the Kerberos GSSAPI spec was written, and the DCE protocol was used as the basis for the first draft of the Kerberos GSSAPI spec. DCE has two modes of operation: "regular Kerberos" (which DCE terms "name-based authorization") and "DCE security" (PAC-based). The Kerberos GSSAPI spec (quite reasonably) documents only the protocol used by DCE in its name-based mode. Somewhere in an early ID of the Kerberos GSSAPI spec, the OID that identifies the mechanism within the GSSAPI token was changed (which was actually quite fortunate, as several options were added to the Kerberos GSSAPI spec that weren't in the DCE protocol, so the protocols really are different). In the case you're talking about above, you have an EPAC, so you're definitely not talking about any protocol that regular MIT Kerberos can talk. However, the DCE name-based and PAC-based protocols are quite similar, the only differences being: i) In DCE PAC-based authentication, the client name asserted by the KRB_AP_REQ is the privilege-service of the target cell, and ii) A PAC or EPAC is included in the protocol. Quite how the PAC/EPAC is inserted into the protocol depends on the version of DCE you're using. In DCE R1.0.*, the PAC was carried within the KRB_AP_REQ, in the a-data field. In DCE R1.1 and later, the EPAC is appended to the KRB_AP_REQ, and a hash of the EPAC is placed in the a-data field in the ticket (for reasons that Rich explained above). I think in both cases, the PAC/EPAC is simply pickled. Since you're seeing an unencrypted EPAC, you must be using DCE R1.1 or higher. Obtaining and assembling a Kerberos AP_REQ and PAC/EPAC is something that the lower levels of DCE security do, and the same routines are used by both the DCE GSSAPI implementation and DCE RPC. If you think of a KRB_AP_REQ + PAC/EPAC as being the "DCE-security equivalent" of a regular Kerberos AP_REQ, then you can see how the Kerberos GSSAPI spec should be (loosely) interpreted in the DCE world. John From owner-cat-ietf@pad-thai.cam.ov.com Wed Apr 29 17:27:21 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA18989; Wed, 29 Apr 98 17:27:21 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id QAA05126 for cat-ietf-redist; Wed, 29 Apr 1998 16:15:04 -0400 (EDT) Message-Id: <6B5344C210C7D011835C0000F80127660189243A@exna01.securitydynamics.com> From: "Linn, John" To: "'CAT-WG List'" , "Linn, John" Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Wed, 29 Apr 1998 16:17:15 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Precedence: bulk As I understand the sense of the traffic following this announcement, Carlisle has confirmed the need to make a change in response to Johan's comments about bad_target_name, but the status wrt the proposal originally made by Denis and then endorsed and refined by Bob Blakley isn't so clear. Where do we stand on this? Once these points are resolved, I believe we'll be in a position to submit a successor IDUP draft to the IESG on behalf of the CAT-WG. Discussion, anyone? --jl > ---------- > From: Linn, John[SMTP:jlinn@securitydynamics.com] > Sent: Monday, April 06, 1998 12:26 PM > To: 'CAT-WG List' > Subject: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > This message is to initiate a CAT WG Last-Call on the most recently > updated version of the IDUP draft, draft-ietf-cat-idup-gss-10.txt, > considering potential submission to the IESG on behalf of the CAT WG > with a request for advancement to Proposed Standard. Any reviewers with > comments pending on this version are hereby requested to indicate them > to the list NLT Friday, 24 April. > > Regards, ... > > --jl > > John Linn (linn@rsa.com) > RSA Laboratories East, Bedford, MA, USA > From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 30 04:24:56 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA00316; Thu, 30 Apr 98 04:24:56 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id DAA03914 for cat-ietf-redist; Thu, 30 Apr 1998 03:09:03 -0400 (EDT) Message-Id: <3548A21B.7992@bull.net> Date: Thu, 30 Apr 1998 09:08:59 -0700 From: Denis Pinkas Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: "Linn, John" Cc: "'CAT-WG List'" Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt References: <6B5344C210C7D011835C0000F80127660189243A@exna01.securitydynamics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk John wrote: > As I understand the sense of the traffic following this announcement, > Carlisle has confirmed the need to make a change in response to Johan's > comments about bad_target_name, but the status wrt the proposal originally > made by Denis and then endorsed and refined by Bob Blakley isn't so clear. > Where do we stand on this? Once these points are resolved, I believe we'll > be in a position to submit a successor IDUP draft to the IESG on behalf of > the CAT-WG. > Discussion, anyone? Hearing from Carlisle on this, would be nice . :-) Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 From owner-cat-ietf@pad-thai.cam.ov.com Thu Apr 30 11:32:51 1998 Received: from pad-thai.cam.ov.com by bitsy.MIT.EDU with SMTP id AA07662; Thu, 30 Apr 98 11:32:51 EDT Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.8/8.8.6) id KAA17139 for cat-ietf-redist; Thu, 30 Apr 1998 10:43:24 -0400 (EDT) Message-Id: From: Carlisle Adams To: "Linn, John" , "'Denis.Pinkas@bull.net'" Cc: "'CAT-WG List'" Subject: RE: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt Date: Thu, 30 Apr 1998 10:39:50 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Precedence: bulk Hi Denis, > ---------- > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > Sent: Thursday, April 30, 1998 12:08 PM > To: Linn, John > Cc: 'CAT-WG List' > Subject: Re: CAT WG Last-Call: draft-ietf-cat-idup-gss-10.txt > > John wrote: > > > As I understand the sense of the traffic following this announcement, > > Carlisle has confirmed the need to make a change in response to Johan's > > comments about bad_target_name, but the status wrt the proposal > originally > > made by Denis and then endorsed and refined by Bob Blakley isn't so > clear. > > > Where do we stand on this? Once these points are resolved, I believe > we'll > > be in a position to submit a successor IDUP draft to the IESG on behalf > of > > the CAT-WG. > > > Discussion, anyone? > > Hearing from Carlisle on this, would be nice . :-) > Carlisle (back in the office again) responds as follows: I've seen three things (all small) that, if changed, will make all interested parties happy with the document -- at least that's my sense of the e-mails I've read. 1) Johan's comments about bad_target_name. 2) Denis' (and Bob's) comments about role. [By the way, I agree with Bob and slightly prefer the Boolean; is this O.K. with you Denis?] 3) Graham's comments on IDU length (I have March 25th in my notes here, but I can't remember offhand if that was a private mail or a message to the list. In any case, it echoed one of the items in his original posting to the list). I will fix/add all three and re-issue as soon as possible (i.e., within a few days). Thanks to everyone for the input! -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com --------------------------------------------