From owner-ietf-cat-wg@lists.Stanford.EDU Mon Oct 4 10:21:48 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02420 for ; Mon, 4 Oct 1999 10:21:46 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA28673 for ietf-cat-wg-out720680; Mon, 4 Oct 1999 06:15:35 -0700 (PDT) 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 GAA28668 for ; Mon, 4 Oct 1999 06:15:30 -0700 (PDT) Received: from s2.smtp.oleane.net by MIT.EDU with SMTP id AA02750; Mon, 4 Oct 99 09:15:31 EDT Received: from Dell (dyn-1-1-229.Cor.dialup.oleane.fr [62.161.8.229]) by s2.smtp.oleane.net with SMTP id PAA82248 for ; Mon, 4 Oct 1999 15:15:23 +0200 (CEST) Message-Id: <003601bf0e6a$82bfe6c0$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: From Firewall to IPSec VPNs Date: Mon, 4 Oct 1999 15:15:20 +0200 Organization: Upperside Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01BF0E7B.45F4CA60" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0033_01BF0E7B.45F4CA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Security services and protection mechanisms IPv6 promises regarding IPSec Certification infrastructure Standardization update Case Studies: ISPs, carriers, private networks AH and ESP protocols description Possible future extensions and modifications of the IKE protocol Complementarity between IPSec and firewalls Global Site-to-Site IPSec VPN's with End-to-End SLA's Managing widespread IPSEC virtual private networks Solving IPSec VPNs scalability Results of some interoperability tests IPSec architectures and non-standardized aspects of IPSec Adding IPSec VPN functions in an existing router network Impact of fragmentation on the performance of IPSec coding IPSEC 99 Conference From Firewall to IPSec VPNs October 26, 27, 28, 29, 1999 Paris - France More infos: www.upperside.fr/baipsec.htm ------=_NextPart_000_0033_01BF0E7B.45F4CA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Security services and protection mechanisms
IPv6 promises = regarding=20 IPSec
Certification infrastructure
Standardization update
Case = Studies:=20 ISPs, carriers, private networks
AH and ESP protocols = description
Possible=20 future extensions and modifications of the IKE = protocol
Complementarity=20 between IPSec and firewalls
Global Site-to-Site IPSec VPN's with = End-to-End=20 SLA's
Managing widespread IPSEC virtual private networks
Solving = IPSec=20 VPNs scalability
Results of some interoperability tests
IPSec=20 architectures and non-standardized aspects of IPSec
Adding IPSec VPN=20 functions in an existing router network
Impact of fragmentation on = the=20 performance of IPSec coding

IPSEC 99 Conference
From Firewall = to IPSec=20 VPNs

October 26, 27, 28, 29, 1999
Paris - France

More = infos: www.upperside.fr/baipsec.htm=
 
------=_NextPart_000_0033_01BF0E7B.45F4CA60-- ========================================================================== 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 Oct 7 11:20:34 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18782 for ; Thu, 7 Oct 1999 11:20:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA15509 for ietf-cat-wg-out720680; Thu, 7 Oct 1999 07:10:01 -0700 (PDT) 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 HAA15502 for ; Thu, 7 Oct 1999 07:09:58 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 7 Oct 1999 14:08:55 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 KAA20583 for ; Thu, 7 Oct 1999 10:04:33 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <4B4JG53L>; Thu, 7 Oct 1999 10:11:31 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Next steps for CAT Date: Thu, 7 Oct 1999 10:16:12 -0400 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 heard from the IETF Secretariat about scheduling of a CAT session for the Washington, DC IETF (8-12 November), but will update the list as further information is available. The WG mailing list has been very quiet since the Oslo meeting, and I hope that we can achieve closure on as many items as possible before the conclusion of the DC meeting. Based on currently reported plans for draft revisions, and comparing against the WG milestones list at http://www.ietf.org/html.charters/cat-charter.html, my current understandings (and embedded questions) regarding potential standards-track actions are as follows: (1) We've decided not to pursue standards-track advancement for authorization documents, though these may become candidates for Experimental RFC publication. (2) The apparent sense of the group regarding low-infrastructure mechanism definitions is to pursue standards-track advancement of LIPKEY. A revision to draft-ietf-cat-lipkey-01 is needed, per discussion noted in Oslo minutes. Question: will this upcoming revision be sufficient and suitable for WG Last-Call? (3) The GSS Java bindings specification, gssv2-javabind-02, is to be revised within the I-D submission window which closes on 22 October, and discussion is intended for the DC meeting. Advancement of this document is a recognized priority. It was proposed at the Oslo meeting that discussion of SPI requirements be undertaken before advancement of gssv2-javabind, but this discussion has not yet proceeded on the list. Question: should progress of gssv2-javabind remain serialized on pending SPI discussion, or should it proceed towards WG Last-Call in the absence of such discussion? (4) Per discussion at Oslo, revisions are pending to both pk-init and kerberos-revisions; given that these documents are related, it was considered appropriate for a concurrent WG Last-Call to be undertaken once suitable versions of both documents are available. (5) Two other Kerberos-related drafts, kerberos-extra-tgt-02 and kerberos-set-passwd-00, have been posted since the Oslo meeting but have received limited discussion on the mailing list. Question: Does constituency and consensus exist for progressing the contents of these documents on the standards track and, if so, how should this be pursued relative to the ongoing development of kerberos-revisions? (6) An SPKM-related draft, ecdh-spkm-00, has been posted since the Oslo meeting but has not yet been discussed on the mailing list. Question: does constituency and consensus exist for progressing this document on the standards track? --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 Oct 7 12:25:03 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20150 for ; Thu, 7 Oct 1999 12:25:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA17212 for ietf-cat-wg-out720680; Thu, 7 Oct 1999 08:23:20 -0700 (PDT) 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 IAA17207 for ; Thu, 7 Oct 1999 08:23:18 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26965; Thu, 7 Oct 1999 08:23:15 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA16166; Thu, 7 Oct 1999 08:23:13 -0700 (PDT) Received: from teal (awe8-122.Central.Sun.COM [129.147.8.122]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA269761; Thu, 7 Oct 1999 08:23:12 -0700 (PDT) Date: Thu, 7 Oct 1999 08:25:30 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Next steps for CAT To: "Linn, John" Cc: "'CAT-WG List'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > (2) The apparent sense of the group regarding low-infrastructure mechanism > definitions is to pursue standards-track advancement of LIPKEY. A revision > to draft-ietf-cat-lipkey-01 is needed, per discussion noted in Oslo minutes. > Question: will this upcoming revision be sufficient and suitable for WG > Last-Call? Possibly. However I think there should be at least one working prototype before issuing last call. I wanted to have one of those prototypes in time for IETF in DC, but a comedy of obstacles have gotten in they way. While writing LIPKEY code is easy, since LIPKEY is layered over SPKM, a working SPKM is needed. The SPKM code I have worked several years ago, but software rot has delayed resuscitation. -mre ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 8 09:46:21 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20633 for ; Fri, 8 Oct 1999 09:46:20 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA25138 for ietf-cat-wg-out720680; Fri, 8 Oct 1999 06:08:36 -0700 (PDT) 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 GAA25133 for ; Fri, 8 Oct 1999 06:08:33 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 8 Oct 1999 13:07:29 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 JAA18546 for ; Fri, 8 Oct 1999 09:03:13 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <4B4JHAH0>; Fri, 8 Oct 1999 09:10:12 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Scheduling of DC CAT session Date: Fri, 8 Oct 1999 09:14:59 -0400 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 DC attendees: According to the agenda now posted on http://www.ietf.org/meetings/agenda.txt, the CAT WG session for the DC IETF is slated for Monday, 8 November, 0930-1130. If you're interested in leading a discussion on an active WG document, please let me know by next Friday, 15 October, so that this can be reflected in preparing a draft agenda for the session. --jl ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 8 12:44:38 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25851 for ; Fri, 8 Oct 1999 12:44:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA29134 for ietf-cat-wg-out720680; Fri, 8 Oct 1999 08:54:17 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA29129 for ; Fri, 8 Oct 1999 08:54:14 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 8 Oct 1999 15:54:14 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id LAA11585; Fri, 8 Oct 1999 11:53:39 -0400 Message-Id: <199910081553.LAA11585@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 8 Oct 1999 15:54:13 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Oct 1999 11:54:13 -0400 To: "'CAT-WG List'" From: Michael Smith Subject: Re: Next steps for CAT Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 10:16 AM 10/7/99 -0400, "Linn, John" wrote: [....] >It was proposed at the Oslo meeting that discussion of >SPI requirements be undertaken before advancement of gssv2-javabind, but >this discussion has not yet proceeded on the list. Question: should >progress of gssv2-javabind remain serialized on pending SPI discussion, or >should it proceed towards WG Last-Call in the absence of such discussion? There's been some off-list back-and-forth about these issues. Since unfortunately I wasn't able to make it to Oslo, I have only a secondhand sense of what was said there. For what it's worth, I didn't get the impression that very many people were concerned about the niceties of the interaction between bindings and SPI (though I of course care passionately about every fourth-order optimization). What I intend to do, provisionally, is revise the SPI document to bring it in line with the forthcoming bindings document. I will come prepared (if anyone is still interested) to discuss some areas where the bindings might perhaps change a bit and make the SPI stuff a bit cleaner. Some of these topics were aired on he list before Oslo; unfortunately, not having been present, I don't have any first-hand sense of how much discussion they received there. I certainly don't want to re-open matters that the WG has already disposed of. In any case, it's my hope that one way or the other we will be able (if we choose) to progress both documents in tandem after DC. I don't think there are any open issues so unclear (at the SPI level) that we can't dispose of them in DC, and there'll certainly then be nothing to hold up the bindings spec. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 8 15:31:43 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29368 for ; Fri, 8 Oct 1999 15:31:43 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA11533 for ietf-cat-wg-out720680; Fri, 8 Oct 1999 12:02:22 -0700 (PDT) Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA11528 for ; Fri, 8 Oct 1999 12:02:19 -0700 (PDT) Received: from int-mail.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ext-mail.valicert.com (8.9.3/8.9.3) with ESMTP id MAA12556; Fri, 8 Oct 1999 12:02:16 -0700 (PDT) Received: from stlawrence (stlawrence.valicert.com [192.168.3.101]) by int-mail.valicert.com (8.9.3/8.9.3) with SMTP id MAA27157; Fri, 8 Oct 1999 12:01:46 -0700 (PDT) From: "Jack Kabat" To: "'Linn, John'" , "'CAT-WG List'" Subject: RE: Next steps for CAT Date: Fri, 8 Oct 1999 12:01:48 -0700 Message-ID: <015001bf11bf$9326c300$6503a8c0@stlawrence.valicert.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-cat-wg@lists.Stanford.EDU > [mailto:owner-ietf-cat-wg@lists.Stanford.EDU]On Behalf Of Linn, John > Sent: Thursday, October 07, 1999 7:16 AM > To: 'CAT-WG List' > Subject: Next steps for CAT > > > CAT fanciers: .... > (3) The GSS Java bindings specification, gssv2-javabind-02, is to > be revised within the I-D submission window which closes on 22 October, > and discussion is intended for the DC meeting. Advancement of this > document is a recognized priority. It was proposed at the Oslo meeting > that discussion of SPI requirements be undertaken before advancement of > gssv2-javabind, but this discussion has not yet proceeded on the list. > Question: > should progress of gssv2-javabind remain serialized on pending SPI > discussion, or should it proceed towards WG Last-Call in the absence > of such discussion? I think that the two documents should be de-coupled and JGSS should progress without being held back by the SPI document. I see the following reasons for this: 1) Advancing the JGSS document would provide the application developers an API to build with their applications. I look at the SPI as an interface for the JGSS layer developers which does not involve the JGSS application writer. The SPI is the plumbing under the JGSS. Creating an SPI mechanism will change the JGSS implementation, but should not effect the APIs available to the application developer. If desired, one could update the JGSS package without needing to change their application level code. 2) One can implement a JGSS package without using SPIs. The C-Bindings does not specify a formal SPI layer which has not prevented its implementation. 3) I think we are close to closure on the few remaining issues w.r.t JGSS. I have not seen much review of the SPI document, and think it might be still quite some time before it reaches the same level as JGSS. Regards, Jack Kabat ========================================================================== 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 Oct 8 18:12:30 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01851 for ; Fri, 8 Oct 1999 18:12:29 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA22265 for ietf-cat-wg-out720680; Fri, 8 Oct 1999 14:30:31 -0700 (PDT) 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 OAA22260 for ; Fri, 8 Oct 1999 14:30:28 -0700 (PDT) Received: from tnt.isi.edu by MIT.EDU with SMTP id AA10702; Fri, 8 Oct 99 17:30:32 EDT Received: from brb.isi.edu (brb.isi.edu [128.9.160.181]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA14061; Fri, 8 Oct 1999 14:29:54 -0700 (PDT) From: ACM Conference on Computer and Communication Security Received: (from ccs99@localhost) by brb.isi.edu (8.8.7/8.8.6) id OAA12309; Fri, 8 Oct 1999 14:29:54 -0700 (PDT) Date: Fri, 8 Oct 1999 14:29:54 -0700 (PDT) Message-Id: <199910082129.OAA12309@brb.isi.edu> To: ccs99@isi.edu Subject: UPDATE: ACM CCS'99 (Rump Session, Registration and Program) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk 6th ACM Conference on Computer and Communications Security November 1-4, 1999 Kent Ridge Digital Labs Singapore Conference Home Page: http://www.isi.edu/ccs99/ Registration: http://homex.s1.net.sg/user/jyzhou/ccs99.html E A R L Y R E G I S T R A T I O N D E A D L I N E !!! ------------------------------------------------------------------------- Early registratuion deadline is approaching fast! To obtain a lower registration fee, please register on or before October 10. ------------------------------------------------------------------------- R U M P S E S S I O N For the first time, there will be a rump session at the upcoming ACM CCS. The rump session is intended to be an informal venue for short presentations on recent results, work in progress, and other topics of interest to the research community. This includes presentations that are not purely technical in nature. The rump session will take place on Wednesday afternoon, November 3. Those wishing to give a talk at the rump session must submit a short abstract, no more than one page long, to the rump session chair, Giuseppe Ateniese. Submissions can be emailed in ASCII only (one page at most) to ateniese@cs.jhu.edu by Thursday, October 28, or handed in person at the conference before 5pm on Tuesday, November 2. All talks will be at most 5 minutes long. ------------------------------------------------------------------------- PROGRAM UPDATE: panel on November 3 Panel topic: On The Importance Of Provable Security Panel Chair: Dan Boneh, Stanford Panelists: - Christian Cachin, IBM Research Zurich - Cynthia Dwork, IBM Research Almaden - Ari Juels, RSA Labs - Guillaume Poupard, ENS ------------------------------------------------------------------------- ========================================================================== 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 Oct 13 10:45:22 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26109 for ; Wed, 13 Oct 1999 10:45:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA16395 for ietf-cat-wg-out720680; Wed, 13 Oct 1999 06:50:40 -0700 (PDT) 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 GAA16390 for ; Wed, 13 Oct 1999 06:50:36 -0700 (PDT) Received: from maildt.cubis.de by MIT.EDU with SMTP id AA06898; Wed, 13 Oct 99 09:50:25 EDT Received: from secunet.de (huehnlein.cubis.de [10.0.133.71]) by mail-int.cubis.de (8.9.3/8.9.3) with ESMTP id PAA24822; Wed, 13 Oct 1999 15:34:34 +0200 (MET DST) Message-Id: <380497A5.B10453AB@secunet.de> Date: Wed, 13 Oct 1999 15:31:01 +0100 From: Detlef =?iso-8859-1?Q?H=FChnlein?= Organization: Secunet AG - The Trust Company X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en,de-DE Mime-Version: 1.0 To: cqre@secunet.de Subject: CQRE'99 - Call for Participation Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.Stanford.EDU id GAA16391 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Dear Listmembers! Sorry for crossposting. The Call for Participation below might be of interest for you. To register, please visit http://www.cqre.net . You might want to note that the early bird registration period already expires on Oct. 22, which is less than two weeks from now. I would be looking forward to seeing you at CQRE. Best regards Detlef Huehnlein *************************************************************** Call for Participation CQRE [Secure] Congress & Exhibition Duesseldorf, Germany, Nov. 30 - Dec. 2 1999 --------------------------------------------------------------- provides a new international forum covering most aspects of information security with a special focus to the role of information security in the context of rapidly evolving economic processes. --------------------------------------------------------------- Part I covers stratecial issues of IT-Security while Part II will discuss more technical issues, like - SmartCard Technology / Security - Public Key Infrastructures - Network Security - Mobile Security - Intrusion Detection - Enterprise Security - Security Design - Electronic Payment - Electronic Commerce - Cryptography - Espionage - Interoperability - Biometrics - Risk Management - Signature Laws - Training / Awareness for example. ---------------------------------------------------------------- CQRE-PROGRAM: ---------------------------------------------------------------- Part I - Strategical Aspects Tuesday, November 30, 1999 ---------------------------------------------------------------- 09.30 Opening: Chairman Paul Arlman, Federation of European Stock Exchange 09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG "A corporate group in transition - how Deutsche Telekom is preparing for the digital economy." 10.15 Keynote Jean-Paul Figer, Cap Gemini S.A "Brave Digital World? The balance between chances and risks for the information society." 10:45 Coffee 11:15 Five parallel Workshops: Workshop 1 - "Values & standards" (Prof.Dr. Gertrud Höhler) Workshop 2 - "Law & regulation" (Klaus-Dieter Scheurle) Workshop 3 - "Strategy & success" Workshop 4 - "Role of technology" (Karl-Heinz Streibich) Workshop 5 - "Monitoring & control" (Piet van Reenen) 12.45 Lunch 14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon "Network Citizen - what does the networked citizen and consumer stand to gain and lose?" 15.15 Workshop results (Moderator Paul Arlman) 15.45 Coffee 16.00 Summary / 10-point-programme 17.00 Happy Hour 18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF) ---------------------------------------------------------------- Part II - Technical Aspects: Wednesday, December 1, 1999 ---------------------------------------------------------------- 09.00 R.Baumgart: Welcome 09.15 B.Schneier: "Attack trees - a novel methodology for risk management." 10.00 Refreshments 10.15 Four parallel tracks: I. Risk Management: D.Povey: "Developing Electronic Trust Policies Using a Risk Management Model" J.Hopkinson: "Guidelines for the Management of IT-Security" II. Security Design: L.Romano, A.Mazzeo and N.Mazzocca: "SECURE: a simulation tool for PKI design" D.Basin: "Lazy Infinite State Analysis of Security Protocols" III. Enterprise Security: P.Kunz: "The case for IT-Security" W.Wedl: "Integrated Enterprise Security - Examples conducted in large European Enterprises" B.Esslinger: "The PKI development of Deutsche Bank" IV. Tutorial: H.Handschuh: "Cryptographic SmartCards" 11.45 Lunch 13.15 S.Senda: "Electronic Cash in Japan" 14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi: "Panel: Electronic payments where do we go from here?" 15.00 Four parallel tracks: I. SmartCard Issues R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based Personal Card Assistant" M.Nyström, J.Brainard: "An X.509-Compatible Syntax for Compact Certificates" II. Applications D.Hühnlein, J.Merkle: "Secure and cost efficent electronic stamps" K.Sako: "Implementation of a Digital Lottery Server on WWW" III. PKI-experiences J.Lopez, A.Mana, J.J.Ortega: "CerteM: Certification System Based on Electronic Mail Service Structure" K.Schmeh: "A method for developing PKI models" J.Hughes: "The Realities of PKI Inter-Operability IV. Tutorial S.Kent: "How many Certification Authorities are Enough?" 16.45 J.J.Quisquater: "Attacks on SmartCards and Countermeasures" 17.00 M.Kuhn: "How tamper-resistant are todays SmartCards?" 18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann: "Secure SmartCards - Fact or Fiction" 19.00 Get-together with music (4 to the bar) and CQRE - Speakers corner - rump session ---------------------------------------------------------------- Part II - Technical Aspects: Thursday, December 2, 1999 ---------------------------------------------------------------- 09.00 R.Baumgart : Good morning 09.15 P.Landrock: Mobile Commerce 10.15 Four parallel tracks: I. Mobile Security M.Borchering: "Mobile Security - an Overview of GSM, SAT and WAP" S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of Authentication Data in Third Generation Mobile Phone Networks" II. Cryptography J.P. Seifert, N.Howgrave: "Extending Wiener`s attack in the Presence of many decrypting exponents" S.Micali, L.Reyzin: "Improving The Exact Security of Fiat-Shamir Signature Schemes" III. Network Security C.Yuen-yan: "On Privacy Issues of Internet Access Services via Proxy Servers" Jorge Davila, Javier Lopez and Rene Peralta: "VPN solutions in diverse layers of the TCP/IP stack" B.Schneier, Mudge, D.Wagner: "Cryptanalysis of Microsofts PPTP Authentification Extensions (MS-CHAPv2)" IV. Tutorial I.Winkler: "How to fight the inner enemy" 12.00 J.S. Coron: "On the security of RSA padding" 12.45 Lunch 14.15 Four parallel tracks: I. PKI A.Young, M.Yung: "Auto-Recoverable Auto-Certifiable Cryptosystems (a survey)" II. Intrusion Detection D.Bulatovic, D.Velasevic: "A Distributed Intrusion Detection System based on Bayesian Alarm Networks" III. Espionage M.Fink: "Espionage - State of the Art and Countermeasures" W.Haas: "Informational Self Defense" IV. Tutorial A.Philip: "Secure E-business" 15.00 S.Kent: "Security for Certification Authorities - A system approach" 16.00 Four parallel tracks: I. Interoperability S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters: "Interopreability Characteristics of S/MIME Products" M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA Project: The Solution to the Interoperability Problems between the X.509 and EDIFACT Public Key Infrastructures" II. Biometrics H.Arendt: "Biometrics - State of the Art" A.P.Gonzales-Marcos, C.Sanchez-Avila, R.Sanchez-Reillo: "Multiresolution Analysis and Geometric Measure for Biometric Identification" III. Signature Laws Workshop - Leader, K.Keus: "German Signature Act - Expiriences made for Europe?" IV. Tutorial J.Massey: "Cryptography at a glance" 17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi: "Panel: Perspectives for a global signature law" 18.30 R.Baumgart: Closing Remarks ========================================================================== 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 Oct 13 18:02:01 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05212 for ; Wed, 13 Oct 1999 18:02:00 -0400 (EDT) Received: by lists.Stanford.EDU (8.9.3/8.9.3) id OAA10560 for ietf-cat-wg-out720680; Wed, 13 Oct 1999 14:35:11 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA10552 for ; Wed, 13 Oct 1999 14:35:07 -0700 (PDT) From: walczykj@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA74582; Wed, 13 Oct 1999 17:34:03 -0400 Received: from d54mta06.raleigh.ibm.com (d54mta06.raleigh.ibm.com [9.67.228.38]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.05) with SMTP id RAA36474; Wed, 13 Oct 1999 17:34:25 -0400 Received: by d54mta06.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256809.007684BF ; Wed, 13 Oct 1999 17:34:32 -0400 X-Lotus-FromDomain: IBMUS To: linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU Message-ID: <85256809.007680CC.00@d54mta06.raleigh.ibm.com> Date: Wed, 13 Oct 1999 17:34:17 -0400 Subject: IDUP-GSS-API C-Bindings? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Is there an IDUP-GSS-API C-bindings RFC/Draft or plan? Specifically, in RFC2479, I'm wondering about input paramter format of the Per-IDU calls (Section 2.3). I understand there are Parameter Bundles (such as the "IDUP_SE Parameter Bundles" in section 2.3.2.2), but these do not seem specific enough to ensure interoperabiltiy. Thanks in advance, John ========================================================================== 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 Oct 14 07:24:04 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25380 for ; Thu, 14 Oct 1999 07:24:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA04328 for ietf-cat-wg-out720680; Thu, 14 Oct 1999 03:52:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA04315 for ; Thu, 14 Oct 1999 03:52:30 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24340; Thu, 14 Oct 1999 06:51:57 -0400 (EDT) Message-Id: <199910141051.GAA24340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-srpgm-00.txt Date: Thu, 14 Oct 1999 06:51:56 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The Secure Remote Password GSS-API Mechanism (SRPGM) Author(s) : K. Burdis Filename : draft-ietf-cat-srpgm-00.txt Pages : 27 Date : 13-Oct-99 This document describes a password-based low-infrastructure GSS-API mechanism based on the Secure Remote Password protocol and the existing Simple Public Key Mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-srpgm-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-srpgm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-srpgm-00.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: <19991013100851.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-srpgm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-srpgm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991013100851.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 Fri Oct 15 15:34:08 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20781 for ; Fri, 15 Oct 1999 15:34:08 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA05603 for ietf-cat-wg-out720680; Fri, 15 Oct 1999 11:49:31 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id LAA05592 for ; Fri, 15 Oct 1999 11:49:27 -0700 (PDT) Received: id OAA08427; Fri, 15 Oct 1999 14:44:07 -0400 Received: by gateway id <43HHN36S>; Fri, 15 Oct 1999 14:46:47 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10171566D@sothmxs06.entrust.com> From: Carlisle Adams To: "'walczykj@us.ibm.com'" Cc: linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU Subject: RE: IDUP-GSS-API C-Bindings? Date: Fri, 15 Oct 1999 14:46:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hi John, > ---------- > From: walczykj@us.ibm.com[SMTP:walczykj@us.ibm.com] > Sent: Wednesday, October 13, 1999 5:34 PM > To: linn@rsa.com; ietf-cat-wg@lists.stanford.edu > Subject: IDUP-GSS-API C-Bindings? > > Is there an IDUP-GSS-API C-bindings RFC/Draft or plan? Specifically, > in > RFC2479, I'm wondering about input paramter format of the Per-IDU calls > (Section > 2.3). I understand there are Parameter Bundles (such as the "IDUP_SE > Parameter Bundles" in section 2.3.2.2), but these do not seem specific > enough > to ensure interoperabiltiy. The question of C-bindings for IDUP-GSS-API has come up several times over the years. For a while there was an Internet Draft on this, but those maintaining the draft got tied up with other projects and the specification did not reach sufficient stability to be frozen as an RFC. The latest version of that draft expired quite some time ago. Would you have any interest in (and availability for) resurrecting a draft on this? Carlisle. ========================================================================== 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 Oct 15 16:12:50 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21428 for ; Fri, 15 Oct 1999 16:12:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA07889 for ietf-cat-wg-out720680; Fri, 15 Oct 1999 12:35:37 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA07884 for ; Fri, 15 Oct 1999 12:35:34 -0700 (PDT) From: hemsath@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA329384; Fri, 15 Oct 1999 15:34:47 -0400 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.05) with SMTP id PAA49314; Fri, 15 Oct 1999 15:35:07 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525680B.006B99FF ; Fri, 15 Oct 1999 15:35:17 -0400 X-Lotus-FromDomain: IBMUS To: Carlisle Adams cc: walczykj@us.ibm.com, linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU, davismc@us.ibm.com Message-ID: <8525680B.006B9848.00@d54mta08.raleigh.ibm.com> Date: Fri, 15 Oct 1999 14:33:18 -0500 Subject: RE: IDUP-GSS-API C-Bindings? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Carlisle. I would be interested (and available) to work on this. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQA/AwUBOAeB8Al0soYoviM2EQIu5gCgkghGmp/3JR5PtDdVKXeo2qNfqzgAnje4 t5DdrJM3kWpO8zIupBDOR73b =inSd -----END PGP SIGNATURE----- David K. Hemsath, Team Lead (Security) SecureWay SysMgmt/Architecture/Standards IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA Tel.: +1(512)838-3618 T/L 678; Fax: 0156 Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com hemsath@us.ibm.com Carlisle Adams on 10/15/1999 01:46:38 PM To: John H Walczyk III/Raleigh/IBM@IBMUS cc: linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU Subject: RE: IDUP-GSS-API C-Bindings? Hi John, > ---------- > From: walczykj@us.ibm.com[SMTP:walczykj@us.ibm.com] > Sent: Wednesday, October 13, 1999 5:34 PM > To: linn@rsa.com; ietf-cat-wg@lists.stanford.edu > Subject: IDUP-GSS-API C-Bindings? > > Is there an IDUP-GSS-API C-bindings RFC/Draft or plan? Specifically, > in > RFC2479, I'm wondering about input paramter format of the Per-IDU calls > (Section > 2.3). I understand there are Parameter Bundles (such as the "IDUP_SE > Parameter Bundles" in section 2.3.2.2), but these do not seem specific > enough > to ensure interoperabiltiy. The question of C-bindings for IDUP-GSS-API has come up several times over the years. For a while there was an Internet Draft on this, but those maintaining the draft got tied up with other projects and the specification did not reach sufficient stability to be frozen as an RFC. The latest version of that draft expired quite some time ago. Would you have any interest in (and availability for) resurrecting a draft on this? Carlisle. ========================================================================== 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 Oct 15 17:30:36 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22122 for ; Fri, 15 Oct 1999 17:30:35 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA12784 for ietf-cat-wg-out720680; Fri, 15 Oct 1999 14:01:29 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id OAA12748 for ; Fri, 15 Oct 1999 14:01:21 -0700 (PDT) Received: id QAA11481; Fri, 15 Oct 1999 16:55:38 -0400 Received: by gateway id <43HHNP8K>; Fri, 15 Oct 1999 16:58:19 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B101715671@sothmxs06.entrust.com> From: Carlisle Adams To: "'hemsath@us.ibm.com'" Cc: walczykj@us.ibm.com, linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU, davismc@us.ibm.com Subject: RE: IDUP-GSS-API C-Bindings? Date: Fri, 15 Oct 1999 16:58:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hi Dave, Good to hear from you again! > ---------- > From: hemsath@us.ibm.com[SMTP:hemsath@us.ibm.com] > Sent: Friday, October 15, 1999 3:33 PM > To: Carlisle Adams > Cc: walczykj@us.ibm.com; linn@rsa.com; ietf-cat-wg@lists.Stanford.EDU; > davismc@us.ibm.com > Subject: RE: IDUP-GSS-API C-Bindings? > > Hello Carlisle. I would be interested (and available) to work on > this. That sounds great. I will not have much time to contribute to this effort, but I should be available to answer any questions or to clarify obscure sections of the API specification (if there are any :-) Carlisle. > Carlisle Adams on 10/15/1999 01:46:38 PM > > To: John H Walczyk III/Raleigh/IBM@IBMUS > cc: linn@rsa.com, ietf-cat-wg@lists.Stanford.EDU > Subject: RE: IDUP-GSS-API C-Bindings? > > Hi John, > > > ---------- > > From: walczykj@us.ibm.com[SMTP:walczykj@us.ibm.com] > > Sent: Wednesday, October 13, 1999 5:34 PM > > To: linn@rsa.com; ietf-cat-wg@lists.stanford.edu > > Subject: IDUP-GSS-API C-Bindings? > > > > Is there an IDUP-GSS-API C-bindings RFC/Draft or plan? > Specifically, > > in > > RFC2479, I'm wondering about input paramter format of the Per-IDU calls > > (Section > > 2.3). I understand there are Parameter Bundles (such as the "IDUP_SE > > Parameter Bundles" in section 2.3.2.2), but these do not seem specific > > enough > > to ensure interoperabiltiy. > > The question of C-bindings for IDUP-GSS-API has come up several times over > the years. For a while there was an Internet Draft on this, but those > maintaining the draft got tied up with other projects and the > specification > did not reach sufficient stability to be frozen as an RFC. The latest > version of that draft expired quite some time ago. > > Would you have any interest in (and availability for) resurrecting a draft > on this? > ========================================================================== 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 Oct 19 14:23:29 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28618 for ; Tue, 19 Oct 1999 14:23:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA25803 for ietf-cat-wg-out720680; Tue, 19 Oct 1999 10:47:04 -0700 (PDT) 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 KAA25796 for ; Tue, 19 Oct 1999 10:47:01 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 19 Oct 1999 17:45:48 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA07493 for ; Tue, 19 Oct 1999 13:41:24 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 19 Oct 1999 13:48:38 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: Towards Java binding disposition [Was: RE: Next steps for CAT] Date: Tue, 19 Oct 1999 13:53:40 -0400 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 So far on this thread, I've seen one message advocating decoupling JGSS from SPI and progressing the high-level JGSS document independent of SPI discussion, and another message suggesting that SPI topics be discussed at the DC meeting as possible input to revising JGSS and SPI in the hopes that successor versions can progress in parallel following the meeting. Absent further comments, it's hard to assess a clear consensus of where the group stands. More discussion, anyone? --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 Oct 19 21:19:40 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05050 for ; Tue, 19 Oct 1999 21:19:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA22080 for ietf-cat-wg-out720680; Tue, 19 Oct 1999 17:50:11 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id RAA22075 for ; Tue, 19 Oct 1999 17:50:09 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA12256 for ; Tue, 19 Oct 1999 17:50:08 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Tue, 19 Oct 1999 17:50:07 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762352@pikachu.wrq.com> From: Joe Salowey To: "'CAT-WG List'" Subject: RE: Towards Java binding disposition [Was: RE: Next steps for CAT ] Date: Tue, 19 Oct 1999 17:50:06 -0700 X-MS-TNEF-Correlator: <86EDBD151558D311BB5700508B2E03FC762352@pikachu.wrq.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF1A95.0D673982" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF1A95.0D673982 Content-Type: text/plain; charset="iso-8859-1" I vote against trying to progress both documents at the same time. I think it is important to have separation between the JGSSAPI document and any SPI document. This is because first and foremost the API must be defined. The SPI layer is an implementation detail that it does not need to (and probably should not) be mandated at this point. It is possible to implement JGSSAPI provider without any SPI at all. It is prudent to consider the possible snafus involved with creating an SPI layer, but getting bogged down in one particular implementation will cause delays and may adversely affect the genericness of the API. I suggest discussing the SPI related issues that either make an SPI layer impossible or extremely unpleasant to implement on this list. I've been away from this for a while, so if someone could post these issues that would help (Michael, I think you had a list of issues). If any outstanding issues are catastrophic to SPI development then they should be discussed and resolved. -Joe -----Original Message----- From: Linn, John [mailto:jlinn@rsasecurity.com] Sent: Tuesday, October 19, 1999 10:54 AM To: 'CAT-WG List' Subject: Towards Java binding disposition [Was: RE: Next steps for CAT] So far on this thread, I've seen one message advocating decoupling JGSS from SPI and progressing the high-level JGSS document independent of SPI discussion, and another message suggesting that SPI topics be discussed at the DC meeting as possible input to revising JGSS and SPI in the hopes that successor versions can progress in parallel following the meeting. Absent further comments, it's hard to assess a clear consensus of where the group stands. More discussion, anyone? --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 ------_=_NextPart_000_01BF1A95.0D673982 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IggAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzwcKABMAEQAyAAYAAgA+AQEggAMADgAAAM8HCgAT ABEAMgAGAAIAPgEBCYABACEAAAA4M0E0MjNENjYyODZEMzExQkI1ODAwNTA4QjJFMDNGQwABBwEE gAEAQwAAAFJFOiBUb3dhcmRzIEphdmEgYmluZGluZyBkaXNwb3NpdGlvbiBbV2FzOiBSRTogTmV4 dCBzdGVwcyBmb3IgQ0FUXQDiFgENgAQAAgAAAAIAAgABA5AGABwMAAA1AAAAAwDeP69vAAADAAGA CCAGAAAAAADAAAAAAAAARgAAAABShQAAPBgAAB4AAoAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAAB AAAABAAAADguNQALAAOACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMABIAIIAYAAAAAAMAA AAAAAABGAAAAAAGFAAAAAAAACwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALAAaACCAG AAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAA AwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAmACCAGAAAAAADAAAAAAAAARgAAAAAY hQAAAAAAAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAA AADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUA AAEAAAABAAAAAAAAAAsADYALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwAOgAsgBgAAAAAA wAAAAAAAAEYAAAAABYgAAAAAAAACAQkQAQAAAO8FAADrBQAAbgkAAExaRnWtfaLTAwAKAHJjcGcx MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFCzCwkBZDM2FlALp2MBMCAgSSB2bw6wIGGK ZwtxcwVAdHJ5C4DiZx4QbyBwA2AJwQQRAQbgdGggZG9jdVcHgAIwBCBhHgFoHYBzzmEHgB4QB3Eu IB0hH3BxC4BrIGkFQAQAIeBtvnAXwQBwHgEeoBPgdiCRdmUKsSBAaQIgH0AUIHcDCeEgY0pHU1NB UKcdMB+mHZBuZCXheQYAeyU5IUFUIaAiMR8xBZBh4nUUECBmaRQAJdQCEN8YIARgHfIggSUibSgg BUD/JCAfkAEQC4AJgCczHYAmcr0LYHkSgSIhA5EiUWwpMP8f8SPEAQABkAMRH3AgQSHx+x+gB5Fu HWAukAngJhAekVYoJfIewWIBoGwmUHPaaAhgbCYQLqEpKlIDgf5kIEAvASBDIiEicAuAJyLuSSID InAEEGkCYCDhHqCnLHck1x7BdmkEgSAD8L8fcAhgJdImVCBBB0BsMpj8cnUBACLEBaAAgTVSIHJh MydzbmFmKCAh4G79HVBsI0AmEDWSOCAYICPBtx5hA5ErdywfQDXhZxQguzsjBuBnPJAmEB+gdyxR /wOgAiA44QrAIQAfwAtgK/H/LIwD8DbQOCAoEwEAK7EsIucmEADAJlBhZCNAFAEwEX05sGYFkCBU PJAq0AUQY/Mq0AQRb2YphiFACqIKhLMKgB0wc3U9MR3xZAQA/x/AM0EeYitFGCALYDGCBAF3ClAE IC3TZTWhEoEAwGv/HYE7iSJDM0UFsQ7BKSFB4vR1biyRYSCwIsQz6CPx7THzbAQAMoMnI0EkICRx /GF3QVEDUjHkKQEdkDWA9yGgLKA8MHMzwUOgUAAHgH8+AgWgMHIzISBTKDFHanfTMGMggGxwL1BN DeAT4PdAoDwwIXZ5CGAjESYRTSP7Q4JHZCkhQkOgJjI10R3w/yXxHlJHZQrAUMEgQEuAHiC0b3Ah oGMegiZzZSNA/RewcCWjIHEkgzAnKmJFxC8xkiYBHwE6My5EWi1KXy5gRFpeP10mYBJPBRBn3wuA B0AF0B8RHaBlYBNEVKJGA2E6IEwLgG48MHVdoGgDoFsAwAMQHpA69mpNMGKQQBQAS4AFkAhxyHR5 LgWgbV1EVAZgWwIwYlBUR5ExYHk8ME/nQmAv0BKBMTk8MGbQZyChZsAwOjU0EMBNRFQCVGOAICdD QVQtLFdHYmEd8CdlBXVivmpCUWWhPZALEQQgSiMw/U9wYguAVyNFsTMhIfAj4sxbV0uAYlBSRWJQ B8B/DtEd8COATxRokWT1RFpTvR6gZgrBTLYfcDrxZFPh/02yFBAkcT4CB4FhIkFyH7D7OxQFgnUL UB5SJOJOg2UFHzZiL4Qe80YmIaBnaC3/LKBZgXNkJWdrISOACfA3s/9DkSZxRFRFtgIgPDAl9B9h f0hicaVFNUYkIEEmch6QcDcN4CfCW1p0RFQgckRD33GBFCA7MzMJC4BwNeEekf8YIDUwRhNzcyXy JnI90XWjz1iQR6VEVEUwY2MfEQWx/0GiI+EEICgAA6Aexz3RI5L/NtB2YQIQNtA9kEYmfmUhQfxB YhQQAjBEVDnAACBIUu9kwR/jPDAh8CcEIBPhLxPvS4AUEAQRT3BjS2GIYgCA/wnwRTBDc0+QBJAg 4UKiA2DXcwCCpVbycyFBTSkRRad3eXRUgCrQP19cY6BEWj3/kN+R75L/lA+UY2flJ3Jxlv9OUDMD MYJwMQhgdgBGVCKh/ykBJhAoACJgOdFjMh5STTL/gqUEkEGhVhRUggPxl7EeoP9LMEUwh1AFASph TpiZGk/h33fBIGJEVHGWBuBkVpFDoC4im7oIkAAwLVghLXdsZyIeggDAaphhA3Bv3kBNMo1QVuKY Ui4JgAxwBURjfaPQAB4AcAABAAAAPwAAAFRvd2FyZHMgSmF2YSBiaW5kaW5nIGRpc3Bvc2l0aW9u IFtXYXM6IFJFOiBOZXh0IHN0ZXBzIGZvciBDQVRdAAACAXEAAQAAABsAAAABvxpio84RmXWqhlUR 04j/AFCLMYrKAAto3sAAAwAuAAAAAAALACsAAAAAAAsAAgABAAAAHgBCEAEAAABFAAAAPEQxMDQx NTAwOThFNkQxMTFCNzgzMDAwMEY4RDkwQUU4QUU1ODhFQGV4bmEwMi5zZWN1cml0eWR5bmFtaWNz LmNvbT4AAAAAAwD9P+QEAABAADkAkIw9DZUavwEDAPE/CQQAAB4AMUABAAAABQAAAEpPRVMAAAAA AwAaQAAAAAAeADBAAQAAAAUAAABKT0VTAAAAAAMAGUAAAAAAAwAmAAAAAAADADYAAAAAAAsA8hAB AAAAAwCAEP////8CAUcAAQAAAC4AAABjPVVTO2E9IDtwPVdSUTtsPVBJS0FDSFUtOTkxMDIwMDA1 MDA2Wi0xNTA4MjUAAAACAfk/AQAAAEQAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089 V1JRL09VPVNFQVRUTEUvQ049UkVDSVBJRU5UUy9DTj1KT0VTAB4A+D8BAAAADAAAAEpvZSBTYWxv d2V5AB4AOEABAAAABQAAAEpPRVMAAAAAAgH7PwEAAABEAAAAAAAAANynQMjAQhAatLkIACsv4YIB AAAAAAAAAC9PPVdSUS9PVT1TRUFUVExFL0NOPVJFQ0lQSUVOVFMvQ049Sk9FUwAeAPo/AQAAAAwA AABKb2UgU2Fsb3dleQAeADlAAQAAAAUAAABKT0VTAAAAAEAABzBkTDsNlRq/AUAACDCCOWcNlRq/ AR4APQABAAAABQAAAFJFOiAAAAAAHgAdDgEAAAA/AAAAVG93YXJkcyBKYXZhIGJpbmRpbmcgZGlz cG9zaXRpb24gW1dhczogUkU6IE5leHQgc3RlcHMgZm9yIENBVF0AAB4ANRABAAAAOQAAADw4NkVE QkQxNTE1NThEMzExQkI1NzAwNTA4QjJFMDNGQzc2MjM1MkBwaWthY2h1LndycS5jb20+AAAAAAsA KQAAAAAACwAjAAAAAAADAAYQPp5UBgMABxBtBgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAA AElWT1RFQUdBSU5TVFRSWUlOR1RPUFJPR1JFU1NCT1RIRE9DVU1FTlRTQVRUSEVTQU1FVElNRUlU SElOS0lUSVNJTVBPUlRBTlRUT0hBVkVTRVBBUkFUSU9OQkVUV0VFTlRIRUoAAAAAAgF/AAEAAAA5 AAAAPDg2RURCRDE1MTU1OEQzMTFCQjU3MDA1MDhCMkUwM0ZDNzYyMzUyQHBpa2FjaHUud3JxLmNv bT4AAAAApwo= ------_=_NextPart_000_01BF1A95.0D673982-- ========================================================================== 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 Oct 19 22:04:20 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06421 for ; Tue, 19 Oct 1999 22:04:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA24511 for ietf-cat-wg-out720680; Tue, 19 Oct 1999 18:33:20 -0700 (PDT) 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 SAA24506 for ; Tue, 19 Oct 1999 18:33:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA18997 for ; Tue, 19 Oct 1999 18:33:17 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.125.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA04402 for ; Tue, 19 Oct 1999 18:33:15 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA23757 for ; Tue, 19 Oct 1999 18:33:12 -0700 (PDT) Message-Id: <199910200133.SAA23757@taller.eng.sun.com> Date: Tue, 19 Oct 1999 18:33:13 -0700 (PDT) From: Mayank Upadhyay Reply-To: Mayank Upadhyay Subject: RE: Towards Java binding disposition [Was: RE: Next steps for CAT ] To: ietf-cat-wg@lists.Stanford.EDU MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TEwIZxvEfC26f3pjqLWphw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I agree with the opinion expressed by Joe and Jack on this. Jack and I will probably send out the new version of the API tomorrow. We've also kept Michael up-to-date on the changes and haven't come across any stumbling blocks that might cause changes in the API to accomodate the SPI. -Mayank >From: Joe Salowey >To: "'CAT-WG List'" >Subject: RE: Towards Java binding disposition [Was: RE: Next steps for CAT ] >X-MS-TNEF-Correlator: <86EDBD151558D311BB5700508B2E03FC762352@pikachu.wrq.com> >MIME-Version: 1.0 > >I vote against trying to progress both documents at the same time. I think >it is important to have separation between the JGSSAPI document and any SPI >document. This is because first and foremost the API must be defined. The >SPI layer is an implementation detail that it does not need to (and probably >should not) be mandated at this point. It is possible to implement JGSSAPI >provider without any SPI at all. It is prudent to consider the possible >snafus involved with creating an SPI layer, but getting bogged down in one >particular implementation will cause delays and may adversely affect the >genericness of the API. > >I suggest discussing the SPI related issues that either make an SPI layer >impossible or extremely unpleasant to implement on this list. I've been >away from this for a while, so if someone could post these issues that would >help (Michael, I think you had a list of issues). If any outstanding issues >are catastrophic to SPI development then they should be discussed and >resolved. > >-Joe > > > > > >-----Original Message----- >From: Linn, John [mailto:jlinn@rsasecurity.com] >Sent: Tuesday, October 19, 1999 10:54 AM >To: 'CAT-WG List' >Subject: Towards Java binding disposition [Was: RE: Next steps for CAT] > > >So far on this thread, I've seen one message advocating decoupling JGSS from >SPI and progressing the high-level JGSS document independent of SPI >discussion, and another message suggesting that SPI topics be discussed at >the DC meeting as possible input to revising JGSS and SPI in the hopes that >successor versions can progress in parallel following the meeting. Absent >further comments, it's hard to assess a clear consensus of where the group >stands. More discussion, anyone? > >--jl > >===================================================================== ===== >This message was posted through the Stanford campus mailing list >server. If you wish to unsubscribe from this mailing list, send the >message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 20 07:26:20 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25143 for ; Wed, 20 Oct 1999 07:26:19 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA16426 for ietf-cat-wg-out720680; Wed, 20 Oct 1999 03:56:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA16421 for ; Wed, 20 Oct 1999 03:56:05 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24086; Wed, 20 Oct 1999 06:56:02 -0400 (EDT) Message-Id: <199910201056.GAA24086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com, ietf-cat-wg@lists.Stanford.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-04.txt Date: Wed, 20 Oct 1999 06:56:01 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A GSS-API Authentication Method for IKE Author(s) : D. Piper Filename : draft-ietf-ipsec-isakmp-gss-auth-04.txt Pages : 11 Date : 19-Oct-99 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. For a list of changes since the previous version of this document, please see Section 4. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-04.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-ipsec-isakmp-gss-auth-04.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-ipsec-isakmp-gss-auth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019135748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019135748.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 Wed Oct 20 07:28:01 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25222 for ; Wed, 20 Oct 1999 07:28:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA16452 for ietf-cat-wg-out720680; Wed, 20 Oct 1999 03:57:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA16446 for ; Wed, 20 Oct 1999 03:57:34 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24288; Wed, 20 Oct 1999 06:57:33 -0400 (EDT) Message-Id: <199910201057.GAA24288@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-brezak-win2k-krb-rc4-hmac-00.txt Date: Wed, 20 Oct 1999 06:57:32 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Windows 2000 RC4-HMAC Kerberos encryption type Author(s) : M. Swift, J. Brezak Filename : draft-brezak-win2k-krb-rc4-hmac-00.txt Pages : 6 Date : 19-Oct-99 The Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES based encryption types. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong crypto (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. The Windows 2000 implementation of Kerberos contains new encryption and checksum types for two reasons: for export reasons early in the development process, 56 bit DES encryption could not be exported, and because upon upgrade from Windows NT 4.0 to Windows 2000, accounts will not have the appropriate DES keying material to do the standard DES encryption. Furthermore, 3DES is not available for export, and there was a desired to use a single flavor of encryption in the product for both US and international products. As a result, there are two new encryption types and one new checksum type introduced in Windows 2000. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brezak-win2k-krb-rc4-hmac-00.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-brezak-win2k-krb-rc4-hmac-00.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-brezak-win2k-krb-rc4-hmac-00.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: <19991019140032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brezak-win2k-krb-rc4-hmac-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-brezak-win2k-krb-rc4-hmac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019140032.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 Wed Oct 20 09:43:38 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01583 for ; Wed, 20 Oct 1999 09:43:37 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA18661 for ietf-cat-wg-out720680; Wed, 20 Oct 1999 06:17:00 -0700 (PDT) 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 GAA18656 for ; Wed, 20 Oct 1999 06:16:57 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 20 Oct 1999 13:15:44 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 JAA00786 for ; Wed, 20 Oct 1999 09:11:19 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Oct 1999 09:18:35 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Subject: CAT-WG DC Agenda, Draft 1 Date: Wed, 20 Oct 1999 09:23:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT-WG DC Agenda, Draft 1 as of 20 October 1999 Session on Monday, 8 November, 0930-1130 0930-0935: Opening remarks 0935-0950: Java GSS SPI Issues (Michael Smith) 0950-1015: Java GSS High-Level Specification (Jack Kabat) 1015-1035: Kerberos-Revisions (Cliff Neuman) 1035-1050: Kerberos PK-INIT 1050-1055: Kerberos DNS-SRV (Jeffrey Altman/Ken Hornstein) 1055-1100: GSS-Easy (Denis Pinkas) 1100-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 Thu Oct 21 07:16:14 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14713 for ; Thu, 21 Oct 1999 07:16:13 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09502 for ietf-cat-wg-out720680; Thu, 21 Oct 1999 03:50:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09487 for ; Thu, 21 Oct 1999 03:49:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13553; Thu, 21 Oct 1999 06:49:56 -0400 (EDT) Message-Id: <199910211049.GAA13553@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-gsseasy-01.txt Date: Thu, 21 Oct 1999 06:49:56 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : The GSS-API-Easy Mechanism Author(s) : J. Lebastard, D. Pinkas Filename : draft-ietf-cat-gsseasy-01.txt Pages : 16 Date : 20-Oct-99 This document provides a description of a GSS-API mechanism usable through the Generic Security Service Application Program Interface (as specified in Internet-Drafts [GSSV2] and [GSSV2-C]) that is easy to deploy since it does not rely on the existence of a security infrastructure nor the existence of a security server. The GSS-API-Easy mechanism enables unilateral and mutual authentication of peers as well as per-message protections. It is based on the use of an identifier and a SharedSecret shared between the client and the server and uses a protocol where the passphrase (i.e. a long phrase used like a password) is never sent in the clear. In addition, this document describes a protocol to change the SharedSecret. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-gsseasy-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-gsseasy-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-gsseasy-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: <19991020133323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gsseasy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gsseasy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991020133323.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 Fri Oct 22 07:21:51 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06867 for ; Fri, 22 Oct 1999 07:21:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA00774 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 03:54:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA00759 for ; Fri, 22 Oct 1999 03:54:29 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05627; Fri, 22 Oct 1999 06:54:24 -0400 (EDT) Message-Id: <199910221054.GAA05627@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-krb-dns-locate-01.txt Date: Fri, 22 Oct 1999 06:54:23 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Distributing Kerberos KDC and Realm Information with DNS Author(s) : K. Hornstein, J. Altman Filename : draft-ietf-cat-krb-dns-locate-01.txt Pages : 6 Date : 21-Oct-99 Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- col [RFC????] describe any mechanism for clients to learn critical configuration information necessary for proper operation of the pro- tocol. Such information includes the location of Kerberos key dis- tribution centers or a mapping between DNS domains and Kerberos realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-krb-dns-locate-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-krb-dns-locate-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-krb-dns-locate-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: <19991021142132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-krb-dns-locate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-krb-dns-locate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142132.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 Fri Oct 22 07:25:24 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06952 for ; Fri, 22 Oct 1999 07:25:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA00815 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 03:54:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA00794 for ; Fri, 22 Oct 1999 03:54:38 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05656; Fri, 22 Oct 1999 06:54:36 -0400 (EDT) Message-Id: <199910221054.GAA05656@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-sskm-01.txt Date: Fri, 22 Oct 1999 06:54:36 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : SPKM with Shared Secret Keys (SSKM) Author(s) : W. Doonan Filename : draft-ietf-cat-sskm-01.txt Pages : 9 Date : 21-Oct-99 This document presents a method for using [SPKM] with exclusively shared secret key technologies. The messages and tokens of [SPKM] are unchanged; the only modifications required are to replace the default public-key cipher suite with ciphers and algorithms suitable for use with shared secret keys. All messages and tokens defined in [SPKM] are preserved; no changes are required to the various authentication modes of [SPKM]. Integrity algorithms and key establishment algorithms suitable for use with secret keys are added to those specified in [SPKM], which are well known and specified for use in other existing IETF standards. We in effect implement the implicit authenticated key exchange protocol proposed in [BR94] using the messages and tokens defined in [SPKM]. An overview and brief discussion of the protocol appears in section 1. The specific algorithms and object identifiers are listed in section 2. Discussion of how [SPKM] messages are used with shared secret keys appears in section 3. Security concerns are addressed in section 4. Patent issues are covered in section 5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-sskm-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-sskm-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-sskm-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: <19991021142203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-sskm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-sskm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142203.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 Fri Oct 22 07:42:50 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07619 for ; Fri, 22 Oct 1999 07:42:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA00788 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 03:54:37 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA00772 for ; Fri, 22 Oct 1999 03:54:32 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05641; Fri, 22 Oct 1999 06:54:30 -0400 (EDT) Message-Id: <199910221054.GAA05641@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-03.txt Date: Fri, 22 Oct 1999 06:54:30 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Security Service API Version 2 : Java bindings Author(s) : J. Kabat, M. Upadhyay Filename : draft-ietf-cat-gssv2-javabind-03.txt Pages : 96 Date : 21-Oct-99 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-03.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-03.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-03.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: <19991021142149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gssv2-javabind-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gssv2-javabind-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142149.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 Fri Oct 22 10:44:04 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16319 for ; Fri, 22 Oct 1999 10:44:02 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA13963 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 07:05:55 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA13937 for ; Fri, 22 Oct 1999 07:05:49 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 22 Oct 1999 14:05:49 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id KAA01225; Fri, 22 Oct 1999 10:05:09 -0400 Message-Id: <199910221405.KAA01225@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 22 Oct 1999 14:05:47 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Oct 1999 10:05:47 -0400 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: GSS: SPI and API Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I sent off a revised draft of the SPI document to the I-D gods yesterday; hopefully this will make it through the process. The filename ought to be ; unfortunately, there has been some confusion about numbering and some of you may have a DIFFERENT -02 version from before Oslo. Get rid of 'em if so. I don't consider that there are any show-stopping problems for the GSS Java binding that arise from the SPI work. Pre-Oslo, I had circulated some suggestions for what I considered an improved approach to the binding, based in part on SPI experience. Oslo would have been the time to discuss those, though, and unless other people feel that these are still open issues, I don't want to retard the process. The logical structure of the interfaces in Jack and Mayank's present binding draft can certainly be accommodated by the SPI and "shims" that use it, even if it isn't (in my view) entirely optimal. The only remaining area where I feel the SPI work suggests a change to J & M's document (assuming that's the one we move forward) is in the now-familiar area of concrete classes vs. interfaces. If I recall correctly, we decided (at Minneapolis, was it?) that the binding spec itself should consist of a repertoire of interfaces rather than concrete classes. J & M have mostly complied with this, except for their "factory class", GSSManager, which they continue to specify as a concrete class. This fact presents certain difficulties for me. I'll try to outline these now as clearly as I can, so that we can plunge right in when we get to DC. I envision that GSS implementations will fall into two broad classes: "monolithic" implementations, with a certain repertoire of mechanisms built in, and "shim" implementations which can load mechanisms dynamically. (It's the latter class that my SPI work is designed to accommodate, of course). Now monolithic implementations don't need and can't support any mechanism-management functionality. Shim implementations do need such functionality. Therefore I have specified a "shim" as a class which implements the GSS functions of GSSManager, and also some mechanism management functions which I define in a SEPARATE interface -- separate because only "shim" implementations will need to use it. J & M, however, have defined GSSManager as a concrete class incorporating some mechanism management functions. I have two problems with this: 1) these functions make no sense in the context of monolithic implementations, which is certainly one class of implementations we want to support, and 2) J & M's management functions don't seem to me to be quite adequate for the purpose. Rather than haggling with J & M over the management functions, though, I think we should do the following: 1) Remove all management functions from their GSSManager, and leave it with nothing but pure GSS-mandated functionality: i.e. the GSS elements common to both monolithic and shim implementations. 2) Turn it into an interface rather than a class. 3) My SPI doc will define a supplementary interface -- call it GSSMechanismManager -- which "shim" implementations will implement along with GSSManager. Monolithic implementations will implement only GSSManager. 4) Then we haggle as much as we like over the management functions, and don't have to hold the core elements of the binding hostage during this intensely pleasurable process -- the binding, stricto sensu, can proceed merrily down the standards track without being held up by the management discussion. Apart from the management functions, there are a few other issues for the SPI itself, and I have a few sugestions for the binding as well, but these topics don't relate to the interaction of binding and SPI, so I'll save them for another occasion. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 22 11:17:01 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18044 for ; Fri, 22 Oct 1999 11:17:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA20899 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 07:35:52 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id HAA20887 for ; Fri, 22 Oct 1999 07:35:49 -0700 (PDT) From: hemsath@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA372186 for ; Fri, 22 Oct 1999 10:35:04 -0400 Received: from d54mta08.raleigh.ibm.com (d54mta08.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.05) with SMTP id KAA60980 for ; Fri, 22 Oct 1999 10:35:19 -0400 Received: by d54mta08.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256812.005027B6 ; Fri, 22 Oct 1999 10:35:30 -0400 X-Lotus-FromDomain: IBMUS To: ietf-cat-wg@lists.Stanford.EDU Message-ID: <85256812.0050232E.00@d54mta08.raleigh.ibm.com> Date: Fri, 22 Oct 1999 09:33:01 -0500 Subject: Towards Java binding disposition [Was: RE: Next steps for CAT] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I feel strongly that the approval of the top level GSS-API (draft-ietf-cat-gssv2-javabind-03) should move quickly and independently of the lower level SPI for GSS (draft-ietf-cat-gssv2-javabind-spi-01) as there is no technical reason to tie the 2 together. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQA/AwUBOBB2Dwl0soYoviM2EQLgUACfdN+uv/hD9DDDx6KcMw8aIupshBQAmgOq +sRhLOXSqH9cEIOaZvGMxrja =S2w6 -----END PGP SIGNATURE----- David K. Hemsath, Team Lead (Security) SecureWay SysMgmt/Architecture/Standards IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA Tel.: +1(512)838-3618 T/L 678; Fax: 0156 Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com hemsath@us.ibm.com ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 22 21:28:16 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13373 for ; Fri, 22 Oct 1999 21:28:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id RAA16730 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 17:44:56 -0700 (PDT) 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 RAA16718 for ; Fri, 22 Oct 1999 17:44:53 -0700 (PDT) Received: from taller.eng.sun.com ([129.144.123.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05147; Fri, 22 Oct 1999 17:44:52 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA24366; Fri, 22 Oct 1999 17:44:47 -0700 (PDT) Date: Fri, 22 Oct 1999 17:44:49 -0700 (PDT) From: Mayank Upadhyay Reply-To: Mayank Upadhyay To: ietf-cat-wg@lists.Stanford.EDU cc: Jack Kabat Subject: GSS-API Java Bindings: Changes in new draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Here is the list of changes that Jack and I have made to the Java bindings for GSS-API in draft-ietf-cat-gssv2-javabind-03.txt. I'll try to have updated javadocs out on http://playground.sun.com/~mdu/ over the weekend. -Mayank =================================================================== (1) Added MessageProp.getMinorStatus() and MessageProp.getMinorString(). We should be able to return a minor status code from per-message calls even if no exception is thrown. For example, this might be needed if unwrap sees an out of sequence token, which is informatory but not a fatal error for per-message calls. (2) GSSName does not extend the java.security.Principal interface anymore. Not all web-browser based JRE's have the java.security.Principal interface defined in them. We have removed this to ensure the API can be used in the browser environment. (3) The package name org.ietf.jgss is all lower case. This is the convention, although the org.omg packages for CORBA are an aberration. This makes it possible for reader's to distinguish package names from class names (that begin with upper-case) without knowing anything else. (4) Removed concrete classes GSSName, GSSCredential and GSSContext that were adding no functionality but simply providing constructors to create implementations of IGSSName, IGSSCredential and IGSSCredential and delegating to those implementations. The GSSManager class still provides factory methods to create implementations of those IGSS* interfaces. Using the simple factory methods in GSSManager eliminates any advantage of having the concrete class wrappers. The API is leaner without any sacrifice in functionality/operating paradigm. Renamed IGSSName to GSSName, IGSSCredential to GSSCredential, and IGSSContext to GSSContext since those names were available and are more appropriate. (5) Removed the details of how to lookup and query Security Providers' deferring them to the service provider interface (SPI) specification. This approach assumes that the GSS implementation may or may not be a modular layer that can be extended with providers to add support for more mechanisms. For GSS implementations that can do so, there is a one call (setProvider) that allows an application to indicate a preferred provider for a particular mechanism. The GSS-API does not have to honor this request and has a way to indicate this. We wish to be very clear that you do not need to use providers, but the API has a method to optionally allow this. (6) Removed the GSSFactory interface Left it upto the SPI to define provider based GSSFactory's. The GSSManger class provides factory methods to obtain instances of the interfaces GSSName, GSSCredential, and GSSContext at the top level. Those may or may not internally use any SPI level GSSFactory obtained from providers. An application that wants to use its own custom complete GSS implementation can simply subclass GSSManager from a standard GSS package. This hides any SPI related functionality in the GSS layer. Mechanism specific factories logically belong in the layer below the GSS. Applications using the GSS-API should be isolated from the SPI layer. (7) Changed static methods in GSSManger to non-static If any preferences are set through static methods, they influence all code running in the same JVM. This is not an acceptable situation for applets in the same browser. Also, applications can now instantiate multiple GSSManager's and have different provider preferences on each of them. Some of these GSSManager's may even be from the applications own custom GSS implementation. (8) Modified sample code to match the changes in the API. =================================================================== ========================================================================== 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 Oct 22 21:53:47 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14504 for ; Fri, 22 Oct 1999 21:53:46 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA21339 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 18:04:25 -0700 (PDT) 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 SAA21324 for ; Fri, 22 Oct 1999 18:04:22 -0700 (PDT) Received: from taller.eng.sun.com ([129.144.250.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07773; Fri, 22 Oct 1999 18:04:21 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id SAA25501; Fri, 22 Oct 1999 18:04:16 -0700 (PDT) Date: Fri, 22 Oct 1999 18:04:18 -0700 (PDT) From: Mayank Upadhyay Reply-To: Mayank Upadhyay To: Michael Smith cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: GSS: SPI and API In-Reply-To: <199910221405.KAA01225@gf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Brief comments below... -Mayank On Fri, 22 Oct 1999, Michael Smith wrote: > concrete classes vs. interfaces. If I recall correctly, we > decided (at Minneapolis, was it?) that the binding spec > itself should consist of a repertoire of interfaces > rather than concrete classes. J & M have mostly complied We had decided this for the Name, Credentials and Context classes only. We had also decided we had to have a standard way for instantiating implementations for these. > with this, except for their "factory class", GSSManager, > which they continue to specify as a concrete class. org.ietf.jgss.GSSManager will be the standard factory class for these top level interfaces. Its easy, logical, and less confusing to developers since you are introducing new provider based factories in the SPI. > J & M, however, have defined GSSManager as a > concrete class incorporating some mechanism > management functions. I have two problems with > this: 1) these functions make no sense in the > context of monolithic implementations, which is > certainly one class of implementations we want > to support, Applications don't want two separate API's for monolithic and non-monolithic implementations. Our GSS-API has the bare minimum addition that can *optionally* enable the implementation to be non-monolithic. > and 2) J & M's management functions > don't seem to me to be quite adequate for the > purpose. We're willing to argue that the provider management functionality you're looking for is already there in the Java language API without us needing to duplicate it in the GSS-API. Please remember that provider management is not GSS-API. It's Java Crypto Architecture and that's being built elsewhere. Unless you have a dire need for something new, its best to not bloat the API. > Rather than haggling with J & M over the > management functions, though, I think we should > do the following: Please, let's not haggle! Let's discuss this issue on technical and practical merits. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sat Oct 23 01:46:24 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21907 for ; Sat, 23 Oct 1999 01:46:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id WAA14945 for ietf-cat-wg-out720680; Fri, 22 Oct 1999 22:15:18 -0700 (PDT) Received: from ude.isi.edu (mg130-012.ricochet.net [204.179.130.12]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id WAA14824 for ; Fri, 22 Oct 1999 22:14:45 -0700 (PDT) Received: (from brian@localhost) by ude.isi.edu (8.8.5/8.8.5) id WAA02773 for ietf-cat-wg@lists.stanford.edu; Fri, 22 Oct 1999 22:18:46 -0700 Date: Fri, 22 Oct 1999 22:18:46 -0700 From: Brian Tung Message-Id: <199910230518.WAA02773@ude.isi.edu> To: ietf-cat-wg@lists.Stanford.EDU Subject: PKINIT, rev 10 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here forthwith the latest revision of the draft, for your perusal. b ***** INTERNET-DRAFT Brian Tung draft-ietf-cat-kerberos-pk-init-10.txt Clifford Neuman Updates: RFC 1510 ISI expires April 30, 2000 Matthew Hur CyberSafe Corporation Ari Medvinsky Excite Sasha Medvinsky General Instrument John Wray Iris Associates, Inc. Jonathan Trostle Cisco Public Key Cryptography for Initial Authentication in Kerberos 0. Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30, 2000. Please send comments to the authors. 1. Abstract This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. 2. Introduction The popularity of public key cryptography has produced a desire for its support in Kerberos [2]. The advantages provided by public key cryptography include simplified key management (from the Kerberos perspective) and the ability to leverage existing and developing public key certification infrastructures. Public key cryptography can be integrated into Kerberos in a number of ways. One is to associate a key pair with each realm, which can then be used to facilitate cross-realm authentication; this is the topic of another draft proposal. Another way is to allow users with public key certificates to use them in initial authentication. This is the concern of the current document. PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in combination with digital signature keys as the primary, required mechanism. It also allows for the use of RSA keys and/or (static) Diffie-Hellman certificates. Note in particular that PKINIT supports the use of separate signature and encryption keys. PKINIT enables access to Kerberos-secured services based on initial authentication utilizing public key cryptography. PKINIT utilizes standard public key signature and encryption data formats within the standard Kerberos messages. The basic mechanism is as follows: The user sends an AS-REQ message to the KDC as before, except that if that user is to use public key cryptography in the initial authentication step, his certificate and a signature accompany the initial request in the preauthentication fields. Upon receipt of this request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as before, except that the encPart from the AS-REP message carrying the TGT is now encrypted utilizing either a Diffie-Hellman derived key or the user's public key. This message is authenticated utilizing the public key signature of the KDC. Note that PKINIT does not require the use of certificates. A KDC may store the public key of a principal as part of that principal's record. In this scenario, the KDC is the trusted party that vouches for the principal (as in a standard, non-cross realm, Kerberos environment). Thus, for any principal, the KDC may maintain a secret key, a public key, or both. The PKINIT specification may also be used as a building block for other specifications. PKCROSS [3] utilizes PKINIT for establishing the inter-realm key and associated inter-realm policy to be applied in issuing cross realm service tickets. As specified in [4], anonymous Kerberos tickets can be issued by applying a NULL signature in combination with Diffie-Hellman in the PKINIT exchange. Additionally, the PKINIT specification may be used for direct peer to peer authentication without contacting a central KDC. This application of PKINIT is described in PKTAPP [5] and is based on concepts introduced in [6, 7]. For direct client-to-server authentication, the client uses PKINIT to authenticate to the end server (instead of a central KDC), which then issues a ticket for itself. This approach has an advantage over TLS [8] in that the server does not need to save state (cache session keys). Furthermore, an additional benefit is that Kerberos tickets can facilitate delegation (see [9]). 3. Proposed Extensions This section describes extensions to RFC 1510 for supporting the use of public key cryptography in the initial request for a ticket granting ticket (TGT). In summary, the following change to RFC 1510 is proposed: * Users may authenticate using either a public key pair or a conventional (symmetric) key. If public key cryptography is used, public key data is transported in preauthentication data fields to help establish identity. The user presents a public key certificate and obtains an ordinary TGT that may be used for subsequent authentication, with such authentication using only conventional cryptography. Section 3.1 provides definitions to help specify message formats. Section 3.2 describes the extensions for the initial authentication method. 3.1. Definitions The extensions involve new preauthentication fields; we introduce the following preauthentication types: PA-PK-AS-REQ 14 PA-PK-AS-REP 15 The extensions also involve new error types; we introduce the following types: KDC_ERR_CLIENT_NOT_TRUSTED 62 KDC_ERR_KDC_NOT_TRUSTED 63 KDC_ERR_INVALID_SIG 64 KDC_ERR_KEY_TOO_WEAK 65 KDC_ERR_CERTIFICATE_MISMATCH 66 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 KDC_ERR_INVALID_CERTIFICATE 71 KDC_ERR_REVOKED_CERTIFICATE 72 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 KDC_ERR_CLIENT_NAME_MISMATCH 75 KDC_ERR_KDC_NAME_MISMATCH 76 We utilize the following typed data for errors: TD-PKINIT-CMS-CERTIFICATES 101 TD-KRB-PRINCIPAL 102 TD-KRB-REALM 103 TD-TRUSTED-CERTIFIERS 104 TD-CERTIFICATE-INDEX 105 We utilize the following encryption types (which map directly to OIDs): dsaWithSHA1-CmsOID 9 md5WithRSAEncryption-CmsOID 10 sha1WithRSAEncryption-CmsOID 11 rc2CBC-EnvOID 12 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 des-ede3-cbc-Env-OID 15 These mappings are provided so that a client may send the appropriate enctypes in the AS-REQ message in order to indicate support for the corresponding OIDs (for performing PKINIT). In many cases, PKINIT requires the encoding of the X.500 name of a certificate authority as a Realm. When such a name appears as a ream it will be represented using the "other" form of the realm name as specified in the naming constraints section of RFC1510. For a realm derived from an X.500 name, NAMETYPE will have the value X500-RFC2253. The full realm name will appear as follows: + ":" + where nametype is "X500-RFC2253" and string is the result of doing an RFC2253 encoding of the distinguished name, i.e. "X500-RFC2253:" + RFC2253Encode(DistinguishedName) where DistinguishedName is an X.500 name, and RFC2253Encode is a function returing a readable UTF encoding of an X.500 name, as defined by RFC 2253 [14] (part of LDAPv3 [18]). To ensure that this encoding is unique, we add the following rule to those specified by RFC 2253: The order in which the attributes appear in the RFC 2253 encoding must be the reverse of the order in the ASN.1 encoding of the X.500 name that appears in the public key certificate. The order of the relative distinguished names (RDNs), as well as the order of the AttributeTypeAndValues within each RDN, will be reversed. (This is despite the fact that an RDN is defined as a SET of AttributeTypeAndValues, where an order is normally not important.) Similarly, in cases where the KDC does not provide a specific policy based mapping from the X.500 name or X.509 Version 3 SubjectAltName extension in the user's certificate to a Kerberos principal name, PKINIT requires the direct encoding of the X.500 name as a PrincipalName. In this case, the name-type of the principal name shall be set to KRB_NT-X500-PRINCIPAL. This new name type is defined in RFC 1510 as: KRB_NT_X500_PRINCIPAL 6 The name-string shall be set as follows: RFC2253Encode(DistinguishedName) as described above. When this name type is used, the principal's realm shall be set to the certificate authority's distinguished name using the X500-RFC2253 realm name format described earlier in this section RFC 1510 specifies the ASN.1 structure for PrincipalName as follows: PrincipalName ::= SEQUENCE { name-type[0] INTEGER, name-string[1] SEQUENCE OF GeneralString } For the purposes of encoding an X.500 name within this structure, the name-string shall be encoded as a single GeneralString. Note that name mapping may be required or optional based on policy. All names must conform to validity requirements as given in RFC 1510. 3.1.1. Encryption and Key Formats In the exposition below, we use the terms public key and private key generically. It should be understood that the term "public key" may be used to refer to either a public encryption key or a signature verification key, and that the term "private key" may be used to refer to either a private decryption key or a signature generation key. The fact that these are logically distinct does not preclude the assignment of bitwise identical keys for RSA keys. In the case of Diffie-Hellman, the key shall be produced from the agreed bit string as follows: * Truncate the bit string to the appropriate length. * Rectify parity in each byte (if necessary) to obtain the key. For instance, in the case of a DES key, we take the first eight bytes of the bit stream, and then adjust the least significant bit of each byte to ensure that each byte has odd parity. 3.1.2. Algorithm Identifiers PKINIT does not define, but does permit, the algorithm identifiers listed below. 3.1.2.1. Signature Algorithm Identifiers The following signature algorithm identifiers specified in [11] and in [15] shall be used with PKINIT: id-dsa-with-sha1 (DSA with SHA1) md5WithRSAEncryption (RSA with MD5) sha-1WithRSAEncryption (RSA with SHA1) 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier The following algorithm identifier shall be used within the SubjectPublicKeyInfo data structure: dhpublicnumber This identifier and the associated algorithm parameters are specified in RFC 2459 [15]. 3.1.2.3. Algorithm Identifiers for RSA Encryption These algorithm identifiers are used inside the EnvelopedData data structure, for encrypting the temporary key with a public key: rsaEncryption (RSA encryption, PKCS#1 v1.5) id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) Both of the above RSA encryption schemes are specified in [16]. Currently, only PKCS#1 v1.5 is specified by CMS [11], although the CMS specification says that it will likely include PKCS#1 v2.0 in the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext vulnerability discovered in PKCS#1 v1.5.) 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys These algorithm identifiers are used inside the EnvelopedData data structure in the PKINIT Reply, for encrypting the reply key with the temporary key: des-ede3-cbc (3-key 3-DES, CBC mode) rc2-cbc (RC2, CBC mode) The full definition of the above algorithm identifiers and their corresponding parameters (an IV for block chaining) is provided in the CMS specification [11]. 3.2. Public Key Authentication Implementation of the changes in this section is REQUIRED for compliance with PKINIT. 3.2.1. Client Request Public keys may be signed by some certification authority (CA), or they may be maintained by the KDC in which case the KDC is the trusted authority. Note that the latter mode does not require the use of certificates. The initial authentication request is sent as per RFC 1510, except that a preauthentication field containing data signed by the user's private key accompanies the request: PA-PK-AS-REQ ::= SEQUENCE { -- PA TYPE 14 signedAuthPack [0] SignedData -- defined in CMS [11] -- AuthPack (below) defines the data -- that is signed trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, -- CAs that the client trusts kdcCert [2] IssuerAndSerialNumber OPTIONAL -- as defined in CMS [11] -- specifies a particular KDC -- certificate if the client -- already has it; encryptionCert [3] IssuerAndSerialNumber OPTIONAL -- For example, this may be the -- client's Diffie-Hellman -- certificate, or it may be the -- client's RSA encryption -- certificate. } TrustedCas ::= CHOICE { principalName [0] KerberosName, -- as defined below caName [1] Name -- fully qualified X.500 name -- as defined by X.509 issuerAndSerial [2] IssuerAndSerialNumber -- Since a CA may have a number of -- certificates, only one of which -- a client trusts } Usage of SignedData: The SignedData data type is specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. - The encapContentInfo field must contain the PKAuthenticator and, optionally, the client's Diffie Hellman public value. - The eContentType field shall contain the OID value for id-data: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) data(1) - The eContent field is data of the type AuthPack (below). - The signerInfos field contains the signature of AuthPack. - The Certificates field, when non-empty, contains the client's certificate chain. If present, the KDC uses the public key from the client's certificate to verify the signature in the request. Note that the client may pass different certificates that are used for signing or for encrypting. Thus, the KDC may utilize a different client certificate for signature verification than the one it uses to encrypt the reply to the client. For example, the client may place a Diffie-Hellman certificate in this field in order to convey its static Diffie Hellman certificate to the KDC to enable static-ephemeral Diffie-Hellman mode for the reply; in this case, the client does NOT place its public value in the AuthPack (defined below). As another example, the client may place an RSA encryption certificate in this field. However, there must always be (at least) a signature certificate. AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL -- if client is using Diffie-Hellman -- (ephemeral-ephemeral only) } PKAuthenticator ::= SEQUENCE { kdcName [0] PrincipalName, kdcRealm [1] Realm, cusec [2] INTEGER, -- for replay prevention as in RFC1510 ctime [3] KerberosTime, -- for replay prevention as in RFC1510 nonce [4] INTEGER } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, -- dhKeyAgreement subjectPublicKey BIT STRING -- for DH, equals -- public exponent (INTEGER encoded -- as payload of BIT STRING) } -- as specified by the X.509 recommendation [10] AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id, parameters ALGORITHM.&type } -- as specified by the X.509 recommendation [10] If the client passes an issuer and serial number in the request, the KDC is requested to use the referred-to certificate. If none exists, then the KDC returns an error of type KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the other hand, the client does not pass any trustedCertifiers, believing that it has the KDC's certificate, but the KDC has more than one certificate. The KDC should include information in the KRB-ERROR message that indicates the KDC certificate(s) that a client may utilize. This data is specified in the e-data, which is defined in RFC 1510 revisions as a SEQUENCE of TypedData: TypedData ::= SEQUENCE { data-type [0] INTEGER, data-value [1] OCTET STRING, } -- per Kerberos RFC 1510 revisions where: data-type = TD-PKINIT-CMS-CERTIFICATES = 101 data-value = CertificateSet // as specified by CMS [11] The PKAuthenticator carries information to foil replay attacks, and to bind the request and response. The PKAuthenticator is signed with the client's signature key. 3.2.2. KDC Response Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication type, the KDC attempts to verify the user's certificate chain (userCert), if one is provided in the request. This is done by verifying the certification path against the KDC's policy of legitimate certifiers. This may be based on a certification hierarchy, or it may be simply a list of recognized certifiers in a system like PGP. If the client's certificate chain contains no certificate signed by a CA trusted by the KDC, then the KDC sends back an error message of type KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104) whose data-value is an OCTET STRING which is the DER encoding of TrustedCertifiers ::= SEQUENCE OF PrincipalName -- X.500 name encoded as a principal name -- see Section 3.1 If while verifying a certificate chain the KDC determines that the signature on one of the certificates in the CertificateSet from the signedAuthPack fails verification, then the KDC returns an error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data is a SEQUENCE of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING which is the DER encoding of the index into the CertificateSet ordered as sent by the client. CertificateIndex ::= INTEGER -- 0 = 1st certificate, -- (in order of encoding) -- 1 = 2nd certificate, etc The KDC may also check whether any of the certificates in the client's chain has been revoked. If one of the certificates has been revoked, then the KDC returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the certificate's revocation status is unknown or not available, then if required by policy, the KDC returns the appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three cases, the affected certificate is identified by the accompanying e-data, which contains a CertificateIndex as described for KDC_ERR_INVALID_CERTIFICATE. If the certificate chain can be verified, but the name of the client in the certificate does not match the client's name in the request, then the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data field in this case. Finally, if the certificate chain is verified, but the KDC's name or realm as given in the PKAuthenticator does not match the KDC's actual principal name, then the KDC returns an error of type KDC_ERR_KDC_NAME_MISMATCH. The accompanying e-data field is again a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET STRING whose data-value is the DER encoding of a PrincipalName or Realm as defined in RFC 1510 revisions. Even if all succeeds, the KDC may--for policy reasons--decide not to trust the client. In this case, the KDC returns an error message of type KDC_ERR_CLIENT_NOT_TRUSTED. If a trust relationship exists, the KDC then verifies the client's signature on AuthPack. If that fails, the KDC returns an error message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the timestamp (ctime and cusec) in the PKAuthenticator to assure that the request is not a replay. The KDC also verifies that its name is specified in the PKAuthenticator. If the clientPublicValue field is filled in, indicating that the client wishes to use Diffie-Hellman key agreement, then the KDC checks to see that the parameters satisfy its policy. If they do not (e.g., the prime size is insufficient for the expected encryption type), then the KDC sends back an error message of type KDC_ERR_KEY_TOO_WEAK. Otherwise, it generates its own public and private values for the response. The KDC also checks that the timestamp in the PKAuthenticator is within the allowable window and that the principal name and realm are correct. If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew, then the KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510. Assuming no errors, the KDC replies as per RFC 1510, except as follows. The user's name in the ticket is determined by the following decision algorithm: 1. If the KDC has a mapping from the name in the certificate to a Kerberos name, then use that name. Else 2. If the certificate contains the SubjectAltName extention and the local KDC policy defines a mapping from the SubjectAltName to a Kerberos name, then use that name. Else 3. Use the name as represented in the certificate, mapping mapping as necessary (e.g., as per RFC 2253 for X.500 names). In this case the realm in the ticket shall be the name of the certifier that issued the user's certificate. Note that a principal name may be carried in the subject alt name field of a certificate. This name may be mapped to a principal record in a security database based on local policy, for example the subject alt name may be kerberos/principal@realm format. In this case the realm name is not that of the CA but that of the local realm doing the mapping (or some realm name chosen by that realm). If a non-KDC X.509 certificate contains the principal name within the subjectAltName version 3 extension , that name may utilize KerberosName as defined below, or, in the case of an S/MIME certificate [17], may utilize the email address. If the KDC is presented with as S/MIME certificate, then the email address within subjectAltName will be interpreted as a principal and realm separated by the "@" sign, or as a name that needs to be canonicalized. If the resulting name does not correspond to a registered principal name, then the principal name is formed as defined in section 3.1. The trustedCertifiers field contains a list of certification authorities trusted by the client, in the case that the client does not possess the KDC's public key certificate. If the KDC has no certificate signed by any of the trustedCertifiers, then it returns an error of type KDC_ERR_KDC_NOT_TRUSTED. KDCs should try to (in order of preference): 1. Use the KDC certificate identified by the serialNumber included in the client's request. 2. Use a certificate issued to the KDC by the client's CA (if in the middle of a CA key roll-over, use the KDC cert issued under same CA key as user cert used to verify request). 3. Use a certificate issued to the KDC by one of the client's trustedCertifier(s); If the KDC is unable to comply with any of these options, then the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the client. The KDC encrypts the reply not with the user's long-term key, but with the Diffie Hellman derived key or a random key generated for this particular response which is carried in the padata field of the TGS-REP message. PA-PK-AS-REP ::= CHOICE { -- PA TYPE 15 dhSignedData [0] SignedData, -- Defined in CMS and used only with -- Diffie-Hellman key exchange (if the -- client public value was present in the -- request). -- This choice MUST be supported -- by compliant implementations. encKeyPack [1] EnvelopedData, -- Defined in CMS -- The temporary key is encrypted -- using the client public key -- key -- SignedReplyKeyPack, encrypted -- with the temporary key, is also -- included. } Usage of SignedData: If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP provides authenticated Diffie-Hellman parameters of the KDC. The reply key used to encrypt part of the KDC reply message is derived from the Diffie-Hellman exchange: - Both the KDC and the client calculate a secret value (g^ab mod p), where a is the client's private exponent and b is the KDC's private exponent. - Both the KDC and the client take the first N bits of this secret value and convert it into a reply key. N depends on the reply key type. - If the reply key is DES, N=64 bits, where some of the bits are replaced with parity bits, according to FIPS PUB 74. - If the reply key is (3-key) 3-DES, N=192 bits, where some of the bits are replaced with parity bits, according to FIPS PUB 74. - The encapContentInfo field must contain the KdcDHKeyInfo as defined below. - The eContentType field shall contain the OID value for id-data: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) data(1) - The certificates field must contain the certificates necessary for the client to establish trust in the KDC's certificate based on the list of trusted certifiers sent by the client in the PA-PK-AS-REQ. This field may be empty if the client did not send to the KDC a list of trusted certifiers (the trustedCertifiers field was empty, meaning that the client already possesses the KDC's certificate). - The signerInfos field is a SET that must contain at least one member, since it contains the actual signature. KdcDHKeyInfo ::= SEQUENCE { -- used only when utilizing Diffie-Hellman nonce [0] INTEGER, -- binds responce to the request subjectPublicKey [2] BIT STRING -- Equals public exponent (g^a mod p) -- INTEGER encoded as payload of -- BIT STRING } Usage of EnvelopedData: The EnvelopedData data type is specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. It contains an temporary key encrypted with the PKINIT client's public key. It also contains a signed and encrypted reply key. - The originatorInfo field is not required, since that information may be presented in the signedData structure that is encrypted within the encryptedContentInfo field. - The optional unprotectedAttrs field is not required for PKINIT. - The recipientInfos field is a SET which must contain exactly one member of the KeyTransRecipientInfo type for encryption with an RSA public key. - The encryptedKey field (in KeyTransRecipientInfo) contains the temporary key which is encrypted with the PKINIT client's public key. - The encryptedContentInfo field contains the signed and encrypted reply key. - The contentType field shall contain the OID value for id-signedData: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) signedData(2) - The encryptedContent field is encrypted data of the CMS type signedData as specified below. - The encapContentInfo field must contains the ReplyKeyPack. - The eContentType field shall contain the OID value for id-data: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) data(1) - The eContent field is data of the type ReplyKeyPack (below). - The certificates field must contain the certificates necessary for the client to establish trust in the KDC's certificate based on the list of trusted certifiers sent by the client in the PA-PK-AS-REQ. This field may be empty if the client did not send to the KDC a list of trusted certifiers (the trustedCertifiers field was empty, meaning that the client already possesses the KDC's certificate). - The signerInfos field is a SET that must contain at least one member, since it contains the actual signature. ReplyKeyPack ::= SEQUENCE { -- not used for Diffie-Hellman replyKey [0] EncryptionKey, -- used to encrypt main reply -- ENCTYPE is at least as strong as -- ENCTYPE of session key nonce [1] INTEGER, -- binds response to the request -- must be same as the nonce -- passed in the PKAuthenticator } Since each certifier in the certification path of a user's certificate is equivalent to a separate Kerberos realm, the name of each certifier in the certificate chain must be added to the transited field of the ticket. The format of these realm names is defined in Section 3.1 of this document. If applicable, the transit-policy-checked flag should be set in the issued ticket. The KDC's certificate(s) must bind the public key(s) of the KDC to a name derivable from the name of the realm for that KDC. X.509 certificates shall contain the principal name of the KDC (defined in section 8.2 of RFC 1510) as the SubjectAltName version 3 extension. Below is the definition of this version 3 extension, as specified by the X.509 standard: subjectAltName EXTENSION ::= { SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName } GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, ... } OTHER-NAME ::= TYPE-IDENTIFIER In this definition, otherName is a name of any form defined as an instance of the OTHER-NAME information object class. For the purpose of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will be chosen and replaced by the type KerberosName: KerberosName ::= SEQUENCE { realm [0] Realm, -- as defined in RFC 1510 principalName [1] PrincipalName, -- as defined in RFC 1510 } This specific syntax is identified within subjectAltName by setting the OID id-ce-subjectAltName to krb5PrincipalName, where (from the Kerberos specification) we have krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) } krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } (This specification may also be used to specify a Kerberos name within the user's certificate.) The KDC's certificate may be signed directly by a CA, or there may be intermediaries if the server resides within a large organization, or it may be unsigned if the client indicates possession (and trust) of the KDC's certificate. The client then extracts the random key used to encrypt the main reply. This random key (in encPaReply) is encrypted with either the client's public key or with a key derived from the DH values exchanged between the client and the KDC. The client uses this random key to decrypt the main reply, and subsequently proceeds as described in RFC 1510. 3.2.3. Required Algorithms Not all of the algorithms in the PKINIT protocol specification have to be implemented in order to comply with the proposed standard. Below is a list of the required algorithms: - Diffie-Hellman public/private key pairs - utilizing Diffie-Hellman ephemeral-ephemeral mode - SHA1 digest and DSA for signatures - 3-key triple DES keys derived from the Diffie-Hellman Exchange - 3-key triple DES Temporary and Reply keys 4. Logistics and Policy This section describes a way to define the policy on the use of PKINIT for each principal and request. The KDC is not required to contain a database record for users who use public key authentication. However, if these users are registered with the KDC, it is recommended that the database record for these users be modified to an additional flag in the attributes field to indicate that the user should authenticate using PKINIT. If this flag is set and a request message does not contain the PKINIT preauthentication field, then the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication field of type PA-PK-AS-REQ must be included in the request. 5. Security Considerations PKINIT raises a few security considerations, which we will address in this section. First of all, PKINIT introduces a new trust model, where KDCs do not (necessarily) certify the identity of those for whom they issue tickets. PKINIT does allow KDCs to act as their own CAs, in order to simplify key management, but one of the additional benefits is to align Kerberos authentication with a global public key infrastructure. Anyone using PKINIT in this way must be aware of how the certification infrastructure they are linking to works. Secondly, PKINIT also introduces the possibility of interactions between different cryptosystems, which may be of widely varying strengths. Many systems, for instance, allow the use of 512-bit public keys. Using such keys to wrap data encrypted under strong conventional cryptosystems, such as triple-DES, is inappropriate; it adds a weak link to a strong one at extra cost. Implementors and administrators should take care to avoid such wasteful and deceptive interactions. Lastly, PKINIT calls for randomly generated keys for conventional cryptosystems. Many such systems contain systematically "weak" keys. PKINIT implementations MUST avoid use of these keys, either by discarding those keys when they are generated, or by fixing them in some way (e.g., by XORing them with a given mask). These precautions vary from system to system; it is not our intention to give an explicit recipe for them here. 6. Transport Issues Certificate chains can potentially grow quite large and span several UDP packets; this in turn increases the probability that a Kerberos message involving PKINIT extensions will be broken in transit. In light of the possibility that the Kerberos specification will require KDCs to accept requests using TCP as a transport mechanism, we make the same recommendation with respect to the PKINIT extensions as well. 7. Bibliography [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments 1510. [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9):33-38. September 1994. [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, A. Medvinsky, M. Hur. Public Key Cryptography for Cross-Realm Authentication in Kerberos. draft-ietf-cat-kerberos-pk-cross-04.txt [4] A. Medvinsky, J. Cargille, M. Hur. Anonymous Credentials in Kerberos. draft-ietf-cat-kerberos-anoncred-00.txt [5] A. Medvinsky, M. Hur, B. Clifford Neuman. Public Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-cat-pktapp-00.txt [6] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using Public Key Cryptography. Symposium On Network and Distributed System Security, 1997. [7] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce, July 1995. [8] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 Request for Comments 2246, January 1999. [9] B.C. Neuman, Proxy-Based Authorization and Accounting for Distributed Systems. In Proceedings of the 13th International Conference on Distributed Computing Systems, May 1993. [10] ITU-T (formerly CCITT) Information technology - Open Systems Interconnection - The Directory: Authentication Framework Recommendation X.509 ISO/IEC 9594-8 [11] R. Housley. Cryptographic Message Syntax. draft-ietf-smime-cms-13.txt, April 1999, approved for publication as RFC. [12] PKCS #7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note Version 1.5 Revised November 1, 1993 [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data Security, Inc. A Description of the RC2(r) Encryption Algorithm March 1998. Request for Comments 2268. [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. Request for Comments 2253. [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, January 1999. Request for Comments 2459. [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography Specifications, October 1998. Request for Comments 2437. [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME Version 2 Certificate Handling, March 1998. Request for Comments 2312. [18] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access Protocol (v3), December 1997. Request for Comments 2251. 8. Acknowledgements Some of the ideas on which this proposal is based arose during discussions over several years between members of the SAAG, the IETF CAT working group, and the PSRG, regarding integration of Kerberos and SPX. Some ideas have also been drawn from the DASS system. These changes are by no means endorsed by these groups. This is an attempt to revive some of the goals of those groups, and this proposal approaches those goals primarily from the Kerberos perspective. Lastly, comments from groups working on similar ideas in DCE have been invaluable. 9. Expiration Date This draft expires April 30, 2000. 10. Authors Brian Tung Clifford Neuman USC Information Sciences Institute 4676 Admiralty Way Suite 1001 Marina del Rey CA 90292-6695 Phone: +1 310 822 1511 E-mail: {brian, bcn}@isi.edu Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Issaquah WA 98027-5378 Phone: +1 425 391 6000 E-mail: matt.hur@cybersafe.com Ari Medvinsky Excite 555 Broadway Redwood City, CA 94063 Phone +1 650 569 2119 E-mail: amedvins@excitecorp.com Sasha Medvinsky General Instrument 6450 Sequence Drive San Diego, CA 92121 Phone +1 619 404 2825 E-mail: smedvinsky@gi.com John Wray Iris Associates, Inc. 5 Technology Park Dr. Westford, MA 01886 E-mail: John_Wray@iris.com Jonathan Trostle 170 W. Tasman Dr. San Jose, CA 95134 E-mail: jtrostle@cisco.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBOBFFNPxWUiHQcCAeEQLV4gCgijkniFe8HUDjRTPOTgGPudSPvwQAoPEW foNjWfydcKnt5yKZhM4U7eDU =ICRa -----END PGP SIGNATURE----- ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Oct 25 07:25:18 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04362 for ; Mon, 25 Oct 1999 07:25:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09537 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 03:56:33 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09520 for ; Mon, 25 Oct 1999 03:56:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02856; Mon, 25 Oct 1999 06:56:27 -0400 (EDT) Message-Id: <199910251056.GAA02856@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-gss-conv-00.txt Date: Mon, 25 Oct 1999 06:56:26 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : GSS Conversation C-bindings Interface Author(s) : T. Ts'o Filename : draft-ietf-cat-gss-conv-00.txt Pages : 5 Date : 22-Oct-99 Traditionally, the GSSAPI specification has not included in its scope the acquisition of initial credentials, or mechanisms which have required interaction with the user in the course of the security context. This has limited the applicability of the GSSAPI specification. This specification allows an application program to register a callback function so that a GSSAPI mechanism can request conversation services from the application program. The application program is responsible for displaying messages to the user and requesting input from the user via the callback function. The goal of this specification is to allow certain low- infrastructure-requiring mechanisms to prompt the user for a username, password, SecureID response, etc. It might also be used by mechanisms such as Kerberos when the GSSAPI library wishes to obtain initial credentials itself, instead of assuming that they are already present in the process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-gss-conv-00.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-gss-conv-00.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-gss-conv-00.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: <19991022135400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gss-conv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gss-conv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135400.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 Oct 25 07:37:55 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04365 for ; Mon, 25 Oct 1999 07:25:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id DAA09521 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 03:56:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id DAA09499 for ; Mon, 25 Oct 1999 03:56:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02844; Mon, 25 Oct 1999 06:56:19 -0400 (EDT) Message-Id: <199910251056.GAA02844@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-spi-02.txt Date: Mon, 25 Oct 1999 06:56:19 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : A Service Provider API for GSS mechanisms in Java Author(s) : M. Smith Filename : draft-ietf-cat-gssv2-javabind-spi-02.txt Pages : 17 Date : 22-Oct-99 This document specifies a 'provider API' by which GSS mechanisms implemented in Java can be accessed through an intermediate 'broker' or 'shim' layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-javabind-spi-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-gssv2-javabind-spi-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-gssv2-javabind-spi-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: <19991022135338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gssv2-javabind-spi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gssv2-javabind-spi-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022135338.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 Oct 25 14:58:17 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02080 for ; Mon, 25 Oct 1999 14:58:16 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA02346 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 10:09:19 -0700 (PDT) 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 KAA02341 for ; Mon, 25 Oct 1999 10:09:17 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20250 for ; Mon, 25 Oct 1999 10:09:15 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA20069 for ; Mon, 25 Oct 1999 10:09:15 -0700 (PDT) Received: from teal (awe8-111.Central.Sun.COM [129.147.8.111]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA542232 for ; Mon, 25 Oct 1999 10:09:13 -0700 (PDT) Date: Mon, 25 Oct 1999 10:11:54 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: RE: GSS: SPI and API To: ietf-cat-wg@lists.Stanford.EDU In-Reply-To: "Your message with ID" <27FF4FAEA8CDD211B97E00902745CBE2167DD2@seine.valicert.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > I thought we > came to agreement on this? indeed. i thought we came to agreement on everything in Minneapolis. -mre ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Oct 25 14:58:18 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02086 for ; Mon, 25 Oct 1999 14:58:17 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA25783 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 09:24:58 -0700 (PDT) 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 JAA25778 for ; Mon, 25 Oct 1999 09:24:55 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 25 Oct 1999 16:23:37 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 MAA24797; Mon, 25 Oct 1999 12:19:10 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Mon, 25 Oct 1999 12:26:32 -0400 Message-ID: From: "Linn, John" To: "'CAT-WG List'" Cc: "'Jeff Schiller'" Subject: GSS-V2 documents approved to become Proposed Standards Date: Mon, 25 Oct 1999 12:31:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CAT-WG: I'm pleased to be able to relay a piece of news recently received from Jeff Schiller. At its most recent teleconference meeting, the IESG approved the pair of GSS-V2 specifications, draft-ietf-cat-rfc2078bis-08.txt and draft-ietf-cat-gssv2-cbind-09.txt, for advancement to Proposed Standards. Protocol Action announcement and RFC Editor processing will follow. Thanks to all who contributed to their preparation and discussion. --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 Mon Oct 25 14:58:21 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02100 for ; Mon, 25 Oct 1999 14:58:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA20415 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 08:56:20 -0700 (PDT) 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 IAA20402 for ; Mon, 25 Oct 1999 08:56:17 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Oct 1999 08:46:29 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2167DD2@seine.valicert.com> From: Jack Kabat To: Michael Smith Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: GSS: SPI and API Date: Mon, 25 Oct 1999 08:46:27 -0700 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 Hello, Below are additional comments to Mayank's reply. Regards, Jack > -----Original Message----- > From: Mayank Upadhyay [mailto:Mayank.Upadhyay@Eng.Sun.COM] > Sent: Friday, October 22, 1999 6:04 PM > To: Michael Smith > Cc: ietf-cat-wg@lists.Stanford.EDU > Subject: Re: GSS: SPI and API > > > Brief comments below... > > -Mayank > > On Fri, 22 Oct 1999, Michael Smith wrote: > > > concrete classes vs. interfaces. If I recall correctly, we > > decided (at Minneapolis, was it?) that the binding spec > > itself should consist of a repertoire of interfaces > > rather than concrete classes. J & M have mostly complied > > We had decided this for the Name, Credentials and Context > classes only. We > had also decided we had to have a standard way for instantiating > implementations for these. > Having interfaces works well, but one needs a well defined method of instantiating these objects. A standard method of accomplishing this in Java is through a factory class, which is what we have followed. In the current draft update we modified the static methods of the factory class with instance methods. > > > with this, except for their "factory class", GSSManager, > > which they continue to specify as a concrete class. > > org.ietf.jgss.GSSManager will be the standard factory class > for these top > level interfaces. Its easy, logical, and less confusing to developers > since you are introducing new provider based factories in the SPI. > > > > J & M, however, have defined GSSManager as a > > concrete class incorporating some mechanism > > management functions. I have two problems with > > this: 1) these functions make no sense in the > > context of monolithic implementations, which is > > certainly one class of implementations we want > > to support, > > Applications don't want two separate API's for monolithic and > non-monolithic implementations. Our GSS-API has the bare > minimum addition > that can *optionally* enable the implementation to be non-monolithic. > Are you referring to the three methods (set/get provider) in GSSManager? These are used to set any provider preferences to the JGSS implementation. These methods need to be specified at the JGSS layer since applications programs will be insulated from any GSS internals. Also, these methods are clearly labeled as optional functions with specific exceptions they will throw in non-supported implementations. Applications wishing maximum interoperability would not use these, just like they would not insist on a specific provider. > > > and 2) J & M's management functions > > don't seem to me to be quite adequate for the > > purpose. > > We're willing to argue that the provider management > functionality you're > looking for is already there in the Java language API without > us needing > to duplicate it in the GSS-API. Please remember that provider > management > is not GSS-API. It's Java Crypto Architecture and that's being built > elsewhere. Unless you have a dire need for something new, its > best to not > bloat the API. > Michael, as we discussed this topic offline, we feel that bloating the GSS layer with management functions is unnecessary. Java provider framework supplies a rich toolbox of methods which make no sense to be duplicated here. And, as Mayank had demonstrated to you in our previous discussion, the existing framework can accomplish all the tasks you desired. I thought we came to agreement on this? > > > Rather than haggling with J & M over the > > management functions, though, I think we should > > do the following: > > Please, let's not haggle! Let's discuss this issue on technical and > practical merits. ========================================================================== 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 Oct 25 17:03:31 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05388 for ; Mon, 25 Oct 1999 17:03:30 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA23952 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 13:29:45 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA23939 for ; Mon, 25 Oct 1999 13:29:40 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 25 Oct 1999 20:29:40 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id QAA04919; Mon, 25 Oct 1999 16:28:59 -0400 Message-Id: <199910252028.QAA04919@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 25 Oct 1999 20:29:38 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Oct 1999 16:29:38 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: GSS: SPI and API Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Jack's and Mayank's comments on my suggestion (to remove management functions from the bindings document and make it an interfaces-only spec, as per Minneapolis) seem to fall into two categories: 1) Who ya gonna call? Con-structors! J & M argue that having the "factory class", GSSManager, be a concrete class gives programmers something to instantiate; whereas if they specify only interfaces, the programmer still needs to know what class to call the constructor of. I can't see that there's any difference for the programmer. Say we follow J & M's approach, and Sun ships a "standard" GSS implementation as part of the JDK and/or JRE under the package name org.ietf.jgss. To use this standard implementation, programmers do the following: (i) import org.ietf.jgss.*; [...] GSSManager gm = new GSSManager(); Now say we follow my approach, and Sun ships a GSS implementation under the package name sun.security.jgss (or something). To use this standard implementation, programmers do the following: (ii) import sun.security.jgss.*; [...] GSSManager gm = new GSSManager(); Under either proposal, programmers who need to use some other GSS package, whether because of export restrictions or because they really prefer FooBar, Inc.'s proprietary snake-oil crypto suite, or perhaps because they're applets and they've brought their own mechanisms with them down the wire, do the following: (iii) import com.foobar.jgss.* [...] GSSManager gm = new GSSManager(); No matter what, you still have to import something, and instantiate something. 2) Provide, provide! (apologies to R. Frost) Jack's references to "bloating" the API for management purposes puzzle me a bit. It was J & M who originally proposed to incorporate several flavors of AddProvider(java.security.Provider) methods to their GSSManager, specifically for use by "shim" implementations of GSSManager, even though non-shim implementations don't need it and can't support it. My idea, on the contrary, is to un-bloat the language binding in the strict sense by removing management functions to a supplementary interface, to be used only by those implementations that need it and can support it. One might tolerate AddProvider() coming along for the ride if it were really the only management method one needed, but I don't think it quite fills the bill. I may not be quite up-to-date on J & M's latest version of this call, since I can't seem to get to the I-D repository, but based on the latest version of their draft that I've seen: -- it provides no way of reversing the operation (removing a provider); -- it provides no way of taking whatever mechanisms are in a Provider and installing them without knowing their Oids; -- it provides no way of having multiple implementations of the same mechanism (which you might want to do, e.g., if they provided different profiles of options); -- it provides no way of ordering among the mechanisms provided by different Providers (except the clumsy expedient of adding them in the order you want them to be used); -- it provides no way of adding, dynamically and with instance scope, an implementation of a mechanism higher in the preference order than those loaded system-wide when the VM was initialized; -- it requires that any mechanism implementations you want to add need to be bundled in a Provider before the "shim" can assimilate them. (This last point may take a little explaining. A Provider is just a glorified hashtable, with the names of classes in it, and for cases where mechanisms come pre-packaged in this particular form of shrink-wrap, might as well use it. But if I already have a class implementing some mechanism that I want to use, why should I have to swaddle it in a Provider before I can hand it over to my shim?) These are top-of-the-head observations; others may occur to others. Perhaps the lesson here is that while the core GSS functionality in the binding has been extensively discussed, both in the WG and off-line, these mechanism management issues have hardly been aired at all. I don't think we should hold up the language binding any longer while we sort through these issues, and I don't think we should send the language binding out into the world with an insufficiently thought-through (and, in my view, just plain insufficient) management interface. Leave it for the SPI phase, where it belongs anyway, and let's move the language binding along if we're happy with it as it stands, qua binding. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Oct 25 19:43:06 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07452 for ; Mon, 25 Oct 1999 19:43:05 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id QAA04947 for ietf-cat-wg-out720680; Mon, 25 Oct 1999 16:14:50 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id QAA04939 for ; Mon, 25 Oct 1999 16:14:47 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA22365 for ; Mon, 25 Oct 1999 16:14:46 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Mon, 25 Oct 1999 16:14:46 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762366@pikachu.wrq.com> From: Joe Salowey To: ietf-cat-wg@lists.Stanford.EDU Subject: RE: GSS-API Java Bindings: Changes in new draft Date: Mon, 25 Oct 1999 16:14:44 -0700 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 I'd rather not see any more concrete classes in the API than we need to. A factory interface provides the capability of allowing the programmer to do most of what needs to be done in a standard way without forcing a particular implementation. The GSSManager class forces a particular implementation (it forces you to have a concrete class org.ietf.gssapi.GSSManager and it also assumes a provider infrastructure). I would rather see an interface here than a concrete class to get these tasks done. The interface would consist of createName createCredential createContext getMechs getNamesForMech getMechsForName I'm not sure much is gained by specifying this as a concrete class and I think flexibility is lost. The factory interface provides value for developers trying to use GSSAPI without constraining the underlying implementation. Joe > -----Original Message----- > From: Mayank Upadhyay [mailto:Mayank.Upadhyay@Eng.Sun.COM] > Sent: Friday, October 22, 1999 5:45 PM > To: ietf-cat-wg@lists.Stanford.EDU > Cc: Jack Kabat > Subject: GSS-API Java Bindings: Changes in new draft ... Text Removed > (6) Removed the GSSFactory interface > > Left it upto the SPI to define provider based GSSFactory's. The > GSSManger class provides factory methods to obtain instances of the > interfaces GSSName, GSSCredential, and GSSContext at the top > level. Those may or may not internally use any SPI level GSSFactory > obtained from providers. > > An application that wants to use its own custom complete GSS > implementation can simply subclass GSSManager from a standard GSS > package. > > This hides any SPI related functionality in the GSS layer. Mechanism > specific factories logically belong in the layer below the GSS. > Applications using the GSS-API should be isolated from the SPI layer. > > > (7) Changed static methods in GSSManger to non-static > > If any preferences are set through static methods, they influence all > code running in the same JVM. This is not an acceptable situation for > applets in the same browser. Also, applications can now instantiate > multiple GSSManager's and have different provider preferences on each > of them. Some of these GSSManager's may even be from the applications > own custom GSS implementation. > > > (8) Modified sample code to match the changes in the API. > > =================================================================== > > > ============================================================== > ============ > 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 Oct 26 13:09:28 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14463 for ; Tue, 26 Oct 1999 13:09:25 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA02291 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 09:36:03 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id JAA02273 for ; Tue, 26 Oct 1999 09:36:00 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 26 Oct 1999 16:35:59 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id MAA05891; Tue, 26 Oct 1999 12:35:18 -0400 Message-Id: <199910261635.MAA05891@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 26 Oct 1999 16:35:57 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1999 12:35:58 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: Java-GSS issues (NOT spi-related!) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I have a couple of suggestions for the Java binding, on the assumption that we have decided to proceed with Jack and Mayank's draft in substantially its present form. The second of these suggestions leads to a general observation. 1) Objects as tokens J & M at present provide two ways of giving tokens to context-establishment and per-message methods: byte array and InputStream. I'd like to suggest that input tokens be more broadly typed as Object. Here's why: There are existing security protocols which are highly intertwined with their application protocols. In such cases, security-related data may well be all mixed up with application data; a fair amount of manipulation may be needed to carve out a byte array representation of the information relevant to (e.g.) context establishment. Moreover, in an object-oriented language like Java, the application and security information may both be delivered to the application program encapsulated in some object representation. An actual example, encountered here at TIAA-CREF: We have an implementation of the DAA protocol for HTTP running under a local version of GSS. Now DAA works by setting certain headers in an HTTP request. In our case, this request arrives on the doorstep of our application code encapsulated in an object -- a ServletRequest, to be precise. It gets worse. We may have to swallow our pride and support Basic authentication for HTTP as well. Now Basic authentication also sets headers in HTTP, but in a different way. Moreover, we may decide to allow Basic authentication only over an SSL connection, just to give ourselves an illusory warm feeling. So if we want to deliver a byte array or stream token to (say) the context-acceptance method, our application needs to dig into the ServletRequest, determine whether it's Basic or DAA and if the former whether it arrived in a plain brown SSL wrapper or not, then quarry out some header contents and concatenate them into the array or the stream. Ugh! These are not details that the application programmers want to worry their pretty little heads about. As it happens, however, we are using (at present) a version of the GSS bindings which allows us to pass an Object -- specifically, in this case, a ServletRequest -- as a token. Our HTTP authentication mechanism understands all about HTTP headers and can ascertain very quickly with a few operations directly on the ServletRequest whether the authenticated request is kosher or not -- without ever having to go through the rigmarole of serializing snippets of HTTP header information into a byte array, and then turning around and parsing it. In short, I think that the repertoire of object types that it will be reasonable to pass to mechanisms will often depend on protocol and/or application and system context, and we'd be better off not trying to shoehorn 'em all into a byte sequence representation. If a mech gets an Object of a type it can't handle as a token, it just throws a bad-token exception precisely as it would do (under J & M's present arrangement) if the application screws up its construction of the byte array. A pleasing side effect would be to de-bloat the context interface by reducing the number of flavors of context-establishment and per-message calls: typing the token as Object covers both the present byte-array and input-stream cases. In this case, the context-establishment calls and per-message calls would be typed as returning a byte array (the output token) and taking a token input parameter of Object, with an (optionally null) OutputStream parameter in case you want the output token on a stream rather than a byte array. 2) Channel bindings J & M at present define a ChannelBinding class which can incorporate a couple of java.net.InetAddresses plus a catchall in the form of a byte array. Here agin, I think the goal would be achieved more simply by typing the channel-bindings parameters to context calls as Object. The reasoning is similar: applications may be communicating over protocols other than TCP/IP, or they may be using networking classes other than java.net to do it, or their "channels" may actually be purely logical constructs unrelated to underlying transport -- for example, the kind of logical "sessions" that Web applications keep track of (and that middleware vendors tend to serve up cookies for). And again, these "channels" real and logical are likely to be represented by an extensive menagerie of objects. This generalization would give us a further de-bloat, to the extent of an entire interface! At this rate, the spec will be positively anorectic. 3) A general observation Point 2) above leads into this. I think it's a bad idea to build into our Java binding any unnecessary dependencies on non-fundamental elements of the Java developer's kit or particular runtime environments. (This was also part of my reason for taking a somewhat dim view of Providers in the SPI work; I don't mind using 'em if they're available, but I don't want to depend on 'em). There are a lot of cool gadgets in the JRE and the JDK, and I understand the impulse to put them through their paces. Nevertheless, there are certain virtues in orthogonality too. Don't misunderstand me: I'm not one of those people who thinks that Java is "just another programming language." (Are there really any such people, I wonder?) Nevertheless, it isn't a mere legalism to observe that we are trying to produce a _language_ binding, not a binding to an entire, comprehensive, soup-to-nuts environment. Of course we're all grateful to the developers of Java for providing developers with an underground railroad off the platform plantations. Once they find themselves on free soil, however, many of them will just want to till their own forty acres in peace, rather than sign on at another big spread. And we IETF-niks surely don't want to sell them a cow when what they're looking for is just a glass of milk. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Oct 26 13:39:08 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15920 for ; Tue, 26 Oct 1999 13:39:05 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA11904 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 10:12:21 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA11877 for ; Tue, 26 Oct 1999 10:12:16 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA19190; Tue, 26 Oct 1999 10:12:12 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Tue, 26 Oct 1999 10:12:11 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762368@pikachu.wrq.com> From: Joe Salowey To: "'Michael Smith'" , ietf-cat-wg@lists.Stanford.EDU Subject: RE: Java-GSS issues (NOT spi-related!) Date: Tue, 26 Oct 1999 10:12:09 -0700 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 Objects as tokens is BAD. I see no way to have any level of interoperability with this. A byte array is a well defined object that can be dealt with is a known way. Likewise as input stream is a well defined object that has useful methods. java.lang.Object is well defined, but it does not have very many useful methods (unless you want to convert every thing into an ASCII encoded string). Just by knowing that something is an Object there is very little I can do with it. If you need to deal with other objects this should be done in a layer outside the GSSAPI and pass only the appropriate mechanism data in a byte array or input stream into the GSSAPI. If you allow generic objects then you GSSAPI mechanisms become application specific which I do not think is the original intent. Joe > -----Original Message----- > From: Michael Smith [mailto:ms@gf.org] > Sent: Tuesday, October 26, 1999 10:36 AM > To: ietf-cat-wg@lists.Stanford.EDU > Subject: Java-GSS issues (NOT spi-related!) > > > I have a couple of suggestions for the Java binding, > on the assumption that we have decided to proceed with > Jack and Mayank's draft in substantially its present > form. The second of these suggestions leads to a > general observation. > > 1) Objects as tokens > > J & M at present provide two ways of giving tokens > to context-establishment and per-message methods: byte > array and InputStream. I'd like to suggest that input > tokens be more broadly typed as Object. Here's why: > > There are existing security protocols which are > highly intertwined with their application protocols. > In such cases, security-related data may well > be all mixed up with application data; a fair amount > of manipulation may be needed to carve out a byte array > representation of the information relevant to (e.g.) > context establishment. Moreover, in an object-oriented > language like Java, the application and security > information may both be delivered to the application > program encapsulated in some object representation. > > An actual example, encountered here at TIAA-CREF: > > We have an implementation of the DAA protocol for HTTP > running under a local version of GSS. Now DAA works by > setting certain headers in an HTTP request. In our case, > this request arrives on the doorstep of our application > code encapsulated in an object -- a ServletRequest, to > be precise. > > It gets worse. We may have to swallow our pride and > support Basic authentication for HTTP as well. Now Basic > authentication also sets headers in HTTP, but in a different > way. > > Moreover, we may decide to allow Basic authentication only > over an SSL connection, just to give ourselves an illusory > warm feeling. > > So if we want to deliver a byte array or stream token to > (say) the context-acceptance method, our application needs > to dig into the ServletRequest, determine whether it's Basic > or DAA and if the former whether it arrived in a plain brown > SSL wrapper or not, then quarry out some header contents and > concatenate them into the array or the stream. Ugh! These are > not details that the application programmers want to worry > their pretty little heads about. > > As it happens, however, we are using (at present) a version > of the GSS bindings which allows us to pass an Object -- > specifically, in this case, a ServletRequest -- as a token. > Our HTTP authentication mechanism understands all about HTTP > headers and can ascertain very quickly with a few operations > directly on the ServletRequest whether the authenticated request > is kosher or not -- without ever having to go through the > rigmarole of serializing snippets of HTTP header information > into a byte array, and then turning around and parsing it. > > In short, I think that the repertoire of object types that > it will be reasonable to pass to mechanisms will often depend > on protocol and/or application and system context, and we'd > be better off not trying to shoehorn 'em all into a byte sequence > representation. If a mech gets an Object of a type it can't > handle as a token, it just throws a bad-token exception precisely > as it would do (under J & M's present arrangement) if the > application screws up its construction of the byte array. > > A pleasing side effect would be to de-bloat the context interface > by reducing the number of flavors of context-establishment and > per-message calls: typing the token as Object covers both the > present byte-array and input-stream cases. In this case, the > context-establishment calls and per-message calls would be typed > as returning a byte array (the output token) and taking a token > input parameter of Object, with an (optionally null) OutputStream > parameter in case you want the output token on a stream rather > than a byte array. > > 2) Channel bindings > > J & M at present define a ChannelBinding class which can incorporate > a couple of java.net.InetAddresses plus a catchall in the form of > a byte array. Here agin, I think the goal would be achieved more > simply by typing the channel-bindings parameters to context calls > as Object. > > The reasoning is similar: applications may be communicating > over protocols other than TCP/IP, or they may be using networking > classes other than java.net to do it, or their "channels" may > actually be purely logical constructs unrelated to underlying > transport -- for example, the kind of logical "sessions" that Web > applications keep track of (and that middleware vendors tend to > serve up cookies for). And again, these "channels" real and logical > are likely to be represented by an extensive menagerie of > objects. > > This generalization would give us a further de-bloat, to the > extent of an entire interface! At this rate, the spec will be > positively anorectic. > > 3) A general observation > > Point 2) above leads into this. I think it's a bad idea to > build into our Java binding any unnecessary dependencies on > non-fundamental elements of the Java developer's kit or > particular runtime environments. (This was also part of my > reason for taking a somewhat dim view of Providers in the SPI > work; I don't mind using 'em if they're available, but I don't > want to depend on 'em). There are a lot of cool gadgets in the > JRE and the JDK, and I understand the impulse to put them > through their paces. Nevertheless, there are certain virtues > in orthogonality too. > > Don't misunderstand me: I'm not one of those people who thinks > that Java is "just another programming language." (Are there > really any such people, I wonder?) Nevertheless, it isn't > a mere legalism to observe that we are trying to produce > a _language_ binding, not a binding to an entire, comprehensive, > soup-to-nuts environment. > > Of course we're all grateful to the developers of Java for > providing developers with an underground railroad off the > platform plantations. Once they find themselves on free soil, > however, many of them will just want to till their own forty > acres in peace, rather than sign on at another big spread. > And we IETF-niks surely don't want to sell them a cow > when what they're looking for is just a glass of milk. > > --Michael Smith > ms@gf.org > > ============================================================== > ============ > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Oct 26 15:20:22 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21235 for ; Tue, 26 Oct 1999 15:20:21 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA05584 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 11:45:02 -0700 (PDT) Received: from relay.gw.tislabs.com (firewall-user@relay.gw.tislabs.com [192.94.214.100]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA05554 for ; Tue, 26 Oct 1999 11:44:55 -0700 (PDT) Received: by relay.gw.tislabs.com; id OAA11847; Tue, 26 Oct 1999 14:53:57 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma011834; Tue, 26 Oct 99 14:53:30 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id OAA21635 for ietf-cat-wg@lists.stanford.edu; Tue, 26 Oct 1999 14:43:26 -0400 (EDT) Date: Tue, 26 Oct 1999 14:43:26 -0400 (EDT) From: "David M. Balenson" Message-Id: <199910261843.OAA21635@clipper.gw.tislabs.com> To: ietf-cat-wg@lists.Stanford.EDU Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - Intrusion Detection Research, Instructor TBD FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Oct 26 15:20:41 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21249 for ; Tue, 26 Oct 1999 15:20:41 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA05435 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 11:44:24 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id LAA05417 for ; Tue, 26 Oct 1999 11:44:20 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 26 Oct 1999 18:44:20 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id OAA06227; Tue, 26 Oct 1999 14:43:39 -0400 Message-Id: <199910261843.OAA06227@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 26 Oct 1999 18:44:18 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1999 14:44:19 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: RE: Java-GSS issues (NOT spi-related!) Cc: Joe Salowey Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 10:12 AM 10/26/99 -0700, Joe Salowey wrote: >Objects as tokens is BAD. [....] >A byte array is a well defined object that can >be dealt with is a known way. Well, yes and no. If the application has to build a byte array (or stream) from snips and snaps of information that it winkles out of some object, then presumably it has to know the token format (often very far from well-defined) required by whatever mechanism it's submitting the byte array to. The application's innocence has already, so to speak, been lost. I don't see that this is superior in any way to the loss of innocence involved in knowing that such-and-such a mechanism can accept, say, a ServletRequest or whatever. What we did here was define methods that returned an array of Class objects indicating what kinds of objects were acceptable as tokens. We could also, of course, mandate that all mechanisms must support AT LEAST a byte array as an input token, and (at their discretion) other kinds of objects as well. This would preserve flexibility AND interoperability. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Oct 26 15:47:27 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22811 for ; Tue, 26 Oct 1999 15:47:27 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA11592 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 12:08:48 -0700 (PDT) Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA11577 for ; Tue, 26 Oct 1999 12:08:44 -0700 (PDT) Received: from jtrostle-pc1 ([10.19.59.100]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA13771; Tue, 26 Oct 1999 12:08:07 -0700 (PDT) Message-Id: <3.0.5.32.19991026120815.00edc100@nsm-mail2.cisco.com> X-Sender: jtrostle@nsm-mail2.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 26 Oct 1999 12:08:15 -0700 To: "Linn, John" , "'CAT-WG List'" From: Jonathan Trostle Subject: Re: Next steps for CAT In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Regarding kerb-set-passwd-00.txt, there is another implementation underway outside of Cisco and Microsoft. It seems the limited discussion criteria would apply to a lot of the drafts in the CAT WG. Jonathan At 10:16 AM 10/7/99 -0400, Linn, John wrote: >CAT fanciers: > >I've not yet heard from the IETF Secretariat about scheduling of a CAT >session for the Washington, DC IETF (8-12 November), but will update the >list as further information is available. The WG mailing list has been very >quiet since the Oslo meeting, and I hope that we can achieve closure on as >many items as possible before the conclusion of the DC meeting. Based on >currently reported plans for draft revisions, and comparing against the WG >milestones list at http://www.ietf.org/html.charters/cat-charter.html, my >current understandings (and embedded questions) regarding potential >standards-track actions are as follows: > >(1) We've decided not to pursue standards-track advancement for >authorization documents, though these may become candidates for Experimental >RFC publication. > >(2) The apparent sense of the group regarding low-infrastructure mechanism >definitions is to pursue standards-track advancement of LIPKEY. A revision >to draft-ietf-cat-lipkey-01 is needed, per discussion noted in Oslo minutes. >Question: will this upcoming revision be sufficient and suitable for WG >Last-Call? > >(3) The GSS Java bindings specification, gssv2-javabind-02, is to be revised >within the I-D submission window which closes on 22 October, and discussion >is intended for the DC meeting. Advancement of this document is a >recognized priority. It was proposed at the Oslo meeting that discussion of >SPI requirements be undertaken before advancement of gssv2-javabind, but >this discussion has not yet proceeded on the list. Question: should >progress of gssv2-javabind remain serialized on pending SPI discussion, or >should it proceed towards WG Last-Call in the absence of such discussion? > >(4) Per discussion at Oslo, revisions are pending to both pk-init and >kerberos-revisions; given that these documents are related, it was >considered appropriate for a concurrent WG Last-Call to be undertaken once >suitable versions of both documents are available. > >(5) Two other Kerberos-related drafts, kerberos-extra-tgt-02 and >kerberos-set-passwd-00, have been posted since the Oslo meeting but have >received limited discussion on the mailing list. Question: Does >constituency and consensus exist for progressing the contents of these >documents on the standards track and, if so, how should this be pursued >relative to the ongoing development of kerberos-revisions? > >(6) An SPKM-related draft, ecdh-spkm-00, has been posted since the Oslo >meeting but has not yet been discussed on the mailing list. Question: does >constituency and consensus exist for progressing this document on the >standards track? > >--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 Oct 26 16:12:51 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24100 for ; Tue, 26 Oct 1999 16:12:50 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA19187 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 12:37:51 -0700 (PDT) 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 MAA19169 for ; Tue, 26 Oct 1999 12:37:47 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 26 Oct 1999 19:36:29 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 PAA07627; Tue, 26 Oct 1999 15:31:52 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 26 Oct 1999 15:39:16 -0400 Message-ID: From: "Linn, John" To: "'Jonathan Trostle'" , "Linn, John" , "'CAT-WG List'" Subject: RE: Next steps for CAT Date: Tue, 26 Oct 1999 15:44:17 -0400 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 Jonathan writes: > Regarding kerb-set-passwd-00.txt, there is another > implementation underway > outside of Cisco and Microsoft. > > It seems the limited discussion criteria would apply to a lot > of the drafts > in the CAT WG. > Quite true, both within CAT and elsewhere. The overall IETF-level criteria for standards track advancement require not only consensus acceptance of the content of a document, but also demonstrated constituency of interest in the document. Until and unless members of a WG engage in discussion of a document, it is difficult to validate either consensus or constituency. --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 Oct 26 16:26:09 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24845 for ; Tue, 26 Oct 1999 16:26:08 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA20853 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 12:43:53 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA20829 for ; Tue, 26 Oct 1999 12:43:49 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA27453; Tue, 26 Oct 1999 12:43:46 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Tue, 26 Oct 1999 12:43:46 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762369@pikachu.wrq.com> From: Joe Salowey To: "'Michael Smith'" , ietf-cat-wg@lists.Stanford.EDU Cc: Joe Salowey Subject: RE: Java-GSS issues (NOT spi-related!) Date: Tue, 26 Oct 1999 12:43:43 -0700 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 > >A byte array is a well defined object that can > >be dealt with is a known way. > > Well, yes and no. If the application has to build a byte array > (or stream) from snips and snaps of information that it winkles > out of some object, then presumably it has to know the token format > (often very far from well-defined) required by whatever mechanism > it's submitting the byte array to. The application's innocence has The token format for your home grown mechanism may be ill-defined, but GSSAPI token formats are well defined and they are application and platform independant (except for perhaps channel bindings)!! Each mechanism has an RFC or at least internet draft that describes this. The point is a mechanism given a byte array or an input stream knows how to extract the data from them. Given a java.lang.Object there is no method except perhaps toString() (UGH!) which the mechanism can use to extract. Although java is a platform independent language, requiring all mechanisms (regardless of what platform they are on) to deal with java objects is not a platform independent solution. The mechanism you are dealing with seems very implementation specific. -Joe ========================================================================== 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 Oct 26 16:38:17 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25475 for ; Tue, 26 Oct 1999 16:38:14 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA27144 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 13:07:19 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA27116 for ; Tue, 26 Oct 1999 13:07:11 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 26 Oct 1999 20:07:11 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id QAA06419; Tue, 26 Oct 1999 16:06:30 -0400 Message-Id: <199910262006.QAA06419@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 26 Oct 1999 20:07:09 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1999 16:07:10 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: RE: Java-GSS issues (NOT spi-related!) Cc: Joe Salowey Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 12:43 PM 10/26/99 -0700, Joe Salowey wrote: >The token format for your home grown mechanism may be ill-defined, but >GSSAPI token formats are well defined and they are application and platform >independant I can't take credit for DAA -- it's a IETF standard, as a matter of fact. > The point is a >mechanism given a byte array or an input stream knows how to extract the >data from them. Yes, the mechanism might know, but the problem lies on the other side: with the application trying to construct it. >Given a java.lang.Object there is no method except perhaps >toString() (UGH!) which the mechanism can use to extract. Not what I had in mind. To say that a mechanism implementation accepts, say, ServletRequest means that the mech. impl. understands how to use the methods of ServletRequest to get the information it needs. > Although java is >a platform independent language, requiring all mechanisms (regardless of >what platform they are on) to deal with java objects is not a platform >independent solution. Again, the idea is that various mech. impl's might accommodate various kinds of objects (and possibly advertise these accommodations) -- not that ANY impl. would accommodate ANY object. > >The mechanism you are dealing with seems very implementation specific. > Very application-protocol-specific, anyway. But such things do happen. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Oct 26 16:50:43 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26302 for ; Tue, 26 Oct 1999 16:50:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA29089 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 13:14:47 -0700 (PDT) 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 NAA29063 for ; Tue, 26 Oct 1999 13:14:43 -0700 (PDT) Received: from barbar.esat.kuleuven.ac.be by MIT.EDU with SMTP id AA27277; Tue, 26 Oct 99 16:14:32 EDT Received: from bronx (bronx.esat.kuleuven.ac.be [134.58.189.79]) by barbar (version 8.8.5) with ESMTP id WAA13048; Tue, 26 Oct 1999 22:14:36 +0200 (METDST) Organization: ESAT, K.U.Leuven, Belgium Date: Tue, 26 Oct 1999 22:14:36 +0200 (CEST) From: Eurocrypt 2000 X-Sender: ec2000@bronx To: cat-ietf@mit.edu Subject: Eurocrypt 2000 submission deadline: November 3, 1999 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk ------------------------------------------------------------- E U R O C R Y P T 2 0 0 0 May 14-18, 2000 Bruges (Brugge), Belgium http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ ------------------------------------------------------------- This is a reminder that the submission deadline for Eurocrypt 2000 is November 3, 1999. Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ for more information. ------------------------------------------------------------- ========================================================================== 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 Oct 26 18:32:53 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02526 for ; Tue, 26 Oct 1999 18:32:52 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA27449 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 15:04:37 -0700 (PDT) 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 PAA27435 for ; Tue, 26 Oct 1999 15:04:33 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Oct 1999 14:54:40 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2167F52@seine.valicert.com> From: Jack Kabat To: Joe Salowey , "'Michael Smith'" Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: Java-GSS issues (NOT spi-related!) Date: Tue, 26 Oct 1999 14:54:36 -0700 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 I completely agree with Joe. What ever is passed into the JGSS to represent tokens has to have a clear API on how to read/write data to it. Object class does not have this. The reason for adding streams was precisely so that an application can pass its own data processing stream (but after removing application specific data). GSS-API (Java and other) have always dealt with just GSS-API tokens. Application tokens are processed by the application, and GSS-API is responsible for only processing the GSS-API part of the load. Mayank and I are open to changing the stream oriented methods to take other objects but ones that have a clear interface for reading and writing data. We used streams because they fit this requirement. Regards, Jack > -----Original Message----- > From: Joe Salowey [mailto:joes@wrq.com] > Sent: Tuesday, October 26, 1999 10:12 AM > To: 'Michael Smith'; ietf-cat-wg@lists.Stanford.EDU > Subject: RE: Java-GSS issues (NOT spi-related!) > > > Objects as tokens is BAD. I see no way to have any level of > interoperability with this. A byte array is a well defined > object that can > be dealt with is a known way. Likewise as input stream is a > well defined > object that has useful methods. java.lang.Object is well > defined, but it > does not have very many useful methods (unless you want to > convert every > thing into an ASCII encoded string). Just by knowing that > something is an > Object there is very little I can do with it. If you need to > deal with > other objects this should be done in a layer outside the > GSSAPI and pass > only the appropriate mechanism data in a byte array or input > stream into the > GSSAPI. If you allow generic objects then you GSSAPI > mechanisms become > application specific which I do not think is the original intent. > > Joe > > > -----Original Message----- > > From: Michael Smith [mailto:ms@gf.org] > > Sent: Tuesday, October 26, 1999 10:36 AM > > To: ietf-cat-wg@lists.Stanford.EDU > > Subject: Java-GSS issues (NOT spi-related!) > > > > > > I have a couple of suggestions for the Java binding, > > on the assumption that we have decided to proceed with > > Jack and Mayank's draft in substantially its present > > form. The second of these suggestions leads to a > > general observation. > > > > 1) Objects as tokens > > > > J & M at present provide two ways of giving tokens > > to context-establishment and per-message methods: byte > > array and InputStream. I'd like to suggest that input > > tokens be more broadly typed as Object. Here's why: > > > > There are existing security protocols which are > > highly intertwined with their application protocols. > > In such cases, security-related data may well > > be all mixed up with application data; a fair amount > > of manipulation may be needed to carve out a byte array > > representation of the information relevant to (e.g.) > > context establishment. Moreover, in an object-oriented > > language like Java, the application and security > > information may both be delivered to the application > > program encapsulated in some object representation. > > > > An actual example, encountered here at TIAA-CREF: > > > > We have an implementation of the DAA protocol for HTTP > > running under a local version of GSS. Now DAA works by > > setting certain headers in an HTTP request. In our case, > > this request arrives on the doorstep of our application > > code encapsulated in an object -- a ServletRequest, to > > be precise. > > > > It gets worse. We may have to swallow our pride and > > support Basic authentication for HTTP as well. Now Basic > > authentication also sets headers in HTTP, but in a different > > way. > > > > Moreover, we may decide to allow Basic authentication only > > over an SSL connection, just to give ourselves an illusory > > warm feeling. > > > > So if we want to deliver a byte array or stream token to > > (say) the context-acceptance method, our application needs > > to dig into the ServletRequest, determine whether it's Basic > > or DAA and if the former whether it arrived in a plain brown > > SSL wrapper or not, then quarry out some header contents and > > concatenate them into the array or the stream. Ugh! These are > > not details that the application programmers want to worry > > their pretty little heads about. > > > > As it happens, however, we are using (at present) a version > > of the GSS bindings which allows us to pass an Object -- > > specifically, in this case, a ServletRequest -- as a token. > > Our HTTP authentication mechanism understands all about HTTP > > headers and can ascertain very quickly with a few operations > > directly on the ServletRequest whether the authenticated request > > is kosher or not -- without ever having to go through the > > rigmarole of serializing snippets of HTTP header information > > into a byte array, and then turning around and parsing it. > > > > In short, I think that the repertoire of object types that > > it will be reasonable to pass to mechanisms will often depend > > on protocol and/or application and system context, and we'd > > be better off not trying to shoehorn 'em all into a byte sequence > > representation. If a mech gets an Object of a type it can't > > handle as a token, it just throws a bad-token exception precisely > > as it would do (under J & M's present arrangement) if the > > application screws up its construction of the byte array. > > > > A pleasing side effect would be to de-bloat the context interface > > by reducing the number of flavors of context-establishment and > > per-message calls: typing the token as Object covers both the > > present byte-array and input-stream cases. In this case, the > > context-establishment calls and per-message calls would be typed > > as returning a byte array (the output token) and taking a token > > input parameter of Object, with an (optionally null) OutputStream > > parameter in case you want the output token on a stream rather > > than a byte array. > > > > 2) Channel bindings > > > > J & M at present define a ChannelBinding class which can incorporate > > a couple of java.net.InetAddresses plus a catchall in the form of > > a byte array. Here agin, I think the goal would be achieved more > > simply by typing the channel-bindings parameters to context calls > > as Object. > > > > The reasoning is similar: applications may be communicating > > over protocols other than TCP/IP, or they may be using networking > > classes other than java.net to do it, or their "channels" may > > actually be purely logical constructs unrelated to underlying > > transport -- for example, the kind of logical "sessions" that Web > > applications keep track of (and that middleware vendors tend to > > serve up cookies for). And again, these "channels" real and logical > > are likely to be represented by an extensive menagerie of > > objects. > > > > This generalization would give us a further de-bloat, to the > > extent of an entire interface! At this rate, the spec will be > > positively anorectic. > > > > 3) A general observation > > > > Point 2) above leads into this. I think it's a bad idea to > > build into our Java binding any unnecessary dependencies on > > non-fundamental elements of the Java developer's kit or > > particular runtime environments. (This was also part of my > > reason for taking a somewhat dim view of Providers in the SPI > > work; I don't mind using 'em if they're available, but I don't > > want to depend on 'em). There are a lot of cool gadgets in the > > JRE and the JDK, and I understand the impulse to put them > > through their paces. Nevertheless, there are certain virtues > > in orthogonality too. > > > > Don't misunderstand me: I'm not one of those people who thinks > > that Java is "just another programming language." (Are there > > really any such people, I wonder?) Nevertheless, it isn't > > a mere legalism to observe that we are trying to produce > > a _language_ binding, not a binding to an entire, comprehensive, > > soup-to-nuts environment. > > > > Of course we're all grateful to the developers of Java for > > providing developers with an underground railroad off the > > platform plantations. Once they find themselves on free soil, > > however, many of them will just want to till their own forty > > acres in peace, rather than sign on at another big spread. > > And we IETF-niks surely don't want to sell them a cow > > when what they're looking for is just a glass of milk. > > > > --Michael Smith > > ms@gf.org > > > > ============================================================== > > ============ > > This message was posted through the Stanford campus mailing list > > server. If you wish to unsubscribe from this mailing list, send the > > message body of "unsubscribe ietf-cat-wg" to > > majordomo@lists.stanford.edu > > > ============================================================== > ============ > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > ========================================================================== 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 Oct 26 19:08:30 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04244 for ; Tue, 26 Oct 1999 19:08:30 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA06439 for ietf-cat-wg-out720680; Tue, 26 Oct 1999 15:38:25 -0700 (PDT) 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 PAA06426 for ; Tue, 26 Oct 1999 15:38:22 -0700 (PDT) Received: from taller.eng.sun.com ([129.144.124.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05439; Tue, 26 Oct 1999 15:38:20 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id PAA28033; Tue, 26 Oct 1999 15:38:16 -0700 (PDT) Date: Tue, 26 Oct 1999 15:38:19 -0700 (PDT) From: Mayank Upadhyay Reply-To: Mayank Upadhyay To: Michael Smith cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: GSS: SPI and API In-Reply-To: <199910252028.QAA04919@gf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > Now say we follow my approach, and Sun ships a GSS implementation > under the package name sun.security.jgss (or something). > To use this standard implementation, programmers do the following: > > (ii) import sun.security.jgss.*; > [...] > GSSManager gm = new GSSManager(); I think this is misleading and needs clarification. Sun would like to work with the IETF to define the specification for the standard API that Sun will ship. In other words, Sun will ship org.ietf.jgss. Applications that need to be portable will instantiate classes from org.ietf.jgss because that is the IETF defined standard. A small minority of applications will subclass classes in org.ietf.jgss to do things that they specifically need. Most will just add functionality to the existing GSS-API in their JRE using the one hook that we have for the Java provider model (i.e., GSSManager.setProvider). -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 Wed Oct 27 08:40:29 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08773 for ; Wed, 27 Oct 1999 08:40:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id FAA24913 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 05:04:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id FAA24896 for ; Wed, 27 Oct 1999 05:03:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06888; Wed, 27 Oct 1999 08:03:53 -0400 (EDT) Message-Id: <199910271203.IAA06888@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-init-10.txt Date: Wed, 27 Oct 1999 08:03:52 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos Author(s) : B. Tung, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, J. Trostle Filename : draft-ietf-cat-kerberos-pk-init-10.txt Pages : 18 Date : 26-Oct-99 This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.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-init-10.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-init-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991026145005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-init-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991026145005.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 Wed Oct 27 10:51:11 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14953 for ; Wed, 27 Oct 1999 10:51:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA21766 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 06:50:43 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id GAA21751 for ; Wed, 27 Oct 1999 06:50:40 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 27 Oct 1999 13:50:39 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id JAA07571; Wed, 27 Oct 1999 09:49:58 -0400 Message-Id: <199910271349.JAA07571@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 27 Oct 1999 13:50:38 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1999 09:50:38 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: What's in a name? (was: GSS SPI/API) Cc: Mayank Upadhyay Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 03:38 PM 10/26/99 -0700, Mayank Upadhyay wrote: >Sun would like to work with the IETF to define the specification for the >standard API that Sun will ship. In other words, Sun will ship >org.ietf.jgss. Applications that need to be portable will instantiate >classes from org.ietf.jgss because that is the IETF defined standard. So the intent here is that a package bearing the IETF's name will in fact be something produced by Sun, and "applications that want to be portable" will have to use this vendor-provided package? This seems to put the IETF in the position of saying, in effect, that the "open standard" is... so-and-so's code. Perhaps older IETF hands than I can tell me whether this is usual or not. Perhaps I was a bit too oblique in an earlier e-mail when I tried to articulate a concern which some of us feel about the future of Java and its relationship with standards bodies like the IETF. Java has been a liberating force so far. But because Java is, in a sense, Private Property, there will always be a risk that it could turn around and become a means for renewed single-vendor control of the programming environment. I personally feel that the IETF should avoid, where possible, doing anything that might tend toward this outcome. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 27 12:48:02 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22259 for ; Wed, 27 Oct 1999 12:48:01 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA20181 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 08:45:37 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id IAA20145 for ; Wed, 27 Oct 1999 08:45:29 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 27 Oct 1999 15:45:29 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id LAA07811; Wed, 27 Oct 1999 11:44:47 -0400 Message-Id: <199910271544.LAA07811@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 27 Oct 1999 15:45:27 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1999 11:45:27 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: Objects as tokens (was: GSSAPI issues...) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 02:54 PM 10/26/99 -0700, Jack Kabat wrote: >What ever is passed into the JGSS to represent tokens has >to have a clear API on how to read/write data to it. >Object class does not have this. I see that I've given both Jack and Joe the same mistaken impression of what I had in mind; obviously I expressed myself badly. May I ask the list's indulgence to re-state my suggestion in a (hopefully) clearer way? My idea was simply to TYPE (forgive the caps) the token parameters, in the interfaces, as Object, solely so as not to constrain what kind of objects could, in particular cases, be used as tokens. This was not intended to suggest that any mechanism could take any kind of object, or that mechanisms would have to restrict themselves to the exiguous repertoire of methods that Object has, in processing tokens. Rather, my idea was that particular mechanisms (or mech implementations, MIs) might well want to support, as tokens, kinds of objects above and beyond byte arrays. The kinds of objects they'd want to support would depend, perhaps, on the nature of the security protocol and/or the application protocol and on the repertoire of object representations associated with these. It wouldn't be the same list for every mechanism, or MI, and many mechanisms, no doubt, would find that byte-array filled all the requirements. An MI's implementation of one of these Object-typed methods would begin by finding out exactly what _kind_ of object was passed in as a token, and then going off to code written to process that particular kind of object, using whatever methods that object supports. If it got an object that it didn't support as a token, it would throw an exception -- precisely as it would do if it got a syntactically malformed token in a byte array. How would applications know what kinds of objects they could use as tokens? Here, we added methods -- Class[] getContextTokenClasses() and Class[] getMessageTokenClasses() -- to advertise what the mechanisms could handle. Here's some code fragments, adapted from the stuff we're using here: /* From a mechanism implementation Heavily edited and not guaranteed to compile */ /** * Utility function to tell callers what kinds of objects are acceptable * as context-establishment tokens. Note that byte [] is always acceptable. * */ public Class[] getContextTokenClasses() { Class accepts[] = new Class[1] ; try { accepts [0] = Class.forName("javax.servlet.http.HttpServletRequest"); } catch (Exception e) { Class [] nullaccepts = {}; return nullaccepts; } return accepts; } /* I'm reluctant to show you any real mechanism code, it's such a dog's breakfast, but here's the general appearance of the logic that branches on token type: */ public void accept(Object token) throws GSSException { byte[] b = {1,2,3}; Class bclass = b.getClass(); Class sclass; try { sclass = Class.forName("javax.servlet.http.HttpServletRequest"); } catch (Exception e) { sclass = null; } if ((token.getClass()).equals(bclass)) { // Do something with the byte array return; } if ((token.getClass()).equals(sclass)) { // Do something with the ServletRequest return; } throw new GSSException ( new BasicGSSStatus (GSSStatus.GSS_S_BAD_TOKEN, (short)0, // Revisit this and signal more detail? (short)0, null) ); } --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 27 13:36:50 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25481 for ; Wed, 27 Oct 1999 13:36:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id JAA03387 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 09:37:36 -0700 (PDT) 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 JAA03375 for ; Wed, 27 Oct 1999 09:37:33 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11182; Wed, 27 Oct 1999 09:37:30 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA14716; Wed, 27 Oct 1999 09:34:52 -0700 (PDT) Received: from teal (awe8-127.Central.Sun.COM [129.147.8.127]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA906356; Wed, 27 Oct 1999 09:34:50 -0700 (PDT) Date: Wed, 27 Oct 1999 09:37:30 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: Re: Objects as tokens (was: GSSAPI issues...) To: Michael Smith Cc: ietf-cat-wg@lists.Stanford.EDU In-Reply-To: "Your message with ID" <199910271544.LAA07811@gf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > My idea was simply to TYPE (forgive the caps) the token > parameters, in the interfaces, as Object, solely so as > not to constrain what kind of objects could, in particular > cases, be used as tokens. This was not intended to > suggest that any mechanism could take any kind of object, > or that mechanisms would have to restrict themselves to > the exiguous repertoire of methods that Object has, in > processing tokens. Would a peer, bound to the C-bindings GSS-API be able to accept and process these tokens? -mre ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 27 13:43:33 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25891 for ; Wed, 27 Oct 1999 13:43:31 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA09624 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 10:01:47 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id KAA09609 for ; Wed, 27 Oct 1999 10:01:43 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 27 Oct 1999 17:01:43 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id NAA07982; Wed, 27 Oct 1999 13:01:02 -0400 Message-Id: <199910271701.NAA07982@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 27 Oct 1999 17:01:41 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1999 13:01:42 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: Re: Objects as tokens (was: GSSAPI issues...) Cc: Mike Eisler Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 09:37 AM 10/27/99 -0700, Mike Eisler wrote: > [You wrote] >> My idea was simply to TYPE (forgive the caps) the token >> parameters, in the interfaces, as Object, solely so as >> not to constrain what kind of objects could, in particular >> cases, be used as tokens. [...] >Would a peer, bound to the C-bindings GSS-API be able to accept and process >these tokens? It would, presumably, never see them. I don't imagine that in general, object encapsulations of protocols and protocol elements will be what are sent over the wire. Protocols define sequences of bytes, but in the OO world, we program to object interfaces which encapsulate protocols and other things. Traditionally, GSS has presupposed -- without being completely explicit about it -- that the GSS caller, or user or whatever, is some entity that's getting stuff right off the wire. But it ain't necessarily so. Applications in the OO world often see stuff "off the wire" in a highly mediated form. Presumably "a peer, bound to the C-bindings GSS-API" is written in C and is thus not (particularly) object-oriented, and therefore not likely to be seeing stuff off the wire in an object-mediated form. An analogy: Unix sockets and "Winsock" are not the same software representation of UDP and TCP wire protocols, but they can interoperate (or at least that's the idea). --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 27 17:58:05 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11987 for ; Wed, 27 Oct 1999 17:58:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA13344 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 14:19:52 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id NAA10970 for ; Wed, 27 Oct 1999 13:56:55 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA23216; Wed, 27 Oct 1999 13:56:52 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Wed, 27 Oct 1999 13:56:51 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762370@pikachu.wrq.com> From: Joe Salowey To: "'Michael Smith'" , ietf-cat-wg@lists.Stanford.EDU Subject: RE: Objects as tokens (was: GSSAPI issues...) Date: Wed, 27 Oct 1999 13:56:49 -0700 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 I can see the value in passing a generic object in as a token, but I think this behavior has a number of implications. First the GSSv2 RFC defines tokens as OCTET STRINGs not objects, so changing this in the language binding is not wise since this was not considered in GSSv2. There are a number of considerations that must be met to insure interoperability across implementations and platforms. For example, object types must be standardized somewhere. In my opinion the language binding is not the place to intoduce this, it would require a revision to the GSSAPI spec (maybe v3). I would like to hear opinions from people who have a deeper insight into GSSAPI than I do. It is also worthwhile to note that while DAA is in the IETF standards track it is NOT a GSSAPI mechanism. -Joe > -----Original Message----- > From: Michael Smith [mailto:ms@gf.org] > Sent: Wednesday, October 27, 1999 9:45 AM > To: ietf-cat-wg@lists.Stanford.EDU > Subject: Objects as tokens (was: GSSAPI issues...) > > > At 02:54 PM 10/26/99 -0700, Jack Kabat wrote: > > >What ever is passed into the JGSS to represent tokens has > >to have a clear API on how to read/write data to it. > >Object class does not have this. > > I see that I've given both Jack and Joe the same mistaken > impression of what I had in mind; obviously I expressed > myself badly. May I ask the list's indulgence to re-state > my suggestion in a (hopefully) clearer way? > > My idea was simply to TYPE (forgive the caps) the token > parameters, in the interfaces, as Object, solely so as > not to constrain what kind of objects could, in particular > cases, be used as tokens. This was not intended to > suggest that any mechanism could take any kind of object, > or that mechanisms would have to restrict themselves to > the exiguous repertoire of methods that Object has, in > processing tokens. Rather, my idea was that particular > mechanisms (or mech implementations, MIs) might well want > to support, as tokens, kinds of objects above and beyond > byte arrays. The kinds of objects they'd want to support > would depend, perhaps, on the nature of the security protocol > and/or the application protocol and on the repertoire of > object representations associated with these. It wouldn't > be the same list for every mechanism, or MI, and many > mechanisms, no doubt, would find that byte-array filled > all the requirements. > > An MI's implementation of one of these Object-typed > methods would begin by finding out exactly what _kind_ > of object was passed in as a token, and then going off > to code written to process that particular kind of object, > using whatever methods that object supports. If it got > an object that it didn't support as a token, it would > throw an exception -- precisely as it would do if it > got a syntactically malformed token in a byte array. > > How would applications know what kinds of objects they > could use as tokens? Here, we added methods -- > > Class[] getContextTokenClasses() > and > Class[] getMessageTokenClasses() > > -- to advertise what the mechanisms could handle. > > Here's some code fragments, adapted from the stuff > we're using here: > > /* > From a mechanism implementation > Heavily edited and not guaranteed to compile > */ > > /** > * Utility function to tell callers what kinds of objects are > acceptable > * as context-establishment tokens. Note that byte [] is > always acceptable. > * > */ > public Class[] getContextTokenClasses() > { > Class accepts[] = new Class[1] ; > try > { > accepts [0] = > Class.forName("javax.servlet.http.HttpServletRequest"); > } > catch (Exception e) > { > Class [] nullaccepts = {}; > return nullaccepts; > } > return accepts; > } > > /* > I'm reluctant to show you any real mechanism > code, it's such a dog's breakfast, but here's > the general appearance of the logic that branches > on token type: > */ > > public void accept(Object token) throws GSSException > { > byte[] b = {1,2,3}; > Class bclass = b.getClass(); > Class sclass; > try > { > sclass = > Class.forName("javax.servlet.http.HttpServletRequest"); > } > catch (Exception e) > { > sclass = null; > } > if ((token.getClass()).equals(bclass)) > { > // Do something with the byte array > return; > } > if ((token.getClass()).equals(sclass)) > { > // Do something with the ServletRequest > return; > } > throw new GSSException > ( new BasicGSSStatus > (GSSStatus.GSS_S_BAD_TOKEN, > (short)0, // Revisit this and signal more detail? > (short)0, > null) > ); > > } > > --Michael Smith > ms@gf.org > > ============================================================== > ============ > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Oct 27 18:19:13 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13366 for ; Wed, 27 Oct 1999 18:19:12 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA21866 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 14:52:56 -0700 (PDT) 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 OAA21844 for ; Wed, 27 Oct 1999 14:52:52 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25285; Wed, 27 Oct 1999 14:52:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA23498; Wed, 27 Oct 1999 14:52:41 -0700 (PDT) Received: from teal (awe8-127.Central.Sun.COM [129.147.8.127]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA967904; Wed, 27 Oct 1999 14:52:39 -0700 (PDT) Date: Wed, 27 Oct 1999 14:55:18 -0700 (PDT) From: Mike Eisler Reply-To: Mike Eisler Subject: RE: Objects as tokens (was: GSSAPI issues...) To: Joe Salowey Cc: "'Michael Smith'" , ietf-cat-wg@lists.Stanford.EDU In-Reply-To: "Your message with ID" <86EDBD151558D311BB5700508B2E03FC762370@pikachu.wrq.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > First the GSSv2 RFC defines > tokens as OCTET STRINGs not objects, so changing this in the language > binding is not wise since this was not considered in GSSv2 Presumably the object is still encapsulated as an OCTET STRING. This way, even a non-Java GSS application can still decode the unwrapped object, if it knows how to decide Java objects. If not, then the proposal is a non-starter. ========================================================================== 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 Oct 27 21:53:02 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23700 for ; Wed, 27 Oct 1999 21:53:00 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA11511 for ietf-cat-wg-out720680; Wed, 27 Oct 1999 18:05:57 -0700 (PDT) Received: from nsm-mail2.cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA11500 for ; Wed, 27 Oct 1999 18:05:54 -0700 (PDT) Received: from jtrostle-pc1 (dhcp-171-71-229-223.cisco.com [171.71.229.223]) by nsm-mail2.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA19536; Wed, 27 Oct 1999 18:05:19 -0700 (PDT) Message-Id: <3.0.5.32.19991027180517.01107210@nsm-mail2.cisco.com> X-Sender: jtrostle@nsm-mail2.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 Oct 1999 18:05:17 -0700 To: ietf-cat-wg@lists.Stanford.EDU From: Jonathan Trostle Subject: revision of iakerb internet draft Cc: jtrostle@cisco.com, mikesw@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk INTERNET-DRAFT Mike Swift draft-ietf-cat-iakerb-04.txt Microsoft Updates: RFC 1510 Jonathan Trostle expires April 30, 2000 Cisco Systems Initial Authentication and Pass Through Authentication Using Kerberos V5 and the GSS-API (IAKERB) 0. Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines an extension to the Kerberos protocol specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for services where: (1) The client knows its principal name and password, but not its realm name (applicable in the situation where a user is already on the network but needs to authenticate to an ISP, and the user does not know his ISP realm name). (2) The client is able to obtain the IP address of the service in a realm which it wants to send a request to, but is otherwise unable to locate or communicate with a KDC in the service realm or one of the intermediate realms. (One example would be a dial up user who does not have direct IP connectivity). (3) The client does not know the realm name of the service. 2. Motivation When authenticating using Kerberos V5, clients obtain tickets from a KDC and present them to services. This method of operation works well in many situations, but is not always applicable since it requires the client to know its own realm, the realm of the target service, the names of the KDC's, and to be able to connect to the KDC's. This document defines an extension to the Kerberos protocol specification (RFC 1510) [1] that enables a client to obtain Kerberos tickets for services where: (1) The client knows its principal name and password, but not its realm name (applicable in the situation where a user is already on the network but needs to authenticate to an ISP, and the user does not know his ISP realm name). (2) The client is able to obtain the IP address of the service in a realm which it wants to send a request to, but is otherwise unable to locate or communicate with a KDC in the service realm or one of the intermediate realms. (One example would be a dial up user who does not have direct IP connectivity). (3) The client does not know the realm name of the service. In this proposal, the client sends KDC request messages directly to application servers if one of the above failure cases develops. The application server acts as a proxy, forwarding messages back and forth between the client and various KDC's (see Figure 1). Client <---------> App Server <----------> KDC proxies Figure 1: IAKERB proxying In the case where the client has sent a TGS_REQ message to the application server without a realm name in the request, the application server will forward an error message to the client with its realm name in the e-data field of the error message. The client will attempt to proceed using conventional Kerberos. 3. When Clients Should Use IAKERB We list several, but possibly not all, cases where the client should use IAKERB. In general, the existing Kerberos paradigm where clients contact the KDC to obtain service tickets should be preserved where possible. (a) AS_REQ cases: (i) The client is unable to locate the user's KDC or the KDC's in the user's realm are not responding, or (ii) The user has not entered a name which can be converted into a realm name (and the realm name cannot be derived from a certificate). (b) TGS_REQ cases: (i) the client determines that the KDC(s) in either an intermediate realm or the service realm are not responding or the client is unable to locate a KDC, (ii) the client is not able to generate the application server realm name. 4. GSSAPI Encapsulation The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the mechanism proposed by SPNEGO for negotiating protocol variations, is: {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2) initialauth(4)} The AS request, AS reply, TGS request, and TGS reply messages are all encapsulated using the format defined by RFC1964 [2]. This consists of the GSS-API token framing defined in appendix B of RFC1508 [3]: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType -- MechType is OBJECT IDENTIFIER -- representing "Kerberos V5" innerContextToken ANY DEFINED BY thisMech -- contents mechanism-specific; -- ASN.1 usage within innerContextToken -- is not required } The innerContextToken consists of a 2-byte TOK_ID field (defined below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field shall be one of the following values, to denote that the message is either a request to the KDC or a response from the KDC. Message TOK_ID KRB-KDC-REQ 00 03 KRB-KDC-REP 01 03 5. The Protocol a. The user supplies a password (AS_REQ): Here the Kerberos client will send an AS_REQ message to the application server if it cannot locate a KDC for the user's realm, or such KDC's do not respond, or the user does not enter a name from which the client can derive the user's realm name. The client sets the realm field of the request equal to its own realm if the realm name is known, otherwise the realm length is set to 0. Upon receipt of the AS_REQ message, the application server checks if the client has included a realm. If the realm was not included in the original request, the application server must determine the realm and add it to the AS_REQ message before forwarding it. If the application server cannot determine the client realm, it returns the KRB_AP_ERR_REALM_REQUIRED error-code in an error message to the client): KRB_AP_ERR_REALM_REQUIRED 77 The error message can be sent in response to either an AS_REQ message, in which case the e-data is empty; or in response to a TGS_REQ message, in which case the e-data will contain the realm of the application server encoded as an OCTET STRING. Once the realm is filled in, the application server forwards the request to a KDC in the user's realm. It will retry the request if necessary, and forward the KDC response back to the client. At the time the user enters a username and password, the client should create a new credential with an INTERNAL NAME [3] that can be used as an input into the GSS_Acquire_cred function call. This functionality is useful when there is no trust relationship between the user's logon realm and the target realm (Figure 2). User Realm KDC / / / / 2,3 1,4 / Client<-------------->App Server 1 Client sends AS_REQ to App Server 2 App server forwards AS_REQ to User Realm KDC 3 App server receives AS_REP from User Realm KDC 4 App server sends AS_REP back to Client Figure 2: IAKERB AS_REQ b. The user does not supply a password (TGS_REQ): The user includes a TGT targetted at the user's realm, or an intermediate realm, in a TGS_REQ message. The TGS_REQ message is sent to the application server. If the client has included the realm name in the TGS request, then the application server will forward the request to a KDC in the request TGT srealm. It will forward the response back to the client. If the client has not included the realm name in the TGS request, then the application server will return its realm name to the client using the KRB_AP_ERR_REALM_REQUIRED error described above. The error message e-data field contains the application server realm name. Note that another principal with the same principal name and a different realm than the intended application server can replace the realm name with its own, thus setting the stage for an impersonation attack. Therefore, sending a TGS_REQ message to the application server without a realm name in the request is a last resort (see security considerations below). The client can now proceed using conventional Kerberos with the realm name from the error message. 6. Addresses in Tickets In IAKERB, the machine sending requests to the KDC is the server and not the client. As a result, the client should not include its addresses in any KDC requests for two reasons. First, the KDC may reject the forwarded request as being from the wrong client. Second, in the case of initial authentication for a dial-up client, the client machine may not yet possess a network address. Hence, as allowed by RFC1510 [1], the addresses field of the AS and TGS requests should be blank and the caddr field of the ticket should similarly be left blank. 7. Combining IAKERB with Other Kerberos Extensions This protocol is usable with other proposed Kerberos extensions such as PKINIT (Public Key Cryptography for Initial Authentication in Kerberos [4]). In such cases, the messages which would normally be sent to the KDC by the GSS runtime are instead sent by the client application to the server, which then forwards them to a KDC. 8. Security Considerations A principal is identified by its principal name and realm. A client that sends a TGS request to an application server without the request realm name will only be able to mutually authenticate the server up to its principal name; another server with the same principal name and a different realm name, that has a trust relationship with the client, will be able to impersonate the intended application server. Thus, such requests should only be used as a last resort. 9. Bibliography [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service (V5). Request for Comments 1510. [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request for Comments 1964 [3] J. Linn. Generic Security Service Application Program Interface. Request for Comments 1508 [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, J. Trostle, Public Key Cryptography for Initial Authentication in Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- pkinit-10.txt. 10. Expires April 30, 2000. 11. Authors' Addresses Michael Swift Microsoft One Microsoft Way Redmond, Washington, 98052, U.S.A. Email: mikesw@microsoft.com Jonathan Trostle 170 W. Tasman Dr. San Jose, CA 95134, U.S.A. Email: jtrostle@cisco.com Phone: (408) 527-6201 ========================================================================== 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 Oct 28 10:50:55 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24383 for ; Thu, 28 Oct 1999 10:50:54 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA11450 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 07:04:18 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA11427 for ; Thu, 28 Oct 1999 07:04:14 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 28 Oct 1999 14:04:14 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id KAA09110; Thu, 28 Oct 1999 10:03:32 -0400 Message-Id: <199910281403.KAA09110@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 28 Oct 1999 14:04:11 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Oct 1999 10:04:12 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: RE: Objects as tokens (was: GSSAPI issues...) Cc: Joe Salowey Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 01:56 PM 10/27/99 -0700, Joe Salowey wrote: > First the GSSv2 RFC defines >tokens as OCTET STRINGs not objects, so changing this in the language >binding is not wise since this was not considered in GSSv2. The transition from procedural languages to object-oriented ones is, as we all know, a big step. I think it's fair to say that GSS-API has its origins at a time when procedural languages were very much the dominant paradigm. In procedural languages -- and particularly, of course, in 'C' -- a series of bytes is about the least characterized, most abstract thing there is. A sequence of bytes can be anything, and everything is in the last analysis a sequence of bytes. In Java, though, the least-characterized, most abstract thing is Object. In saying that tokens are OCTET STRINGS, the GSS-API spec places the least possible constraint, in a procedural language, on what can be passed as a token: it says, in effect, give the mech a blob and it's up to the mech to parse it. The equivalent in Java -- the least-characterized, most-abstract, minimal-constraint specification for tokens -- is Object. This follows from a fundamental difference between procedural and object-oriented languages. >There are a >number of considerations that must be met to insure interoperability across >implementations and platforms. For example, object types must be >standardized somewhere. I don't see that this follows. I can easily envision situations in which an implementation of protocol X has, on Ann's end of the wire, an object representation A of the state of that protocol, and the implementation on Bob's end has a totally different object representation B of X, or a representation which isn't object oriented at all (perhaps Bob is a 'C' monoglot). The only requirement is that Ann and Bob have, respectively, representations acceptable to their respective local implementations. Actually, I think that my proposal (with the methods to advertise what kinds of objects are locally supported as tokens) is considerably more helpful to applications than the OCTET STRING specification. With OCTET STRING, any Bob who needs to extract and/or build a token from his protocol interactions with Ann needs prior knowledge of how to do that: take one byte from column A, two from column B, etc. With my scheme, Bob can get a list of object types which will will least give him something to go on in putting together a token. If the architect and/or administrator of the system Bob is running on have done their work well, he's quite likely to find that one of the objects supported just happens to be one he already has lying around, or knows how to construct. >It is also worthwhile to note that while DAA is in the IETF standards track >it is NOT a GSSAPI mechanism. As are (are not?) many other protocols in very common use. My own perspective on this is a down-and-dirty one. The waters in which I sail are full of "legacy systems" wallowing like icebergs, and "middleware" vendors plying their deadly craft like Barbary pirates. GSS-API actually offers me a very promising means to insulate applications from the morass of protocols in use in this so-called "application infrastructure," and from its constant flux. The less hospitable GSS is to mechanisms designed without GSS in mind, the less useful it is to me. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 11:24:11 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26156 for ; Thu, 28 Oct 1999 11:24:10 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA21037 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 07:42:19 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA21010 for ; Thu, 28 Oct 1999 07:42:13 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 28 Oct 1999 14:42:12 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id KAA09237; Thu, 28 Oct 1999 10:41:30 -0400 Message-Id: <199910281441.KAA09237@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 28 Oct 1999 14:42:09 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Oct 1999 10:42:11 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: CAT: Now something completely different... Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I seem to recall that when Java-GSS discussions first got underway, one of the contributors to this list told us something about a GSS binding for the language Python. I don't seem to have kept that mail, annoyingly enough. Is there anybody on the list who knows about Python/GSS work? I've discovered a coven of secret Python cultists here who have escaped from the C++, VB, and Java reservations and are now living in the woods and eating roots and grubs. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 14:44:49 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05283 for ; Thu, 28 Oct 1999 14:44:48 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA28850 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 10:12:01 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA28782 for ; Thu, 28 Oct 1999 10:11:48 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id KAA09442; Thu, 28 Oct 1999 10:11:01 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be software-munitions.com Message-ID: <381883A5.7502C141@software-munitions.com> Date: Thu, 28 Oct 1999 10:11:01 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith CC: ietf-cat-wg@lists.Stanford.EDU Subject: Re: CAT: Now something completely different... References: <199910281441.KAA09237@gf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD5BEC789085334B0A62BB427" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------msD5BEC789085334B0A62BB427 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Smith wrote: > > I seem to recall that when Java-GSS discussions > first got underway, one of the contributors to this > list told us something about a GSS binding for > the language Python. I don't seem to have kept > that mail, annoyingly enough. Is there anybody > on the list who knows about Python/GSS work? > I've discovered a coven of secret Python cultists > here who have escaped from the C++, VB, and Java > reservations and are now living in the woods and > eating roots and grubs. > Here is the header and identifying trailer from the message. I have the body but I am in the middle of moving between mail tools. I'll send the body if requested. >From postmaster@pad-thai.cam.ov.com Thu Nov 6 21:31:16 1997 Return-Path: Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by btw.plaintalk.bellevue.wa.us (8.8.7/8.8.7) with ESMTP id VAA01984 for ; Thu, 6 Nov 1997 21:30:58 -0800 (PST) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id WAA07190 for cat-ietf-redist; Thu, 6 Nov 1997 22:40:14 -0500 (EST) Date: Fri, 7 Nov 1997 13:39:56 +1000 (EST) From: Simon Gibson To: CAT IETF Work Group Cc: Tim Redhead Subject: GSSAPI Python Bindings Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk ------------------------------------------------------------------------- Simon Gibson, Telephone: +61 7 3864 5120 Security Unit, Facsimile: +61 7 3864 1282 Distributed Systems Technology Centre, Queensland University of Technology, email: Brisbane Qld 4001, Australia. ------------------------------------------------------------------------- --------------msD5BEC789085334B0A62BB427 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKLgYJKoZIhvcNAQcCoIIKHzCCChsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B7owggSEMIID7aADAgECAhAV4oOYVg1pE0gVFzzXJ4WbMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDMyMTAwMDAw MFoXDTAwMDMyMDIzNTk1OVowggEoMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0Rlbm5pcyBHbGF0dGluZzE1MDMGCSqG SIb3DQEJARYmZGVubmlzLmdsYXR0aW5nQHNvZnR3YXJlLW11bml0aW9ucy5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKSBSrAz19P5zPsu3odv359aq1FIuU7RXSXlVga0DqpE ST8T6/e3wtn1f8NnfnytpCWP4r2FgO51Z2Q8o5fy99Gajtlm5tYDBEm09HGWoxAYfEJE8oVI lMCDRQazW5WFiY8WkoNl36eoVl0Oa5rsaSMnk5u45R7Mu3wyLRBooXfnAgMBAAGjggEGMIIB AjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVy aVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2Ug bGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B AQQFAAOBgQAlb2LpvHzHBF/o/uILYbM2MGnIkf4y7PN+XQnMAXpk1mIFeVtIH+kquwCo93ra 9h1wdohBxmPt4Sw/EHG4WNr8PnYXuo7kFOBokqSTOYQTr/6zbSKnjXhO3N4qWKoS0dK0G8GO QTKulULvZBkmbnHJ1YIvES2KH7hC2Uzs1K7SDDCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKo JV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgT Vi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMC AQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0G CSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVq D7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9d WBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEBXig5hWDWkTSBUX PNcnhZswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw05OTEwMjgxNzExMDFaMCMGCSqGSIb3DQEJBDEWBBTcXAn4s0D8BoI3WAqFPZtW AxmnKDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgJzl HPphJoHtzfDet4a7VFRBUaRao/xTWw45DcITxlJJIuRvAaP+nFslSrFBmlWxRSwLIA9dUNqv KB/77tbWI1cYpnMiTIHRXJighF7W8x79FPw8ZQb4OK7ZE1oaG32jhzlwkDBcHrSYFo07lFCO DEprII+IbR7s0P9X4JKSK3/L --------------msD5BEC789085334B0A62BB427-- ========================================================================== 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 Oct 28 14:45:05 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05319 for ; Thu, 28 Oct 1999 14:45:04 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA15172 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 11:15:08 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA15160 for ; Thu, 28 Oct 1999 11:15:05 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA04549; Thu, 28 Oct 1999 11:15:01 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 11:15:01 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762375@pikachu.wrq.com> From: Joe Salowey To: "'Michael Smith'" , ietf-cat-wg@lists.Stanford.EDU Cc: Joe Salowey Subject: RE: Objects as tokens (was: GSSAPI issues...) Date: Thu, 28 Oct 1999 11:15:00 -0700 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 GSSAPI allows an application developer to upgrade or change its security layer without having the application modify large amounts of code (yes, I know in practice this is not always true, but I see no reason to make it worse). You have a mechanism from company A that takes an object like things.Stuff as its token because it is convenient for a very specific application. It is found the implementation provided by company A does not work well and is insufficient for the current security requirements for your project so you obtain a more reliable more secure implementation from company B. Unfortunately, company B's implementation does not know anything about things.stuff so you have to spend months rewriting you application so it uses other.Stuff instead. One of the values of using GSSAPI is lost. If you are going to allow other objects you must at the very least standardize on what objects are allowed. -Joe > -----Original Message----- > From: Michael Smith [mailto:ms@gf.org] > Sent: Thursday, October 28, 1999 8:04 AM > To: ietf-cat-wg@lists.Stanford.EDU > Cc: Joe Salowey > Subject: RE: Objects as tokens (was: GSSAPI issues...) > > > At 01:56 PM 10/27/99 -0700, Joe Salowey wrote: > > First the GSSv2 RFC defines > >tokens as OCTET STRINGs not objects, so changing this in the language > >binding is not wise since this was not considered in GSSv2. > > The transition from procedural languages to object-oriented > ones is, as we all know, a big step. I think it's fair to say that > GSS-API has its origins at a time when procedural languages > were very much the dominant paradigm. In procedural languages > -- and particularly, of course, in 'C' -- a series of bytes is > about the least characterized, most abstract thing there is. > A sequence > of bytes can be anything, and everything is in the last analysis a > sequence of bytes. In Java, though, the least-characterized, most > abstract thing is Object. In saying that tokens are OCTET > STRINGS, the > GSS-API spec places the least possible constraint, in a procedural > language, on what can be passed as a token: it says, in effect, > give the mech a blob and it's up to the mech to parse it. The > equivalent > in Java -- the least-characterized, most-abstract, minimal-constraint > specification for tokens -- is Object. This follows from a > fundamental > difference between procedural and object-oriented languages. There is a fundamental difference between a blob of bytes and an object. > >There are a > >number of considerations that must be met to insure > interoperability across > >implementations and platforms. For example, object types must be > >standardized somewhere. > > I don't see that this follows. I can easily envision situations > in which an implementation of protocol X has, on Ann's end of the > wire, an object representation A of the state of that protocol, and > the implementation on Bob's end has a totally different object > representation B of X, or a representation which isn't object > oriented at all (perhaps Bob is a 'C' monoglot). The only requirement > is that Ann and Bob have, respectively, representations acceptable > to their respective local implementations. > > Actually, I think that my proposal (with the methods to advertise > what kinds of objects are locally supported as tokens) is considerably > more helpful to applications than the OCTET STRING specification. > With OCTET STRING, any Bob who needs to extract and/or > build a token from his protocol interactions with Ann needs prior > knowledge of how to do that: take one byte from column A, two from > column B, etc. With my scheme, Bob can get a list of object types > which will will least give him something to go on in putting > together a token. If the architect and/or administrator of the > system Bob is running on have done their work well, he's quite > likely to find that one of the objects supported just happens > to be one he already has lying around, or knows how to construct. > ============================================================== > ============ > 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 Oct 28 15:12:02 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06866 for ; Thu, 28 Oct 1999 15:12:01 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id LAA21864 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 11:40:56 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id LAA21831 for ; Thu, 28 Oct 1999 11:40:50 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Oct 1999 11:40:22 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569040DF06B@SIT.platinum.corp.microsoft.com> From: "John Brezak (Exchange)" To: "'Brian Tung'" , "'ietf-cat-wg@lists.stanford.edu'" Subject: RE: PKINIT, rev 10 Date: Thu, 28 Oct 1999 11:40:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk There is an issue in PKINIT having to do with the use of the transited field and compatability with existing KDCs. From PKINIT-10: Since each certifier in the certification path of a user's certificate is equivalent to a separate Kerberos realm, the name of each certifier in the certificate chain must be added to the transited field of the ticket. The format of these realm names is defined in Section 3.1 of this document. If applicable, the transit-policy-checked flag should be set in the issued ticket. In this case the transited field would contain X500-RFC2253 nametype. Most of the widely deployed Kerberos realms are not able to check this nametype and will reject any ticket obtained via PKINIT from a realm that does this. For example the MIT Kerberos 1.0.5 KDC will fail with "Illegal cross-realm ticket" when it encounters a PKINIT'ed ticket that implements this. If this mechanism is required, then there will be no interop with existing deployed Kerberos realms. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak * mailto:jbrezak@microsoft.com Microsoft Corporation * 425-936-2602 One Microsoft Way Redmond, WA 98052 ========================================================================== 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 Oct 28 15:39:43 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08279 for ; Thu, 28 Oct 1999 15:39:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA27265 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 12:01:57 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id MAA27245 for ; Thu, 28 Oct 1999 12:01:53 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 28 Oct 1999 19:01:52 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id PAA09990; Thu, 28 Oct 1999 15:01:11 -0400 Message-Id: <199910281901.PAA09990@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 28 Oct 1999 19:01:50 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Oct 1999 15:01:51 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: RE: Objects as tokens (was: GSSAPI issues...) Cc: Mayank Upadhyay Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 10:54 AM 10/28/99 -0700, Mayank Upadhyay wrote: >Michael, > >I vaguely remember having a discussion with you about this mechanism >before. Mike Eisler and I had pointed out to you even then that as per the >GSS-API RFC, the first token has to have a mechanism independent part to >it which contains the Oid of the underlying mechanism that will be used. I remember the conversation well; the problem here is not my advancing age, but my application requirements. It remains the case that many protocols have been developed, and no doubt will be developed, without GSS in mind. As I mentioned earlier, if CAT decides to shut the GSS door on these, the usefulness of this work will be greatly compromised, both for me and for a good many other people. I understand the reasons for the token encapsulation requirement; unfortunately, it has painted us into a corner somewhat, as the tangled history of interaction between, e.g., GSS and SASL and GSS and SOCKS may suggest. Interestingly, the broadening of type which I propose offers a way out of this corner, I think, at least for Java applications and mechanism implementations. If mechs can indicate the types of objects that they accept as tokens, this provides a way of structuring the set of potential input tokens, analogous to the structuring provided by Oid encapsulation, but considerably more powerful and less rigid. Incidentally, it probably isn't necessary to say this, but just in case: of course everyone realizes that if the token type is Object, a byte array can still be passed, if you have one (since byte arrays extend Object). In other words, my broadening of type doesn't in any way prevent protocols that have nice GSS-formatted tokens from passing them as byte arrays if that's what they want to do. The idea of the broadening is to take advantage of (should I say "leverage"?) the power of the language's type system to make life less of a hassle for applications which don't sit directly on the wire, and/or use protocols that don't GSS-encapsulate tokens. And once more I stress that these protocols exist and will not go away. We are simply not in a position to dictate terms to protocol implementers. >Your idea of using a plain object and passing it blindly to a GSS-API that >supports just one mechanism, your mechanism, will work but it is against >the design principles of the GSS-API IMHO. Not "blindly," and not a "plain object"; the idea is to find out what kinds of specific objects -- _extensions_ of "plain," or abstract, Object -- the mech supports and then pass one of those. Nor is this confined to single-mechanism implementations; it's perfectly compatible with multi-mechanism ones, and even SPI-based ones with a "shim". >A reasonable solution to this might be adding an interface that supports >"byte[] getToken()" and your "Object" then implement this interface. Clever idea. The problem is that I need to associate the functionality of digesting the object containing the token with the mechanism implementation rather than with the application. Of course one could always define some class, associated with the mech. impl., which would provide your method byte[] getToken() -- but then the app would still have to have some way of getting this class from the mech. impl., of determining what input classes it would accommodate to get the token, etc. -- in short, a roundabout way of achieving the same thing. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 15:41:59 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08462 for ; Thu, 28 Oct 1999 15:41:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA09953 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 10:54:51 -0700 (PDT) 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 KAA09930 for ; Thu, 28 Oct 1999 10:54:45 -0700 (PDT) Received: from taller.eng.sun.com ([129.144.124.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14856; Thu, 28 Oct 1999 10:54:42 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id KAA02843; Thu, 28 Oct 1999 10:54:38 -0700 (PDT) Date: Thu, 28 Oct 1999 10:54:40 -0700 (PDT) From: Mayank Upadhyay Reply-To: Mayank Upadhyay To: Michael Smith cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: Objects as tokens (was: GSSAPI issues...) In-Reply-To: <199910281403.KAA09110@gf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Michael, I vaguely remember having a discussion with you about this mechanism before. Mike Eisler and I had pointed out to you even then that as per the GSS-API RFC, the first token has to have a mechanism independent part to it which contains the Oid of the underlying mechanism that will be used. In other words the first token is not just an opaque blob as you seem to think. (See section 3.1 of RFC 2078bis.) This mechanism independent Oid enables the application to determine which single mechanism GSS it has to bind to, or it enables a multi-mechanism GSS to determine which underlying mechanism it has to use. Therefore, as you see the GSS-API is a little bit more than just another API, it also has a small amount of protocol. Your idea of using a plain object and passing it blindly to a GSS-API that supports just one mechanism, your mechanism, will work but it is against the design principles of the GSS-API IMHO. A reasonable solution to this might be adding an interface that supports "byte[] getToken()" and your "Object" then implement this interface. (In your case, you can construct an object that contains the servlet request and also implements this method. Then the API does not violate the GSS-API RFC while at the same time your mechanism specific GSS can accept some object instead of just a byte[]. -Mayank On Thu, 28 Oct 1999, Michael Smith wrote: > At 01:56 PM 10/27/99 -0700, Joe Salowey wrote: >.... A sequence > of bytes can be anything, and everything is in the last analysis a > sequence of bytes. In Java, though, the least-characterized, most > abstract thing is Object. In saying that tokens are OCTET STRINGS, the > GSS-API spec places the least possible constraint, in a procedural > language, on what can be passed as a token: it says, in effect, > give the mech a blob and it's up to the mech to parse it. The equivalent > in Java -- the least-characterized, most-abstract, minimal-constraint > specification for tokens -- is Object. This follows from a fundamental > difference between procedural and object-oriented languages. ========================================================================== 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 Oct 28 15:47:27 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08780 for ; Thu, 28 Oct 1999 15:47:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id KAA09378 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 10:52:31 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id KAA09270 for ; Thu, 28 Oct 1999 10:52:04 -0700 (PDT) Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id KAA09701; Thu, 28 Oct 1999 10:44:37 -0700 (PDT) X-Authentication-Warning: btw.plaintalk.bellevue.wa.us: Host fwiw.plaintalk.bellevue.wa.us [206.129.5.157] claimed to be software-munitions.com Message-ID: <38188B85.2FC11812@software-munitions.com> Date: Thu, 28 Oct 1999 10:44:37 -0700 From: Dennis Glatting X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith CC: ietf-cat-wg@lists.Stanford.EDU Subject: Re: CAT: Now something completely different... References: <199910281441.KAA09237@gf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8A99BD97D191F07B6EB5597C" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms8A99BD97D191F07B6EB5597C Content-Type: multipart/mixed; boundary="------------8587C8328098EFE645EFC5A4" This is a multi-part message in MIME format. --------------8587C8328098EFE645EFC5A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Smith wrote: > > I seem to recall that when Java-GSS discussions > first got underway, one of the contributors to this > list told us something about a GSS binding for > the language Python. I don't seem to have kept > that mail, annoyingly enough. Is there anybody > on the list who knows about Python/GSS work? > I've discovered a coven of secret Python cultists > here who have escaped from the C++, VB, and Java > reservations and are now living in the woods and > eating roots and grubs. > > --Michael Smith > ms@gf.org > Hopefully this message includes the Python message. --------------8587C8328098EFE645EFC5A4 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by btw.plaintalk.bellevue.wa.us (8.8.7/8.8.7) with ESMTP id VAA01984 for ; Thu, 6 Nov 1997 21:30:58 -0800 (PST) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id WAA07190 for cat-ietf-redist; Thu, 6 Nov 1997 22:40:14 -0500 (EST) Date: Fri, 7 Nov 1997 13:39:56 +1000 (EST) From: Simon Gibson To: CAT IETF Work Group Cc: Tim Redhead Subject: GSSAPI Python Bindings Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk G'day All, Recently I have been involved in a project integrating security into a prototype middleware for distributed objects that is being developed in Python. A generic method of security was needed so the GSSAPI was a perfect candidate, we also had a GSSAPI prototype that had previously been developed that we could use as a test bed. To facilitate this integration the C bindings were wrapped using SWIG (Simplified Wrapper Interface Generator) to gain access from python. This involved writing typemaps for the datatypes to be coerced from python to C and vice versa. After wrapping the functions an intermediate OO layer was added. This layer grouped function calls that had commonality into classes. Each class also holds a type of handle as an attribute of the object eg. the context_handle is an attribute of the Context class. This OO interface gave a clean and simplified access to the standard function calls. From this interface we have developed an OO python binding to the GSSAPI. This is not meant as a standalone binding but as complementary to the C binding. This interface is currently working well. We have been able to use the GSSAPI for security but also able to maintain the OO paradigm of the developing project. From a personal point of view as I have added extra functionality to our GSSAPI implementation I have found it easier and faster to do the testing from the python interface. The rest of this email is broken up into 2 parts: Part 1: Shows the class structure and the python bindings. Part 2: Shows simple example client and server programmes using the python bindings to demonstrate usage. I would appreciate any comments/criticisms that you might have. Simon ------------------------------------------------------------------------- Simon Gibson, Telephone: +61 7 3864 5120 Security Unit, Facsimile: +61 7 3864 1282 Distributed Systems Technology Centre, Queensland University of Technology, email: Brisbane Qld 4001, Australia. ------------------------------------------------------------------------- Part 1 ====== PYTHON BINDINGS =============== Class Sets: Name: ==== gss_compare_name() gss_canonicalize_name() gss_display_name() gss_duplicate_name() gss_export_name() gss_import_name() gss_release_name() Credential: ========== gss_acquire_cred() gss_add-cred() gss_inquire_cred() gss_inquire_cred_by_mech() gss_release_cred() Context: ======= gss_accept_sec_context() gss_context_time() gss_del_sec_context() gss_export_sec_context() gss_get_mic() gss_import_sec_context() gss_init_sec_context() gss_inquire_context() gss_process_context_token() gss_unwrap() gss_verify_mic() gss_wrap() gss_wrap_size_limit() OIDset: ====== gss_add_oid_set_member() gss_create_oid_set() gss_inquire_mechs_for_name() gss_inquire_names_for_mechs() gss_release_oid_set() gss_test_oid_set_member() Support: ======= gss_display_status() gss_indicate_mechs() gss_release_buffer() ******************************************************************************** Class Name =============================================================================== gss_compare_name ( name_obj2) # Python Name() object returns [major_status, #PyInteger minor_status, #PyInteger name_equal ] #PyInteger 0 = FALSE, 1 = TRUE eg. [maj,min,name_eq]=name.gss_compare_name(name2_obj) gss_canonicalize_name ( mech-type ) # string returns [major_status, #PyInteger minor_status, #PyInteger output_name ] #string gss_display_name() returns [major_status, #PyInteger minor_status, #PyInteger outbuffer, #string out_type ] #string eg. [maj,min,out,type] = name.gss_display_name() gss_duplicate_name () returns [major_status, #PyInteger minor_status, #PyInteger dest_name ] #Python Name() object gss_export_name () returns [major_status, #PyInteger minor_status, #PyInteger exported_name ] #Python Name() object gss_import-name ( input_name, #string input_nme_type) #string eg. GSS_C_NO_OID returns [major_status, #PyInteger minor_status ] #PyInteger eg. [maj,min] = name.gss_import_name("simon",'GSS_C_NO_OID') gss_release_name() returns [major_status #PyInteger minor_status] #PyInteger eg. [maj,min] = name.gss_release_name() ******************************************************************************** Class Credential ******************************************************************************** gss_acquire_cred ( name_obj, #Python Name() object time_rec, #PyInteger desired_mechs, #string or # OIDset() object # eg. # GSS_C_NO_OID_SET cred-usage) #PyInteger returns [major_status, #PyInteger minor_status, #PyInteger act_mech, #Python OIDset() object time_rec ] #PyInteger eg. [maj,min,mech,time] = credential.gss_acquire_cred(name_obj, 100,'GSS_C_NO_OID_SET', GSS_C_INITIATE) gss_add_cred ( desired_name, #Python Name() object desired_mech, #String cred_usage, #PyInteger init_time_req, #PyInteger accept_time_req #PyInteger out_cred_handle) #Python Credential() # object or 'NULL' returns [major_status, #PyInteger minor_status, #PyInteger output_cred, #Python Credential() object actual_mechs, #Python OIDset() object init_time_rec, #PyInteger accept_time_rec] #PyInteger gss_inquire_cred () returns [major_status, #PyInteger minor_status, #PyInteger name, #Name object lifetime, #PyInteger usage, #PyInteger mechanism ] #Python OIDset() object eg. [maj,min,nme_obj,lifetime,cred_usage,mechan] = credential.gss_inquire_cred() gss_inquire_cred_by_mech ( mech_type ) #string returns [major_status, #PyInteger minor_status, #PyInteger name_obj, #Python Name() object init_lifetime, #PyInteger accept_lifetime, #PyInteger cred_usage ] #PyInteger gss_release_cred() returns [major_status, #PyInteger minor_status] #PyInteger eg. [maj,min] = credential.gss_release_cred() ******************************************************************************** Class Context ******************************************************************************** gss_accept_sec_context( context, #string eg. #GSS_C_NO_CONTEXT OR #Context object credential, #Credential object token_in, #string chan_bind) #string eg. NULL returns [major_status, #PyInteger minor_status, #PyInteger newname, #Name() object mech_type, #Python pointer tokenout, #string ret_flags, #PyInteger time_rec, #PyInteger del_cred] #Python Credential() object eg. [maj,min,newname,mech,dataout,retflg,time_rec,delcred] = \ context.gss_accept_sec_context('GSS_C_NO_CONTEXT',cred,datain,'NULL') gss_context_time() returns [major_status, #PyInteger minor_status, #PyInteger time ] #PyInteger in seconds eg. [maj,min,time] = context.gss_context_time() gss_delete_sec_context() returns [major_status, #PyInteger minor_status, #PyInteger data ] #string = eg. [maj,min,data] = context.gss_delete_sec_context() gss_export_sec_context () returns [major_status, #PyInteger minor_status, #PyInteger interprocess_token] #String gss_get_mic( qop_req, #PyInteger msg_buffer) #string returns [major_status, #PyInteger minor_status, #PyInteger msg_token ] #string eg. [maj,min,dataout] = context.get_mic(1,datain) gss_import_sec_context( interproc_tok) #string returns [major_status, #PyInteger minor_status ] #PyInteger gss_init_sec_context( cred_obj, #Credential() object context, #string eg. #GSS_C_NO_CONTEXT OR #Context object targ_nme, #python Name() object mech_type, #String eg. #GSS_C_NO_OID req_flgs, #PyInteger time_req, #PyInteger ch_bind, #string eg. NULL in_token) #string eg. #GSS_C_NO_BUFFER returns [ major_status, #PyInteger minor_status, #PyInteger act_mech_type #python string token, #string flags, #PyInteger time_rec ] #PyInteger eg. [maj,min,act_mech_type,token,flags,time_rec] = context.gss_init_context\ (Cred,'GSS_C_NO_CONTEXT',name,'GSS_C_NO_OID', \ 0,10,'NULL','GSS_C_NO_BUFFER') gss_inquire_context() returns [major_status, #PyInteger minor_status, #PyInteger initNme, #Python Name() object acceptorNme, #Python Name() object lifetime_rec, #PyInteger mech_type, #Python string ret_flag, #PyInteger local_init, #PyInteger open ] #PyInteger eg. [maj,min,init_nme,acc_nme,life_rec,mech_tpe,ret_flg,loc_init] = \ context.inquire_context() gss_process_context_token( buffer) #string returns [major_status #PyInteger minor_status] #PyInteger eg. [maj,min] = context.gss_process_context_token (in_buff) gss_unwrap( in_token ) #string returns [major_status, #PyInteger minor_status, #PyInteger token_out, #string conf, #PyInteger -0 = signed, 1 = sealed qop ] #PyInteger eg. [maj,min,dataout,conf,qop] = context.gss_unwrap(inbuff) gss_verify_mic( message_buffer #string token_buffer ) #string returns [major_status, #PyInteger minor_status, #PyInteger qop ] #PyInteger eg. [maj,min,dataout,qop] = context.gss_verify_mic(message, token) Class Context gss_wrap ( conf_req, #PyInteger qop_req, #PyInteger data_out ) #string returns [major_status, #PyInteger minor_status, #PyInteger conf_state, #PyInteger token_out ] #string eg. [maj,min,state,dataout] = context.gss_wrap(1,0,datain) gss_wrap_size_limit ( conf_req, #PyInteger qop_req, #PyInteger req_out_size ) #PyInteger returns [major_status, #PyInteger minor_status, #PyInteger max_input_size ] #PyInteger ******************************************************************************** Class Support ******************************************************************************** gss_display_status ( stat_value, #PyInteger stat_type, #PyInteger mech_type, #string eg. #GSS_C_NO_OID mesg_ctxt) #PyInteger returns [major_status, #PyInteger minor_status, #PyInteger mesg_ctxt #PyInteger mesg] #string eg. [maj1,min1,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NO_OID",0) gss_indicate_mechs () returns [major_status, #PyInteger minor_status, #PyInteger mech_set] #Python OIDset() object gss_release_buffer( buffer) #string returns [major_status, #PyInteger minor_status, #PyInteger buffer ] #string = eg. [maj,min,dataout] = support.gss_release_buffer(dataout) ******************************************************************************** Class OIDset ******************************************************************************** gss_add_oid_set_member ( member_oid) #string eg. # GSS_C_MECH_DES returns [major_status, #PyInteger minor_status ] #PyInteger gss_create_oid_set () returns [major_status, #PyInteger minor_status ] #PyInteger gss_inquire_mechs_for_name ( input_name ) # Name object returns [major_status, #PyInteger minor_status ] #PyInteger gss_inquire_names_for_mech ( mechanism ) #string or python ptr returns [major_status, #PyInteger minor_status ] #PyInteger = gss_release_oid_set () returns [major_status, #PyInteger minor_status ] #PyInteger gss_test_oid_set_member ( member ) #string eg. # GSS_C_MECH_DES returns [major_status, #PyInteger minor_status, #PyInteger present ] #PyInteger -------------------------------------------------------------------------------- Part 2: #! /usr/local/bin/python ## ## server.py ## ## Server programme that accepts a security context from client programme. The server ## then receives messages and can decrypt using the context import gssapi ## OO interface to the python wrapped C gssapi functions >from mysock import * ## Some generic socket routines AS_SERVER = 'typhoon.dstc.qut.edu.au' as_port_number = 5333 GSS_C_BOTH = 0 ## define some basic constants GSS_C_INITIATE = 1 GSS_C_ACCEPT = 2 GSS_C_GSS_CODE = 1 excBADNME = 'excBADNME' ## define some exceptions excBADCRD = 'excBADCRD' excBADCTX = 'excBADCTX' excBADSEAL = 'excBADSEAL' Nme = gssapi.Name() ## create some objects Cred = gssapi.Credential() context = gssapi.Context() support = gssapi.Support() try : [maj,min] = Nme.gss_import_name(sys.argv[1],'GSS_C_NULL_OID') if maj != 0: Nme.gss_release_name() raise excBADNME,maj [maj,min,time_rec,mech] = Cred.gss_acquire_cred(Nme,86400,'GSS_C_NULL_OID_SET',\ GSS_C_BOTH) if maj != 0: Cred.gss_release_cred() raise excBADCRD,maj sock = socket(AF_INET,SOCK_STREAM) sock.bind(AS_SERVER,as_port_number) sock.listen(1) while 1 : print "Waiting for client connection..." conn,addr = sock.accept() print "Connection incoming" ctxt_est = 0 ## context established == FALSE ctxt = 'GSS_C_NO_CONTEXT' ## No context for first call to init-sec() while not ctxt_est: datain = conn.recv(1024) [maj,min,newname,mech,token,retflg,time_rec,delcred] = \ context.gss_accept_sec_context(ctxt,Cred,datain,'NULL') if len(token)>0: ## There is a token to be sent conn.send(token) if maj > 1: ## error [maj,min,data] = context.gss_delete_sec_context() raise excBADCTX,maj if maj == 0 : ## complete ctxt_est = 1 ## context established else: ## maj == 1 ie gss_continue_needed ctxt = context ## input itself to next call of accept-sec-ctxt [maj,min,init_nme,acc_nme,life_rec,mech_tpe,ret_flg,loc_init] = \ context.gss_inquire_context() [maj,min,out1,type] = init_nme.gss_display_name() print out1 [maj,min,out,type] = acc_nme.gss_display_name() print out Finished = 0 while Finished == 0: inbuff = conn.recv(1024) if inbuff == '': Finished = 1 else: [maj,min,dataout,conf,qop] = context.gss_unseal(inbuff) if maj != 0: raise excBADCRD,maj print "Message buffer before decryption -->",inbuff print "------------" print 'Message received was ->',dataout,'\n' print "Message was signed and sealed by principal",out1,'\n' print "--------------------------------" print "Closing connection" print '\n' [maj,min,data] = context.gss_delete_sec_context() [maj,min,dataout] = support.gss_release_buffer(dataout) [maj,min] = Nme.gss_release_name() [maj,min] = init_nme.gss_release_name() [maj,min] = acc_nme.gss_release_name() [maj,min] = Cred.gss_release_cred() sock_close(sock) except ValueError: print "Exception" except KeyboardInterrupt: print "Interrupt. Closing down!" except IndexError: print "Usage: ",sys.argv[0],"" except excBADNME,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in name because of :",mesg except excBADCRD,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in acquire_credential because of:",mesg except excBADCTX,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in accept_sec_context because of:",mesg except excBADSEAL,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in seal because of:",mesg #! /usr/local/bin/python ## ## client.py ## ## Sample client programme using GSSAPI. The client negotiates a mutually ## authenticated context. Then an encrypted message is sent to the server. import gssapi ## OO interface to the python wrapped C gssapi functions >from mysock import * ## Some generic socket routines AS_SERVER = 'typhoon.dstc.qut.edu.au' as_port_number = 5333 GSS_C_BOTH = 0 ## define some constants GSS_C_INITIATE = 1 GSS_C_ACCEPT = 2 GSS_C_GSS_CODE = 1 FLAG = 2 ## Mutual Auth excBADNME = 'excBADNME' ## define some exceptions excBADCRD = 'excBADCRD' excBADCTX = 'excBADCTX' excBADSEAL = 'excBADSEAL' Nme = gssapi.Name() ## create some objects TargNme = gssapi.Name() Cred = gssapi.Credential() context = gssapi.Context() support = gssapi.Support() try : [maj1,min1] = Nme.gss_import_name(sys.argv[2],'GSS_C_NULL_OID') if maj1 != 0: raise excBADNME,maj1 [maj,min] = TargNme.gss_import_name(sys.argv[1],'GSS_C_NULL_OID') if maj != 0: raise excBADNME,maj [maj,min,eq] = Nme.gss_compare_name(TargNme) [maj,min,mechs,time_rec] = Cred.gss_acquire_cred \ (Nme,100,'GSS_C_NULL_OID_SET' \ ,GSS_C_INITIATE) if maj != 0: raise excBADCRD,maj [maj,min,nme,lifetime,cred_usage,mechan] = Cred.gss_inquire_cred() if maj != 0: raise excBADCRD,maj sock = open_sock(AS_SERVER,as_port_number) ctxt_est = 0 ## context established == FALSE ctxt = 'GSS_C_NO_CONTEXT' datain = 'GSS_C_NO_BUFFER' while ctxt_est == 0: [maj,min,act_mech_type,token,flags,time_rec] = \ context.gss_init_sec_context \ (Cred,ctxt,TargNme, \ 'GSS_C_NULL_OID', \ FLAG,200,'NULL',datain) if len(token) > 0: # There is a token to be sent sock.send(token) if maj > 1: # error [maj,min,data] = context.gss_delete_sec_context() raise excBADCTX,maj if maj == 1: # continue needed ctxt = context # input itself to next call of init-sec-ctxt datain = sock.recv(1024) else: # context is now established ie maj == 0 ctxt_est = 1 [maj,min,init_nme,acc_nme,life_rec,mech_tpe,ret_flg,loc_init] = \ context.gss_inquire_context() if maj != 0: raise excBADCTX,maj print "There is ",life_rec,"seconds left in context" [maj,min,out,type] = Nme.gss_display_name() if maj != 0: raise excBADNME,maj [maj,min,time] = ctx.gss_context_time() if maj != 0: raise excBADCTX,maj Finished = 0 print "To terminate, enter an empty buffer." qop = 1 while Finished == 0: datain = raw_input("Enter data-->") if datain == '': ## Terminate Finished = 1 sock_write(sock,datain) dataout = '' else: [maj,min,state,dataout] = context.gss_seal(qop,0,datain) if maj != 0: raise excBADSEAL,maj [maj,min,time] = context.gss_context_time() print time,' seconds left in context' sock_write(sock,dataout) [maj,min,data] = context.gss_delete_sec_context() [maj,min,dataout] = support.gss_release_buffer(dataout) [maj,min] = Nme.gss_release_name() [maj,min] = TargNme.gss_release_name( [maj,min] = Cred.gss_release_cred() sock_close(sock) except KeyboardInterrupt: print "interrupt" sock_write(sock,'') [maj,min,data] = context.gss_delete_sec_context() [maj,min] = TargNme.gss_release_name( [maj,min] = Nme.gss_release_name() [maj,min] = Cred.gss_release_cred() sock_close(sock) except IndexError: print "Usage: ",sys.argv[0]," " except excBADNME,val: [maj1,min1,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in init-sec-context because of :",mesg except excBADCRD,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in acquire_credential because of:",mesg except excBADCTX,val: [maj,min,mesg_ctxt,mesg] = support.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in init_sec_context because of:",mesg except excBADSEAL,val: [maj,min,mesg_ctxt,mesg] = suportp.gss_display_status(val,GSS_C_GSS_CODE, \ "GSS_C_NULL_OID",0) print "Error in seal because of:",mesg ################################################################################ Reference URL's: Python: http://www.python.org SWIG: http://www.cs.utah.edu/~beazley/SWIG/swig.html # ============================================================================= # # Copyright (C) DSTC Pty Ltd (ACN 052 372 577) 1993, 1994, 1995, 1996, 1997. # Unpublished work. All Rights Reserved. # This software is being provided "AS IS" without warranty of # any kind. In no event shall DSTC Pty Ltd be liable for # damage of any kind arising out of or in connection with # the use or performance of this software. # # ============================================================================= --------------8587C8328098EFE645EFC5A4-- --------------ms8A99BD97D191F07B6EB5597C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKLgYJKoZIhvcNAQcCoIIKHzCCChsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B7owggSEMIID7aADAgECAhAV4oOYVg1pE0gVFzzXJ4WbMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDMyMTAwMDAw MFoXDTAwMDMyMDIzNTk1OVowggEoMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD0Rlbm5pcyBHbGF0dGluZzE1MDMGCSqG SIb3DQEJARYmZGVubmlzLmdsYXR0aW5nQHNvZnR3YXJlLW11bml0aW9ucy5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKSBSrAz19P5zPsu3odv359aq1FIuU7RXSXlVga0DqpE ST8T6/e3wtn1f8NnfnytpCWP4r2FgO51Z2Q8o5fy99Gajtlm5tYDBEm09HGWoxAYfEJE8oVI lMCDRQazW5WFiY8WkoNl36eoVl0Oa5rsaSMnk5u45R7Mu3wyLRBooXfnAgMBAAGjggEGMIIB AjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUF BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVy aVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2Ug bGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0B AQQFAAOBgQAlb2LpvHzHBF/o/uILYbM2MGnIkf4y7PN+XQnMAXpk1mIFeVtIH+kquwCo93ra 9h1wdohBxmPt4Sw/EHG4WNr8PnYXuo7kFOBokqSTOYQTr/6zbSKnjXhO3N4qWKoS0dK0G8GO QTKulULvZBkmbnHJ1YIvES2KH7hC2Uzs1K7SDDCCAy4wggKXoAMCAQICEQDSdi6NFAw9fbKo JV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4s TElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFs IFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgT Vi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMC AQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0G CSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVq D7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9d WBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEBXig5hWDWkTSBUX PNcnhZswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw05OTEwMjgxNzQ0MzdaMCMGCSqGSIb3DQEJBDEWBBTw1qCiZkLkjOdvnCoqo6RK Gm78qDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgJAA O8ZsbODTxrLAklgI2cWIdp52CYFMjOc0OCQvirKBtR8rPCCaPGE37RlaPwZmVBGpgKocgR8A vuAz+k9Se7jXJHrCwIrxYhnnlhkfRoV2PVHbsiS/0wLTFtsDV1+k6x6calC1xXApTbOVSBK+ DQu++JsHwUMuwWbHBixbH7pY --------------ms8A99BD97D191F07B6EB5597C-- ========================================================================== 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 Oct 28 16:11:33 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10026 for ; Thu, 28 Oct 1999 16:11:28 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA03531 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 12:27:09 -0700 (PDT) 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 MAA03512 for ; Thu, 28 Oct 1999 12:27:04 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Oct 1999 12:25:02 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE216812E@seine.valicert.com> From: Jack Kabat To: Michael Smith Cc: Joe Salowey , ietf-cat-wg@lists.Stanford.EDU Subject: RE: Objects as tokens Date: Thu, 28 Oct 1999 12:25:01 -0700 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 Michael, The main issue I see with your proposal is that it leads to interoperability problems. If I use GSS implementation Y, which supports object X, there is no guarantee that implementation Z will also support object X. This leads to an application being tied to a particular implementation of JGSS - something that we should not be encouraging. GSS has always been clear about separating the application protocol from GSS protocols. The reason for my addition of streams into the JGSS specification was precisely to solve the issue you are tackling with and to take advantage of the OO encapsulation, yet not to tie down to a particular implementation. Notice that you are free to create your own stream class which can handle any application protocol you desire. For example, if I have my token embedded in RPC protocol, I might create an XDR stream which I then supply into JGSS. Now, every time JGSS does a read, my stream will perform the necessary XDR decoding (and any other application protocol specific processing). Because this is done in the stream class, I can freely use any JGSS implementation. Using streams allows the application to use protocol specific objects directly in JGSS, but the logic is kept in the stream implementation and not JGSS. This is rightly so, since the protocol is application specific and not JGSS specific. I agree with you that this functionality is useful and Java lends itself well to supporting it, so we should take advantage of it, but the logic should be supplied by the application and not JGSS. Regards, Jack > -----Original Message----- > From: Michael Smith [mailto:ms@gf.org] > Sent: Thursday, October 28, 1999 8:04 AM > To: ietf-cat-wg@lists.Stanford.EDU > Cc: Joe Salowey > Subject: RE: Objects as tokens (was: GSSAPI issues...) > > > At 01:56 PM 10/27/99 -0700, Joe Salowey wrote: > > First the GSSv2 RFC defines > >tokens as OCTET STRINGs not objects, so changing this in the language > >binding is not wise since this was not considered in GSSv2. > > The transition from procedural languages to object-oriented > ones is, as we all know, a big step. I think it's fair to say that > GSS-API has its origins at a time when procedural languages > were very much the dominant paradigm. In procedural languages > -- and particularly, of course, in 'C' -- a series of bytes is > about the least characterized, most abstract thing there is. > A sequence > of bytes can be anything, and everything is in the last analysis a > sequence of bytes. In Java, though, the least-characterized, most > abstract thing is Object. In saying that tokens are OCTET > STRINGS, the > GSS-API spec places the least possible constraint, in a procedural > language, on what can be passed as a token: it says, in effect, > give the mech a blob and it's up to the mech to parse it. The > equivalent > in Java -- the least-characterized, most-abstract, minimal-constraint > specification for tokens -- is Object. This follows from a > fundamental > difference between procedural and object-oriented languages. > > >There are a > >number of considerations that must be met to insure > interoperability across > >implementations and platforms. For example, object types must be > >standardized somewhere. > > I don't see that this follows. I can easily envision situations > in which an implementation of protocol X has, on Ann's end of the > wire, an object representation A of the state of that protocol, and > the implementation on Bob's end has a totally different object > representation B of X, or a representation which isn't object > oriented at all (perhaps Bob is a 'C' monoglot). The only requirement > is that Ann and Bob have, respectively, representations acceptable > to their respective local implementations. > > Actually, I think that my proposal (with the methods to advertise > what kinds of objects are locally supported as tokens) is considerably > more helpful to applications than the OCTET STRING specification. > With OCTET STRING, any Bob who needs to extract and/or > build a token from his protocol interactions with Ann needs prior > knowledge of how to do that: take one byte from column A, two from > column B, etc. With my scheme, Bob can get a list of object types > which will will least give him something to go on in putting > together a token. If the architect and/or administrator of the > system Bob is running on have done their work well, he's quite > likely to find that one of the objects supported just happens > to be one he already has lying around, or knows how to construct. > > >It is also worthwhile to note that while DAA is in the IETF > standards track > >it is NOT a GSSAPI mechanism. > > As are (are not?) many other protocols in very common use. > > My own perspective on this is a down-and-dirty one. The > waters in which I sail are full of "legacy systems" wallowing > like icebergs, and "middleware" vendors plying their deadly > craft like Barbary pirates. GSS-API actually offers me > a very promising means to insulate applications from the > morass of protocols in use in this so-called "application > infrastructure," and from its constant flux. The less > hospitable GSS is to mechanisms designed without GSS in mind, > the less useful it is to me. > > --Michael Smith > ms@gf.org > > ============================================================== > ============ > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 16:28:30 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10801 for ; Thu, 28 Oct 1999 16:28:27 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id MAA10672 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 12:55:38 -0700 (PDT) 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 MAA10648 for ; Thu, 28 Oct 1999 12:55:33 -0700 (PDT) Received: from taller.eng.sun.com ([129.144.174.34]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11204; Thu, 28 Oct 1999 12:55:31 -0700 (PDT) Received: from vishwas.eng.sun.COM (vishwas [129.144.124.222]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id MAA17400; Thu, 28 Oct 1999 12:55:28 -0700 (PDT) Date: Thu, 28 Oct 1999 12:55:31 -0700 (PDT) From: Mayank Upadhyay To: Michael Smith cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: Objects as tokens (was: GSSAPI issues...) In-Reply-To: <199910281901.PAA09990@gf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > I remember the conversation well; the problem here is not my > advancing age, but my application requirements. ... ... > > Interestingly, the broadening of type which I propose offers a way > out of this corner, I think, at least for Java applications and mechanism > implementations. If mechs can indicate the types of objects > that they accept as tokens, this provides a way of structuring the set > of potential input tokens, analogous to the structuring provided by > Oid encapsulation, but considerably more powerful and less rigid. .... .... > Not "blindly," and not a "plain object"; the idea is to find out what > kinds of specific objects -- _extensions_ of "plain," or abstract, Object -- > the mech supports and then pass one of those. Nor is this confined > to single-mechanism implementations; it's perfectly compatible with > multi-mechanism ones, and even SPI-based ones with a "shim". Who creates one of these mechanism specific objects? Is that logic in the application layer? If your application and your mechanism are joined at the hip, I'm beginning to wonder what you're achieving by using the GSS-API. Maybe your needs will be best served by directly programming to a mechanism specific API. Have you considered this option? -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 Oct 28 16:29:58 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10866 for ; Thu, 28 Oct 1999 16:29:56 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id NAA11989 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 13:00:21 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id NAA11965 for ; Thu, 28 Oct 1999 13:00:16 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 28 Oct 1999 20:00:16 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id PAA10125; Thu, 28 Oct 1999 15:59:34 -0400 Message-Id: <199910281959.PAA10125@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 28 Oct 1999 20:00:14 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Oct 1999 16:00:14 -0500 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: RE: Objects as tokens Cc: Jack Kabat Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 12:25 PM 10/28/99 -0700, Jack Kabat wrote: >Michael, > > >The main issue I see with your proposal is that >it leads to interoperability problems. If I use GSS >implementation Y, which supports object X, there is >no guarantee that implementation Z will also support >object X. This leads to an application being tied >to a particular implementation of JGSS Well, it might lead to an application being dependent on a given implementation, or a given class of implementations, of a given mechanism, but not on a given implementation of JGSS. For the kind of cases that I'm trying to address here, this isn't a problem. My problem is supplying mechanism implementations -- really, of course, translation layers to existing infrastructure -- which acommodate known requirements of applications in known environments. If I know that applications require mechs to accept objects of type foo.bar.Blob as tokens, I'm not going to deploy a mech that doesn't do that. But if I have GSS-API as an abstraction layer, I can swap out my.local.RACF in favor of mynewimproved.local.RACF or my.local.SomethingElse or even my.consultants.SnakeOil, and if one of these implementers has blundered and forgotten to support foo.bar.Blob as a token, I'll know about it right away -- I'll get a nice informative Exception. Whereas if they have a different understanding of the structure of a token in a byte array, I'll have some very fussy debugging to do. No doubt if I were a commercial supplier of mechanism implementations, I wouldn't take this approach -- particularly if the mechs were being shipped free-standing from any application protocols. I'd very likely just specify that you need to give me a byte array and no other kind of Object, and that would be that. Note that nothing in my suggestion prevents a mechanism implementer from doing precisely this. >The reason for my addition of streams into the JGSS >specification was precisely to solve the issue you are >tackling with and to take advantage of the OO encapsulation, >yet not to tie down to a particular implementation. >Notice that you are free to create your own stream class >which can handle any application protocol you desire [....] >but the logic should be supplied by the application >and not JGSS. Ah, but this is precisely the rub. There are many companies (and this is one of them) where there is considered to be a big difference between system programmers and application programmers. To say that functionality of this kind needs to be supplied by the application would get me hanged from the nearest lamppost. Note, by the way, that I don't propose to have the functionality supplied "by JGSS", but by the mechanism implementation. All I need from JGSS is to get the damn token object across the API. And I'm beginning to think that Hannibal had an easier time getting his elephants across the Alps. --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 18:20:24 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16191 for ; Thu, 28 Oct 1999 18:20:22 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA08086 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 14:47:48 -0700 (PDT) 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 OAA08073 for ; Thu, 28 Oct 1999 14:47:46 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Oct 1999 14:45:43 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2168158@seine.valicert.com> From: Jack Kabat To: Joe Salowey Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: GSS-API Java Bindings: Changes in new draft Date: Thu, 28 Oct 1999 14:45:42 -0700 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 Hello, Here are some more comments about the old interface vs concrete class discussion.... Interfaces are appropriate in many environments and I think there is a place for them in our specification. This is why we have changed the GSSName, GSSCredential and GSSContext to use them. But I don't think they are always appropriate. Having concrete classes gives the following advantage (and yes Michael, it is related to constructors). When specified as concrete class in our draft, all implementation must provide a GSSManager class. Then, all applications can safely instantiate a GSSManager object in their implementation: GSSManager mgr = new GSSManager(); If we take the route of interfaces, each GSS implementation will implement a GSSManager behaviour in some object, but how will the applications know what class to instantiate to get this behaviour? For example, my implementation will have class X implement GSSManager interface, while Michael's will have class Y implement the interface. The application code now needs to determine, in some out of band way, which class to create to get the GSSManager functionality. If I switch between implementation, I have to change the class I create! This is also the motivation behind having a GSSFactory/GSSManger class in the first place. Otherwise we could just require the user to instantiate the other interfaces directly. Instead, we provide GSSManager to have the logic to know which class it should create for each of the interfaces. I'm also skeptical about the loss of flexibility argument w.r.t to the GSSManager class. I think this was a fair argument when talking about the more general classes of GSSContext, Credential and Name, but does not have as much weight here. I think satisfying the interoperability requirement and ease of use by the applications far outweighs any other possible loss in flexibility. Regards, Jack > -----Original Message----- > From: Joe Salowey [mailto:joes@wrq.com] > Sent: Monday, October 25, 1999 4:15 PM > To: ietf-cat-wg@lists.Stanford.EDU > Subject: RE: GSS-API Java Bindings: Changes in new draft > > > > I'd rather not see any more concrete classes in the API than > we need to. A > factory interface provides the capability of allowing the > programmer to do > most of what needs to be done in a standard way without > forcing a particular > implementation. The GSSManager class forces a particular > implementation (it > forces you to have a concrete class > org.ietf.gssapi.GSSManager and it also > assumes a provider infrastructure). I would rather see an > interface here > than a concrete class to get these tasks done. The interface > would consist > of > > createName > createCredential > createContext > getMechs > getNamesForMech > getMechsForName > > I'm not sure much is gained by specifying this as a concrete > class and I > think flexibility is lost. The factory interface provides value for > developers trying to use GSSAPI without constraining the underlying > implementation. > > Joe > > > > -----Original Message----- > > From: Mayank Upadhyay [mailto:Mayank.Upadhyay@Eng.Sun.COM] > > Sent: Friday, October 22, 1999 5:45 PM > > To: ietf-cat-wg@lists.Stanford.EDU > > Cc: Jack Kabat > > Subject: GSS-API Java Bindings: Changes in new draft > > ... Text Removed > > (6) Removed the GSSFactory interface > > > > Left it upto the SPI to define provider based GSSFactory's. The > > GSSManger class provides factory methods to obtain instances of the > > interfaces GSSName, GSSCredential, and GSSContext at the top > > level. Those may or may not internally use any SPI level GSSFactory > > obtained from providers. > > > > An application that wants to use its own custom complete GSS > > implementation can simply subclass GSSManager from a standard GSS > > package. > > > > This hides any SPI related functionality in the GSS layer. Mechanism > > specific factories logically belong in the layer below the GSS. > > Applications using the GSS-API should be isolated from the > SPI layer. > > > > > > (7) Changed static methods in GSSManger to non-static > > > > If any preferences are set through static methods, they > influence all > > code running in the same JVM. This is not an acceptable > situation for > > applets in the same browser. Also, applications can now instantiate > > multiple GSSManager's and have different provider > preferences on each > > of them. Some of these GSSManager's may even be from the > applications > > own custom GSS implementation. > > > > > > (8) Modified sample code to match the changes in the API. > > > > =================================================================== > > ========================================================================== 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 Oct 28 18:35:25 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17119 for ; Thu, 28 Oct 1999 18:35:23 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id OAA09498 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 14:53:25 -0700 (PDT) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id OAA09483 for ; Thu, 28 Oct 1999 14:53:21 -0700 (PDT) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JHO75BMMGIC6D5E8@GI.COM> for ietf-cat-wg@lists.stanford.edu; Thu, 28 Oct 1999 14:53:27 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Oct 1999 14:57:30 -0400 Content-return: allowed Date: Thu, 28 Oct 1999 17:53:41 -0400 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: PKINIT, rev 10 To: "'John Brezak (Exchange)'" , "'Brian Tung'" , "'ietf-cat-wg@lists.stanford.edu'" Message-id: <97DEDE66B3DCD11199D200805FA71BE2020F2384@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BF2176.4885D090" 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_01BF2176.4885D090 Content-Type: text/plain Also, it appears that "the name of each certifier in the certificate chain must be added to the transited field of the ticket", is not precise enough. Kerberos revisions draft says: "A realm name ending with a "." is interpreted as being prepended to the previous realm". The X500-RFC2253 encoding of a realm name can theoretically end on a '.', but you don't want it to be prepended to the previous realm. Kerberos revisions has some other rules that don't apply to a X500-RFC2253 encoding of a realm, but this is the only one that appears to be a problem. > -----Original Message----- > From: John Brezak (Exchange) [SMTP:jbrezak@Exchange.Microsoft.com] > Sent: Thursday, October 28, 1999 11:40 AM > To: 'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu' > Subject: RE: PKINIT, rev 10 > > There is an issue in PKINIT having to do with the use of the transited > field > and compatability with existing KDCs. > > From PKINIT-10: > > Since each certifier in the certification path of a user's > certificate is equivalent to a separate Kerberos realm, the name > of each certifier in the certificate chain must be added to the > transited field of the ticket. The format of these realm names is > defined in Section 3.1 of this document. If applicable, the > transit-policy-checked flag should be set in the issued ticket. > > In this case the transited field would contain X500-RFC2253 nametype. Most > of the widely deployed Kerberos realms are not able to check this nametype > and will reject any ticket obtained via PKINIT from a realm that does > this. > > For example the MIT Kerberos 1.0.5 KDC will fail with "Illegal cross-realm > ticket" when it encounters a PKINIT'ed ticket that implements this. > > If this mechanism is required, then there will be no interop with existing > deployed Kerberos realms. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > John Brezak * mailto:jbrezak@microsoft.com > Microsoft Corporation * 425-936-2602 > One Microsoft Way > Redmond, WA 98052 > > ========================================================================== > 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_01BF2176.4885D090 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: PKINIT, rev 10

Also, it appears = that "the name of each = certifier in the certificate chain must be added to the transited field = of the ticket", is not precise enough. 

Kerberos revisions = draft says: "A realm name ending with a "." is = interpreted as being prepended to the previous realm".  = The X500-RFC2253 encoding of a realm name can = theoretically end on a '.', but you don't want it to be prepended to = the previous realm.  Kerberos revisions has some other rules that = don't apply to a X500-RFC2253 encoding of a realm, but this is the only one that = appears to be a problem.

 

    -----Original Message-----
    From:   John Brezak (Exchange) = [SMTP:jbrezak@Exchange.Microsoft.com]
    Sent:   Thursday, October 28, 1999 11:40 AM
    To:     'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu'
    Subject:       = RE: PKINIT, rev 10

    There is an issue in PKINIT having to = do with the use of the transited field
    and compatability with existing = KDCs.

    From PKINIT-10:

    Since each certifier in the = certification path of a user's
        certificate is = equivalent to a separate Kerberos realm, the name
        of each certifier = in the certificate chain must be added to the
        transited field of = the ticket.  The format of these realm names is
        defined in Section = 3.1 of this document.  If applicable, the
        = transit-policy-checked flag should be set in the issued ticket.

    In this case the transited field would = contain X500-RFC2253 nametype. Most
    of the widely deployed Kerberos = realms are not able to check this nametype
    and will reject any ticket obtained = via PKINIT from a realm that does this.

    For example the MIT Kerberos 1.0.5 KDC = will fail with "Illegal cross-realm
    ticket" when it encounters a = PKINIT'ed ticket that implements this.

    If this mechanism is required, then = there will be no interop with existing
    deployed Kerberos realms.


    =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
    John = Brezak           =        * mailto:jbrezak@microsoft.com
    Microsoft = Corporation        * = 425-936-2602
    One Microsoft Way
    Redmond, WA 98052

    =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=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=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_01BF2176.4885D090-- ========================================================================== 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 Oct 28 18:36:50 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17172 for ; Thu, 28 Oct 1999 18:36:49 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA12789 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 15:06:15 -0700 (PDT) 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 PAA12774 for ; Thu, 28 Oct 1999 15:06:11 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Oct 1999 15:04:08 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2168166@seine.valicert.com> From: Jack Kabat To: Michael Smith Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: Objects as tokens Date: Thu, 28 Oct 1999 15:04:07 -0700 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 > >The main issue I see with your proposal is that > >it leads to interoperability problems. If I use GSS > >implementation Y, which supports object X, there is > >no guarantee that implementation Z will also support > >object X. This leads to an application being tied > >to a particular implementation of JGSS > > Well, it might lead to an application being dependent > on a given implementation, or a given class of implementations, > of a given mechanism, but not on a given implementation > of JGSS. Not sure I see the distinction here? .... > [....] > >but the logic should be supplied by the application > >and not JGSS. > > > Ah, but this is precisely the rub. There are many > companies (and this is one of them) where there is > considered to be a big difference between system > programmers and application programmers. To say > that functionality of this kind needs to be supplied > by the application would get me hanged from the > nearest lamppost. I don't think anyone wants this :-) Sounds like you are the developer for the JGSS, the mechanism, and the protocol for some other group of "application" developers. So there is nothing stopping you from also developing a subclass of stream that you supply with your packages and protocol implementation. This should keep you safe from any harm and keep the users happy. This would also allow you to pass the "damn token object across the API." GSS tokens have a mechanism independent header which identifies the mechanism and allows the implementation to pass it to the correct mechanism. Not sure how this would work with your approach? jack > > Note, by the way, that I don't propose to have > the functionality supplied "by JGSS", but by > the mechanism implementation. All I need from JGSS > is to get the damn token object across the API. > And I'm beginning to think that Hannibal had an > easier time getting his elephants across the Alps. > > --Michael Smith > ms@gf.org > ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Oct 28 19:08:35 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18870 for ; Thu, 28 Oct 1999 19:08:33 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA21268 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 15:40:03 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA21242 for ; Thu, 28 Oct 1999 15:39:57 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Oct 1999 15:39:29 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A569040DF080@SIT.platinum.corp.microsoft.com> From: "John Brezak (Exchange)" To: "'Medvinsky, Sasha (SD-EX)'" , "'Brian Tung'" , "'ietf-cat-wg@lists.stanford.edu'" Subject: RE: PKINIT, rev 10 Date: Thu, 28 Oct 1999 15:39:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2195.4A224059" 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_01BF2195.4A224059 Content-Type: text/plain Granted, but this still doesn't give you interoperability with existing KDCs. Are you suggesting the users that have authenticated with PKINIT not be able to access services in realms that are using the currently available KDCs? -----Original Message----- From: Medvinsky, Sasha (SD-EX) [mailto:SMedvinsky@gi.com] Sent: Thursday, October 28, 1999 2:54 PM To: John Brezak (Exchange); 'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu' Subject: RE: PKINIT, rev 10 Also, it appears that "the name of each certifier in the certificate chain must be added to the transited field of the ticket", is not precise enough. Kerberos revisions draft says: "A realm name ending with a "." is interpreted as being prepended to the previous realm". The X500-RFC2253 encoding of a realm name can theoretically end on a '.', but you don't want it to be prepended to the previous realm. Kerberos revisions has some other rules that don't apply to a X500-RFC2253 encoding of a realm, but this is the only one that appears to be a problem. -----Original Message----- From: John Brezak (Exchange) [SMTP:jbrezak@Exchange.Microsoft.com] Sent: Thursday, October 28, 1999 11:40 AM To: 'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu' Subject: RE: PKINIT, rev 10 There is an issue in PKINIT having to do with the use of the transited field and compatability with existing KDCs. From PKINIT-10: Since each certifier in the certification path of a user's certificate is equivalent to a separate Kerberos realm, the name of each certifier in the certificate chain must be added to the transited field of the ticket. The format of these realm names is defined in Section 3.1 of this document. If applicable, the transit-policy-checked flag should be set in the issued ticket. In this case the transited field would contain X500-RFC2253 nametype. Most of the widely deployed Kerberos realms are not able to check this nametype and will reject any ticket obtained via PKINIT from a realm that does this. For example the MIT Kerberos 1.0.5 KDC will fail with "Illegal cross-realm ticket" when it encounters a PKINIT'ed ticket that implements this. If this mechanism is required, then there will be no interop with existing deployed Kerberos realms. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak * mailto:jbrezak@microsoft.com Microsoft Corporation * 425-936-2602 One Microsoft Way Redmond, WA 98052 ========================================================================== 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_01BF2195.4A224059 Content-Type: text/html RE: PKINIT, rev 10
