From owner-ietf-cat-wg@lists.Stanford.EDU Tue Feb 1 20:36:13 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 UAA11940 for ; Tue, 1 Feb 2000 20:36:10 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA12303 for ietf-cat-wg-out720680; Tue, 1 Feb 2000 17:02:17 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id RAA12292 for ; Tue, 1 Feb 2000 17:02:13 -0800 (PST) Received: from deimos ([13.0.209.39]) by alpha.xerox.com with SMTP id <71613(3)>; Tue, 1 Feb 2000 16:58:47 PST From: "Mike Spreitzer" To: , Cc: "Jeffrey I. Schiller" , "Marcus Leech" , "Allison Mankin" , "Mike Spreitzer" Subject: GSSish TLS? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Date: Tue, 1 Feb 2000 16:58:47 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I find the stream-filtering nature of TLS useful beyond the confines of the security enhancements TLS is currently defined to provide. I could ask for more out of TLS, but why duplicate work? We already have an IETF standard framework for security enhancements, namely the GSS-API. It seems natural to want to create a TLS-like stream filter that transports the tokens that the GSS is defined to produce/consume. This could even be done in a way that keeps parts of the existing TLS --- just define two new message types to carry the tokens from the two phases (setup, then data) of GSS exchange. I know there was some discussion of something like this early in the history of the TLS WG. Perhaps the situation is different now; perhaps I'm not asking for exacly the same thing. I'm not implying which, if any, existing WG this would fall to. But I am asking for the benefit of your wisdom. Does this make sense? If so, where should the effort be homed? Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Feb 1 23:37: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 XAA16181 for ; Tue, 1 Feb 2000 23:37:55 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id UAA23457 for ietf-cat-wg-out720680; Tue, 1 Feb 2000 20:08:49 -0800 (PST) Received: from dns2.anl.gov (dns2.anl.gov [146.139.254.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id UAA23452 for ; Tue, 1 Feb 2000 20:08:47 -0800 (PST) Received: from anl.gov (pembroke.ctd.anl.gov [146.137.180.163]) by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id WAA07580; Tue, 1 Feb 2000 22:08:35 -0600 (CST) Message-ID: <3897ADE1.DB5758@anl.gov> Date: Tue, 01 Feb 2000 22:09:05 -0600 From: "Douglas E. Engert" Reply-To: deengert@anl.gov Organization: Argonne National Laborotory X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Spreitzer CC: ietf-cat-wg@lists.Stanford.EDU, ietf-tls@consensus.com, "Jeffrey I. Schiller" , Marcus Leech , Allison Mankin , Frank Siebenlist , Mark Davis Subject: Re: GSSish TLS? 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 This was discussed at the last IETF in both the TLS and CAT working groups. Frank Siebenlist discussed a GSSAPI using SSL/TLS at the CAT group. Mark Davis discussed delegation with TLS at the TLS meeting. As pointed out in the above two sessions, the Globus project, http://www.globus.org/security has implemented a GSSAPI using SSL and the SSLeay package. GSI supports GSS delegation using "proxy" certificates as well as user-to-user authentication. Works with smartcards via PKCS#11. Runs on WIN32, and most UNIX platforms. Can use the MIT gssftp. We have mods to ssh to use GSSAPI as an authentication method, which are included in SecureCRT. If you are interested, see me at the ISOC NDSS this week. Mike Spreitzer wrote: > > I find the stream-filtering nature of TLS useful beyond the confines of the security enhancements TLS is currently defined to > provide. I could ask for more out of TLS, but why duplicate work? We already have an IETF standard framework for security > enhancements, namely the GSS-API. It seems natural to want to create a TLS-like stream filter that transports the tokens that the > GSS is defined to produce/consume. This could even be done in a way that keeps parts of the existing TLS --- just define two new > message types to carry the tokens from the two phases (setup, then data) of GSS exchange. > > I know there was some discussion of something like this early in the history of the TLS WG. Perhaps the situation is different now; > perhaps I'm not asking for exacly the same thing. I'm not implying which, if any, existing WG this would fall to. But I am asking > for the benefit of your wisdom. > > Does this make sense? If so, where should the effort be homed? > > Thanks, > Mike > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 2 03:00:09 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00632 for ; Wed, 2 Feb 2000 03:00:06 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id XAA02313 for ietf-cat-wg-out720680; Tue, 1 Feb 2000 23:25:05 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id XAA02308 for ; Tue, 1 Feb 2000 23:25:03 -0800 (PST) Received: from deimos ([13.0.209.39]) by alpha.xerox.com with SMTP id <71912(1)>; Tue, 1 Feb 2000 23:24:58 PST From: "Mike Spreitzer" To: "IETF CAT fanciers" Cc: "Mike Spreitzer" Subject: Looking for Java GSS implementations Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Date: Tue, 1 Feb 2000 23:24:56 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I'm looking for pure Java implementations of the GSS-API. I'm most interested in the Kerberos v5 mechanism. I'd prefer something that's free for commercial use, but might settle for worse terms. Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Feb 2 15:26:07 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 PAA20460 for ; Wed, 2 Feb 2000 15:26:06 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA01521 for ietf-cat-wg-out720680; Wed, 2 Feb 2000 11:55:06 -0800 (PST) Received: from mail.rdc1.sfba.home.com (imail@ha1.rdc1.sfba.home.com [24.0.0.66]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA01501 for ; Wed, 2 Feb 2000 11:55:00 -0800 (PST) Received: from dascom.com ([24.12.52.50]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000202195459.KVND12979.mail.rdc1.sfba.home.com@dascom.com>; Wed, 2 Feb 2000 11:54:59 -0800 Message-ID: <3898886F.1A0A0160@dascom.com> Date: Wed, 02 Feb 2000 11:41:35 -0800 From: Frank Siebenlist Organization: DASCOM, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Spreitzer CC: ietf-cat-wg@lists.Stanford.EDU, ietf-tls@consensus.com, "Jeffrey I. Schiller" , Marcus Leech , Allison Mankin , Paul Leach Subject: Re: GSSish TLS? 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 Mike, At the last IETF meeting, Paul Leach from Microsoft told the meeting that the latest Windows 2000 already has a gssapi equivalent for a ssl/tls mechanism. Paul also claimed that documentation would be available that describes the implementation. So far, we haven't been able to find any, though. I've send Paul an email to request for more info but never got any response. Maybe Paul is willing to share with the list where we could find detailed information about MS' gss-ssl mechanism? Regards, Frank. Mike Spreitzer wrote: > > I find the stream-filtering nature of TLS useful beyond the confines of the security enhancements TLS is currently defined to > provide. I could ask for more out of TLS, but why duplicate work? We already have an IETF standard framework for security > enhancements, namely the GSS-API. It seems natural to want to create a TLS-like stream filter that transports the tokens that the > GSS is defined to produce/consume. This could even be done in a way that keeps parts of the existing TLS --- just define two new > message types to carry the tokens from the two phases (setup, then data) of GSS exchange. > > I know there was some discussion of something like this early in the history of the TLS WG. Perhaps the situation is different now; > perhaps I'm not asking for exacly the same thing. I'm not implying which, if any, existing WG this would fall to. But I am asking > for the benefit of your wisdom. > > Does this make sense? If so, where should the effort be homed? > > Thanks, > Mike > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -- Frank Siebenlist Tivoli SecureWay Security Geek Supreme 3004 Mission Street Email: fs@us.ibm.com Santa Cruz, CA 95060, USA Phone: +1 408/871-8072 +1 831/460-3600 (switch) Fax: +1 831/460-0255 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Feb 2 17:03:29 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 RAA22683 for ; Wed, 2 Feb 2000 17:03:27 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA07267 for ietf-cat-wg-out720680; Wed, 2 Feb 2000 13:35:48 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA07262 for ; Wed, 2 Feb 2000 13:35:46 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Feb 2000 12:47:50 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <1BSJF91S>; Wed, 2 Feb 2000 12:47:49 -0800 Message-ID: <19398D273324D3118A2B0008C7E9A569051BEDE3@SIT.platinum.corp.microsoft.com> From: Paul Leach To: "'Frank Siebenlist'" , Mike Spreitzer Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-tls@consensus.com, "Jeffrey I. Schiller" , Marcus Leech , Allison Mankin Subject: RE: GSSish TLS? Date: Wed, 2 Feb 2000 12:45:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk SSPI doc is at http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/psdk/secspi/port alsspi_1545.htm Under the subtopic "Using SSPI" is specific info about SSL and SSPI. > -----Original Message----- > From: Frank Siebenlist [mailto:frank@dascom.com] > Sent: Wednesday, February 02, 2000 11:42 AM > To: Mike Spreitzer > Cc: ietf-cat-wg@lists.Stanford.EDU; ietf-tls@consensus.com; Jeffrey I. > Schiller; Marcus Leech; Allison Mankin; Paul Leach > Subject: Re: GSSish TLS? > > > Mike, > > At the last IETF meeting, Paul Leach from Microsoft told the > meeting that the latest Windows 2000 already has a gssapi > equivalent for a ssl/tls mechanism. > > Paul also claimed that documentation would be available that > describes the implementation. So far, we haven't been able to > find any, though. I've send Paul an email to request for more > info but never got any response. > > Maybe Paul is willing to share with the list where we could > find detailed information about MS' gss-ssl mechanism? > > Regards, Frank. > > > Mike Spreitzer wrote: > > > > I find the stream-filtering nature of TLS useful beyond the > confines of the security enhancements TLS is currently defined to > > provide. I could ask for more out of TLS, but why > duplicate work? We already have an IETF standard framework > for security > > enhancements, namely the GSS-API. It seems natural to want > to create a TLS-like stream filter that transports the tokens that the > > GSS is defined to produce/consume. This could even be done > in a way that keeps parts of the existing TLS --- just define two new > > message types to carry the tokens from the two phases > (setup, then data) of GSS exchange. > > > > I know there was some discussion of something like this > early in the history of the TLS WG. Perhaps the situation is > different now; > > perhaps I'm not asking for exacly the same thing. I'm not > implying which, if any, existing WG this would fall to. But > I am asking > > for the benefit of your wisdom. > > > > Does this make sense? If so, where should the effort be homed? > > > > Thanks, > > Mike > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > > -- > Frank Siebenlist Tivoli SecureWay > Security Geek Supreme 3004 Mission Street > Email: fs@us.ibm.com Santa Cruz, CA 95060, USA > Phone: +1 408/871-8072 +1 831/460-3600 (switch) > Fax: +1 831/460-0255 > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 3 03:36: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 DAA12302 for ; Thu, 3 Feb 2000 03:36:23 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id AAA13195 for ietf-cat-wg-out720680; Thu, 3 Feb 2000 00:08:57 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id AAA13184 for ; Thu, 3 Feb 2000 00:08:54 -0800 (PST) Received: from deimos ([13.0.209.39]) by alpha.xerox.com with SMTP id <72038(2)>; Thu, 3 Feb 2000 00:08:48 PST From: "Mike Spreitzer" To: "IETF TLS WG" , "IETF CAT fanciers" Cc: "Jeffrey I. Schiller" , "Marcus Leech" , "Allison Mankin" , "Mike Spreitzer" Subject: GSS in (something like) TLS? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Date: Thu, 3 Feb 2000 00:08:47 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit [Trying again, as my first message was bounced from the TLS list and misunderstood on the CAT list.] It seems natural to me for someone who's using the GSS-API to want a stream filter protocol similar to TLS to transport the tokens that the GSS-API is defined to produce and consume. If I've decided to use the GSS-API as my framework for selecting and engaging security mechanisms, I don't need another one in TLS (indeed, relating the two frameworks would involve breaking the abstraction that is central to the GSS-API). What I need is to add what's missing to make a complete protocol. Something like the record protocol of TLS plus a few GSS-oriented message types (one to carry GSS setup tokens, another to carry GSS data tokens, perhaps one for GSS shutdown tokens, perhaps a few more for context switching and/or alerts). Creating a GSS mechanism that does TLS misses the point; the point is to make a stream filter that can use the full spectrum of GSS mechanisms now and later defined, managed and extended in the way that they are through the GSS. Does this sound to you like something that should be produced (and if so, where)? Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Feb 3 05:32:44 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 FAA12871 for ; Thu, 3 Feb 2000 05:32:43 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id CAA18560 for ietf-cat-wg-out720680; Thu, 3 Feb 2000 02:02:17 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id CAA18555 for ; Thu, 3 Feb 2000 02:02:15 -0800 (PST) Received: from taller.eng.sun.com ([129.144.123.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21998; Thu, 3 Feb 2000 01:15:27 -0800 (PST) Received: from ghar (awe195-2.AWE.Sun.COM [192.29.195.2]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id BAA04543; Thu, 3 Feb 2000 01:15:24 -0800 (PST) Message-Id: <200002030915.BAA04543@taller.eng.sun.com> Date: Thu, 3 Feb 2000 01:15:46 -0800 (PST) From: Mayank Upadhyay Reply-To: Mayank Upadhyay Subject: Re: GSS in (something like) TLS? To: ietf-tls@consensus.com, ietf-cat-wg@lists.Stanford.EDU, spreitze@parc.xerox.com Cc: jis@mit.edu, mleech@nortelnetworks.com, mankin@east.isi.edu, spreitze@parc.xerox.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LrkgHd1TXr5MOnHcdwnFFQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_25 SunOS 5.8 sun4u sparc Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >From: "Mike Spreitzer" >Subject: GSS in (something like) TLS? > >It seems natural to me for someone who's using the GSS-API to want a stream filter protocol similar to TLS to transport the tokens >that the GSS-API is defined to produce and consume. ... ... >Does this sound to you like something that should be produced (and if so, where)? > This sounds like a good idea. I'm interested in this from the point of view of a Java developer who would like a streams based API that can hide the details of the GSS-API from me. As a different issue, I would also like to have one API that can provide me with support for both GSS mechanisms and TLS cipher suites. It appears that there are two different ways to achieve both goals together: (1) Support GSS mechanisms under TLS as new cipher suites and use the streams based API's that TLS implementations generally provide. We would need to define new message types to carry the different GSS tokens at different stages of the the TLS protocol as Mike suggested, and also make some exceptions in the TLS protocol for the GSS cipher suites. This would allow existing applications that use TLS to continue to work seamlessly when switched to a GSS based cipher suite. Moreover, the TLS handshake negotiation mechanism could be used to negotiate not just among existing TLS cipher suites but also among any GSS mechanism based suites. This does not preclude SPNego from being used as yet another GSS based cipher suite. Note that applications that could use a GSS based cipher suite for TLS will be unable to interoperate with peers that use pure GSS but might be able to negotiate successfully with peers that use only TLS 1.0 cipher suites. (2) Define a streams based abstraction that utilizes the GSS-API to wrap/unwrap data as the application writes to or reads from the IO streams. To solve the other problem of TLS support, define a TLS like mechanism for the GSS-API, as suggested by Frank. This mechanism might have to reach into the guts of a TLS implementation and utilize just the underlying layers there. Note that applications that use this TLS like mechanism under GSS will be unable to interoperate with peers that use just TLS; however, with the help of SPNego, they might interop with peers that use existing GSS mechanisms. Leaving the question of "GSS under TLS" or "TLS under GSS" aside, there is another issue to note when considering stream filters for GSS. The GSS-API is well tailored for message based applications that might wish to protect different messages differently. For instance, one might be merely integrity protected while another might be encrypted, and yet another might use a different key strength (QOP) for either one of these operations. These options are requested via arguments to the gss_wrap() call. On the other hand, when we impose a streams based abstraction on the GSS-API there will be one InputStream (e.g., in Java) and one OutputStream that the application will use. The application will then be stuck with "integrity only always" or "integrity and privacy always", and with the same QOP. These limitations seem inherent to a stream based API but for the added convenience of streams, many programmers might be willing to live with this limitation. To answer one other question that Mike asked, if we undertake to provide a solution as outlined in (1) the work might be more appropriate for the TLS working group. However, if we were to undertake a solution as outlined in (2) then the part of it which includes the addition of stream based API for GSS definitely seems more appropriate for the CAT WG. Regards, Mayank -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 3 16:47:22 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00237 for ; Thu, 3 Feb 2000 16:47:15 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA10145 for ietf-cat-wg-out720680; Thu, 3 Feb 2000 12:59:19 -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 MAA09970 for ; Thu, 3 Feb 2000 12:58:32 -0800 (PST) Received: (qmail 26452 invoked from network); 3 Feb 2000 19:57:58 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 3 Feb 2000 19:57:58 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Thu, 03 Feb 2000 11:55:07 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id <1GD83LP8>; Thu, 3 Feb 2000 11:57:38 -0800 Message-ID: <80A473F584BED311810D0050DA289BD40F3D86@corporate.cybersafe.com> From: Matt Hur To: "'Mayank Upadhyay'" , ietf-tls@consensus.com, ietf-cat-wg@lists.Stanford.EDU, spreitze@parc.xerox.com Cc: jis@mit.edu, mleech@nortelnetworks.com, mankin@east.isi.edu Subject: RE: GSS in (something like) TLS? Date: Thu, 3 Feb 2000 11:57:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6E80.EB97CF30" 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_01BF6E80.EB97CF30 Content-Type: text/plain; charset="iso-8859-1" Per your point #1: RFC 2712 specififes the use of Kerberos tickets as the authentication mechanism in TLS. Below is a loose specification for a simple way to do the same with a krb5 GSS mech (which has been implemented). I have not submitted this as an IETF draft. -- Matt Hur =================================== RFC 2712 specifies that a Kerberos ticket is used in the ClientKeyExchange message. For our purposes, we are using GSS tokens (the result of calls to init_sec_context/gss_wrap). Constructing the Client Key Exchange Message: In RFC2712, the example KerberosWrapper structure is as follows: struct { select (KeyExchangeAlgorithm) { case krb5: KerberosWrapper; /* new addition */ case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; } Exchange_keys; } ClientKeyExchange; struct { opaque Ticket; opaque authenticator; /* optional */ opaque EncryptedPreMasterSecret; /* encrypted with the session key which is sealed in the ticket */ } KerberosWrapper; /* new addition */ For our purposes, we changed this as follows: struct { select (KeyExchangeAlgorithm) { case krb5: KerberosWrapper; case gss_krb5; GssKrb5Wrapper; case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; } Exchange_keys; } ClientKeyExchange; struct { opaque InitialContextToken; /* token from call to init_sec_context */ opaque InitialContextToken; /* token from call to gss_wrap which contains */ opaque EncryptedPreMasterSecret; /* the EncryptedPreMasterSecret which is */ /* encrypted with the session key sealed */ /* in the ticket */ } GssKbr5Wrapper; (InitialContextToken is defined in RFC1964) In GSS, context establishment may take a few trips (looping over an init/accept call). For our purposes (1st effort), we are assuming that we do not need to do this. If we cannot make this fly on first pass, then we have an error condition. > -----Original Message----- > From: Mayank Upadhyay [mailto:Mayank.Upadhyay@Eng.Sun.COM] > Sent: Thursday, February 03, 2000 1:16 AM > To: ietf-tls@consensus.com; ietf-cat-wg@lists.Stanford.EDU; > spreitze@parc.xerox.com > Cc: jis@mit.edu; mleech@nortelnetworks.com; mankin@east.isi.edu; > spreitze@parc.xerox.com > Subject: Re: GSS in (something like) TLS? > > > >From: "Mike Spreitzer" > >Subject: GSS in (something like) TLS? > > > >It seems natural to me for someone who's using the GSS-API to want a > stream filter protocol similar to TLS to transport the tokens > >that the GSS-API is defined to produce and consume. > ... > ... > >Does this sound to you like something that should be > produced (and if > so, where)? > > > > > This sounds like a good idea. I'm interested in this from the point > of view of a Java developer who would like a streams based API that > can hide the details of the GSS-API from me. > > As a different issue, I would also like to have one API that can > provide me with support for both GSS mechanisms and TLS cipher > suites. > > It appears that there are two different ways to achieve both goals > together: > > (1) Support GSS mechanisms under TLS as new cipher suites and use the > streams based API's that TLS implementations generally provide. We > would need to define new message types to carry the different GSS > tokens at different stages of the the TLS protocol as Mike suggested, > and also make some exceptions in the TLS protocol for the GSS cipher > suites. > > This would allow existing applications that use TLS to continue to > work seamlessly when switched to a GSS based cipher suite. Moreover, > the TLS handshake negotiation mechanism could be used to negotiate not > just among existing TLS cipher suites but also among any GSS mechanism > based suites. This does not preclude SPNego from being used as yet > another GSS based cipher suite. > > Note that applications that could use a GSS based cipher > suite for TLS > will be unable to interoperate with peers that use pure GSS but might > be able to negotiate successfully with peers that use only TLS 1.0 > cipher suites. > > (2) Define a streams based abstraction that utilizes the > GSS-API to wrap/unwrap data as the application writes to or > reads from > the IO streams. To solve the other problem of TLS support, define a > TLS like mechanism for the GSS-API, as suggested by Frank. This > mechanism might have to reach into the guts of a TLS implementation > and utilize just the underlying layers there. > > Note that applications that use this TLS like mechanism under GSS will > be unable to interoperate with peers that use just TLS; however, with > the help of SPNego, they might interop with peers that use existing > GSS mechanisms. > > Leaving the question of "GSS under TLS" or "TLS under GSS" aside, > there is another issue to note when considering stream filters for > GSS. The GSS-API is well tailored for message based applications that > might wish to protect different messages differently. For instance, > one might be merely integrity protected while another might be > encrypted, and yet another might use a different key strength (QOP) > for either one of these operations. These options are requested via > arguments to the gss_wrap() call. On the other hand, when we impose a > streams based abstraction on the GSS-API there will be one InputStream > (e.g., in Java) and one OutputStream that the application will use. > The application will then be stuck with "integrity only always" or > "integrity and privacy always", and with the same QOP. These > limitations seem inherent to a stream based API but for the added > convenience of streams, many programmers might be willing to live with > this limitation. > > To answer one other question that Mike asked, if we undertake to > provide a solution as outlined in (1) the work might be more > appropriate for the TLS working group. However, if we were to > undertake a solution as outlined in (2) then the part of it which > includes the addition of stream based API for GSS definitely seems > more appropriate for the CAT WG. > > Regards, > Mayank > > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > 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_01BF6E80.EB97CF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GSS in (something like) TLS?

Per your point #1:
RFC 2712 specififes the use of Kerberos tickets as = the authentication mechanism in TLS.
Below is a loose specification for a simple way to = do the same with a krb5 GSS mech (which has been implemented).  I = have not submitted this as an IETF draft.


-- Matt Hur


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


RFC 2712 specifies that a Kerberos ticket is used in = the ClientKeyExchange message.  For our purposes, we are using GSS = tokens (the result of calls to init_sec_context/gss_wrap).

Constructing the Client Key Exchange Message:

In RFC2712, the example KerberosWrapper structure is = as follows:
 struct
 {
     select = (KeyExchangeAlgorithm)
     {
         = case = krb5:            = KerberosWrapper;       /* new addition = */
         = case = rsa:           &n= bsp; EncryptedPreMasterSecret;
         = case diffie_hellman:  ClientDiffieHellmanPublic;
     } Exchange_keys;

 } ClientKeyExchange;

 struct
 {
     opaque Ticket;
     opaque = authenticator;         &nbs= p;  /* optional */
     opaque = EncryptedPreMasterSecret; /* encrypted with the session key
          &nb= sp;           &nb= sp;           &nb= sp;      which is sealed in the ticket = */
 } = KerberosWrapper;         &n= bsp;         /* new addition = */


For our purposes, we changed this as follows:
 struct
 {
     select = (KeyExchangeAlgorithm)
     {
         = case = krb5:            = KerberosWrapper;
         = case gss_krb5;        = GssKrb5Wrapper;
         = case = rsa:           &n= bsp; EncryptedPreMasterSecret;
         = case diffie_hellman:  ClientDiffieHellmanPublic;
     } Exchange_keys;

 } ClientKeyExchange;

 struct
 {
     opaque = InitialContextToken;      /* token from call = to init_sec_context */
     opaque = InitialContextToken;      /* token from call = to gss_wrap which contains */
     opaque = EncryptedPreMasterSecret; /* the EncryptedPreMasterSecret which is = */
          &nb= sp;           &nb= sp;           &nb= sp;   /* encrypted with the session key sealed */
          &nb= sp;           &nb= sp;           &nb= sp;   /* in the ticket */
 } GssKbr5Wrapper;
(InitialContextToken is defined in RFC1964)

In GSS, context establishment may take a few trips = (looping over an init/accept call).  For our purposes (1st = effort), we are assuming that we do not need to do this.  If we = cannot make this fly on first pass, then we have an error = condition.





> -----Original Message-----
> From: Mayank Upadhyay [mailto:Mayank.Upadhyay@Eng.S= un.COM]
> Sent: Thursday, February 03, 2000 1:16 = AM
> To: ietf-tls@consensus.com; = ietf-cat-wg@lists.Stanford.EDU;
> spreitze@parc.xerox.com
> Cc: jis@mit.edu; mleech@nortelnetworks.com; = mankin@east.isi.edu;
> spreitze@parc.xerox.com
> Subject: Re: GSS in (something like) = TLS?
>
>
> >From: "Mike Spreitzer" = <spreitze@parc.xerox.com>
> >Subject: GSS in (something like) = TLS?
> >
> >It seems natural to me for someone who's = using the GSS-API to want a
> stream filter protocol similar to TLS to = transport the tokens
> >that the GSS-API is defined to produce and = consume.
> ...
> ...
> >Does this sound to you like something that = should be
> produced (and if
> so, where)?
> >
>
>
> This sounds like a good idea. I'm interested in = this from the point
> of view of a Java developer who would like a = streams based API that
> can hide the details of the GSS-API from = me.
>
> As a different issue, I would also like to have = one API that can
> provide me with support for both GSS mechanisms = and TLS cipher
> suites.
>
> It appears that there are two different ways to = achieve both goals
> together:
>
> (1) Support GSS mechanisms under TLS as new = cipher suites and use the
> streams based API's that TLS implementations = generally provide. We
> would need to define new message types to carry = the different GSS
> tokens at different stages of the the TLS = protocol as Mike suggested,
> and also make some exceptions in the TLS = protocol for the GSS cipher
> suites.
>
> This would allow existing applications that use = TLS to continue to
> work seamlessly when switched to a GSS based = cipher suite. Moreover,
> the TLS handshake negotiation mechanism could = be used to negotiate not
> just among existing TLS cipher suites but also = among any GSS mechanism
> based suites. This does not preclude SPNego = from being used as yet
> another GSS based cipher suite.
>
> Note that applications that could use a GSS = based cipher
> suite for TLS
> will be unable to interoperate with peers that = use pure GSS but might
> be able to negotiate successfully with peers = that use only TLS 1.0
> cipher suites.
>
> (2) Define a streams based abstraction that = utilizes the
> GSS-API to wrap/unwrap data as the application = writes to or
> reads from
> the IO streams. To solve the other problem of = TLS support, define a
> TLS like mechanism for the GSS-API, as = suggested by Frank. This
> mechanism might have to reach into the guts of = a TLS implementation
> and utilize just the underlying layers = there.
>
> Note that applications that use this TLS like = mechanism under GSS will
> be unable to interoperate with peers that use = just TLS; however, with
> the help of SPNego, they might interop with = peers that use existing
> GSS mechanisms.
>
> Leaving the question of "GSS under = TLS" or "TLS under GSS" aside,
> there is another issue to note when considering = stream filters for
> GSS. The GSS-API is well tailored for message = based applications that
> might wish to protect different messages = differently. For instance,
> one might be merely integrity protected while = another might be
> encrypted, and yet another might use a = different key strength (QOP)
> for either one of these operations. These = options are requested via
> arguments to the gss_wrap() call. On the other = hand, when we impose a
> streams based abstraction on the GSS-API there = will be one InputStream
> (e.g., in Java) and one OutputStream that the = application will use.
> The application will then be stuck with = "integrity only always" or
> "integrity and privacy always", and = with the same QOP. These
> limitations seem inherent to a stream based API = but for the added
> convenience of streams, many programmers might = be willing to live with
> this limitation.
>
> To answer one other question that Mike asked, = if we undertake to
> provide a solution as outlined in (1) the work = might be more
> appropriate for the TLS working group. However, = if we were to
> undertake a solution as outlined in (2) then = the part of it which
> includes the addition of stream based API for = GSS definitely seems
> more appropriate for the CAT WG.
>
> Regards,
> Mayank
>
>
>
> = -++**=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_01BF6E80.EB97CF30-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 3 20:38: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 UAA03309 for ; Thu, 3 Feb 2000 20:38:57 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA27329 for ietf-cat-wg-out720680; Thu, 3 Feb 2000 16:52:49 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id QAA27324 for ; Thu, 3 Feb 2000 16:52:47 -0800 (PST) Received: from deimos ([13.0.209.39]) by alpha.xerox.com with SMTP id <67908(2)>; Thu, 3 Feb 2000 16:52:23 PST From: "Mike Spreitzer" To: "Matt Hur" Cc: , , , "'Mayank Upadhyay'" , , Subject: RE: GSS in (something like) TLS? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <80A473F584BED311810D0050DA289BD40F3D86@corporate.cybersafe.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Importance: Normal Date: Thu, 3 Feb 2000 16:52:20 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit If I understand you correctly, you're suggesting a hybrid approach: use the GSS to wrap the premaster secret, and then proceed with the rest of TLS as if you had done RSA-based key exchange. Is that right? (1) That doesn't apply the selected GSS mechanism to the data conversation, only the key exchange. (2) Why did you make your GssKbr5Wrapper include two InitialContextTokens? gss_wrap doesn't emit an InitialContextToken, it emits a SealedMessage (right?). Can you be a little more explicit about what's in a GssKrb5Wrapper? (3) This is not exactly specific to Kerberos; what's critical is that the GSS mechanism's setup phase needs just one message --- right? Thanks, Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Feb 7 07:19: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 HAA03187 for ; Mon, 7 Feb 2000 07:19:55 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA05467 for ietf-cat-wg-out720680; Mon, 7 Feb 2000 03:36:06 -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 DAA05462 for ; Mon, 7 Feb 2000 03:36:02 -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 GAA02032; Mon, 7 Feb 2000 06:35:57 -0500 (EST) Message-Id: <200002071135.GAA02032@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-gssv2-javabind-05.txt Date: Mon, 07 Feb 2000 06:35:56 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Security Service API Version 2 : Java bindings Author(s) : J. Kabat, M. Upadhyay Filename : draft-ietf-cat-gssv2-javabind-05.txt Pages : 100 Date : 04-Feb-00 The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2078 [GSSAPIv2]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-javabind-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-gssv2-javabind-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-gssv2-javabind-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000204120730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gssv2-javabind-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gssv2-javabind-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000204120730.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 Mon Feb 7 13:41:29 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 NAA18598 for ; Mon, 7 Feb 2000 13:41:28 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA18385 for ietf-cat-wg-out720680; Mon, 7 Feb 2000 10:14:57 -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 KAA18377 for ; Mon, 7 Feb 2000 10:14:54 -0800 (PST) Received: (qmail 7497 invoked from network); 7 Feb 2000 18:14:21 -0000 Received: from fw.cybersafe.com (192.156.168.3) by dmzsmtp01.cybersafe.com with SMTP; 7 Feb 2000 18:14:21 -0000 Received: from corporate.cybersafe.com ([10.2.2.62]) by fw.cybersafe.com; Mon, 07 Feb 2000 10:11:28 +0000 (PST) Received: by corporate.cybersafe.com with Internet Mail Service (5.5.2650.21) id <1MJJSCQB>; Mon, 7 Feb 2000 10:13:51 -0800 Message-ID: <80A473F584BED311810D0050DA289BD40F3D89@corporate.cybersafe.com> From: Matt Hur To: "'Mike Spreitzer'" Cc: jis@mit.edu, mleech@nortelnetworks.com, mankin@east.isi.edu, "'Mayank Upadhyay'" , ietf-tls@consensus.com, ietf-cat-wg@lists.Stanford.EDU Subject: RE: GSS in (something like) TLS? Date: Mon, 7 Feb 2000 10:13:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7197.154A7B80" 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_01BF7197.154A7B80 Content-Type: text/plain; charset="iso-8859-1" In response to 1,2,3 below: 1) Right - GSS is used to authenticate and wrap the premaster secret. Just as in RFC 2712, this is just another authentication component of a ciphersuite. 2) The GssKbr5Wrapper should contain the authentication token and the wrap token (with encrypted premaster secret). Sorry that wasn't clear. 3) Right - the GSS setup phase needs one message to authenticate and protect the premaster secret. --Matt > -----Original Message----- > From: Mike Spreitzer [mailto:spreitze@parc.xerox.com] > Sent: Thursday, February 03, 2000 4:52 PM > To: Matt Hur > Cc: jis@mit.edu; mleech@nortelnetworks.com; > mankin@east.isi.edu; 'Mayank > Upadhyay'; ietf-tls@consensus.com; ietf-cat-wg@lists.Stanford.EDU > Subject: RE: GSS in (something like) TLS? > > > If I understand you correctly, you're suggesting a hybrid > approach: use the GSS to wrap the premaster secret, and then > proceed with > the rest of TLS as if you had done RSA-based key exchange. > Is that right? > > (1) That doesn't apply the selected GSS mechanism to the data > conversation, only the key exchange. > > (2) Why did you make your GssKbr5Wrapper include two > InitialContextTokens? gss_wrap doesn't emit an > InitialContextToken, it emits a > SealedMessage (right?). Can you be a little more explicit > about what's in a GssKrb5Wrapper? > > (3) This is not exactly specific to Kerberos; what's critical > is that the GSS mechanism's setup phase needs just one message --- > right? > > > Thanks, > Mike > ------_=_NextPart_001_01BF7197.154A7B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GSS in (something like) TLS?

In response to 1,2,3 below:
1) Right - GSS is used to authenticate and wrap the = premaster secret.  Just as in RFC 2712, this is just another = authentication component of a ciphersuite.

2) The GssKbr5Wrapper should contain the = authentication token and the wrap token (with encrypted premaster = secret).  Sorry that wasn't clear.

