From kitten-bounces@lists.ietf.org Tue Jan 31 10:50:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xld-0003z0-RH; Tue, 31 Jan 2006 10:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xla-0003y3-Qj for kitten@megatron.ietf.org; Tue, 31 Jan 2006 10:50:02 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28215 for ; Tue, 31 Jan 2006 10:48:25 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F3xlZ-0003Ic-U6; Tue, 31 Jan 2006 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 31 Jan 2006 10:50:01 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-rfc2853bis-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Generic Security Service API Version 2 : Java Bindings Update Author(s) : M. Upadhyay, S. Malkani Filename : draft-ietf-kitten-rfc2853bis-01.txt Pages : 102 Date : 2006-1-31 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 updates the Java bindings for the GSS-API that are specified in RFC 2853 [JGSS]. This document obsoletes RFC 2853 [JGSS] by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience. The only note-worthy changes are in sections 4.12.1, 6.3.2, and 6.8.1 of RFC 2853 [JGSS], which are replaced by the sections 5.12.1, 7.3.2, and 7.8.1 of this document, where numerical constants were either added or modified. The GSS-API is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE]. 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-kitten-rfc2853bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-kitten-rfc2853bis-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-kitten-rfc2853bis-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: <2006-1-31101544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-rfc2853bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-rfc2853bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-31101544.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@lists.ietf.org Tue Jan 31 11:26:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yLF-0003DV-Ta; Tue, 31 Jan 2006 11:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yL9-0003Bo-Cm for kitten@megatron.ietf.org; Tue, 31 Jan 2006 11:26:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03397 for ; Tue, 31 Jan 2006 11:25:02 -0500 (EST) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yVy-0001io-V0 for kitten@ietf.org; Tue, 31 Jan 2006 11:37:59 -0500 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 31 Jan 2006 09:26:22 -0700 Message-Id: <43DF2D2E.365D.009A.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Tue, 31 Jan 2006 09:26:06 -0700 From: "Juan Carlos Luciani" To: "Horst Reiterer" References: <43DD65A8.10200@mind-breeze.com> In-Reply-To: <43DD65A8.10200@mind-breeze.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: kitten@ietf.org Subject: Re: GSS-API V2: C# Bindings X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1964150486==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1964150486== Content-Type: multipart/alternative; boundary="=__PartF5D7648E.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartF5D7648E.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Horst, After reading the .NET naming guidelines, I agree with your assessment that the bindings should use Pascal casing for methods, properties as well as constant value names. I also agree that classes that need to provide explicit control to developers for when native resources are released should implement the IDisposable interface to be compatible with the .NET Framework's Dispose pattern. I will update the draft with the naming changes and with the changes to the GSSCredential and GSSContext classes indicating that they implement the IDisposable interface. Please let me know of any other issues that you may see. Thanks you very much for your help, Juan Carlos Luciani >>> Horst Reiterer 01/29/06 6:02 pm >>> Juan Carlos, I am working on integrating Kerberos authentication into a Mono-based application (possibly the Mono Framework implementation itself if I can find the time) so that native Kerberos clients can interoperate with Mono-based services. While starting the implementation, I've come across your GSS-API C# bindings draft: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-bindings-00.txt I'm glad that bindings already exist or are being worked on at the moment. In the introduction, you mentioned that one of the design goals was to emulate the Java bindings specified in RFC 2853 as much as possible while still taking advantage of C# features such as Properties. I fully agree here! I must say however that the bindings IMHO follow the original too closely in some respects. Let me mention two concrete examples: a) byte[] acceptSecContext(byte[] inTok, int offset, int len); Methods, properties as well as constant values (e.g. NO_CONTEXT) violate the .NET Framework coding guidelines as defined by Microsoft (methods properties and constant values should use Pascal casing). For a C# developer, it is very inconvenient to work with a library that does not follow the platform's naming conventions for example. Modifying the bindings to follow the guidelines would IMHO make it's interface significantly more intuitive. Was there a particular reason why you've chosen to follow the Java naming conventions here? References: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp b) void dispose(); In my opinion, this is a very serious issue because this disposal facility simply bypasses the .NET Framework's Dispose pattern and thus does not allow developers to handle objects with native resources accordingly. As a .NET Framework developer, I would expect the following (modified sample taken from the draft) to work: // ... GSSCredential cred = mgr.createCredential(name, GSSCredentialUsage.ACCEPT_ONLY); using (cred) { Oid[] mechs = cred.getMechs(); if (mechs != null) { for (int i = 0; i < mechs.length; i++) Console.WriteLine(mechs[i].ToString()); } } Unfortunately, it can't because the class does not implement IDisposable (unless I missed something). My strong recommendation would be to follow the Dispose pattern in all cases involving native resources so that language / platform facilities (as demonstrated above) can be taken advantage of. References: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cpgenref/html/cpconfinalizedispose.asp Does a reference implementation of the draft (or at least class and interface definitions in source code form) already exist? Please let me know so that I can decide how to proceed in respect to integrating Kerberos. If it doesn't, I would be forced to roll out my own implementation. I'd be more than happy to provide you with further input for the sake of maximizing the value for developers interacting with the GSS-API using C#. Thanks for your time, I highly appreciate your work! Cheers, Horst. --=__PartF5D7648E.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =20