Granted, but this still doesn't give you interoperability with existing KDCs. Are you suggesting the users that have authenticated with PKINIT not be able to access services in realms that are using the currently available KDCs?
-----Original Message-----
From: Medvinsky, Sasha (SD-EX) [mailto:SMedvinsky@gi.com]
Sent: Thursday, October 28, 1999 2:54 PM
To: John Brezak (Exchange); 'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu'
Subject: RE: PKINIT, rev 10

Also, it appears that "the name of each certifier in the certificate chain must be added to the transited field of the ticket", is not precise enough. 

Kerberos revisions draft says: "A realm name ending with a "." is interpreted as being prepended to the previous realm".  The X500-RFC2253 encoding of a realm name can theoretically end on a '.', but you don't want it to be prepended to the previous realm.  Kerberos revisions has some other rules that don't apply to a X500-RFC2253 encoding of a realm, but this is the only one that appears to be a problem.

 

    -----Original Message-----
    From:   John Brezak (Exchange) [SMTP:jbrezak@Exchange.Microsoft.com]
    Sent:   Thursday, October 28, 1999 11:40 AM
    To:     'Brian Tung'; 'ietf-cat-wg@lists.stanford.edu'
    Subject:        RE: PKINIT, rev 10

    There is an issue in PKINIT having to do with the use of the transited field
    and compatability with existing KDCs.

    From PKINIT-10:

    Since each certifier in the certification path of a user's
        certificate is equivalent to a separate Kerberos realm, the name
        of each certifier in the certificate chain must be added to the
        transited field of the ticket.  The format of these realm names is
        defined in Section 3.1 of this document.  If applicable, the
        transit-policy-checked flag should be set in the issued ticket.

    In this case the transited field would contain X500-RFC2253 nametype. Most
    of the widely deployed Kerberos realms are not able to check this nametype
    and will reject any ticket obtained via PKINIT from a realm that does this.

    For example the MIT Kerberos 1.0.5 KDC will fail with "Illegal cross-realm
    ticket" when it encounters a PKINIT'ed ticket that implements this.

    If this mechanism is required, then there will be no interop with existing
    deployed Kerberos realms.


    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    John Brezak                  * mailto:jbrezak@microsoft.com
    Microsoft Corporation        * 425-936-2602
    One Microsoft Way
    Redmond, WA 98052

    ==========================================================================
    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_01BF2195.4A224059-- ========================================================================== 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 Oct 28 19:17:59 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19325 for ; Thu, 28 Oct 1999 19:17:58 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id PAA22401 for ietf-cat-wg-out720680; Thu, 28 Oct 1999 15:44:49 -0700 (PDT) Received: from smaug.wrq.com (smaug.wrq.com [150.215.17.2]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id PAA22389 for ; Thu, 28 Oct 1999 15:44:43 -0700 (PDT) Received: from abra.wrq.com (abra.wrq.com [150.215.8.10]) by smaug.wrq.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA20071; Thu, 28 Oct 1999 15:44:40 -0700 (PDT) Received: by abra.wrq.com with Internet Mail Service (5.5.2448.0) id ; Thu, 28 Oct 1999 15:44:39 -0700 Message-ID: <86EDBD151558D311BB5700508B2E03FC762378@pikachu.wrq.com> From: Joe Salowey To: "'Jack Kabat'" , Joe Salowey Cc: ietf-cat-wg@lists.Stanford.EDU Subject: RE: GSS-API Java Bindings: Changes in new draft Date: Thu, 28 Oct 1999 15:44:37 -0700 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 comments added in text below. > -----Original Message----- > From: Jack Kabat [mailto:jackk@valicert.com] > Sent: Thursday, October 28, 1999 2:46 PM > To: Joe Salowey > Cc: ietf-cat-wg@lists.Stanford.EDU > Subject: RE: GSS-API Java Bindings: Changes in new draft (... some lines removed) > Having concrete classes gives the following advantage > (and yes Michael, it is related to constructors). When > specified as concrete class in our draft, all implementation > must provide a GSSManager class. Then, all applications > can safely instantiate a GSSManager object in their > implementation: GSSManager mgr = new GSSManager(); > > If we take the route of interfaces, each GSS implementation > will implement a GSSManager behaviour in some object, but > how will the applications know what class to instantiate to > get this behaviour? This is part of the documentation that comes with the particular GSSAPI implementation. > For example, my implementation will have class X implement > GSSManager interface, while Michael's will have class Y > implement the interface. The application code now needs to > determine, in some out of band way, which class to create > to get the GSSManager functionality. If I switch between > implementation, I have to change the class I create! This is true, but that may be all you have to do, and depending on the needs of your application it may not even require a code change. How does one write a provider for GSSManager? You need an SPI. If GSSManager is concrete and required then the high level bindings are tied to the SPI. > This is also the motivation behind having a GSSFactory/GSSManger > class in the first place. Otherwise we could just require the > user to instantiate the other interfaces directly. Instead, we > provide GSSManager to have the logic to know which class it > should create for each of the interfaces. What happens if there is a GSSManager in the class search path on the local system, and a different GSSManager is being downloaded in the code of an applet? In java 1.1 the applet class will not get run (and the applet will not get the functionality it requires). Java 2 has more of a chance of working, but I have not tested it out yet. > I'm also skeptical about the loss of flexibility argument w.r.t > to the GSSManager class. I think this was a fair argument when > talking about the more general classes of GSSContext, Credential > and Name, but does not have as much weight here. The flexibility is in the capability to deal with multiple implementations of Java GSSAPI. > I think satisfying the interoperability requirement and ease > of use by the applications far outweighs any other possible > loss in flexibility. The interoperability requirements are not satisfied. How do Java 1.1 (yes people still use java 1.1 and even 1.02) applets make sure the get the right GSSManager class? How does one write a mechanism to fit in the GSSManager provider framework (where is the SPI)? I would like to see a document which essentially contains everything you need to code a mechanism and use the interfaces. Which Java GSS implementation you use is up to the application developer (unless there is only one implementation). Interface code should be provided as well as code for the simple container classes (such as OID, MessageProps, ChannelBindings). Right now the GSSManager class is undefined. In order to define it you need to specify an SPI to make the document complete. This means the SPI and high level API must progress together. Thanks for listening, Joe > Regards, > > Jack > ========================================================================== 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 Oct 29 10:46:40 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28526 for ; Fri, 29 Oct 1999 10:46:39 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id HAA29377 for ietf-cat-wg-out720680; Fri, 29 Oct 1999 07:05:27 -0700 (PDT) Received: from firewall.ext (gf.gf.org [207.86.8.110]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id HAA29357 for ; Fri, 29 Oct 1999 07:05:22 -0700 (PDT) Received: from inside-www.gf.org by firewall.ext via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 29 Oct 1999 14:05:22 UT Received: from firewall.gf.org by gf.org (SMI-8.6/SMI-SVR4) id KAA11046; Fri, 29 Oct 1999 10:04:38 -0400 Message-Id: <199910291404.KAA11046@gf.org> Received: from w043.z209220023.nyc-ny.dsl.cnc.net ([209.220.23.43]) by firewall.gf.org via smtpd (for inside-www.gf.org [10.1.1.2]) with SMTP; 29 Oct 1999 14:05:18 UT X-Sender: ms@mail.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Oct 1999 10:05:18 -0500 To: Jack Kabat From: Michael Smith Subject: RE: Objects as tokens Cc: ietf-cat-wg@lists.Stanford.EDU Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk At 03:04 PM 10/28/99 -0700, Jack wrote: [I had written:] >> Well, it might lead to an application being dependent >> on a given implementation, or a given class of implementations, >> of a given mechanism, but not on a given implementation >> of JGSS. > >Not sure I see the distinction here? Well, recall that I have in mind ultimately that the local GSS implementation will be a "shim" and it will load mechanism implementations (MIs) dynamically. If an application is written so as to depend on the ability to pass an instance of foo.bar.Blob as a token, then the only MIs it can use, obviously, are those that know how to process such an object. That is, there's a functionality, or feature, requirement for MIs. This doesn't seem like quite the same thing as being bound to a particular JGSS implementation or even a particular mech implementation. > > So there is nothing >stopping you from also developing a subclass of >stream that you supply with your packages and >protocol implementation. This should keep you >safe from any harm and keep the users happy. This >would also allow you to pass the >"damn token object across the API." If I understand what you're suggesting here, it's similar to Mayank's suggestion in an earlier mail. Under this approach, an application would have know what (local) subclass of Stream to instantiate for a given combination of input token object and mech. How would it find out? Whereas with my approach, which incorporates a means for mechs to inform applications what objects they will accept, less prior knowledge is required of applications, and their code is cleaner. In any case, logic to process token information in various kinds of objects seems inextricably bound up with mechanism knowedge, and thus naturally belongs with mechanism implementation. Are we starting to repeat ourselves, I wonder? Should we defer further discussion of this matter to DC, when hopefully more people will get involved? --Michael Smith ms@gf.org ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Oct 29 11:42:31 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01873 for ; Fri, 29 Oct 1999 11:42:31 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id IAA14409 for ietf-cat-wg-out720680; Fri, 29 Oct 1999 08:13:52 -0700 (PDT) Received: from oberon.ctd.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA14392 for ; Fri, 29 Oct 1999 08:13:48 -0700 (PDT) Received: from anl.gov (pembroke.ctd.anl.gov [146.137.180.163]) by oberon.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA07755; Fri, 29 Oct 1999 10:13:38 -0500 (CDT) Message-ID: <3819B9B5.73DE82E0@anl.gov> Date: Fri, 29 Oct 1999 10:13:57 -0500 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: "Medvinsky, Sasha (SD-EX)" CC: "'John Brezak (Exchange)'" , "'Brian Tung'" , "'ietf-cat-wg@lists.stanford.edu'" Subject: Re: PKINIT, rev 10 References: <97DEDE66B3DCD11199D200805FA71BE2020F2384@ntas0027.gi.com> 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 While you are discussing how to add CA names into the transited field, consider the more general problem of how you would add the transited field into a X.509 extension. PKINIT lets you use certificates to get a TGT. There are other systems which will issue you a certificate based on a Kerberos ticket. (k5cert for example.) And the certificate chain used on PKINIT may have been delegated as well. Our Globus project (http://www.gobus.org) has a GSSAPI built on the SSL protocol. We have added delegation, by having the acceptor create a key pair and the initiator sign a "proxy" certificate which becomes part of the certificate chain. This allows for the equivalent of a Kerberos forwarded ticket. These proxy certificate and the chain can be used to get a TGT. We are not using PKINIT yet, but SSLK5 which is functional equivalent, using an SSL session to transmit the AS_REQ to a modified KDC which will accept the SSL authentication and issue a TGT, returned by the SSL session. So it is possible to do the following: Smart Card with X.509 certificate use to get a local proxy certificate (done on PC much like doing a kinit) Proxy certificate chain uses sslk5 to get TGT (could use PKINIT here) (so I can do a ktelnet) TGT is forwarded across realms. (ktelnet to ktelnetd) TGT is used to get a short term certificate at some site k5cert program. (get a certificate to run Globus job) certificate is delegated using another proxy certificate (Globus job starts many processes at other sites delegating proxies which are used for process-to-process authentication) Proxy certificates then used to get another TGT. (Need access to local DFS which is using Kerberos) So it might be time to reexamine the transited field of Kerberos, and look at a more general structure, which could be carried in a ticket, or as a X509 extension, and added to as certificates are issued based on the kerberos ticket, or kerberos tickets are issued based on a certificate chain. -- 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 Sat Oct 30 09:57:42 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14191 for ; Sat, 30 Oct 1999 09:57:42 -0400 (EDT) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id GAA22419 for ietf-cat-wg-out720680; Sat, 30 Oct 1999 06:35:21 -0700 (PDT) Received: from oberon.ctd.anl.gov ([130.202.20.3]) by lists.Stanford.EDU (8.9.3/8.9.3) with ESMTP id GAA22396 for ; Sat, 30 Oct 1999 06:35:17 -0700 (PDT) Received: from anl.gov (pembroke.ctd.anl.gov [146.137.180.163]) by oberon.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id IAA11627; Sat, 30 Oct 1999 08:35:15 -0500 (CDT) Message-ID: <381AF426.4888AD2F@anl.gov> Date: Sat, 30 Oct 1999 08:35:34 -0500 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: "'ietf-cat-wg@lists.stanford.edu'" CC: "Medvinsky, Sasha (SD-EX)" , "'John Brezak (Exchange)'" , "'Brian Tung'" Subject: Re: PKINIT, rev 10 References: <97DEDE66B3DCD11199D200805FA71BE2020F2384@ntas0027.gi.com> 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 While you are discussing how to add CA names into the transited field, consider the more general problem of how you would add the transited field into a X.509 extension. PKINIT lets you use certificates to get a TGT. There are other systems which will issue you a certificate based on a Kerberos ticket. (k5cert for example.) And the certificate chain used on PKINIT may have been delegated as well. Our Globus project (http://www.gobus.org) has a GSSAPI built on the SSL protocol. We have added delegation, by having the acceptor create a key pair and the initiator sign a "proxy" certificate which becomes part of the certificate chain. This allows for the equivalent of a Kerberos forwarded ticket. These proxy certificate and the chain can be used to get a TGT. We are not using PKINIT yet, but SSLK5 which is functional equivalent, using an SSL session to transmit the AS_REQ to a modified KDC which will accept the SSL authentication and issue a TGT, returned by the SSL session. So it is possible to do the following: Smart Card with X.509 certificate use to get a local proxy certificate (done on PC much like doing a kinit) Proxy certificate chain uses sslk5 to get TGT (could use PKINIT here) (so I can do a ktelnet) TGT is forwarded across realms. (ktelnet to ktelnetd) TGT is used to get a short term certificate at some site k5cert program. (get a certificate to run Globus job) certificate is delegated using another proxy certificate (Globus job starts many processes at other sites delegating proxies which are used for process-to-process authentication) Proxy certificates then used to get another TGT. (Need access to local DFS which is using Kerberos) So it might be time to reexamine the transited field of Kerberos, and look at a more general structure, which could be carried in a ticket, or as a X509 extension, and added to as certificates are issued based on the kerberos ticket, or kerberos tickets are issued based on a certificate chain. (This message is a reposting as the first appears to have not made it to the list. Sorry if you have already received a copy.) -- 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 Sun Oct 31 21:50:48 1999 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29340 for ; Sun, 31 Oct 1999 21:50:47 -0500 (EST) Received: (from daemon@localhost) by lists.Stanford.EDU (8.9.3/8.9.3) id SAA13405 for ietf-cat-wg-out720680; Sun, 31 Oct 1999 18:22:35 -0800 (PST) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.9.3/8.9.3) with SMTP id SAA13361 for ; Sun, 31 Oct 1999 18:22:26 -0800 (PST) From: art123@pacsun.com Received: from 152.pool.atl800.gw.eni.net by MIT.EDU with SMTP id AA08391; Sun, 31 Oct 99 21:22:01 EST Subject: laser printer toner advertisement Date: Sun, 31 Oct 1999 17:53:54 Message-Id: <701.718382.364380@> Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-532-7170**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. NOTE NUMBER (3): OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE THEREOF. ========================================================================== 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