From kitten-bounces@lists.ietf.org Wed Jun 01 16:28:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZpP-0005P8-9k; Wed, 01 Jun 2005 16:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZpM-0005Nc-Rk for kitten@megatron.ietf.org; Wed, 01 Jun 2005 16:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04760 for ; Wed, 1 Jun 2005 16:28:34 -0400 (EDT) Received: from stratton-three-sixty-nine.mit.edu ([18.187.6.114] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dda9D-00046M-NA for kitten@ietf.org; Wed, 01 Jun 2005 16:49:10 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2A710E0063; Wed, 1 Jun 2005 16:28:25 -0400 (EDT) To: "Blumenthal, Uri" References: <3DEC199BD7489643817ECA151F7C5929012EB35C@pysmsx401.amr.corp.intel.com> <20050523184637.GE27516@binky.Central.Sun.COM> From: Sam Hartman Date: Wed, 01 Jun 2005 16:28:25 -0400 In-Reply-To: <20050523184637.GE27516@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 23 May 2005 13:46:37 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org Subject: Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, May 23, 2005 at 02:13:55PM -0400, Blumenthal, Uri Nicolas> wrote: >> Sounds fine. Do we want to elaborate, like explain that since >> PRF is a PSEUDO-random function, it does have a [usually rather >> long] cycle after which the values start repeating, and we're >> trying to avoid it? Nicolas> I don't care -- as long as we get done with this pair of Nicolas> I-Ds :) Nicolas> Also, I'm not sure that the period is the issue here -- Nicolas> for each call the periodicity issue is handled already in Nicolas> section 2. The issue is that at some point a PRF can Nicolas> start leaking data. I imagine GSS_Pseudo_random() being Nicolas> used to make an XOR encryption pad, for example -- after Nicolas> a while but well before the underlying PRG/PRF's period Nicolas> is reached we may have other weaknesses in it leak Nicolas> information through the pad, parts of which might be Nicolas> recoverable by attackers that know any of the plaintext Nicolas> being encrypted. IANAC, but this seems difficult to Nicolas> explain, particularly in the generic function definition, Nicolas> rather than in the mechanims'. Hmm, I'd consider using a PRF to construct a stream cipher a fine use of a PRF if a bit odd in GSS. I'd certainly expect reasonable crypto to deal appropriately in this case. Nicolas> So I think vague text is the best I can do here, though I Nicolas> welcome suggestions -- I'm sure others can do better than Nicolas> :) I agree vague text is the answer. I'd recommend avoiding specific numbers. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 01 16:30:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZrF-000708-C5; Wed, 01 Jun 2005 16:30:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdZrC-0006z2-UJ for kitten@megatron.ietf.org; Wed, 01 Jun 2005 16:30:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05802 for ; Wed, 1 Jun 2005 16:30:28 -0400 (EDT) Received: from stratton-three-sixty-nine.mit.edu ([18.187.6.114] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdaB5-0004Z1-OI for kitten@ietf.org; Wed, 01 Jun 2005 16:51:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 79339E0063; Wed, 1 Jun 2005 16:30:23 -0400 (EDT) To: Jeffrey Altman References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> From: Sam Hartman Date: Wed, 01 Jun 2005 16:30:23 -0400 In-Reply-To: <429493A6.2040708@columbia.edu> (Jeffrey Altman's message of "Wed, 25 May 2005 11:03:02 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Actually, the question I raised was on the krb5 prf draft Jeffrey> since that is where the current text is located. I would Jeffrey> like a consensus call on the following questions. Jeffrey> (1) Add this text to the security considerations section Jeffrey> of the general prf draft: Jeffrey> Pseudorandom functions by their nature are capable of Jeffrey> producing only limited amounts of cryptographically Jeffrey> secure output. The exact amount of output that one can Jeffrey> safely use, unfortunately varies from one PRF to another Jeffrey> (which prevents us from recommending specific Jeffrey> numbers). Because of this, we recommend that unless you Jeffrey> really know what you are doing (i.e. you are a Jeffrey> cryptographer and are qualified to pass judgement on Jeffrey> cryptographic functions in areas of period, presence of Jeffrey> short cycles, etc), you limit the amount of the PRF Jeffrey> output used to the necessary minimum. I'm willing to live with this text although it's not great. I don't have improvements to offer. The spirit behind the text is fine. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 03 15:55:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIGA-00011k-Iz; Fri, 03 Jun 2005 15:55:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIG6-00010f-PM; Fri, 03 Jun 2005 15:55:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29099; Fri, 3 Jun 2005 15:55:09 -0400 (EDT) Message-Id: <200506031955.PAA29099@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 03 Jun 2005 15:55:08 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gss-naming-02.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 : Desired Enhancements to GSSAPI Naming Author(s) : S. Hartman Filename : draft-ietf-kitten-gss-naming-02.txt Pages : 15 Date : 2005-6-3 The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms such as public-key mechanisms do not have a single name to be used across all environments. Other mechanisms such as Kerberos include may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-02.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-gss-naming-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gss-naming-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-3162833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gss-naming-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gss-naming-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162833.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 Fri Jun 03 17:41:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeJuw-0002HE-6k; Fri, 03 Jun 2005 17:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeJuu-0002H2-4O for kitten@megatron.ietf.org; Fri, 03 Jun 2005 17:41:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16965 for ; Fri, 3 Jun 2005 17:41:19 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeKF9-0002IB-5P for kitten@ietf.org; Fri, 03 Jun 2005 18:02:21 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j53LfEKg001484 for ; Fri, 3 Jun 2005 14:41:18 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j53LfD6v024206 for ; Fri, 3 Jun 2005 15:41:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j53LfDP7002479; Fri, 3 Jun 2005 16:41:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j53LfCp4002478; Fri, 3 Jun 2005 16:41:12 -0500 (CDT) Date: Fri, 3 Jun 2005 16:41:12 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050603214112.GV27456@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 Sam> I'm willing to live with this text although it's not great. I Sam> don't have improvements to offer. The spirit behind the text is Sam> fine. How about pointing out that the lack of useful APIs for inquiring about cryptographic QoPs or specification of policies on the same means that pplications that need to make more than nominal use of GSS_Pseudo_random() should take extra care? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 03 19:15:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLNu-0005it-MJ; Fri, 03 Jun 2005 19:15:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLNt-0005eG-3O for kitten@megatron.ietf.org; Fri, 03 Jun 2005 19:15:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23678 for ; Fri, 3 Jun 2005 19:15:22 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeLiC-0004Hm-97 for kitten@ietf.org; Fri, 03 Jun 2005 19:36:25 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 911DAE0063; Fri, 3 Jun 2005 19:15:23 -0400 (EDT) To: Jeffrey Altman References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> <20050603214112.GV27456@binky.Central.Sun.COM> From: Sam Hartman Date: Fri, 03 Jun 2005 19:15:23 -0400 In-Reply-To: <20050603214112.GV27456@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 3 Jun 2005 16:41:12 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 >>>>> "Nicolas" == Nicolas Williams writes: Sam> I'm willing to live with this text although it's not great. Sam> I don't have improvements to offer. The spirit behind the Sam> text is fine. Nicolas> How about pointing out that the lack of useful APIs for Nicolas> inquiring about cryptographic QoPs or specification of Nicolas> policies on the same means that pplications that need to Nicolas> make more than nominal use of GSS_Pseudo_random() should Nicolas> take extra care? I'd actually like to stay away from discussion of APIs. m I honestly believe that for any mechanism we are likely to standardize and for any use of PRF we are likely to standardize there isn't that big of a concern beyond the key lifetime concern we're already discussing unrealted to PRF. So mentioning APIs as a way to find out whether what you are doing is OK is fine but mentioning APIsas a requirement seems unnecessary. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 03 19:17:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLPx-0006DO-RH; Fri, 03 Jun 2005 19:17:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeLPv-0006DA-2K for kitten@megatron.ietf.org; Fri, 03 Jun 2005 19:17:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23845 for ; Fri, 3 Jun 2005 19:17:28 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeLkE-0004Ki-VU for kitten@ietf.org; Fri, 03 Jun 2005 19:38:31 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j53NHTKg010465 for ; Fri, 3 Jun 2005 16:17:29 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j53NHS04015028 for ; Fri, 3 Jun 2005 17:17:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j53NHRRN002638; Fri, 3 Jun 2005 18:17:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j53NHRaL002637; Fri, 3 Jun 2005 18:17:27 -0500 (CDT) Date: Fri, 3 Jun 2005 18:17:27 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050603231727.GD27456@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> <20050603214112.GV27456@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 On Fri, Jun 03, 2005 at 07:15:23PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Sam> I'm willing to live with this text although it's not great. > Sam> I don't have improvements to offer. The spirit behind the > Sam> text is fine. > > Nicolas> How about pointing out that the lack of useful APIs for > Nicolas> inquiring about cryptographic QoPs or specification of > Nicolas> policies on the same means that pplications that need to > Nicolas> make more than nominal use of GSS_Pseudo_random() should > Nicolas> take extra care? > > > > I'd actually like to stay away from discussion of APIs. m I honestly > believe that for any mechanism we are likely to standardize and for > any use of PRF we are likely to standardize there isn't that big of a > concern beyond the key lifetime concern we're already discussing > unrealted to PRF. > > So mentioning APIs as a way to find out whether what you are doing is > OK is fine but mentioning APIsas a requirement seems unnecessary. Ok, so we should stick with the text you agreed to earlier. I don't know how to improve it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 09 18:20:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgVNw-0004lY-8I; Thu, 09 Jun 2005 18:20:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgVNu-0004lQ-Fw for kitten@megatron.ietf.org; Thu, 09 Jun 2005 18:20:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25449 for ; Thu, 9 Jun 2005 18:20:17 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgVjO-0003Ji-1l for kitten@ietf.org; Thu, 09 Jun 2005 18:42:36 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j59MKGw4025995 for ; Thu, 9 Jun 2005 16:20:16 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j59MKEsU012025 for ; Thu, 9 Jun 2005 16:20:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j59MKC9T000437; Thu, 9 Jun 2005 17:20:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j59MKAI8000436; Thu, 9 Jun 2005 17:20:10 -0500 (CDT) Date: Thu, 9 Jun 2005 17:20:10 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050609222010.GO659@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429493A6.2040708@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 On Wed, May 25, 2005 at 11:03:02AM -0400, Jeffrey Altman wrote: > Actually, the question I raised was on the krb5 prf draft since that is > where the current text is located. I would like a consensus call on the > following questions. What's the consensus? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 10 12:58:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgmqE-0001SV-0Z; Fri, 10 Jun 2005 12:58:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgmqC-0001SQ-4A for kitten@megatron.ietf.org; Fri, 10 Jun 2005 12:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08235 for ; Fri, 10 Jun 2005 12:58:38 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgnBq-0006jp-QP for kitten@ietf.org; Fri, 10 Jun 2005 13:21:08 -0400 Received: from [18.100.0.71] (VPN-SEVENTY-ONE.MIT.EDU [18.100.0.71]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5AGwb9r005919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Jun 2005 12:58:39 -0400 (EDT) Message-ID: <42A9C785.7000704@columbia.edu> Date: Fri, 10 Jun 2005 10:01:57 -0700 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> <20050609222010.GO659@binky.Central.Sun.COM> In-Reply-To: <20050609222010.GO659@binky.Central.Sun.COM> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: kitten@ietf.org Subject: Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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: , Content-Type: multipart/mixed; boundary="===============0705990475==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0705990475== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060006060902080908080403" This is a cryptographically signed message in MIME format. --------------ms060006060902080908080403 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Wed, May 25, 2005 at 11:03:02AM -0400, Jeffrey Altman wrote: > >>Actually, the question I raised was on the krb5 prf draft since that is >>where the current text is located. I would like a consensus call on the >>following questions. > > > What's the consensus? The consensus is that we have text which those who have expressed an opinion are will to swallow but that no one likes. If no one can come up with alternative text by the end of today, I will ask you to submit a new draft with the agreed to text so that we can issue the working group last call. Jeffrey Altman --------------ms060006060902080908080403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjEwMTcwMTU3WjAjBgkqhkiG9w0BCQQxFgQUm1zmZPg0NMO5tUyIxAQffmF5Kl8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAiasNNVUk9cjOzA6yzlS3m1/7XZ92W6/CkjkNzFH6 f0+JBqDkFFbe/xB/3G93tKkUO2hFTb+wapwVNGUfKhJU/AHrzuHmMDyOfqYxRa7Cpg30GkC7 SoOeFdoxgC5g1Rw3pI+Q1CqwaHjGW6RLx6VBNraBveSg7vp+QYTZ7itXY788/s2A+NA+v9UX AMsF3zMVa38AV7f0EAwiSgSBFxdwDGCKU9e0u1qOeGK2THoPCSZclHh/WXcTezB610snYVIi /HsLxD93Dr5MgPqdO9Z6JIGYp8h0L2tXgLY1F2x3/vgeyJe22pZ+lemiJ/VptDrtVCaq8hqH AymWu1mfLqmkMgAAAAAAAA== --------------ms060006060902080908080403-- --===============0705990475== 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 --===============0705990475==-- From kitten-bounces@lists.ietf.org Mon Jun 13 18:01:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhx0F-0002yY-Hk; Mon, 13 Jun 2005 18:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhx0E-0002y3-DY for kitten@megatron.ietf.org; Mon, 13 Jun 2005 18:01:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10931 for ; Mon, 13 Jun 2005 18:01:51 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhxMa-0000GR-Mk for kitten@ietf.org; Mon, 13 Jun 2005 18:25:01 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5DM1qKg014362 for ; Mon, 13 Jun 2005 15:01:52 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5DM1m3Z011813 for ; Mon, 13 Jun 2005 16:01:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5DM1ja7006279; Mon, 13 Jun 2005 17:01:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5DM1jjo006278; Mon, 13 Jun 2005 17:01:45 -0500 (CDT) Date: Mon, 13 Jun 2005 17:01:45 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050613220145.GB6266@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <7210B31550AC934A8637D6619739CE690534F6FB@e2k-sea-xch2.sea-alpha.cisco.com> <429493A6.2040708@columbia.edu> <20050609222010.GO659@binky.Central.Sun.COM> <42A9C785.7000704@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A9C785.7000704@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Updated I-Ds submitted, pls begin WGLC (Re: Consensus call was Re: Comments on draft-ietf-kitten-krb5-gssapi-prf-03.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 On Fri, Jun 10, 2005 at 10:01:57AM -0700, Jeffrey Altman wrote: > Nicolas Williams wrote: > > > On Wed, May 25, 2005 at 11:03:02AM -0400, Jeffrey Altman wrote: > > > >>Actually, the question I raised was on the krb5 prf draft since that is > >>where the current text is located. I would like a consensus call on the > >>following questions. > > > > > > What's the consensus? > > The consensus is that we have text which those who have expressed an > opinion are will to swallow but that no one likes. > > If no one can come up with alternative text by the end of today, I will > ask you to submit a new draft with the agreed to text so that we can > issue the working group last call. I've updated the I-Ds accordingly, and only as proposed, and submitted new (-04) versions. Please begin WGLC at your earliest convenience. Thanks, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jun 14 16:02:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHbz-000711-J7; Tue, 14 Jun 2005 16:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHbv-00070E-5G; Tue, 14 Jun 2005 16:02:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25640; Tue, 14 Jun 2005 16:02:09 -0400 (EDT) Message-Id: <200506142002.QAA25640@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 14 Jun 2005 16:02:09 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-prf-04.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 : A PRF API extension for the GSS-API Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-prf-04.txt Pages : 9 Date : 2005-6-14 This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per- message MIC (message integrity check) and wrap tokens for session protection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-04.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-gssapi-prf-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-14163641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-prf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-14163641.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 Jun 14 16:02:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHc8-00072d-QL; Tue, 14 Jun 2005 16:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHc4-00071Z-BY; Tue, 14 Jun 2005 16:02:20 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25647; Tue, 14 Jun 2005 16:02:18 -0400 (EDT) Message-Id: <200506142002.QAA25647@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 14 Jun 2005 16:02:18 -0400 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-krb5-gssapi-prf-04.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 : A PRF for the Kerberos V GSS-API Mechanism Author(s) : N. Williams Filename : draft-ietf-kitten-krb5-gssapi-prf-04.txt Pages : 6 Date : 2005-6-14 This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Programming Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.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-krb5-gssapi-prf-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-14163648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-krb5-gssapi-prf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-14163648.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 Jun 14 17:21:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIqS-00086w-UP; Tue, 14 Jun 2005 17:21:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIqR-00086o-Ih for kitten@megatron.ietf.org; Tue, 14 Jun 2005 17:21:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07162 for ; Tue, 14 Jun 2005 17:21:13 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiJCz-00031V-Gl for kitten@ietf.org; Tue, 14 Jun 2005 17:44:34 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5ELLC2v020623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2005 17:21:12 -0400 (EDT) Message-ID: <42AF4B19.5040202@columbia.edu> Date: Tue, 14 Jun 2005 17:24:41 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten , Kerberos WG X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: WGLC: Kitten PRF drafts 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="===============1749156888==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1749156888== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020507020505070603060907" This is a cryptographically signed message in MIME format. --------------ms020507020505070603060907 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A two week working group last call is issued for the following Kitten Working Group internet drafts: Title : A PRF API extension for the GSS-API Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-prf-04.txt Pages : 9 Date : 2005-6-14 This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per- message MIC (message integrity check) and wrap tokens for session protection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-04.txt Title : A PRF for the Kerberos V GSS-API Mechanism Author(s) : N. Williams Filename : draft-ietf-kitten-krb5-gssapi-prf-04.txt Pages : 6 Date : 2005-6-14 This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Programming Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.txt --------------ms020507020505070603060907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjE0MjEyNDQxWjAjBgkqhkiG9w0BCQQxFgQUvHmDi4CeFCYNCuHfYNE3hctxdI8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAR1Zfh40/165Yu/7ur3HLxi4YS6GPQTVlG+7hgbDe tbGsWthW60yEiLxMZ/TP3W3ri5rxGh2pmbd936LsRzGLqRKcwAo6jVzxNtDPw4v4QpD9OyNi sd6cLXafootYXISg1VxdKFfp9iZLo3xFt7K3bUsZn4wWWkWu1cEoqOWjWYfK2gq+NdslmqTd DgxB4MpvW2BiISTBAMhFIKx+cV742elsQaNnA3byulb1Zp7zb3Ynlz/jxPhDLVJ/JBW2wRTL /6D4xyfKWSbDKCe/4ooMYG7K95hJQGYQJZBgwDNMERT2X4VQG9R3C/s7EiknkWnoHoMrzYNr lBaiS7VOBSRl1QAAAAAAAA== --------------ms020507020505070603060907-- --===============1749156888== 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 --===============1749156888==-- From kitten-bounces@lists.ietf.org Thu Jun 23 14:04:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlW3v-0002TM-P2; Thu, 23 Jun 2005 14:04:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlW3s-0002Sj-JW for kitten@megatron.ietf.org; Thu, 23 Jun 2005 14:04:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10975 for ; Thu, 23 Jun 2005 14:04:23 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlWSE-0001Kn-Jh for kitten@ietf.org; Thu, 23 Jun 2005 14:29:36 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2005 11:04:11 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5NI48VX015656; Thu, 23 Jun 2005 11:04:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2005 11:08:22 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905668FD9@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: SECMECH list announcement Thread-Index: AcV4HfKjfilgW2qqTWu/fGuVNvxdbw== From: "Salowey, Joe" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: Subject: SECMECH list announcement 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 This is a brief note to announce a the creation of a mailing list for discussing security mechanisms. The current scope is security mechanisms for the GSS-API, EAP and SASL frameworks. There will most likely be a BOF on this topic at IETF 63. Please join the mailing list if you have interest in this topic. =20 General Discussion: secmech@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/secmech Archive: http://www.ietf.org/mail-archive/web/secmech/index.html Description ------------------- There exists a disconnect between the IETF's security frameworks. Although these frameworks have very similar goals, the set of mechanisms available depends upon the choice of framework. There are a number of issues that make a compelling case for converging the way we develop mechanisms for these frameworks. =20 - There is a desire to standardized EAP mechanisms and there currently is no working group with this on its charter. It would be desirable to work on this in conjunction with other efforts in the security area including work on GSS-API enhancements in KITTEN working group and SASL enhancements in the SASL working group. - The actual mechanisms in each of these frameworks have very similar goals of authentication and establishing a cryptographic context. In many cases frameworks are developing new functionality that bring them closer together. An example of this is the addition of a PRF API to access key material from GSS-API.=20 - There is pressure to adopt a particular framework because of the set of mechanisms available not because of the capabilities and upper-layer interface of the framework. This recently was an issue with ISMS, but there has also been a desire to use EAP to authenticate other applications. We should be in a situation where the choice on mechanism was dictated by the deployment requirements and the choice of framework dictated by protocol design and implementation simplicity. =20 - There is a duplication of effort in the development of security mechanism that support similar credential types and infrastructures. This is problematic because the development of security mechanisms is both difficult and time consuming. It would be good to leverage the work and expertise required for developing a mechanism across all the frameworks. - Often the cost of deploying a security mechanism is in the infrastructure and not the implementation of the mechanism itself. There limited set of mechanisms available to particular frameworks makes the coordination and administration of security between applications that use different frameworks more difficult.=20 The first tasks of a SECMECH working group would be to document a set of evaluation criteria/guidelines explaining what standards-track security mechanisms need to do and how we will evaluate them and to document how we're going to go about specifying a security mechanism for use in the frameworks that are in scope. The working group would also be chartered to define a set of standards track mechanisms. The mechanism work would complete after the first two tasks have completed.=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 16:54:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYik-0006pI-VF; Thu, 23 Jun 2005 16:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYiZ-0006l5-5R for kitten@megatron.ietf.org; Thu, 23 Jun 2005 16:54:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00714 for ; Thu, 23 Jun 2005 16:54:30 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlYtZ-0003sV-EO for kitten@ietf.org; Thu, 23 Jun 2005 17:05:58 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j5NKef2b001665; Thu, 23 Jun 2005 16:40:42 -0400 (EDT) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) (authenticated bits=56) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j5NKeZFp012482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2005 16:40:35 -0400 (EDT) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.12.9) id j5NKeYxl017324; Thu, 23 Jun 2005 16:40:34 -0400 To: kitten@ietf.org From: Ken Raeburn Date: Thu, 23 Jun 2005 16:40:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.041 X-Spam-Level: * (1.041) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: PRF comments 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 Going over the -04 drafts today, I was struck by a few things: draft-ietf-kitten-gssapi-prf-04.txt: Mechanisms MUST be able to consume all the provided prf_in input data that is 2^14 or fewer octets. If a mechanism cannot consume as much input data as provided by the caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE. We should probably add explicitly: "Mechanism PRF specifications may not truncate the supplied input data." If the implementation cannot produce the desired output due to lack of resources then it MUST output what it can and still return GSS_S_COMPLETE. This makes "mechanism spec said to output only X bytes" indistinguishable from "out of resources". If the output is being used as protocol keying material or something comparable, then the exchange may eventually fail because one side generated less data than the other. I'd suggest either this should fail, or return some magic error code that means "truncated output" and we provide some way to resume where it left off. (Probably the former, though that may mean that small-memory systems simply cannot satisfy some requests.) In fact, it's probably worth explicitly stating that the mechanism definitions must indicate what the only correct output length is, for a given input. Additional major status codes for the C-bindings: o GSS_S_CALL_INACCESSIBLE_READ o GSS_S_CALL_INACCESSIBLE_WRITE See [RFC2744]. These status codes are very poorly described in RFC 2744, and are not explicitly noted as status returns for any functions in RFC 2744, so I don't think they need to be called out specially here. And why would they be "additional" major status codes? I'm not sure when they could come up, anyways, unless you're checking memory mappings for validity of the supplied pointers. It looks like the MIT code never returns them. For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf': I'm not familiar with Java interface definitions. Is it considered okay to simply add a new method to a standardized interface? Add a comma after "Java". Callers of GSS_Pseudo_random() should avoid accidentally calling it with the same inputs. "... for different purposes [or uses]." There are certainly cases where you'd want different calls to use the same inputs, and not by accident. presence of short cycles, etc), you limit the amount of the PRF output used to the necessary minimum. I think "minimum necessary" sounds better. "Necessary minimum" sounds to me like it is necessary that a minimum exists, whereas we want the minimum amount of output that is necessary. (I.e., "minimum" and "necessary" modify "amount"; "necessary" doesn't modify "minimum".) draft-ietf-kitten-krb5-gssapi-prf-04.txt: Section 2, move [RFC3961] up to the first paragraph where the PRF function is first mentioned. Should the [RFC1964] reference be updated to CFX? The computational cost of computing this PRF+ may vary depending on the Kerberos V encryption types being used, but generally the computation of this PRF+ gets more expensive as the input and output [...] With some rewording ("a mechanism that uses a PRF+ construction...", or just "for many PRF constructions..."), this would be appropriate for draft-ietf-kitten-gssapi-prf instead. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 17:12:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlZ07-0002zS-VS; Thu, 23 Jun 2005 17:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlZ05-0002zH-V1 for kitten@megatron.ietf.org; Thu, 23 Jun 2005 17:12:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02903 for ; Thu, 23 Jun 2005 17:12:39 -0400 (EDT) Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlZOT-0005sA-Mv for kitten@ietf.org; Thu, 23 Jun 2005 17:37:55 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA11158; Thu, 23 Jun 2005 23:12:03 +0200 (MESZ) From: Martin Rex Message-Id: <200506232112.XAA25862@uw1048.wdf.sap.corp> To: raeburn@MIT.EDU (Ken Raeburn) Date: Thu, 23 Jun 2005 23:12:03 +0200 (MET DST) In-Reply-To: from "Ken Raeburn" at Jun 23, 5 04:40:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: PRF comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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 Ken Raeburn wrote: > > Additional major status codes for the C-bindings: > > o GSS_S_CALL_INACCESSIBLE_READ > > o GSS_S_CALL_INACCESSIBLE_WRITE > > See [RFC2744]. > > These status codes are very poorly described in RFC 2744, and are not > explicitly noted as status returns for any functions in RFC 2744, so I > don't think they need to be called out specially here. And why would > they be "additional" major status codes? > > I'm not sure when they could come up, anyways, unless you're checking > memory mappings for validity of the supplied pointers. It looks like > the MIT code never returns them. RFC-2743 originally mentioned that some gssapi mechanisms may be part of a TCB, and there you would certainly expect pointers to be tested against valid/mapped memory address ranges before they're accessed/dereferenced in order not to cause an exception within the TCB or scribbling over normally protected memory, i.e. where gss_buffer_t is used as an input parameter (affecting both, the base pointer and the value pointer), or where gss_buffer_t is used as an output parameter (here only the the base structure pointer is interesting, because the value will be allocated by the gssapi mechanism). The much more common gssapi mechanisms--as an application library living entirely in the application's process space is unlikely to test for more than !=NULL (if at all), I expect. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 17:17:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlZ4g-0003Vh-Tb; Thu, 23 Jun 2005 17:17:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlZ4f-0003VO-JC for kitten@megatron.ietf.org; Thu, 23 Jun 2005 17:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03569 for ; Thu, 23 Jun 2005 17:17:23 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlZT1-0006Cf-14 for kitten@ietf.org; Thu, 23 Jun 2005 17:42:38 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5NLHJKg021450 for ; Thu, 23 Jun 2005 14:17:19 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5NLHJfb002298 for ; Thu, 23 Jun 2005 15:17:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5NLHI3Q009646; Thu, 23 Jun 2005 16:17:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5NLHIWN009645; Thu, 23 Jun 2005 16:17:18 -0500 (CDT) Date: Thu, 23 Jun 2005 16:17:18 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050623211717.GT16670@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org, Seema Malkani References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Thu, Jun 23, 2005 at 04:40:34PM -0400, Ken Raeburn wrote: > Going over the -04 drafts today, I was struck by a few things: > > draft-ietf-kitten-gssapi-prf-04.txt: > > Mechanisms MUST be able to consume all the provided prf_in input data > that is 2^14 or fewer octets. > > If a mechanism cannot consume as much input data as provided by the > caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE. > > We should probably add explicitly: "Mechanism PRF specifications may > not truncate the supplied input data." I thought that "[m]echanisms MUST be able to consume all the provided prf_in..." meant exactly that. How could it mean otherwise? > If the implementation cannot produce the desired output due to lack > of resources then it MUST output what it can and still return > GSS_S_COMPLETE. > > This makes "mechanism spec said to output only X bytes" > indistinguishable from "out of resources". If the output is being Ah. > used as protocol keying material or something comparable, then the > exchange may eventually fail because one side generated less data than > the other. > > I'd suggest either this should fail, or return some magic error code > that means "truncated output" and we provide some way to resume where > it left off. (Probably the former, though that may mean that > small-memory systems simply cannot satisfy some requests.) We have GSS_S_UNAVAILABLE. So return that and still output prf_out. > In fact, it's probably worth explicitly stating that the mechanism > definitions must indicate what the only correct output length is, for > a given input. How would they? > Additional major status codes for the C-bindings: > > o GSS_S_CALL_INACCESSIBLE_READ > > o GSS_S_CALL_INACCESSIBLE_WRITE > > See [RFC2744]. > > These status codes are very poorly described in RFC 2744, and are not > explicitly noted as status returns for any functions in RFC 2744, so I > don't think they need to be called out specially here. And why would > they be "additional" major status codes? RFC2743 doesn't define them -- they are an artifact of the C bindings, needed to indicate calling errors where the caller passed in a NULL pointer where a non-NULL pointer to a basic GSS type variable was needed. > I'm not sure when they could come up, anyways, unless you're checking > memory mappings for validity of the supplied pointers. It looks like > the MIT code never returns them. See above. Solaris' libgss returns those errors as described above. > For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf': > > I'm not familiar with Java interface definitions. Is it considered > okay to simply add a new method to a standardized interface? Seema, can you look at this? > Add a comma after "Java". > > Callers of GSS_Pseudo_random() should avoid accidentally calling it > with the same inputs. > > "... for different purposes [or uses]." There are certainly cases > where you'd want different calls to use the same inputs, and not by > accident. Right, but since those wouldn't be accidents I think no change is needed. > presence of short cycles, etc), you limit the amount of the PRF > output used to the necessary minimum. > > I think "minimum necessary" sounds better. "Necessary minimum" sounds > to me like it is necessary that a minimum exists, whereas we want the > minimum amount of output that is necessary. (I.e., "minimum" and > "necessary" modify "amount"; "necessary" doesn't modify "minimum".) Sure. > > draft-ietf-kitten-krb5-gssapi-prf-04.txt: > > Section 2, move [RFC3961] up to the first paragraph where the PRF > function is first mentioned. Should the [RFC1964] reference be > updated to CFX? Er, yes, now that CFX is at Proposed Standard. > The computational cost of computing this PRF+ may vary depending on > the Kerberos V encryption types being used, but generally the > computation of this PRF+ gets more expensive as the input and output > [...] > > With some rewording ("a mechanism that uses a PRF+ construction...", > or just "for many PRF constructions..."), this would be appropriate > for draft-ietf-kitten-gssapi-prf instead. Well, I suppose. If one mechanism may have a PRF that gets slower the longer the inputs and required outputs then so may others, and that's worth warning about, so: For some mechanisms the computational cost of computing GSS_Pseudo_random() may increase exponentially as the length of the prf_in data and/or the desired_output_length increase. This means that if an application can be tricked into providing very large input octet strings and requesting very long output octet strings then that may constitute a denial of service attack on the application; therefore applications SHOULD place appropriate limits on the size of any input octet strings received from their peers without integrity protection. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 21:42:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DldCw-000248-3U; Thu, 23 Jun 2005 21:42:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DldCu-000243-75 for kitten@megatron.ietf.org; Thu, 23 Jun 2005 21:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24574 for ; Thu, 23 Jun 2005 21:42:10 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DldbL-0001nU-3L for kitten@ietf.org; Thu, 23 Jun 2005 22:07:27 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j5O1g73R028576; Thu, 23 Jun 2005 21:42:07 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j5O1g07A024601 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 23 Jun 2005 21:42:01 -0400 (EDT) In-Reply-To: <20050623211717.GT16670@binky.Central.Sun.COM> References: <20050623211717.GT16670@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74368cfa4c7b89bc59759af531f38503@mit.edu> From: Ken Raeburn Date: Thu, 23 Jun 2005 21:41:57 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.622) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Jun 23, 2005, at 17:17, Nicolas Williams wrote: > On Thu, Jun 23, 2005 at 04:40:34PM -0400, Ken Raeburn wrote: >> We should probably add explicitly: "Mechanism PRF specifications may >> not truncate the supplied input data." > > I thought that "[m]echanisms MUST be able to consume all the provided > prf_in..." meant exactly that. > > How could it mean otherwise? Can a mechanism define "consume" as "discard/ignore everything after X bytes"? I guess that's what I'm getting at. I don't think it should be allowed to. > We have GSS_S_UNAVAILABLE. So return that and still output prf_out. "The operation or option is unavailable", when it's a size problem (presumably, unable to allocate)? Doesn't sound like a great match, but I'm not sure what else to suggest. And it seems to me like this is only useful if the application protocol specifies up-front generation of more pseudorandom data than may be needed, "just in case", and the application will only succeed if the excess data is in fact not needed. >> In fact, it's probably worth explicitly stating that the mechanism >> definitions must indicate what the only correct output length is, for >> a given input. > > How would they? Well, indirectly, I guess, by way of specifying what the complete, deterministic output should be. I.e., if the implementation's output is the wrong length, then it's wrong. > RFC2743 doesn't define them -- they are an artifact of the C bindings, > needed to indicate calling errors where the caller passed in a NULL > pointer where a non-NULL pointer to a basic GSS type variable was > needed. Right, but I don't think we need to call them out explicitly here; the generic codes that apply to the rest of the C bindings should be understood to apply here, just as the type definitions do. > See above. Solaris' libgss returns those errors as described above. Makes sense. As does Martin's point about TCB implementations. Thanks. >> "... for different purposes [or uses]." There are certainly cases >> where you'd want different calls to use the same inputs, and not by >> accident. > > Right, but since those wouldn't be accidents I think no change is > needed. Just trying to make it very clear... :-) > Well, I suppose. If one mechanism may have a PRF that gets slower the > longer the inputs and required outputs then so may others, and that's > worth warning about, so: > > For some mechanisms the computational cost of computing > GSS_Pseudo_random() may increase exponentially as the length of the Exponentially would surprise me, but I could certainly see O(inlen*outlen) behavior being common. Maybe "significantly"... otherwise, it looks good. One more thing I just noticed in looking at RFC 2744: The minor_status output is defined as being mechanism-specific or implementation-specific, on a function by function basis. So this draft should do likewise. Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 23:09:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DleZA-0007cw-04; Thu, 23 Jun 2005 23:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DleZ7-0007cr-El for kitten@megatron.ietf.org; Thu, 23 Jun 2005 23:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00675 for ; Thu, 23 Jun 2005 23:09:06 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlexQ-0005l7-W5 for kitten@ietf.org; Thu, 23 Jun 2005 23:34:25 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5O391qg021895 for ; Thu, 23 Jun 2005 21:09:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5O390fb012489 for ; Thu, 23 Jun 2005 21:09:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5O3900Z009925; Thu, 23 Jun 2005 22:09:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5O38uW1009924; Thu, 23 Jun 2005 22:08:56 -0500 (CDT) Date: Thu, 23 Jun 2005 22:08:56 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050624030856.GX16670@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org, Seema Malkani References: <20050623211717.GT16670@binky.Central.Sun.COM> <74368cfa4c7b89bc59759af531f38503@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74368cfa4c7b89bc59759af531f38503@mit.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Thu, Jun 23, 2005 at 09:41:57PM -0400, Ken Raeburn wrote: > On Jun 23, 2005, at 17:17, Nicolas Williams wrote: > >On Thu, Jun 23, 2005 at 04:40:34PM -0400, Ken Raeburn wrote: > >>We should probably add explicitly: "Mechanism PRF specifications may > >>not truncate the supplied input data." > > > >I thought that "[m]echanisms MUST be able to consume all the provided > >prf_in..." meant exactly that. > > > >How could it mean otherwise? > > Can a mechanism define "consume" as "discard/ignore everything after X > bytes"? I guess that's what I'm getting at. I don't think it should > be allowed to. I see no other interpretation than it should use all the input octets to compute the PRF. That said, you're welcome to propose better language. > >We have GSS_S_UNAVAILABLE. So return that and still output prf_out. > > "The operation or option is unavailable", when it's a size problem > (presumably, unable to allocate)? Doesn't sound like a great match, > but I'm not sure what else to suggest. > > And it seems to me like this is only useful if the application protocol > specifies up-front generation of more pseudorandom data than may be > needed, "just in case", and the application will only succeed if the > excess data is in fact not needed. Er, hmmm. Perhaps it's best to say that the PRF has to output as much as requested or fail altogether. I see no harm in that. > >>In fact, it's probably worth explicitly stating that the mechanism > >>definitions must indicate what the only correct output length is, for > >>a given input. > > > >How would they? > > Well, indirectly, I guess, by way of specifying what the complete, > deterministic output should be. I.e., if the implementation's output > is the wrong length, then it's wrong. BTW, there's not supposed to be a correlation between input and output sizes -- both are in the application's control. > >RFC2743 doesn't define them -- they are an artifact of the C bindings, > >needed to indicate calling errors where the caller passed in a NULL > >pointer where a non-NULL pointer to a basic GSS type variable was > >needed. > > Right, but I don't think we need to call them out explicitly here; the > generic codes that apply to the rest of the C bindings should be > understood to apply here, just as the type definitions do. Ah, got it. I'm just as happy leaving the C-bindings calling errors out as in. > >See above. Solaris' libgss returns those errors as described above. > > Makes sense. As does Martin's point about TCB implementations. Thanks. NP. > >>"... for different purposes [or uses]." There are certainly cases > >>where you'd want different calls to use the same inputs, and not by > >>accident. > > > >Right, but since those wouldn't be accidents I think no change is > >needed. > > Just trying to make it very clear... :-) I somehow doubt folks are going to be getting this wrong. The text seems clear to me, but, again, I don't oppose clarification if the WG thinks it's needed. > >Well, I suppose. If one mechanism may have a PRF that gets slower the > >longer the inputs and required outputs then so may others, and that's > >worth warning about, so: > > > > For some mechanisms the computational cost of computing > > GSS_Pseudo_random() may increase exponentially as the length of the > > Exponentially would surprise me, but I could certainly see > O(inlen*outlen) behavior being common. Maybe "significantly"... > otherwise, it looks good. Ok, "significantly" then. > One more thing I just noticed in looking at RFC 2744: The minor_status > output is defined as being mechanism-specific or > implementation-specific, on a function by function basis. So this > draft should do likewise. Well, RFC2743 does that, and it's a normative reference; you have to read the base specs to figure out how to display major and minor status codes anyways. And the text in draft-ietf-kitten-gssapi-prf-04 kinda mentions it already: o GSS_S_FAILURE indicates general failure, possibly due to the given input data being too large or of zero length, or due to the desired_output_len being zero; the minor status code may provide additional information. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 23:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlexU-00039W-71; Thu, 23 Jun 2005 23:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlexS-00039R-Td for kitten@megatron.ietf.org; Thu, 23 Jun 2005 23:34:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02343 for ; Thu, 23 Jun 2005 23:34:20 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfLt-0006vP-G4 for kitten@ietf.org; Thu, 23 Jun 2005 23:59:39 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j5O3YHVr018816; Thu, 23 Jun 2005 23:34:17 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j5O3Y5o7005370 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 23 Jun 2005 23:34:11 -0400 (EDT) In-Reply-To: <20050624030856.GX16670@binky.Central.Sun.COM> References: <20050623211717.GT16670@binky.Central.Sun.COM> <74368cfa4c7b89bc59759af531f38503@mit.edu> <20050624030856.GX16670@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> From: Ken Raeburn Date: Thu, 23 Jun 2005 23:34:02 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.622) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Jun 23, 2005, at 23:08, Nicolas Williams wrote: >> Can a mechanism define "consume" as "discard/ignore everything after X >> bytes"? I guess that's what I'm getting at. I don't think it should >> be allowed to. > > I see no other interpretation than it should use all the input octets > to > compute the PRF. That said, you're welcome to propose better language. I'll think on it... >> Well, indirectly, I guess, by way of specifying what the complete, >> deterministic output should be. I.e., if the implementation's output >> is the wrong length, then it's wrong. > > BTW, there's not supposed to be a correlation between input and output > sizes -- both are in the application's control. Sure. I guess I'm not expressing myself well today... :-( >> One more thing I just noticed in looking at RFC 2744: The >> minor_status >> output is defined as being mechanism-specific or >> implementation-specific, on a function by function basis. So this >> draft should do likewise. > > Well, RFC2743 does that, and it's a normative reference; you have to > read the base specs to figure out how to display major and minor status > codes anyways. And the text in draft-ietf-kitten-gssapi-prf-04 kinda > mentions it already: > > o GSS_S_FAILURE indicates general failure, possibly due to the > given > input data being too large or of zero length, or due to the > desired_output_len being zero; the minor status code may provide > additional information. In the descriptions of individual functions in RFC 2744, minor_status described as one or the other -- either it's mechanism-specific for this function, or it's implementation-specific. For GSS_Pseudo_random, which one is it? That aspect of RFC 2744 bothers me, actually. Seems to me that it implies that mechanism-specific and implementation-specific minor status codes would have to partition the number space or risk duplicating values. Maybe it's just a bug in the RFC and it should've been mechanism-specific always? Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 23 23:44:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlf7E-0005m0-4H; Thu, 23 Jun 2005 23:44:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlf7C-0005lo-Oz for kitten@megatron.ietf.org; Thu, 23 Jun 2005 23:44:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04101 for ; Thu, 23 Jun 2005 23:44:24 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfVd-0007q2-R6 for kitten@ietf.org; Fri, 24 Jun 2005 00:09:43 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5O3iNFF013897 for ; Thu, 23 Jun 2005 20:44:23 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5O3iMfb024781 for ; Thu, 23 Jun 2005 21:44:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5O3iMsb009968; Thu, 23 Jun 2005 22:44:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5O3iLE5009967; Thu, 23 Jun 2005 22:44:21 -0500 (CDT) Date: Thu, 23 Jun 2005 22:44:21 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050624034421.GC16670@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org, Seema Malkani References: <20050623211717.GT16670@binky.Central.Sun.COM> <74368cfa4c7b89bc59759af531f38503@mit.edu> <20050624030856.GX16670@binky.Central.Sun.COM> <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Thu, Jun 23, 2005 at 11:34:02PM -0400, Ken Raeburn wrote: > >Well, RFC2743 does that, and it's a normative reference; you have to > >read the base specs to figure out how to display major and minor status > >codes anyways. And the text in draft-ietf-kitten-gssapi-prf-04 kinda > >mentions it already: > > > > o GSS_S_FAILURE indicates general failure, possibly due to the > >given > > input data being too large or of zero length, or due to the > > desired_output_len being zero; the minor status code may provide > > additional information. > > In the descriptions of individual functions in RFC 2744, minor_status > described as one or the other -- either it's mechanism-specific for > this function, or it's implementation-specific. For GSS_Pseudo_random, > which one is it? Grrr. RFC2744 says this about it in the description of gss_create_empty_oid_set() minor_status Integer, modify Mechanism specific status code Clearly a mistake -- there's NO MECHANISM INVOLVED in creating an empty OID set, at least not in a multi-mechanism implementation. The problem here is not RFC2744's fault, but 2743's. There are GSS functions that don't obviously involve a mechanism but which nonetheless output a minor_status, and it's not at all clear how to display them, because GSS_C_NULL_OID is allowed to mean the default mechanism! Which is why I'd like to introduce an OID for the multi-mechglue itself -- just so it can be used in calls to gss_display_status(). But, look, I refuse :) to have to deal with this problem in this I-D -- it's quite clear that GSS_Pseudo_random() involves a mechanism, so the minor_status code must, implicitly, be a mechanism-specific code, and, anyways, the app can currently do nothing more than call gss_display_status() with the actual mechanism of the context in order to display it. > That aspect of RFC 2744 bothers me, actually. Seems to me that it > implies that mechanism-specific and implementation-specific minor > status codes would have to partition the number space or risk > duplicating values. Maybe it's just a bug in the RFC and it should've > been mechanism-specific always? See above. It's a bug in the RFC. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 00:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfTB-0003HL-6R; Fri, 24 Jun 2005 00:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlfT9-0003HG-OL for kitten@megatron.ietf.org; Fri, 24 Jun 2005 00:07:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07562 for ; Fri, 24 Jun 2005 00:07:05 -0400 (EDT) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlfrb-00015T-Dx for kitten@ietf.org; Fri, 24 Jun 2005 00:32:24 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id j5O474Vr002472; Fri, 24 Jun 2005 00:07:04 -0400 (EDT) Received: from [18.101.0.226] ([18.101.0.226]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id j5O46vNY007970 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 24 Jun 2005 00:06:58 -0400 (EDT) In-Reply-To: <20050624034421.GC16670@binky.Central.Sun.COM> References: <20050623211717.GT16670@binky.Central.Sun.COM> <74368cfa4c7b89bc59759af531f38503@mit.edu> <20050624030856.GX16670@binky.Central.Sun.COM> <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> <20050624034421.GC16670@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5bc7334435f9c0e2889c7829b1d40beb@mit.edu> From: Ken Raeburn Date: Fri, 24 Jun 2005 00:06:57 -0400 To: Nicolas Williams X-Mailer: Apple Mail (2.622) X-Spam-Score: -2.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Jun 23, 2005, at 23:44, Nicolas Williams wrote: > But, look, I refuse :) to have to deal with this problem in this I-D -- > it's quite clear that GSS_Pseudo_random() involves a mechanism, so the > minor_status code must, implicitly, be a mechanism-specific code, and, > anyways, the app can currently do nothing more than call > gss_display_status() with the actual mechanism of the context in order > to display it. Ah, but just as clearly, a call from C code to gss_pseudo_random() involves an implementation. :-) > See above. It's a bug in the RFC. Okay, I can believe that... Ken _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 11:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqSj-0002ni-8S; Fri, 24 Jun 2005 11:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlqSh-0002nd-Eb for kitten@megatron.ietf.org; Fri, 24 Jun 2005 11:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19126 for ; Fri, 24 Jun 2005 11:51:18 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlqrA-0006wN-Le for kitten@ietf.org; Fri, 24 Jun 2005 12:16:44 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5OFpEw4028786 for ; Fri, 24 Jun 2005 09:51:14 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5OFpEfb016355 for ; Fri, 24 Jun 2005 09:51:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5OFnPxQ010149; Fri, 24 Jun 2005 10:49:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5OFnOhT010148; Fri, 24 Jun 2005 10:49:24 -0500 (CDT) Date: Fri, 24 Jun 2005 10:49:24 -0500 From: Nicolas Williams To: Ken Raeburn Message-ID: <20050624154924.GF16670@binky.Central.Sun.COM> Mail-Followup-To: Ken Raeburn , kitten@ietf.org, Seema Malkani References: <20050623211717.GT16670@binky.Central.Sun.COM> <74368cfa4c7b89bc59759af531f38503@mit.edu> <20050624030856.GX16670@binky.Central.Sun.COM> <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> <20050624034421.GC16670@binky.Central.Sun.COM> <5bc7334435f9c0e2889c7829b1d40beb@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bc7334435f9c0e2889c7829b1d40beb@mit.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, Seema Malkani Subject: Re: PRF comments 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 On Fri, Jun 24, 2005 at 12:06:57AM -0400, Ken Raeburn wrote: > On Jun 23, 2005, at 23:44, Nicolas Williams wrote: > >But, look, I refuse :) to have to deal with this problem in this I-D -- > >it's quite clear that GSS_Pseudo_random() involves a mechanism, so the > >minor_status code must, implicitly, be a mechanism-specific code, and, > >anyways, the app can currently do nothing more than call > >gss_display_status() with the actual mechanism of the context in order > >to display it. > > Ah, but just as clearly, a call from C code to gss_pseudo_random() > involves an implementation. :-) Yeah, in general, a pluggable multi-mech implementation will have to reserve a chunk of the minor_status namespace in order to be able to distinguish between implementation and mechanism minor status codes in the cases of functions like this one that involve both. > >See above. It's a bug in the RFC. > > Okay, I can believe that... Heh. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 19:55:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dly1Y-0006UP-LE; Fri, 24 Jun 2005 19:55:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dly1X-0006UK-13 for kitten@megatron.ietf.org; Fri, 24 Jun 2005 19:55:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09854 for ; Fri, 24 Jun 2005 19:55:50 -0400 (EDT) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyQ9-00023e-2V for kitten@ietf.org; Fri, 24 Jun 2005 20:21:18 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA16106; Sat, 25 Jun 2005 01:55:14 +0200 (MESZ) From: Martin Rex Message-Id: <200506242355.BAA17309@uw1048.wdf.sap.corp> To: Nicolas.Williams@Sun.COM (Nicolas Williams) Date: Sat, 25 Jun 2005 01:55:11 +0200 (MET DST) In-Reply-To: <20050624030856.GX16670@binky.Central.Sun.COM> from "Nicolas Williams" at Jun 23, 5 10:08:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, raeburn@MIT.EDU, Seema.Malkani@Sun.COM Subject: Re: PRF comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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 Nicolas Williams wrote: > > Well, RFC2743 does that, and it's a normative reference; you have to > read the base specs to figure out how to display major and minor status > codes anyways. And the text in draft-ietf-kitten-gssapi-prf-04 kinda > mentions it already: > > o GSS_S_FAILURE indicates general failure, possibly due to the given > input data being too large or of zero length, or due to the > desired_output_len being zero; the minor status code may provide > additional information. GSS_S_FAILURE is supposed to be the indicator that an error occured for which no generic error code was defined. That means a mechanism (close to) "must" supply a minor_status code in order to give a clue why the call failed. The general rule is that this minor_status code needs to translate into something that a human can comprehend (at least a human with clue), because portable applications will not be able to programmatically react to individual minor_status codes and instead will present the output of gss_display_status(MECH_CODE,minor_status) either to a human user or (in case of unattended servers) write it to a logfile and consider the operation or transaction failed. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 20:15:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyKz-0003vg-WA; Fri, 24 Jun 2005 20:15:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyKx-0003vZ-Kg for kitten@megatron.ietf.org; Fri, 24 Jun 2005 20:15:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12011 for ; Fri, 24 Jun 2005 20:15:54 -0400 (EDT) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyjZ-0002oP-OE for kitten@ietf.org; Fri, 24 Jun 2005 20:41:23 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA24411; Sat, 25 Jun 2005 02:15:35 +0200 (MESZ) From: Martin Rex Message-Id: <200506250015.CAA17576@uw1048.wdf.sap.corp> To: raeburn@MIT.EDU (Ken Raeburn) Date: Sat, 25 Jun 2005 02:15:35 +0200 (MET DST) In-Reply-To: <63eb2f8b3ca5cf526790ec53bc5d22a5@mit.edu> from "Ken Raeburn" at Jun 23, 5 11:34:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, Seema.Malkani@Sun.COM, Nicolas.Williams@Sun.COM Subject: Re: PRF comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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 Ken Raeburn wrote: > > In the descriptions of individual functions in RFC 2744, minor_status > described as one or the other -- either it's mechanism-specific for > this function, or it's implementation-specific. For GSS_Pseudo_random, > which one is it? > > That aspect of RFC 2744 bothers me, actually. Seems to me that it > implies that mechanism-specific and implementation-specific minor > status codes would have to partition the number space or risk > duplicating values. Maybe it's just a bug in the RFC and it should've > been mechanism-specific always? I agree that it is difficult to partition the number space, but depending on the architecture it may be impossible to do otherwise. The minor_status is usually implementation specific, but a mechanism spec could decide to standardize on a small number of explicit minor_status codes so that an application that recognizes this particular mechanism could programmatically recognize and process the mechanism-specific minor_status code. All minor_status codes that are not explicitly menitioned/reserved in the mechanism spec are therefore implementation specific -- which also means that only the mechanism which produced it can translate it into a textual message when called via gss_display_message(). Anyone who looked at my gsskrb5 wrapper for Microsoft's SSPI may have noticed the partitioning of the minor_status number space that I'm doing there. In a layered software architecture you may not want to enumerate every possible error code yourself with an explanation, but instead try to pass on errors from lower layers (hoping they fit into a specific number range as they are or tailoring them for this purpose. I partitioned the number space on Microsoft Windows so that I could pass through - errno's from ANSI-C functions which are very low numbers - Errors from Win32-API GetLastError() which are faily low numbers - Errors from Winsock-API WSAGetLastError() small range, fairly low base - SSPI SecStatus values small range, quite high base - parsing errors from the generic wrapping layer - parsing errors from the mechanism specific wrapping layer It seems to work fairly well. Curiously, I have even extended the model quite recently (in a not yet release version), so that it also Identifies the exact SSPI-call which failed when an minor_status describing an SSPI-error is returned, since some of the wrapper functions call several SSPI calls within a single GSS-API call and it's otherwise too difficult to debug if the SSPI unexpectedly returns "UNSUPPORTED_FUNCTION" on a new service pack or a particular customer machine on a function with is working fine with the same parameters on thousands of other/older machines and configurations. So far that happened twice to me ... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 20:27:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyWb-0006FI-SI; Fri, 24 Jun 2005 20:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlyWa-0006FD-N0 for kitten@megatron.ietf.org; Fri, 24 Jun 2005 20:27:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12695 for ; Fri, 24 Jun 2005 20:27:55 -0400 (EDT) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyvD-00036E-1c for kitten@ietf.org; Fri, 24 Jun 2005 20:53:24 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA28503; Sat, 25 Jun 2005 02:27:35 +0200 (MESZ) From: Martin Rex Message-Id: <200506250027.CAA17701@uw1048.wdf.sap.corp> To: Nicolas.Williams@Sun.COM (Nicolas Williams) Date: Sat, 25 Jun 2005 02:27:35 +0200 (MET DST) In-Reply-To: <20050624034421.GC16670@binky.Central.Sun.COM> from "Nicolas Williams" at Jun 23, 5 10:44:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org, raeburn@MIT.EDU, Seema.Malkani@Sun.COM Subject: Re: PRF comments X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com 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 Nicolas Williams wrote: > > Grrr. RFC2744 says this about it in the description of > gss_create_empty_oid_set() > > minor_status Integer, modify > Mechanism specific status code > > Clearly a mistake -- there's NO MECHANISM INVOLVED in creating an empty > OID set, at least not in a multi-mechanism implementation. > > The problem here is not RFC2744's fault, but 2743's. There are GSS > functions that don't obviously involve a mechanism but which nonetheless > output a minor_status, and it's not at all clear how to display them, > because GSS_C_NULL_OID is allowed to mean the default mechanism! > > Which is why I'd like to introduce an OID for the multi-mechglue itself > -- just so it can be used in calls to gss_display_status(). If it wouldn't have been to late, we would have ripped the entire set of gss_OID_set management function from the GSS-API v2 spec when we found the serious problems with the gss_OID functions, on the grounds that these functions are not mechanism specific and therefore don't really belong into this API. They're nice helper function for some purposes, yes, but they're definitely not mechanism specific and primarily bloat the spec. A reasonable portable application will bring along its own functions (not only because it needs them anyway if all it gets is a GSS-API v1 mechanism), but also because it can deal with its own implementation much more efficiently and 100% predictable and clear regarding the error handling. > > But, look, I refuse :) to have to deal with this problem in this I-D -- > it's quite clear that GSS_Pseudo_random() involves a mechanism, so the > minor_status code must, implicitly, be a mechanism-specific code, and, > anyways, the app can currently do nothing more than call > gss_display_status() with the actual mechanism of the context in order > to display it. You could define additional major status codes -- the only difficult (but solvable) problem is how to assign/reserve numbers for the different language bindings (and how to make sure new or rev'ed language bindings and/or high-level spec adopt them on their next round on the standards track. :) > > That aspect of RFC 2744 bothers me, actually. Seems to me that it > > implies that mechanism-specific and implementation-specific minor > > status codes would have to partition the number space or risk > > duplicating values. Maybe it's just a bug in the RFC and it should've > > been mechanism-specific always? > > See above. It's a bug in the RFC. I don't think it is a bug. It rather is a tribute to reality that there's no silver bullet solution and in some scenarios the number space may have to be partitioned in order to make things work (particularly layering of software). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 23:36:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1Ss-0004gs-T2; Fri, 24 Jun 2005 23:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1Sq-0004gn-9M for kitten@megatron.ietf.org; Fri, 24 Jun 2005 23:36:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26540 for ; Fri, 24 Jun 2005 23:36:11 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm1rQ-0008Qh-Qz for kitten@ietf.org; Sat, 25 Jun 2005 00:01:43 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5P3a9FF017179 for ; Fri, 24 Jun 2005 20:36:09 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5P3a9fb015579 for ; Fri, 24 Jun 2005 21:36:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5P3a8fV011205; Fri, 24 Jun 2005 22:36:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5P3a45i011204; Fri, 24 Jun 2005 22:36:04 -0500 (CDT) Date: Fri, 24 Jun 2005 22:36:04 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20050625033604.GG16670@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , raeburn@MIT.EDU, kitten@ietf.org, Seema.Malkani@Sun.COM References: <20050624030856.GX16670@binky.Central.Sun.COM> <200506242355.BAA17309@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506242355.BAA17309@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, raeburn@MIT.EDU, Seema.Malkani@Sun.COM Subject: Re: PRF comments 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 On Sat, Jun 25, 2005 at 01:55:11AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > Well, RFC2743 does that, and it's a normative reference; you have to > > read the base specs to figure out how to display major and minor status > > codes anyways. And the text in draft-ietf-kitten-gssapi-prf-04 kinda > > mentions it already: > > > > o GSS_S_FAILURE indicates general failure, possibly due to the given > > input data being too large or of zero length, or due to the > > desired_output_len being zero; the minor status code may provide > > additional information. > > GSS_S_FAILURE is supposed to be the indicator that an error occured > for which no generic error code was defined. That means a mechanism > (close to) "must" supply a minor_status code in order to give a clue > why the call failed. Sigh. I don't think "MUST" is necessary. RFCs 2743 and 2744 are incredibly loose with respect to minor_status codes, and I don't want to have to address that with each little extension. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 24 23:42:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1YS-0005gC-1l; Fri, 24 Jun 2005 23:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1YQ-0005g1-Lk for kitten@megatron.ietf.org; Fri, 24 Jun 2005 23:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26890 for ; Fri, 24 Jun 2005 23:42:00 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm1x4-00006m-MN for kitten@ietf.org; Sat, 25 Jun 2005 00:07:32 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5P3fxKg026652 for ; Fri, 24 Jun 2005 20:41:59 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5P3fxfb017015 for ; Fri, 24 Jun 2005 21:41:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5P3fxoi011217; Fri, 24 Jun 2005 22:41:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5P3fxwG011216; Fri, 24 Jun 2005 22:41:59 -0500 (CDT) Date: Fri, 24 Jun 2005 22:41:58 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20050625034158.GH16670@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , raeburn@MIT.EDU, kitten@ietf.org, Seema.Malkani@Sun.COM References: <20050624034421.GC16670@binky.Central.Sun.COM> <200506250027.CAA17701@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506250027.CAA17701@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org, raeburn@MIT.EDU, Seema.Malkani@Sun.COM Subject: Re: PRF comments 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 On Sat, Jun 25, 2005 at 02:27:35AM +0200, Martin Rex wrote: > If it wouldn't have been to late, we would have ripped the entire > set of gss_OID_set management function from the GSS-API v2 spec when > we found the serious problems with the gss_OID functions, on the > grounds that these functions are not mechanism specific and therefore > don't really belong into this API. They're nice helper function for > some purposes, yes, but they're definitely not mechanism specific > and primarily bloat the spec. If it makes you feel any better, GSS_Import_name() has exactly the same problem with respect to minor_status as do the OID set utility functions. And so does GSS_Indicate_mechs(), and... And GSS_Accept_sec_context could return a non-mechanism minor_status code, e.g., if the OID wrapper on an initial context token is missing/defective. And GSS_Import_name() could too when importing a defective exported name token. But all this is off-topic. While we're off-topic, I doubt I'll agree to removing the OID set utility functions :) > I don't think it is a bug. > > It rather is a tribute to reality that there's no silver bullet > solution and in some scenarios the number space may have to be partitioned > in order to make things work (particularly layering of software). The API could have been designed with better error reporting facilities -- e.g., with an opaque error output object instead of an integer type. But this is off-off-topic. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Jun 25 00:01:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1qx-0001WR-Nj; Sat, 25 Jun 2005 00:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm1qv-0001Vp-UU for kitten@megatron.ietf.org; Sat, 25 Jun 2005 00:01:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27897 for ; Sat, 25 Jun 2005 00:01:07 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm2FZ-0000Yi-SW for kitten@ietf.org; Sat, 25 Jun 2005 00:26:39 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5P416qg026749 for ; Fri, 24 Jun 2005 22:01:07 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5P416fb023773 for ; Fri, 24 Jun 2005 22:01:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5P40x5V011272 for ; Fri, 24 Jun 2005 23:00:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5P40xmb011271 for kitten@ietf.org; Fri, 24 Jun 2005 23:00:59 -0500 (CDT) Date: Fri, 24 Jun 2005 23:00:59 -0500 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050625040059.GL711@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: Proposed PRF changes to address Ken's comments 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 I propose the following changes to the PRF I-Ds to address Ken's comments: - Change the reference to the Kerberos V mechanism to be a reference to the CFX I-D, rather than a reference to RFC1964. - Add the following to the Security Considerations of the base PRF I-D: For some mechanisms the computational cost of computing GSS_Pseudo_random() may increase significantly as the length of the prf_in data and/or the desired_output_length increase. This means that if an application can be tricked into providing very large input octet strings and requesting very long output octet strings then that may constitute a denial of service attack on the application; therefore applications SHOULD place appropriate limits on the size of any input octet strings received from their peers without integrity protection. - In the base PRF I-D change: - If the implementation cannot produce the desired output due to lack - of resources then it MUST output what it can and still return - GSS_S_COMPLETE. to + If the implementation cannot produce the desired output due to lack + of resources then it MUST return GSS_S_FAILURE and MUST set a + suitable minor status code. - I see no value in saying anything more about minor_status. I think RFCs 2743 and 2744, normative references that they are, should answer (or not) any questions about it. - I await a reply from Seema about Ken's Java bindings question. Comments? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Jun 26 13:41:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmb8C-0005EC-LF; Sun, 26 Jun 2005 13:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmb8B-0005E4-AZ for kitten@megatron.ietf.org; Sun, 26 Jun 2005 13:41:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26373 for ; Sun, 26 Jun 2005 13:41:17 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmbX7-0006kT-Fc for kitten@ietf.org; Sun, 26 Jun 2005 14:07:08 -0400 Received: from phys-d3-ha21sca-1 ([129.145.155.163]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j5QHfEw4025629 for ; Sun, 26 Jun 2005 11:41:14 -0600 (MDT) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IIP00701CNIWU@ha21sca-mail1.sfbay.sun.com> (original mail from Seema.Malkani@Sun.COM) for kitten@ietf.org; Sun, 26 Jun 2005 10:41:14 -0700 (PDT) Received: from sun.com (vpn-129-150-33-109.Central.Sun.COM [129.150.33.109]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IIP00MG4D4PTN@ha21sca-mail1.sfbay.sun.com> for kitten@ietf.org; Sun, 26 Jun 2005 10:41:14 -0700 (PDT) Date: Sun, 26 Jun 2005 10:42:26 -0700 From: Seema Malkani In-reply-to: <20050625040059.GL711@binky.Central.Sun.COM> To: Nicolas Williams Message-id: <42BEE902.3010009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 References: <20050625040059.GL711@binky.Central.Sun.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7BIT Cc: kitten@ietf.org Subject: Re: Proposed PRF changes to address Ken's comments 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 Nicolas Williams wrote: > > - I await a reply from Seema about Ken's Java bindings question. > > >Comments? > >Nico > > To answer Ken's question : Adding a new method to a standardized interface will break existing applications. This means all classes that implement GSSContext interface will now need to add the new method. All implementations of Java GSS will NOT compile until the new method is added. Abstract classes don't have such a problem, since you can provide a default (possibly empty) implementation, and existing implementations will not break. It is easier to evolve an abstract class than to evolve an interface. Since GSSContext was defined to be an interface, we cannot change it. Alternatives ? We can possibly add the new method to GSSManager class, which is an abstract class. This class serves as a factory for three GSS interfaces: GSSName, GSSCredential, and GSSContext. The new method will have to be invoked after the GSSContext has been established. GSSManager class: public byte[] prf(GSSContext context, int prf_key, byte[] inBuf, int outlen) throws GSSException GSSManager mgr = GSSManager.getInstance(); GSSName targetName = mgt.createName("service@host", ..); GSSContext context = mgr.createContext(targetName, ..); .. if (context.isEstablished()) { // define PRF key, input.. int prf_key = .. .. byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen); } Seema _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Jun 26 19:35:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmgfP-00084q-69; Sun, 26 Jun 2005 19:35:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmgfN-00084l-90 for kitten@megatron.ietf.org; Sun, 26 Jun 2005 19:35:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23753 for ; Sun, 26 Jun 2005 19:35:53 -0400 (EDT) Received: from stratton-three-fifty-seven.mit.edu ([18.187.6.102] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmh4O-0007BY-P4 for kitten@ietf.org; Sun, 26 Jun 2005 20:01:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4135CE0063; Sun, 26 Jun 2005 19:35:51 -0400 (EDT) To: Matt Peterson References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> From: Sam Hartman Date: Sun, 26 Jun 2005 19:35:51 -0400 In-Reply-To: <200504211232.20480.mpeterson@vintela.com> (Matt Peterson's message of "Thu, 21 Apr 2005 12:32:20 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF 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 >>>>> "Matt" == Matt Peterson writes: Matt> Hi, >> > Jeffrey Altman wrote: > I have started a discussion with you >> on the krbdev@mit.edu mailing > list. Let's take this >> discussion there. I am sure that we can work > with you to get >> the functionality you need into a future release > without >> muddying the GSS standards track. Matt> So can someone explain why this is a krbdev@mit.edu Matt> discussion and not something suited to the kitten list? I Matt> don't think it is mudding the waters at all. It seems to me Matt> like a legitmate request for generic API functionality. I think the argument is that it is outside the kitten charter. Speaking as an individual, I don't want to see kitten become a forum for Microsoft interoperability. I'd rather see the GSSAPI be a well designed security API, not one forced to support all the mistakes Microsoft made. We'll be busy enough supporting the mistakes we make. That said, I believe we may actually want an API for extracting the key or at least something that maps on the EAP MSK and EMSK. Matt> I agree with Nico's post... >> On Friday 15 April 2005 22:01, Nicolas Williams wrote: [snip] >> *That* function cannot be standardized, but *a* function like >> it that did not use the 'krb5_keyblock' type *could* be made a >> standard mechanism-specific GSS-API extension. >> >> And why not? SPNEGO has mechanism-specific extensions too... >> >> I'd have the function output an INTEGER corresponding to the >> key's enctype and an OCTET STRING corresponding to the key's >> value. The C-bindings of that would be straightforward. Matt> I think that GSS-API needs to respond to the types of Matt> request being made by the Samba team for a usable API. Why Matt> can't we talk about standardizing a function instead of Matt> shuffling the discussion off to an implementation specific Matt> mailing list? Matt> -- Matt Matt> _______________________________________________ Kitten Matt> mailing list Kitten@lists.ietf.org Matt> https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Jun 26 19:39:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmgjA-0000Hu-FU; Sun, 26 Jun 2005 19:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmgj8-0000Hm-NM for kitten@megatron.ietf.org; Sun, 26 Jun 2005 19:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23980 for ; Sun, 26 Jun 2005 19:39:47 -0400 (EDT) Received: from stratton-three-fifty-seven.mit.edu ([18.187.6.102] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmh8A-0007QR-89 for kitten@ietf.org; Sun, 26 Jun 2005 20:05:43 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C34D4E0063; Sun, 26 Jun 2005 19:39:46 -0400 (EDT) To: Matt Peterson References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <20050421183737.GF7361@binky.Central.Sun.COM> <20050421183807.GF14870@binky.Central.Sun.COM> <200504211454.23148.mpeterson@vintela.com> From: Sam Hartman Date: Sun, 26 Jun 2005 19:39:46 -0400 In-Reply-To: <200504211454.23148.mpeterson@vintela.com> (Matt Peterson's message of "Thu, 21 Apr 2005 14:54:22 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Nicolas Williams Subject: Re: CIFS and the krb5 PRF 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 >>>>> "Matt" =3D=3D Matt Peterson writes: Matt> On Thursday 21 April 2005 12:38, Nicolas Williams wrote: >> KITTEN is not charatered to design a raw krb5 mechanism and >> associated mechanism-specific GSS extensions. =A0Generic GSS >> extensions, OTOH, do fall under its charter. >>=20 >> There's no need to burden the KITTEN list subscribers with talk >> of a GSS-based API for raw krb5, at least not yet. >>=20 >> None of which means that a raw krb5 API based on the GSS-API >> couldn't be documented in IETF RFCs. =A0All we need is a forum >> with the right participants, and I do believe that this is >> pretty close to being the right forum. >>=20 >> this =3D=3D krbdev Matt> Ok. As a *mechanism-specific GSS extension* moving the Matt> discussion to a new forum makes sense. (I assume the Matt> discussion falls outside the scope of ietf-krb-wg charter?) Note that the krb-wg or kitten chairs could decide that the discussion was appropriate on their lists even if it is out of charter. They would typically do so if they expected the discussion to be relatively short, contained and not to get in the way of the working group's efforts. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jun 27 05:11:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmpel-0000yE-83; Mon, 27 Jun 2005 05:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmpej-0000y6-13 for kitten@megatron.ietf.org; Mon, 27 Jun 2005 05:11:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27450 for ; Mon, 27 Jun 2005 05:11:50 -0400 (EDT) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmq3n-0006v4-8M for kitten@ietf.org; Mon, 27 Jun 2005 05:37:50 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id D091F162AF4; Mon, 27 Jun 2005 09:11:41 +0000 (GMT) From: Andrew Bartlett To: Sam Hartman In-Reply-To: References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> Date: Mon, 27 Jun 2005 19:11:44 +1000 Message-Id: <1119863504.8698.22.camel@amy.flyaway.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: kitten@ietf.org Subject: Re: CIFS and the krb5 PRF 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="===============2063467781==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --===============2063467781== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-P7lwV4GllEGg1t28TRKe" --=-P7lwV4GllEGg1t28TRKe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-06-26 at 19:35 -0400, Sam Hartman wrote: > >>>>> "Matt" =3D=3D Matt Peterson writes: >=20 > Matt> Hi, > >> > Jeffrey Altman wrote: > I have started a discussion with you > >> on the krbdev@mit.edu mailing > list. Let's take this > >> discussion there. I am sure that we can work > with you to get > >> the functionality you need into a future release > without > >> muddying the GSS standards track. >=20 > Matt> So can someone explain why this is a krbdev@mit.edu > Matt> discussion and not something suited to the kitten list? I > Matt> don't think it is mudding the waters at all. It seems to me > Matt> like a legitmate request for generic API functionality. >=20 > I think the argument is that it is outside the kitten charter. >=20 > Speaking as an individual, I don't want to see kitten become a forum > for Microsoft interoperability. I'd rather see the GSSAPI be a well > designed security API, not one forced to support all the mistakes > Microsoft made. We'll be busy enough supporting the mistakes we make. >=20 > That said, I believe we may actually want an API for extracting the > key or at least something that maps on the EAP MSK and EMSK. Given the strongly held views of represented here that Samba4 (in particular) should not be locked into a particular Kerberos/GSSAPI implementation, where should I address discussion about the changes that Samba4 requires? I have already made a number of experimental modifications to Heimdal kerberos (a copy of which we will ship built into Samba4 for initial release). While I already get some good feedback from Love, I know others have views. =20 The 'CIFS Session key' export is just one of these required extensions - we also need to change the GSS_Wrap arguments to support AEAD, and closer control over the underlying Kerberos behaviour. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Samba Developer, SuSE Labs, Novell Inc. http://suse.de Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-P7lwV4GllEGg1t28TRKe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCv8LQz4A8Wyi0NrsRAjHPAJ42hBg4n3oCnm0JK4cu5cyX7KMkgACfXj8U 0s8pjdZIO0MeWCvhIDeoLpI= =1Z03 -----END PGP SIGNATURE----- --=-P7lwV4GllEGg1t28TRKe-- --===============2063467781== 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 --===============2063467781==-- From kitten-bounces@lists.ietf.org Mon Jun 27 05:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmpqp-0002hF-KJ; Mon, 27 Jun 2005 05:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmpqo-0002hA-9a for kitten@megatron.ietf.org; Mon, 27 Jun 2005 05:24:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28430 for ; Mon, 27 Jun 2005 05:24:19 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmqFu-0007Co-Ox for kitten@ietf.org; Mon, 27 Jun 2005 05:50:20 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5R9OECd021109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2005 05:24:16 -0400 (EDT) Message-ID: <42BFC696.2040904@columbia.edu> Date: Mon, 27 Jun 2005 05:27:50 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Bartlett References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> <1119863504.8698.22.camel@amy.flyaway.abartlet.net> In-Reply-To: <1119863504.8698.22.camel@amy.flyaway.abartlet.net> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: kitten@ietf.org, Sam Hartman Subject: Re: CIFS and the krb5 PRF 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="===============0356569670==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0356569670== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000404050201000402000803" This is a cryptographically signed message in MIME format. --------------ms000404050201000402000803 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Bartlett wrote: > Given the strongly held views of represented here that Samba4 (in > particular) should not be locked into a particular Kerberos/GSSAPI > implementation, where should I address discussion about the changes that > Samba4 requires? > > I have already made a number of experimental modifications to Heimdal > kerberos (a copy of which we will ship built into Samba4 for initial > release). While I already get some good feedback from Love, I know > others have views. > > The 'CIFS Session key' export is just one of these required extensions - > we also need to change the GSS_Wrap arguments to support AEAD, and > closer control over the underlying Kerberos behaviour. > > Andrew Bartlett Discussions of proprietary mechanism extensions for Kerberos 5 such as access to the Kerberos 5 ticket (or ticket parts) that you wish to be adopted by both Heimdal and MIT Kerberos should take place on the krbdev@mit.edu mailing list. The same is true for anything other change that would be incompatible with implementations of GSS API version 2 update 1. Discussions that are appropriate for the Kitten list are any changes this working group should consider for GSS API version 3. Jeffrey Altman --------------ms000404050201000402000803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI3MDkyNzUwWjAjBgkqhkiG9w0BCQQxFgQU8iKYSWX00+Zmrz8/GLmkUWnawRAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAZ4dV8Yrhd71rku/FfTArDja1uvHsBY0M0qJjdOV+ PZq/TL6vBKgl0bjyl5yzRp9cZ6/42ZaC3jHx5ocTv9Bp8F10gFwSNu2uqdzQxz7/Hv2NGM/p EkJLqIRLa4DkdYayHv3ZfkukZK0HemAS7r7+hUsBwgRtUK8HNS939JxPIcqaGTGe8hufIJrt uzY0Li81SF7R50JJNSkVcFGUjiizX03NRS7EvWOEI7b7a2IGahW0jK2ZXsOWpJrtNMbWdw2H WP5LclOdC9ZOhFHaC93cdpO2jaPo5JScZTRjS0v5Is3YGPZelfTVBxqfwH/lj5vH7PPnqJ0D jV24UxEJOfle6wAAAAAAAA== --------------ms000404050201000402000803-- --===============0356569670== 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 --===============0356569670==-- From kitten-bounces@lists.ietf.org Mon Jun 27 06:37:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqzZ-0004cx-Rv; Mon, 27 Jun 2005 06:37:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmqzX-0004cs-NJ for kitten@megatron.ietf.org; Mon, 27 Jun 2005 06:37:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04433 for ; Mon, 27 Jun 2005 06:37:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmrOe-0002oW-OC for kitten@ietf.org; Mon, 27 Jun 2005 07:03:26 -0400 Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1DmqzW-0005vm-Tc for kitten@ietf.org; Mon, 27 Jun 2005 06:37:26 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 6D5BF162AFC; Mon, 27 Jun 2005 10:36:52 +0000 (GMT) From: Andrew Bartlett To: Jeffrey Altman In-Reply-To: <42BFC696.2040904@columbia.edu> References: <1113608643.7488.274.camel@amy.samba4.abartlet.net> <42607B3A.3010806@columbia.edu> <42608663.2060506@sun.com> <200504211232.20480.mpeterson@vintela.com> <1119863504.8698.22.camel@amy.flyaway.abartlet.net> <42BFC696.2040904@columbia.edu> Date: Mon, 27 Jun 2005 20:36:55 +1000 Message-Id: <1119868615.8698.46.camel@amy.flyaway.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: kitten@ietf.org, Sam Hartman Subject: Re: CIFS and the krb5 PRF 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="===============1964727043==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org --===============1964727043== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dBjSE+NeDxO63YmRcVTr" --=-dBjSE+NeDxO63YmRcVTr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-06-27 at 05:27 -0400, Jeffrey Altman wrote:=20 > Andrew Bartlett wrote: >=20 > > Given the strongly held views of represented here that Samba4 (in > > particular) should not be locked into a particular Kerberos/GSSAPI > > implementation, where should I address discussion about the changes tha= t > > Samba4 requires? > >=20 > > I have already made a number of experimental modifications to Heimdal > > kerberos (a copy of which we will ship built into Samba4 for initial > > release). While I already get some good feedback from Love, I know > > others have views. =20 > >=20 > > The 'CIFS Session key' export is just one of these required extensions = - > > we also need to change the GSS_Wrap arguments to support AEAD, and > > closer control over the underlying Kerberos behaviour. > >=20 > > Andrew Bartlett >=20 > Discussions of proprietary mechanism extensions for Kerberos 5 such as > access to the Kerberos 5 ticket (or ticket parts) that you wish to be > adopted by both Heimdal and MIT Kerberos should take place on the > krbdev@mit.edu mailing list. &#-1;&#-1;=20 > > The same is true for anything other > change that would be incompatible with implementations of GSS API > version 2 update 1. >=20 > Discussions that are appropriate for the Kitten list are any changes > this working group should consider for GSS API version 3. Well, I certainly would like to see GSS API version 3 being flexible enough to provide the facilities that Samba4 requires. That would seem to be a desirable outcome. Clearly not all the things Samba4 requires, fit into that category, but I think some do. I'll continue hacking my way though GSSAPI as I move forward, let me know if you want to hear about what things I'm finding. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Samba Developer, SuSE Labs, Novell Inc. http://suse.de Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-dBjSE+NeDxO63YmRcVTr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCv9bHz4A8Wyi0NrsRAv2/AKCSzw1xhhOSZ33S2WKtbfmjI9o7BACeP0f0 6EiiCbS8jWaTEI/HcYyg9Lg= =gZUT -----END PGP SIGNATURE----- --=-dBjSE+NeDxO63YmRcVTr-- --===============1964727043== 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 --===============1964727043==-- From kitten-bounces@lists.ietf.org Mon Jun 27 11:30:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvYe-0002eu-Qe; Mon, 27 Jun 2005 11:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvYc-0002dv-FF for kitten@megatron.ietf.org; Mon, 27 Jun 2005 11:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03322 for ; Mon, 27 Jun 2005 11:29:55 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmvxl-0007vT-3Q for kitten@ietf.org; Mon, 27 Jun 2005 11:55:59 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5RFTs47012317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2005 11:29:54 -0400 (EDT) Message-ID: <42C01C5C.7020904@columbia.edu> Date: Mon, 27 Jun 2005 11:33:48 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seema Malkani References: <20050625040059.GL711@binky.Central.Sun.COM> <42BEE902.3010009@sun.com> In-Reply-To: <42BEE902.3010009@sun.com> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Proposed PRF changes to address Ken's comments 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="===============0311430273==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0311430273== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090905020607000606060801" This is a cryptographically signed message in MIME format. --------------ms090905020607000606060801 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Seema Malkani wrote: > To answer Ken's question : > > Adding a new method to a standardized interface will break existing > applications. This means all classes that implement GSSContext interface > will now need to add the new method. All implementations of Java GSS > will NOT compile until the new method is added. > > Abstract classes don't have such a problem, since you can provide a > default (possibly empty) implementation, and existing implementations > will not break. It is easier to evolve an abstract class than to evolve > an interface. Since GSSContext was defined to be an interface, we cannot > change it. > > Alternatives ? > > We can possibly add the new method to GSSManager class, which is an > abstract class. This class serves as a factory for three GSS interfaces: > GSSName, GSSCredential, and GSSContext. The new method will have to be > invoked after the GSSContext has been established. > > GSSManager class: > public byte[] prf(GSSContext context, int prf_key, byte[] inBuf, int > outlen) > throws GSSException > > GSSManager mgr = GSSManager.getInstance(); > GSSName targetName = mgt.createName("service@host", ..); > GSSContext context = mgr.createContext(targetName, ..); > .. > if (context.isEstablished()) { > // define PRF key, input.. > int prf_key = .. > .. > byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen); > } > > Seema Seema: This will definitely be a much more generic issue for Java GSS support than just the PRF. There are a number of new methods that the work of this group will require moving forward. Adding them all to the GSSManager class seems like an inappropriate thing to do. Even if we hold off defining a Java binding for PRF and wait for the majority of this group's work to complete, we will still be faced with this issue. I think we need to address the question of extensibility for the Java bindings. It would be unfortunate if everytime new GSS functionality was defined the interfaces implementing one or more of the classes had to be replaced. Jeffrey Altman --------------ms090905020607000606060801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI3MTUzMzQ4WjAjBgkqhkiG9w0BCQQxFgQU+eJ95YaIlkxPvNVsO6ZbplsL5+ww UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAjUyaRQacwEJP5PiFGa52+60g7/ofyveF4qEd8I4U 3xBBGMXUwv1e6QRFWVmSYxmLZGAXSfQeJD8dnEsKyh6S7gO942X6WeZYhpaUFYF+xuy4Opzv y7PkGXbBlJXD8R7QLoyffdpdRtsUPlyRsfzy5YLKEI7FF1mRwf1hiyT2EFx99kr3TBopVh2i 0CZufHzT7DlX0L6fple2Jb2LTZWrFIisfHdrmCrPPoiAVvmRdJrLU7U7mS7JMwAk3/23T0Fs vy0VGMMfOhq9qcI9nUuWeWfISvyMIF3wDuyA5mNb5QJo6Wr6J6j0nZC9rsDbGkFQy9nDkRMg cPbVJU82QUXMFAAAAAAAAA== --------------ms090905020607000606060801-- --===============0311430273== 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 --===============0311430273==-- From kitten-bounces@lists.ietf.org Mon Jun 27 14:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyhB-0003Ps-Ct; Mon, 27 Jun 2005 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyhA-0003Pn-5u for kitten@megatron.ietf.org; Mon, 27 Jun 2005 14:51:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23704 for ; Mon, 27 Jun 2005 14:50:56 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmz6G-0003VB-BB for kitten@ietf.org; Mon, 27 Jun 2005 15:17:01 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5RIopqg005706 for ; Mon, 27 Jun 2005 12:50:51 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5RIoofd027063 for ; Mon, 27 Jun 2005 12:50:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5RIon14018919; Mon, 27 Jun 2005 13:50:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5RIolKK018918; Mon, 27 Jun 2005 13:50:47 -0500 (CDT) Date: Mon, 27 Jun 2005 13:50:47 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050627185047.GS16670@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Seema Malkani , kitten@ietf.org References: <20050625040059.GL711@binky.Central.Sun.COM> <42BEE902.3010009@sun.com> <42C01C5C.7020904@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C01C5C.7020904@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org, Seema Malkani Subject: Re: Proposed PRF changes to address Ken's comments 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 On Mon, Jun 27, 2005 at 11:33:48AM -0400, Jeffrey Altman wrote: > Seema Malkani wrote: > > To answer Ken's question : > > > > Adding a new method to a standardized interface will break existing > > applications. This means all classes that implement GSSContext interface > > will now need to add the new method. All implementations of Java GSS > > will NOT compile until the new method is added. > > > > Abstract classes don't have such a problem, since you can provide a > > default (possibly empty) implementation, and existing implementations > > will not break. It is easier to evolve an abstract class than to evolve > > an interface. Since GSSContext was defined to be an interface, we cannot > > change it. > > > > Alternatives ? > > > > We can possibly add the new method to GSSManager class, which is an > > abstract class. This class serves as a factory for three GSS interfaces: > > GSSName, GSSCredential, and GSSContext. The new method will have to be > > invoked after the GSSContext has been established. > > Seema: > > This will definitely be a much more generic issue for Java GSS support > than just the PRF. There are a number of new methods that the work of > this group will require moving forward. Adding them all to the > GSSManager class seems like an inappropriate thing to do. Even if we > hold off defining a Java binding for PRF and wait for the majority of > this group's work to complete, we will still be faced with this issue. > I think we need to address the question of extensibility for the Java > bindings. It would be unfortunate if everytime new GSS functionality > was defined the interfaces implementing one or more of the classes had > to be replaced. I propose removing the Java bindings from the PRF I-D and resolving this problem separately. No, I don't like this proposal, but it's either that or wait to resolve the Java bindings extensibility issue first. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jun 27 15:20:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmz9p-0000Hg-Si; Mon, 27 Jun 2005 15:20:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmz9n-0000GQ-U0 for kitten@megatron.ietf.org; Mon, 27 Jun 2005 15:20:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26652 for ; Mon, 27 Jun 2005 15:20:33 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmzYz-0005nO-E3 for kitten@ietf.org; Mon, 27 Jun 2005 15:46:38 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5RJKWP2013367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2005 15:20:33 -0400 (EDT) Message-ID: <42C05259.1040300@columbia.edu> Date: Mon, 27 Jun 2005 15:24:09 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <20050625040059.GL711@binky.Central.Sun.COM> <42BEE902.3010009@sun.com> <42C01C5C.7020904@columbia.edu> <20050627185047.GS16670@binky.Central.Sun.COM> In-Reply-To: <20050627185047.GS16670@binky.Central.Sun.COM> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: kitten@ietf.org Subject: Re: Proposed PRF changes to address Ken's comments 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="===============0444540320==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0444540320== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090703070504010107000300" This is a cryptographically signed message in MIME format. --------------ms090703070504010107000300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > I propose removing the Java bindings from the PRF I-D and resolving this > problem separately. No, I don't like this proposal, but it's either > that or wait to resolve the Java bindings extensibility issue first. > > Nico Can someone speak to the question of whether or not C# is going to have similar issues? Jeffrey Altman --------------ms090703070504010107000300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI3MTkyNDA5WjAjBgkqhkiG9w0BCQQxFgQUH9d2IVzhkRNKG0ngoOHgxEox0ssw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAjljM8QCH/GYDm4Th3FdbS3IfEJq/0aOkW5y7vOqD cTkrFChddnqAlJvmXFnTrXMGSRn+9i3BT7RlWRsG4uODczX35jSLDXBKEpEWJMnoiq2lNgGS a5XPSzLy++LAK3mFV5ZfMVVlki+zULVn3w+TmfVtUn9hVyBDexyWz5OAXfKGMqQ3r8KbhXmo joh+G7ML8Sik/DbmfqNR/yCOeNll8Rc4AbCMYbm1Js1CmU4MMV/DlFwyPuQTzz8KaLVgbK8+ ory6nJ/cjwkgkxeSdHjDkBqSxlXj5vO6qS/3HHvmnn9TGGQBEi5jX1leYqUwsaCJ7od+MzNj i4tXtHz6ultFJQAAAAAAAA== --------------ms090703070504010107000300-- --===============0444540320== 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 --===============0444540320==-- From kitten-bounces@lists.ietf.org Mon Jun 27 18:53:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2Tf-00054j-D8; Mon, 27 Jun 2005 18:53:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn2Te-00054e-1a for kitten@megatron.ietf.org; Mon, 27 Jun 2005 18:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06021 for ; Mon, 27 Jun 2005 18:53:14 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn2sq-0003Mz-KW for kitten@ietf.org; Mon, 27 Jun 2005 19:19:22 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5RMrEIq022805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 27 Jun 2005 18:53:14 -0400 (EDT) Message-ID: <42C0844B.2030300@columbia.edu> Date: Mon, 27 Jun 2005 18:57:15 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: request for agenda items 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="===============1257077880==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1257077880== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040906080700000003070300" This is a cryptographically signed message in MIME format. --------------ms040906080700000003070300 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit During the Paris IETF63 I would like to spend the majority of the time on a specific topic: reviewing the mailing list archives and identifying the specific sections of text we wish to use as a basis for satisfying this Working Group milestone: Jul 05 Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard Please provide a list of other topics to be discussed at this meeting. Thank you. Jeffrey Altman --------------ms040906080700000003070300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI3MjI1NzE1WjAjBgkqhkiG9w0BCQQxFgQU3hMaZ9J7XO7YpR8XWZ2OaAu8bFMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAiUr41845RP+7Z5NizvO0xSlm6jAtDpTFjpS5F2ic gUb5XT5jTrC7cAsaYv4xJV0HMO/8HUhW4FdCrwXzuoa+CAY2+K4XFApAET0WRWtZNENPgQRt StaAYmH06GbtBXIrh1i3THk9miQBzJzY/9cZSgHPiqfUQIaWHvPoVL2z1hUsiZr1CYndZlGH F+Uj6are5SecNO0hiV+yM+Vgcy4SvxFvGLZi2M1105NJqlLPc9mZ01Vt+5WjLOLV0nYvxglJ DpzKn1rWn+kEPboc9A5lMa/HQl/rGAXRYS/1KFkKlw7UtS+QiR8+wVhJkuIjKq475xiVkA+c GtUKzyhDUJu0LgAAAAAAAA== --------------ms040906080700000003070300-- --===============1257077880== 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 --===============1257077880==-- From kitten-bounces@lists.ietf.org Wed Jun 29 13:45:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngdL-0006m7-7f; Wed, 29 Jun 2005 13:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngdK-0006kM-CI for kitten@megatron.ietf.org; Wed, 29 Jun 2005 13:45:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16834 for ; Wed, 29 Jun 2005 13:45:57 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnh2s-0000Ag-IV for kitten@ietf.org; Wed, 29 Jun 2005 14:12:25 -0400 Received: from [18.18.6.109] (WEST-NINETYTWO-THREE-SIXTY-FOUR.MIT.EDU [18.18.6.109]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5THjrUm028244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Jun 2005 13:45:53 -0400 (EDT) Message-ID: <42C2DE3F.4050502@columbia.edu> Date: Wed, 29 Jun 2005 13:45:35 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Subject: [Fwd: IANA GSSAPI name registry out of date] 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="===============0993208146==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0993208146== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060904080904070101070709" This is a cryptographically signed message in MIME format. --------------ms060904080904070101070709 Content-Type: multipart/mixed; boundary="------------030205030802080803030403" This is a multi-part message in MIME format. --------------030205030802080803030403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------030205030802080803030403 Content-Type: message/rfc822; name="IANA GSSAPI name registry out of date" Content-Disposition: inline; filename="IANA GSSAPI name registry out of date" Return-Path: Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by feta.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5THdf4U002100 for ; Wed, 29 Jun 2005 13:39:42 -0400 (EDT) Received: by mailhost.anl.gov (Postfix) id 29962F4; Wed, 29 Jun 2005 12:39:40 -0500 (CDT) Delivered-To: ietf-krb-wg-outgoing@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 07F82F1 for ; Wed, 29 Jun 2005 12:39:40 -0500 (CDT) Received: by mailhost.anl.gov (Postfix, from userid 10733) id EA9C1F4; Wed, 29 Jun 2005 12:39:39 -0500 (CDT) X-Original-To: ietf-krb-wg@anl.gov Delivered-To: ietf-krb-wg@anl.gov Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 7D2BFF2 for ; Wed, 29 Jun 2005 12:39:39 -0500 (CDT) Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix) with ESMTP id 682B4F1 for ; Wed, 29 Jun 2005 12:39:39 -0500 (CDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 051015F0C4D; Wed, 29 Jun 2005 12:39:40 -0500 (CDT) Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mailrelay.anl.gov (Postfix) with ESMTP id AB6A85F0C4D for ; Wed, 29 Jun 2005 12:39:39 -0500 (CDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2F3D4E0063; Wed, 29 Jun 2005 13:39:37 -0400 (EDT) To: krbdev@mit.edu, ietf-krb-wg@anl.gov Subject: IANA GSSAPI name registry out of date From: Sam Hartman Date: Wed, 29 Jun 2005 13:39:37 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on frigga.ctd.anl.gov X-Spam-Status: No, hits=-100.0 required=5.7 tests=USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Level: Sender: owner-ietf-krb-wg@mailhost.anl.gov Precedence: bulk X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Hi. a vendor was asking about the gss service name registry and I took a look at http://www.iana.org/assignments/gssapi-service-names I think we could do some work updating this registry. Errors I noticed; 1) rcmd is v4 2) Missing HTTP, cifs, ldap, probably many others. I'd appreciate it if someone could prepare a set of updates to the registry. I'd be happy to review them and to send them to IANA. --Sam --------------030205030802080803030403-- --------------ms060904080904070101070709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI5MTc0NTM1WjAjBgkqhkiG9w0BCQQxFgQUdLvDRPQuLWU2BDzZYvXtxqjVJMAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAA9H0IgaweyNAUQQ4h/z3DWADGQiHGrT5JT+ajlMr z/rwcJ/IyrWx4UgUueFbdOqULmf2DJFk4cBl6vUa/c0fsE9piyBp49fbdaPF43wZ/eVYjyMJ ZWKZE/ZatnsMQQudesK0Q3LRl0UFaPQGw72ly2juJHT8k0wQciUS9nTG77nXv8XzIlzoE59P HZnb7rQSNMrterkDQfW1HqoPTHYAbhAXp9GQuJViO0NiwG99DeJ9O/kEhR2weJItyosWnQh7 ocLuP/XmB92y2SbnKcoSFEqpoN01Bm4NLEDh5bUTuYLytkklL2l9Iv1YX/IqjPf5sEE9EJJd qYKRtd/VuvPn/gAAAAAAAA== --------------ms060904080904070101070709-- --===============0993208146== 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 --===============0993208146==-- From kitten-bounces@lists.ietf.org Wed Jun 29 17:24:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnk2P-0003mj-0G; Wed, 29 Jun 2005 17:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnk2O-0003mb-D2 for kitten@megatron.ietf.org; Wed, 29 Jun 2005 17:24:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27111 for ; Wed, 29 Jun 2005 17:24:02 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnkS0-0001ek-LP for kitten@ietf.org; Wed, 29 Jun 2005 17:50:33 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 17138E0063; Wed, 29 Jun 2005 17:24:00 -0400 (EDT) To: kitten@ietf.org References: <20050222234246.GP1007@binky.Central.Sun.COM> From: Sam Hartman Date: Wed, 29 Jun 2005 17:24:00 -0400 In-Reply-To: <20050222234246.GP1007@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 22 Feb 2005 17:42:46 -0600") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: Re: New naming draft submitted 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 >>>>> "Nicolas" == Nicolas Williams writes: Hi. A new draft has been submitted which I believe addresses your comments. See below. Nicolas> - section 1, 2nd paragraph, not only do names change Nicolas> over time, but they may even be re-used, which poses a Nicolas> real security problem. Text added. Nicolas> - section 3, you may want to mention that an exported Nicolas> name token for x.509 certs that included all attributes Nicolas> of the cert, or the cert itself, also would be an Nicolas> inadequate solution, and why. Done. Nicolas> - section 4, we may need some additional operations: Nicolas> - inquire additional typing information given a name Nicolas> attribute OID Nicolas> - name attribute type/value display operation Nicolas> - utility for extended name display Nicolas> - name attribute comparison and/or export/import, Nicolas> unless the name attribute octet string is required to be Nicolas> in some canonical format that can be compared directly Added text indicating this is not an exaustive list. Nicolas> - section 4, it may be worthwhile to point out that Nicolas> knowing the source of a name attribute would be good. Nicolas> Name attributes may have been added to a name without any Nicolas> authentication, or they may have been asserted, but not Nicolas> authenticated during security context establishment, or Nicolas> they may be part of one's or a peer's credentials, and Nicolas> therefore authenticated. This is covered later. Nicolas> - section 4.3, another possibility is that Nicolas> gss_export_name() for such mechanisms returns different, Nicolas> unique, results on each invocation, even if for the same Nicolas> name, and that the exported name tokens may either not be Nicolas> importable or, if imported, do not compare as equal to Nicolas> the original name object. True. Nicolas> - section 5, GSS-API applications do not have access to Nicolas> peers' credential handles, which outright rules out the Nicolas> use of credential extensions for extending GSS-API Nicolas> authorization beyond name-based authorization, unless Nicolas> credential extensions are paired with context extensions, Nicolas> which section 6 hints at. Personally, name attributes Nicolas> are a simpler, and cleaner design than paired credential Nicolas> and security context extensions. the intent was for context extensions as well. Nicolas> Credential extensions may be useful for other Nicolas> purposes, as you point out, which too, I think, makes Nicolas> name attributes a cleaner design, as it keeps separate Nicolas> things separate. Think of a credential extension for Nicolas> specifying whether a a delegated credential should in Nicolas> turn be delegatable -- such an extension has not business Nicolas> being like a name attribute. I agree with you but the draft is intended to be general. Nicolas> - section 6, this section should probably be merged with Nicolas> section 5. See above. Nicolas> - We may want some examples indicating how applications Nicolas> are expected to use these facilities. Or we may want to Nicolas> leave that to an actual specification. Do you see merging these as a requirement? Personally I like the current organization. Nicolas> - section 7, I don't understand this text. What don't you understand. Section 7 attempts to discuss the problem that today's mail to krbdev discusses in more detail. You want to choose source name based on target name. Can you suggest clarification? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 17:32:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkAe-0007J8-4W; Wed, 29 Jun 2005 17:32:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkAc-0007J3-AR for kitten@megatron.ietf.org; Wed, 29 Jun 2005 17:32:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27897 for ; Wed, 29 Jun 2005 17:32:30 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnkaC-0002DH-Cx for kitten@ietf.org; Wed, 29 Jun 2005 17:59:01 -0400 Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5TLWTGY023681 for ; Wed, 29 Jun 2005 15:32:29 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5TLWTfb026952 for ; Wed, 29 Jun 2005 15:32:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5TLWS4F023267; Wed, 29 Jun 2005 16:32:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5TLWRlQ023266; Wed, 29 Jun 2005 16:32:27 -0500 (CDT) Date: Wed, 29 Jun 2005 16:32:27 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050629213227.GO16670@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org References: <20050222234246.GP1007@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: New naming draft submitted 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 On Wed, Jun 29, 2005 at 05:24:00PM -0400, Sam Hartman wrote: > Nicolas> - section 7, I don't understand this text. Sam> What don't you understand. Section 7 attempts to discuss the Sam> problem that today's mail to krbdev discusses in more detail. You Sam> want to choose source name based on target name. Sam> Can you suggest clarification? I think I get it now. An example would be nice. Also, we've talked about an acceptor-side extension that deals with multiple credentials properly, and you've convinced me that that's a good idea. I just hadn't yet considered the utility of the same sort of extension for the initiator side, nor have I yet thought through it. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 18:03:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkeV-0002bT-JN; Wed, 29 Jun 2005 18:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkeU-0002bO-1l for kitten@megatron.ietf.org; Wed, 29 Jun 2005 18:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01296 for ; Wed, 29 Jun 2005 18:03:23 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnl46-0004bh-Pt for kitten@ietf.org; Wed, 29 Jun 2005 18:29:55 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6CA00E0063; Wed, 29 Jun 2005 18:03:26 -0400 (EDT) To: Jeffrey Altman References: <42C0844B.2030300@columbia.edu> From: Sam Hartman Date: Wed, 29 Jun 2005 18:03:26 -0400 In-Reply-To: <42C0844B.2030300@columbia.edu> (Jeffrey Altman's message of "Mon, 27 Jun 2005 18:57:15 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Kitten Subject: Re: request for agenda items 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 I'd like to have a discussion on what it would take to move 2743/2744 to draft? Would we have to respin the documents? Will we be ready to have a presentation on Nico's proposal to implement name attributes? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 18:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkoV-0005wR-Ff; Wed, 29 Jun 2005 18:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkoU-0005vE-Op for kitten@megatron.ietf.org; Wed, 29 Jun 2005 18:13:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02958 for ; Wed, 29 Jun 2005 18:13:44 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnlE4-00055v-T7 for kitten@ietf.org; Wed, 29 Jun 2005 18:40:16 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5TMDaFF021452 for ; Wed, 29 Jun 2005 15:13:36 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5TMDZfd016085 for ; Wed, 29 Jun 2005 16:13:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5TMDZ7a023324; Wed, 29 Jun 2005 17:13:35 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5TMDW0N023323; Wed, 29 Jun 2005 17:13:32 -0500 (CDT) Date: Wed, 29 Jun 2005 17:13:32 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050629221332.GQ16670@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , Kitten References: <42C0844B.2030300@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Kitten Subject: Re: request for agenda items 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 On Wed, Jun 29, 2005 at 06:03:26PM -0400, Sam Hartman wrote: > I'd like to have a discussion on what it would take to move 2743/2744 > to draft? Would we have to respin the documents? A discussion? Sure, but we'll need more folks to sign up to do the work. > Will we be ready to have a presentation on Nico's proposal to > implement name attributes? I intend to be. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 18:15:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkqD-0007EJ-3S; Wed, 29 Jun 2005 18:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnkqC-0007EE-7X for kitten@megatron.ietf.org; Wed, 29 Jun 2005 18:15:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03411 for ; Wed, 29 Jun 2005 18:15:29 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnlFp-0005KE-SA for kitten@ietf.org; Wed, 29 Jun 2005 18:42:02 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D541CE0063; Wed, 29 Jun 2005 18:15:37 -0400 (EDT) To: Jeffrey Altman References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> From: Sam Hartman Date: Wed, 29 Jun 2005 18:15:37 -0400 In-Reply-To: <20050629221332.GQ16670@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 29 Jun 2005 17:13:32 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Kitten Subject: Re: request for agenda items 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Jun 29, 2005 at 06:03:26PM -0400, Sam Hartman Nicolas> wrote: >> I'd like to have a discussion on what it would take to move >> 2743/2744 to draft? Would we have to respin the documents? Nicolas> A discussion? Sure, but we'll need more folks to sign up Nicolas> to do the work. Yes. But I'd like to understand whether it requires a respin. If the answer is yes, we may want to hold off until v3. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 18:38:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnlCs-0006iZ-04; Wed, 29 Jun 2005 18:38:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnlCq-0006iU-5j for kitten@megatron.ietf.org; Wed, 29 Jun 2005 18:38:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05921 for ; Wed, 29 Jun 2005 18:38:53 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnlcS-0006ed-UY for kitten@ietf.org; Wed, 29 Jun 2005 19:05:26 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5TMcoFF012857 for ; Wed, 29 Jun 2005 15:38:50 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5TMcnfd028530 for ; Wed, 29 Jun 2005 16:38:50 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5TMcm1N023509; Wed, 29 Jun 2005 17:38:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5TMcm53023508; Wed, 29 Jun 2005 17:38:48 -0500 (CDT) Date: Wed, 29 Jun 2005 17:38:48 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20050629223848.GS16670@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Altman , Kitten References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Kitten Subject: Re: request for agenda items 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 On Wed, Jun 29, 2005 at 06:15:37PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Jun 29, 2005 at 06:03:26PM -0400, Sam Hartman > Nicolas> wrote: > >> I'd like to have a discussion on what it would take to move > >> 2743/2744 to draft? Would we have to respin the documents? > > Nicolas> A discussion? Sure, but we'll need more folks to sign up > Nicolas> to do the work. > > Yes. But I'd like to understand whether it requires a respin. If the > answer is yes, we may want to hold off until v3. There's no RFC2119 reference or language in the base specs, which I assume would automatically block a move to Draft Standard without a respin. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jun 29 23:01:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnpJH-0000UX-5a; Wed, 29 Jun 2005 23:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnpJF-0000US-3n for kitten@megatron.ietf.org; Wed, 29 Jun 2005 23:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29655 for ; Wed, 29 Jun 2005 23:01:44 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnpir-0006RO-7Y for kitten@ietf.org; Wed, 29 Jun 2005 23:28:19 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5U31gRn003321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2005 23:01:43 -0400 (EDT) Message-ID: <42C335A1.5070903@columbia.edu> Date: Wed, 29 Jun 2005 19:58:25 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seema Malkani , Nicolas Williams References: <20050625040059.GL711@binky.Central.Sun.COM> <42BEE902.3010009@sun.com> In-Reply-To: <42BEE902.3010009@sun.com> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.7 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: kitten@ietf.org Subject: Java Bindings do not need to be removed was Re: Proposed PRF changes to address Ken's comments 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="===============1170484279==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1170484279== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050804060004010104000307" This is a cryptographically signed message in MIME format. --------------ms050804060004010104000307 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Seema Malkani wrote: > To answer Ken's question : > > Adding a new method to a standardized interface will break existing > applications. This means all classes that implement GSSContext interface > will now need to add the new method. All implementations of Java GSS > will NOT compile until the new method is added. > > Abstract classes don't have such a problem, since you can provide a > default (possibly empty) implementation, and existing implementations > will not break. It is easier to evolve an abstract class than to evolve > an interface. Since GSSContext was defined to be an interface, we cannot > change it. > > Alternatives ? > > We can possibly add the new method to GSSManager class, which is an > abstract class. This class serves as a factory for three GSS interfaces: > GSSName, GSSCredential, and GSSContext. The new method will have to be > invoked after the GSSContext has been established. > > GSSManager class: > public byte[] prf(GSSContext context, int prf_key, byte[] inBuf, int > outlen) > throws GSSException > > GSSManager mgr = GSSManager.getInstance(); > GSSName targetName = mgt.createName("service@host", ..); > GSSContext context = mgr.createContext(targetName, ..); > .. > if (context.isEstablished()) { > // define PRF key, input.. > int prf_key = .. > .. > byte[] prf_out = mgr.prf(context, prf_key, inBuf, outlen); > } > > Seema I have given this subject much consideration. I believe that the issues relating to Java and C# are no different than the issues related to the C binding. What this document does is specify an "implementation specific extension" to GSS API version 2 update 1. As such, it is not going to be possible for a given application to be able to expect that this functionality exists without some implementation specific knowledge that it is there. Simply knowing that we are using GSS API will not be enough. I do not believe it is appropriate for this document (or any other document specifying an extension to GSSAPI v2 u1 that Kitten publishes before GSSAPI v3) to describe the tools necessary for a caller to determine whether or not the function/method is implemented by a given implementation. The mistake that the document makes is by specifying that the method belongs to the "GSSContext" interface. It is perfectly reasonable for a Java class that implements the GSSContext interface to provide the prf() method even if it is not part of the GSSContext interface. An application that expects to use the prf() prior to the availability of a GSSv3Context interface will need to obtain the GSSContext reference, use introspection on the resulting class to search for the method, and if it is found, use a class reference to access the method. I believe that adding this method to the GSSManager class would violate the abstraction model. prf is the first of many extensions this working group will be proposing. Continuously adding new methods to GSSManager would result in a class definition that is constantly in a state of flux without providing any real benefit. Jeffrey Altman --------------ms050804060004010104000307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjI5MjM1ODI1WjAjBgkqhkiG9w0BCQQxFgQUF60MEMt+ig9xwxX+sEM35t1wOx8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEARrGZqyhJ+8THFWhuWBsn7xClTPLWDm1S0V//z9Tu C8GqHa2ON2f2YhJIphQ6MbXC0w/Clgoe9xpJSuloJy2Sc+0O7PvDGpsY4rEFmL+7XP7ebnEC QW7mst3O2aLHMZLUYZ7T2ASt48lGPF0YOGICW9XE5GOD4ra90hGcccwYP6Wu2x+scGOFf2HM Rsg3Fbrl1MNpmMam9QrCxeKeKPfsl1VCqFl772BDkkGr+nPjwbT3jd3ZacbLqM2Bdr6c6xje ruI8BwRdEpxlGx2t5/HrsPu07WgXksprPZJhQq43KUS0H6bH8U4Udpz670+m8NSt0jMTQaD6 L86Zg3A55d2i4QAAAAAAAA== --------------ms050804060004010104000307-- --===============1170484279== 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 --===============1170484279==-- From kitten-bounces@lists.ietf.org Thu Jun 30 00:16:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnqTC-0006u7-KL; Thu, 30 Jun 2005 00:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnqTB-0006u1-3P for kitten@megatron.ietf.org; Thu, 30 Jun 2005 00:16:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04934 for ; Thu, 30 Jun 2005 00:16:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnqsr-0003k8-2W for kitten@ietf.org; Thu, 30 Jun 2005 00:42:42 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 878A9E0064; Thu, 30 Jun 2005 00:16:09 -0400 (EDT) To: Jeffrey Altman References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> From: Sam Hartman , c@mit.edu Date: Thu, 30 Jun 2005 00:16:09 -0400 In-Reply-To: <20050629223848.GS16670@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 29 Jun 2005 17:38:48 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Kitten Subject: Re: request for agenda items 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> There's no RFC2119 reference or language in the base Nicolas> specs, which I assume would automatically block a move to Nicolas> Draft Standard without a respin. Not to my knowledge. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 11:31:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do10b-0003u3-1L; Thu, 30 Jun 2005 11:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do10Z-0003tX-KP for kitten@megatron.ietf.org; Thu, 30 Jun 2005 11:31:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24570 for ; Thu, 30 Jun 2005 11:31:15 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1QG-0006fX-5W for kitten@ietf.org; Thu, 30 Jun 2005 11:57:56 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5UFVBFF000533 for ; Thu, 30 Jun 2005 08:31:11 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5UFVA3Z005046 for ; Thu, 30 Jun 2005 09:31:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5UFV6VB023869; Thu, 30 Jun 2005 10:31:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5UFV3k4023868; Thu, 30 Jun 2005 10:31:03 -0500 (CDT) Date: Thu, 30 Jun 2005 10:31:03 -0500 From: Nicolas Williams To: Sam Hartman , c@mit.edu Message-ID: <20050630153103.GW16670@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , c@mit.edu, Jeffrey Altman , Kitten References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Kitten Subject: Re: request for agenda items 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 On Thu, Jun 30, 2005 at 12:16:09AM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> There's no RFC2119 reference or language in the base > Nicolas> specs, which I assume would automatically block a move to > Nicolas> Draft Standard without a respin. > > Not to my knowledge. In that case sure. BTW, how do you interop test APIs? I mean, the GSS-API defines very little in the way of bits on the wire. Try to compile and run generic GSS-API test applications? We can test RFC1964/CFX, of course. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 11:31:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do10h-0003ww-D6; Thu, 30 Jun 2005 11:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do10g-0003wW-3D for kitten@megatron.ietf.org; Thu, 30 Jun 2005 11:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24589 for ; Thu, 30 Jun 2005 11:31:23 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1QR-0006fz-Vt for kitten@ietf.org; Thu, 30 Jun 2005 11:58:05 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5UFVNOk012927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Jun 2005 11:31:24 -0400 (EDT) Message-ID: <42C41046.9050603@columbia.edu> Date: Thu, 30 Jun 2005 11:31:18 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: Proposed IETF 63 Meeting Request 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="===============1516327195==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1516327195== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030508050307010905090105" This is a cryptographically signed message in MIME format. --------------ms030508050307010905090105 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following is the proposed meeting request I plan to submit tomorrow. Please advise if there are addition agenda items or conflicts that need to be added. Working Group: Kitten Area: Security Conflicts: SASL, KRB-WG, SECMECH, NFSV4, KINK, PKIX, SECSH, ISMS, BTNS, SAAG, SIEVE, IMAPEXT, HASH Attendance: 25 Special Requests: New Style Room, Meeting Monday to Wednesday due to limited availability of primary author Slots: 1 Length: two hours Agenda: 1. Review of Milestones 2. Work session: review of CAT and KRB-WG archives to identify specific items for use in satisfying the milestone: Jul 05 Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard 3. Work session: Name Attributes 4. Discussion: Can RFC 2743/2744 be moved to Draft without a respin? --------------ms030508050307010905090105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjMwMTUzMTE4WjAjBgkqhkiG9w0BCQQxFgQUMK56ANw4p3+npacQpxuX7H8w7pAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAIeow9IdTXmRUpnoljwZOZPIeSJaKbwsgChdec6gt zSS5lZGAa+fyyg8Kus2SmC2iYN45XgeiBAdA8uhaHJjNu0rOGE4Ss0/xPbAkEJ2v9+ONHY47 QOMbMc+6SJ6BZiPD3Z7b6OdlSUs4a6xFxkbb/TBctESNy8qF3b1/8WpMMzoVsvmeutrJ7ACz 6j1ZNve2gzOiCpKyhRTgLwAHct0EwHvYtV1cHTqsz5n6IxfE+A0H4HiKGRGR5pFJoMPvTZxQ GObjOCs5Owd6WJwos6j9sIQKt4qL4ZUZFZj/Ksp83MdoLO67LK86kWi3Pex1bSJ4edW6kOZ6 wkh4tGhfiyuz8wAAAAAAAA== --------------ms030508050307010905090105-- --===============1516327195== 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 --===============1516327195==-- From kitten-bounces@lists.ietf.org Thu Jun 30 11:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do12j-0004HB-Ki; Thu, 30 Jun 2005 11:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do12i-0004Gx-CL for kitten@megatron.ietf.org; Thu, 30 Jun 2005 11:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24689 for ; Thu, 30 Jun 2005 11:33:30 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1SV-0000DB-8N for kitten@ietf.org; Thu, 30 Jun 2005 12:00:11 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5UFXUKb013415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 11:33:31 -0400 (EDT) Message-ID: <42C410C6.1000907@columbia.edu> Date: Thu, 30 Jun 2005 11:33:26 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> <20050630153103.GW16670@binky.Central.Sun.COM> In-Reply-To: <20050630153103.GW16670@binky.Central.Sun.COM> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Kitten , Sam Hartman Subject: Re: request for agenda items 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="===============1938927097==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1938927097== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080806090405040908020407" This is a cryptographically signed message in MIME format. --------------ms080806090405040908020407 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > BTW, how do you interop test APIs? I mean, the GSS-API defines very > little in the way of bits on the wire. Try to compile and run generic > GSS-API test applications? Exactly. --------------ms080806090405040908020407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNjMwMTUzMzI2WjAjBgkqhkiG9w0BCQQxFgQUlrmPsfRT6SXWhF6qmvA0XkZYXcsw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAPIeDKihynkGbQZ2g4jJyhyfrbN+YxsA2TlS5oPq8 1ffOzZ+vn/I8mPcSQU3HbQm577FAdnDa7phTZGejDA0QHLNrtN3EUtyyXUAiZgCSjwNQrm1s g+c3NDzBud6dx5OVWcdrwLXRZY3pnneMZfgHO1KbmSE+SG6uZTnJUfpWHkWtyDYmPYtwiUtp m/q+DBlwiaFHx0AZwEtvbE596w/VOtHczb4fMP0eQGKEWhMiAQ43SgDOXN3PjSHXRuEgSZls BDVkbL+FCAfCdh75yNcsO00qGqRFG6NLiSiDIyhjkDnl3JEcis6U7xjApk/Fs213KTAP4KpM HsDCokN7nx9uMQAAAAAAAA== --------------ms080806090405040908020407-- --===============1938927097== 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 --===============1938927097==-- From kitten-bounces@lists.ietf.org Thu Jun 30 11:35:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do14h-0004uC-6b; Thu, 30 Jun 2005 11:35:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do14f-0004rt-BI for kitten@megatron.ietf.org; Thu, 30 Jun 2005 11:35:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24963 for ; Thu, 30 Jun 2005 11:35:31 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1UO-0000HR-Vd for kitten@ietf.org; Thu, 30 Jun 2005 12:02:12 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5UFZSFF003198 for ; Thu, 30 Jun 2005 08:35:28 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5UFZRfd024948 for ; Thu, 30 Jun 2005 09:35:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5UFZRCd023880; Thu, 30 Jun 2005 10:35:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5UFZRdQ023879; Thu, 30 Jun 2005 10:35:27 -0500 (CDT) Date: Thu, 30 Jun 2005 10:35:27 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050630153527.GX16670@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Kitten , Sam Hartman References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> <20050630153103.GW16670@binky.Central.Sun.COM> <42C410C6.1000907@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C410C6.1000907@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Kitten , Sam Hartman Subject: Re: request for agenda items 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 On Thu, Jun 30, 2005 at 11:33:26AM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > BTW, how do you interop test APIs? I mean, the GSS-API defines very > > little in the way of bits on the wire. Try to compile and run generic > > GSS-API test applications? > > Exactly. So we'll need to develop some, or use/extend GSSMONGER. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 11:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do17T-00067z-By; Thu, 30 Jun 2005 11:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do17S-00067u-Ea for kitten@megatron.ietf.org; Thu, 30 Jun 2005 11:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25155 for ; Thu, 30 Jun 2005 11:38:24 -0400 (EDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Do1XE-0000NN-8D for kitten@ietf.org; Thu, 30 Jun 2005 12:05:05 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa14431; 30 Jun 2005 11:37 EDT Date: Thu, 30 Jun 2005 11:37:43 -0400 From: Jeffrey Hutzelman To: Sam Hartman , c@mit.edu, Jeffrey Altman Message-ID: In-Reply-To: References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:014KIOOEoKg6ws7Ya5EyA+p3cURWNn1odNFzydFiI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Kitten Subject: Re: request for agenda items 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 On Thursday, June 30, 2005 12:16:09 AM -0400 Sam Hartman , c@mit.edu wrote: >>>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> There's no RFC2119 reference or language in the base > Nicolas> specs, which I assume would automatically block a move to > Nicolas> Draft Standard without a respin. > > Not to my knowledge. Mine either. 2119 is a nice source of terminology that everyone understands, or thinks they do, but it is entirely possible to specify a protocol (or, in this case, an API) without them. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 17:23:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do6Vi-00025U-2x; Thu, 30 Jun 2005 17:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do6Vg-00024Q-H0 for kitten@megatron.ietf.org; Thu, 30 Jun 2005 17:23:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25170 for ; Thu, 30 Jun 2005 17:23:46 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6vV-0004OM-Cs for kitten@ietf.org; Thu, 30 Jun 2005 17:50:30 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 785CFE0063; Thu, 30 Jun 2005 17:23:49 -0400 (EDT) To: Jeffrey Altman References: <42C0844B.2030300@columbia.edu> <20050629221332.GQ16670@binky.Central.Sun.COM> <20050629223848.GS16670@binky.Central.Sun.COM> <20050630153103.GW16670@binky.Central.Sun.COM> <42C410C6.1000907@columbia.edu> <20050630153527.GX16670@binky.Central.Sun.COM> From: Sam Hartman Date: Thu, 30 Jun 2005 17:23:49 -0400 In-Reply-To: <20050630153527.GX16670@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 30 Jun 2005 10:35:27 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Kitten Subject: Re: request for agenda items 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 I actually suspect Martin may well already have sufficient data to meet the interop requirements for draft standard. I don't know if he would be willing to share that data with us or whether his confidentiality agreements would allow him to do so. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 19:55:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do8sO-00061K-V4; Thu, 30 Jun 2005 19:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do8sO-00061E-Ce for kitten@megatron.ietf.org; Thu, 30 Jun 2005 19:55:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20303 for ; Thu, 30 Jun 2005 19:55:19 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do9IB-0005BP-CM for kitten@ietf.org; Thu, 30 Jun 2005 20:22:05 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5UNtIFF026975 for ; Thu, 30 Jun 2005 16:55:18 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5UNtE3Z021399 for ; Thu, 30 Jun 2005 17:55:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5UNtDGj024695; Thu, 30 Jun 2005 18:55:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5UNtC4I024694; Thu, 30 Jun 2005 18:55:12 -0500 (CDT) Date: Thu, 30 Jun 2005 18:55:12 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20050630235512.GQ16670@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , Seema Malkani , kitten@ietf.org References: <20050625040059.GL711@binky.Central.Sun.COM> <42BEE902.3010009@sun.com> <42C335A1.5070903@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42C335A1.5070903@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org, Seema Malkani Subject: Re: Java Bindings do not need to be removed was Re: Proposed PRF changes to address Ken's comments 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 On Wed, Jun 29, 2005 at 07:58:25PM -0400, Jeffrey Altman wrote: > I have given this subject much consideration. I believe that the > issues relating to Java and C# are no different than the issues related > to the C binding. What this document does is specify an > "implementation specific extension" to GSS API version 2 update 1. > As such, it is not going to be possible for a given application to be > able to expect that this functionality exists without some > implementation specific knowledge that it is there. Simply knowing that > we are using GSS API will not be enough. > > I do not believe it is appropriate for this document (or any other > document specifying an extension to GSSAPI v2 u1 that Kitten publishes > before GSSAPI v3) to describe the tools necessary for a caller to > determine whether or not the function/method is implemented by a given > implementation. The mistake that the document makes is by specifying > that the method belongs to the "GSSContext" interface. It is perfectly > reasonable for a Java class that implements the GSSContext interface to > provide the prf() method even if it is not part of the GSSContext > interface. An application that expects to use the prf() prior to the > availability of a GSSv3Context interface will need to obtain the > GSSContext reference, use introspection on the resulting class to search > for the method, and if it is found, use a class reference to access the > method. > > I believe that adding this method to the GSSManager class would violate > the abstraction model. prf is the first of many extensions this working > group will be proposing. Continuously adding new methods to GSSManager > would result in a class definition that is constantly in a state of flux > without providing any real benefit. I agree. Thanks. I'll make the necessary edits and resubmit. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 23:02:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBnd-0005M6-EB; Thu, 30 Jun 2005 23:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBnc-0005M1-Bg for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:02:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03264 for ; Thu, 30 Jun 2005 23:02:37 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCDU-0008Dj-3O for kitten@ietf.org; Thu, 30 Jun 2005 23:29:25 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:01:20 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:01:20 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:01:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:01:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2005 20:01:18 -0700 Message-ID: Thread-Topic: Proposed PRF changes to address Ken's comments Thread-Index: AcV7TZBo8NxKBGgxQV+ossPhwxkh9gCmv+Yg From: "Liqiang\(Larry\) Zhu" To: "Jeffrey Altman" , "Nicolas Williams" X-OriginalArrivalTime: 01 Jul 2005 03:01:18.0681 (UTC) FILETIME=[271A3C90:01C57DE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: RE: Proposed PRF changes to address Ken's comments 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 I want to speak a bit for C#, the C# interface supports inheritance (I think Java interface does too), thus you can expose this new PRF in a subtype of the v1 interface.=20 That said I am not quite convinced abstract class is superior, as some might have claimed, than the interface. The advantage of abstract class is that you can supply a default implementation. I am not sure it is possible to supply a default PRF implementation. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Jeffrey Altman Sent: Monday, June 27, 2005 12:24 PM To: Nicolas Williams Cc: kitten@ietf.org Subject: Re: Proposed PRF changes to address Ken's comments Nicolas Williams wrote: > I propose removing the Java bindings from the PRF I-D and resolving this > problem separately. No, I don't like this proposal, but it's either > that or wait to resolve the Java bindings extensibility issue first. >=20 > Nico Can someone speak to the question of whether or not C# is going to have similar issues? Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 23:08:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBtR-00070p-I3; Thu, 30 Jun 2005 23:08:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBtQ-000709-Dn for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:08:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03678 for ; Thu, 30 Jun 2005 23:08:37 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCJG-0008LM-Ov for kitten@ietf.org; Thu, 30 Jun 2005 23:35:25 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6138X1G008955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 23:08:34 -0400 (EDT) Message-ID: <42C4B387.2040008@columbia.edu> Date: Thu, 30 Jun 2005 23:07:51 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: kitten@ietf.org, Nicolas Williams Subject: Re: Proposed PRF changes to address Ken's comments 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="===============1498259228==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1498259228== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060308060602040505030608" This is a cryptographically signed message in MIME format. --------------ms060308060602040505030608 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Larry: In Java, "classes" support inheritance, "interfaces" do not. As I pointed out in my e-mail from last night. There is nothing that prevents a class that implements the GSSContext interface from also implementing this new method. However, before the method can be used the reference of type GSSContext must be replaced with a reference type that includes the new method. Jeffrey Altman Liqiang(Larry) Zhu wrote: > I want to speak a bit for C#, the C# interface supports inheritance (I > think Java interface does too), thus you can expose this new PRF in a > subtype of the v1 interface. > > That said I am not quite convinced abstract class is superior, as some > might have claimed, than the interface. The advantage of abstract class > is that you can supply a default implementation. I am not sure it is > possible to supply a default PRF implementation. > > -- Larry > > -----Original Message----- > From: kitten-bounces@lists.ietf.org > [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Jeffrey Altman > Sent: Monday, June 27, 2005 12:24 PM > To: Nicolas Williams > Cc: kitten@ietf.org > Subject: Re: Proposed PRF changes to address Ken's comments > > Nicolas Williams wrote: > > >>I propose removing the Java bindings from the PRF I-D and resolving > > this > >>problem separately. No, I don't like this proposal, but it's either >>that or wait to resolve the Java bindings extensibility issue first. >> >>Nico > > > Can someone speak to the question of whether or not C# is going to have > similar issues? > > Jeffrey Altman --------------ms060308060602040505030608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNzAxMDMwNzUxWjAjBgkqhkiG9w0BCQQxFgQUHFH+jU3gkVVKr2V09rJ8DDE1Qxcw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEALMakQVnScTNCu0yVmwfb4NnSwpkA9lJbE0XkprPB q0xW7wwFAkvSPT2Bxp2GbryzeJkqaFngnnNiGptpzDeddkF8yjSXKx+yBau7upZ3gAspGHp5 JB512MSF3krm93aSjhsWIepUmGmd/uWPCK1Lpzdg6rk1QYBg/sXPxy7lLi+3r/0bMNnjmLyx nvpTt/oESvOlQxfqOzRFut/guXHgtixqvdA2jn7ypVACWAA/C86e7zt7vToWa77vErpHgP9L XwQibyibcj+EJuv+i7KqHqs8bAG/H3r0oqWyLP29TeKEfSP//smxuYPvIjYkftKY556m7rzc NSpyu5Pr5u7IdQAAAAAAAA== --------------ms060308060602040505030608-- --===============1498259228== 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 --===============1498259228==-- From kitten-bounces@lists.ietf.org Thu Jun 30 23:10:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBvL-0007Xg-I6; Thu, 30 Jun 2005 23:10:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBvK-0007Xb-Fn for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:10:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03915 for ; Thu, 30 Jun 2005 23:10:35 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCLD-0008Pv-3E for kitten@ietf.org; Thu, 30 Jun 2005 23:37:23 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:10:28 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:10:28 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:10:27 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 20:10:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2005 20:10:27 -0700 Message-ID: Thread-Topic: CIFS and the krb5 PRF Thread-Index: AcV7BGqtuOsRb5t1SY2LcMNHK8jmvwC5YAtA From: "Liqiang\(Larry\) Zhu" To: "Andrew Bartlett" , "Jeffrey Altman" X-OriginalArrivalTime: 01 Jul 2005 03:10:27.0085 (UTC) FILETIME=[6DFA0BD0:01C57DEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Sam Hartman Subject: RE: CIFS and the krb5 PRF 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 What about adding a flag argument to GSS_Pseudo_random(), thus we can allow implementations to *optionally* expose the raw session key via the PRF. I am saying so assuming folks genuinely need to support a way to interop with existing applications that expose the direct Kerberos key today, Kerb-TLS, to think of it, is one of them. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Andrew Bartlett Sent: Monday, June 27, 2005 3:37 AM To: Jeffrey Altman Cc: kitten@ietf.org; Sam Hartman Subject: Re: CIFS and the krb5 PRF On Mon, 2005-06-27 at 05:27 -0400, Jeffrey Altman wrote:=20 > Andrew Bartlett wrote: >=20 > > Given the strongly held views of represented here that Samba4 (in > > particular) should not be locked into a particular Kerberos/GSSAPI > > implementation, where should I address discussion about the changes that > > Samba4 requires? > >=20 > > I have already made a number of experimental modifications to Heimdal > > kerberos (a copy of which we will ship built into Samba4 for initial > > release). While I already get some good feedback from Love, I know > > others have views. =20 > >=20 > > The 'CIFS Session key' export is just one of these required extensions - > > we also need to change the GSS_Wrap arguments to support AEAD, and > > closer control over the underlying Kerberos behaviour. > >=20 > > Andrew Bartlett >=20 > Discussions of proprietary mechanism extensions for Kerberos 5 such as > access to the Kerberos 5 ticket (or ticket parts) that you wish to be > adopted by both Heimdal and MIT Kerberos should take place on the > krbdev@mit.edu mailing list. &#-1;&#-1;=20 > > The same is true for anything other > change that would be incompatible with implementations of GSS API > version 2 update 1. >=20 > Discussions that are appropriate for the Kitten list are any changes > this working group should consider for GSS API version 3. Well, I certainly would like to see GSS API version 3 being flexible enough to provide the facilities that Samba4 requires. That would seem to be a desirable outcome. Clearly not all the things Samba4 requires, fit into that category, but I think some do. I'll continue hacking my way though GSSAPI as I move forward, let me know if you want to hear about what things I'm finding. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Samba Developer, SuSE Labs, Novell Inc. http://suse.de Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 23:23:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoC8D-0003LO-Rs; Thu, 30 Jun 2005 23:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoC8B-0003LJ-UM for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:23:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04778 for ; Thu, 30 Jun 2005 23:23:53 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCY0-0000EP-W4 for kitten@ietf.org; Thu, 30 Jun 2005 23:50:41 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j613NoKg005494 for ; Thu, 30 Jun 2005 20:23:50 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j613Nn3Z024565 for ; Thu, 30 Jun 2005 21:23:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j613NnH9024910; Thu, 30 Jun 2005 22:23:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j613NkNI024909; Thu, 30 Jun 2005 22:23:46 -0500 (CDT) Date: Thu, 30 Jun 2005 22:23:46 -0500 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20050701032345.GW16670@binky.Central.Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , Andrew Bartlett , Jeffrey Altman , kitten@ietf.org, Sam Hartman References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: kitten@ietf.org, Sam Hartman Subject: Re: CIFS and the krb5 PRF 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 On Thu, Jun 30, 2005 at 08:10:27PM -0700, Liqiang(Larry) Zhu wrote: > > What about adding a flag argument to GSS_Pseudo_random(), thus we can > allow implementations to *optionally* expose the raw session key via the > PRF. I am saying so assuming folks genuinely need to support a way to > interop with existing applications that expose the direct Kerberos key > today, Kerb-TLS, to think of it, is one of them. We've discussed this before I think, and we concluded that a difference function should be used for that. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 30 23:27:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCBH-0004MV-T0; Thu, 30 Jun 2005 23:27:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCBG-0004MQ-6Z for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:27:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05112 for ; Thu, 30 Jun 2005 23:27:03 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCb8-0000Jb-8m for kitten@ietf.org; Thu, 30 Jun 2005 23:53:51 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j613R1kb008907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 23:27:01 -0400 (EDT) Message-ID: <42C4B7D8.2050009@columbia.edu> Date: Thu, 30 Jun 2005 23:26:16 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: kitten@ietf.org, Sam Hartman Subject: Re: CIFS and the krb5 PRF 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="===============1376537159==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1376537159== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010500020509040902010906" This is a cryptographically signed message in MIME format. --------------ms010500020509040902010906 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The raw session key has very different properties than the output of GSS_Pseudo_random(). We all agree that there is a need for implementations of the krb5 mechanism to be able to expose the raw components of the ticket. The components that applications need access to are no limited to the session key. That is the reason the MIT implementation is going to provide a implementation specific extension to access all of the components of the ticket associated with the GSS Context. Let's not try to mix apples and oranges. As for RFC 2712 (Kerberos Ciphers for TLS), this protocol does not use GSS. It would therefore provide no benefit to add this functionality. What we do need to do is scrap RFC 2712 and replace it with something either based on GSS or at least something that makes use of the KCrypto PRF. That discussion is not within the bounds of the Kitten charter. Jeffrey Altman Liqiang(Larry) Zhu wrote: > What about adding a flag argument to GSS_Pseudo_random(), thus we can > allow implementations to *optionally* expose the raw session key via the > PRF. I am saying so assuming folks genuinely need to support a way to > interop with existing applications that expose the direct Kerberos key > today, Kerb-TLS, to think of it, is one of them. > > -- Larry --------------ms010500020509040902010906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNzAxMDMyNjE2WjAjBgkqhkiG9w0BCQQxFgQUR/9jY1fZhDHXhsM9WL8mViOz2Y8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAgOI47xibsdVpjIb1MHLXb5dOscuhYQGTk18jtVXL ws01Uer4FpC9BKdexxskgT0RFoVOGJ0tkegcjEVkraMkIBR+eTl3s2rVwqQBwd9lj0anOHNh 5QjtflTkdgx8kp/M8Jhfw8eNTIaRJz8ag/wZJrou8k3fYx2bRirXPXdZUzG/vgGj03EQYXPw HyXcUotvwFylS+fWSWhq6AiNNlz0f+U1mnBSw2SNn4wLDpMvcsUQNW1ANhKoB8FPwiu1w7zk XvZRQvbkKivVbxB9ULLk9kIH9bH4Wq4YrpoUyGOlrZFKfq30fvglsqvjqHJV7IlszEoU6WK1 Pm9A6Rff1TEqRQAAAAAAAA== --------------ms010500020509040902010906-- --===============1376537159== 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 --===============1376537159==-- From kitten-bounces@lists.ietf.org Thu Jun 30 23:32:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCGM-0005pl-Qc; Thu, 30 Jun 2005 23:32:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCGL-0005pg-4t for kitten@megatron.ietf.org; Thu, 30 Jun 2005 23:32:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05480 for ; Thu, 30 Jun 2005 23:32:18 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCgC-0000QA-5U for kitten@ietf.org; Thu, 30 Jun 2005 23:59:06 -0400 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j613WGwH010805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 23:32:17 -0400 (EDT) Message-ID: <42C4B912.7060508@columbia.edu> Date: Thu, 30 Jun 2005 23:31:30 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kitten , Kerberos WG References: <42AF4B19.5040202@columbia.edu> In-Reply-To: <42AF4B19.5040202@columbia.edu> X-Enigmail-Version: 0.91.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: WGLC Results 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="===============1735532262==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1735532262== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080102040008030203080601" This is a cryptographically signed message in MIME format. --------------ms080102040008030203080601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The WGLC for these documents ended on Wednesday. The PRF for the Kerberos V GSS-API Mechanism draft has passed last call. The PRF API extension for the GSS-API draft did not. Nico will submit an updated draft for the PRF API extension and at that time I will issue a one week WGLC on the changes. I plan to submit both of these documents to the IESG once the PRF API draft passes a WGLC. Jeffrey Altman Jeffrey Altman wrote: > A two week working group last call is issued for the following Kitten > Working Group internet drafts: > > Title : A PRF API extension for the GSS-API > Author(s) : N. Williams > Filename : draft-ietf-kitten-gssapi-prf-04.txt > Pages : 9 > Date : 2005-6-14 > > This document defines a Pseudo-Random Function (PRF) extension to the > Generic Security Service Application Programming Interface (GSS-API) > for keying application protocols given an established GSS-API > security context. The primary intended use of this function is to > key secure session layers that don't or cannot use GSS-API per- > message MIC (message integrity check) and wrap tokens for session > protection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-04.txt > > Title : A PRF for the Kerberos V GSS-API Mechanism > Author(s) : N. Williams > Filename : draft-ietf-kitten-krb5-gssapi-prf-04.txt > Pages : 6 > Date : 2005-6-14 > > This document defines the Pseudo-Random Function (PRF) for the > Kerberos V mechanism for the Generic Security Service Application > Programming Interface (GSS-API), based on the PRF defined for the > Kerberos V cryptographic framework, for keying application protocols > given an established Kerberos V GSS-API security context. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-04.txt > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms080102040008030203080601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwNzAxMDMzMTMwWjAjBgkqhkiG9w0BCQQxFgQU9QhO70QkaB933ZTKxy4c7BVdIhIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAB7kjFzu32K0QlApPcbPJt884sssWMf6I6xtOKtIb YLhTZ+h13lVh3kP10qI1clqxAVYdcHO26tYcl07athCAbdlFxjdcMX2Qj+Z9W2khwUSYgJpw 11pHVRq9h4v+qYvo6N/qyHmDRw58tp7J9XkAQodD3UsQpiC88WQi+RMZC6/FqndHjp4YFV0E /gQ1RpMe6FPgD74QSL36vF75Lb39/vKbgPno2syFQLYar4JgTXhfCoq/8HRFe7jfEkKZr/mX 08QOd1eYdTvo2CJACsyQl2JgbreYdPsndqACEX2wjy3cY57Z5X0FFd7lXBK3AJwtqgbNqc5U 2X/vVrQLAW71eAAAAAAAAA== --------------ms080102040008030203080601-- --===============1735532262== 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 --===============1735532262==--