From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 3 05:58:37 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28937 for ; Mon, 3 Jan 2000 05:58:36 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id CAA02672 for ietf-cat-wg-out720680; Mon, 3 Jan 2000 02:33:32 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id CAA02659 for ; Mon, 3 Jan 2000 02:33:24 -0800 (PST) Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id LAA17260; Mon, 3 Jan 2000 11:32:58 +0100 Message-ID: <38707AD4.C019BB78@bull.net> Date: Mon, 03 Jan 2000 11:32:52 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: "Linn, John" CC: "'Mike Eisler'" , "'CAT-WG List'" Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit John, Back from holidays today. As you noticed you were the single one raising comments on this document. You also noticed that Mike advertised that he was changing position within his company and that he was not sure anymore to be able to build an implementation of this document. So I would like to raise the following question: since the situation has changed form the Washington meeting, does it still make sense to forward this draft on the Standard Track ? Would'nt it be safer to progress it on Experimental since there is no hint at present time that we will get two independent implementations within a six months time frame, ... maybe not even one ? Regards, Denis > Thanks, Mike, for the timely update. I believe that the new > draft-ietf-cat-lipkey-03.txt responds suitably to the issues identified in > my message, and no other comments against the draft have so far been posted > during the WG Last-Call period ending today. Unless other issues are raised > to the list today, therefore, I'll plan to forward > draft-ietf-cat-lipkey-03.txt to the IESG on behalf of the WG, requesting > that it be considered for advancement to Proposed Standard. > > --jl > > > -----Original Message----- > > From: Mike Eisler [mailto:mre@Eng.Sun.COM] > > Sent: Monday, December 20, 1999 11:59 PM > > To: 'CAT-WG List' > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > > > I've submitted a new i-d (draft-ietf-cat-lipkey-03.txt) with changes > > incorporating John's feedback. As always, > > http://playground.sun.com/~mre/lipkey/ > > archives the latest and previous revisions, with and without > > change bars. > > > > > > > Date: Wed, 15 Dec 1999 11:05:20 -0500 > > > From: "Linn, John" > > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > To: "'CAT-WG List'" > > > > > Sec. 3.2.3.2, 3rd-4th paragraphs: I think there's something > > missing in this > > > aspect of the protocol definition. As described, the > > initiator LIPKEY > > > entity has assembled a token containing the provided user > > name and password > > > (aka the LIPKEY credentials), called SPKM-3 to GSS_Wrap it, > > and has returned > > > GSS_S_CONTINUE_NEEDED along with the GSS_Wrapped token to > > its caller. The > > > 4th paragraph states that "The caller of LIPKEY sends its > > second token to > > > the target, and waits for either a GSS_S_COMPLETE response > > from the target, > > > indicating that the user name and password was accepted, or an error > > > indicating rejection..." I can't find, however, a > > definition of the LIPKEY > > > protocol element which is returned from the target to the > > initiator, which > > > would enable the initiator-side LIPKEY module to advance > > the context out of > > > GSS_S_CONTINUE_NEEDED state and inform its > > GSS_Init_sec_context caller of > > > whether a success or failure case occurred. Absent a > > returned token, how is > > > this status information (corresponding to GSS_S_COMPLETE or > > error returned > > > on the target side) transferred from target to initiator? > > > > I've updated the i-d to define a token that returns relevant > > status information. > > > > > Abstract, 2nd para: "Transport Layer Service" -> "Transport > > Layer Security". > > > > Fixed. > > > > > Sec. 1, 5th para: suggest adding comment (consistent with > > 5.2) that the > > > client does need one minimal infrastructure element: > > knowledge of its > > > trusted CAs and their public keys. > > > > Done. > > > > > Sec. 2.3.1, discussion of C-ALG: "set 128 bits" -> "set to > > 128 bits"; > > > > fixed. > > > > > following paragraph, "mega hertz" -> "megahertz". > > > > fixed. > > > > > > > > Sec. 2.4. title: "Context Establish" -> "Context Establishment". > > > > fixed. > > > > In addition I found and fixed several other editorial errors, > > and also deleted > > one entry from the References section that wasn't being > > refered to (the 3DES > > algorithm OID). And of course, listed John in the > > Acknowledgements section. > > > > I also made two other non-editorial changes: > > > > In the discussion on initiator credential acquisostion, > > noted that > > the interactive prompting for user name and password can be > > defered till GSS_Init_sec_context is called. > > > > Note that the mutual_req_flag parameter to LIPKEY's > > GSS_Init_sec_context > > routine is ignored, and why. I added this after I > > considered what > > effects mutual_req_flag might have on the context token > > exchanges, > > (as it does with Kerberos V5, RFC 1964). > > > > -mre > > > > -mre > > > > ============================================================== > > ============ > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to > > majordomo@lists.stanford.edu > > > ========================================================================== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 3 11:35:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03866 for ; Mon, 3 Jan 2000 11:35:22 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA11324 for ietf-cat-wg-out720680; Mon, 3 Jan 2000 08:10:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA11319 for ; Mon, 3 Jan 2000 08:10:07 -0800 (PST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08838; Mon, 3 Jan 2000 09:10:01 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA23181; Mon, 3 Jan 2000 08:09:59 -0800 (PST) Received: from eng.sun.com (awe171-69.AWE.Sun.COM [192.29.171.69] (may be forged)) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17630; Mon, 3 Jan 2000 08:09:58 -0800 (PST) Message-ID: <3870C98C.A716B7F7@eng.sun.com> Date: Mon, 03 Jan 2000 10:08:44 -0600 From: Spencer Shepler Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: "Linn, John" , "'Mike Eisler'" , "'CAT-WG List'" Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt References: <38707AD4.C019BB78@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Denis and John, The current draft of the NFSv4 protocol specifies the LIPKEY mechanism as mandatory to implement. The NFSv4 WG has held one bakeoff so far with another planned testing event during Connectathon in March of this year. I fully expect that work on LIPKEY implementations will occur as a result of the general NFSv4 efforts. Thanks, Spencer (NFSv4 draft editor) Denis Pinkas wrote: > > John, > > Back from holidays today. > > As you noticed you were the single one raising comments on this > document. You also noticed that Mike advertised that he was changing > position within his company and that he was not sure anymore to be > able to build an implementation of this document. > > So I would like to raise the following question: since the situation > has changed form the Washington meeting, does it still make sense to > forward this draft on the Standard Track ? > > Would'nt it be safer to progress it on Experimental since there is > no hint at present time that we will get two independent > implementations within a six months time frame, ... maybe not even > one ? > > Regards, > > Denis ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 4 08:47:51 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28312 for ; Tue, 4 Jan 2000 08:47:50 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA05342 for ietf-cat-wg-out720680; Tue, 4 Jan 2000 05:22:22 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id FAA05337 for ; Tue, 4 Jan 2000 05:22:18 -0800 (PST) Received: by sentry; id IAA03470; Tue, 4 Jan 2000 08:23:27 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma003465; Tue, 4 Jan 00 08:22:54 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id IAA12045 for ietf-cat-wg@lists.stanford.edu; Tue, 4 Jan 2000 08:21:28 -0500 (EST) Date: Tue, 4 Jan 2000 08:21:28 -0500 (EST) From: "David M. Balenson" Message-Id: <200001041321.IAA12045@clipper.gw.tislabs.com> To: ietf-cat-wg@lists.Stanford.EDU Subject: Jan. 6th early registration deadline for NDSS 2000 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk S A V E $ 7 0 O F F R E G I S T R A T I O N F E E ! ! R E G I S T E R B Y J A N U A R Y 6 , 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 4 10:10:23 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29679 for ; Tue, 4 Jan 2000 10:10:19 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA05527 for ietf-cat-wg-out720680; Tue, 4 Jan 2000 05:43:10 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id FAA05522 for ; Tue, 4 Jan 2000 05:43:07 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 4 Jan 2000 13:40:48 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA16955; Tue, 4 Jan 2000 08:42:13 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 08:44:26 -0500 Message-ID: From: "Linn, John" To: "'Denis Pinkas'" Cc: "'Mike Eisler'" , "'CAT-WG List'" Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt Date: Tue, 4 Jan 2000 08:50:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Denis, all: The WG position for pursuing advancement of LIPKEY on the standards track wasn't new as of Washington, but instead dates back to the Minneapolis meeting. There isn't a procedural requirement for available implementations to progress to the level of Proposed Standard. I believe, therefore, that it's appropriate and consistent for this document to proceed to the IESG requesting Proposed status. --jl > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Monday, January 03, 2000 5:33 AM > To: Linn, John > Cc: 'Mike Eisler'; 'CAT-WG List' > Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > John, > > Back from holidays today. > > As you noticed you were the single one raising comments on this > document. You also noticed that Mike advertised that he was changing > position within his company and that he was not sure anymore to be > able to build an implementation of this document. > > So I would like to raise the following question: since the situation > has changed form the Washington meeting, does it still make sense to > forward this draft on the Standard Track ? > > Would'nt it be safer to progress it on Experimental since there is > no hint at present time that we will get two independent > implementations within a six months time frame, ... maybe not even > one ? > > Regards, > > Denis > > > > Thanks, Mike, for the timely update. I believe that the new > > draft-ietf-cat-lipkey-03.txt responds suitably to the > issues identified in > > my message, and no other comments against the draft have so > far been posted > > during the WG Last-Call period ending today. Unless other > issues are raised > > to the list today, therefore, I'll plan to forward > > draft-ietf-cat-lipkey-03.txt to the IESG on behalf of the > WG, requesting > > that it be considered for advancement to Proposed Standard. > > > > --jl > > > > > -----Original Message----- > > > From: Mike Eisler [mailto:mre@Eng.Sun.COM] > > > Sent: Monday, December 20, 1999 11:59 PM > > > To: 'CAT-WG List' > > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > > > > > > I've submitted a new i-d (draft-ietf-cat-lipkey-03.txt) > with changes > > > incorporating John's feedback. As always, > > > http://playground.sun.com/~mre/lipkey/ > > > archives the latest and previous revisions, with and without > > > change bars. > > > > > > > > > > Date: Wed, 15 Dec 1999 11:05:20 -0500 > > > > From: "Linn, John" > > > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > To: "'CAT-WG List'" > > > > > > > Sec. 3.2.3.2, 3rd-4th paragraphs: I think there's something > > > missing in this > > > > aspect of the protocol definition. As described, the > > > initiator LIPKEY > > > > entity has assembled a token containing the provided user > > > name and password > > > > (aka the LIPKEY credentials), called SPKM-3 to GSS_Wrap it, > > > and has returned > > > > GSS_S_CONTINUE_NEEDED along with the GSS_Wrapped token to > > > its caller. The > > > > 4th paragraph states that "The caller of LIPKEY sends its > > > second token to > > > > the target, and waits for either a GSS_S_COMPLETE response > > > from the target, > > > > indicating that the user name and password was > accepted, or an error > > > > indicating rejection..." I can't find, however, a > > > definition of the LIPKEY > > > > protocol element which is returned from the target to the > > > initiator, which > > > > would enable the initiator-side LIPKEY module to advance > > > the context out of > > > > GSS_S_CONTINUE_NEEDED state and inform its > > > GSS_Init_sec_context caller of > > > > whether a success or failure case occurred. Absent a > > > returned token, how is > > > > this status information (corresponding to GSS_S_COMPLETE or > > > error returned > > > > on the target side) transferred from target to initiator? > > > > > > I've updated the i-d to define a token that returns relevant > > > status information. > > > > > > > Abstract, 2nd para: "Transport Layer Service" -> "Transport > > > Layer Security". > > > > > > Fixed. > > > > > > > Sec. 1, 5th para: suggest adding comment (consistent with > > > 5.2) that the > > > > client does need one minimal infrastructure element: > > > knowledge of its > > > > trusted CAs and their public keys. > > > > > > Done. > > > > > > > Sec. 2.3.1, discussion of C-ALG: "set 128 bits" -> "set to > > > 128 bits"; > > > > > > fixed. > > > > > > > following paragraph, "mega hertz" -> "megahertz". > > > > > > fixed. > > > > > > > > > > > Sec. 2.4. title: "Context Establish" -> "Context Establishment". > > > > > > fixed. > > > > > > In addition I found and fixed several other editorial errors, > > > and also deleted > > > one entry from the References section that wasn't being > > > refered to (the 3DES > > > algorithm OID). And of course, listed John in the > > > Acknowledgements section. > > > > > > I also made two other non-editorial changes: > > > > > > In the discussion on initiator credential acquisostion, > > > noted that > > > the interactive prompting for user name and password can be > > > defered till GSS_Init_sec_context is called. > > > > > > Note that the mutual_req_flag parameter to LIPKEY's > > > GSS_Init_sec_context > > > routine is ignored, and why. I added this after I > > > considered what > > > effects mutual_req_flag might have on the context token > > > exchanges, > > > (as it does with Kerberos V5, RFC 1964). > > > > > > -mre > > > > > > -mre > > > > > > ============================================================== > > > ============ > > > This message was posted through the Stanford campus mailing list > > > server. If you wish to unsubscribe from this mailing > list, send the > > > message body of "unsubscribe ietf-cat-wg" to > > > majordomo@lists.stanford.edu > > > > > > ============================================================== > ============ > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 4 10:22:05 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00050 for ; Tue, 4 Jan 2000 10:22:04 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA05644 for ietf-cat-wg-out720680; Tue, 4 Jan 2000 05:53:42 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id FAA05639 for ; Tue, 4 Jan 2000 05:53:34 -0800 (PST) Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id OAA36804; Tue, 4 Jan 2000 14:53:31 +0100 Message-ID: <3871FB51.391A893D@bull.net> Date: Tue, 04 Jan 2000 14:53:21 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: "Linn, John" CC: "'CAT-WG List'" Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Denis, all: > > The WG position for pursuing advancement of LIPKEY on the standards track > wasn't new as of Washington, but instead dates back to the Minneapolis > meeting. There isn't a procedural requirement for available implementations > to progress to the level of Proposed Standard. I believe, therefore, that > it's appropriate and consistent for this document to proceed to the IESG > requesting Proposed status. As far as I understand the response to my previous mail there is at least one planed implementation. That's fine ! Denis > --jl > > > -----Original Message----- > > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > > Sent: Monday, January 03, 2000 5:33 AM > > To: Linn, John > > Cc: 'Mike Eisler'; 'CAT-WG List' > > Subject: Re: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > > > John, > > > > Back from holidays today. > > > > As you noticed you were the single one raising comments on this > > document. You also noticed that Mike advertised that he was changing > > position within his company and that he was not sure anymore to be > > able to build an implementation of this document. > > > > So I would like to raise the following question: since the situation > > has changed form the Washington meeting, does it still make sense to > > forward this draft on the Standard Track ? > > > > Would'nt it be safer to progress it on Experimental since there is > > no hint at present time that we will get two independent > > implementations within a six months time frame, ... maybe not even > > one ? > > > > Regards, > > > > Denis > > > > > > > Thanks, Mike, for the timely update. I believe that the new > > > draft-ietf-cat-lipkey-03.txt responds suitably to the > > issues identified in > > > my message, and no other comments against the draft have so > > far been posted > > > during the WG Last-Call period ending today. Unless other > > issues are raised > > > to the list today, therefore, I'll plan to forward > > > draft-ietf-cat-lipkey-03.txt to the IESG on behalf of the > > WG, requesting > > > that it be considered for advancement to Proposed Standard. > > > > > > --jl > > > > > > > -----Original Message----- > > > > From: Mike Eisler [mailto:mre@Eng.Sun.COM] > > > > Sent: Monday, December 20, 1999 11:59 PM > > > > To: 'CAT-WG List' > > > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > > > > > > > > > I've submitted a new i-d (draft-ietf-cat-lipkey-03.txt) > > with changes > > > > incorporating John's feedback. As always, > > > > http://playground.sun.com/~mre/lipkey/ > > > > archives the latest and previous revisions, with and without > > > > change bars. > > > > > > > > > > > > > Date: Wed, 15 Dec 1999 11:05:20 -0500 > > > > > From: "Linn, John" > > > > > Subject: RE: WG Last-Call: draft-ietf-cat-lipkey-02.txt > > > > > To: "'CAT-WG List'" > > > > > > > > > Sec. 3.2.3.2, 3rd-4th paragraphs: I think there's something > > > > missing in this > > > > > aspect of the protocol definition. As described, the > > > > initiator LIPKEY > > > > > entity has assembled a token containing the provided user > > > > name and password > > > > > (aka the LIPKEY credentials), called SPKM-3 to GSS_Wrap it, > > > > and has returned > > > > > GSS_S_CONTINUE_NEEDED along with the GSS_Wrapped token to > > > > its caller. The > > > > > 4th paragraph states that "The caller of LIPKEY sends its > > > > second token to > > > > > the target, and waits for either a GSS_S_COMPLETE response > > > > from the target, > > > > > indicating that the user name and password was > > accepted, or an error > > > > > indicating rejection..." I can't find, however, a > > > > definition of the LIPKEY > > > > > protocol element which is returned from the target to the > > > > initiator, which > > > > > would enable the initiator-side LIPKEY module to advance > > > > the context out of > > > > > GSS_S_CONTINUE_NEEDED state and inform its > > > > GSS_Init_sec_context caller of > > > > > whether a success or failure case occurred. Absent a > > > > returned token, how is > > > > > this status information (corresponding to GSS_S_COMPLETE or > > > > error returned > > > > > on the target side) transferred from target to initiator? > > > > > > > > I've updated the i-d to define a token that returns relevant > > > > status information. > > > > > > > > > Abstract, 2nd para: "Transport Layer Service" -> "Transport > > > > Layer Security". > > > > > > > > Fixed. > > > > > > > > > Sec. 1, 5th para: suggest adding comment (consistent with > > > > 5.2) that the > > > > > client does need one minimal infrastructure element: > > > > knowledge of its > > > > > trusted CAs and their public keys. > > > > > > > > Done. > > > > > > > > > Sec. 2.3.1, discussion of C-ALG: "set 128 bits" -> "set to > > > > 128 bits"; > > > > > > > > fixed. > > > > > > > > > following paragraph, "mega hertz" -> "megahertz". > > > > > > > > fixed. > > > > > > > > > > > > > > Sec. 2.4. title: "Context Establish" -> "Context Establishment". > > > > > > > > fixed. > > > > > > > > In addition I found and fixed several other editorial errors, > > > > and also deleted > > > > one entry from the References section that wasn't being > > > > refered to (the 3DES > > > > algorithm OID). And of course, listed John in the > > > > Acknowledgements section. > > > > > > > > I also made two other non-editorial changes: > > > > > > > > In the discussion on initiator credential acquisostion, > > > > noted that > > > > the interactive prompting for user name and password can be > > > > defered till GSS_Init_sec_context is called. > > > > > > > > Note that the mutual_req_flag parameter to LIPKEY's > > > > GSS_Init_sec_context > > > > routine is ignored, and why. I added this after I > > > > considered what > > > > effects mutual_req_flag might have on the context token > > > > exchanges, > > > > (as it does with Kerberos V5, RFC 1964). > > > > > > > > -mre > > > > > > > > -mre > > > > > > > > ============================================================== > > > > ============ > > > > This message was posted through the Stanford campus mailing list > > > > server. If you wish to unsubscribe from this mailing > > list, send the > > > > message body of "unsubscribe ietf-cat-wg" to > > > > majordomo@lists.stanford.edu > > > > > > > > > ============================================================== > > ============ > > > This message was posted through the Stanford campus mailing list > > > server. If you wish to unsubscribe from this mailing list, send the > > > message body of "unsubscribe ietf-cat-wg" to > > majordomo@lists.stanford.edu > > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 4 12:05:17 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02429 for ; Tue, 4 Jan 2000 12:05:16 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA08639 for ietf-cat-wg-out720680; Tue, 4 Jan 2000 08:23:36 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA08634 for ; Tue, 4 Jan 2000 08:23:33 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 4 Jan 2000 16:21:13 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA07069 for ; Tue, 4 Jan 2000 11:22:43 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 11:24:56 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt Date: Tue, 4 Jan 2000 11:31:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT WG: This message is to initiate a CAT-WG Last-Call on draft-ietf-cat-gssv2-javabind-04.txt, "Generic Security Service API Version 2: Java Bindings". I thank the document editors for their submission of this updated version. To support review of this lengthy specification, I propose to open a three week WG Last-Call period, ending 25 January 2000. If anyone wishes to comment on this document with respect to its prospective recommendation to the IESG on behalf of the CAT-WG for advancement to Proposed Standard, please do so within this period. --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jan 7 09:58:53 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19328 for ; Fri, 7 Jan 2000 09:58:53 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA05408 for ietf-cat-wg-out720680; Fri, 7 Jan 2000 06:33:35 -0800 (PST) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id GAA05403 for ; Fri, 7 Jan 2000 06:33:33 -0800 (PST) Received: from odin.ietf.org by MIT.EDU with SMTP id AA08439; Fri, 7 Jan 00 09:34:28 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18706; Fri, 7 Jan 2000 09:33:29 -0500 (EST) Message-Id: <200001071433.JAA18706@ietf.org> To: IETF-Announce:;;;;@cnri.reston.va.us;;; Cc: cat-ietf@mit.edu From: The IESG Subject: Last Call: LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM to Proposed Standard Reply-To: iesg@ietf.org Date: Fri, 07 Jan 2000 09:33:29 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk The IESG has received a request from the Common Authentication Technology Working Group to consider LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM 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 January 20, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-cat-lipkey-03.txt -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jan 7 11:48:20 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22090 for ; Fri, 7 Jan 2000 11:48:19 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA07457 for ietf-cat-wg-out720680; Fri, 7 Jan 2000 08:18:31 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA07446 for ; Fri, 7 Jan 2000 08:18:26 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA14963; Fri, 7 Jan 2000 10:18:25 -0600 (CST) Message-Id: <200001071618.KAA14963@gungnir.fnal.gov> To: ietf-cat-wg@lists.Stanford.EDU Cc: krbdev@mit.edu From: "Matt Crawford" Subject: order of processing for multiple PA-DATA Date: Fri, 07 Jan 2000 10:18:25 -0600 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Is it safe to assume that multiple PA-DATA units (in a KDC-REQ, KDC-REP, or KRB-ERROR message) will be processed in order? The MIT code does so, but both RFC 1510 and (the expired!) draft-ietf-cat-kerberos-revisions-04.txt are very light on specification of preauthentication other than encrypted timestamps. Matt -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sat Jan 8 08:19:28 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18367 for ; Sat, 8 Jan 2000 08:19:26 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id EAA13418 for ietf-cat-wg-out720680; Sat, 8 Jan 2000 04:54:37 -0800 (PST) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id EAA13413 for ; Sat, 8 Jan 2000 04:54:34 -0800 (PST) From: abtecagasa@aol.com Received: from ege.ebso.com.tr by MIT.EDU with SMTP id AA13545; Sat, 8 Jan 00 07:54:12 EST Received: from 212.174.113.124 ([152.201.253.55]) by ege.ebso.com.tr (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C2256860.00476DE0; Thu, 8 Jan 1970 15:00:16 +0200 Date: Sat, 08 Jan 00 05:51:31 EST To: Friend@public.com Subject: A Search Engine Just For You ! Message-Id: <> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This e-mail is to inform you of a new search engine for adult web sites: http://www.adultfairlinks.com. Fairlinks is being built at this time and will be launched in a few months. We are contacting webmasters now so you can take a look at the site and give us any input you may have. This site will be unique since it will be a TRUE SEARCH ENGINE FOR ADULT SITES. There will be no banner ads, no support from any adult site. All categories will rotate so that each site will be at the top. Two thirds of all money collected will then be used to promote Fairlinks. Most advertising will be done off the web with plans already made to market the site on the Internet. We are going to pool thousands of adult sites together to form a partnership that will make a formidable force and to have funds for national advertising. Please take a look, join in and get your site promoted as it should be! http://www.adultfairlinks.com To be removed, call (888) 341-4786 and Clearly spell your email address and you will be removed. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 17 16:29:12 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09125 for ; Mon, 17 Jan 2000 16:29:12 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA09747 for ietf-cat-wg-out720680; Mon, 17 Jan 2000 12:56:52 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA09739 for ; Mon, 17 Jan 2000 12:56:49 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 17 Jan 2000 20:54:16 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA01556 for ; Mon, 17 Jan 2000 15:55:41 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 15:58:10 -0500 Message-ID: From: "Linn, John" To: "Linn, John" , "'CAT-WG List'" Subject: RE: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt Date: Mon, 17 Jan 2000 16:04:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT-WG: Just a reminder that draft-ietf-cat-gssv2-javabind-04.txt is in WG Last Call through 25 January. If anyone wishes to post comments before the document is forwarded to the IESG to be considered for Proposed Standard, please do so within this period. --jl -----Original Message----- From: Linn, John [mailto:jlinn@rsasecurity.com] Sent: Tuesday, January 04, 2000 11:31 AM To: 'CAT-WG List' Subject: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt CAT WG: This message is to initiate a CAT-WG Last-Call on draft-ietf-cat-gssv2-javabind-04.txt, "Generic Security Service API Version 2: Java Bindings". I thank the document editors for their submission of this updated version. To support review of this lengthy specification, I propose to open a three week WG Last-Call period, ending 25 January 2000. If anyone wishes to comment on this document with respect to its prospective recommendation to the IESG on behalf of the CAT-WG for advancement to Proposed Standard, please do so within this period. --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jan 19 07:36:16 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26978 for ; Wed, 19 Jan 2000 07:36:15 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA13899 for ietf-cat-wg-out720680; Wed, 19 Jan 2000 03:57:38 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA13894 for ; Wed, 19 Jan 2000 03:57:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26027; Wed, 19 Jan 2000 06:57:28 -0500 (EST) Message-Id: <200001191157.GAA26027@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-srpgm-02.txt Date: Wed, 19 Jan 2000 06:57:27 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The Secure Remote Password GSS-API Mechanism (SRPGM) Author(s) : K. Burdis Filename : draft-ietf-cat-srpgm-02.txt Pages : 23 Date : 14-Jan-00 This document describes a password-based low-infrastructure GSS-API mechanism based on the Secure Remote Password protocol (SRP) and the existing Simple Public Key Mechanism (SPKM). This mechanism is suitable for establishing a secure context between two entities that have established a shared secret as per the SRP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-srpgm-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-srpgm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-srpgm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000114083922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-srpgm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-srpgm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000114083922.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jan 20 23:51:41 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21812 for ; Thu, 20 Jan 2000 23:51:41 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id UAA01109 for ietf-cat-wg-out720680; Thu, 20 Jan 2000 20:20:40 -0800 (PST) Received: from yem.jsv.qwest.net (yem.jsv.qwest.net [208.44.135.48]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id UAA01095 for ; Thu, 20 Jan 2000 20:20:36 -0800 (PST) Received: from iconnet.net (localhost [127.0.0.1]) by yem.jsv.qwest.net (8.9.3/8.9.3) with ESMTP id UAA06432; Thu, 20 Jan 2000 20:19:31 -0800 (PST) Message-Id: <200001210419.UAA06432@yem.jsv.qwest.net> X-Mailer: exmh version 2.1.0 04/14/1999 To: "Matt Crawford" Cc: ietf-cat-wg@lists.Stanford.EDU, krbdev@mit.edu Subject: Re: order of processing for multiple PA-DATA In-reply-to: crawdad's message of Fri, 07 Jan 2000 10:18:25 -0600. <200001071618.KAA14963@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jan 2000 20:19:31 -0800 From: Frank Cusack Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk It is not safe to assume so. ~f > Is it safe to assume that multiple PA-DATA units (in a > KDC-REQ, KDC-REP, or KRB-ERROR message) will be processed in > order? The MIT code does so, but both RFC 1510 and (the > expired!) draft-ietf-cat-kerberos-revisions-04.txt are very > light on specification of preauthentication other than > encrypted timestamps. > > Matt -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jan 21 01:39:48 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24951 for ; Fri, 21 Jan 2000 01:39:47 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id WAA13602 for ietf-cat-wg-out720680; Thu, 20 Jan 2000 22:10:41 -0800 (PST) Received: from yem.jsv.qwest.net (yem.jsv.qwest.net [208.44.135.48]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id WAA13597 for ; Thu, 20 Jan 2000 22:10:39 -0800 (PST) Received: from iconnet.net (localhost [127.0.0.1]) by yem.jsv.qwest.net (8.9.3/8.9.3) with ESMTP id WAA06713; Thu, 20 Jan 2000 22:09:28 -0800 (PST) Message-Id: <200001210609.WAA06713@yem.jsv.qwest.net> X-Mailer: exmh version 2.1.0 04/14/1999 To: krbdev@mit.edu Cc: ietf-cat-wg@lists.Stanford.EDU Subject: des3 enctypes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Jan 2000 22:09:28 -0800 From: Frank Cusack Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk The kerberos-04 draft lists the following: enctype etype des3-cbc-md5 5 [des3-cbc-raw?] 6 des3-cbc-sha1 7 The MIT krb5.h has a different idea: des3-cbc-md5 does not exist [des3-cbc-raw?] 6 des3-cbc-sha 5 des3-cbc-sha1 16 (0x10) a) Should des3-cbc-sha be eliminated? b) Will the draft change or should the code change. thx ~f -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jan 21 11:32:21 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13318 for ; Fri, 21 Jan 2000 11:32:20 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA11308 for ietf-cat-wg-out720680; Fri, 21 Jan 2000 07:55:54 -0800 (PST) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [130.237.221.147]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA11302 for ; Fri, 21 Jan 2000 07:55:50 -0800 (PST) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 12BgNl-0003eZ-00; Fri, 21 Jan 2000 16:53:53 +0100 To: Frank Cusack Cc: krbdev@mit.edu, ietf-cat-wg@lists.Stanford.EDU Subject: Re: des3 enctypes References: <200001210609.WAA06713@yem.jsv.qwest.net> From: joda@pdc.kth.se (Johan Danielsson) Date: 21 Jan 2000 16:53:53 +0100 In-Reply-To: Frank Cusack's message of "Thu, 20 Jan 2000 22:09:28 -0800" Message-ID: Lines: 4 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Des3-cbc-sha1 (with key-derivation) should be 16. /Johan -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Jan 21 16:04:40 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17323 for ; Fri, 21 Jan 2000 16:04:33 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA01211 for ietf-cat-wg-out720680; Fri, 21 Jan 2000 12:34:24 -0800 (PST) Received: from dmzsmtp01.cybersafe.com (dmzsmtp01.cybersafe.com [192.156.168.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA01200 for ; Fri, 21 Jan 2000 12:34:20 -0800 (PST) Received: (qmail 12808 invoked from network); 21 Jan 2000 20:33:49 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 21 Jan 2000 20:33:49 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Fri, 21 Jan 2000 12:31:07 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jan 2000 12:33:16 -0800 Message-ID: <80A473F584BED311810D0050DA289BD407AE2D@corporate.cybersafe.com> From: Tony Andrea To: Frank Cusack , krbdev@mit.edu Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: des3 enctypes Date: Fri, 21 Jan 2000 12:33:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF644E.BEF125C0" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF644E.BEF125C0 Content-Type: text/plain; charset="iso-8859-1" the draft looks right to me. des3-cbc-md5 should be 5, des3-cbc-sha1 should be 7 and des3-cbc-sha1-kd should be 16. later, tony. -- Tony Andrea | Product Architecture | CyberSafe Corporation 1605 NW Sammamish Road Issaquah, WA 98027 425-391-6000 mailto:tony.andrea@cybersafe.com | http://www.cybersafe.com -----Original Message----- From: Frank Cusack [mailto:fcusack@iconnet.net] Sent: Thursday, January 20, 2000 10:09 PM To: krbdev@mit.edu Cc: ietf-cat-wg@lists.Stanford.EDU Subject: des3 enctypes The kerberos-04 draft lists the following: enctype etype des3-cbc-md5 5 [des3-cbc-raw?] 6 des3-cbc-sha1 7 The MIT krb5.h has a different idea: des3-cbc-md5 does not exist [des3-cbc-raw?] 6 des3-cbc-sha 5 des3-cbc-sha1 16 (0x10) a) Should des3-cbc-sha be eliminated? b) Will the draft change or should the code change. thx ~f -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ------_=_NextPart_001_01BF644E.BEF125C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: des3 enctypes