3) Right - the GSS setup phase needs one message to = authenticate and protect the premaster secret.

--Matt


> -----Original Message-----
> From: Mike Spreitzer [mailto:spreitze@parc.xerox.com]
> Sent: Thursday, February 03, 2000 4:52 = PM
> To: Matt Hur
> Cc: jis@mit.edu; mleech@nortelnetworks.com; =
> mankin@east.isi.edu; 'Mayank
> Upadhyay'; ietf-tls@consensus.com; = ietf-cat-wg@lists.Stanford.EDU
> Subject: RE: GSS in (something like) = TLS?
>
>
> If I understand you correctly, you're = suggesting a hybrid
> approach: use the GSS to wrap the premaster = secret, and then
> proceed with
> the rest of TLS as if you had done RSA-based = key exchange. 
> Is that right?
>
> (1) That doesn't apply the selected GSS = mechanism to the data
> conversation, only the key exchange.
>
> (2) Why did you make your GssKbr5Wrapper = include two
> InitialContextTokens?  gss_wrap doesn't = emit an
> InitialContextToken, it emits a
> SealedMessage (right?).  Can you be a = little more explicit
> about what's in a GssKrb5Wrapper?
>
> (3) This is not exactly specific to Kerberos; = what's critical
> is that the GSS mechanism's setup phase needs = just one message ---
> right?
>
>
> Thanks,
> Mike
>

------_=_NextPart_001_01BF7197.154A7B80-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 7 16:08: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 QAA21851 for ; Mon, 7 Feb 2000 16:08:26 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA28606 for ietf-cat-wg-out720680; Mon, 7 Feb 2000 12:42:12 -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 MAA28601 for ; Mon, 7 Feb 2000 12:42:09 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 7 Feb 2000 20:39: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 PAA13614; Mon, 7 Feb 2000 15:40:30 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <1JXYZJJT>; Mon, 7 Feb 2000 15:43:24 -0500 Message-ID: From: "Linn, John" To: "'Jack Kabat'" , "Linn, John" , "'CAT-WG List'" Subject: RE: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt Date: Mon, 7 Feb 2000 15:50:18 -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 Thanks for this note and the recently-issued draft-ietf-cat-gssv2-javabind-05.txt, which also updates references from RFCs 1509/2078 to RFCs 2743/2744. Since no objections were posted to the list in response to this message, and no objections to the predecessor document were made to the list during the WG Last-Call, my assumption is that this version is ready to be forwarded to the IESG on behalf of the WG to be considered for Proposed Standard, and I'll plan to do so later this week. --jl > -----Original Message----- > From: Jack Kabat [mailto:jackk@valicert.com] > Sent: Monday, January 24, 2000 2:45 AM > To: Linn, John; 'CAT-WG List' > Subject: RE: Initiating WG Last-Call: > draft-ietf-cat-gssv2-javabind-04.txt > > > > 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 Feb 7 18:29:30 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24150 for ; Mon, 7 Feb 2000 18:29:29 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id NAA29487 for ietf-cat-wg-out720680; Mon, 7 Feb 2000 13:07:49 -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 NAA29382 for ; Mon, 7 Feb 2000 13:06:48 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 7 Feb 2000 21:03:54 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 QAA14809 for ; Mon, 7 Feb 2000 16:05:10 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <1JXYZJSZ>; Mon, 7 Feb 2000 16:08:03 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: CAT session in Adelaide Date: Mon, 7 Feb 2000 16:14:59 -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 fanciers: There's a CAT session tentatively scheduled for the Adelaide IETF meeting, on Monday, 27 March, 0930-1130. If you're interested in leading a discussion on an active WG Internet-Draft, please let me know NLT Friday, 18 February, so that this can be reflected in a draft session agenda. (NB: The Internet-Draft submission window in advance of the Adelaide meeting will close on Friday, 10 March.) --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 Tue Feb 8 00:39:03 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 AAA29345 for ; Tue, 8 Feb 2000 00:39:02 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id VAA03122 for ietf-cat-wg-out720680; Mon, 7 Feb 2000 21:13:20 -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 VAA03117 for ; Mon, 7 Feb 2000 21:13:18 -0800 (PST) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Feb 2000 21:05:07 -0800 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2514071@seine.valicert.com> From: Jack Kabat To: "Linn, John" Cc: "'CAT-WG List'" Subject: RE: Initiating WG Last-Call: draft-ietf-cat-gssv2-javabind-04.txt Date: Mon, 7 Feb 2000 21:05:06 -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 John, The updated document addresses all the outstanding comments that Mayank and I have received. draft-ietf-cat-gssv2-javabind-05.txt incorporates the following changes: 1) list of changes send previously 2) changes to reflect RFC status of the GSS-API V2 C-bindings and GSS-API V2 references 3) description has been added to GSSContext.getMech() method to indicate it may be called before context establishment as specified in RFC 2743. 4) Since we added the DEFAULT_LIFETIME constant to both GSSCredential and GSSContext, we have also renamed the INDEFINITE constant to INDEFINITE_LIFETIME. Regards, Jack > -----Original Message----- > From: Linn, John [mailto:jlinn@rsasecurity.com] > Sent: Monday, February 07, 2000 12:50 PM > To: 'Jack Kabat'; Linn, John; 'CAT-WG List' > Subject: RE: Initiating WG Last-Call: > draft-ietf-cat-gssv2-javabind-04.txt > > > Thanks for this note and the recently-issued > draft-ietf-cat-gssv2-javabind-05.txt, which also updates > references from > RFCs 1509/2078 to RFCs 2743/2744. Since no objections were > posted to the > list in response to this message, and no objections to the predecessor > document were made to the list during the WG Last-Call, my > assumption is > that this version is ready to be forwarded to the IESG on > behalf of the WG > to be considered for Proposed Standard, and I'll plan to do > so later this > week. > > --jl > > > -----Original Message----- > > From: Jack Kabat [mailto:jackk@valicert.com] > > Sent: Monday, January 24, 2000 2:45 AM > > To: Linn, John; 'CAT-WG List' > > Subject: RE: Initiating WG Last-Call: > > draft-ietf-cat-gssv2-javabind-04.txt > > > > > > > > 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 Thu Feb 10 21:38:09 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14670 for ; Thu, 10 Feb 2000 21:38:02 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA16343 for ietf-cat-wg-out720680; Thu, 10 Feb 2000 18:06:10 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id SAA16333 for ; Thu, 10 Feb 2000 18:06:06 -0800 (PST) Received: from deimos ([13.0.209.39]) by alpha.xerox.com with SMTP id <71828(1)>; Thu, 10 Feb 2000 17:48:03 PST From: "Mike Spreitzer" To: "Mayank Upadhyay" , , Cc: , , Subject: RE: GSS in (something like) TLS? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 In-Reply-To: <200002030915.BAA04543@taller.eng.sun.com> Date: Thu, 10 Feb 2000 17:48:03 PST Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Mayank Upadhyay wrote: > This sounds like a good idea. I'm interested in this from the point > of view of a Java developer who would like a streams based API that > can hide the details of the GSS-API from me. It seems to me that a lot of the details of the API would have to stick around; what I'm asking for is just a particular higher-level protocol in which to put the tokens in which GSS traffics. The stream abstraction will be a little easier to use than the token exchange; is that what you mean? > As a different issue, I would also like to have one API that can > provide me with support for both GSS mechanisms and TLS cipher > suites. Yes, and I think this may be good for interoperability and evolutionary reasons as well. Actually, I think it would be good to have *two* APIs that each gives me access to both sets of mechanisms --- and those two APIs should be the GSS-API and the one(s?) common for TLS. It seems to me that I may be thinking something unusual in terms of software structure for the peers. It's not the only scenario we're addressing, but it's a simple one I'd like to include. I'd like to be able to write code that is a user of the GSS-API --- not in bed with anything below that API --- and that implements the stream filter I'm asking for. In particular, without modifying GSS tokens or even understanding the token formats defined for use with specific GSS mechanisms. In terms of protocols, I thus think it might be best to combine the two approaches you suggested, with a slight change to your first (if I understood it correctly). I like the idea of easing the evolution of the wire protocols as well as easing the evolution of the APIs. I also like to minimize round trips. I'd be inclined to go about them as follows. The basic idea is to generalize the TLS protocol by adding record types to carry GSS tokens. Define a new TLS record type to carry GSS setup tokens. A client willing to support both GSS and old TLS starts the negotiation by sending both (1) a TLS Client Hello message and (2) the token out of the first call on the GSS-API's init-sec-context routine. These would be two TLS records, with the GSS-oriented one first. An old server would simply discard the GSS-oriented record (that's what TLS says it should do with non-understood record types, right?), thus automatically restricting the negotiation to existing TLS cipher-suites. A new server would understand this pair of messages as requesting an expanded negotiation, and respond however it likes. An old client would send a TLS Client Hello not preceded by a GSS-oriented message; an old server would be happy, and a new server would understand the client's limitations. That approach dodges the following bullet on the wire (although not in the API's --- but I think that's less worrisome). The GSS identifies a mechanism by an OID; this technique supports decentalized evolution, which I think is good. TLS identifies a cipher-suite by a 16-bit number, managed by a central registry, which I think is less good. As suggested above, I might support also defining GSS mechanisms that employ the existing TLS cipher-suites. This would give two ways --- on the wire --- to get to those mechanisms: directly at the generalized TLS level, or indirectly as a mechanism of the GSS embedded in the generalized TLS. That doesn't bother me too much. Mike -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Feb 11 08:29:03 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 IAA07829 for ; Fri, 11 Feb 2000 08:29:00 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id EAA15553 for ietf-cat-wg-out720680; Fri, 11 Feb 2000 04:48:08 -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 EAA15548 for ; Fri, 11 Feb 2000 04:48:04 -0800 (PST) Received: from shaggy-s1.lineone.net by MIT.EDU with SMTP id AA14017; Fri, 11 Feb 00 07:48:01 EST Received: from notebook (host212-140-36-57.btinternet.com [212.140.36.57]) by shaggy.lineone.net (8.9.3/8.8.8) with SMTP id MAA15651; Fri, 11 Feb 2000 12:23:41 GMT Date: Fri, 11 Feb 2000 12:23:41 GMT From: cddeal To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, February 11th, 2000 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, February 9th, 2000 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, February 7th, 2000 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, February 6th, 2000 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, February 12th, 2000 Reply-To: cddeal@lineone.net Subject: CD Deal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mime-Autoconverted: from 8bit to quoted-printable by shaggy.lineone.net id MAA15651 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.Stanford.EDU id EAA15549 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Welcome to CD Deal the 'new' software concept that gives you: * FREE Software selling in the UK retail for £99.99!! In the first month you will be able to have Plan it! Marketing Plan (£49.99), Life Label Maker (£39.99) and Tertrimania lite (£9.99) - all absollutely FREE * Other software and music titles which you can buy at fantastic prices!! eg Shania Twain WGames Pack worth £120 in the shops which we sell £29.99, the complete Kids Pack selling in UK retail for £180 which we sell for £29.99 The software we are selling is bought directly from the software and music companies and is packaged in plastic crystal cases exactly the same as in the shops. To receive ONE email a month with great offers and details of FREE products which you can have with NO obligation, NO catch and No contract all you need to do is click on the address below: Email: cddeal_yes@lineone.net If you don't want to receive the once a month e-mail with great offers then ignore this mail and never hear from us again. We look forward to hearing from you. Nick Hansen Customer Services Manager. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 11 09:09: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 JAA09215 for ; Fri, 11 Feb 2000 09:09:36 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA16244 for ietf-cat-wg-out720680; Fri, 11 Feb 2000 05:27:43 -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 FAA16239 for ; Fri, 11 Feb 2000 05:27:40 -0800 (PST) Received: from shaggy-s1.lineone.net by MIT.EDU with SMTP id AA26953; Fri, 11 Feb 00 08:28:54 EST Received: from notebook (host212-140-46-209.btinternet.com [212.140.46.209]) by shaggy.lineone.net (8.9.3/8.8.8) with SMTP id NAA28915; Fri, 11 Feb 2000 13:04:12 GMT Date: Fri, 11 Feb 2000 13:04:12 GMT From: cddeal To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, February 11th, 2000 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, February 9th, 2000 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, February 7th, 2000 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, February 6th, 2000 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, February 12th, 2000 Reply-To: cddeal@lineone.net Subject: CD Deal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mime-Autoconverted: from 8bit to quoted-printable by shaggy.lineone.net id NAA28915 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.Stanford.EDU id FAA16240 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Welcome to CD Deal the 'new' software concept that gives you: * FREE Software selling in the UK retail for £99.99!! In the first month you will be able to have Plan it! Marketing Plan (£49.99), Life Label Maker (£39.99) and Tertrimania lite (£9.99) - all absollutely FREE * Other software and music titles which you can buy at fantastic prices!! eg Shania Twain WGames Pack worth £120 in the shops which we sell £29.99, the complete Kids Pack selling in UK retail for £180 which we sell for £29.99 The software we are selling is bought directly from the software and music companies and is packaged in plastic crystal cases exactly the same as in the shops. To receive ONE email a month with great offers and details of FREE products which you can have with NO obligation, NO catch and No contract all you need to do is click on the address below: Email: cddeal_yes@lineone.net If you don't want to receive the once a month e-mail with great offers then ignore this mail and never hear from us again. We look forward to hearing from you. Nick Hansen Customer Services Manager. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 14 09:06: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 JAA10543 for ; Mon, 14 Feb 2000 09:06:15 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA28617 for ietf-cat-wg-out720680; Mon, 14 Feb 2000 05:33:24 -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 FAA28612 for ; Mon, 14 Feb 2000 05:33:21 -0800 (PST) Received: from odin.ietf.org by MIT.EDU with SMTP id AA25431; Mon, 14 Feb 00 08:34:37 EST Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08414; Mon, 14 Feb 2000 08:33:16 -0500 (EST) Message-Id: <200002141333.IAA08414@ietf.org> To: IETF-Announce:;;;;@cnri.reston.va.us;;; Cc: cat-ietf@mit.edu From: The IESG Subject: Last Call: Generic Security Service API Version 2 : Java bindings to Proposed Standard Reply-To: iesg@ietf.org Date: Mon, 14 Feb 2000 08:33:16 -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 Generic Security Service API Version 2 : Java bindings 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 February 28, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-javabind-05.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 Wed Feb 16 07:11:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23538 for ; Wed, 16 Feb 2000 07:11:44 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA11403 for ietf-cat-wg-out720680; Wed, 16 Feb 2000 03:39:27 -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 DAA11398 for ; Wed, 16 Feb 2000 03:39:21 -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 GAA22383; Wed, 16 Feb 2000 06:39:15 -0500 (EST) Message-Id: <200002161139.GAA22383@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-set-passwd-01.txt Date: Wed, 16 Feb 2000 06:39:14 -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 : Kerberos Set/Change Password: Version 2 Author(s) : M. Swift, J. Trostle, J. Brezak, B. Gossman Filename : draft-ietf-cat-kerberos-set-passwd-01.txt Pages : 6 Date : 15-Feb-00 The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), does not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal extends [4] to allow password setting. The changes are: adding new fields to the request message to indicate the principal which is having its password set, not requiring the initial flag in the service ticket, using a new protocol version number, and adding three new result codes. We also extend the set/change protocol to allow a client to send a sequence of keys to the KDC instead of a cleartext password. If in the cleartext password case, the cleartext password fails to satisfy password policy, the server should use the result code KRB5_KPASSWD_POLICY_REJECT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-set-passwd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-set-passwd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000215124048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-set-passwd-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-set-passwd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000215124048.I-D@ietf.org> --OtherAccess-- --NextPart-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Feb 22 09:44:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11367 for ; Tue, 22 Feb 2000 09:44:09 -0500 (EST) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id GAA18842 for ietf-cat-wg-out720680; Tue, 22 Feb 2000 06:12: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 GAA18837 for ; Tue, 22 Feb 2000 06:12:30 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 22 Feb 2000 14:09:23 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 JAA12214 for ; Tue, 22 Feb 2000 09:10:31 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 22 Feb 2000 09:13:43 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: RE: CAT session in Adelaide Date: Tue, 22 Feb 2000 09:20:52 -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 fanciers: I've not yet received definitive proposals to lead discussions in Adelaide on active CAT WG Internet-Drafts. Since LIPKEY and the high-level GSS Java bindings have recently been handed up to the IESG for advancement consideration, it would appear that most of the remaining candidate discussion topics are likely to concern Kerberos documents. At this point, I'll renew the solicitation for discussion leaders and their topics through this week (i.e., Friday, 25 February); if contents for a concrete agenda do not emerge, it may become appropriate to reevaluate whether the session should take place. --jl > -----Original Message----- > From: Linn, John [mailto:jlinn@rsasecurity.com] > Sent: Monday, February 07, 2000 4:15 PM > To: 'CAT-WG List' > Subject: CAT session in Adelaide > > > CAT fanciers: > > There's a CAT session tentatively scheduled for the Adelaide > IETF meeting, > on Monday, 27 March, 0930-1130. If you're interested in leading a > discussion on an active WG Internet-Draft, please let me know > NLT Friday, 18 > February, so that this can be reflected in a draft session > agenda. (NB: The > Internet-Draft submission window in advance of the Adelaide > meeting will > close on Friday, 10 March.) > > --jl > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Feb 22 10:35:39 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12996 for ; Tue, 22 Feb 2000 10:35:29 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA20349 for ietf-cat-wg-out720680; Tue, 22 Feb 2000 07:13:31 -0800 (PST) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA20344 for ; Tue, 22 Feb 2000 07:13:28 -0800 (PST) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 22 Feb 2000 15:13:28 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id KAA24948; Tue, 22 Feb 2000 10:12:13 -0500 Message-Id: <3.0.6.32.20000222101324.00ab9100@mail.gf.org> Received: from jlefevre.dialup.access.net ([166.84.194.85]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 22 Feb 2000 15:13:26 UT X-Sender: ms@mail.gf.org X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 22 Feb 2000 10:13:24 -0500 To: From: Michael Smith Subject: RE: CAT session in Adelaide In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 09:20 AM 2/22/00 -0500, John wrote: >CAT fanciers: > >I've not yet received definitive proposals to lead discussions in Adelaide >on active CAT WG Internet-Drafts. I won't be able to make it to Adelaide, but would like to pick up the JGSS SPI discussions in time for the following IETF -- if anyone else is interested. I certainly haven't any reason to think that anybody has a pressing need to discuss these issues in Adelaide, but correct me if I'm wrong. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 23 11:55:49 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26230 for ; Wed, 23 Feb 2000 11:55:47 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA29594 for ietf-cat-wg-out720680; Wed, 23 Feb 2000 08:23:27 -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 IAA29589 for ; Wed, 23 Feb 2000 08:23:24 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 23 Feb 2000 16:20: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 LAA26427 for ; Wed, 23 Feb 2000 11:21:23 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Wed, 23 Feb 2000 11:24:36 -0500 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Draft 1, CAT-WG Adelaide agenda Date: Wed, 23 Feb 2000 11:31:47 -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 fanciers: Based on requests so far received, attached find a Draft 1 agenda for the CAT-WG Adelaide session. Further requests to lead discussions on WG drafts are welcome, and will be considered as inputs to a subsequent agenda draft; I'd also encourage advance list discussions on any contentious areas related to the drafts, in order to facilitate progress at and in advance of the meeting. CAT-WG Adelaide Agenda, Draft 1 as of 23 February 2000 Session on Monday, 27 March, 0930-1130 0930-0940: Opening remarks 0940-1005: Kerberos-Revisions (Cliff Neuman) 1005-1020: Kerberos PK-Init (Cliff Neuman) 1020-1040: Kerberos DNS-Locate (Ken Hornstein) 1040-1050: GAA-API (Cliff Neuman) 1050-1120: Other business as needed 1120-1130: Status review and closing remarks --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Feb 23 19:35:58 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 TAA05788 for ; Wed, 23 Feb 2000 19:35:57 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA25240 for ietf-cat-wg-out720680; Wed, 23 Feb 2000 15:54:28 -0800 (PST) Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA25200 for ; Wed, 23 Feb 2000 15:54:19 -0800 (PST) Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id RAA27798; Wed, 23 Feb 2000 17:52:46 -0600 (CST) Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id RAA18250; Wed, 23 Feb 2000 17:52:47 -0600 (CST) Message-ID: <00df01bf7e59$a26e7400$24a13994@shaggy.austin.dascom.com> From: "Bob Blakley" To: "CAT" Subject: Authorization APIs Date: Wed, 23 Feb 2000 17:56:42 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DC_01BF7E27.57D40400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01BF7E27.57D40400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, In Oslo I mentioned that we had a proposal for an authorization API in consideration for standardization at the Open Group. This proposal has now been adopted by the Open Group, and the resulting final API is available in HTML format on the Open Group web site at: http://www.opengroup.org/publications/catalog/c908.htm#medium2 (you have to fill out a registration to get access to this; you can get the .pdf free if you're an Open Group member. If anyone wants a copy of the .pdf and isn't a member, please get in touch with me privately via email and I'll try to arrange a free review copy). A number of commercial organizations have endorsed the API and made various statements about implementation and exploitation; I can provide a list if it's interesting; IBM/Tivoli has already implemented and shipped the API in its Policy Director product, so it's possible to evaluate its capabilities "in use" if that's material. I don't know what the group's general feeling is about progressing an authorization API definition on the standards track in CAT, but if there is interest in doing this, I'd like to have the group consider this API as well as GAA (I'm not necessarily proposing this as an alternative; Cliff and I have talked several times and my impression is that we are both willing to work together on some sort of compromise proposal incorporating the best elements of both APIs if this is considered desirable by the group). I'd be interested to hear from the list whether there's interest in progressing *any* authorization API on the standards track, or whether we're taking a "wait-and-see" attitude for a while. --bob Bob Blakley Chief Scientist, Tivoli SecureWay Business Unit ------=_NextPart_000_00DC_01BF7E27.57D40400 Content-Type: text/x-vcard; name="Bob Blakley.vcf" Content-Disposition: attachment; filename="Bob Blakley.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Blakley;Bob FN:Bob Blakley ORG:Dascom TITLE:Chief Scientist TEL;WORK;VOICE:+1 (512) 458-4037 x 5012 TEL;WORK;FAX:+1 (512) 458-2377 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 = Balcones Drive;Austin;TX;78731;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 = Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA URL: URL:http://www.dascom.com EMAIL;PREF;INTERNET:blakley@dascom.com REV:20000223T235642Z END:VCARD ------=_NextPart_000_00DC_01BF7E27.57D40400-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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 Feb 24 09:00:03 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 JAA29871 for ; Thu, 24 Feb 2000 09:00:01 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA05629 for ietf-cat-wg-out720680; Thu, 24 Feb 2000 05:29:37 -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 FAA05624 for ; Thu, 24 Feb 2000 05:29:33 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 24 Feb 2000 13:26:24 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 IAA05027; Thu, 24 Feb 2000 08:27:03 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 24 Feb 2000 08:30:18 -0500 Message-ID: From: "Linn, John" To: "'Bob Blakley'" , CAT Subject: RE: Authorization APIs Date: Thu, 24 Feb 2000 08:37:30 -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 Bob wrote, excerpting: I'd be interested to hear from the list whether there's interest in progressing *any* authorization API on the standards track, or whether we're taking a "wait-and-see" attitude for a while. As of the Oslo meeting last summer, the WG position was that any authorization API documents developed within CAT would be targeted for Experimental, not standards track status. This reflected concerns about levels of constituency and active discussion, and a recognition that extensive work with consuming applications would be required in order to validate an API's suitability and utility. This position hasn't been revisited since that point; unless and until a strong consensus and constituency becomes apparent within the WG, I consider that it still holds. --jl -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Feb 24 10:47:50 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03434 for ; Thu, 24 Feb 2000 10:47:46 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA13111 for ietf-cat-wg-out720680; Thu, 24 Feb 2000 06:59:56 -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 GAA13106 for ; Thu, 24 Feb 2000 06:59:51 -0800 (PST) Received: from bull.net (itinerant4.frpq.bull.fr [129.184.8.52]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id PAA23054; Thu, 24 Feb 2000 15:59:19 +0100 Message-ID: <38B54739.E8CF373E@bull.net> Date: Thu, 24 Feb 2000 15:59:05 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: "Linn, John" CC: "'Bob Blakley'" , CAT Subject: Re: Authorization APIs 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 > Bob wrote, excerpting: > > I'd be interested to hear from the list whether there's interest in > progressing *any* > authorization API on the standards track, or whether we're taking a > "wait-and-see" > attitude for a while. > > As of the Oslo meeting last summer, the WG position was that any > authorization API documents developed within CAT would be targeted for > Experimental, not standards track status. This reflected concerns about > levels of constituency and active discussion, and a recognition that > extensive work with consuming applications would be required in order to > validate an API's suitability and utility. This position hasn't been > revisited since that point; unless and until a strong consensus and > constituency becomes apparent within the WG, I consider that it still holds. I agree. Denis > --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 Fri Feb 25 07:20:10 2000 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05908 for ; Fri, 25 Feb 2000 07:20:10 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA28150 for ietf-cat-wg-out720680; Fri, 25 Feb 2000 03:32:07 -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 DAA28144 for ; Fri, 25 Feb 2000 03:32:03 -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 GAA04976; Fri, 25 Feb 2000 06:32:01 -0500 (EST) Message-Id: <200002251132.GAA04976@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-set-passwd-02.txt Date: Fri, 25 Feb 2000 06:32:01 -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 : Kerberos Set/Change Password: Version 2 Author(s) : M. Swift, J. Trostle, J. Brezak, B. Gossman Filename : draft-ietf-cat-kerberos-set-passwd-02.txt Pages : 6 Date : 24-Feb-00 The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), does not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal extends [4] to allow password setting. The changes are: adding new fields to the request message to indicate the principal which is having its password set, not requiring the initial flag in the service ticket, using a new protocol version number, and adding three new result codes. We also extend the set/change protocol to allow a client to send a sequence of keys to the KDC instead of a cleartext password. If in the cleartext password case, the cleartext password fails to satisfy password policy, the server should use the result code KRB5_KPASSWD_POLICY_REJECT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-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-kerberos-set-passwd-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-kerberos-set-passwd-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: <20000224111601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-set-passwd-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-set-passwd-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111601.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 Mon Feb 28 17:12:31 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 RAA21808 for ; Mon, 28 Feb 2000 17:12:18 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA27408 for ietf-cat-wg-out720680; Mon, 28 Feb 2000 13:36:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA04034 for ; Mon, 28 Feb 2000 09:48:33 -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 GAA02776; Mon, 28 Feb 2000 06:20:52 -0500 (EST) Message-Id: <200002281120.GAA02776@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-tapp-02.txt Date: Mon, 28 Feb 2000 06:20:52 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Utilizing Tickets for Application Servers (PKTAPP) Author(s) : A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman Filename : draft-ietf-cat-kerberos-pk-tapp-02.txt Pages : 5 Date : 25-Feb-00 Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-tapp-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-kerberos-pk-tapp-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-kerberos-pk-tapp-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: <20000225135651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-tapp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-tapp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000225135651.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