Hi Horst,

After reading the .NET naming guidelines, I agree with your = assessment that the bindings should use Pascal casing for methods, = properties as well as constant value names. I also agree that classes that = need to provide explicit control to developers for when native resources = are released should implement the IDisposable interface to be compatible = with the .NET Framework's Dispose pattern.

I will update the draft with the naming changes and with the = changes to the GSSCredential and GSSContext classes indicating that they = implement the IDisposable interface.

Please let me know of any other issues that you may see.

Thanks you very much for your help,

Juan Carlos Luciani

>>> Horst Reiterer <horst.rei= terer@mind-breeze.com> 01/29/06 6:02 pm >>>
Juan Carlos,=

I am working on integrating Kerberos authentication into a = Mono-based
application (possibly the Mono Framework implementation = itself if I can
find the time) so that native Kerberos clients can = interoperate with
Mono-based services. While starting the implementation= , I've come across
your GSS-API C# bindings draft:

&#= 160;
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp= -bindings-00.txt

I'm glad that bindings already exist or are = being worked on at the
moment. In the introduction, you mentioned = that one of the design goals
"was to emulate the Java bindings = specified in RFC 2853 as much as
possible while still taking advantage = of C# features such as
Properties". I fully agree here! I = must say however that the bindings
IMHO follow the original too closely = in some respects. Let me mention
two concrete examples:

 &nb= sp;a) byte[] acceptSecContext(byte[] inTok,
=             = 60;            =    int offset,
      &#= 160;            = ;         int len);
     Methods, properties as well as = constant values (e.g. NO_CONTEXT)
violate the .NET Framework = coding guidelines as defined by Microsoft
(methods properties and = constant values should use Pascal casing). For a
C# developer= 4; it is very inconvenient to work with a library that does
not follow = the platform's naming conventions for example. Modifying the
binding= s to follow the guidelines would IMHO make it's interface
significan= tly more intuitive.

     Was there a = particular reason why you've chosen to follow the Java
naming = conventions here?

     References:
&= #160;    http://msdn.microsoft.com/library/default.asp&= #63;url=
     /library/en-us/cpgenref/html/= cpconNETFrameworkDesignGuidelines.asp

  b) void = dispose();

     In my = opinion, this is a very serious issue because this disposal
facility= simply bypasses the .NET Framework's Dispose pattern and thus
does = not allow developers to handle objects with native resources
accordingly= . As a .NET Framework developer, I would expect the following
(m= odified sample taken from the draft) to work:

   =   // ...
     GSSCredential cred = = mgr.createCredential(name,
     &= #160;           = 0;          GSSCredential= Usage.ACCEPT_ONLY);

     using = (cred) {
       Oid= [] mechs = cred.getMechs();
   &#= 160;   if (mechs != null) {
= 60;        for (int i = = 0; i < mechs.length; i++)
    = ;       Console.WriteLine(mechs[= i].ToString());
      =  }
     }

  = 60;  Unfortunately, it can't because the class does not = implement
IDisposable (unless I missed something). My strong = recommendation would
be to follow the Dispose pattern in all cases = involving native resources
so that language / platform facilities = (as demonstrated above) can be
taken advantage of.

 =     References:
     http:/= /msdn.microsoft.com/library/default.asp?url=
   &= #160; /library/en-us/cpgenref/html/cpconfinalizedispose.asp

Doe= s a reference implementation of the draft (or at least class and
int= erface definitions in source code form) already exist? Please let = me
know so that I can decide how to proceed in respect to integratingKerberos. If it doesn't, I would be forced to roll out my = own
implementation.

I'd be more than happy to provide you = with further input for the sake of
maximizing the value for developers = interacting with the GSS-API using C#.

Thanks for your = time, I highly appreciate your work!

Cheers,

Hors= t.

--=__PartF5D7648E.0__=-- --===============1964150486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1964150486==--