the draft looks right to me.

des3-cbc-md5 should be 5, des3-cbc-sha1 should be = 7
and des3-cbc-sha1-kd should be 16.

later,
tony.


--

Tony Andrea | Product Architecture | CyberSafe = Corporation
1605 NW Sammamish Road Issaquah, WA 98027 = 425-391-6000
mailto:tony.andrea@cybersafe.c= om | http://www.cybersafe.com



-----Original Message-----
From: Frank Cusack [mailto:fcusack@iconnet.net]
Sent: Thursday, January 20, 2000 10:09 PM
To: krbdev@mit.edu
Cc: ietf-cat-wg@lists.Stanford.EDU
Subject: des3 enctypes


The kerberos-04 draft lists the following:

enctype         = etype

des3-cbc-md5    5
[des3-cbc-raw?] 6
des3-cbc-sha1   7

The MIT krb5.h has a different idea:

des3-cbc-md5    does not exist
[des3-cbc-raw?] 6
des3-cbc-sha    5
des3-cbc-sha1   16 (0x10)

a) Should des3-cbc-sha be eliminated?
b) Will the draft change or should the code = change.

thx
~f
-++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++= **=3D=3D--++**=3D=3D
This message was posted through the Stanford campus = mailing list
server.  If you wish to unsubscribe from this = mailing list, send the
message body of "unsubscribe ietf-cat-wg" = to majordomo@lists.stanford.edu

