From kitten-bounces@ietf.org Wed Feb 2 10:47:28 2005 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 KAA19186; Wed, 2 Feb 2005 10:47:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN1U-00033T-Hg; Wed, 02 Feb 2005 11:06:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMgl-0007vQ-U7; Wed, 02 Feb 2005 10:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMYn-00064B-Lp for kitten@megatron.ietf.org; Wed, 02 Feb 2005 10:36:53 -0500 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 KAA17957 for ; Wed, 2 Feb 2005 10:36:49 -0500 (EST) Received: from smtpsrv12.isis.unc.edu ([152.2.1.243] helo=smtp.unc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMr8-0002hn-DB for kitten@ietf.org; Wed, 02 Feb 2005 10:55:54 -0500 Received: from [192.168.2.2] ([66.57.250.13]) (authenticated bits=0) by smtp.unc.edu (8.12.9/8.12.9) with ESMTP id j12FaVE4025586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 2 Feb 2005 10:36:31 -0500 (EST) Message-ID: <4200F3AA.9070900@unc.edu> Date: Wed, 02 Feb 2005 10:37:14 -0500 From: Simon Spero User-Agent: Mozilla Thunderbird 1.0RC1 (Macintosh/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <200501242039.PAA21383@ietf.org> In-Reply-To: <200501242039.PAA21383@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Subject: reqFlags - ASN.1 comment out of sync with text (was Re: I-D ACTION:draft-ietf-kitten-2478bis-05.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit BTW, is there any reason why the initiator side is just 'SHOULD'? Are there any valid reasons for a new implementation to include this? Text : reqFlags This field, if present, contains the service options that are requested to establish the context (the req_flags parameter of GSS_Init_sec_context()). This field is inherited from RFC 2478 and it is not integrity protected. For implementations of this specification the initiator SHOULD omit this reqFlags field, and the acceptor MUST ignore this reqFlags field. ASN.1: ... reqFlags [1] ContextFlags OPTIONAL, -- inherited from RFC 2478 for backward compatibility, -- RECOMMENDED to be left out ... --------------- Fix: reqFlags [1] ContextFlags OPTIONAL -- inherited from RFC 2478 for backward compatibility -- initiator SHOULD omit -- acceptor MUST ignore _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Feb 2 16:14:32 2005 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 QAA03152; Wed, 2 Feb 2005 16:14:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwS84-0007Jw-0J; Wed, 02 Feb 2005 16:33:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRL6-0000Uy-Qr; Wed, 02 Feb 2005 15:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRFA-0005Xp-Hd; Wed, 02 Feb 2005 15:36:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26294; Wed, 2 Feb 2005 15:36:52 -0500 (EST) Message-Id: <200502022036.PAA26294@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 02 Feb 2005 15:36:52 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-rfc2853bis-00.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Corrections and Updates of GSS-API Java Bindings Author(s) : S. Malkani Filename : draft-ietf-kitten-rfc2853bis-00.txt Pages : 9 Date : 2005-2-2 This document corrects and updates the specification of the Java programming language bindings of the Generic Security Services Application Programming Interface (GSS-API). Specifically, the error code values used for GSS exceptions were incorrect in the original; additionally, missing numeric values of the credential usage constants are specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-rfc2853bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-rfc2853bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-rfc2853bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-2143454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-rfc2853bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-rfc2853bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-2143454.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Wed Feb 2 17:07:33 2005 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 RAA14700; Wed, 2 Feb 2005 17:07:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSxN-0002yb-C5; Wed, 02 Feb 2005 17:26:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSGx-0007AC-0j; Wed, 02 Feb 2005 16:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwS5W-0005Aq-N2 for kitten@megatron.ietf.org; Wed, 02 Feb 2005 16:31:02 -0500 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 QAA07868 for ; Wed, 2 Feb 2005 16:30:58 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSNw-0000Wy-VB for kitten@ietf.org; Wed, 02 Feb 2005 16:50:06 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 13:30:30 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 2 Feb 2005 13:30:29 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 13:30:51 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 2 Feb 2005 13:30:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2005 13:30:27 -0800 Message-ID: Thread-Topic: reqFlags - ASN.1 comment out of sync with text (was Re: I-DACTION:draft-ietf-kitten-2478bis-05.txt) Thread-Index: AcUJPpWFD3SCLmXgTD2/E1n51carBgAL1//g From: "Liqiang\(Larry\) Zhu" To: "Simon Spero" , X-OriginalArrivalTime: 02 Feb 2005 21:30:28.0670 (UTC) FILETIME=[6A6FEDE0:01C5096E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Subject: RE: reqFlags - ASN.1 comment out of sync with text (was Re: I-DACTION:draft-ietf-kitten-2478bis-05.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable I see it as being consistent: "RECOMMENDED" =3D=3D "SHOULD". > is there any reason why the initiator side is just 'SHOULD'? This should be fine too as long as the acceptor ignores it. -- Larry -----Original Message----- From: kitten-bounces@lists.ietf.org [mailto:kitten-bounces@lists.ietf.org] On Behalf Of Simon Spero Sent: Wednesday, February 02, 2005 7:37 AM To: kitten@ietf.org Subject: reqFlags - ASN.1 comment out of sync with text (was Re: I-DACTION:draft-ietf-kitten-2478bis-05.txt) BTW, is there any reason why the initiator side is just 'SHOULD'? Are there any valid reasons for a new implementation to include this? Text : reqFlags This field, if present, contains the service options that are requested to establish the context (the req_flags parameter of GSS_Init_sec_context()). This field is inherited from RFC 2478 and it is not integrity protected. For implementations of this specification the initiator SHOULD omit this reqFlags field, and the acceptor MUST ignore this reqFlags field. ASN.1: ... reqFlags [1] ContextFlags OPTIONAL, -- inherited from RFC 2478 for backward compatibility, -- RECOMMENDED to be left out ... --------------- Fix: reqFlags [1] ContextFlags OPTIONAL -- inherited from RFC 2478 for backward compatibility -- initiator SHOULD omit -- acceptor MUST ignore =09 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Feb 2 18:02:37 2005 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 SAA22853; Wed, 2 Feb 2005 18:02:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTog-0005lz-Ix; Wed, 02 Feb 2005 18:21:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTO6-0007z4-Mp; Wed, 02 Feb 2005 17:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTLG-0006qy-7V for kitten@megatron.ietf.org; Wed, 02 Feb 2005 17:51:22 -0500 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 RAA21815 for ; Wed, 2 Feb 2005 17:51:14 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTdd-0005O1-TN for kitten@ietf.org; Wed, 02 Feb 2005 18:10:23 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA11400; Wed, 2 Feb 2005 23:50:24 +0100 (MEZ) From: Martin Rex Message-Id: <200502022250.XAA01963@uw1048.wdf.sap.corp> To: ses@unc.edu (Simon Spero) Date: Wed, 2 Feb 2005 23:50:23 +0100 (MET) In-Reply-To: <4200F3AA.9070900@unc.edu> from "Simon Spero" at Feb 2, 5 10:37:14 am 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: reqFlags - ASN.1 comment out of sync with text (was Re: I-D 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 8bit Simon Spero wrote: > > BTW, is there any reason why the initiator side is just 'SHOULD'? Are > there any valid reasons for a new implementation to include this? Actually, the "acceptor MUST ignore" is inappropriate procedurally, it ought to be a SHOULD. If there was a feature in a predecessor spec on the standards track, then the revision of the spec may deprecate that feature and discourage it use, but it should not outlaw its use entirely (except maybe for exceptional cases, but that doesn't apply here). -Martin > > Text : > reqFlags > > This field, if present, contains the service options that are > requested to establish the context (the req_flags parameter of > GSS_Init_sec_context()). This field is inherited from RFC 2478 > and it is not integrity protected. For implementations of this > specification the initiator SHOULD omit this reqFlags field, > and the acceptor MUST ignore this reqFlags field. > > > ASN.1: > ... > reqFlags [1] ContextFlags OPTIONAL, > -- inherited from RFC 2478 for backward compatibility, > -- RECOMMENDED to be left out > ... > --------------- > Fix: > > reqFlags [1] ContextFlags OPTIONAL > -- inherited from RFC 2478 for backward compatibility > -- initiator SHOULD omit > -- acceptor MUST ignore _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Feb 3 13:07:37 2005 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 NAA21717; Thu, 3 Feb 2005 13:07:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwlgs-0007BL-Uv; Thu, 03 Feb 2005 13:26:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwlJM-00074X-Up; Thu, 03 Feb 2005 13:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwlC6-0004B8-1D for kitten@megatron.ietf.org; Thu, 03 Feb 2005 12:55:06 -0500 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 MAA20456 for ; Thu, 3 Feb 2005 12:55:02 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwlUh-0006nC-Bp for kitten@ietf.org; Thu, 03 Feb 2005 13:14:19 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13Ht3Vu022719 for ; Thu, 3 Feb 2005 10:55:03 -0700 (MST) 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 j13Ht3aa006024 for ; Thu, 3 Feb 2005 10:55:03 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j13HrcZV445626; Thu, 3 Feb 2005 11:53:38 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.1+Sun/8.13.1/Submit) id j13HrbrV445625; Thu, 3 Feb 2005 11:53:37 -0600 (CST) Date: Thu, 3 Feb 2005 11:53:37 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20050203175337.GU156775@binky.central.sun.com> Mail-Followup-To: Martin Rex , Simon Spero , kitten@ietf.org References: <4200F3AA.9070900@unc.edu> <200502022250.XAA01963@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502022250.XAA01963@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: kitten@ietf.org Subject: Re: reqFlags - ASN.1 comment out of sync with text (was Re: I-D 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Wed, Feb 02, 2005 at 11:50:23PM +0100, Martin Rex wrote: > Actually, the "acceptor MUST ignore" is inappropriate procedurally, > it ought to be a SHOULD. > > If there was a feature in a predecessor spec on the standards track, > then the revision of the spec may deprecate that feature and > discourage it use, but it should not outlaw its use entirely > (except maybe for exceptional cases, but that doesn't apply here). There was nothing (see below) that an acceptor could have done with that field, so deprecating it is entirely appropriate. RFC2478 said nothing about what an acceptor should or could do with reqFlags nor is there an obvious handling for that field in the context of the GSS-API (GSS_Accept_sec_context() lacks a flags input parameter). (But see below.) And there's probably no obvious acceptor disposition for that field for acceptors implemented using non-GSS interfaces (e.g., the SSPI) to GSS mechanisms. Sure, an acceptor might compare reqFlags to ret_flags from GSS_Accept_sec_context() and return an error if the context did not provide some feature requested by the initiatior. But rfc2478 is quite silent on this matter and provides no suitable major/minor status code to return in such situations. And such behaviour might be rather surprising -- and unnecessary to boot since both peers get a ret_flags out of the mech context (it would as surprising if a mechanism produced different ret_flags for the two peers of a context; I don't recall if such behaviour is allowed by RFC2743, but in any case, the application would no doubt notice). What conclusion can we reach other than that either the spec was incomplete with regards to reqFlags or that reqFlags was a bug in the spec, such that we can now deprecate it safely? If there is some desirable acceptor handling of reqFlags other than ignoring it (is there?) we could specifiy that instead of deprecating that field. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Fri Feb 4 12:29:39 2005 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 MAA17330; Fri, 4 Feb 2005 12:29:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7Zq-0007In-71; Fri, 04 Feb 2005 12:49:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7Fb-0005oq-7T; Fri, 04 Feb 2005 12:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7CI-0005UH-Eo for kitten@megatron.ietf.org; Fri, 04 Feb 2005 12:24:47 -0500 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 MAA16555 for ; Fri, 4 Feb 2005 12:24:43 -0500 (EST) Received: from stratton-two-fifty-eight.mit.edu ([18.187.6.3] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7V6-000775-2Y for kitten@ietf.org; Fri, 04 Feb 2005 12:44:13 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 6AFF4E0077; Fri, 4 Feb 2005 12:24:37 -0500 (EST) To: martin.rex@sap.com References: <200502022250.XAA01963@uw1048.wdf.sap.corp> From: Sam Hartman Date: Fri, 04 Feb 2005 12:24:37 -0500 In-Reply-To: <200502022250.XAA01963@uw1048.wdf.sap.corp> (Martin Rex's message of "Wed, 2 Feb 2005 23:50:23 +0100 (MET)") 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: reqFlags - ASN.1 comment out of sync with text (was Re: I-D 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >>>>> "Martin" == Martin Rex writes: Martin> Simon Spero wrote: >> BTW, is there any reason why the initiator side is just >> 'SHOULD'? Are there any valid reasons for a new implementation >> to include this? Martin> Actually, the "acceptor MUST ignore" is inappropriate Martin> procedurally, it ought to be a SHOULD. Martin> If there was a feature in a predecessor spec on the Martin> standards track, then the revision of the spec may Martin> deprecate that feature and discourage it use, but it Martin> should not outlaw its use entirely (except maybe for Martin> exceptional cases, but that doesn't apply here). One of the common cases where this is appropriate is when a security problem is discovered. "Foo should have been integrity protected and is not," is an example of such a case. As such I think a MUST is entirely appropriate from a procedural standpoint. A SHOULd is also OK from a procedural standpoint. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Feb 15 13:34:40 2005 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 NAA11111; Tue, 15 Feb 2005 13:34:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17s7-0000s3-9x; Tue, 15 Feb 2005 13:56:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15LV-0006GP-Rp; Tue, 15 Feb 2005 11:14:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14hY-0002ND-9g; Tue, 15 Feb 2005 10:33:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14083; Tue, 15 Feb 2005 10:33:22 -0500 (EST) Message-Id: <200502151533.KAA14083@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, 15 Feb 2005 10:33:21 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-prf-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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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-02.txt Pages : 9 Date : 2005-2-14 This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Applicatoin 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-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-gssapi-prf-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-gssapi-prf-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-2-15103754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-prf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-prf-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103754.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Tue Feb 15 13:37:51 2005 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 NAA12211; Tue, 15 Feb 2005 13:37:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17vC-00019w-CD; Tue, 15 Feb 2005 13:59:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15Ld-0006QG-4N; Tue, 15 Feb 2005 11:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14hh-0002Vc-5T; Tue, 15 Feb 2005 10:33:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14139; Tue, 15 Feb 2005 10:33:31 -0500 (EST) Message-Id: <200502151533.KAA14139@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, 15 Feb 2005 10:33:31 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-v3-guide-to-00.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Guide to the GSS-APIv3 Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-v3-guide-to-00.txt Pages : 20 Date : 2005-2-14 Extensions to the GSS-APIv2 are needed for a number of reasons. This documents describes the extensions being proposed, the resons, possible future directions, and portability, IANA and security considerations. This document does not define any protocol or interface and is purely informational. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-v3-guide-to-00.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-v3-guide-to-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-v3-guide-to-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-15103800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-v3-guide-to-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-v3-guide-to-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103800.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Tue Feb 15 15:12:19 2005 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 PAA05407; Tue, 15 Feb 2005 15:12:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ob-0008H4-9s; Tue, 15 Feb 2005 15:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18ea-0000nX-W3; Tue, 15 Feb 2005 14:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D17vc-0002wb-CA for kitten@megatron.ietf.org; Tue, 15 Feb 2005 14:00:08 -0500 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 OAA19261 for ; Tue, 15 Feb 2005 14:00:06 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18Gg-0003UG-I8 for kitten@ietf.org; Tue, 15 Feb 2005 14:21:55 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1FJ04nK024117 for ; Tue, 15 Feb 2005 12:00:04 -0700 (MST) 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 j1FJ04aa019852 for ; Tue, 15 Feb 2005 12:00:04 -0700 (MST) 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 j1FIwTl1017885 for ; Tue, 15 Feb 2005 12:58:29 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j1FIwT5E017884 for kitten@ietf.org; Tue, 15 Feb 2005 12:58:29 -0600 (CST) Date: Tue, 15 Feb 2005 12:58:29 -0600 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050215185828.GA17068@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org References: <200502151533.KAA14083@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502151533.KAA14083@ietf.org> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: Re: I-D ACTION:draft-ietf-kitten-gssapi-prf-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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab BTW, the difference between -01 and -02 is that I figured out how to deal with PROT_READY and the PRF in between and -02 reflects this. I'm not sure why PROT_READY should have ever been needed, really, since an app shouldn't have to wait till the flag is set -- it could just call the per-msg token functions and they could just return an error (e.g., GSS_S_UNAVAILABLE and a minor code indicating "more context tokens need to be exchanged, so be patient, stupid"). That's the approach to PRF readiness that I used in -02. Comments? (I'm particularly interested in hearing Martin's take on this.) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Feb 15 19:38:36 2005 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 TAA05490; Tue, 15 Feb 2005 19:38:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1DYM-0007Px-Sa; Tue, 15 Feb 2005 20:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1DAx-0006bW-Je; Tue, 15 Feb 2005 19:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1D6D-00059s-6i for kitten@megatron.ietf.org; Tue, 15 Feb 2005 19:31:25 -0500 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 TAA03921 for ; Tue, 15 Feb 2005 19:31:22 -0500 (EST) Received: from stratton-five-o-five.mit.edu ([18.187.6.250] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1DRL-00072F-FO for kitten@ietf.org; Tue, 15 Feb 2005 19:53:16 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 2FB03E0063; Tue, 15 Feb 2005 19:31:37 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Tue, 15 Feb 2005 19:31: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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: People should take a look at draft-ietf-mmusic-kmgmt-ext 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 First, I'm going to try and work on the no-multi-round-trip issue. However this seems like a great application to motivate prot_ready. Also I think it would be neat if someone would do a gssapi binding for this work. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Feb 16 14:00:12 2005 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 OAA25645; Wed, 16 Feb 2005 14:00:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UkY-0002cG-QO; Wed, 16 Feb 2005 14:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Soo-0005bK-06; Wed, 16 Feb 2005 12:18:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1R1I-0004J8-SW; Wed, 16 Feb 2005 10:23:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22740; Wed, 16 Feb 2005 10:23:14 -0500 (EST) Message-Id: <200502161523.KAA22740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Feb 2005 10:23:14 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-krb5-gssapi-prf-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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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-02.txt Pages : 7 Date : 2005-2-15 This document defines the Pseudo-Random Function (PRF) for the Kerberos V GSS-API mechanism, 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-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-krb5-gssapi-prf-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-krb5-gssapi-prf-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-2-16102638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-krb5-gssapi-prf-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-krb5-gssapi-prf-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102638.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Wed Feb 16 14:01:58 2005 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 OAA26156; Wed, 16 Feb 2005 14:01:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UmH-0002mS-1Z; Wed, 16 Feb 2005 14:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Sow-0005kw-Q7; Wed, 16 Feb 2005 12:18:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1R1R-0004NC-Ec; Wed, 16 Feb 2005 10:23:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22792; Wed, 16 Feb 2005 10:23:22 -0500 (EST) Message-Id: <200502161523.KAA22792@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Feb 2005 10:23:22 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-channel-bindings-00.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Clarifications and Extensions to the GSS-API for the Use of Channel Bindings Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-channel-bindings-00.txt Pages : 14 Date : 2005-2-15 This document clarifies and generalizes the GSS-API "channel bindings" facility. This document also specifies the format of the various types of channel bindings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-00.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-channel-bindings-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-16102645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-channel-bindings-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102645.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Wed Feb 16 14:03:34 2005 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 OAA26798; Wed, 16 Feb 2005 14:03:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Unp-0002yE-Hs; Wed, 16 Feb 2005 14:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Sp1-0005pq-R6; Wed, 16 Feb 2005 12:18:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1R1c-0004Ow-Jr; Wed, 16 Feb 2005 10:23:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22824; Wed, 16 Feb 2005 10:23:34 -0500 (EST) Message-Id: <200502161523.KAA22824@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Feb 2005 10:23:33 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-store-cred-00.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : GSS-API Extension for Storing Delegated Credentials Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-store-cred-00.txt Pages : 10 Date : 2005-2-15 This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-store-cred-00.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-store-cred-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-store-cred-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-16102651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-store-cred-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-store-cred-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102651.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Wed Feb 16 14:07:15 2005 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 OAA28134; Wed, 16 Feb 2005 14:07:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UrO-0003Oe-Os; Wed, 16 Feb 2005 14:29:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Sp7-0005sc-M6; Wed, 16 Feb 2005 12:18:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1R1m-0004R8-IA; Wed, 16 Feb 2005 10:23:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22885; Wed, 16 Feb 2005 10:23:44 -0500 (EST) Message-Id: <200502161523.KAA22885@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Feb 2005 10:23:43 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gssapi-extensions-iana-00.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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Namespace Considerations and Registries for GSS-API Extensions Author(s) : N. Williams Filename : draft-ietf-kitten-gssapi-extensions-iana-00.txt Pages : 7 Date : 2005-2-15 This document describes the ways in which the GSS-API may be extended and directs the creation of IANA registries for various GSS-API namespaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-extensions-iana-00.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-extensions-iana-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gssapi-extensions-iana-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-16102656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gssapi-extensions-iana-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-extensions-iana-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-16102656.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Sun Feb 20 18:05:47 2005 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 SAA19816; Sun, 20 Feb 2005 18:05:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D30VH-00048f-9c; Sun, 20 Feb 2005 18:28:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2zFW-0004gl-6P; Sun, 20 Feb 2005 17:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ygg-00050j-N8 for kitten@megatron.ietf.org; Sun, 20 Feb 2005 16:32:23 -0500 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 QAA12718 for ; Sun, 20 Feb 2005 16:32:15 -0500 (EST) Received: from stratton-three-seventy-nine.mit.edu ([18.187.6.124] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2z2k-0001y9-7Y for kitten@ietf.org; Sun, 20 Feb 2005 16:55:11 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id E0C16E0063; Sun, 20 Feb 2005 16:42:40 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Sun, 20 Feb 2005 16:42:40 -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: bb8f917bb6b8da28fc948aeffb74aa17 Subject: 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b I've submitted draft-ietf-kitten-gss-naming-01.txt. I think this one is readyish for last-call, but would like to ask Nico and Martin to review it and tell me what's broken and then consider the next revision for a real last call. I believe I've addressed Nico's comments this time around. I've also pulled in some information from the discussion of SPKM and naming. The one thing I haven't touched is text on mechanisms that respond/assert to multiple names. I think I convinced Nico that in the normal v3 case we didn't want that behavior unless you were limiting a credential in some way. However I thing there was still some question about how the ability to assert multiple names might work for v2 mechanisms/applications. In any solution to this problem we need to keep Martin's comments about v2 names and how they interact with credentials in mind. In particular, you can have a single cert/ticket/something that can generate different gssapi credentials depending on what name you use to acquire credentials. You cannot have more than one credential for the same mechanism as part of a gssapi credential. Also, once you have a v2 gssapi credential, the name you get back from enquiring that credential must be the same as the name you would get from enquiring a context established with that credential. For v3, it's not clear clear to what extent this shows up as multiple GSSAPI credentials for the same underlying cert/ticket that are selected by the name you acquire or whether there is more mechanism involved. Does there need to be text about this in the draft? If so, where and roughly what? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Feb 23 16:22:41 2005 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 QAA19090; Wed, 23 Feb 2005 16:22:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D44Km-0002IN-4X; Wed, 23 Feb 2005 16:46:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjR-0005Oq-Qj; Tue, 22 Feb 2005 19:50:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hBk-00011X-3u; Tue, 22 Feb 2005 16:03:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20892; Tue, 22 Feb 2005 16:03:21 -0500 (EST) Message-Id: <200502222103.QAA20892@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, 22 Feb 2005 16:03:21 -0500 Cc: kitten@ietf.org Subject: I-D ACTION:draft-ietf-kitten-gss-naming-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --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-01.txt Pages : 13 Date : 2005-2-22 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gss-naming-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gss-naming-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gss-naming-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gss-naming-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160430.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --NextPart-- From kitten-bounces@ietf.org Thu Feb 24 01:55:47 2005 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 BAA12806; Thu, 24 Feb 2005 01:55:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DHN-00036l-SZ; Thu, 24 Feb 2005 02:19:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D49W5-0005sq-3P; Wed, 23 Feb 2005 22:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lNY-0001TW-Jp for kitten@megatron.ietf.org; Tue, 22 Feb 2005 20:31:56 -0500 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 SAA09617 for ; Tue, 22 Feb 2005 18:44:27 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3k4E-0006tB-6Z for kitten@ietf.org; Tue, 22 Feb 2005 19:07:50 -0500 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 j1MNiPhl009478 for ; Tue, 22 Feb 2005 16:44:28 -0700 (MST) 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 j1MNiLeu016589 for ; Tue, 22 Feb 2005 16:44:21 -0700 (MST) 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 j1MNglaX002825; Tue, 22 Feb 2005 17:42:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j1MNgkHB002824; Tue, 22 Feb 2005 17:42:46 -0600 (CST) Date: Tue, 22 Feb 2005 17:42:46 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20050222234246.GP1007@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org, martin.rex@sap.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 I very much like this I-D -- it covers the problem description and proposed solutions quite well, with the right level of abstraction and sufficiently detailed examples. Comments: - section 1, 2nd paragraph, not only do names change over time, but they may even be re-used, which poses a real security problem. - section 3, you may want to mention that an exported name token for x.509 certs that included all attributes of the cert, or the cert itself, also would be an inadequate solution, and why. Why would that beinadequate? To begin with, using the cert itself as the exported name token would cause problems with respect to certificate expiration, revocation and replacement. If a cert is revoked and a new one (with a new subjectPublicKey) is issued then any exported name tokens for the revoked cert will fail to match the peer when it uses the new cert. But also, there may be environments where there are multiple certs corresponding to the same DN but with different extensions/attributes/subjectAltName where using certs as the exported name token may be inapropriate. And then there's applications where one might want to grant access to some resource to any peer whose cert has some EKU, or to any peer whose cert is from some subset of a larger PKI, and so on -- name-based authorization just does not support this well, as pointed out in your I-D already. - section 4, we may need some additional operations: - inquire additional typing information given a name attribute OID - name attribute type/value display operation - utility for extended name display - name attribute comparison and/or export/import, unless the name attribute octet string is required to be in some canonical format that can be compared directly - section 4, it may be worthwhile to point out that knowing the source of a name attribute would be good. Name attributes may have been added to a name without any authentication, or they may have been asserted, but not authenticated during security context establishment, or they may be part of one's or a peer's credentials, and therefore authenticated. In particular, if the GSS-API is to support name attribute assertion on a per-security context basis, in addition to, rather than only on a per-credential basis, then applications definitely need to know whether a given name attribute was merely asserted, or actually authenticated. - section 4.2, IMO these extensions should allow for arbitrary name attribute assertion by peers. See above. - section 4.3, another possibility is that gss_export_name() for such mechanisms returns different, unique, results on each invocation, even if for the same name, and that the exported name tokens may either not be importable or, if imported, do not compare as equal to the original name object. - section 5, GSS-API applications do not have access to peers' credential handles, which outright rules out the use of credential extensions for extending GSS-API authorization beyond name-based authorization, unless credential extensions are paired with context extensions, which section 6 hints at. Personally, name attributes are a simpler, and cleaner design than paired credential and security context extensions. Credential extensions may be useful for other purposes, as you point out, which too, I think, makes name attributes a cleaner design, as it keeps separate things separate. Think of a credential extension for specifying whether a a delegated credential should in turn be delegatable -- such an extension has not business being like a name attribute. - section 6, this section should probably be merged with section 5. See above. - We may want some examples indicating how applications are expected to use these facilities. Or we may want to leave that to an actual specification. - section 7, I don't understand this text. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Feb 28 09:39:53 2005 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 JAA25191; Mon, 28 Feb 2005 09:39:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5m4f-0008TG-L2; Mon, 28 Feb 2005 09:40:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5m31-0003FS-5Z; Mon, 28 Feb 2005 09:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5m2z-0003FC-QT for kitten@megatron.ietf.org; Mon, 28 Feb 2005 09:38:57 -0500 Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.29.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25076 for ; Mon, 28 Feb 2005 09:38:56 -0500 (EST) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j1SEcsJw003238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Feb 2005 09:38:54 -0500 (EST) Message-ID: <42232D44.9060806@columbia.edu> Date: Mon, 28 Feb 2005 09:40:04 -0500 From: Jeffrey Altman Organization: Not 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.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Agenda via RT X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Cc: kitten@ietf.org Subject: GSS-API Next Generation WG (kitten) 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="===============0903271843==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c This is a cryptographically signed message in MIME format. --===============0903271843== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000707020709050500060103" This is a cryptographically signed message in MIME format. --------------ms000707020709050500060103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit GSS API Next Generation WG (Kitten) WEDNESDAY, March 9, 2005 1300-1500 Afternoon Sessions I ============================== Chair: Jeffrey Altman AGENGA: Introduction - Jeffrey Altman (5 min) - Blue Sheets - Jabber/Scribe - Agenda Bashing SPNEGO - Larry Zhu (10 minutes) GSS Naming - Sam Hartman (10 minutes) PRF for GSS and PRF for Kerberos V - Nico Williams (5 minutes) Domain-based Service Names and Types - Nico Williams (5 minutes) GSS Stackable Pseudo Mechanisms - Nico Williams (5 min) GSS Clarifications and Extensions for the Use of Channel Bindings - Nico Williams (5 min) GSS Extension for Storing Delegated Credentials - Nico Williams (5 min) IANA Registry for GSS Extensions - Nico Williams (5 min) Updates to Java and C# Bindings - Jeffrey Altman (15 min) Open Floor Milestones (10 min) --------------ms000707020709050500060103 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 AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL 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 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMjI4MTQ0MDA0WjAjBgkqhkiG9w0BCQQxFgQUPjwVwzp5/VgSHvNFvTr5MQcts+8w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA1mLXjAHxTln1AvL2eed2mxcEpj1qgqzK/xB5eAAJ ZM6FZgNep5fkaCuapwxFeJv1jj2gAMrPYzTr6HS2TiuWLQ+HerlRyVSgdrpD75HLjyx0emfc 5XpJKcpNXDzrQ+mSaRbeWK/iDnGfNkIAC0/2RV4zhylYBzybVzALEykiXgopDCBS1GfnfaJS u82mKen8ltj4WEtSW7Kpa8lQZGGEQkE7W+uPzzjMdkDTk63+u+beZZf2JkB243fiA7L7IyVs NiLYtuKfwDpkfuaUI3x5DjVxKsyvUqpPBZJeOksAZsKda1R/92w2oG8I1zcysiu6yGPTTRqm ci0Wk4aDWaWFNgAAAAAAAA== --------------ms000707020709050500060103-- --===============0903271843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0903271843==--