From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jul 2 16:10:21 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA07646; Thu, 2 Jul 98 16:10:21 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA22969 for ietf-cat-wg-out720680; Thu, 2 Jul 1998 12:33:36 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA22964 for ; Thu, 2 Jul 1998 12:33:34 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 2 Jul 1998 19:37:35 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id PAA12194 for ; Thu, 2 Jul 1998 15:38:03 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Thu, 2 Jul 1998 15:36:37 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" Subject: First call: Planning for Chicago IETF CAT session Date: Thu, 2 Jul 1998 15:32:45 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > CAT fanciers: > I've requested one 2-hour slot for CAT at the Chicago IETF (23-28 August), but have not yet heard on its scheduling. If anyone wishes to request time to present material or lead discussion on specific topics related to issue resolution on, and advancement of, WG documents, please make this known by Wednesday, 15 July; I'll plan to distribute a draft agenda (subject to later revision) later this month. Also, it would be helpful for planning purposes if anyone intending to update or submit CAT-related I-Ds before the meeting could indicate their plans when possible. The Internet-Draft submission cutoff will be 7 August. Thanks, ... > --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 Jul 6 16:42:41 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA19005; Mon, 6 Jul 98 16:42:41 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA12036 for ietf-cat-wg-out720680; Mon, 6 Jul 1998 13:02:39 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id NAA12030 for ; Mon, 6 Jul 1998 13:02:36 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com by MIT.EDU with SMTP id AA25748; Mon, 6 Jul 98 16:02:42 EDT Received: from CyberSafe.COM dmzsmtp01.cybersafe.com id MAA04262 for ; Mon, 6 Jul 1998 12:03:05 -0700 Received: from fw1.cybersafe.com(192.156.168.6) by dmzsmtp01.cybersafe.com via smap (V2.0) id xma004260; Mon, 6 Jul 98 12:02:49 -0700 Received: by fw1.cybersafe.com; id NAA07643 Received: from admsvc02.cybersafe.com(10.2.2.52) by fw1.cybersafe.com via smap (4.0a) id xma007641; Mon, 6 Jul 98 13:01:11 +0800 Received: from CyberSafe.COM kerby.cybersafe.com id MAA18982; Mon, 6 Jul 1998 12:58:55 -0700 (PDT) X-Sender: craigh@pop-srvr Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Jul 1998 13:05:38 -0700 To: cat-ietf@mit.edu From: Craig Hotchkiss Subject: GSSAPI v2 gss_process_context_token() inconsistency Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This call seems to have an inherent problem in that the behavior from v1 has changed but the function name remains the same. Since it's impossible in the library to determine which version the user is attempting to leverage, it's impossible to behave differently which makes life difficult for implementors of GSSAPI libraries that are trying to be v1 and v2 compliant. The differing behaviors are that both RFC 2078 and Update 1 allude to a new use for this call -- to handle all context tokens in v2, not just the delete_sec type from v1. However, the C Bindings do not reflect the new v2 usage which casts some doubt to my interpretation. One view is in the draft Update 1 of RFC 2078 (http://www.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-04.txt), it talks a bit vaguely about some other uses for this function outside the v1 handling of gss_delete_sec_context() tokens. Another view is in the C bindings (http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-cbind-05.txt) where it says the call is still only for gss_delete_sec_context() tokens but that implementors are discouraged from having gss_delete_sec_context() emit any tokens at all. In a slightly different third view, the v2 RFC 2078 (ftp://ftp.isi.edu/in-notes/rfc2078.txt) mentions that this call is now "used to process context_tokens received from a peer once a context has been established" which seems to imply that this call is always necessary if any of the context routines return tokens. There are several options to solve this issue. Here's a few that I thought of: - Simplify v2 by removing the call entirely. Forces the case to be made for keeping the call around. - Change the behavior of gss_process_context_token() for v2. If it's intended to process all context tokens, not just delete, change the C bindings to reflect the new usage. Note that v1 users of the v2 library may have minor (no pun intended) side effects because of the behavior change. - Invent a new call for the new behavior and update the documents including the C bindings. This would be a nice clean wall between the v1 and v2 worlds. -craig CyberSafe Corporation (425) 837-1070 ========================================================================== 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 Jul 6 19:44:09 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA22118; Mon, 6 Jul 98 19:44:09 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA18043 for ietf-cat-wg-out720680; Mon, 6 Jul 1998 16:13:18 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id QAA18038 for ; Mon, 6 Jul 1998 16:13:15 -0700 (PDT) Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA10666; Mon, 6 Jul 98 19:13:11 EDT Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.sap-ag.de (out) with SMTP id BAA09995; Tue, 7 Jul 1998 01:14:02 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA20109; Tue, 7 Jul 1998 01:12:50 +0200 Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id BAA21278; Tue, 7 Jul 1998 01:12:56 +0200 (METDST) From: Martin Rex Message-Id: <199807062312.BAA21278@hw1464.wdf.sap-ag.de> Subject: Re: GSSAPI v2 gss_process_context_token() inconsistency To: craig.hotchkiss@CyberSafe.COM (Craig Hotchkiss) Date: Tue, 7 Jul 1998 01:12:56 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: from "Craig Hotchkiss" at Jul 6, 98 01:05:38 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Craig Hotchkiss wrote: > > This call seems to have an inherent problem in that the behavior from v1 > has changed but the function name remains the same. Since it's impossible > in the library to determine which version the user is attempting to > leverage, it's impossible to behave differently which makes life difficult > for implementors of GSSAPI libraries that are trying to be v1 and v2 > compliant. > > The differing behaviors are that both RFC 2078 and Update 1 allude to a new > use for this call -- to handle all context tokens in v2, not just the > delete_sec type from v1. However, the C Bindings do not reflect the new v2 > usage which casts some doubt to my interpretation. That's not quite the intention as far as I understand. gss_process_context_token() is supposed to consume all context level tokens after either context-establishment calls gss_init_sec_context() and gss_accept_sec_context() has already returned GSS_S_COMPLETE. For a context establishment that needs an odd number of message exchanges (1, 3, (2n-1)) the last context-level token is normally created on the initiator side and returned from gss_init_sec_context() along with GSS_S_COMPLETE. When the acceptor then does it's final call to gss_accept_sec_context() it expects to see GSS_S_COMPLETE and no more context level tokens. But in some cases the context establishment may fail on this final step, and it is now permitted to gssapi mechanim implementations to return a context-level token along with a fatal routine error to propagate the error back to the initiator at the gssapi level. However it depends on the application whether it actually transfers this token back, or if it simply releases and ignores it, and propagates an error at the application level (or simply drops the connection). When the application transfers such a final and unexpected token, the initiator may no longer pass it to gss_init_sec_context(), because this call had returned GSS_S_COMPLETE on the previous iteration. This is where gss_process_context_token() gets called and what is documented in RFC2078 / bis. Passing regular context establishment tokens to gss_process_context_token() results in undefined behaviour. I don't think that it is hard to implement this "change", since the existance of a context-level error propagation token is gssapi mechanism specific -- i.e. if it is not defined in the mechanism specification then it is not permitted for this mechanism because it would impair interoperability. This misalignment was #9 on my list of "pending alignment issues of C-Bindings with rfc2078bis" in a message to the CAT mailing list on May, 1st, 1998 -Martin ========================================================================== 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 Jul 7 16:12:46 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA13333; Tue, 7 Jul 98 16:12:46 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA18606 for ietf-cat-wg-out720680; Tue, 7 Jul 1998 12:40:52 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id MAA18600 for ; Tue, 7 Jul 1998 12:40:49 -0700 (PDT) Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id PAA06465 for ; Tue, 7 Jul 1998 15:40:45 -0400 (EDT) Message-Id: <199807071940.PAA06465@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU Subject: Discussion on PW_EXPTIME last-req X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 07 Jul 1998 15:40:44 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I'd like some discussion on my proposal for a new last-req type called PW_EXPTIME. Rather than retype all of my points, y'all can just read about it at http://gost.isi.edu/info/kerberos/open_issues.html (it's issue #19 on the RFC-1510 revision). I implemented it, it works great, yada yada yada. IIRC, I believe the Heimdal guys have implemented this as well. If no one really cares to talk about it now, then I'll be happy to table it until the Chicago IETF. --Ken ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jul 8 04:46:28 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA26576; Wed, 8 Jul 98 04:46:28 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id BAA12485 for ietf-cat-wg-out720680; Wed, 8 Jul 1998 01:04:25 -0700 (PDT) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [193.10.159.47]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id BAA12480 for ; Wed, 8 Jul 1998 01:04:22 -0700 (PDT) Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3) id 0ytpCc-0005U6-00; Wed, 8 Jul 1998 10:03:46 +0200 To: Ken Hornstein Cc: ietf-cat-wg@lists.stanford.edu Subject: Re: Discussion on PW_EXPTIME last-req References: <199807071940.PAA06465@ginger.cmf.nrl.navy.mil> X-Emacs: 19.34 Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.77) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 08 Jul 1998 10:03:45 +0200 In-Reply-To: Ken Hornstein's message of "Tue, 07 Jul 1998 15:40:44 -0400" Message-Id: Lines: 7 X-Mailer: Gnus v5.6.9/Emacs 19.34 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Ken Hornstein writes: > IIRC, I believe the Heimdal guys have implemented this as well. Yup. Issue 31 also deals with this, and some related things. /Johan ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jul 13 11:25:53 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA09743; Mon, 13 Jul 98 11:25:53 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id HAA18358 for ietf-cat-wg-out720680; Mon, 13 Jul 1998 07:40:06 -0700 (PDT) Received: from chrysalis.iris.com (fw2.iris.com [198.112.211.10]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id HAA18353 for ; Mon, 13 Jul 1998 07:40:00 -0700 (PDT) From: John_Wray@iris.com Received: from arista.iris.com ([9.95.65.15]) by chrysalis.iris.com (Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) with SMTP id 85256640.0050C74D; Mon, 13 Jul 1998 10:42:19 -0400 Received: by arista.iris.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10- 1998)) id 85256640.00511826 ; Mon, 13 Jul 1998 10:45:45 -0400 X-Lotus-Fromdomain: IRIS To: Ietf-cat-wg@lists.stanford.edu Message-Id: <85256640.00511479.00@arista.iris.com> Date: Mon, 13 Jul 1998 10:41:05 -0400 Subject: New GSSAPI C-bindings draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I've just submitted an updated C-bindings document, so expect draft-ietf-cat-gssv2-cbind-06.txt to show up on the repositories in the next couple of days. Changes from the previous version: Reformatting. Changing jobs meant I no longer have all the nroff macros I used to use, so I took the opportunity to migrate to a slightly more modern formatting program. One unfortunate result of this is that diff-ing this version against the previous one won't give much useful information. Incorporation of the 2078bis alignments posted to the list by Martin. A number of typos and clarification requests received by e-mail (also from Martin). 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 Tue Jul 14 08:20:09 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA01622; Tue, 14 Jul 98 08:20:09 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id EAA22375 for ietf-cat-wg-out720680; Tue, 14 Jul 1998 04:54:03 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id EAA22370 for ; Tue, 14 Jul 1998 04:54:00 -0700 (PDT) Received: from odin.ietf.org by MIT.EDU with SMTP id AA16573; Tue, 14 Jul 98 07:53:55 EDT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA25450; Tue, 14 Jul 1998 07:53:56 -0400 (EDT) Message-Id: <199807141153.HAA25450@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-gssv2-cbind-06.txt Date: Tue, 14 Jul 1998 07:53:55 -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 : C-bindings Author(s) : J. Wray Filename : draft-ietf-cat-gssv2-cbind-06.txt Pages : 101 Date : 13-Jul-98 This draft document specifies C language bindings for Version 2 of the Generic Security Service Application Program Interface (GSSAPI), which is described at a language-independent conceptual level in other drafts [GSSAPI]. If approved, will revise RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-gssv2-cbind-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-gssv2-cbind-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-06.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: <19980713104608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-gssv2-cbind-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980713104608.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 Jul 15 15:01:20 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA04206; Wed, 15 Jul 98 15:01:20 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA17569 for ietf-cat-wg-out720680; Wed, 15 Jul 1998 11:25:47 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id LAA17562 for ; Wed, 15 Jul 1998 11:25:42 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 15 Jul 1998 18:30:43 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id OAA19090; Wed, 15 Jul 1998 14:30:20 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Wed, 15 Jul 1998 14:28:50 -0400 Message-Id: From: "Linn, John" To: "Ietf-cat-wg@lists.Stanford.EDU" , "'Wray, John'" Subject: RE: New GSSAPI C-bindings draft Date: Wed, 15 Jul 1998 14:26:20 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Thanks, John. I've now submitted a revised version of 2078bis, to become draft-ietf-cat-rfc2078bis-05.txt. Its changes are confined to the following small set of detailed points, primarily resulting from Martin Rex's alignment review against the C bindings. My assumption is that once this pair of drafts emerges on the I-D directories and there's been an opportunity to verify their consistency with the alignment review, we'll be ready to forward the pair from the WG on to the IESG. Unless further inconsistencies are reported and need to be reconciled, I'll propose to forward the documents to the IESG on Friday, 31 July. Comments or discussion? Changes in rfc2078bis-05.txt: Replaced boilerplate paragraph about I-D repositories with new one received from Cynthia Clark. Per list discussion 1 May 1998 as a result of C bindings alignment review, added the following: - to discussion of GSS_S_COMPLETE status for gss_inquire_context(), noted that not only must a context be in "open" state for a name to be returned but also that the context peer's name must be known. (This aligns with recent change to gss_init_sec_context(), permitting the possibility of GSS_C_NO_NAME input for target_name.) - added following commentary in Sec. 1.2.7 (Per-Message Protection During Context Establishment): Callers making use of per-message protection services in advance of GSS_S_COMPLETE status should be aware of the possibility that a subsequent context establishment step may fail, and that certain context data (e.g., mech_type) as returned for subsequent calls may change. - in gss_init_sec_context() and gss_accept_sec_context(), stated that mech_type OID may be returned in conjunction with fatal error cases, if mechanism determinable. (Absent discussion, did not presume consensus for stronger recommendation or requirement.) Reconciled reported inconsistencies between gss_init_sec_context() and gss_inquire_context() by stating, for gss_inquire_context(), that the lifetime_rec value is returned only for contexts in "open" state, and that mech_type must be returned for contexts in "open" state and may be returned for other contexts. --jl > ---------- > From: John_Wray@iris.com[SMTP:John_Wray@iris.com] > Sent: Monday, July 13, 1998 10:41 AM > To: Ietf-cat-wg@lists.Stanford.EDU > Subject: New GSSAPI C-bindings draft > > I've just submitted an updated C-bindings document, so expect > draft-ietf-cat-gssv2-cbind-06.txt to show up on the repositories in the > next couple of days. > > Changes from the previous version: > > Reformatting. Changing jobs meant I no longer have all > the nroff macros I used to use, so I took the opportunity > to migrate to a slightly more modern formatting program. > One unfortunate result of this is that diff-ing this version > against the previous one won't give much useful > information. > > Incorporation of the 2078bis alignments posted to the > list by Martin. > > A number of typos and clarification requests received > by e-mail (also from Martin). > > 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 > ========================================================================== 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 Jul 16 07:29:17 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA21051; Thu, 16 Jul 98 07:29:17 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id DAA10243 for ietf-cat-wg-out720680; Thu, 16 Jul 1998 03:55:32 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id DAA10226 for ; Thu, 16 Jul 1998 03:55:29 -0700 (PDT) Received: from odin.ietf.org by MIT.EDU with SMTP id AA07365; Thu, 16 Jul 98 06:55:42 EDT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA09691; Thu, 16 Jul 1998 06:55:19 -0400 (EDT) Message-Id: <199807161055.GAA09691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-05.txt Date: Thu, 16 Jul 1998 06:55: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 : Generic Security Service Application Program Interface Version 2, Update 1 Author(s) : J. Linn Filename : draft-ietf-cat-rfc2078bis-05.txt Pages : 100 Date : 15-Jul-98 This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-rfc2078bis-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-rfc2078bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980715153748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-rfc2078bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-rfc2078bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980715153748.I-D@ietf.org> --OtherAccess-- --NextPart-- ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Jul 16 14:38:42 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA28345; Thu, 16 Jul 98 14:38:42 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA13129 for ietf-cat-wg-out720680; Thu, 16 Jul 1998 11:01:20 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id LAA13124 for ; Thu, 16 Jul 1998 11:01:17 -0700 (PDT) Received: from pollux.usc.edu by MIT.EDU with SMTP id AA27486; Thu, 16 Jul 98 14:01:05 EDT Received: (from tsudik@localhost) by pollux.usc.edu (8.8.8/8.8.8/usc) id LAA22540 for cat-ietf@mit.edu; Thu, 16 Jul 1998 11:01:09 -0700 (PDT) Date: Thu, 16 Jul 1998 11:01:09 -0700 (PDT) From: Gene Tsudik Message-Id: <199807161801.LAA22540@pollux.usc.edu> To: cat-ietf@mit.edu Subject: ACM CCCS'98: Preliminary Program and Call for Participation Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Subject: ACM CCCS'98: Preliminary Program and Call for Participation Preliminary Program Fifth ACM Conference on Computer and Communications Security San Francisco, California November 2-5, 1998 Sponsored by ACM SIGSAC For more information visit http://www.research.att.com/~reiter/ccs5 Launched in 1993, ACM CCCS is the ACM's flagship security conference. CCCS covers a wide range of topics in computer/information security and offers a technical as well as a tutorial program. Presentation topics are diverse, addressing state-of-the-art results of both practical and theoretical nature (and everything in between). ================================= DAY 0 =================================== Monday, November 2, 1998: Tutorials Core Topics Emerging Topics 9:00-12:30 Cryptography: Theory and Programming Languages and Security Applications Martin Abadi (DEC Systems Research Dan Boneh (Stanford Center, USA) and George Necula University, USA) (Carnegie Mellon University, USA) 12:30-13:30 Lunch 13:30-17:00 To Be Determined Authentication Protocol Verification and Analysis Jon Millen (SRI International, USA) ================================= DAY 1 =================================== Tuesday, November 3, 1998: Technical sessions 9:00-10:00 Keynote address Risks and challenges in computer-communication infrastructures Peter G. Neumann (SRI International, USA) 10:00-10:30 Break 10:30-12:00 Group key management Communication complexity of group key distribution Klaus Becker (R^3 Security Engineering, Switzerland) and Uta Wille (IBM Zurich Research Laboratory, Switzerland) Key management for encrypted broadcast Avishai Wool (Bell Labs, USA) Authenticated group key agreement and related protocols Giuseppe Ateniese (USC Information Sciences Institute, USA), Michael Steiner (IBM Zurich Research Laboratory, Switzerland), and Gene Tsudik (USC Information Sciences Institute, USA) 12:00-13:30 Lunch 13:30-15:30 Anonymity The design, implementation and operation of an email pseudonym server David Mazie`res and M. Frans Kaashoek (Massachusetts Institute of Technology, USA) Panel: Anonymity on the Internet Moderator: Paul Syverson (Naval Research Lab, USA) 15:30-16:00 Break 16:00-17:00 Mobile code security History-based access-control for mobile code Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of California, Santa Barbara, USA) A specification of Java loading and bytecode verification Allen Goldberg (Kestrel Institute, USA) ================================= DAY 2 =================================== Wednesday, November 4, 1998: Technical sessions 9:00-10:30 Cryptography A new public key cryptosystem based on higher residues David Naccache (Gemplus, France) and Jacques Stern (Ecole Normale Superieure, France) An efficient non-interactive statistical zero-knowledge proof system for quasi-safe prime products Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele Micciancio (Massachusetts Institute of Technology, USA), and Tal Rabin (IBM T.J. Watson Research Center, USA) Communication-efficient anonymous group identification Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni Di Crescenzo (University of California, San Diego, USA) 10:30-11:00 Break 11:00-12:00 Invited talk The development of public key cryptography Martin Hellman 12:00-13:30 Lunch 13:30-15:00 Systems A security architecture for computational grids Ian Foster (Argonne National Laboratory, USA), Carl Kesselman, Gene Tsudik (USC Information Sciences Institute, USA), and Steven Tuecke (Argonne National Laboratory, USA) Design of a high-performance ATM firewall Jun Xu and Mukesh Singhal (Ohio State University, USA) A practical secure physical random bit generator Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs, USA) and Ari Juels (RSA Labs, USA) 15:00-15:30 Break 15:30-16:30 Invited talk Trust in cyberspace? A research roadmap Fred Schneider (Cornell University, USA) ================================= DAY 3 =================================== Thursday, November 5, 1998: Technical sessions 9:00-10:30 Protocol design and analysis A probabilistic poly-time framework for protocol analysis Pat Lincoln (SRI International, USA), John Mitchell, Mark Mitchell (Stanford University, USA), and Andre Scedrov (University of Pennsylvania, USA) On using public-key cryptography in password protocols Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo Krawczyk (Technion, Israel) Cryptanalysis of Microsoft's point-to-point tunneling protocol Bruce Schneier (Counterpane Systems, USA) 10:30-11:00 Break 11:00-12:00 System monitoring How to prove where you are Eran Gabber and Avishai Wool (Bell Labs, USA) Temporal sequence learning and data reduction for anomaly detection Terran Lane and Carla E. Brodley (Purdue University, USA) ================== Worst paper award and author lampooning =================== Steering committee chair: Ravi Sandhu, George Mason University General chair: Li Gong, JavaSoft Program chair: Mike Reiter AT&T Labs, Room A269, 180 Park Avenue Florham Park, NJ 07932-0971 USA phone: +973-360-8349 Awards chair: Jacques Stern, ENS/DMI Publication chair: Stuart Stubblebine, AT&T Labs Publicity chair: Gene Tsudik, USC ISI Program committee: Martin Abadi, DEC SRC David Naccache, Gemplus Bill Cheswick, Lucent/Bell Labs Hilarie Orman, DARPA/ITO Carl Ellison, Cybercash Avi Rubin, AT&T Labs--Research Ed Felten, Princeton University Pierangela Samarati, Universita di Milano Paul Karger, IBM T.J. Watson Gene Tsudik, USC ISI Steve Kent, BBN Corporation Paul Van Oorschot, Entrust Technologies Ueli Maurer, ETH Zurich Bennet Yee, UCSD Cathy Meadows, Naval Res. Lab Moti Yung, CertCo For more information, visit http://www.research.att.com/~reiter/ccs5 ========================================================================== 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 Jul 22 13:36:47 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA25540; Wed, 22 Jul 98 13:36:47 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id KAA15761 for ietf-cat-wg-out720680; Wed, 22 Jul 1998 10:03:50 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id KAA15755 for ; Wed, 22 Jul 1998 10:03:47 -0700 (PDT) Received: from mercury.Sun.COM by MIT.EDU with SMTP id AA15985; Wed, 22 Jul 98 13:03:38 EDT Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI- 8.6/mail.byaddr) with SMTP id KAA21091 for ; Wed, 22 Jul 1998 10:03:44 -0700 Received: from thestork.eng.sun.com (thestork.Eng.Sun.COM [129.146.88.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id KAA17185 for ; Wed, 22 Jul 1998 10:03:42 -0700 Received: from ontario (ontario.Eng.Sun.COM) by thestork.eng.sun.com (Sun Internet Mail Server sims.3.5.1998.06.29.00.09) with SMTP id <0EWI001G2A256S@thestork.eng.sun.com> for cat-ietf@mit.edu; Wed, 22 Jul 1998 10:03:42 -0700 (PDT) Date: Wed, 22 Jul 1998 09:57:08 -0700 (PDT) From: Jack Kabat Subject: Java GSS-API bindings To: cat-ietf@mit.edu Reply-To: Jack Kabat Message-Id: <0EWI001G3A256S@thestork.eng.sun.com> Mime-Version: 1.0 X-Mailer: dtmail 1.2.0 CDE Version 1.2_28 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Content-Md5: vD+YtUlbgSlmn4NegpSp5Q== Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk As suggested by John Linn, I am inquiring within this group about the level of interest in pursuing a Java GSS-API bindings. We here at Sun are in the process of preparing a draft of the Java bindings for submission to the working group. Currently, I am in discussion with Michael Smith who has expressed interest in this topic. If anyone else is interested please voice your interest to the group. Thank you, 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 Wed Jul 22 17:21:38 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA29396; Wed, 22 Jul 98 17:21:38 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id NAA25387 for ietf-cat-wg-out720680; Wed, 22 Jul 1998 13:48:57 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id NAA25382 for ; Wed, 22 Jul 1998 13:48:54 -0700 (PDT) Received: from indy.gradient.com by MIT.EDU with SMTP id AA17848; Wed, 22 Jul 98 16:48:46 EDT Received: from beech by indy.gradient.com (8.7.1/Gradient-3) id QAA06853; Wed, 22 Jul 1998 16:48:45 -0400 (EDT) Message-Id: <199807222048.QAA06853@indy.gradient.com> X-Sender: kevin@indy.gradient.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 22 Jul 1998 16:50:27 -0400 To: Jack Kabat From: Kevin Farrington Subject: Re: Java GSS-API bindings Cc: cat-ietf@mit.edu In-Reply-To: <0EWI001G3A256S@thestork.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Jack, Gradient would be very interested in pursuing the Java GSS-API bindings, as we are already doing some work in this area for Kerberos and DCE. Thanks. Kevin At 09:57 AM 7/22/98 -0700, you wrote: > > >As suggested by John Linn, I am inquiring within this group >about the level of interest in pursuing a Java GSS-API bindings. >We here at Sun are in the process of preparing a draft of the >Java bindings for submission to the working group. > >Currently, I am in discussion with Michael Smith who has expressed >interest in this topic. If anyone else is interested please voice >your interest to the group. > > >Thank you, > >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 > Kevin M. Farrington Gradient Technologies, Inc kevin_f@gradient.com 2 Mt. Royal Avenue (508) 624-9600 Marlborough, MA 01752 ========================================================================== 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 Jul 22 19:37:18 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA01797; Wed, 22 Jul 98 19:37:18 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA01038 for ietf-cat-wg-out720680; Wed, 22 Jul 1998 16:02:34 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id QAA01027 for ; Wed, 22 Jul 1998 16:02:29 -0700 (PDT) Received: from dmzsmtp01.cybersafe.com by MIT.EDU with SMTP id AA15697; Wed, 22 Jul 98 19:02:20 EDT Received: from CyberSafe.COM dmzsmtp01.cybersafe.com id PAA06579; Wed, 22 Jul 1998 15:02:43 -0700 Received: from fw1.cybersafe.com(192.156.168.6) by dmzsmtp01.cybersafe.com via smap (V2.0) id xma006575; Wed, 22 Jul 98 15:02:17 -0700 Received: by fw1.cybersafe.com; id QAA25648 Received: from admsvc02.cybersafe.com(10.2.2.52) by fw1.cybersafe.com via smap (4.0a) id xma025630; Wed, 22 Jul 98 15:59:48 +0800 Received: from CyberSafe.COM kerby.cybersafe.com id PAA29328; Wed, 22 Jul 1998 15:57:50 -0700 (PDT) X-Sender: craigh@pop-srvr Message-Id: In-Reply-To: <0EWI001G3A256S@thestork.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jul 1998 16:04:53 -0700 To: cat-ietf@mit.edu From: Craig Hotchkiss Subject: Re: Java GSS-API bindings Cc: Jack Kabat Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk CyberSafe is very interested in Java GSSAPI bindings since we've had some customer interest in object-oriented security APIs. We've just upgraded our C-bound GSSAPI toolkit to GSSAPI v2 and are studying the OOP issues now so your project is timely. Please let us know how we can help. -craig >As suggested by John Linn, I am inquiring within this group >about the level of interest in pursuing a Java GSS-API bindings. >We here at Sun are in the process of preparing a draft of the >Java bindings for submission to the working group. > >Currently, I am in discussion with Michael Smith who has expressed >interest in this topic. If anyone else is interested please voice >your interest to the group. > > >Thank you, > >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 ========================================================================== 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 Jul 22 20:13:54 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA02409; Wed, 22 Jul 98 20:13:54 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA02558 for ietf-cat-wg-out720680; Wed, 22 Jul 1998 16:46:40 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id QAA02553 for ; Wed, 22 Jul 1998 16:46:37 -0700 (PDT) Received: from typhoon.dstc.qut.edu.au by MIT.EDU with SMTP id AA21160; Wed, 22 Jul 98 19:46:27 EDT Received: from localhost (gibson@localhost [127.0.0.1]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with SMTP id JAA23750; Thu, 23 Jul 1998 09:46:26 +1000 (EST) From: Simon Gibson Message-Id: <199807222346.JAA23750@typhoon.dstc.qut.edu.au> X-Authentication-Warning: typhoon.dstc.qut.edu.au: gibson@localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 2.0zeta 7/24/97 To: Jack Kabat Cc: cat-ietf@mit.edu, gibson@dstc.qut.edu.au Subject: Re: Java GSS-API bindings In-Reply-To: Your message of "Wed, 22 Jul 98 09:57:08 MST." <0EWI001G3A256S@thestork.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Jul 98 09:46:25 +1000 X-Mts: smtp Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > > As suggested by John Linn, I am inquiring within this group > about the level of interest in pursuing a Java GSS-API bindings. > We here at Sun are in the process of preparing a draft of the > Java bindings for submission to the working group. > > Currently, I am in discussion with Michael Smith who has expressed > interest in this topic. If anyone else is interested please voice > your interest to the group. > > > Thank you, > > Jack Kabat We did some work designing an OO GSSAPI binding for Python in November last year. I would imagine that some of the OO ideas would be useful from that work. Our approach was through necessity in securing a project written in Python. We used SWIG to wrap the functions and then added an OO layer. This allowed us to use an existing mechanism for the security but gave a neat OO feel from the application. The bindings can be seen at: http://www.dstc.qut.edu.au/MSU/projects/gss-api/V2Python.bindings I should probably redo the format. Email me if you want some explanation of anything and we would be happy to contribute in some way if needed. Simon =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-==-=-=-=-=-=-=-= Simon Gibson, Telephone: +61 7 3864 5120 Research Scientist, Security Unit, Facsimile: +61 7 3864 1282 CRC for Distributed Systems Technology, Queensland University of Technology, email: Brisbane Qld 4001, Australia. http://www.dstc.edu.au =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ========================================================================== 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 Jul 23 00:00:29 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA06324; Thu, 23 Jul 98 00:00:29 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id UAA09398 for ietf-cat-wg-out720680; Wed, 22 Jul 1998 20:25:57 -0700 (PDT) Received: from postman.opengroup.org (postman.opengroup.org [130.105.1.152]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id UAA09393 for ; Wed, 22 Jul 1998 20:25:54 -0700 (PDT) Received: from prion (prion.camb.opengroup.org [130.105.3.59]) by postman.opengroup.org (8.8.6/8.8.6) with SMTP id XAA28929 for ; Wed, 22 Jul 1998 23:25:53 -0400 (EDT) Message-Id: <2.2.32.19980723032358.0134ec18@postman.camb.opengroup.org> X-Sender: sanfilip@postman.camb.opengroup.org X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jul 1998 23:23:58 -0400 To: ietf-cat-wg@lists.stanford.edu From: Tom Sanfilippo Subject: Re: Java GSS-API bindings Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I don't know if this has been posted recently, but there was the JGSS project at UIUC. See: http://choices.cs.uiuc.edu/Security/JGSS/jgss.html I thought they pretty much did a binding with a native library interface, though I've never used it myself. Of course, I don't think they did a binding spec. I was hoping to connect the Java-Kerberos libraries up to JGSS at some point, and help finish it out if necessary. So, needless to say, I'm interested in the bindings. Tom Sanfilippo Research Scientist The Open Group Research Institute > As suggested by John Linn, I am inquiring within this group > about the level of interest in pursuing a Java GSS-API bindings. > We here at Sun are in the process of preparing a draft of the > Java bindings for submission to the working group. > > Currently, I am in discussion with Michael Smith who has expressed > interest in this topic. If anyone else is interested please voice > your interest to the group. > > > Thank you, > > 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 Thu Jul 23 20:07:03 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA27021; Thu, 23 Jul 98 20:07:03 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id QAA10049 for ietf-cat-wg-out720680; Thu, 23 Jul 1998 16:39:59 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id QAA10044 for ; Thu, 23 Jul 1998 16:39:56 -0700 (PDT) Received: from typhoon.dstc.qut.edu.au by MIT.EDU with SMTP id AA02290; Thu, 23 Jul 98 19:39:46 EDT Received: from localhost (gibson@localhost [127.0.0.1]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with SMTP id JAA31749 for cat-ietf@mit.edu; Fri, 24 Jul 1998 09:39:50 +1000 (EST) From: Simon Gibson Message-Id: <199807232339.JAA31749@typhoon.dstc.qut.edu.au> X-Authentication-Warning: typhoon.dstc.qut.edu.au: gibson@localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 2.0zeta 7/24/97 To: cat-ietf@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jul 98 09:39:49 +1000 X-Mts: smtp Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk > > > As suggested by John Linn, I am inquiring within this group > about the level of interest in pursuing a Java GSS-API bindings. > We here at Sun are in the process of preparing a draft of the > Java bindings for submission to the working group. > > Currently, I am in discussion with Michael Smith who has expressed > interest in this topic. If anyone else is interested please voice > your interest to the group. > > > Thank you, > > Jack Kabat We did some work designing an OO GSSAPI binding for Python in November last year. I would imagine that some of the OO ideas would be useful from that work. Our approach was through necessity in securing a project written in Python. We used SWIG to wrap the functions and then added an OO layer. This allowed us to use an existing mechanism for the security but gave a neat OO feel from the application. The bindings can be seen at: http://www.dstc.qut.edu.au/MSU/projects/gss-api/V2Python.bindings I should probably redo the format. Email me if you want some explanation of anything and we would be happy to contribute in some way if needed. Simon =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-==-=-=-=-=-=-=-= Simon Gibson, Telephone: +61 7 3864 5120 Research Scientist, Security Unit, Facsimile: +61 7 3864 1282 CRC for Distributed Systems Technology, Queensland University of Technology, email: Brisbane Qld 4001, Australia. http://www.dstc.edu.au =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ========================================================================== 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 Jul 24 13:25:45 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA14902; Fri, 24 Jul 98 13:25:45 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id JAA05468 for ietf-cat-wg-out720680; Fri, 24 Jul 1998 09:55:42 -0700 (PDT) Received: from moe.gf.org (moe.gf.org [207.86.8.75]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id JAA05462 for ; Fri, 24 Jul 1998 09:55:38 -0700 (PDT) Received: from foobar (jlefevre.dialup.access.net [166.84.194.85]) by moe.gf.org (8.8.5/8.8.5) with SMTP id NAA09159 for ; Fri, 24 Jul 1998 13:20:29 -0400 Message-Id: <199807241720.NAA09159@moe.gf.org> X-Sender: ms@moe.gf.org X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 12:57:20 -0400 To: ietf-cat-wg@lists.Stanford.EDU From: Michael Smith Subject: Re: Java GSS-API bindings Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I'm glad to see there's so much more interest in this topic than there was even a couple of months ago. As Jack Kabat indicated, he and I have been having a very interesting and useful (to me at least) correspondence about this subject. For internal use where I work, I have constructed a provisional set of GSS Java bindings, whose most recent version owes a great deal to insights offered by Jack (any remaining idiocies and blunders are, of course, my sole responsibility). Javadoc for the package can be found at . The source for abstract classes, a few small utility classes, and interfaces associated with the package can be downloaded at . This package is offered, without strings, as a contribution to the WG's efforts. Unfortunately, I'll be away on vacation from tomorrow (Saturday July 25) until August 8, so I'll probably miss all the good discussion. Damn! Even so, I would appreciate any comments or observations that this package suggests, and promise faithfully to reply to all such when I get back. --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 Jul 24 15:11:09 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA16680; Fri, 24 Jul 98 15:11:09 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id LAA09287 for ietf-cat-wg-out720680; Fri, 24 Jul 1998 11:29:15 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id LAA09282 for ; Fri, 24 Jul 1998 11:29:12 -0700 (PDT) Received: from odin.ietf.org by MIT.EDU with SMTP id AA00988; Fri, 24 Jul 98 14:29:02 EDT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22420; Fri, 24 Jul 1998 14:29:07 -0400 (EDT) Message-Id: <199807241829.OAA22420@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: cat-ietf@mit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-rfc2078bis-05.txt Date: Fri, 24 Jul 1998 14:29:06 -0400 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --NextPart Note: This announcement is being re-sent with a correction made. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Generic Security Service Application Program Interface Version 2, Update 1 Author(s) : J. Linn Filename : draft-ietf-cat-rfc2078bis-05.txt Pages : 100 Date : 15-Jul-98 The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-rfc2078bis-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-cat-rfc2078bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980723121508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-rfc2078bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-rfc2078bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980723121508.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 Jul 24 16:06:30 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA17620; Fri, 24 Jul 98 16:06:30 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA11817 for ietf-cat-wg-out720680; Fri, 24 Jul 1998 12:29:48 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA11812 for ; Fri, 24 Jul 1998 12:29:45 -0700 (PDT) Received: from smtp3.ny.us.ibm.com by MIT.EDU with SMTP id AB15510; Fri, 24 Jul 98 15:29:36 EDT Received: from relay3.server.ibm.com (relay3.server.ibm.com [9.14.2.100]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id PAA82388; Fri, 24 Jul 1998 15:18:50 -0400 Received: from US.IBM.COM (d04lms01.raleigh.ibm.com [9.37.164.193]) by relay3.server.ibm.com (8.8.7/8.8.7) with SMTP id PAA27418; Fri, 24 Jul 1998 15:23:24 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU017 id 5040100020701154; Fri, 24 Jul 1998 15:32:41 -0400 From: Bob Blakley To: Subject: Re: Java GSS-API bindings Message-Id: <5040100020701154000002L042*@MHS> Date: Fri, 24 Jul 1998 15:32:41 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >> As suggested by John Linn, I am inquiring within this group >> about the level of interest in pursuing a Java GSS-API bindings. >> We here at Sun are in the process of preparing a draft of the >> Java bindings for submission to the working group. >> >> Currently, I am in discussion with Michael Smith who has expressed >> interest in this topic. If anyone else is interested please voice >> your interest to the group. >> >> >> Thank you, >> >> Jack Kabat > >We did some work designing an OO GSSAPI binding for Python in November last >year. I would imagine that some of the OO ideas would be useful from that >work. Our approach was through necessity in securing a project written in >Python. We used SWIG to wrap the functions and then added an OO layer. This >allowed us to use an existing mechanism for the security but gave a neat OO >feel from the application. The bindings can be seen at: > >http://www.dstc.qut.edu.au/MSU/projects/gss-api/V2Python.bindings > >I should probably redo the format. Email me if you want some explanation of >anything and we would be happy to contribute in some way if needed. > >Simon Gibson The CORBA security service was specifically designed to encapsulate GSS-API and is in a sense a somewhat more abstract binding for GSS-API. I'm including some snippets of the CORBA security interfaces for authentication, credential acquisition, and context establishment here for your edification and delight :-) All of the syntax here is CORBA IDL; this could easily be used as the basis for a java implementation. =========== type definitions ============ typedef sequence AttributeList; // Security mech types supported for secure association const CORBA::ServiceDetailType SecurityMechanismType = 1; // security association mechanism type typedef string MechanismType; struct SecurityMechandName { MechanismType mech_type; SecurityName security_name; }; // Authentication return status enum AuthenticationStatus { SecAuthSuccess, SecAuthFailure, SecAuthContinue, SecAuthExpired }; // Association return status enum AssociationStatus { SecAssocSuccess, SecAssocFailure, SecAssocContinue }; // Authentication method typedef unsigned long AuthenticationMethod; // Security features available on credentials. enum SecurityFeature { SecNoDelegation, SecSimpleDelegation, SecCompositeDelegation, SecNoProtection, SecIntegrity, SecConfidentiality, SecIntegrityAndConfidentiality, SecDetectReplay, SecDetectMisordering, SecEstablishTrustInTarget }; // Security feature-value struct SecurityFeatureValue { SecurityFeature feature; boolean value; }; typedef sequenceSecurityFeatureValueList; // Quality of protection which can be specified // for an object reference and used to protect messages enum QOP { SecQOPNoProtection, SecQOPIntegrity, SecQOPConfidentiality, SecQOPIntegrityAndConfidentiality }; // Association options which can be administered // on secure invocation policy and used to // initialize security context typedef unsigned short AssociationOptions; const AssociationOptions NoProtection = 1; const AssociationOptions Integrity = 2; const AssociationOptions Confidentiality = 4; const AssociationOptions DetectReply = 8; const AssociationOptions DetectMisordering = 16; const AssociationOptions EstablishTrustInTarget = 32; const AssociationOptions EstablishTrustInClient = 64; // Flag to indicate whether association options being // administered are the "required" or "supported" set enum RequiresSupports { SecRequires, SecSupports }; // Direction of communication for which // secure invocation policy applies enum CommunicationDirection { SecDirectionBoth, SecDirectionRequest, SecDirectionReply }; // AssociationOptions-Direction pair struct OptionsDirectionPair { AssociationOptions options; CommunicationDirection direction; }; typedef sequenceOptionsDirectionPairList; // Delegation mode which can be administered enum DelegationMode { SecDelModeNoDelegation, // i.e. use own credentials SecDelModeSimpleDelegation, // delegate received credentials SecDelModeCompositeDelegation// delegate both; }; // Association options supported by a given mech type struct MechandOptions { MechanismType mechanism_type; AssociationOptions options_supported; }; typedef sequence MechandOptionsList; ========== principal authentication interface (authenticates and acquires a credential) ============= // Interface PrincipalAuthenticator interface PrincipalAuthenticator { // Locality Constrained Security::AuthenticationStatus authenticate ( in Security::AuthenticationMethod method, in Security::SecurityName security_name, in Security::Opaque auth_data, in Security::AttributeList privileges, out Credentials creds, out Security::Opaque continuation_data, out Security::Opaque auth_specific_data ); Security::AuthenticationStatus continue_authentication ( in Security::Opaque response_data, in Credentials creds, out Security::Opaque continuation_data, out Security::Opaque auth_specific_data ); }; interface SecurityContext; //forward declaration =========== Vault interface (equivalent to gss-init and gss-accept) ============ interface Vault { // Locality Constrained Security::AssociationStatus init_security_context ( in SecurityLevel2::CredentialsList creds_list, in Security::SecurityName target_security_name, in Object target, in Security::DelegationMode delegation_mode, in Security::OptionsDirectionPairList association_options, in Security::MechanismType mechanism, in Security::Opaque mech_data, //from IOR in Security::Opaque chan_binding, out Security::Opaque security_token, out SecurityContext security_context ); Security::AssociationStatus accept_security_context ( in SecurityLevel2::CredentialsList creds_list, in Security::Opaque chan_bindings, in Security::Opaque in_token, out Security::Opaque out_token ); Security::MechandOptionsList get_supported_mechs (); }; =========== Security Context interface (supports functionality of gss-sign and gss-seal) ============ interface SecurityContext { // Locality Constrained readonly attribute SecurityLevel2::CredentialsList received_credentials; readonly attribute Security::SecurityFeatureValueList security_features; Security::AssociationStatus continue_security_context ( in Security::Opaque in_token, out Security::Opaque out_token ); void protect_message ( in Security::Opaque message, in Security::QOP qop, out Security::Opaque text_buffer, out Security::Opaque token ); boolean reclaim_message ( in Security::Opaque text_buffer, in Security::Opaque token, out Security::QOP qop, out Security::Opaque message ); boolean is_valid ( out Security::UtcT expiry_time ); boolean refresh ( ); }; ======================= --bob Bob Blakley IBM Lead Security Architect Voice: +1 (512) 838-8133 Fax: +1 (512) 838-0156 Post: 11400 Burnet Road, Mail Stop 9134, Austin, TX 78758 USA Internet: blakley@us.ibm.com ========================================================================== 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 Jul 25 21:44:15 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA17928; Sat, 25 Jul 98 21:44:15 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id SAA17444 for ietf-cat-wg-out720680; Sat, 25 Jul 1998 18:11:26 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id SAA17439 for ; Sat, 25 Jul 1998 18:11:23 -0700 (PDT) Received: from ingwwdf.sap-ag.de by MIT.EDU with SMTP id AA01024; Sat, 25 Jul 98 21:11:13 EDT Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.sap-ag.de (out) with SMTP id DAA03236; Sun, 26 Jul 1998 03:11:41 +0200 (MESZ) Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA07610; Sun, 26 Jul 1998 03:10:31 +0200 Received: (from d019080@localhost) by hw1464.wdf.sap-ag.de (8.7.6/8.7.1) id DAA11678; Sun, 26 Jul 1998 03:10:44 +0200 (METDST) From: Martin Rex Message-Id: <199807260110.DAA11678@hw1464.wdf.sap-ag.de> Subject: Re: Java GSS-API bindings To: blakley@us.ibm.com (Bob Blakley) Date: Sun, 26 Jul 1998 03:10:44 +0200 (METDST) Cc: cat-ietf@mit.edu In-Reply-To: <5040100020701154000002L042*@MHS> from "Bob Blakley" at Jul 24, 98 03:32:41 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by ingwwdf.sap-ag.de id DAA03236 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Bob Blakley wrote: >=20 > The CORBA security service was specifically designed to encapsulate GSS= -API > and is in a sense a somewhat more abstract binding for GSS-API. > I'm including some snippets of the CORBA security interfaces for > authentication, credential acquisition, and context establishment > here for your edification and delight :-) > All of the syntax here is CORBA IDL; this could easily be used as > the basis for a java implementation. >=20 I must admit that I don=C4't know anything about Corba an Java, and I'm could even be considered ignorant and biased against Corba, but the supplied snipped looks suspiciously wrong about GSS-API in a few details... In the snippet I also see several GSS-API defined terms with a different meaning and several terms that GSS-API doesn't have. I don't particularly like this shift/change in terminology. -Martin > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D type definitions =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > typedef sequence AttributeList; >=20 > // Security mech types supported for secure association > const CORBA::ServiceDetailType SecurityMechanismType =3D 1; >=20 > // security association mechanism type > typedef string MechanismType; > struct SecurityMechandName { > MechanismType mech_type; > SecurityName > security_name; > }; >=20 > // Authentication return status > enum AuthenticationStatus { > SecAuthSuccess, > SecAuthFailure, > SecAuthContinue, > SecAuthExpired > }; "expired authentication" is not defined by GSS-API. >=20 > // Association return status > enum AssociationStatus { > SecAssocSuccess, > SecAssocFailure, > SecAssocContinue > }; >=20 > // Authentication method > typedef unsigned long AuthenticationMethod; >=20 > // Security features available on credentials. > enum SecurityFeature { > SecNoDelegation, > SecSimpleDelegation, > SecCompositeDelegation, > SecNoProtection, > SecIntegrity, > SecConfidentiality, > SecIntegrityAndConfidentiality, > SecDetectReplay, > SecDetectMisordering, > SecEstablishTrustInTarget > }; What is the meaning of this enum? Many of this attributes are available in combination with others, others may be meaningless alone or might be conflicting! Looks extremely weird to me. Is this enum meant to represent multiple values within a set of attributes (instead of a "C" bitfield)? Then why is there a "integrity", "confidentiality" AND a "integrity+confidentiality" ? Btw. confidentiality without integrity is NOT available via GSSAPI. >=20 > // Security feature-value > struct SecurityFeatureValue { > SecurityFeature feature; > boolean value; > }; >=20 > typedef sequenceSecurityFeatureValueList; >=20 > // Quality of protection which can be specified > // for an object reference and used to protect messages > enum QOP { > SecQOPNoProtection, > SecQOPIntegrity, > SecQOPConfidentiality, > SecQOPIntegrityAndConfidentiality > }; QOP at GSSAPI is meant for selecting among different integrity and confidentiality algorithms, NOT to select these basic services. Again, GSS-API doesn't provide confidentiality without integrity (which is a Good Thing!). >=20 > // Association options which can be administered > // on secure invocation policy and used to > // initialize security context > typedef unsigned short AssociationOptions; > const AssociationOptions NoProtection =3D 1; > const AssociationOptions Integrity =3D 2; > const AssociationOptions Confidentiality =3D 4; > const AssociationOptions DetectReply =3D 8; > const AssociationOptions DetectMisordering =3D 16; > const AssociationOptions EstablishTrustInTarget > =3D 32; > const AssociationOptions EstablishTrustInClient =3D 64; >=20 > // Flag to indicate whether association options being > // administered are the "required" or "supported" set >=20 > enum RequiresSupports { > SecRequires, > SecSupports > }; >=20 > // Direction of communication for which > // secure invocation policy applies > enum CommunicationDirection { > SecDirectionBoth, > SecDirectionRequest, > SecDirectionReply > }; >=20 > // AssociationOptions-Direction pair > struct OptionsDirectionPair { > AssociationOptions options; > CommunicationDirection direction; > }; >=20 > typedef sequenceOptionsDirectionPairList; >=20 > // Delegation mode which can be administered > enum DelegationMode { > SecDelModeNoDelegation, // i.e. use own credentials > SecDelModeSimpleDelegation, // delegate received credentials > SecDelModeCompositeDelegation// delegate both; > }; >=20 > // Association options supported by a given mech type > struct MechandOptions { > MechanismType mechanism_type; > AssociationOptions options_supported; > }; > typedef sequence MechandOptionsList; >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D principal authentication interface (auth= enticates and acquires a > credential) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > // Interface PrincipalAuthenticator >=20 > interface PrincipalAuthenticator { // Locality Constrained >=20 > Security::AuthenticationStatus authenticate ( > in Security::AuthenticationMethod method, > in Security::SecurityName security_name, > in Security::Opaque auth_data, > in Security::AttributeList privileges, > out Credentials creds, > out Security::Opaque continuation_data, > out Security::Opaque auth_specific_data > ); >=20 > Security::AuthenticationStatus continue_authentication ( > in Security::Opaque response_data, > in Credentials creds, > out Security::Opaque continuation_data, > out Security::Opaque auth_specific_data > ); >=20 > }; >=20 > interface SecurityContext; //forward declaration >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Vault interface (equivalent to gss-in= it and gss-accept) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > interface Vault { // Locality Constrained >=20 > Security::AssociationStatus init_security_context ( > in SecurityLevel2::CredentialsList creds_list, > in Security::SecurityName target_security_name, > in Object target, > in Security::DelegationMode delegation_mode, > in Security::OptionsDirectionPairList > association_options, > in Security::MechanismType mechanism, > in Security::Opaque mech_data, //from > IOR > in Security::Opaque chan_binding, > out Security::Opaque security_token, > out SecurityContext security_context > ); >=20 > Security::AssociationStatus accept_security_context ( > in SecurityLevel2::CredentialsList creds_list, > in Security::Opaque chan_bindings, > in Security::Opaque in_token, > out Security::Opaque out_token > ); >=20 > Security::MechandOptionsList get_supported_mechs (); > }; >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Security Context interface (supports = functionality of gss-sign and > gss-seal) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > interface SecurityContext { // Locality Constrained >=20 > readonly attribute SecurityLevel2::CredentialsList received_credential= s; > readonly attribute Security::SecurityFeatureValueList security_features= ; >=20 > Security::AssociationStatus continue_security_context ( > in Security::Opaque in_token, > out Security::Opaque out_token > ); >=20 > void protect_message ( > in Security::Opaque message, > in Security::QOP qop, > out Security::Opaque text_buffer, > out Security::Opaque token > ); >=20 > boolean reclaim_message ( > in Security::Opaque text_buffer, > in Security::Opaque token, > out Security::QOP qop, > out Security::Opaque message > ); >=20 > boolean is_valid ( > out Security::UtcT expiry_time > ); >=20 > boolean refresh ( > ); Now this last one looks REALLY strange. What is that "refresh()" supposed to mean? Does it mean "security context refresh"? I don't think so, since security context refresh is nothing that can be done within GSSAPI (or any other abstraction that doesn't include and control program flow and transport/peer communication. And as soon as the library has that power, the "refresh" totally disappears within the library. A remaining problem associated with security context refresh is the "expiration of the security context while a message is in transit". One basically cannot hide this problem from the application, because it does impact the communication architecture and error handling. ========================================================================== 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 Jul 27 14:35:37 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA29776; Mon, 27 Jul 98 14:35:37 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id KAA00450 for ietf-cat-wg-out720680; Mon, 27 Jul 1998 10:40:03 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id KAA00445 for ; Mon, 27 Jul 1998 10:40:01 -0700 (PDT) Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.6.18]) by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id NAA21225 for ; Mon, 27 Jul 1998 13:39:50 -0400 (EDT) Message-Id: <199807271739.NAA21225@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.stanford.edu Subject: draft-ietf-cat-kerberos-passwords-02.txt X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 27 Jul 1998 13:39:46 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I'm part of a large group of sites who are using the MIT Kerberos support for single-use authentication mechanisms, as documented in expired draft draft-ietf-cat-kerberos-passwords-02.txt. We are getting to the point of wanting to use some commercial products with this setup, and the vendors are saying, "Well, where is this protocol documented?". Obviously, I can't really point them to an expired Internet Draft (well, I _could_, but it would be a whole lot better if I could point them to an RFC). Since this draft expired in 1996, I think that no one is still working on it. If this is the case, I'd like to volunteer to take over as editor for this draft and do the work to hopefully advance it to a standard. Does anyone object? --Ken ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jul 27 16:11:38 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA01518; Mon, 27 Jul 98 16:11:38 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id MAA04535 for ietf-cat-wg-out720680; Mon, 27 Jul 1998 12:36:54 -0700 (PDT) Received: from tholian.securid.com (tholian.securid.com [204.167.112.129]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id MAA04530 for ; Mon, 27 Jul 1998 12:36:52 -0700 (PDT) Received: from mail.securid.com by tholian.securid.com via smtpd (for lists.Stanford.EDU [171.64.14.232]) with SMTP; 27 Jul 1998 19:42:49 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id PAA28573 for ; Mon, 27 Jul 1998 15:41:46 -0400 (EDT) Received: by exna01.securitydynamics.com with Internet Mail Service (5.0.1460.8) id ; Mon, 27 Jul 1998 15:40:08 -0400 Message-Id: From: "Linn, John" To: "'CAT-WG List'" Subject: CAT-WG Chicago agenda, draft 1 Date: Mon, 27 Jul 1998 15:37:44 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Draft 1 agenda (based on requests and discussion received as of 27 July 1998) for CAT-WG meeting, Chicago IETF, Monday, 24 August 1998, 0930-1130. 0930-0940: Opening discussion and agenda review 0940-0950: Status of IESG-level WG documents: spnego, idup 0950-1020: rfc2078bis/c-bindings issues (only if not already at IESG, or if issues raised at IESG level) 1020-1030: Status of other ongoing WG work items 1030-1050: T. Ryutov / C. Neuman: proposed new work on authorization API and C bindings therefor 1050-1110: GSS-API Java bindings Further requests and discussion are hereby solicited, for consideration in a subsequent agenda draft to be issued in August. --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 Jul 27 17:38:47 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA02994; Mon, 27 Jul 98 17:38:47 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id OAA07776 for ietf-cat-wg-out720680; Mon, 27 Jul 1998 14:07:03 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id OAA07771 for ; Mon, 27 Jul 1998 14:07:00 -0700 (PDT) Received: from SAINT-ELMOS-FIRE.MIT.EDU by MIT.EDU with SMTP id AA19908; Mon, 27 Jul 98 17:06:50 EDT Received: by saint-elmos-fire.mit.edu (SMI-8.6/4.7) id RAA18376; Mon, 27 Jul 1998 17:06:57 -0400 Date: Mon, 27 Jul 1998 17:06:57 -0400 Message-Id: <199807272106.RAA18376@saint-elmos-fire.mit.edu> To: Ken Hornstein Cc: ietf-cat-wg@lists.stanford.edu From: Tom Yu Subject: Re: draft-ietf-cat-kerberos-passwords-02.txt In-Reply-To: <199807271739.NAA21225@ginger.cmf.nrl.navy.mil> References: <199807271739.NAA21225@ginger.cmf.nrl.navy.mil> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk I believe Marc Horowitz intends to reissue it soon. ---Tom ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Jul 27 17:59:43 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA03346; Mon, 27 Jul 98 17:59:43 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id OAA09037 for ietf-cat-wg-out720680; Mon, 27 Jul 1998 14:34:00 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by lists.Stanford.EDU (8.8.5/8.7.1) with ESMTP id OAA09031 for ; Mon, 27 Jul 1998 14:33:58 -0700 (PDT) Received: from pendragon.cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.6.18]) by ginger.cmf.nrl.navy.mil (8.8.5/8.8.5) with ESMTP id RAA26208; Mon, 27 Jul 1998 17:33:49 -0400 (EDT) Message-Id: <199807272133.RAA26208@ginger.cmf.nrl.navy.mil> To: Tom Yu Cc: ietf-cat-wg@lists.stanford.edu Subject: Re: draft-ietf-cat-kerberos-passwords-02.txt In-Reply-To: Your message of "Mon, 27 Jul 1998 17:06:57 EDT." <199807272106.RAA18376@saint-elmos-fire.mit.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 27 Jul 1998 17:33:47 -0400 From: Ken Hornstein Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >I believe Marc Horowitz intends to reissue it soon. Oh, not _that_ one ... this is different than the kerberos-change-passwords draft (the original is poorly named, I think). --Ken ========================================================================== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Jul 29 11:49:32 1998 Received: from lists.Stanford.EDU by bitsy.MIT.EDU with SMTP id AA16488; Wed, 29 Jul 98 11:49:32 EDT Received: (from daemon@localhost) by lists.Stanford.EDU (8.8.5/8.7.1) id IAA24590 for ietf-cat-wg-out720680; Wed, 29 Jul 1998 08:02:59 -0700 (PDT) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by lists.Stanford.EDU (8.8.5/8.7.1) with SMTP id IAA24584 for ; Wed, 29 Jul 1998 08:02:53 -0700 (PDT) Received: from copernicus.hpc.org by MIT.EDU with SMTP id AA17657; Wed, 29 Jul 98 11:02:37 EDT Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id LAA16238; Wed, 29 Jul 1998 11:15:46 -0400 (EDT) Received: by earth.hpc.org (SMI-8.6/SMI-SVR4) id KAA20584; Wed, 29 Jul 1998 10:58:46 -0400 Date: Wed, 29 Jul 1998 10:58:46 -0400 From: ho@earth.hpc.org (Hilarie Orman) Message-Id: <199807291458.KAA20584@earth.hpc.org> To: trustmgt@east.isi.edu, ipsec@tis.com, cat-ietf@mit.edu, ietf-ssh@clinet.fi, www-security@ns2.Rutgers.EDU Subject: Trust Management BOF, Chicago, Thursday Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk There will be a BOF on trust management expression and negotiation Thursday afternoon, 3:30. The agenda is still forming, so let me know if you are interested in presenting ideas. The purpose of the BOF is to discuss the need for a working group to develop data representations and protocols that allow entities in different organizations to express and negotiate the conditions under which they will communicate for various network services. The conditions are expected to include security-related mechanisms for authentication and integrity; the representations and protocols for accomplishing the negotiation are themselves security relevant and may be the subject of analysis. The BOF will discuss trust management issues in current and planned protocols and the question of whether or not the policy expression and negotiation are distinct enough from activities in the other groups to warrant the formation of a new WG. ========================================================================== 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