------_=_NextPart_001_01BF644E.BEF125C0-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 24 03:21:11 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29505 for ; Mon, 24 Jan 2000 03:21:11 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA23111 for ietf-cat-wg-out720680; Sun, 23 Jan 2000 23:52:49 -0800 (PST) Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id XAA23103 for ; Sun, 23 Jan 2000 23:52:45 -0800 (PST) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Sun, 23 Jan 2000 23:45:28 -0800 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE251385B@seine.valicert.com> From: Jack Kabat To: "Linn, John" , "'CAT-WG List'" Subject: RE: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt Date: Sun, 23 Jan 2000 23:45:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Mayank and I have received feedback from several implementers and reviewers regarding the JGSS draft. Based on the feedback, additional text is required when describing the credential and context creation calls. The text needs to specify to supply a lifetime of 0 to obtain the default credential and context lifetime. The effected sections are listed below. A constant within the GSSContext and GSSCredential classes will be added to represent the default lifetime. In addition several typos and code sample mis-prints have been brought to our attention. thanks, jack 6.1.10 createCredential public abstract GSSCredential createCredential (int usage) throws GSSException Here INDEFINITE should be changed to default. 6.1.11. createCredential public abstract GSSCredential createCredential (GSSName aName, int lifetime, Oid mechOid, int usage) throws GSSException Here the description of lifetime parameter will include 0 as a value to obtain default credential lifetime. 6.1.12. createCredential public abstract GSSCredential createCredential(GSSName aName, int lifetime, Oid mechs[], int usage) throws GSSException Same as above. 6.1.13. createContext public abstract GSSContext createContext(GSSName peer, Oid mechOid, GSSCredential myCred, int lifetime) throws GSSException Same as above. 6.3.12. add public void add(GSSName aName, int initLifetime, int acceptLifetime, Oid mech, int usage) throws GSSException The description of initLifetime and acceptLifetime should include the previous clarification. 6.4.26. requestLifetime public void requestLifetime(int lifetime) throws GSSException Here 0 should have the special meaning of default lifetime. > -----Original Message----- > From: Linn, John [mailto:jlinn@rsasecurity.com] > Sent: Monday, January 17, 2000 1:05 PM > To: Linn, John; 'CAT-WG List' > Subject: RE: Initiating WG Last-Call: > draft-ietf-cat-gssv2-javabind-04.txt > > > CAT-WG: > > Just a reminder that draft-ietf-cat-gssv2-javabind-04.txt is > in WG Last Call > through 25 January. If anyone wishes to post comments before > the document > is forwarded to the IESG to be considered for Proposed > Standard, please do > so within this period. > > --jl > > -----Original Message----- > From: Linn, John [mailto:jlinn@rsasecurity.com] > Sent: Tuesday, January 04, 2000 11:31 AM > To: 'CAT-WG List' > Subject: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt > > > CAT WG: > > This message is to initiate a CAT-WG Last-Call on > draft-ietf-cat-gssv2-javabind-04.txt, "Generic Security > Service API Version > 2: Java Bindings". I thank the document editors for their > submission of this > updated version. To support review of this lengthy > specification, I propose > to open a three week WG Last-Call period, ending 25 January > 2000. If anyone > wishes to comment on this document with respect to its prospective > recommendation to the IESG on behalf of the CAT-WG for advancement to > Proposed Standard, please do so within this period. > > --jl > > ============================================================== > ============ > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 24 09:46:59 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08771 for ; Mon, 24 Jan 2000 09:46:58 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA10958 for ietf-cat-wg-out720680; Mon, 24 Jan 2000 06:07:11 -0800 (PST) Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id GAA10953 for ; Mon, 24 Jan 2000 06:07:08 -0800 (PST) From: Mary_Ellen_Zurko@iris.com Subject: NSPW 2000 Call For Papers To: ietf-cat-wg@lists.Stanford.EDU X-Mailer: Lotus Notes Release 5.0.2 November 4, 1999 Message-ID: Date: Mon, 24 Jan 2000 09:07:46 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/24/2000 09:05:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk ======================================================================== Call For Papers New Security Paradigms Workshop 2000 An ACM/SIGSAC sponsored workshop 19 - 21 September 2000 Ballycotton, County Cork, Ireland http://www.nspw.org/ ======================================================================== For eight years, the New Security Paradigms Workshop has provided a productive and highly interactive forum in which innovative new approaches (and some radical older approaches) to computer security have been offered, explored, refined, and published. The workshop offers a constructive environment where experienced researchers and practitioners work alongside newer participants in the field. The result is a unique opportunity to exchange ideas. New Security Paradigms Workshop (NSPW) 2000 will take place September 19 - 21, 2000 at the Bayview Hotel, Ballycotton, a 45 minute drive from the Cork airport. In order to preserve the small, intimate nature of the workshop, participation is limited to authors of accepted papers and conference organizers. Because these are new paradigms, we cannot predict what subjects will be covered. Any paper that presents a significant shift in thinking about difficult security issues or builds on a previous shift will be welcomed. The New Security Paradigms Workshop is highly interactive in nature. Authors are encouraged to present ideas that might be considered risky in some other forum. All participants are charged with providing feedback in a constructive manner. The resulting brainstorming environment has proven to be an excellent medium for furthering the development of these ideas. The proceedings, published after the workshop, have consistently benefited from the inclusion of workshop feedback. To participate, please submit your paper, justification, and attendance statement, preferably via e-mail, to both Program Chairs -- Cristina Serban (cserban@att.com) and Brenda Timmerman (btimmer@ecs.csun.edu) -- by Friday, March 31, 2000 (hardcopy submissions must be received by Friday, March 24, 2000). Further details on the required format of submissions follow. 1 - Your Paper You should submit either a research paper, a 5 - 10 page position paper, or a discussion topic proposal. Submissions of any type must not have been published elsewhere. Discussion topic proposals should include an in-depth description of the topic to be discussed, a convincing argument that the topic will lead to a lively discussion, and any other supporting materials. Softcopy submissions should be in Postscript or ASCII format. Papers may be submitted in hardcopy. To submit hardcopy, please mail 5 (five) copies to Program co-chair Cristina Serban. Please allow adequate time for delivery. 2 - Justification You should describe, in one page or less, why your paper is appropriate for the New Security Paradigms Workshop. A good justification will describe the new paradigm being proposed, explain how it is a departure from existing theory or practice, and identify those aspects of the status quo it challenges or rejects. 3 - Attendance Statement You should state how many authors wish to attend the workshop. Accepted papers require the attendance of at least one author. In order to ensure that all papers receive equally strong feedback, all attendees are expected to stay for the entire duration of the workshop. The program committee will referee the papers and notify the authors of acceptance status by June 9, 2000. We expect to be able to offer a limited number of scholarships. More information will be provided on our web site (http://www.nspw.org/) as it becomes available. Workshop Co-Chairs Mary Ellen Zurko Steven J. Greenwald Iris Associates 2521 NE 135th Street 230 Nashua Rd. North Miami, FL 33181 USA Groton, MA 01450 USA e-mail: sjg6@gate.net e-mail: mzurko@iris.com voice: +1 (305) 944-7842 voice: +1 (978) 392-6018 fax +1 (305) 489-8129 fax: +1 (978) 692-7365 Program Committee Co-Chairs Cristina Serban Brenda Timmerman AT&T Labs California State University 307 Middletown-Lincroft Rd. 18111 Nordhoff St. Lincroft, NJ 07738 USA Northridge, CA 91330-8281 USA e-mail: cserban@att.com e-mail: btimmer@ecs.csun.edu voice: +1 (732) 576-3279 voice: +1 (818) 677-7341 fax: +1 (732) 576-6406 fax: +1 (818) 677-2140 Program Committee Bob Blakley, Tivoli Heather Hinton, Tivoli Erland Jonsson, Chalmers University of Technology Clifford Kahn, EMC Corporation Darrell Kienzle, The MITRE Corporation Jun Li, UCLA Catherine Meadows, Naval Research Laboratory Susan Pancho, University of Cambridge Dean Povey, DSTC Thomas Riechmann, Siemens Marvin Schaefer, ARCA Systems John Michael Williams Local Arrangements Simon Foley (University College, Cork, Ireland) +353 21 902929 Scholarships Hilary Hosmer (Data Security Inc.) +1 (781) 275-8231 John McHugh (SEI/CERT) +1 (412) 268-7737 Publications Marvin Schaefer (ARCA Systems) +1 (410) 309-1780 Publicity Crispin Cowan (WireX Communications, Inc.) +1 (503) 241-6575 ACM-SIGSAC Chair Ravi Sandhu (George Mason University) +1 (703) 993-1659 Steering Committee Bob Blakley, Steven J. Greenwald, Hilary Hosmer, Darrell Kienzle, Catherine Meadows, Cristina Serban, Brenda Timmerman, Mary Ellen Zurko -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jan 24 13:37:19 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18249 for ; Mon, 24 Jan 2000 13:37:16 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA25026 for ietf-cat-wg-out720680; Mon, 24 Jan 2000 10:01:55 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA25010 for ; Mon, 24 Jan 2000 10:01:49 -0800 (PST) Received: by sentry; id NAA27901; Mon, 24 Jan 2000 13:03:04 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma027892; Mon, 24 Jan 00 13:02:18 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id MAA11724 for ietf-cat-wg@lists.stanford.edu; Mon, 24 Jan 2000 12:58:07 -0500 (EST) Date: Mon, 24 Jan 2000 12:58:07 -0500 (EST) From: "David M. Balenson" Message-Id: <200001241758.MAA11724@clipper.gw.tislabs.com> To: ietf-cat-wg@lists.Stanford.EDU Subject: Last chance to register for NDSS 2000 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk L A S T C H A N C E - R E G I S T E R F O R N D S S 2 0 0 0 THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 REGISTER ONLINE ON OR BEFORE WEDNESDAY, JANUARY 26 REGISTER ONSITE AFTER WEDNESDAY, JANUARY 26 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 25 13:39:42 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05930 for ; Tue, 25 Jan 2000 13:39:41 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA05919 for ietf-cat-wg-out720680; Tue, 25 Jan 2000 10:10:39 -0800 (PST) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA05914 for ; Tue, 25 Jan 2000 10:10:36 -0800 (PST) From: hemsath@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA47294 for ; Tue, 25 Jan 2000 12:59:03 -0600 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA72334 for ; Tue, 25 Jan 2000 13:10:34 -0500 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256871.0063D64C ; Tue, 25 Jan 2000 13:10:29 -0500 X-Lotus-FromDomain: IBMUS To: ietf-cat-wg@lists.Stanford.EDU Message-ID: <85256871.0063D463.00@d54mta08.raleigh.ibm.com> Date: Tue, 25 Jan 2000 12:04:25 -0600 Subject: Stronger QoP for GSS-API Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With the recent changes in U.S. Federal Gov't crypto export regulations, is there any interest in the CAT community in extending GSS-API (actually, I think this deals more with specific mechanisms and SPNEGO) to provide stronger QoP that can interoperate between multiple implementations? My own interest is driven by new crypto algorithms showing up in Kerberos (e.g., 3DES from MIT, RC4 from Microsoft). However, as it stands now, the Kerberos Mechanism for GSS-API (RFC 1964) only supports 56-bit DES as the standard confidentiality algorithm used to implement the GSS_Wrap() and GSS_Unwrap() calls. I think I understand the existing RFCs and any active Draft submissions, but as always I'm happy to be informed otherwise. David K. Hemsath, IBM Tivoli Security Business Unit -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQA/AwUBOI3m6wl0soYoviM2EQKA6gCfZnkQul+i6YopSpgnxv6iMGCXpfQAnR7s RHfjb9q1RPC5MWmv2aZn2+mj =+s5r -----END PGP SIGNATURE----- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Jan 25 16:57:57 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08501 for ; Tue, 25 Jan 2000 16:57:56 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA18807 for ietf-cat-wg-out720680; Tue, 25 Jan 2000 13:33:00 -0800 (PST) Received: from dcl.mit.edu (DCL.MIT.EDU [18.172.1.4]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA18802 for ; Tue, 25 Jan 2000 13:32:57 -0800 (PST) Received: (from raeburn@localhost) by dcl.mit.edu (8.9.3) id QAA11075; Tue, 25 Jan 2000 16:32:55 -0500 (EST) To: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Stronger QoP for GSS-API References: <85256871.0063D463.00@d54mta08.raleigh.ibm.com> Mime-Version: 1.0 From: Ken Raeburn Date: 25 Jan 2000 16:32:55 -0500 In-Reply-To: hemsath@us.ibm.com's message of "Tue, 25 Jan 2000 12:04:25 -0600" Message-ID: Lines: 55 User-Agent: Gnus/5.070063 (Pterodactyl Gnus v0.63) Emacs/20.5 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk hemsath@us.ibm.com writes: > My own interest is driven by new crypto algorithms showing up in > Kerberos (e.g., 3DES from MIT, RC4 from Microsoft). However, as it > stands now, the Kerberos Mechanism for GSS-API (RFC 1964) only > supports 56-bit DES as the standard confidentiality algorithm used to > implement the GSS_Wrap() and GSS_Unwrap() calls. I think I understand > the existing RFCs and any active Draft submissions, but as always I'm > happy to be informed otherwise. Well, we could always add more numbers to the tables, but then we have to keep extending the krb5 mechanism spec every time krb5 itself gets a new cryptosystem. I think the first thing to try is to work out whether it's possible to derive more information from the Kerberos messages exchanged. For example, the current SEAL_ALG values defined are ff ff - none 00 00 - DES to which Microsoft adds 01 00 - RC4 and perhaps we could add 00 02 - whatever enctype is indicated for the session key with a suggestion to implementors that they use 00 00 for a DES key. And add some text specifying usage values for key derivation. And replace all descriptions of padding to multiples of 8 bytes with padding to multiples of the cryptosystem block size (which in the DES case would be 8, so no incompatibility there). IIRC there's at least one case where padding is done as 1 to 8 bytes; that just needs some careful wording to indicate the next multiple of the block size that's *higher* than the existing field size. And, thanks to the MICROS~1 scheme, the sequence number byte order is dependent on the cryptosystem type. *sigh* Some of it would be tricky, but I think it would be possible to extend RFC1964 in a way fully backwards compatible with the original RFC, and not totally ugly. I'd been thinking of working out the details and writing up something along these lines in my Copious Free Time[TM], but haven't gotten around to it yet. (Though it'll probably become a priority very soon.) However, all of this does ignore the possible desire to have SPNEGO compare the actual cryptosystems that the available mechanisms would use.... Ken -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jan 26 09:25:43 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04671 for ; Wed, 26 Jan 2000 09:25:42 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA17403 for ietf-cat-wg-out720680; Wed, 26 Jan 2000 05:51:34 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id FAA17398 for ; Wed, 26 Jan 2000 05:51:31 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 26 Jan 2000 13:48:50 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA03391 for ; Wed, 26 Jan 2000 08:50:12 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 08:52:50 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: GSS-V2, Update 1 high-level and C bindings RFCs issued Date: Wed, 26 Jan 2000 08:59:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT-WG: For the benefit of any CAT-WG subscribers who don't also receive the general IETF list and RFC announcements: the pair of GSS-V2, Update 1 and associated C bindings specifications have just been issued as Proposed Standard RFCs 2743 and 2744 respectively. RFC-2743 obsoletes RFC-2078, and RFC-2744 obsoletes RFC-1509. The new RFCs are available on ftp://ftp.isi.edu/in-notes/rfc2743.txt and ftp://ftp.isi.edu/in-notes/rfc2744.txt. --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu