From kitten-bounces@lists.ietf.org Wed Nov 01 17:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOz9-0001XQ-9q; Wed, 01 Nov 2006 17:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOz8-0001XB-Co for kitten@ietf.org; Wed, 01 Nov 2006 17:55:02 -0500 Received: from stratton-four-eighty-nine.mit.edu ([18.187.6.234] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfOz7-0006y9-49 for kitten@ietf.org; Wed, 01 Nov 2006 17:55:02 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ADF22E0035; Wed, 1 Nov 2006 17:54:58 -0500 (EST) From: Sam Hartman To: kitten@ietf.org References: Date: Wed, 01 Nov 2006 17:54:58 -0500 In-Reply-To: (Sam Hartman's message of "Fri, 20 Oct 2006 08:39:14 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ietf-krb-wg@anl.gov Subject: Re: AD review comments for the GSS-API domain name specs 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: , Errors-To: kitten-bounces@lists.ietf.org I haven't seen any discussion of my comments. If a new draft addressing these issues were reviewed and submitted early next week, then these could be approved on the next IESG telechat. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Nov 01 18:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPFE-00079X-Qp; Wed, 01 Nov 2006 18:11:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPFD-00079S-5M for kitten@ietf.org; Wed, 01 Nov 2006 18:11:39 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPF8-0000yt-DN for kitten@ietf.org; Wed, 01 Nov 2006 18:11:39 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA1NBX8R020326 for ; Wed, 1 Nov 2006 15:11:33 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA1NBWHa016836 for ; Wed, 1 Nov 2006 16:11:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA1NBVdL023262; Wed, 1 Nov 2006 17:11:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA1NBUaJ023261; Wed, 1 Nov 2006 17:11:30 -0600 (CST) Date: Wed, 1 Nov 2006 17:11:30 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20061101231129.GA23255@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org, ietf-krb-wg@anl.gov 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: AD review comments for the GSS-API domain name specs 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: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Nov 01, 2006 at 05:54:58PM -0500, Sam Hartman wrote: > I haven't seen any discussion of my comments. Sorry, replies will be sent soon. > If a new draft addressing these issues were reviewed and submitted > early next week, then these could be approved on the next IESG > telechat. > > > _______________________________________________ > 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@lists.ietf.org Wed Nov 01 19:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQrz-0001lO-AQ; Wed, 01 Nov 2006 19:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQrv-0001N5-Jd for kitten@ietf.org; Wed, 01 Nov 2006 19:55:43 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQgE-0006N9-0A for kitten@ietf.org; Wed, 01 Nov 2006 19:43:40 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 61A2AE0035; Wed, 1 Nov 2006 19:43:29 -0500 (EST) From: Sam Hartman To: Alexey Melnikov References: <4512C6B1.6050000@isode.com> <20060921183500.GL18305@binky.Central.Sun.COM> <4513DBCE.3000005@isode.com> <20060922153334.GW18305@binky.Central.Sun.COM> Date: Wed, 01 Nov 2006 19:43:29 -0500 In-Reply-To: <20060922153334.GW18305@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 22 Sep 2006 10:33:34 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, Hai Zaar Subject: Re: GSS-API QoPs and SASL SSF (Re: SASL always returns ssf=56 for GSSAPI) 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: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Cc'ing KITTEN to record my thoughts on this topic, which Nicolas> started out as a question about the SASL SSF of the SASL Nicolas> "GSSAPI" mechanism (as in "why is it always 56?"). Nicolas> IMO absolute SSF values are a broken concept, and Nicolas> dangerous too, because the relative strengths of Nicolas> individual cryptographic algorithms and constructions Nicolas> vary over time as cryptanalysis develops. Nicolas> Local SSF assignments based on local policy that does not Nicolas> rely on a notion of absolute strength would be better. Keep in mind that ssf is a implementation detail of at least one implementation and does not appear as part of SASL. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 02 22:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfq62-0007BM-OE; Thu, 02 Nov 2006 22:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfq60-0007BA-SB for kitten@ietf.org; Thu, 02 Nov 2006 22:51:56 -0500 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfq5z-0001wo-HP for kitten@ietf.org; Thu, 02 Nov 2006 22:51:56 -0500 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA33pnVr029783 for ; Thu, 2 Nov 2006 19:51:49 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8400301YOSFK00@d1-sfbay-09.sun.com> (original mail from Jeff.Nisewanger@Sun.COM) for kitten@ietf.org; Thu, 02 Nov 2006 19:51:49 -0800 (PST) Received: from [192.168.1.107] (adsl-71-141-235-74.dsl.snfc21.pacbell.net [71.141.235.74]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8400J1IYQD1O20@d1-sfbay-09.sun.com> for kitten@ietf.org; Thu, 02 Nov 2006 19:51:49 -0800 (PST) Date: Thu, 02 Nov 2006 19:51:48 -0800 From: Jeff Nisewanger To: kitten@ietf.org Message-id: <454ABCD4.8060601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: Re: Working Group Last Call: "An update to the Java GSS-API specification" 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: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > A two week Working Group Last Call is being initiated to determine if > this document is ready for publication. Positive acknowledgment of > document review and feedback is requested. I have reviewed draft-ietf-kitten-rfc2853bis-02 and believe it is ready to advance to IESG review. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Nov 02 22:55:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfq90-0000IS-2K; Thu, 02 Nov 2006 22:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfq8y-0000I4-0s for kitten@lists.ietf.org; Thu, 02 Nov 2006 22:55:00 -0500 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfq8w-0002JJ-Fb for kitten@lists.ietf.org; Thu, 02 Nov 2006 22:55:00 -0500 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA33svOP004407 for ; Thu, 2 Nov 2006 19:54:57 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8400501YTU1G00@d1-sfbay-09.sun.com> (original mail from Jeff.Nisewanger@Sun.COM) for kitten@lists.ietf.org; Thu, 02 Nov 2006 19:54:57 -0800 (PST) Received: from [192.168.1.107] (adsl-71-141-235-74.dsl.snfc21.pacbell.net [71.141.235.74]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J8400J1YYVL1O20@d1-sfbay-09.sun.com> for kitten@lists.ietf.org; Thu, 02 Nov 2006 19:54:57 -0800 (PST) Date: Thu, 02 Nov 2006 19:54:56 -0800 From: Jeff Nisewanger To: kitten@lists.ietf.org Message-id: <454ABD90.5040802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: Re: Working Group Last Call: "An update to the Java GSS-API specification" 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: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > A two week Working Group Last Call is being initiated to determine if > this document is ready for publication. Positive acknowledgment of > document review and feedback is requested. I have reviewed draft-ietf-kitten-rfc2853bis-02 and believe it is ready to advance to IESG review. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Nov 03 02:00:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft2Q-00025b-Uw; Fri, 03 Nov 2006 02:00:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft2P-00025G-4Q for kitten@ietf.org; Fri, 03 Nov 2006 02:00:25 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gft2N-0006Z6-Ru for kitten@ietf.org; Fri, 03 Nov 2006 02:00:25 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA370MGZ003923 for ; Fri, 3 Nov 2006 02:00:23 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033811.msg for ; Fri, 03 Nov 2006 02:03:51 -0500 Message-ID: <454AE9D5.6020906@secure-endpoints.com> Date: Fri, 03 Nov 2006 02:03:49 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: kitten@ietf.org References: <45367FF9.4090306@secure-endpoints.com> In-Reply-To: <45367FF9.4090306@secure-endpoints.com> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 03 Nov 2006 02:03:51 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: Re: Working Group Last Call: Stackable Generic Security Service Pseudo-Mechanisms X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2066636989==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2066636989== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090001080900050507040801" This is a cryptographically signed message in MIME format. --------------ms090001080900050507040801 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit The Working Group Last Call period is scheduled to expire today. If you have reviewed this document, please send an e-mail indicating that you have done so. A consensus of "silence" cannot be used to forward a document to the IESG. Thank you. Jeffrey Altman Jeffrey Altman wrote: > The Kitten Chair has received a request to submit > "Stackable Generic Security Service Pseudo-Mechanisms" > > to the IESG for publication as a Proposed Standard. > > Abstract > > This document defines and formalizes the concept of stackable pseudo- > mechanisms, and associated concept of composite mechanisms, for the > Generic Security Service Application Programming Interface (GSS-API), > as well as several utility functions. > > Stackable GSS-API pseudo-mechanisms allow for the composition of new > mechanisms that combine features from multiple mechanisms. Stackable > mechanisms that add support for Perfect Forward Security (PFS), data > compression, additional authentication factors, etc... are > facilitated by this document. > > A two week Working Group Last Call is being initiated to determine if > this document is ready for publication. Positive acknowledgment of > document review and feedback is requested. > > The working group last call will terminate at 00:00 EST 2 November 2006. > > Jeffrey Altman > Kitten Chair > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms090001080900050507040801 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDMwNzAzNDlaMCMGCSqGSIb3DQEJBDEWBBSaqUSN ByQLEWFstkOXNB//VCObUTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAIrMQMAQS35/gqWIJHuF2ZWlwlZ0KncNWCMIWHvdl8h1t65zFb84f cpY5i/mWuHCxYwFSTS60tOMNr/kjKW6GZkUMfBSn84vRQUayrOR9Wyadq+5HB/rgbmIMMR+K UbKzrl+GA/W2bw2AR/J80t9m7EWCKkKhFU0A7esUZcrjDm97MSxf50XEwLGnOr4yPBuu8Lqr pfJ5psmYtYw5NHoBHZrrAGfabS9GQFtiitO7qQqAV84BrPoBbfAKNBxtCQk+ZPaI8gnW+Bdl e2Mn60oUV5kifVGiXY6s0LPboLnFPBB7Rx+G6HTb3FSlLTpHZgcewsrqT31naGtxrzgyWmQZ VAAAAAAAAA== --------------ms090001080900050507040801-- --===============2066636989== 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 --===============2066636989==-- From kitten-bounces@lists.ietf.org Fri Nov 03 02:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft33-0002Aq-NJ; Fri, 03 Nov 2006 02:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft33-0002Af-0F for kitten@ietf.org; Fri, 03 Nov 2006 02:01:05 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gft31-0006cy-MP for kitten@ietf.org; Fri, 03 Nov 2006 02:01:04 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA3712nc004512 for ; Fri, 3 Nov 2006 02:01:03 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033812.msg for ; Fri, 03 Nov 2006 02:04:32 -0500 Message-ID: <454AE9FC.4090104@secure-endpoints.com> Date: Fri, 03 Nov 2006 02:04:28 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: kitten@ietf.org References: <45355F63.9050804@Sun.COM> <45367919.4050207@secure-endpoints.com> In-Reply-To: <45367919.4050207@secure-endpoints.com> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 03 Nov 2006 02:04:32 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Subject: Re: Working Group Last Call: "An update to the Java GSS-API specification" X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0600763698==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0600763698== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030101050907020703050308" This is a cryptographically signed message in MIME format. --------------ms030101050907020703050308 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit The Working Group Last Call period is scheduled to expire today. If you have reviewed this document, please send an e-mail indicating that you have done so. A consensus of "silence" cannot be used to forward a document to the IESG. Thank you. Jeffrey Altman Jeffrey Altman wrote: > The Kitten Chair has received a request to submit "An Update to the Java > GSS-API Specification" > > to the IESG for publication as a Proposed Standard. > > Abstract > > The Generic Security Services Application Program Interface (GSS-API) > offers application programmers uniform access to security services > atop a variety of underlying cryptographic mechanisms. This document > updates the Java bindings for the GSS-API that are specified in > "Generic Security Service API version 2 : Java Bindings" (RFC2853). > This document obsoletes RFC2853 by making specific and incremental > clarifications and corrections to it in response to identification of > transcription errors and implementation experience. The note-worthy > changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853, > which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and 7.8.1 of > this document, where numerical constants were either added or > modified. > > The GSS-API is described at a language independent conceptual level > in "Generic Security Service Application Program Interface Version 2, > Update 1" (RFC2743). The GSS-API allows a caller application to > authenticate a principal identity, to delegate rights to a peer, and > to apply security services such as confidentiality and integrity on a > per-message basis. Examples of security mechanisms defined for GSS- > API are "The Simple Public-Key GSS-API Mechanism" (RFC2025) and "The > Kerberos Version 5 GSS-API Mechanism (RFC4121). > > A two week Working Group Last Call is being initiated to determine if > this document is ready for publication. Positive acknowledgment of > document review and feedback is requested. > > The working group last call will terminate at 00:00 EST 2 November 2006. > > Jeffrey Altman > Kitten Chair > > Seema Malkani wrote: >> An update to the Java GSS-API specification has been submitted in >> draft-ietf-kitten-rfc2853bis-02.txt >> http://www.ietf.org/internet-drafts/draft-ietf-kitten-rfc2853bis-02.txt >> >> This document updates the Java bindings for the GSS-API that are >> specified in "Generic Security Service API version 2 : Java Bindings" >> (RFC2853), by making specific and incremental clarifications and >> corrections to it in response to identification of transcription errors >> and implementation experience. The note-worthy changes are in the >> sections stated in the draft, where numerical constants were either >> added or modified. >> >> Please begin WGLC at your earliest convenience. >> >> Thanks, >> Seema >> >> >> >> _______________________________________________ >> 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 --------------ms030101050907020703050308 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDMwNzA0MjhaMCMGCSqGSIb3DQEJBDEWBBTsgcqL kvx/tibfEb/nHkma6e9BRzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAk8waltzIrvNI8/cJNGfRpTKDxqTbJahlFO/CDRVm2/BPXZuFt9eq dEjCwpHte6tXBQMi9plkUlRn+SP8AV9TlZOXcuM0/A17H5qHhAUkNyi/OhgjQbgQRekw5ofD +lDCFqpMDGPFSA5hx7IwQVXMj/yez+F4oTENlGL7ptx0pbU9cNlO5Umo2HsP7jDm/mwbgQCz arZCCQeXeNs6A+aotigneZ6xtUb7Zo8qMHtk2AAQS8LTt5bWToh/Qv1xS1ldFoZcbdoo5UQ2 RBh8iPQKquN87IMSElebC0uvkAg0kHy+cN+f+mCuBXI10AFBdnBhYNRhOOTsWlm6tfV3K3w5 8gAAAAAAAA== --------------ms030101050907020703050308-- --===============0600763698== 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 --===============0600763698==-- From kitten-bounces@lists.ietf.org Fri Nov 03 02:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft3n-0002VJ-2P; Fri, 03 Nov 2006 02:01:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gft3m-0002VE-HF for kitten@ietf.org; Fri, 03 Nov 2006 02:01:50 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gft3k-0006pp-8E for kitten@ietf.org; Fri, 03 Nov 2006 02:01:50 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA371lM9025681 for ; Fri, 3 Nov 2006 02:01:47 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033813.msg for ; Fri, 03 Nov 2006 02:05:17 -0500 Message-ID: <454AEA28.9070806@secure-endpoints.com> Date: Fri, 03 Nov 2006 02:05:12 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: kitten@ietf.org References: <45367F30.6010003@secure-endpoints.com> In-Reply-To: <45367F30.6010003@secure-endpoints.com> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 03 Nov 2006 02:05:17 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: Re: Working Group Last Call: Extended Generic Security Service Mechanism Inquiry APIs X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314480709==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1314480709== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000804010505020903060306" This is a cryptographically signed message in MIME format. --------------ms000804010505020903060306 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit The Working Group Last Call period is scheduled to expire today. If you have reviewed this document, please send an e-mail indicating that you have done so. A consensus of "silence" cannot be used to forward a document to the IESG. Thank you. Jeffrey Altman Jeffrey Altman wrote: > The Kitten Chair has received a request to submit > "Extended Generic Security Service Mechanism Inquiry APIs" > > to the IESG for publication as a Proposed Standard. > > Abstract > > This document introduces new application programming interfaces > (APIs) to the Generic Security Services API (GSS-API) for extended > mechanism attribute inquiry. These interfaces are primarily intended > for use in mechanism composition, but also to reduce instances of > hardcoding of mechanism identifiers in GSS applications. > > These interfaces include: mechanism attributes and attribute sets, a > function for inquiring the attributes of a mechanism, a function for > indicating mechanisms that posses given attributes, and a function > for displaying mechanism attributes. > > A two week Working Group Last Call is being initiated to determine if > this document is ready for publication. Positive acknowledgment of > document review and feedback is requested. > > The working group last call will terminate at 00:00 EST 2 November 2006. > > Jeffrey Altman > Kitten Chair > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms000804010505020903060306 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDMwNzA1MTJaMCMGCSqGSIb3DQEJBDEWBBT9Zrqd 8WeuKU52H1o4L14ihbNzBTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEARdWgN4ilPgVIPGNA1ZMDA25ivo1gxbZrh935QKdj0S/kEzt4yRDg ZlsT6CGXg3/U8IZqv8LtaIvnWCu9kLE0YUsVZv1KjZ0JWS0Sw/5yCH78pI0RPJcps7h0t6Wk xVGQ6NFnrNpmUd4JuO6Fd4fEDSUK4v+MWypuD2niMgsxAG2jiRNdN2MQ87YjkRz4/m8+dU0b AS6iGnyX0Yzxz+Xd6W9ZGfSe5lZxyF+oDSIzGdgsM22fLzyMnsf6FSMUCesaQmIsqffLAGlE s7Y732XhECq31bOSkVkD0sAK51eRMh6z7r3f034SMO0xVEQoa6cJden1hsRwNMVIskMbdVEo NwAAAAAAAA== --------------ms000804010505020903060306-- --===============1314480709== 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 --===============1314480709==-- From kitten-bounces@lists.ietf.org Sat Nov 04 00:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmJ-0004oi-9T; Sat, 04 Nov 2006 00:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmH-0004oc-R3 for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0007zn-Ca for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA4591bG007591 for ; Sat, 4 Nov 2006 00:09:02 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033892.msg for ; Sat, 04 Nov 2006 00:12:31 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:26 -0500 Resent-Message-Id: <454C213A.5010501@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=unavailable version=3.1.5 X-Spam-Report: * 0.1 FORGED_RCVD_HELO Received: contains a forged HELO * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Received: from av8-2-sn3.vrr.skanova.net (av8-2-sn3.vrr.skanova.net [81.228.9.184]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033876.msg for ; Fri, 03 Nov 2006 18:30:05 -0500 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0284937EE3; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E437E37E9E for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BC5A337E4F for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg8QZ-0007yV-M2 for kitten-chairs@tools.ietf.org; Sat, 04 Nov 2006 00:26:28 +0100 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA3NQJwO011933 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA3NQIlw027638 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA3NQHh2025454; Fri, 3 Nov 2006 17:26:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA3NQGCV025453; Fri, 3 Nov 2006 17:26:16 -0600 (CST) Date: Fri, 3 Nov 2006 17:26:16 -0600 From: Nicolas Williams To: Tom Yu Message-ID: <20061103232616.GA23255@binky.Central.Sun.COM> Mail-Followup-To: Tom Yu , secdir@MIT.EDU, iesg@ietf.org, kitten-chairs@tools.ietf.org 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-SA-Exim-Connect-IP: 192.18.98.34 X-SA-Exim-Mail-From: nw141292@binky.Central.SuFrom kitten-bounces@lists.ietf.org Sat Nov 04 00:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmJ-0004oi-9T; Sat, 04 Nov 2006 00:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmH-0004oc-R3 for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0007zn-Ca for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA4591bG007591 for ; Sat, 4 Nov 2006 00:09:02 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033892.msg for ; Sat, 04 Nov 2006 00:12:31 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:26 -0500 Resent-Message-Id: <454C213A.5010501@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=unavailable version=3.1.5 X-Spam-Report: * 0.1 FORGED_RCVD_HELO Received: contains a forged HELO * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Received: from av8-2-sn3.vrr.skanova.net (av8-2-sn3.vrr.skanova.net [81.228.9.184]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033876.msg for ; Fri, 03 Nov 2006 18:30:05 -0500 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0284937EE3; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E437E37E9E for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BC5A337E4F for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg8QZ-0007yV-M2 for kitten-chairs@tools.ietf.org; Sat, 04 Nov 2006 00:26:28 +0100 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA3NQJwO011933 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA3NQIlw027638 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA3NQHh2025454; Fri, 3 Nov 2006 17:26:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA3NQGCV025453; Fri, 3 Nov 2006 17:26:16 -0600 (CST) Date: Fri, 3 Nov 2006 17:26:16 -0600 From: Nicolas Williams To: Tom Yu Message-ID: <20061103232616.GA23255@binky.Central.Sun.COM> Mail-Followup-To: Tom Yu , secdir@MIT.EDU, iesg@ietf.org, kitten-chairs@tools.ietf.org 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-SA-Exim-Connect-IP: 192.18.98.34 X-SA-Exim-Mail-From: nw141292@binky.Central.Sun.COM X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on nw141292@binky.Central.Sun.COM does not match 81.228.9.184 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:31 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: kitten-chairs@tools.ietf.org, secdir@MIT.EDU, iesg@ietf.org Subject: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nw141292@binky.Central.Sun.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 Resent-Date: Sat, 04 Nov 2006 00:09:11 -0500 On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote: > For some time, I had some difficult-to-articulate misgivings about the > domain-based name concept advanced in these documents. I now realize > that the underlying issue is one of implicitly creating an > authorization role where one might not have been present before. > Essentially, the mere existence of a domain-based principal name forms > an authorization assertion. Yes. > In Kerberos, and possibly other > authentication architectures, the mere existence of a name does not > usually express any authorization assertion. > > For a traditional host-based service principal name, e.g., > "service_a@hostname_b", successful authentication to that service > principal only implies that the administrator of the namespace has > certified the association of some secret with the particular hostname > (hostname_b), and that perhaps the administrator of "hostname_b" > wishes to run an instance of "service_a" upon that host. Indeed. We're extending this very model. > In contrast, the existence of a domain-based principal name such as > "service_a@domain_b@hostname_c" constitutes an assertion that within > the administrative domain defined for the namespace, the administrator > of "hostname_c" is authorized to operate the specific service instance > represented by the name "domain_b". Correct. > I think that users contemplating the use of these domain-based > principal names should be cautioned that using such names will require > re-evaluation of the policies followed by the administrators of the > namespace, because the administrators must now consider that creating > a principal name constitutes an authorization assertion, and the > administrators may not have previously had the role of making > authorization assertions. So, then, it seems that you want a note cautioning realm administrators that they must understand the purpose of any domain-based principal which they create? I believe that would be fair. > I'm not sure this is the best textual description of the problem, but > I think it does need to be discussed in the security considerations. > The problem isn't sufficiently serious that it would be a bad idea to > implement the domain-based principal name concept as described; it > just would be a good idea to document the related security policy > issues. I believe: a) there is no problem, b) the problem that domain-based naming solves is bigger than the problem you thinn.COM X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on nw141292@binky.Central.Sun.COM does not match 81.228.9.184 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:31 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: kitten-chairs@tools.ietf.org, secdir@MIT.EDU, iesg@ietf.org Subject: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nw141292@binky.Central.Sun.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 Resent-Date: Sat, 04 Nov 2006 00:09:11 -0500 On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote: > For some time, I had some difficult-to-articulate misgivings about the > domain-based name concept advanced in these documents. I now realize > that the underlying issue is one of implicitly creating an > authorization role where one might not have been present before. > Essentially, the mere existence of a domain-based principal name forms > an authorization assertion. Yes. > In Kerberos, and possibly other > authentication architectures, the mere existence of a name does not > usually express any authorization assertion. > > For a traditional host-based service principal name, e.g., > "service_a@hostname_b", successful authentication to that service > principal only implies that the administrator of the namespace has > certified the association of some secret with the particular hostname > (hostname_b), and that perhaps the administrator of "hostname_b" > wishes to run an instance of "service_a" upon that host. Indeed. We're extending this very model. > In contrast, the existence of a domain-based principal name such as > "service_a@domain_b@hostname_c" constitutes an assertion that within > the administrative domain defined for the namespace, the administrator > of "hostname_c" is authorized to operate the specific service instance > represented by the name "domain_b". Correct. > I think that users contemplating the use of these domain-based > principal names should be cautioned that using such names will require > re-evaluation of the policies followed by the administrators of the > namespace, because the administrators must now consider that creating > a principal name constitutes an authorization assertion, and the > administrators may not have previously had the role of making > authorization assertions. So, then, it seems that you want a note cautioning realm administrators that they must understand the purpose of any domain-based principal which they create? I believe that would be fair. > I'm not sure this is the best textual description of the problem, but > I think it does need to be discussed in the security considerations. > The problem isn't sufficiently serious that it would be a bad idea to > implement the domain-based principal name concept as described; it > just would be a good idea to document the related security policy > issues. I believe: a) there is no problem, b) the problem that domain-based naming solves is bigger than the problem you think d-b naming has, c) other ways of solving that bigger problem would be much more heavy-weight than d-b naming. That said, I don't mind adding security considerations text as described above. I'll write some up and post it. Note that folks can and, I bet, have used Kerberos V's multi-component principal naming feature to support naming conventions similar to the one in d-b naming, thus this would seem like a generic security consideration for any network authentication scheme with user-extensible naming. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Nov 04 00:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmG-0004oG-3M; Sat, 04 Nov 2006 00:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0004o4-GQ for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmC-0007vp-HK for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA458j5B007338 for ; Sat, 4 Nov 2006 00:08:46 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033891.msg for ; Sat, 04 Nov 2006 00:12:16 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:10 -0500 Resent-Message-Id: <454C212A.7070207@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Received-SPF: softfail (www.secure-endpoints.com: domain of transitioning tlyu@MIT.EDU does not designate 81.228.9.181 as permitted sender) x-spf-client=MDaemon.PRO.v9.0.8 receiver=www.secure-endpoints.com client-ip=81.228.9.181 envelope-from= helo=av7-1-sn3.vrr.skanova.net Received: from av7-1-sn3.vrr.skanova.net (av7-1-sn3.vrr.skanova.net [81.228.9.181]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033871.msg for ; Fri, 03 Nov 2006 17:39:45 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5A2F737FDE; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 472CD37F42 for ; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D6E7F37E55 for ; Fri, 3 Nov 2006 23:36:10 +0100 (CET) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg7du-0005HU-8M for kitten-chairs@tools.ietf.org; Fri, 03 Nov 2006 23:36:10 +0100 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA3MZeIJ024658; Fri, 3 Nov 2006 17:35:40 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kA3MZdMC008185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Nov 2006 17:35:39 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id kA3MZcSf006159; Fri, 3 Nov 2006 17:35:39 -0500 (EST) To: secdir@mit.edu, iesg@ietf.org, kitten-chairs@tools.ietf.org, Nicolas.Williams@sun.com From: Tom Yu Date: Frk d-b naming has, c) other ways of solving that bigger problem would be much more heavy-weight than d-b naming. That said, I don't mind adding security considerations text as described above. I'll write some up and post it. Note that folks can and, I bet, have used Kerberos V's multi-component principal naming feature to support naming conventions similar to the one in d-b naming, thus this would seem like a generic security consideration for any network authentication scheme with user-extensible naming. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Nov 04 00:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmG-0004oG-3M; Sat, 04 Nov 2006 00:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0004o4-GQ for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmC-0007vp-HK for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA458j5B007338 for ; Sat, 4 Nov 2006 00:08:46 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033891.msg for ; Sat, 04 Nov 2006 00:12:16 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:10 -0500 Resent-Message-Id: <454C212A.7070207@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Received-SPF: softfail (www.secure-endpoints.com: domain of transitioning tlyu@MIT.EDU does not designate 81.228.9.181 as permitted sender) x-spf-client=MDaemon.PRO.v9.0.8 receiver=www.secure-endpoints.com client-ip=81.228.9.181 envelope-from= helo=av7-1-sn3.vrr.skanova.net Received: from av7-1-sn3.vrr.skanova.net (av7-1-sn3.vrr.skanova.net [81.228.9.181]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033871.msg for ; Fri, 03 Nov 2006 17:39:45 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5A2F737FDE; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 472CD37F42 for ; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D6E7F37E55 for ; Fri, 3 Nov 2006 23:36:10 +0100 (CET) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg7du-0005HU-8M for kitten-chairs@tools.ietf.org; Fri, 03 Nov 2006 23:36:10 +0100 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA3MZeIJ024658; Fri, 3 Nov 2006 17:35:40 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kA3MZdMC008185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Nov 2006 17:35:39 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id kA3MZcSf006159; Fri, 3 Nov 2006 17:35:39 -0500 (EST) To: secdir@mit.edu, iesg@ietf.org, kitten-chairs@tools.ietf.org, Nicolas.Williams@sun.com From: Tom Yu Date: Fri, 03 Nov 2006 17:35:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-SA-Exim-Connect-IP: 18.7.7.80 X-SA-Exim-Mail-From: tlyu@MIT.EDU X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=2.5 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on tlyu@MIT.EDU does not match 81.228.9.181 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:16 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tlyu@mit.edu 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 Resent-Date: Sat, 04 Nov 2006 00:09:08 -0500 I have reviewed draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt for the security directorate. For the most part, I do not see any serious security issues, but I do think the security considerations should be expanded. For some time, I had some difficult-to-articulate misgivings about the domain-based name concept advanced in these documents. I now realize that the underlying issue is one of implicitly creating an authorization role where one might not have been present before. Essentially, the mere existence of a domain-based principal name forms an authorization assertion. In Kerberos, and possibly other authentication architectures, the mere existence of a name does not usually express any authorization assertion. For a traditional host-based service principal name, e.g., "service_a@hostname_b", successful authentication to that service principal only implies that the administrator of the namespace has certified the association of some secret with the particular hostname (hostname_b), and that perhaps the administrator of "hostname_b" wishes to run an instance of "service_a" upon that host. In contrast, the existence of a domain-based principal name such as "service_a@domain_b@hostname_c" constitutes an assertion that within the administrative domain defined for the namespace, the administrator of "hostname_c" is authorized to operate the specific service instance represented by the name "domain_b". I think that users contemplating the use of these domain-based principal names should be cautioned that using such names will require re-evaluation of the policies followed by the administrators of the namespace, because the administrators must now consider that creating a principal name constitutes an authorization assertion, and the administrators may not have previously had the role of making authorization assertions. I'm not sure this is the best textual description of the problem, but I think it does need to be discussed in the security considerations. The problem isn't sufficiently serious that it would be a bad idea to implement the domain-based principal nai, 03 Nov 2006 17:35:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-SA-Exim-Connect-IP: 18.7.7.80 X-SA-Exim-Mail-From: tlyu@MIT.EDU X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=2.5 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on tlyu@MIT.EDU does not match 81.228.9.181 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:16 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tlyu@mit.edu 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 Resent-Date: Sat, 04 Nov 2006 00:09:08 -0500 I have reviewed draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt for the security directorate. For the most part, I do not see any serious security issues, but I do think the security considerations should be expanded. For some time, I had some difficult-to-articulate misgivings about the domain-based name concept advanced in these documents. I now realize that the underlying issue is one of implicitly creating an authorization role where one might not have been present before. Essentially, the mere existence of a domain-based principal name forms an authorization assertion. In Kerberos, and possibly other authentication architectures, the mere existence of a name does not usually express any authorization assertion. For a traditional host-based service principal name, e.g., "service_a@hostname_b", successful authentication to that service principal only implies that the administrator of the namespace has certified the association of some secret with the particular hostname (hostname_b), and that perhaps the administrator of "hostname_b" wishes to run an instance of "service_a" upon that host. In contrast, the existence of a domain-based principal name such as "service_a@domain_b@hostname_c" constitutes an assertion that within the administrative domain defined for the namespace, the administrator of "hostname_c" is authorized to operate the specific service instance represented by the name "domain_b". I think that users contemplating the use of these domain-based principal names should be cautioned that using such names will require re-evaluation of the policies followed by the administrators of the namespace, because the administrators must now consider that creating a principal name constitutes an authorization assertion, and the administrators may not have previously had the role of making authorization assertions. I'm not sure this is the best textual description of the problem, but I think it does need to be discussed in the security considerations. The problem isn't sufficiently serious that it would be a bad idea to implement the domain-based principal name concept as described; it just would be a good idea to document the related security policy issues. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten me concept as described; it just would be a good idea to document the related security policy issues. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Nov 06 11:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6yz-00064K-4n; Mon, 06 Nov 2006 11:05:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6yw-00062F-S7 for kitten@ietf.org; Mon, 06 Nov 2006 11:05:54 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6w4-0004Mm-EO for kitten@ietf.org; Mon, 06 Nov 2006 11:02:59 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA6G2t7T019175 for ; Mon, 6 Nov 2006 11:02:55 -0500 (EST) Received: from [75.213.16.188] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000034005.msg for ; Mon, 06 Nov 2006 11:06:29 -0500 Message-ID: <454F5D7B.8040800@secure-endpoints.com> Date: Mon, 06 Nov 2006 08:06:19 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Mon, 06 Nov 2006 11:06:29 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.213.16.188 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 Cc: Subject: [Fwd: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0821406715==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0821406715== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040507070803080106070207" This is a cryptographically signed message in MIME format. --------------ms040507070803080106070207 Content-Type: multipart/mixed; boundary="------------000107000304090306070001" This is a multi-part message in MIME format. --------------000107000304090306070001 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit The attached messages were the result of a Security Directorate review of draft-ietf-kitten-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt. Nico will post to the Kitten mailing list the proposed Security Considerations text when it is ready. Jeffrey Altman --------------000107000304090306070001 Content-Type: message/rfc822; name*0="Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names"; name*1="-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03."; name*2="txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: secdir review of draft-ietf-kitten-gssapi-domain-based-n"; filename*1="ames-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-n"; filename*2="ames-03.txt" Return-Path: Received: from bockwurst.cc.columbia.edu ([unix socket]) by bockwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 04 Nov 2006 00:09:20 -0500 X-Sieve: CMU Sieve 2.3 Received: from jujube.cc.columbia.edu (jujube.cc.columbia.edu [128.59.28.170]) by bockwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kA459GMa002683 for ; Sat, 4 Nov 2006 00:09:16 -0500 Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by jujube.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA459BaW029284 for ; Sat, 4 Nov 2006 00:09:16 -0500 (EST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmJ-0004oi-8c; Sat, 04 Nov 2006 00:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmH-0004oc-R3 for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0007zn-Ca for kitten@ietf.org; Sat, 04 Nov 2006 00:09:09 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA4591bG007591 for ; Sat, 4 Nov 2006 00:09:02 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033892.msg for ; Sat, 04 Nov 2006 00:12:31 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:26 -0500 Resent-Message-Id: <454C213A.5010501@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=unavailable version=3.1.5 X-Spam-Report: * 0.1 FORGED_RCVD_HELO Received: contains a forged HELO * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Received: from av8-2-sn3.vrr.skanova.net (av8-2-sn3.vrr.skanova.net [81.228.9.184]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033876.msg for ; Fri, 03 Nov 2006 18:30:05 -0500 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 0284937EE3; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E437E37E9E for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id BC5A337E4F for ; Sat, 4 Nov 2006 00:26:28 +0100 (CET) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg8QZ-0007yV-M2 for kitten-chairs@tools.ietf.org; Sat, 04 Nov 2006 00:26:28 +0100 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA3NQJwO011933 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA3NQIlw027638 for ; Fri, 3 Nov 2006 16:26:19 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA3NQHh2025454; Fri, 3 Nov 2006 17:26:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA3NQGCV025453; Fri, 3 Nov 2006 17:26:16 -0600 (CST) Date: Fri, 3 Nov 2006 17:26:16 -0600 From: Nicolas Williams To: Tom Yu Message-ID: <20061103232616.GA23255@binky.Central.Sun.COM> Mail-Followup-To: Tom Yu , secdir@MIT.EDU, iesg@ietf.org, kitten-chairs@tools.ietf.org 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-SA-Exim-Connect-IP: 192.18.98.34 X-SA-Exim-Mail-From: nw141292@binky.Central.Sun.COM X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on nw141292@binky.Central.Sun.COM does not match 81.228.9.184 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:31 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: -1.999 () CU_LISTSUB_OK UNPARSEABLE_RELAY X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: kitten-chairs@tools.ietf.org, secdir@MIT.EDU, iesg@ietf.org Subject: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nw141292@binky.Central.Sun.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 Resent-Date: Sat, 04 Nov 2006 00:09:11 -0500 X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote: > For some time, I had some difficult-to-articulate misgivings about the > domain-based name concept advanced in these documents. I now realize > that the underlying issue is one of implicitly creating an > authorization role where one might not have been present before. > Essentially, the mere existence of a domain-based principal name forms > an authorization assertion. Yes. > In Kerberos, and possibly other > authentication architectures, the mere existence of a name does not > usually express any authorization assertion. > > For a traditional host-based service principal name, e.g., > "service_a@hostname_b", successful authentication to that service > principal only implies that the administrator of the namespace has > certified the association of some secret with the particular hostname > (hostname_b), and that perhaps the administrator of "hostname_b" > wishes to run an instance of "service_a" upon that host. Indeed. We're extending this very model. > In contrast, the existence of a domain-based principal name such as > "service_a@domain_b@hostname_c" constitutes an assertion that within > the administrative domain defined for the namespace, the administrator > of "hostname_c" is authorized to operate the specific service instance > represented by the name "domain_b". Correct. > I think that users contemplating the use of these domain-based > principal names should be cautioned that using such names will require > re-evaluation of the policies followed by the administrators of the > namespace, because the administrators must now consider that creating > a principal name constitutes an authorization assertion, and the > administrators may not have previously had the role of making > authorization assertions. So, then, it seems that you want a note cautioning realm administrators that they must understand the purpose of any domain-based principal which they create? I believe that would be fair. > I'm not sure this is the best textual description of the problem, but > I think it does need to be discussed in the security considerations. > The problem isn't sufficiently serious that it would be a bad idea to > implement the domain-based principal name concept as described; it > just would be a good idea to document the related security policy > issues. I believe: a) there is no problem, b) the problem that domain-based naming solves is bigger than the problem you think d-b naming has, c) other ways of solving that bigger problem would be much more heavy-weight than d-b naming. That said, I don't mind adding security considerations text as described above. I'll write some up and post it. Note that folks can and, I bet, have used Kerberos V's multi-component principal naming feature to support naming conventions similar to the one in d-b naming, thus this would seem like a generic security consideration for any network authentication scheme with user-extensible naming. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --------------000107000304090306070001 Content-Type: message/rfc822; name*0="secdir review of draft-ietf-kitten-gssapi-domain-based-names-03."; name*1="txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="secdir review of draft-ietf-kitten-gssapi-domain-based-names"; filename*1="-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names"; filename*2="-03.txt" Return-Path: Received: from bockwurst.cc.columbia.edu ([unix socket]) by bockwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 04 Nov 2006 00:09:24 -0500 X-Sieve: CMU Sieve 2.3 Received: from feta.cc.columbia.edu (feta.cc.columbia.edu [128.59.28.164]) by bockwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kA459IdE002684 for ; Sat, 4 Nov 2006 00:09:18 -0500 Received: from megatron.ietf.org (www1.ietf.ORG [156.154.16.145]) by feta.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA459CAm012809 for ; Sat, 4 Nov 2006 00:09:17 -0500 (EST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmG-0004oG-2f; Sat, 04 Nov 2006 00:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgDmE-0004o4-GQ for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgDmC-0007vp-HK for kitten@ietf.org; Sat, 04 Nov 2006 00:09:06 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA458j5B007338 for ; Sat, 4 Nov 2006 00:08:46 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000033891.msg for ; Sat, 04 Nov 2006 00:12:16 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Sat, 4 Nov 2006 00:12:10 -0500 Resent-Message-Id: <454C212A.7070207@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Received-SPF: softfail (www.secure-endpoints.com: domain of transitioning tlyu@MIT.EDU does not designate 81.228.9.181 as permitted sender) x-spf-client=MDaemon.PRO.v9.0.8 receiver=www.secure-endpoints.com client-ip=81.228.9.181 envelope-from= helo=av7-1-sn3.vrr.skanova.net Received: from av7-1-sn3.vrr.skanova.net (av7-1-sn3.vrr.skanova.net [81.228.9.181]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000033871.msg for ; Fri, 03 Nov 2006 17:39:45 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 5A2F737FDE; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 472CD37F42 for ; Fri, 3 Nov 2006 23:35:57 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id D6E7F37E55 for ; Fri, 3 Nov 2006 23:36:10 +0100 (CET) Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Gg7du-0005HU-8M for kitten-chairs@tools.ietf.org; Fri, 03 Nov 2006 23:36:10 +0100 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA3MZeIJ024658; Fri, 3 Nov 2006 17:35:40 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kA3MZdMC008185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Nov 2006 17:35:39 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id kA3MZcSf006159; Fri, 3 Nov 2006 17:35:39 -0500 (EST) To: secdir@mit.edu, iesg@ietf.org, kitten-chairs@tools.ietf.org, Nicolas.Williams@sun.com From: Tom Yu Date: Fri, 03 Nov 2006 17:35:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 X-Scanned-By: MIMEDefang 2.42 X-SA-Exim-Connect-IP: 18.7.7.80 X-SA-Exim-Mail-From: tlyu@MIT.EDU X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=2.5 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on tlyu@MIT.EDU does not match 81.228.9.181 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Sat, 04 Nov 2006 00:12:16 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: -1.999 () CU_LISTSUB_OK UNPARSEABLE_RELAY X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tlyu@mit.edu 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 Resent-Date: Sat, 04 Nov 2006 00:09:08 -0500 I have reviewed draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt for the security directorate. For the most part, I do not see any serious security issues, but I do think the security considerations should be expanded. For some time, I had some difficult-to-articulate misgivings about the domain-based name concept advanced in these documents. I now realize that the underlying issue is one of implicitly creating an authorization role where one might not have been present before. Essentially, the mere existence of a domain-based principal name forms an authorization assertion. In Kerberos, and possibly other authentication architectures, the mere existence of a name does not usually express any authorization assertion. For a traditional host-based service principal name, e.g., "service_a@hostname_b", successful authentication to that service principal only implies that the administrator of the namespace has certified the association of some secret with the particular hostname (hostname_b), and that perhaps the administrator of "hostname_b" wishes to run an instance of "service_a" upon that host. In contrast, the existence of a domain-based principal name such as "service_a@domain_b@hostname_c" constitutes an assertion that within the administrative domain defined for the namespace, the administrator of "hostname_c" is authorized to operate the specific service instance represented by the name "domain_b". I think that users contemplating the use of these domain-based principal names should be cautioned that using such names will require re-evaluation of the policies followed by the administrators of the namespace, because the administrators must now consider that creating a principal name constitutes an authorization assertion, and the administrators may not have previously had the role of making authorization assertions. I'm not sure this is the best textual description of the problem, but I think it does need to be discussed in the security considerations. The problem isn't sufficiently serious that it would be a bad idea to implement the domain-based principal name concept as described; it just would be a good idea to document the related security policy issues. ---Tom _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --------------000107000304090306070001-- --------------ms040507070803080106070207 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDYxNjA2MTlaMCMGCSqGSIb3DQEJBDEWBBRPY4SZ 7Mnb/+9jem+5H9juvQv4bjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAEVfv6DQX/a/Yp5n2MMFNMFl+jncvKT8EWvRf2lTJSHi/qyEQ6qMP ClVBG1FHrrZbqp4sqSkA4DHG+342v7QkZMBrbcIicVwLDZ7hxETA8VA5ncnb44f2o441PXCV aI2KZl94YO6/Bq5zO+rxtOR1WzKrVH7sGHTSJOI8gx9dN3S4LndsMRELVXgsXLgIBWNEkkNZ Sggtf4E3iUkZGDSBT2AsQX9ZwZ+32uE/t02Tk/+QO7Svo26o69kK6mxuDTk/Mtg6fbwBmB5P AZyQHutXirEDWbXsIvujJzN17KZX7hnJPO2NcGJQBbzsDO5AWFXWtfzSxVMuBQzsTxm7LuGC JQAAAAAAAA== --------------ms040507070803080106070207-- --===============0821406715== 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 --===============0821406715==-- From kitten-bounces@lists.ietf.org Tue Nov 07 01:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhK5Q-0006hv-Ji; Tue, 07 Nov 2006 01:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhK5P-0006gT-Bt for kitten@ietf.org; Tue, 07 Nov 2006 01:05:27 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhK5M-0008F6-T6 for kitten@ietf.org; Tue, 07 Nov 2006 01:05:27 -0500 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA765OKI022122 for ; Mon, 6 Nov 2006 22:05:24 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA765Nd5005740 for ; Mon, 6 Nov 2006 23:05:23 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA765MnI027537; Tue, 7 Nov 2006 00:05:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA765Mxd027536; Tue, 7 Nov 2006 00:05:22 -0600 (CST) Date: Tue, 7 Nov 2006 00:05:22 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20061107060522.GV25646@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , kitten@ietf.org, ietf-krb-wg@anl.gov 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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: AD review comments for the GSS-API domain name specs 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: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Oct 20, 2006 at 08:39:14AM -0400, Sam Hartman wrote: > These AD comments need to be fixed. However they are rather minor so > I'm going to last call the comments in parallel. > > draft-ietf-kitten-gssapi-domain-based-names : > > * There is no IANA considerations section yet actions (allocation of > an oid) are requested of IANA Actually, the IANA may have no role to play and my note in the I-D may have been incorrect. I cannot find an IANA registry for the 1.3.6.1.5.6 sub-tree. RFC2743 establishes an IANA registry of _service names_ but not of name types. So I wouldn't quite know how to write instructions to IANA about this short of actually writing instructions for establishing the missing registry. We have a separate I-D on IANA registries for the GSS-API, but I don't want this I-D to block on that one. And since the existing name type OIDs have been allocated by Standards Track RFCs I believe the right thing to do is to remove my note about the allocation of this OID. > * Do we really want to recommend _foo._tcp.example.tld instead of just > example.tld? I don't think I care one way or the other. > draft-ietf-kitten-krb5-gssapi-domain-based-names > > What does the following text mean: > > o the realm of the resulting principal name is that which > corresponds to the domain name, treated as a hostname. > > I think you may mean something like: As with host-based service names, > implementations need to choose the appropriate realm for the Kerberos > principal corresponding to the domain-based name. This realm is the > Kerberos realm that is authoritative for the domain portion of the > name, not the host portion of the name. Typically Kerberos > implementations have a facility that can map a host name to a realm; > implementations MAY use the realm that results from providing the > domain portion of the name as an input into this facility. Yes. Do you have better text suggestions? How about: o the realm of the resulting principal name SHALL be that which would be used for a hostname whose name is the same as the domain name component of the domain-based service name. Thanks, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 04:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhNbU-00048T-6L; Tue, 07 Nov 2006 04:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhNbS-00047r-Np; Tue, 07 Nov 2006 04:50:46 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhNbK-0000Ve-9z; Tue, 07 Nov 2006 04:50:46 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.685.10; Tue, 7 Nov 2006 01:50:37 -0800 Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 01:50:36 -0800 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.70.76]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Tue, 7 Nov 2006 01:50:36 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.0; Tue, 7 Nov 2006 01:50:35 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 7 Nov 2006 01:50:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C70252.137285A1" Date: Tue, 7 Nov 2006 01:49:54 -0800 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: PKU2U ID Thread-Index: AccCUhOie6a+Br7iTSWJo47zceIgvA== From: "Liqiang(Larry) Zhu" To: , X-OriginalArrivalTime: 07 Nov 2006 09:50:35.0460 (UTC) FILETIME=[2C25D840:01C70252] X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a5294b34f62cf4aba63c62e30e627ff Cc: jaltman@secure-endpoints.com Subject: PKU2U ID 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: , Errors-To: kitten-bounces@lists.ietf.org ------_=_NextPart_001_01C70252.137285A1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C70252.137285A1" ------_=_NextPart_002_01C70252.137285A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per discussion in the BOF on Monday I am posting the PKU2U ID.=20 =20 Per an request from Jeff, I included kitten. =20 I spent sometime today to unify PKU2U with WS-KERB, and updated WS-KERB to have consistent terminology here. The updated -01 is also attached. Thanks. =20 --Larry ------_=_NextPart_002_01C70252.137285A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per discussion in the BOF on Monday I am posting = the PKU2U ID.

 

Per an request from Jeff, I included = kitten.

 

I spent sometime today to unify PKU2U with WS-KERB, = and updated WS-KERB to have consistent terminology here. The updated -01 is = also attached. Thanks.

 

--Larry

------_=_NextPart_002_01C70252.137285A1-- ------_=_NextPart_001_01C70252.137285A1 Content-Type: text/plain; name="draft-zhu-pku2u-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-zhu-pku2u-00.txt Content-Disposition: attachment; filename="draft-zhu-pku2u-00.txt" DQoNCk5FVFdPUksgV09SS0lORyBHUk9VUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEwuIFpodQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQS4gTWVkdmluc2t5DQpVcGRhdGVzOiA0MTIwIChpZiBh cHByb3ZlZCkgICAgICAgICAgICAgICAgICAgICAgICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCklu dGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEouIEFsdG1hbg0KRXhwaXJlczogTWF5IDExLCAyMDA3ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFNlY3VyZSBFbmQgUG9pbnRzDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDcsIDIwMDYNCg0KDQogIFB1 YmxpYyBLZXkgQ3J5cHRvZ3JhcGh5IGJhc2VkIFVzZXIgdG8gVXNlciBBdXRoZW50aWNhdGlvbiAt IChQS1UyVSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LXpodS1wa3UydS0wMA0K DQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1E cmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRl bnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhh dmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUg YmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBT ZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiks IGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUu ICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNl DQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBh Y2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSAxMSwgMjAwNy4NCg0KQ29w eXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgy MDA2KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBQdWJsaWMg S2V5IENyeXB0b2dyYXBoeSBiYXNlZCBVc2VyIHRvIFVzZXINCiAgIGF1dGhlbnRpY2F0aW9uIHBy b3RvY29sIC0gUEtVMlUuIFBLVTJVIGlzIGJhc2VkIG9uIFJGQzQ0NTYgYW5kDQogICBSRkM0MTIw LiAgVGhpcyBlbmFibGVzIHBlZXIgdG8gcGVlciBhdXRoZW50aWNhdGlvbiB1c2luZyBLZXJiZXJv cw0KICAgbWVzc2FnZXMgd2l0aG91dCByZXF1aXJpbmcgYW4gb25saW5lIHRydXN0ZWQgdGhpcmQg cGFydHkuICBJbg0KICAgYWRkaXRpb24sIHRoZSBiaW5kaW5nIG9mIFBLVTJVIGZvciB0aGUgR2Vu ZXJpYyBTZWN1cml0eSBTZXJ2aWNlDQogICBBcHBsaWNhdGlvbiBQcm9ncmFtIEludGVyZmFjZSAo R1NTLUFQSSkgcGVyIFJGQzI3NDMgaXMgZGVmaW5lZCBiYXNlZA0KDQoNCg0KWmh1LCBldCBhbC4g ICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxMSwgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdl IDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgUEtVMlUgICAgICAgICAg ICAgICAgICAgIE5vdmVtYmVyIDIwMDYNCg0KDQogICBvbiBSRkM0MTIxLg0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEgIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgMiAgQ29udmVudGlvbnMgVXNlZCBpbiBU aGlzIERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAzICBQcm90 b2NvbCBkZXNjcmlwdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDMNCiAgIDQgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0KICAgNSAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICA2ICBJQU5BIENvbnNp ZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUN CiAgIDcgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNQ0KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1DQogICBJbnRlbGxlY3R1YWwgUHJvcGVy dHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDcNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KWmh1LCBldCBhbC4gICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxMSwgMjAw NyAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgUEtVMlUgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDYNCg0KDQoxICBJ bnRyb2R1Y3Rpb24NCg0KICAgUGVlci10by1wZWVyIHN5c3RlbXMgYXJlIGluY3JlYXNpbmdseSBw b3B1bGFyIHRvZGF5LiAgSW4gYSBwZWVyLXRvLQ0KICAgcGVlciBzeXN0ZW0sIGFsbCBjbGllbnRz IHByb3ZpZGUgcmVzb3VyY2VzIHRoYXQgY29udHJpYnV0ZSBwb3NpdGl2ZWx5DQogICB0byB0aGUg dG90YWwgY2FwYWNpdHkgb2YgdGhlIG92ZXJhbGwgc3lzdGVtIGFuZCB0aGVyZSBpcyBubyBzaW5n bGUNCiAgIHBvaW50IG9mIGZhaWx1cmUuICBUaGlzIGRpc3RyaWJ1dGVkIG5hdHVyZSBtYWtlcyB0 aGUgc3lzdGVtIGhpZ2hseQ0KICAgc2NhbGFibGUgYW5kIHJvYnVzdC4gIEluIGFkZGl0aW9uLCB0 aGUgcGVlci10by1wZWVyIHN5c3RlbSBpcyBzZWxmLQ0KICAgb3JnYW5pemVkLiAgVGhlc2UgZW5h YmxlIHNlcnZpY2VzIHRoYXQganVzdCB3b3JrLg0KDQogICBJbiBhIHBlZXItdG8tcGVlciBzeXN0 ZW0sIGlmIHRoZSBpbml0aWF0b3IgY2FuIGF1dGhlbnRpY2F0ZSB0aGUNCiAgIGFjY2VwdG9yIGFu ZCB0aGVuIGVzdGFibGlzaCB0cnVzdCBpbiB0aGUgaW5mb3JtYXRpb24gcmVjZWl2ZWQgZnJvbQ0K ICAgdGhlIHBlZXIsIG1hbnkgYXR0YWNrcyBzdWNoIGFzIHBvaXNvbmluZyAoZS5nLiBwcm92aWRp bmcgZGF0YQ0KICAgY29udGVudHMgYXJlIGRpZmZlcmVudCBmcm9tIHRoZSBkZXNjcmlwdGlvbikg YW5kIHBvbGx1dGluZyAoZS5nLg0KICAgaW5zZXJ0aW5nICJiYWQiIGNodW5rcy9wYWNrZXRzKSBj YW4gYmUgbWl0aWdhdGVkIG9yIGVsaW1pbmF0ZWQuDQogICBIb3dldmVyLCBjdXJyZW50bHkgdGhl cmUgaXMgbm8gaW50ZXJvcGVyYWJsZSBHU1MtQVBJIG1lY2hhbmlzbSBmb3INCiAgIHVzZSBpbiB0 aGVzZSBlbnZpcm9ubWVudHMuDQoNCiAgIFRoZSBQS1UyVSBwcm90b2NvbCBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQgZXh0ZW5kcyBQS0lOSVQgdG8gc3VwcG9ydA0KICAgcGVlci10by1wZWVyIGF1 dGhlbnRpY2F0aW9ucyB3aXRob3V0IHRoZSB1c2Ugb2YgS2V5IERpc3RyaWJ1dGlvbg0KICAgQ2Vu dGVyIChLREMpIFtSRkM0MTIwXS4gIFRodXMgaXQgZW5hYmxlcyBwZWVyIHRvIHBlZXIgYXV0aGVu dGljYXRpb24NCiAgIGJhc2VkIG9uIHB1YmxpYyBrZXkgY3J5cHRvZ3JhcGh5LiAgSW4gYWRkaXRp b24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcw0KICAgdGhlIGJpbmRpbmcgZm9yIEdTUy1BUEkgYmFz ZWQgb24gW1JGQzQxMjFdIGFuZCBbV1MtS0VSQl0sIHdoaWNoIG1ha2VzDQogICBQS1UyVSByZWFk aWx5IGF2YWlsYWJsZSB0byB0aGUgd2lkZWx5IGRlcGxveWVkIEdTUy1BUEkgYXBwbGljYXRpb25z Lg0KDQoNCjIgIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudA0KDQogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoNCg0KMyAgUHJvdG9jb2wgZGVzY3JpcHRpb24NCg0K ICAgVGhlIFBLVTJVIHJlYWxtIG5hbWUgaXMgYSByZXNlcnZlZCBuYW1lIHRoYXQgaXMgZGVmaW5l ZCBhY2NvcmRpbmcgdG8NCiAgIFtLUkItTkFNRV0uICBJdCBoYXMgdGhlIHZhbHVlIG9mICJSRVNF UlZFRDpQS1UyVSIuDQoNCiAgIFBLVTJVIHJlcGxhY2VzIHRoZSBLREMgaW4gW1JGQzQ1NTZdIHdp dGggdGhlIGlkZW50aXR5IG9mIHRoZQ0KICAgYWNjZXB0b3IsIGFuZCBpdCB1cGRhdGVzIHRoZSBw cm90b2NvbCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KICAgQWxsIHRoZSByZWFsbSBu YW1lcyBpbiBLZXJiZXJvcyBtZXNzYWdlcyBhcmUgZmlsbGVkIHdpdGggdGhlIFBLVTJVDQogICBy ZXNlcnZlZCByZWFsbS4NCg0KICAgVGhlIGNsaWVudCBuYW1lIGluIEFTLVJFUSBbUkZDNDEyMF0g Y29udGFpbnMgdGhlIG5hbWUgb2YgdGhlDQogICBpbml0aWF0b3IsIGFuZCB0aGUgc2VydmVyIG5h bWUgY29udGFpbnMgdGhlIEtlcmJlcm9zIG5hbWUgb2YgdGhlDQogICBhY2NlcHRvci4NCg0KICAg VGhlIGluaXRpYXRvciBzaWducyB0aGUgcHJlLWF1dGhlbnRpY2F0aW9uIGRhdGEgYXMgbmVlZGVk IHBlcg0KDQoNCg0KWmh1LCBldCBhbC4gICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxMSwgMjAw NyAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgUEtVMlUgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDYNCg0KDQogICBb UkZDNDEyMF0gYW5kIGNvbnN0cnVjdHMgYW4gQVMtUkVRLCBhbmQgdGhlbiBzZW5kcyB0aGUgcmVx dWVzdCB0byB0aGUNCiAgIGFjY2VwdG9yIHVzaW5nIHRoZSBzYW1lIEdTUy1BUEkgZW5jYXBzdWxh dGlvbiBkZWZpbmVkIGluIFtXUy1LRVJCXSwNCiAgIGV4Y2VwdCB0aGUgbWVjaGFuaXNtIE9iamVj dGlvbiBJZGVudGlmaWVyIChPSUQpIGZvciBQS1UyVSBpcyBpZC0NCiAgIGtlcmJlcm9zLXBrdTJ1 Lg0KDQogICAgICBpZC1rZXJiZXJvcy1wa3UydSA6Oj0NCiAgICAgICAgeyBpc28oMSkgb3JnKDMp IGRvZCg2KSBpbnRlcm5ldCgxKSBzZWN1cml0eSg1KSBrZXJiZXJvc1Y1KDIpDQogICAgICAgICAg cGt1MnUoNykgfQ0KDQogICBUaGUgY2xpZW50IGZpbGxzIG91dCB0aGUgcmVhbG0gZmllbGQgaW4g dGhlIFByb3h5RGF0YSBbV1MtS0VSQl0gdXNpbmcNCiAgIHRoZSByZXNlcnZlZCBQS1UyVSByZWFs bS4gIFVwb24gcmVjZWlwdCBvZiB0aGUgV1NfS1JCX1BST1hZIG1lc3NhZ2UsDQogICB0aGUgR1NT LUFQSSBhY2NlcHRvciBwcm9jZXNzZXMgdGhlIEtlcmJlcm9zIG1lc3NhZ2UgKGFuIEFTLVJFUSkg dGhhdA0KICAgZm9sbG93cyB0aGUgV1NfS1JCX1BST1hZIGhlYWRlci4NCg0KICAgVGhlIGFjY2Vw dG9yIHZhbGlkYXRlcyB0aGUgcHJlLWF1dGhlbnRpY2F0aW9uIGRhdGEgaW4gdGhlIHJlcXVlc3Qg cGVyDQogICBTZWN0aW9uIDMuMi4yIG9mIFtSRkM0NTU2XSBhbmQgaXQgTVVTVCB2ZXJpZnkgdGhl IGJpbmRpbmcgYmV0d2VlbiB0aGUNCiAgIGNsaWVudCBuYW1lIGFuZCB0aGUgY2xpZW50J3Mgc2ln bmluZyBrZXksIGlmIHRoZSBwcmUtYXV0aGVudGljYXRpb24NCiAgIGRhdGEgaW4gdGhlIHJlcXVl c3QgaXMgc2lnbmVkLiAgVGhlIGNsaWVudCdzIFguNTA5IGNlcnRpZmljYXRlLCBpZg0KICAgcHJl c2VudCwgTVVTVCBjb250YWluIGlkLXBraW5pdC1LUENsaWVudEF1dGggW1JGQzQ1NTZdIG9yIGlk LWtwLQ0KICAgY2xpZW50QXV0aCBbUkZDMzI4MF0uICBJZiB0aGUgY2xpZW50IGlzIGF1dGhlbnRp Y2F0ZWQgYXMgZXhwZWN0ZWQsDQogICB0aGUgYWNjZXB0b3IgaXNzdWVzIGEgc2VydmljZSB0aWNr ZXQgdG8gdGhlIGluaXRpYXRvciBwZXIgW1JGQzQxMjBdLg0KDQogICBVcG9uIHJlY2VpcHQgb2Yg dGhlIHJlcGx5LCB0aGUgaW5pdGlhdG9yIHZhbGlkYXRlcyB0aGUgcHJlLQ0KICAgYXV0aGVudGlj YXRpb24gZGF0YSBpbiB0aGUgcmVwbHkgcGVyIFNlY3Rpb24gMy4yLjQgb2YgW1JGQzQ1NTZdLiAg QXMNCiAgIHN0YXRlZCBlYXJsaWVyLCB0aGVyZSBpcyBubyBLREMgaW4gUEtVMlUsIHRodXMgdGhl IHJlcXVpcmVtZW50IG9mIHRoZQ0KICAgaWQtcGtpbml0LUtQS2RjIGlzIG5vdCBhcHBsaWNhYmxl IHdoZW4gUEtVMlUgaXMgdXNlZC4gIFRoZSBpbml0aWF0b3INCiAgIE1VU1QgdmVyaWZ5IHRoZSBi aW5kaW5nIGJldHdlZW4gdGhlIHNpZ25pbmcga2V5IGluIHRoZSByZXBseSBhbmQgdGhlDQogICBh Y2NlcHRvci4gIFdoZW4gdGhlIEdTUy1BUEkgYWNjZXB0b3IgaXMgaWRlbnRpZmllZCB1c2luZyB0 aGUNCiAgIHRhcmdfbmFtZSBwYXJhbWV0ZXIgb2YgdGhlIEdTU19Jbml0X3NlY19jb250ZXh0KCkg Y2FsbCwgdGhlIHNpZ25pbmcNCiAgIGtleSBNVVNUIGJlIGJvdW5kIHdpdGggdGhlIHRhcmdfbmFt ZS4gIFRoZSBhY2NlcHRvcidzIFguNTA5DQogICBjZXJ0aWZpY2F0ZSBNVVNUIGNvbnRhaW4gaWQt a3AtY2xpZW50QXV0aCBbUkZDMzI4MF0gb3IgaWQta3AtDQogICBzZXJ2ZXJBdXRoIFtSRkMzMjgw XSBvciBpZC1wa2luaXQtS1BDbGllbnRBdXRoIFtSRkM0NTU2XS4NCg0KICAgVGhlIEtlcmJlcm9z IHByaW5jaXBhbCBuYW1lIGZvcm0gYW5kIHRoZSBob3N0LWJhc2VkIHNlcnZpY2UgTmFtZQ0KICAg ZGVzY3JpYmVkIGluIFtSRkMxOTY0XSBNVVNUIGJlIHN1cHBvcnRlZCBieSBjb25mb3JtaW5nDQog ICBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQogICBPbmNlIHRoZSBB Uy1SRVAgaW4gdGhlIHJlcGx5IGlzIGFjY2VwdGVkLCB0aGUgaW5pdGlhdG9yIGNhbiB1c2UgdGhl DQogICBvYnRhaW5lZCBzZXJ2aWNlIHRvIGNvbnN0cnVjdCBhbiBBUC1SRVEgYW5kIGNvbW11bmlj YXRlIHdpdGggdGhlDQogICBhY2NlcHRvci4gIFRoZSByZXN0IG9mIHRoZSBwcm90b2NvbCBhbmQg dGhlIEdTUy1BUEkgYmluZGluZyBhcmUgdGhlDQogICBzYW1lIGFzIGRlZmluZWQgaW4gW1dTLUtF UkJdIGFuZCBbUkZDNDEyMV0uDQoNCg0KNCAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFtSRkM0NTU2XSBhcHBseSBoZXJlLiAgSW4g YWRkaXRpb24sDQogICB0aGUgaW5pdGlhdG9yIGFuZCB0aGUgYWNjZXB0b3IgTVVTVCBiZSBhYmxl IHRvIHZlcmlmeSB0aGUgYmluZGluZw0KICAgYmV0d2VlbiB0aGUgc2lnbmluZyBrZXkgYW5kIHRo ZSBhc3NvY2lhdGVkIGlkZW50aXR5Lg0KDQoNCg0KWmh1LCBldCBhbC4gICAgICAgICAgICAgICBF eHBpcmVzIE1heSAxMSwgMjAwNyAgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgUEtVMlUgICAgICAgICAgICAgICAgICAgIE5vdmVt YmVyIDIwMDYNCg0KDQo1ICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxk IGxpa2UgdGhhbmtzIEplZmZlcnkgSHV0emVsbWFuIGZvciBoaXMgY29tbWVudHMgd2l0aA0KICAg cmVnYXJkaW5nIHRvIHVuaWZ5aW5nIFtXUy1LRVJCXSB3aXRoIFBLVTJVIC4NCg0KDQo2ICBJQU5B IENvbnNpZGVyYXRpb25zDQoNCiAgIFNlY3Rpb24gMyBkZWZpbmVzIHRoZSBQS1UyVSByZWFsbS4g IFRoZSBJQU5BIHJlZ2lzdHJ5IGZvciB0aGUNCiAgIHJlc2VydmVkIG5hbWVzIHNob3VsZCBiZSB1 cGRhdGVkIHRvIHJlZmVyZW5jZSB0aGlzIGRvY3VtZW50Lg0KDQoNCjcuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcw0KDQogICBbS1JCLU5BTUVdIEwuIFpodSwgIkFkZGl0aW9uYWwgS2VyYmVyb3MgTmFt aW5nIENvbnN0cmFpbnRzIiwgDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYta3JiLXdnLW5hbWlu Zywgd29yayBpbiBwcm9ncmVzcy4NCg0KICAgW1JGQzE5NjRdICBMaW5uLCBKLiwgIlRoZSBLZXJi ZXJvcyBWZXJzaW9uIDUgR1NTLUFQSSBNZWNoYW5pc20iLA0KICAgICAgICAgICAgICBSRkMgMTk2 NCwgSnVuZSAxOTk2Lg0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZl bHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMjc0M10gIExpbm4s IEouLCAiR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlIEFwcGxpY2F0aW9uIFByb2dyYW0NCiAgICAg ICAgICAgICAgSW50ZXJmYWNlIFZlcnNpb24gMiwgVXBkYXRlIDEiLCBSRkMgMjc0MywgSmFudWFy eSAyMDAwLg0KDQogICBbUkZDMzI4MF0gIEhvdXNsZXksIFIuLCBQb2xrLCBXLiwgRm9yZCwgVy4s IGFuZCBELiBTb2xvLCAiSW50ZXJuZXQNCiAgICAgICAgICAgICAgWC41MDkgUHVibGljIEtleSBJ bmZyYXN0cnVjdHVyZSBDZXJ0aWZpY2F0ZSBhbmQNCiAgICAgICAgICAgICAgQ2VydGlmaWNhdGUg UmV2b2NhdGlvbiBMaXN0IChDUkwpIFByb2ZpbGUiLCBSRkMgMzI4MCwNCiAgICAgICAgICAgICAg QXByaWwgMjAwMi4NCg0KICAgW1JGQzQxMjBdICBOZXVtYW4sIEMuLCBZdSwgVC4sIEhhcnRtYW4s IFMuLCBhbmQgSy4gUmFlYnVybiwgIlRoZQ0KICAgICAgICAgICAgICBLZXJiZXJvcyBOZXR3b3Jr IEF1dGhlbnRpY2F0aW9uIFNlcnZpY2UgKFY1KSIsIFJGQyA0MTIwLA0KICAgICAgICAgICAgICBK dWx5IDIwMDUuDQoNCiAgIFtSRkM0MTIxXSAgWmh1LCBMLiwgSmFnYW5hdGhhbiwgSy4sIGFuZCBT LiBIYXJ0bWFuLCAiVGhlIEtlcmJlcm9zDQogICAgICAgICAgICAgIFZlcnNpb24gNSBHZW5lcmlj IFNlY3VyaXR5IFNlcnZpY2UgQXBwbGljYXRpb24gUHJvZ3JhbQ0KICAgICAgICAgICAgICBJbnRl cmZhY2UgKEdTUy1BUEkpIE1lY2hhbmlzbTogVmVyc2lvbiAyIiwgUkZDIDQxMjEsDQogICAgICAg ICAgICAgIEp1bHkgMjAwNS4NCg0KICAgW1JGQzQxNzhdICBaaHUsIEwuLCBMZWFjaCwgUC4sIEph Z2FuYXRoYW4sIEsuLCBhbmQgVy4gSW5nZXJzb2xsLCAiVGhlDQogICAgICAgICAgICAgIFNpbXBs ZSBhbmQgUHJvdGVjdGVkIEdlbmVyaWMgU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbg0KICAg ICAgICAgICAgICBQcm9ncmFtIEludGVyZmFjZSAoR1NTLUFQSSkgTmVnb3RpYXRpb24gTWVjaGFu aXNtIiwNCiAgICAgICAgICAgICAgUkZDIDQxNzgsIE9jdG9iZXIgMjAwNS4NCg0KICAgW1JGQzQ1 NTZdICBaaHUsIEwuIGFuZCBCLiBUdW5nLCAiUHVibGljIEtleSBDcnlwdG9ncmFwaHkgZm9yIElu aXRpYWwNCiAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gaW4gS2VyYmVyb3MgKFBLSU5JVCki LCBSRkMgNDU1NiwgSnVuZSAyMDA2Lg0KDQoNCg0KDQpaaHUsIGV0IGFsLiAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDExLCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBQS1UyVSAgICAgICAgICAgICAgICAgICAgTm92 ZW1iZXIgMjAwNg0KDQoNCiAgIFtXUy1LRVJCXSBMLiBaaHUsICJLZXJiZXJvcyBmb3IgV2ViIFNl cnZpY2VzIiwgZHJhZnQtemh1LXdzLWtlcmIsIHdvcmsNCiAgICAgICAgICAgICBpbiBwcm9ncmVz cy4NCiAgICAgICAgICAgICANCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBMYXJyeSBaaHUNCiAg IE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KICAgT25lIE1pY3Jvc29mdCBXYXkNCiAgIFJlZG1vbmQs IFdBICA5ODA1Mg0KICAgVVMNCg0KICAgRW1haWw6IGx6aHVAbWljcm9zb2Z0LmNvbQ0KDQoNCiAg IEFyaSBNZWR2aW5za3kNCiAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbg0KICAgT25lIE1pY3Jvc29m dCBXYXkNCiAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KICAgVVMNCg0KICAgRW1haWw6IGFyaW1lZEBt aWNyb3NvZnQuY29tDQoNCg0KICAgSmVmZmVyeQ0KICAgU2VjdXJlIEVuZCBQb2ludHMNCiAgIDYx MiBXZXN0IDExNXRoIFN0cmVldCBSb29tIDcxNg0KICAgTmV3IFlvcmssIE5ZICAxMDAyNQ0KICAg VVMNCg0KICAgRW1haWw6IGphbHRtYW5Ac2VjdXJlZW5kcG9pbnQuY29tDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaHUsIGV0IGFsLiAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDExLCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBQS1UyVSAgICAgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAwNg0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQogICBDb3B5cmln aHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4NCg0KICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMNCiAgIGNv bnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQog ICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUv U0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVS TkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5H IEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElN UExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBUaGUg SUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9m IGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhh dCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv ciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1p Z2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0 IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBz dWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3Bl Y3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzgg YW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBv YnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMN CiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJ UFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJ RVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlv biBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Ig b3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRo YXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0 Zi5vcmcuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0 b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZlIFN1 cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0KDQoNCg0KDQoNClpodSwgZXQgYWwuICAgICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMTEsIDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KDQo= ------_=_NextPart_001_01C70252.137285A1 Content-Type: text/plain; name="draft-zhu-ws-kerb-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-zhu-ws-kerb-01.txt Content-Disposition: attachment; filename="draft-zhu-ws-kerb-01.txt" DQoNCk5FVFdPUksgV09SS0lORyBHUk9VUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEwuIFpodQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnBvcmF0aW9uDQpVcGRhdGVzOiA0MTIwIChpZiBh cHByb3ZlZCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDYNCklu dGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQpFeHBpcmVzOiBBcHJpbCA0LCAyMDA3DQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICBLZXJiZXJvcyBmb3IgV2ViIFNlcnZpY2VzDQogICAg ICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LXpodS13cy1rZXJiLTAxDQoNClN0YXR1cyBvZiB0 aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1 dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJ UFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdp bGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBh d2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBC Q1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhl IEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAg VGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQog ICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBs aXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgNCwgMjAwNy4NCg0KQ29weXJpZ2h0IE5vdGlj ZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4NCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gdGhlIEtlcmJl cm9zIHByb3RvY29sIGFuZCB0aGUNCiAgIEdTUy1BUEkgS2VyYmVyb3MgbWVjaGFuaXNtIHRoYXQg ZW5hYmxlIGEgR1NTLUFQSSBLZXJiZXJvcyBjbGllbnQgdG8NCiAgIGV4Y2hhbmdlIG1lc3NhZ2Vz IHdpdGggdGhlIEtEQyB1c2luZyB0aGUgR1NTLUFQSSBhY2NlcHRvciBhcyB0aGUNCiAgIHByb3h5 LCBieSBlbmNhcHN1bGF0aW5nIHRoZSBLZXJiZXJvcyBtZXNzYWdlcyBpbnNpZGUgR1NTLUFQSSB0 b2tlbnMuDQogICBXaXRoIHRoZXNlIGV4dGVuc2lvbnMsIEtlcmJlcm9zIGlzIHN1aXRhYmxlIGZv ciBzZWN1cmluZw0KICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHdlYiBz ZXJ2aWNlcyBvdmVyIHRoZSBJbnRlcm5ldC4NCg0KDQoNCg0KWmh1ICAgICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDQsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBXUy1LRVJCICAgICAgICAgICAgICAgICAg ICBPY3RvYmVyIDIwMDYNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMN CiAgIDIuICBDb252ZW50aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMw0KICAgMy4gIEdTUy1BUEkgRW5jYXBzdWxhdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICA0LiAgQWRkcmVzc2VzIGluIFRp Y2tldHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYNCiAgIDUu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gNg0KICAgNi4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3DQogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcNCiAgIDguICBOb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNw0KICAgQXV0aG9yJ3MgQWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiA4DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHly aWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDkNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNClpodSAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA0LCAyMDA3ICAgICAg ICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg V1MtS0VSQiAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA2DQoNCg0KMS4gIEludHJvZHVj dGlvbg0KDQogICBUaGUgS2VyYmVyb3MgW1JGQzQxMjBdIHByZS1hdXRoZW50aWNhdGlvbiBmcmFt ZXdvcmsgW0tSQi1QQUZXXQ0KICAgcHJvbWlzZXMgbWluaW1hbCBvciBubyBleHBvc3VyZSBvZiB3 ZWFrIGNsaWVudCBrZXlzIGFuZCBzdHJvbmcgY2xpZW50DQogICBhdXRoZW50aWNhdGlvbi4gIFRo ZSBLZXJiZXJvcyBzdXBwb3J0IG9mIGFub255bWl0eSBbS1JCLUFOT05dDQogICBwcm92aWRlcyBm b3IgcHJpdmFjeS4gIFRoZXNlIGFkdmFuY2VtZW50cyBtYWtlIEtlcmJlcm9zIHN1aXRhYmxlIG92 ZXINCiAgIHRoZSBJbnRlcm5ldC4NCg0KICAgVGhlIHRyYWRpdGlvbmFsIGNsaWVudC1wdXNoIEtl cmJlcm9zIHByb3RvY29sIGRvZXMgbm90IHdvcmsgd2VsbCBpbg0KICAgdGhlIFdlYiBzZXJ2aWNl cyBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIEtEQyBpcyBub3QgYWNjZXNzaWJsZSB0byB0aGUNCiAg IGNsaWVudCwgYnV0IGlzIGFjY2Vzc2libGUgdG8gdGhlIHdlYiBzZXJ2ZXIuICBGb3IgZXhhbXBs ZSwgdGhlIEtEQyBpcw0KICAgY29tbW9ubHkgcGxhY2VkIGJlaGluZCBhIGZpcmV3YWxsIHRvZ2V0 aGVyIHdpdGggdGhlIGFwcGxpY2F0aW9uDQogICBzZXJ2ZXIuICBUaGUgbGFjayBvZiBhY2Nlc3Np YmlsaXR5IHRvIHRoZSBLREMgYnkgdGhlIGNsaWVudCBjb3VsZA0KICAgYWxzbyBvY2N1ciBhcmUg d2hlbiB0aGUgY2xpZW50IGRvZXMgbm90IGhhdmUgYW4gSVAgYWRkcmVzcyBwcmlvciB0bw0KICAg YXV0aGVudGljYXRpbmcgdG8gYW4gYWNjZXNzIHBvaW50Lg0KDQogICBHZW5lcmljIFNlY3VyaXR5 IFNlcnZpY2UgQXBwbGljYXRpb24gUHJvZ3JhbSBJbnRlcmZhY2UgKEdTUy1BUEkpDQogICBbUkZD Mjc0M10gYWxsb3dzIHNlY3VyaXR5IG1lY2hhbmlzbXMgZXhjaGFuZ2UgYXJiaXRyYXJ5IG1lc3Nh Z2VzDQogICBiZXR3ZWVuIHRoZSBpbml0aWF0b3IgYW5kIHRoZSBhY2NlcHRvciB2aWEgdGhlIGFw cGxpY2F0aW9uIHRyYWZmaWMsDQogICBpbmRlcGVuZGVudCBvZiB0aGUgdW5kZXJseWluZyB0cmFu c3BvcnRzLiAgQSBwcm90b2NvbCBiYXNlZCBvbg0KICAgW1JGQzQxMjFdIGlzIHRodXMgZGVmaW5l ZCB0byBhbGxvdyB0aGUgR1NTLUFQSSBpbml0aWF0b3IgdG8gZXhjaGFuZ2UNCiAgIEtlcmJlcm9z IG1lc3NhZ2VzIHdpdGggdGhlIEtEQyBieSB1c2luZyB0aGUgR1NTLUFQSSBhY2NlcHRvciBhcyB0 aGUNCiAgIHByb3h5LiAgVGhlIGFjY2VwdG9yLXB1bGwgbW9kZWwgZGVmaW5lZCBpbiB0aGlzIHNw ZWNpZmljYXRpb24gaXMNCiAgIGJlbmVmaWNhbCBmb3IgaW5pdGlhdG9ycyB3aXRoIGxpbWl0ZWQg cHJvY2Vzc2luZyBwb3dlciBzdWNoIGFzIG1vYmlsZQ0KICAgZGV2aWNlcywgb3Igd2hlbiB0aGUg dHJhbnNwb3J0IGxheWVyIGJldHdlZW4gdGhlIGluaXRpYXRvciBhbmQgdGhlDQogICBhY2NlcHRv ciBoYXMgaGlnaCBuZXR3b3JrIGxhdGVuY3kuDQoNCiAgICAgICAgICAgQ2xpZW50IC0tLS0tLS0t LSBXUy1LRVJCIHByb3h5IC0tLS0tLS0tLS0gS0RDDQoNCiAgIFRoZSBLZXJiZXJvcyBjbGllbnQg TVVTVCBhdm9pZCBleHBvc3VyZSBvZiBsb25nIHRlcm0gY2xpZW50IGtleXMgdG8NCiAgIHRoZSBH U1MtQVBJIGFjY2VwdG9yLCBiZWZvcmUgYW5kIGFmdGVyIHRoZSBLZXJiZXJvcyBzZXJ2ZXIgaXMN CiAgIGF1dGhlbnRpY2F0ZWQuICBUaGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgdXNpbmcgS2Vy YmVyb3MtRkFTVCBbS1JCLQ0KICAgUEFGV10uICBGdXJ0aGVybW9yZSwgdGhlIGluaXRpYXRvciBj YW4gdXNlIHRoZSBhbm9ueW1vdXMgb3B0aW9uIGFzDQogICBkZWZpbmVkIGluIFNlY3Rpb24gNi41 LjIgb2YgW0tSQi1QQUZXXSwgdG8gaGlkZSB0aGUgY2xpZW50IGlkZW50aXR5DQogICBmcm9tIGFk dmVyc2FyeSB3aG8gY2FuIGVhdmVzZHJvcCB0aGUgYXBwbGljYXRpb24gdHJhZmZpYy4NCg0KDQoy LiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERvY3VtZW50DQoNCiAgIFRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAg ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMyMTE5XS4NCg0KDQozLiAgR1NTLUFQSSBFbmNhcHN1bGF0aW9uDQoNCiAgIFRo ZSBtZWNoYW5pc20gT2JqZWN0aW9uIElkZW50aWZpZXIgKE9JRCkgZm9yIEdTUy1BUEkgV1MtS0VS QiwgaW4NCiAgIGFjY29yZGFuY2Ugd2l0aCB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIGJ5IFtSRkM0 MTc4XSBmb3IgbmVnb3RpYXRpbmcNCg0KDQoNClpodSAgICAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBcHJpbCA0LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgV1MtS0VSQiAgICAgICAgICAgICAgICAgICAgT2N0b2Jl ciAyMDA2DQoNCg0KICAgcHJvdG9jb2wgdmFyaWF0aW9ucywgaXMgaWQta2VyYmVyb3Mtd3MuDQoN CiAgICAgIGlkLWtlcmJlcm9zLXdzIDo6PQ0KICAgICAgICB7IGlzbygxKSBvcmcoMykgZG9kKDYp IGludGVybmV0KDEpIHNlY3VyaXR5KDUpIGtlcmJlcm9zVjUoMikNCiAgICAgICAgICB3ZWJTZXJ2 aWNlKDYpIH0NCg0KICAgVGhlIGZpcnN0IHRva2VuIG9mIHRoZSBHU1MtQVBJIFdTLUtFUkIgbWVj aGFuaXNtIE1VU1QgaGF2ZSB0aGUNCiAgIGdlbmVyaWMgdG9rZW4gZnJhbWluZyBkZXNjcmliZWQg aW4gc2VjdGlvbiAzLjEgb2YgW1JGQzI3NDNdIHdpdGggdGhlDQogICBtZWNoYW5pc20gT0lEIGJl aW5nIGlkLWtlcmJlcm9zLXdzLCBhbmQgYW55IHN1YnNlcXVlbnQgR1NTLUFQSSBXUy0NCiAgIEtF UkIgdG9rZW4gTVVTVCBOT1QgaGF2ZSB0aGlzIGZyYW1pbmcuDQoNCiAgIFRoZSBHU1MtQVBJIFdT LUtFUkIgbWVjaGFuaXNtIE1VU1QgYWx3YXlzIHByb3ZpZGUgbXV0dWFsDQogICBhdXRoZW50aWNh dGlvbiwgZXZlbiBpZiB0aGUgaW5pdGlhdG9yIGRvZXMgbm90IGFzayBmb3IgaXQuICBXaGVuDQog ICBtdXR1YWwtYXV0aGVudGljYXRpb24gaXMgcGVyZm9ybWVkLCB0aGUgR1NTLUFQSSBhY2NlcHRv ciB3aWxsIGFsd2F5cw0KICAgc2VuZCBiYWNrIGFuIEFQLVJFUCwgYW5kIGFzIGRlc2NyaWJlZCBs YXRlciBpbiB0aGlzIHNlY3Rpb24gdGhpcw0KICAgbWVjaGFuaXNtIHByb3ZpZGVzIGludGVncml0 eSBwcm90ZWN0aW9uIGZvciBhbGwgaW5pdGlhdG9yLWFjY2VwdG9yDQogICBwcm94eSBtZXNzYWdl IGV4Y2hhbmdlcy4NCg0KICAgVGhlIGlubmVyVG9rZW4gZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4x IG9mIFtSRkMyNzQzXSBhbmQgc3Vic2VxdWVudA0KICAgR1NTLUFQSSB0b2tlbnMgaGF2ZSB0aGUg Zm9sbG93aW5nIGZvcm1hdHM6IGl0IHN0YXJ0cyB3aXRoIGEgdHdvLW9jdGV0DQogICB0b2tlbi1p ZGVudGlmaWVyIChUT0tfSUQpLCBmb2xsb3dlZCBieSBhIFdTLUtFUkIgbWVzc2FnZSBvciBhDQog ICBLZXJiZXJvcyBtZXNzYWdlLg0KDQoNCiAgICAgICAgICAgICBUb2tlbi9NZXNzYWdlICAgICAg IFRPS19JRCBWYWx1ZSBpbiBIZXgNCiAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICBXU19LUkJfUFJPWFkgICAgICAgICAwNSAw MQ0KDQogICBPbmx5IG9uZSBXUy1LRVJCIHNwZWNpZmljIG1lc3NhZ2UsIG5hbWVseSB0aGUgV1Nf S1JCX1BST1hZIG1lc3NhZ2UsDQogICBpcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICBUaGUg VE9LX0lEIHZhbHVlcyBmb3IgW1JGQzQxMjBdDQogICBLZXJiZXJvcyBtZXNzYWdlcyBhcmUgdGhl IHNhbWUgYXMgdGhvc2UgZGVmaW5lZCBmb3IgdGhlIEdTUy1BUEkNCiAgIEtlcmJlcm9zIG1lY2hh bmlzbSBbUkZDNDEyMV0uDQoNCiAgIFRoZSBtZXNzYWdlIG9mIHRoZSBXU19LUkJfUFJPWFkgdHlw ZSBpcyBkZWZpbmVkIGFzIGEgV1MtS1JCLUhFQURFUg0KICAgc3RydWN0dXJlIGltbWVkaWF0ZWx5 IGZvbGxvd2VkIGJ5IGEgS2VyYmVyb3MgbWVzc2FnZS4gIFRoZSBLZXJiZXJvcw0KICAgbWVzc2Fn ZSBjYW4gYmUgYW4gQVMtUkVRLCBhbiBBUy1SRVAsIGEgVEdTLVJFUSwgYSBUR1MtUkVQLCBvciBh IEtSQi0NCiAgIEVSUk9SIGFzIGRlZmluZWQgaW4gW1JGQzQxMjBdLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNClpodSAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA0LCAy MDA3ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgV1MtS0VSQiAgICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDA2DQoNCg0KICAg ICAgICAgICBXUy1LUkItSEVBREVSIDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAgICAgICBwcm94 eS1kYXRhICAgICAgWzFdIFByb3h5RGF0YSwNCiAgICAgICAgICAgICAgIC4uLg0KICAgICAgICAg ICB9DQoNCiAgICAgICAgICAgUHJveHlEYXRhIDo6ID0gU0VRVUVOQ0Ugew0KICAgICAgICAgICAg ICAgcmVhbG0gICAgICAgICAgIFsxXSBSZWFsbSwNCiAgICAgICAgICAgICAgIGNvb2tpZSAgICAg ICAgICBbM10gT0NURVQgU1RSSU5HIE9QVElPTkFMLA0KICAgICAgICAgICAgICAgICAgLS0gb3Bh cXVlIGRhdGEsIGlmIHNlbnQgYnkgdGhlIGFjY2VwdG9yLA0KICAgICAgICAgICAgICAgICAgLS0g TVVTVCBiZSBjb3BpZWQgYnkgdGhlIGNsaWVudCB1bmNoYW5nZWQgaW50bw0KICAgICAgICAgICAg ICAgICAgLS0gdGhlIG5leHQgV1MtS0VSQiBtZXNzYWdlLg0KICAgICAgICAgICAgICAgLi4uDQog ICAgICAgICAgIH0NCg0KDQogICBUaGUgV1MtS1JCLUhFQURFUiBzdHJ1Y3R1cmUgYW5kIGFsbCB0 aGUgS2VyYmVyb3MgbWVzc2FnZXMgTVVTVCBiZQ0KICAgZW5jb2RlZCB1c2luZyBBYnN0cmFjdCBT eW50YXggTm90YXRpb24gT25lIChBU04uMSkgRGlzdGluZ3Vpc2hlZA0KICAgRW5jb2RpbmcgUnVs ZXMgKERFUikgW1g2ODBdIFtYNjkwXS4NCg0KICAgVGhlIEdTUy1BUEkgaW5pdGlhdG9yIGZpbGxz IG91dCB0aGUgcmVhbG0gZmllbGQgaW4gdGhlIFByb3h5RGF0YSBvZg0KICAgdGhlIGZpcnN0IHJl cXVlc3Qgd2l0aCB0aGUgY2xpZW50IHJlYWxtLiAgSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBrbm93 DQogICB0aGUgY2xpZW50IHJlYWxtIFtSRUZFUkFMU10sIGl0IE1VU1QgZmlsbCBpdCBvdXQgdXNp bmcgdGhlIGNsaWVudCdzDQogICBkZWZhdWx0IHJlYWxtIG5hbWUgc3VjaCBhcyB0aGUgcmVhbG0g b2YgdGhlIGNsaWVudCBob3N0LiAgVHlwaWNhbGx5DQogICB0aGUgS2VyYmVyb3MgbWVzc2FnZSBp biB0aGUgZmlyc3QgV1NfS1JCX1BST1hZIG1lc3NhZ2UgZnJvbSB0aGUNCiAgIGNsaWVudCBpcyBh biBBUy1SRVEgbWVzc2FnZS4NCg0KICAgVXBvbiByZWNlaXB0IG9mIHRoZSBXU19LUkJfUFJPWFkg bWVzc2FnZSwgdGhlIEdTUy1BUEkgV1MtS0VSQg0KICAgYWNjZXB0b3IgTVVTVCB1c2UgdGhlIHBy b3h5LWRhdGEgaW4gdGhlIG1lc3NhZ2UgZnJvbSB0aGUgY2xpZW50IHRvDQogICBsb2NhdGUgdGhl IEtEQyBhbmQgc2VuZHMgdGhlIGVuY2Fwc3VsYXRlZCBLZXJiZXJvcyBtZXNzYWdlIHRvIHRoYXQN CiAgIEtEQy4gIFVubGVzcyBvdGhlcndpc2Ugc3BlY2lmaWVkLCB0aGUgYWNjZXB0b3IgY2FuIGxv Y2F0ZSB0aGUgS0RDIHBlcg0KICAgU2VjdGlvbiA3LjIuMy4yIG9mIFtSRkM0MTIwXS4NCg0KICAg SW4gb3JkZXIgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2Ygcm91bmR0cmlwcyBiZXR3ZWVuIHRoZSBp bml0aWF0b3IgYW5kDQogICB0aGUgYWNjZXB0b3IsIHRoZSBhY2NlcHRvciBTSE9VTEQgcHJvY2Vz cyBhbnkgbWVzc2FnZSBleGNoYW5nZSB3aXRoDQogICB0aGUgS0RDIGlmIHRoZSBleGNoYW5nZSBp cyB1bmF1dGhlbnRpY2F0ZWQsIHN1Y2ggYXMgY2xpZW50LXJlZmVycmFsDQogICBtZXNzYWdlIGV4 Y2hhbmdlIFtSRUZFUkFMU10uICBJZiB0aGUgYWNjZXB0b3IgY2FuIG5vdCBwcm9jZXNzIHRoZSBL REMNCiAgIHJlc3BvbnNlIGJ5IGl0c2VsZiwgZm9yIGV4YW1wbGUgd2hlbiB0aGUga25vd2xlZGdl IG9mIHRoZSBjbGllbnQga2V5cw0KICAgaXMgcmVxdWlyZWQsIGl0IHNlbmRzIGJhY2sgdG8gdGhl IGNsaWVudCB0aGUgS0RDIHJlcGx5IG1lc3NhZ2UNCiAgIGVuY2Fwc3VsYXRlZCBpbiBhIFdTX0tS Ql9QUk9YWSBtZXNzYWdlLiAgVGhlIGFjY2VwdG9yIE1VU1QgZmlsbCBvdXQNCiAgIHRoZSByZWFs bSBuYW1lIHdob3NlIEtEQyBwcm9kdWNlZCB0aGUgcmVzcG9uc2UuICBUaGUgYWNjZXB0b3IgU0hP VUxEDQogICB1c2UgdGhlIGtkYy1yZWZlcnJhbHMgb3B0aW9uIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDYuNS4yIG9mIFtLUkItUEFGV10NCiAgIHRvIGFsbG93IHRoZSBLREMgb2YgdGhlIGNsaWVudCdz IHJlYWxtIHRvIG9idGFpbiBhIHNlcnZpY2UgdGlja2V0DQogICBhZGRyZXNzZWQgdG8gdGhlIGFj Y2VwdG9yLCB0aHVzIGZ1cnRoZXIgcmVkdWNlIHRoZSBudW1iZXIgb2YNCiAgIHJvdW5kdHJpcHMg YmV0d2VlbiB0aGUgR1NTLUFQSSBpbml0aWF0b3IgYW5kIHRoZSBHU1MtQVBJIGFjY2VwdG9yLg0K ICAgVGhlIEdTUy1BUEkgYWNjZXB0b3IgY2FuIHNlbmQgb3BhcXVlIGRhdGEgaW4gdGhlIGNvb2tp ZSBmaWVsZCBvZiB0aGUNCiAgIFdTLUtSQi1IRUFERVIgc3RydWN0dXJlIGluIHRoZSByZXBseSBm cm9tIHRoZSBhY2NlcHRvciB0byB0aGUNCiAgIGluaXRpYXRvciwgaW4gb3JkZXIgdG8sIGZvciBl eGFtcGxlLCB0byBmYWNpbGl0YXRlIHN0YXRlIG1hbmFnZW1lbnRzDQogICBvbiB0aGUgR1NTLUFQ SSBhY2NlcHRvci4gIFRoZSBjb250ZW50IGFuZCB0aGUgZW5jb2Rpbmcgb2YgdGhlIGNvb2tpZQ0K DQoNCg0KWmh1ICAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDQsIDIwMDcgICAg ICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICBXUy1LRVJCICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDYNCg0KDQogICBmaWVsZCBp cyBhIGxvY2FsIG1hdHRlciBvZiB0aGUgYWNjZXB0b3IuICBUaGUgaW5pdGlhdG9yIE1VU1QgY29w eSB0aGUNCiAgIHZlcmJhdGltIGNvb2tpZSBmcm9tIHRoZSBwcmV2aW91cyBhY2NlcHRvciByZXNw b25zZSwgd2hlbiB0aGUgY29va2llDQogICBpcyBwcmVzZW50LCB3aGVuZXZlciBpdCBzZW5kcyBh biBhZGRpdGlvbmFsIFdTLUtSQi1QUk9YWSBtZXNzYWdlIHRvDQogICB0aGUgYWNjZXB0b3IuICBU aGUgY2xpZW50IHByb2Nlc3NlcyB0aGUgS0RDIHJlc3BvbnNlLCBhbmQgZmlsbHMgb3V0DQogICB0 aGUgcmVhbG0gbmFtZSBpdCBiZWxpZXZlcyB0byB3aG9tIHRoZSBhY2NlcHRvciBzaG91bGQgc2Vu ZCB0aGUNCiAgIGVuY2Fwc3VsYXRlZCBLZXJiZXJvcyBtZXNzYWdlLg0KDQogICBXaGVuIHRoZSBj bGllbnQgb2J0YWlucyBhIHNlcnZpY2UgdGlja2V0LCB0aGUgaW5pdGlhdG9yIHRoZW4gc2VuZHMg YQ0KICAgS1JCX0FQX1JFUSBtZXNzYWdlIHRvIHRoZSBhY2NlcHRvciwgYW5kIHByb2NlZWQgYXMg ZGVmaW5lZCBpbg0KICAgW1JGQzQxMjFdLiAgQSBHU1MtQVBJIGF1dGhlbnRpY2F0b3IgZXh0ZW5z aW9uIFtHU1MtRVhUU10gTVVTVCBiZSBzZW50DQogICBieSB0aGUgaW5pdGlhdG9yLiAgVGhlIGV4 dGVuc2lvbiB0eXBlIGlzIDIgYW5kIHRoZSBjb250ZW50IGlzIHRoZQ0KICAgQVNOLjEgREVSIGVu Y29kaW5nIG9mIHRoZSB0eXBlIENoZWNrc3VtLiAgVGhlIGNoZWNrc3VtIGlzIHBlcmZvcm1lZA0K ICAgb3ZlciBhbGwgR1NTLUFQSSBtZXNzYWdlcyBhcyBleGNoYW5nZWQgYmV0d2VlbiB0aGUgaW5p dGlhdG9yIGFuZCB0aGUNCiAgIGFjY2VwdG9yIGJlZm9yZSB0aGUgS1JCX0FQX1JFUSBtZXNzYWdl LCBhbmQgaW4gdGhlIG9yZGVyIG9mIHRoZQ0KICAgZXhjaGFuZ2UuICBUaGUgY2hlY2tzdW0gdHlw ZSBpcyB0aGUgcmVxdWlyZWQgY2hlY2tzdW0gdHlwZSBmb3IgdGhlDQogICBlbmN0eXBlIG9mIHRo ZSBzdWJrZXkgaW4gdGhlIGF1dGhlbnRpY2F0b3IsIHRoZSBwcm90b2NvbCBrZXkgaXMgdGhlDQog ICBhdXRoZW50aWNhdG9yIHN1YmtleSwgYW5kIHRoZSBrZXkgdXNhZ2UgbnVtYmVyIGlzIFRCQS0x LiAgVGhlDQogICBhY2NlcHRvciBNVVNUIHZlcmlmeSB0aGlzIGNoZWNrc3VtIGluIHRoZSBHU1Mt QVBJIGF1dGhlbnRpY2F0b3INCiAgIGV4dGVuc2lvbiwgdGhlbiByZXNwb25kIHdpdGggYW4gQVAt UkVQIGV4dGVuc2lvbiBbR1NTLUVYVFNdLiAgVGhlIEFQLQ0KICAgUkVQIGV4dGVuc2lvbiB0eXBl IGlzIDIgYW5kIHRoZSB0aGUgY29udGVudCBpcyB0aGUgQVNOLjEgREVSIGVuY29kaW5nDQogICBv ZiB0aGUgdHlwZSBDaGVja3N1bS4gIFRoaXMgY2hlY2tzdW0gaXMgcGVyZm9ybWVkIG92ZXIgYWxs IEdTUy1BUEkNCiAgIG1lc3NhZ2VzIGFzIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBpbml0aWF0b3Ig YW5kIHRoZSBhY2NlcHRvciBiZWZvcmUNCiAgIHRoZSBLUkJfQVBfUkVRIG1lc3NhZ2UsIGFuZCBp biB0aGUgb3JkZXIgb2YgdGhlIGV4Y2hhbmdlLiAgVGhlDQogICBjaGVja3N1bSB0eXBlIGlzIHRo ZSByZXF1aXJlZCBjaGVja3N1bSB0eXBlIGZvciB0aGUgZW5jdHlwZSBvZiB0aGUNCiAgIGF1dGhl bnRpY2F0b3Igc3Via2V5IGluIHRoZSByZXF1ZXN0LCBhbmQgdGhlIHByb3RvY29sIGtleSBpcyB0 aGUNCiAgIGF1dGhlbnRpY2F0b3Igc3Via2V5LCBhbmQgdGhlIGtleSB1c2FnZSBudW1iZXIgaXMg VEJBLTIuICBUaGUNCiAgIGluaXRpYXRvciBNVVNUIHRoZW4gdmVyaWZ5IHRoaXMgY2hlY2tzdW0u DQoNCg0KNC4gIEFkZHJlc3NlcyBpbiBUaWNrZXRzDQoNCiAgIEluIFdTLUtFUkIsIHRoZSBtYWNo aW5lIHNlbmRpbmcgcmVxdWVzdHMgdG8gdGhlIEtEQyBpcyB0aGUgR1NTLUFQSQ0KICAgYWNjZXB0 b3IgYW5kIG5vdCB0aGUgaW5pdGlhdG9yLiAgQXMgYSByZXN1bHQsIHRoZSBpbml0aWF0b3Igc2hv dWxkDQogICBub3QgaW5jbHVkZSBpdHMgYWRkcmVzc2VzIGluIGFueSBLREMgcmVxdWVzdHMgZm9y IHR3byByZWFzb25zLg0KICAgRmlyc3QsIHRoZSBLREMgbWF5IHJlamVjdCB0aGUgZm9yd2FyZGVk IHJlcXVlc3QgYXMgYmVpbmcgZnJvbSB0aGUNCiAgIHdyb25nIGNsaWVudC4gIFNlY29uZCwgaW4g dGhlIGNhc2Ugb2YgaW5pdGlhbCBhdXRoZW50aWNhdGlvbiBmb3IgYQ0KICAgZGlhbC11cCBjbGll bnQsIHRoZSBjbGllbnQgbWFjaGluZSBtYXkgbm90IHlldCBwb3NzZXNzIGEgbmV0d29yaw0KICAg YWRkcmVzcy4gIEhlbmNlLCBhcyBhbGxvd2VkIGJ5IFtSRkM0MTIwXSwgdGhlIGFkZHJlc3NlcyBm aWVsZCBvZiB0aGUNCiAgIEFTLVJFUSBhbmQgVEdTLVJFUSByZXF1ZXN0cyBTSE9VTEQgYmUgYmxh bmsgYW5kIHRoZSBjYWRkciBmaWVsZCBvZg0KICAgdGhlIHRpY2tldCBTSE9VTEQgc2ltaWxhcmx5 IGJlIGxlZnQgYmxhbmsuDQoNCg0KNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFNp bWlsYXIgdG8gb3RoZXIgbmV0d29yayBhY2Nlc3MgcHJvdG9jb2xzLCBXUy1LRVJCIGFsbG93cyBh bg0KICAgdW5hdXRoZW50aWNhdGVkIGNsaWVudCAocG9zc2libHkgb3V0c2lkZSB0aGUgc2VjdXJp dHkgcGVyaW1ldGVyIG9mIGFuDQogICBvcmdhbml6YXRpb24pIHRvIHNlbmQgbWVzc2FnZXMgdGhh dCBhcmUgcHJveGllZCB0byBpbnRlcmlvciBzZXJ2ZXJzLg0KDQoNCg0KDQpaaHUgICAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNCwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgIFdTLUtFUkIgICAgICAgICAg ICAgICAgICAgIE9jdG9iZXIgMjAwNg0KDQoNCiAgIEluIGEgc2NlbmFyaW8gd2hlcmUgRE5TIFNS ViBSUidzIGFyZSBiZWluZyB1c2VkIHRvIGxvY2F0ZSB0aGUgS0RDLA0KICAgV1MtS0VSQiBpcyBi ZWluZyB1c2VkLCBhbmQgYW4gZXh0ZXJuYWwgYXR0YWNrZXIgY2FuIG1vZGlmeSBETlMNCiAgIHJl c3BvbnNlcyB0byB0aGUgV1MtS0VSQiBwcm94eSwgdGhlcmUgYXJlIHNldmVyYWwgY291bnRlcm1l YXN1cmVzIHRvDQogICBwcmV2ZW50IGFyYml0cmFyeSBtZXNzYWdlcyBmcm9tIGJlaW5nIHNlbnQg dG8gaW50ZXJuYWwgc2VydmVyczoNCg0KICAgMS4gIEtEQyBwb3J0IG51bWJlcnMgY2FuIGJlIHN0 YXRpY2FsbHkgY29uZmlndXJlZCBvbiB0aGUgV1MtS0VSQg0KICAgICAgIHByb3h5LiAgSW4gdGhp cyBjYXNlLCB0aGUgbWVzc2FnZXMgd2lsbCBhbHdheXMgYmUgc2VudCB0byBLREMncy4NCiAgICAg ICBGb3IgYW4gb3JnYW5pemF0aW9uIHRoYXQgcnVucyBLREMncyBvbiBhIHN0YXRpYyBwb3J0ICh1 c3VhbGx5DQogICAgICAgcG9ydCA4OCkgYW5kIGRvZXMgbm90IHJ1biBhbnkgb3RoZXIgc2VydmVy cyBvbiB0aGUgc2FtZSBwb3J0LA0KICAgICAgIHRoaXMgY291bnRlcm1lYXN1cmUgd291bGQgYmUg ZWFzeSB0byBhZG1pbmlzdGVyIGFuZCBzaG91bGQgYmUNCiAgICAgICBlZmZlY3RpdmUuDQoNCiAg IDIuICBUaGUgcHJveHkgY2FuIGRvIGFwcGxpY2F0aW9uIGxldmVsIHNhbml0eSBjaGVja2luZyBh bmQgZmlsdGVyaW5nLg0KICAgICAgIFRoaXMgY291bnRlcm1lYXN1cmUgc2hvdWxkIGVsaW1pbmF0 ZSBtYW55IG9mIHRoZSBhYm92ZSBhdHRhY2tzLg0KDQogICAzLiAgRE5TIHNlY3VyaXR5IGNhbiBi ZSBkZXBsb3llZC4gIFRoaXMgY291bnRlcm1lYXN1cmUgaXMgcHJvYmFibHkNCiAgICAgICBvdmVy a2lsbCBmb3IgdGhpcyBwYXJ0aWN1bGFyIHByb2JsZW0sIGJ1dCBpZiBhbiBvcmdhbml6YXRpb24g aGFzDQogICAgICAgYWxyZWFkeSBkZXBsb3llZCBETlMgc2VjdXJpdHkgZm9yIG90aGVyIHJlYXNv bnMsIHRoZW4gaXQgbWlnaHQNCiAgICAgICBtYWtlIHNlbnNlIHRvIGxldmVyYWdlIGl0IGhlcmUu ICBOb3RlIHRoYXQgS2VyYmVyb3MgY291bGQgYmUgdXNlZA0KICAgICAgIHRvIHByb3RlY3QgdGhl IEROUyBleGNoYW5nZXMuICBUaGUgaW5pdGlhbCBETlMgU1JWIEtEQyBsb29rdXAgYnkNCiAgICAg ICB0aGUgcHJveHkgd2lsbCBiZSB1bnByb3RlY3RlZCwgYnV0IGFuIGF0dGFjayBoZXJlIGlzIGF0 IG1vc3QgYQ0KICAgICAgIGRlbmlhbCBvZiBzZXJ2aWNlICh0aGUgaW5pdGlhbCBsb29rdXAgd2ls bCBiZSBmb3IgdGhlIHByb3h5J3MgS0RDDQogICAgICAgdG8gZmFjaWxpdGF0ZSBLZXJiZXJvcyBw cm90ZWN0aW9uIG9mIHN1YnNlcXVlbnQgRE5TIGV4Y2hhbmdlcw0KICAgICAgIGJldHdlZW4gaXRz ZWxmIGFuZCB0aGUgRE5TIHNlcnZlcikuDQoNCg0KNi4gIEFja25vd2xlZGdlbWVudHMNCg0KICAg VGhlIGFjY2VwdG9yLXByb3h5IGlkZWEgaXMgYmFzZWQgb24gdGhlIGVhcmx5IHJldmlzaW9ucyBv ZiB0aGlzDQogICBkb2N1bWVudCB3cml0dGVuIGJ5IEpvbmF0aGFuIFRyb3N0bGUsIE1pY2hhZWwg U3dpZnQsIEJlcm5hcmQgQWJvYmENCiAgIGFuZCBHbGVuIFpvcm4uDQoNCiAgIFRoZSByZXN0IG9m IHRoZSBpZGVhcyBtb3N0bHkgY2FtZSBmcm9tIGhhbGx3YXkgY29udmVyc2F0aW9ucyBiZXR3ZWVu DQogICB0aGUgYXV0aG9yIGFuZCBOaWNvbGFzIFdpbGxpYW1zLg0KDQoNCjcuICBJQU5BIENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoZXJlIGlzIG5vIElBTkEgYWN0aW9uIHJlcXVpcmVkIGZvciB0aGlz IGRvY3VtZW50Lg0KDQoNCjguICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0g IEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAg ICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAx OTk3Lg0KDQogICBbUkZDMjc0M10gIExpbm4sIEouLCAiR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNl IEFwcGxpY2F0aW9uIFByb2dyYW0NCiAgICAgICAgICAgICAgSW50ZXJmYWNlIFZlcnNpb24gMiwg VXBkYXRlIDEiLCBSRkMgMjc0MywgSmFudWFyeSAyMDAwLg0KDQoNCg0KWmh1ICAgICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDQsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICBXUy1LRVJCICAgICAgICAgICAg ICAgICAgICBPY3RvYmVyIDIwMDYNCg0KDQogICBbUkZDNDEyMF0gIE5ldW1hbiwgQy4sIFl1LCBU LiwgSGFydG1hbiwgUy4sIGFuZCBLLiBSYWVidXJuLCAiVGhlDQogICAgICAgICAgICAgIEtlcmJl cm9zIE5ldHdvcmsgQXV0aGVudGljYXRpb24gU2VydmljZSAoVjUpIiwgUkZDIDQxMjAsDQogICAg ICAgICAgICAgIEp1bHkgMjAwNS4NCg0KICAgW1JGQzQxMjFdICBaaHUsIEwuLCBKYWdhbmF0aGFu LCBLLiwgYW5kIFMuIEhhcnRtYW4sICJUaGUgS2VyYmVyb3MNCiAgICAgICAgICAgICAgVmVyc2lv biA1IEdlbmVyaWMgU2VjdXJpdHkgU2VydmljZSBBcHBsaWNhdGlvbiBQcm9ncmFtDQogICAgICAg ICAgICAgIEludGVyZmFjZSAoR1NTLUFQSSkgTWVjaGFuaXNtOiBWZXJzaW9uIDIiLCBSRkMgNDEy MSwNCiAgICAgICAgICAgICAgSnVseSAyMDA1Lg0KDQogICBbUkZDNDE3OF0gIFpodSwgTC4sIExl YWNoLCBQLiwgSmFnYW5hdGhhbiwgSy4sIGFuZCBXLiBJbmdlcnNvbGwsICJUaGUNCiAgICAgICAg ICAgICAgU2ltcGxlIGFuZCBQcm90ZWN0ZWQgR2VuZXJpYyBTZWN1cml0eSBTZXJ2aWNlIEFwcGxp Y2F0aW9uDQogICAgICAgICAgICAgIFByb2dyYW0gSW50ZXJmYWNlIChHU1MtQVBJKSBOZWdvdGlh dGlvbiBNZWNoYW5pc20iLA0KICAgICAgICAgICAgICBSRkMgNDE3OCwgT2N0b2JlciAyMDA1Lg0K DQogICBbS1JCLUFOT05dIFpodSwgTC4sIExlYWNoLCBQLiBhbmQgSmFnYW5hdGhhbiwgSy4sICJL ZXJiZXJvcyBBbm9ueW1pdHkgDQogICAgICAgICAgICAgIFN1cHBvcnQiLCBkcmFmdC1pZXRmLWty Yi13Zy1hbm9uLCB3b3JrIGluIHByb2dyZXNzLg0KDQogICBbS1JCLVBBRlddIFpodSwgZXRsLCAi S2VyYmVyb3MgUHJlLUF1dGhlbnRpY2F0aW9uIGZyYW1ld29yayIsIA0KICAgICAgICAgICAgICBk cmFmdC1pZXRmLWtyYi13Zy1wcmVhdXRoLWZyYW1ld29yaywgd29yayBpbiBwcm9ncmVzcy4NCiAg ICAgICAgICAgICAgDQogICBbR1NTLUVYVFNdIEVtZXJ5LCBTLiwgZHJhZnQtaWV0Zi1rcmItd2ct Z3NzLWNiLWhhc2gtYWdpbGl0eSwgd29yayBpbiANCiAgICAgICAgICAgICAgcHJvZ2Vzcy4NCg0K ICAgW1JFRkVSQUxTXSBSYWVidXJuLCBLLiwgIkdlbmVyYXRpbmcgS0RDIFJlZmVycmFscyB0byBM b2NhdGUgS2VyYmVyb3MgDQogICAgICAgICAgICAgIFJlYWxtcyIsIGRyYWZ0LWlldGYta3JiLXdn LWtlcmJlcm9zLXJlZmVycmFscywgd29yayBpbg0KICAgICAgICAgICAgICBwcm9ncmVzcy4NCiAg ICAgICAgICAgICAgDQogICBbWDY4MF0gICAgIElUVS1UIFJlY29tbWVuZGF0aW9uIFguNjgwICgy MDAyKSB8IElTTy9JRUMgODgyNC0xOjIwMDIsDQogICAgICAgICAgICAgIEluZm9ybWF0aW9uIHRl Y2hub2xvZ3kgLSBBYnN0cmFjdCBTeW50YXggTm90YXRpb24gT25lDQogICAgICAgICAgICAgIChB U04uMSk6IFNwZWNpZmljYXRpb24gb2YgYmFzaWMgbm90YXRpb24uDQoNCiAgIFtYNjkwXSAgICAg SVRVLVQgUmVjb21tZW5kYXRpb24gWC42OTAgKDIwMDIpIHwgSVNPL0lFQyA4ODI1LTE6MjAwMiwN CiAgICAgICAgICAgICAgSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtIEFTTi4xIGVuY29kaW5nIFJ1 bGVzOg0KICAgICAgICAgICAgICBTcGVjaWZpY2F0aW9uIG9mIEJhc2ljIEVuY29kaW5nIFJ1bGVz IChCRVIpLCBDYW5vbmljYWwNCiAgICAgICAgICAgICAgRW5jb2RpbmcgUnVsZXMgKENFUikgYW5k IERpc3Rpbmd1aXNoZWQgRW5jb2RpbmcgUnVsZXMNCiAgICAgICAgICAgICAgKERFUikuDQoNCg0K QXV0aG9yJ3MgQWRkcmVzcw0KDQogICBMYXJyeSBaaHUNCiAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlv bg0KICAgT25lIE1pY3Jvc29mdCBXYXkNCiAgIFJlZG1vbmQsIFdBICA5ODA1Mg0KICAgVVMNCg0K ICAgRW1haWw6IGx6aHVAbWljcm9zb2Z0LmNvbQ0KDQoNCg0KDQoNClpodSAgICAgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCA0LCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgV1MtS0VSQiAgICAgICAgICAgICAg ICAgICAgT2N0b2JlciAyMDA2DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLg0KDQogICBUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0K ICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwg dGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24g YW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElP TiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJTkVFUklORyBUQVNLIEZP UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsDQogICBJTkNM VURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhF DQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBB TlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KSW50ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAg IFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2Nv cGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0 cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0 aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1l bnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0K ICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50 IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkg YW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGgg cmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJD UCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8g dGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0 byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRl IHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m DQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2Yg dGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1s aW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAg VGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0 ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25z LCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xv Z3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAg UGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlw ckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZD IEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUgSUVURg0KICAgQWRtaW5pc3RyYXRp dmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuDQoNCg0KDQoNCg0KWmh1ICAgICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEFwcmlsIDQsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoM DQoNCg== ------_=_NextPart_001_01C70252.137285A1 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_001_01C70252.137285A1-- From kitten-bounces@lists.ietf.org Tue Nov 07 08:09:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhQht-0005ut-96; Tue, 07 Nov 2006 08:09:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhQhs-0005uR-0f for kitten@ietf.org; Tue, 07 Nov 2006 08:09:36 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhQho-0000EK-AZ for kitten@ietf.org; Tue, 07 Nov 2006 08:09:35 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7D9Rxq023690 for ; Tue, 7 Nov 2006 08:09:27 -0500 (EST) Received: from [75.212.58.98] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000034124.msg for ; Tue, 07 Nov 2006 08:13:02 -0500 Resent-From: Jeffrey Altman Resent-To: Kitten Resent-Date: Tue, 7 Nov 2006 05:12:52 -0800 Resent-Message-Id: <45508654.6000302@secure-endpoints.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=unavailable version=3.1.5 X-Spam-Report: * 0.1 FORGED_RCVD_HELO Received: contains a forged HELO * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Received: from av6-1-sn3.vrr.skanova.net (av6-1-sn3.vrr.skanova.net [81.228.9.179]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000034098.msg for ; Tue, 07 Nov 2006 00:46:40 -0500 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 3606A37F39; Tue, 7 Nov 2006 06:42:56 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 21F0E37E5C for ; Tue, 7 Nov 2006 06:42:56 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 0357837E76 for ; Tue, 7 Nov 2006 06:42:55 +0100 (CET) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GhJjZ-00028d-Bt for kitten-chairs@tools.ietf.org; Tue, 07 Nov 2006 06:42:55 +0100 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA75gmjC012510 for ; Mon, 6 Nov 2006 21:42:48 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA75glGT018889 for ; Mon, 6 Nov 2006 22:42:48 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA75gkek027524; Mon, 6 Nov 2006 23:42:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA75gjkL027522; Mon, 6 Nov 2006 23:42:45 -0600 (CST) Date: Mon, 6 Nov 2006 23:42:45 -0600 From: Nicolas Williams To: Tom Yu , secdir@MIT.EDU, iesg@ietf.org, kitten-chairs@tools.ietf.org Message-ID: <20061107054244.GU25646@binky.Central.Sun.COM> Mail-Followup-To: Tom Yu , secdir@MIT.EDU, iesg@ietf.org, kitten-chairs@tools.ietf.org References: <20061103232616.GA23255@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061103232616.GA23255@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-SA-Exim-Connect-IP: 192.18.42.13 X-SA-Exim-Mail-From: nw141292@binky.Central.Sun.COM X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Lookup-Warning: MAIL lookup on nw141292@binky.Central.Sun.COM does not match 81.228.9.179 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 08:13:02 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.212.58.98 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nw141292@binky.Central.Sun.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 Resent-Date: Tue, 07 Nov 2006 08:09:37 -0500 On Fri, Nov 03, 2006 at 05:26:16PM -0600, Nicolas Williams wrote: > On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote: > > For some time, I had some difficult-to-articulate misgivings about the > > domain-based name concept advanced in these documents. I now realize > > that the underlying issue is one of implicitly creating an > > authorization role where one might not have been present before. > > Essentially, the mere existence of a domain-based principal name forms > > an authorization assertion. > > Yes. > > > In Kerberos, and possibly other > > authentication architectures, the mere existence of a name does not > > usually express any authorization assertion. > > > > For a traditional host-based service principal name, e.g., > > "service_a@hostname_b", successful authentication to that service > > principal only implies that the administrator of the namespace has > > certified the association of some secret with the particular hostname > > (hostname_b), and that perhaps the administrator of "hostname_b" > > wishes to run an instance of "service_a" upon that host. > > Indeed. Actually, it goes further than that. Users typically know of hostnames, as in URLs that they remember. And these may be for sensitive services, to which they'd send sensitive data. Consider an application that, even when using network authentication services to authenticate users, wants users to provide additional authentication in the form of cleartext passwords. For example, an application for administering employee payment options (direct deposit, tax deductions claimed, retirement account funding, etc...). Users will generally know the service by name, so the name of the service is quite significant -- users trust that name if their browser indicates that it has been authenticated. So realm administrators had better know the significance of the hostnames for which they issue long-term hostbased service credentials. Users perform a mental authorization step. > We're extending this very model. But not in a fundamental way. Therefore I now reject the need for any further security considerations text. If the WG believes any such text is need, however, here's what I would propose adding to the Security Considerations of draft-ietf-kitten- gssapi-domain-based-names-03.txt: Note that, as with all service names, domain-based service names convey meaningful information that may be used for access control by initiators, therefore administrators of distributed authentication services should be aware of the significance of the service names for which they create acceptor credentials. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 08:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRBR-0004pI-Gt; Tue, 07 Nov 2006 08:40:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhRBQ-0004pB-8p for kitten@ietf.org; Tue, 07 Nov 2006 08:40:08 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhRBL-0006Ix-VP for kitten@ietf.org; Tue, 07 Nov 2006 08:40:08 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7De2pf014955 for ; Tue, 7 Nov 2006 08:40:03 -0500 (EST) Received: from [75.212.58.98] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.8) with ESMTP id md50000034135.msg for ; Tue, 07 Nov 2006 08:43:37 -0500 Message-ID: <45508D7D.5040305@secure-endpoints.com> Date: Tue, 07 Nov 2006 05:43:25 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 08:43:37 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.212.58.98 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.3 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Subject: [Fwd: draft-ietf-kitten-extended-mech-inquiry-02.txt] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1460008092==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1460008092== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010900050308090307020904" This is a cryptographically signed message in MIME format. --------------ms010900050308090307020904 Content-Type: multipart/mixed; boundary="------------030705070705010102000405" This is a multi-part message in MIME format. --------------030705070705010102000405 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------030705070705010102000405 Content-Type: message/rfc822; name="draft-ietf-kitten-extended-mech-inquiry-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-kitten-extended-mech-inquiry-02.txt" Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.1.5 X-Spam-Report: * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Authentication-Results: www.secure-endpoints.com smtp.mail=David.Leonard@quest.com; spf=neutral; ip-match=fail Received: from irvbhxw03.quest.com (irvbhxw03.quest.com [12.106.87.70]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.0.8) with ESMTP id md50000034120.msg for ; Tue, 07 Nov 2006 07:47:27 -0500 Received: from [10.100.0.16] ([10.20.36.132]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 04:43:31 -0800 Message-ID: <45507F6D.8030100@quest.com> Date: Tue, 07 Nov 2006 22:43:25 +1000 From: David Leonard User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nicolas.Williams@sun.com CC: jaltman@secure-endpoints.com Subject: draft-ietf-kitten-extended-mech-inquiry-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 12:43:31.0734 (UTC) FILETIME=[54E39B60:01C7026A] X-Lookup-Warning: MAIL lookup on David.Leonard@quest.com does not match 12.106.87.70 X-MDRcpt-To: jaltman@secure-endpoints.com X-Rcpt-To: jaltman@secure-endpoints.com X-MDRemoteIP: 12.106.87.70 X-Return-Path: David.Leonard@quest.com X-Envelope-From: David.Leonard@quest.com X-MDaemon-Deliver-To: jaltman@secure-endpoints.com Reply-To: David.Leonard@quest.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 07:47:27 -0500 Hi, Comments regarding draft-ietf-kitten-extended-mech-inquiry-02.txt There is a typo in 3.3 "GSS_C_MA_WRAP wap" ... probably should be "wrap" Table 2's entry for GSS_C_MA_ITOK_FRAMED refers to rfc2743, not [RFC2743] In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be returned. I think it should be expected that a future caller could be searching for an attribute OID that the implementation doesn't know about. s 3.5.3 does not mention language/locale/encoding with the short_desc and long_desc description output of GSS_Display_mech_attr(). Is that deliberate? Could I assume it will sensitive to the 'current' locale, and return UTF-8? I notice RFC2743 doesn't address this with the other GSS_Display calls, so maybe this is addressed more generally? Also, in s3.5.3 would it be reasonable to allow the return of empty or null descriptions from GSS_Display_mech_attr()? Thanks David Leonard --------------030705070705010102000405-- --------------ms010900050308090307020904 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDcxMzQzMjVaMCMGCSqGSIb3DQEJBDEWBBTsZ7gk pdT8iBfcTj5RDBd/vBrD8zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAC0a0Ttk0vSc4+hf0ZSbLYXXtn+JezRACckSxTFU76TSqqgmhSp6K oUVjaWMQwBcnfh4RZ7Nz/e07/czmvO+lhWyKMYcjKwAct+hc5q6xBOfbn5rH+xfuP7GkGeeS xE5qry+EdEJFW6uinvS6gY/gIkfmOO/D/tpMYnTzUSxT5tshxlS9qd+6AE5bXW6zb5lp7v5G NGZrRNP3IEJie4JczQJqQr014gPJEoUtpPaQRZlML/Y+OzKnRN37XaT7nc8INQZTKofTjU93 DuvWzWmX2kOc4ij7iZXRh/Gtz7ub8DUdA/dPYrec7Sbl6BV60JLUuUgsnwkLINdFWZ5PSJ6N fAAAAAAAAA== --------------ms010900050308090307020904-- --===============1460008092== 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 --===============1460008092==-- From kitten-bounces@lists.ietf.org Tue Nov 07 11:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTqq-0007eL-J3; Tue, 07 Nov 2006 11:31:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTqo-0007e4-TJ for kitten@ietf.org; Tue, 07 Nov 2006 11:31:02 -0500 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTql-0006eX-Ju for kitten@ietf.org; Tue, 07 Nov 2006 11:31:02 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7GUwFT029141 for ; Tue, 7 Nov 2006 11:30:58 -0500 (EST) Received: from [192.168.1.240] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.2) with ESMTP id md50000034158.msg for ; Tue, 07 Nov 2006 11:34:33 -0500 Message-ID: <4550B592.2030303@secure-endpoints.com> Date: Tue, 07 Nov 2006 08:34:26 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 11:34:33 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: Subject: [Fwd: Re: draft-ietf-kitten-extended-mech-inquiry-02.txt] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785958128==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0785958128== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030705050908090300080408" This is a cryptographically signed message in MIME format. --------------ms030705050908090300080408 Content-Type: multipart/mixed; boundary="------------060704020501090001010402" This is a multi-part message in MIME format. --------------060704020501090001010402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------060704020501090001010402 Content-Type: message/rfc822; name="Re: draft-ietf-kitten-extended-mech-inquiry-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: draft-ietf-kitten-extended-mech-inquiry-02.txt" Return-path: X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.1.5 X-Spam-Report: * -4.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Authentication-Results: www.secure-endpoints.com smtp.mail=nw141292@binky.Central.Sun.COM; spf=neutral; ip-match=fail Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.5.2) with ESMTP id md50000034157.msg for ; Tue, 07 Nov 2006 11:33:53 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7GUBF8017173 for ; Tue, 7 Nov 2006 09:30:11 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7GUAjh003767 for ; Tue, 7 Nov 2006 09:30:11 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7GU91o027996; Tue, 7 Nov 2006 10:30:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7GU9Jo027995; Tue, 7 Nov 2006 10:30:09 -0600 (CST) Date: Tue, 7 Nov 2006 10:30:09 -0600 From: Nicolas Williams To: David Leonard Cc: jaltman@secure-endpoints.com Subject: Re: draft-ietf-kitten-extended-mech-inquiry-02.txt Message-ID: <20061107163008.GZ25646@binky.Central.Sun.COM> References: <45507F6D.8030100@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45507F6D.8030100@quest.com> User-Agent: Mutt/1.5.7i X-Lookup-Warning: MAIL lookup on nw141292@binky.Central.Sun.COM does not match 192.18.98.43 X-MDRcpt-To: jaltman@secure-endpoints.com X-Rcpt-To: jaltman@secure-endpoints.com X-MDRemoteIP: 192.18.98.43 X-Return-Path: nw141292@binky.Central.Sun.COM X-Envelope-From: nw141292@binky.Central.Sun.COM X-MDaemon-Deliver-To: jaltman@secure-endpoints.com Reply-To: Nicolas.Williams@sun.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 11:33:53 -0500 On Tue, Nov 07, 2006 at 10:43:25PM +1000, David Leonard wrote: > Hi, > > Comments regarding draft-ietf-kitten-extended-mech-inquiry-02.txt These should be sent to the list. > There is a typo in 3.3 "GSS_C_MA_WRAP wap" ... probably should be "wrap" Indeed, thanks. > Table 2's entry for GSS_C_MA_ITOK_FRAMED refers to rfc2743, not [RFC2743] Will fix. > In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be > returned. I think it should be expected that a future caller could be > searching for an attribute OID that the implementation doesn't know about. GSS_Indicate_mechs_by_attr() could just return an empty OID set instead of GSS_BAD_MECH_ATTR. See below. > s 3.5.3 does not mention language/locale/encoding with the short_desc > and long_desc description output of GSS_Display_mech_attr(). Is that > deliberate? Could I assume it will sensitive to the 'current' locale, > and return UTF-8? I notice RFC2743 doesn't address this with the other > GSS_Display calls, so maybe this is addressed more generally? RFC2743 does not address this, no. RFC2744 says "Latin-1." Our conclusio is that outputs from functions such as GSS_Display_status() are in the codeset of the current locale and in the language of the current locale. > Also, in s3.5.3 would it be reasonable to allow the return of empty or > null descriptions from GSS_Display_mech_attr()? I suppose so, or a string that says "description missing" or something to the effect. A complete implementation wouldn't, of course. Note that here GSS_BAD_MECH_ATTR is useful. Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR. Nico -- --------------060704020501090001010402-- --------------ms030705050908090300080408 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDcxNjM0MjZaMCMGCSqGSIb3DQEJBDEWBBSMcH0Y 3dkSHqoERkSHMoAxdKreFTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAE4ViVf4G0rbAjVPJgYjJ1a9/zcVZS4Fn1dHbUN3e0NwdD+eZO/hD puituHGufWgtoFxFIhk9rzU0KYeEnyqFIfHOVfvkU4t5chy+HvY/UL8dO5e+aqU47VbD80RP KvBeDkvhpCdHdoN9fAlpstezKRLKbUPwJdD9mZRLacfVcNVfPrSDTyjnqq59AkVC+FonJE5H xx3mzi+8sCKSo0ibygTk70zhrI2ZPg7+S/KwnYBHYfwHBbP1kNtcc6jnj+4Fk6wbfqvMk6NP oYuq6dyNVl35iFsAMUTGMm3ea9RiqhVqrfq0hKa9ATxe/CrF4V5qDZKfYLvtLVCwFVctrWA+ rQAAAAAAAA== --------------ms030705050908090300080408-- --===============0785958128== 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 --===============0785958128==-- From kitten-bounces@lists.ietf.org Tue Nov 07 11:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTqo-0007dm-9f; Tue, 07 Nov 2006 11:31:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTqm-0007dg-VU for kitten@ietf.org; Tue, 07 Nov 2006 11:31:00 -0500 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhTqh-0006cx-BV for kitten@ietf.org; Tue, 07 Nov 2006 11:31:00 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7GUsod020964 for ; Tue, 7 Nov 2006 08:30:54 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7GUs31004284 for ; Tue, 7 Nov 2006 09:30:54 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7GUrJs028003 for ; Tue, 7 Nov 2006 10:30:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7GUrUE028002 for kitten@ietf.org; Tue, 7 Nov 2006 10:30:53 -0600 (CST) Resent-From: Nicolas.Williams@sun.com Resent-Date: Tue, 7 Nov 2006 10:30:53 -0600 Resent-Message-ID: <20061107163053.GB26436@binky.Central.Sun.COM> Resent-To: kitten@ietf.org Date: Tue, 7 Nov 2006 10:30:08 -0600 From: Nicolas Williams To: David Leonard Message-ID: <20061107163008.GZ25646@binky.Central.Sun.COM> References: <45507F6D.8030100@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45507F6D.8030100@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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 Resent-Date: Tue, 07 Nov 2006 11:31:02 -0500 On Tue, Nov 07, 2006 at 10:43:25PM +1000, David Leonard wrote: > Hi, > > Comments regarding draft-ietf-kitten-extended-mech-inquiry-02.txt These should be sent to the list. > There is a typo in 3.3 "GSS_C_MA_WRAP wap" ... probably should be "wrap" Indeed, thanks. > Table 2's entry for GSS_C_MA_ITOK_FRAMED refers to rfc2743, not [RFC2743] Will fix. > In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be > returned. I think it should be expected that a future caller could be > searching for an attribute OID that the implementation doesn't know about. GSS_Indicate_mechs_by_attr() could just return an empty OID set instead of GSS_BAD_MECH_ATTR. See below. > s 3.5.3 does not mention language/locale/encoding with the short_desc > and long_desc description output of GSS_Display_mech_attr(). Is that > deliberate? Could I assume it will sensitive to the 'current' locale, > and return UTF-8? I notice RFC2743 doesn't address this with the other > GSS_Display calls, so maybe this is addressed more generally? RFC2743 does not address this, no. RFC2744 says "Latin-1." Our conclusio is that outputs from functions such as GSS_Display_status() are in the codeset of the current locale and in the language of the current locale. > Also, in s3.5.3 would it be reasonable to allow the return of empty or > null descriptions from GSS_Display_mech_attr()? I suppose so, or a string that says "description missing" or something to the effect. A complete implementation wouldn't, of course. Note that here GSS_BAD_MECH_ATTR is useful. Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 12:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUNb-0001Rn-Bi; Tue, 07 Nov 2006 12:04:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUNa-0001Ra-60 for kitten@ietf.org; Tue, 07 Nov 2006 12:04:54 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUNX-0004Kh-P8 for kitten@ietf.org; Tue, 07 Nov 2006 12:04:54 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7H4mKG007561 for ; Tue, 7 Nov 2006 12:04:49 -0500 (EST) Received: from [75.212.58.98] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.2) with ESMTP id md50000034167.msg for ; Tue, 07 Nov 2006 12:08:23 -0500 Message-ID: <4550BD7F.1020603@secure-endpoints.com> Date: Tue, 07 Nov 2006 09:08:15 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 12:08:23 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.212.58.98 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Subject: [Fwd: Kitten doc reviews] X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1680134632==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1680134632== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000607080003000507080301" This is a cryptographically signed message in MIME format. --------------ms000607080003000507080301 Content-Type: multipart/mixed; boundary="------------070007060801090303090109" This is a multi-part message in MIME format. --------------070007060801090303090109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------070007060801090303090109 Content-Type: message/rfc822; name="Kitten doc reviews" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Kitten doc reviews" Return-path: Authentication-Results: www.secure-endpoints.com smtp.mail=warlord@MIT.EDU; spf=neutral; ip-match=fail Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by secure-endpoints.com (www.secure-endpoints.com) (MDaemon PRO v9.5.2) with ESMTP id md50000034149.msg for ; Tue, 07 Nov 2006 11:05:28 -0500 Received: from cliodev.pgp.com (0127bhost247.starwoodbroadband.com [12.105.247.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id EBF3A8B4005 for ; Tue, 7 Nov 2006 11:01:41 -0500 (EST) Received: (from warlord@localhost) by cliodev.pgp.com (8.13.7/8.13.1/Submit) id kA7G14jm009903; Tue, 7 Nov 2006 11:01:04 -0500 From: Derek Atkins To: Subject: Kitten doc reviews Date: Tue, 07 Nov 2006 11:01:04 -0500 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 11:05:28 -0500 (not processed: sender in recipient's private address book) X-Lookup-Warning: MAIL lookup on warlord@MIT.EDU does not match 204.107.200.6 X-MDRcpt-To: jaltman@secure-endpoints.com X-Rcpt-To: jaltman@secure-endpoints.com X-MDRemoteIP: 204.107.200.6 X-Return-Path: warlord@MIT.EDU X-Envelope-From: warlord@MIT.EDU X-MDaemon-Deliver-To: jaltman@secure-endpoints.com Reply-To: derek@ihtfp.com Here are my reviews for you.. -derek draft-ietf-kitten-stackable-pseudo-mechs-02.txt Abstract: This document defines and formalizes the concept of stackable pseudo- mechanisms, and associated concept of composite mechanisms, for the Generic Security Service Application Programming Interface (GSS-API), as well as several utility functions. This first sentence is awkward. I think you should remove the first comma and add a "the", so it reads: ... stackable pseudo-mechanisms and the associated concept ... 3. Mechanism Composition Issues What about mechanism ordering? Security Modules cannot necessarily get transposed, or the ordering matters. Also, send vs. receive order might need to be different. 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces o Which composite mechanisms, if any, are indicated through GSS_Indicate_mechs() SHOULD be configurable. This reads awkwardly. A better sentence would read: Any composite mechanisms indicated through GSS_Indicate_mechs() SHOULD be configurable. 5.1. New GSS-API Function Interfaces This section looks like it uses the exact same text as 4.4, but just in a paragraph instead of bullet-items. What's the point of that? It also has the same syntactic issue as 4.4: GSS_Indicate_mechs() MAY indicate support for some, all or none of the available composite mechanisms; which composite mechanisms, if any, are indicated through GSS_Indicate_mechs() SHOULD be configurable. should probably get re-written in the same way as 4.4: ... any composite mechanisms indidicated through GSS_Indicate_mechs() SHOULD be configurable. 5.1.4. GSS_Indicate_negotiable_mechs() o peer_type_known BOOLEAN, -- indicates whether the peer is known to support or not supprot the stackable pseudo-mechanism framework. supprot -> support GSS_Inquire_cred()), but composite mechanisms will be included either implicitly or implicitly as per the following rules: "implicitly or implicitly"? I think it should be "explicitly or implicitly" General Comments... This document talks about "rules for mechanism composition" but nowhere does it discuss a way to encode these rules. How do I express these rules? The draft mentions a means to upgrade these rules, but not where these rules need to get stored. draft-ietf-kitten-extended-mech-inquiry-02.txt No Introduction? 3. New GSS-API Interfaces The opening sentence is awkwardly composed. I recommend changing it to: Today GSS-API applications face the problem of how to select from multiple GSS-API mechanisms that may be available. 3.5. New GSS-API Function Interfaces This section uses similar text to the other draft. In particular: support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() MAY indicate support for some, all or none of the available composite mechanisms; which composite mechanisms, if any, are indicated through GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and The 'which' portion should be re-written as suggested for the previous draft. General comments: Again, the document mentions the composition rules but doesn't specify them or how to use them. This document has no security considerations. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --------------070007060801090303090109-- --------------ms000607080003000507080301 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDcxNzA4MTVaMCMGCSqGSIb3DQEJBDEWBBQk0S+L ncHX39SU7E43uhwTDG5YbTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAeX59yWfoCwBwhb5WoTJ8H3Jouoy1VoLZ8nG/GWg6fRCRrTeEFGKQ Swh6dQBfg+PdIPT2+IKkNh86ZaCaMUP6NF+/bXCak4vRunKK5HxjWynD3ga42wAXQ3ocVm+b zRybsOLgMWrgR1zkTEdzkFWRGpECCzswqTPc+4Bx0aQE6ArG3fRX3N3Rd2EbvTqeMF40SWgN T4zyBpMlEO9PCZ4AlKqj0v74yc6JVbegLZ3olnuJ4TxcaB6EcMMZ2ddysopI3qpF6fYeO4mz kMZQ1Gu999H804NdUACt8tMXzDXuAmjmdfeQ91Y0RzonXiffPlLSusHXeuqpFL1MumUyAdb8 vAAAAAAAAA== --------------ms000607080003000507080301-- --===============1680134632== 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 --===============1680134632==-- From kitten-bounces@lists.ietf.org Tue Nov 07 12:08:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhURI-0003a5-Ls; Tue, 07 Nov 2006 12:08:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhURH-0003Zt-Mf for kitten@ietf.org; Tue, 07 Nov 2006 12:08:43 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhURG-0004kZ-2F for kitten@ietf.org; Tue, 07 Nov 2006 12:08:43 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7H8f15004239 for ; Tue, 7 Nov 2006 10:08:41 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7H8fbb025750 for ; Tue, 7 Nov 2006 10:08:41 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7H8fph028040 for ; Tue, 7 Nov 2006 11:08:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7H8eWi028039 for kitten@ietf.org; Tue, 7 Nov 2006 11:08:40 -0600 (CST) Resent-From: Nicolas.Williams@sun.com Resent-Date: Tue, 7 Nov 2006 11:08:40 -0600 Resent-Message-ID: <20061107170840.GC26436@binky.Central.Sun.COM> Resent-To: kitten@ietf.org Date: Tue, 7 Nov 2006 11:00:24 -0600 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20061107170024.GA25646@binky.Central.Sun.COM> References: <4550BD7F.1020603@secure-endpoints.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4550BD7F.1020603@secure-endpoints.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Derek Atkins Subject: Re: [Fwd: Kitten doc reviews] 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 Resent-Date: Tue, 07 Nov 2006 12:08:44 -0500 On Tue, Nov 07, 2006 at 08:11:56AM -0800, Jeffrey Altman wrote: > From: Derek Atkins > To: jaltman@secure-endpoints.com > Subject: Kitten doc reviews > Date: Tue, 07 Nov 2006 11:01:04 -0500 > > Here are my reviews for you.. > > -derek > > draft-ietf-kitten-stackable-pseudo-mechs-02.txt > > Abstract: > > This document defines and formalizes the concept of stackable pseudo- > mechanisms, and associated concept of composite mechanisms, for the > Generic Security Service Application Programming Interface (GSS-API), > as well as several utility functions. > > This first sentence is awkward. I think you should remove the first > comma and add a "the", so it reads: ... stackable pseudo-mechanisms and > the associated concept ... > > > 3. Mechanism Composition Issues > > What about mechanism ordering? Security Modules cannot necessarily > get transposed, or the ordering matters. Correct. This is why composition rules matter, see section 4.2. > Also, send vs. receive order > might need to be different. I don't understand this comment. > > 4.4. Compatibility with the Basic GSS-APIv2u1 Interfaces > > o Which composite mechanisms, if any, are indicated through > GSS_Indicate_mechs() SHOULD be configurable. > > This reads awkwardly. A better sentence would read: > > Any composite mechanisms indicated through GSS_Indicate_mechs() > SHOULD be configurable. Your version is ambiguous. What should be configurable? The mechanisms? Or the set of mechanisms? :) How about: o The set of composite mechanisms indicated by GSS_Indicate_mechs() SHOULD be configurable. > 5.1. New GSS-API Function Interfaces > > This section looks like it uses the exact same text as 4.4, but > just in a paragraph instead of bullet-items. What's the point > of that? It also has the same syntactic issue as 4.4: Good point. I think most of section 5.1 can be replaced with a reference to section 4.4. > GSS_Indicate_mechs() > MAY indicate support for some, all or none of the available composite > mechanisms; which composite mechanisms, if any, are indicated through > GSS_Indicate_mechs() SHOULD be configurable. > > should probably get re-written in the same way as 4.4: > > ... any composite mechanisms indidicated through GSS_Indicate_mechs() > SHOULD be configurable. > > > 5.1.4. GSS_Indicate_negotiable_mechs() > > > o peer_type_known BOOLEAN, -- indicates whether the peer is known to > support or not supprot the stackable pseudo-mechanism framework. > > supprot -> support *nod* > > GSS_Inquire_cred()), but composite mechanisms will be included either > implicitly or implicitly as per the following rules: > > "implicitly or implicitly"? I think it should be "explicitly or implicitly" Come to think of it, those three words should be removed altogether. > General Comments... > > This document talks about "rules for mechanism composition" but > nowhere does it discuss a way to encode these rules. How do I express > these rules? The draft mentions a means to upgrade these rules, but > not where these rules need to get stored. There is no need to encode these rules. The intention is that SPIs between framework and plug-in mechanisms should be used so that mechanisms evaluate proposed compositions themselves. Since existing pluggable GSS framework implementations tend to have SPIs derived from the GSS-API itself, then, the where the extended mechanism inquiry APIs are available stackable mechanisms would be expect to use them to discover the attributes of mechanisms stacked below and evaluate whether a composition is valid. E.g., the framework would call a stackable mechanism's GSS_Inquire_attrs_for_mech() function on a composite mechanism's OID -- the result would be GSS_S_BAD_MECH for bad compositions, or GSS_S_COMPLETE and a set of mechanism attributes for good compositions. Where the extended mechanism iquiry APIs are not available the set of valid composite mechanisms has to be constructed by hand as there would then be no way to dynamically evaluate proposed compositions. > draft-ietf-kitten-extended-mech-inquiry-02.txt > > > No Introduction? Is one always needed? > > 3. New GSS-API Interfaces > > The opening sentence is awkwardly composed. I recommend changing it to: > > Today GSS-API applications face the problem of how to select from > multiple GSS-API mechanisms that may be available. OK. > > 3.5. New GSS-API Function Interfaces > > This section uses similar text to the other draft. In particular: > > support for any stackable pseduo-mechanisms. GSS_Indicate_mechs() > MAY indicate support for some, all or none of the available composite > mechanisms; which composite mechanisms, if any, are indicated through > GSS_Indicate_mechs() SHOULD be configurable. GSS_Acquire_cred() and > > The 'which' portion should be re-written as suggested for the previous > draft. See above. > > > General comments: > > Again, the document mentions the composition rules but doesn't > specify them or how to use them. It cannot and so won't specify them. Stackable mechanisms must specify their own composition rules. No formal composition rule language is needed because the API/SPI allows for stackable mechanisms to implement their rules as code. A formal composition rule language could be worked out, but it does not seem necessary. We describe lots of normative things in English now throughout IETF documents, and there is a real tension between too much use of formal specification languages and too little (see KRB WG threads on use of advanced ASN.1 techniques to increase formalism). > This document has no security considerations. Good point. I'll write one up. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 12:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhV8T-0002Ko-Qu; Tue, 07 Nov 2006 12:53:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhV8S-0002Kb-QX for kitten@ietf.org; Tue, 07 Nov 2006 12:53:20 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhV8R-0004pG-I9 for kitten@ietf.org; Tue, 07 Nov 2006 12:53:20 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7HrIZt010398 for ; Tue, 7 Nov 2006 12:53:19 -0500 (EST) Received: from [75.212.58.98] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.2) with ESMTP id md50000034172.msg for ; Tue, 07 Nov 2006 12:56:54 -0500 Message-ID: <4550C8E0.1040200@secure-endpoints.com> Date: Tue, 07 Nov 2006 09:56:48 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 12:56:54 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.212.58.98 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: IETF67 Meeting Reminder X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887286479==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0887286479== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040409030105060700060709" This is a cryptographically signed message in MIME format. --------------ms040409030105060700060709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kitten will be meeting today at IETF67 in San Diego. TUESDAY, November 7, 2006 1520-1720 Afternoon Session II (PST) Seabreeze Jabber Room: kitten@jabber.ietf.org Audio Stream: http://videolab.uoregon.edu/events/ietf/ietf672.m3u Agenda: Discussion of Documents in Working Group Last Call "An Update to the Java GSS-API Specification" "Stackable Generic Security Service Pseudo-Mechanisms" "Extended Generic Security Service Mechanism Inquiry APIs" Status of Internationalization Charter Revision Status Open Mic --------------ms040409030105060700060709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDcxNzU2NDhaMCMGCSqGSIb3DQEJBDEWBBR7x5UZ 2dYP+5xLV6q4nCEYbuzOcjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAUT4y6Cw58im+IKSl3WluJVDsjBDSreSqTbydvJJ6y1KUlqaHjXKD 5DYX7PvRcBH8d/zz7QTxP51ShYnjWh070oAMVgcc4lkb8NZVTChngv9W/ApzNioW2cehPQHN sOCe+OIaMMxVLKqBiq9YUuM7FUTDqD/KA5/XA+0yLLNWmiU2lIqgtRfXhqauvPiQ1eJVdbBa 5MC9zCJxRKiOIdaJxvjGOc8IGcTXtjxu/aTWNoxvLX/fi1mV40KWv72GupFjcKEcIKcr2Dux 1xMNYJE/Gk/h5kQN7EJ6osaZ37eFtdPOxvnxwE8j2rWjlpdsWMJUlmvOUy1Ai3UHhS8TAnW1 UgAAAAAAAA== --------------ms040409030105060700060709-- --===============0887286479== 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 --===============0887286479==-- From kitten-bounces@lists.ietf.org Tue Nov 07 13:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVry-0006k8-8I; Tue, 07 Nov 2006 13:40:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhVrw-0006ib-Tc for kitten@ietf.org; Tue, 07 Nov 2006 13:40:20 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVrv-0004U9-KG for kitten@ietf.org; Tue, 07 Nov 2006 13:40:20 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA7IeIvl020695 for ; Tue, 7 Nov 2006 13:40:19 -0500 (EST) Received: from [75.212.58.98] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.2) with ESMTP id md50000034183.msg for ; Tue, 07 Nov 2006 13:43:54 -0500 Message-ID: <4550D3E1.7060106@secure-endpoints.com> Date: Tue, 07 Nov 2006 10:43:45 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: kitten@ietf.org, ietf-krb-wg@anl.gov References: <20061107060522.GV25646@binky.Central.Sun.COM> In-Reply-To: <20061107060522.GV25646@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 07 Nov 2006 13:43:54 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 75.212.58.98 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: Re: AD review comments for the GSS-API domain name specs X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961086242==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1961086242== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010403010706010102010600" This is a cryptographically signed message in MIME format. --------------ms010403010706010102010600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Fri, Oct 20, 2006 at 08:39:14AM -0400, Sam Hartman wrote: >> These AD comments need to be fixed. However they are rather minor so >> I'm going to last call the comments in parallel. >> >> draft-ietf-kitten-gssapi-domain-based-names : >> >> * There is no IANA considerations section yet actions (allocation of >> an oid) are requested of IANA > > Actually, the IANA may have no role to play and my note in the I-D may > have been incorrect. > > I cannot find an IANA registry for the 1.3.6.1.5.6 sub-tree. RFC2743 > establishes an IANA registry of _service names_ but not of name types. > > So I wouldn't quite know how to write instructions to IANA about this > short of actually writing instructions for establishing the missing > registry. We have a separate I-D on IANA registries for the GSS-API, > but I don't want this I-D to block on that one. And since the existing > name type OIDs have been allocated by Standards Track RFCs I believe the > right thing to do is to remove my note about the allocation of this OID. I believe the OID should be allocated by standards action. The IANA allocation reference should be removed. >> * Do we really want to recommend _foo._tcp.example.tld instead of just >> example.tld? > > I don't think I care one way or the other. There is a typo in the draft in that it uses _tcp._foo.example.tld. I would replace this with _service._protocol.example.tld. The DNS SRV record specification indicates that it should use service and protocol as specified in the standards document defining the service protocol. Our documents should not be conflicting with that advice. >> draft-ietf-kitten-krb5-gssapi-domain-based-names >> >> What does the following text mean: >> >> o the realm of the resulting principal name is that which >> corresponds to the domain name, treated as a hostname. >> >> I think you may mean something like: As with host-based service names, >> implementations need to choose the appropriate realm for the Kerberos >> principal corresponding to the domain-based name. This realm is the >> Kerberos realm that is authoritative for the domain portion of the >> name, not the host portion of the name. Typically Kerberos >> implementations have a facility that can map a host name to a realm; >> implementations MAY use the realm that results from providing the >> domain portion of the name as an input into this facility. > > Yes. > > Do you have better text suggestions? How about: > > o the realm of the resulting principal name SHALL be that which > would be used for a hostname whose name is the same as the domain > name component of the domain-based service name. I think this proposed text is fine. Jeffrey Altman (speaking as an individual) --------------ms010403010706010102010600 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDcxODQzNDVaMCMGCSqGSIb3DQEJBDEWBBS1qMNZ yZU0EYWrkeH9HyTL+OEsHjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAnHatMneeIdYn8o6GLpRgc1XiG3BKwk66VmSBhguQRZGWkloBViAK VY0TXlLzrehxMM0aC05eHNPUZ84rQZEc1QHx7EB5HZZWArj+V5c9jAo7+JAP0OvMY5RBcFdU hei58d9LoLUcb9CkEhc430MUyTXQwDeMluSqQUO0RaVnSD+YrI7ZAGw13nFXJa5erFr95wUS dWEba8fdHeI/1KEyMCdAeL4E6U5ssFwiOOn6MCSJU3o8r5dcCFQfdxQgaGd9zZg6w6hApJCb DbgQiMi7KmaLf3QzjY4COClzLNh1NcHqNiSLmTZ1rHcOwboWxUMzEo1EQKHBM4htQQ1tJD5z lAAAAAAAAA== --------------ms010403010706010102010600-- --===============1961086242== 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 --===============1961086242==-- From kitten-bounces@lists.ietf.org Tue Nov 07 14:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWF4-0007if-KT; Tue, 07 Nov 2006 14:04:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWF3-0007iU-Ap for kitten@ietf.org; Tue, 07 Nov 2006 14:04:13 -0500 Received: from dhcp68-116.ietf67.org ([130.129.68.116] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWF0-0007j1-27 for kitten@ietf.org; Tue, 07 Nov 2006 14:04:13 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AABA8E0035; Tue, 7 Nov 2006 14:03:59 -0500 (EST) From: Sam Hartman To: kitten@ietf.org References: <20061107060522.GV25646@binky.Central.Sun.COM> Date: Tue, 07 Nov 2006 14:03:59 -0500 In-Reply-To: <20061107060522.GV25646@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 7 Nov 2006 00:05:22 -0600") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf-krb-wg@anl.gov Subject: Re: AD review comments for the GSS-API domain name specs 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: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Yes. Nicolas> Do you have better text suggestions? How about: Nicolas> o the realm of the resulting principal name SHALL be Nicolas> that which would be used for a hostname whose name is the Nicolas> same as the domain name component of the domain-based Nicolas> service name. Works for me. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 14:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWeM-0003v9-MB; Tue, 07 Nov 2006 14:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWeL-0003uw-U5 for kitten@ietf.org; Tue, 07 Nov 2006 14:30:22 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWeJ-00028Y-GV for kitten@ietf.org; Tue, 07 Nov 2006 14:30:21 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA25784 for ; Tue, 7 Nov 2006 20:30:17 +0100 (MEZ) From: Martin Rex Message-Id: <200611071930.UAA16317@uw1048.wdf.sap.corp> Orig-To: jaltman@secure-endpoints.com To: kitten@ietf.org Date: Fri, 3 Nov 2006 17:48:40 +0100 (MET) In-Reply-To: <45367FF9.4090306@secure-endpoints.com> from "Jeffrey Altman" at Oct 18, 6 03:26:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Nicolas.Williams@sun.com Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey, Nico, Jeffrey Altman wrote: > > The Kitten Chair has received a request to submit > "Stackable Generic Security Service Pseudo-Mechanisms" > > to the IESG for publication as a Proposed Standard. > > The working group last call will terminate at 00:00 EST 2 November 2006. I'm sorry, It looks like I missed the last call period. So I'm sending this to you directly. Stackable pseudo-mechanisms looks very ambitious to me -- a magnitude more ambitious than binary plug'n'play with shared libraries. I can not seriously comment on the document, because I lack the time to read it carefully and think about it, and I don't have any implementation or usage experience with this concept. Two observations: - A lot of existing gss-api mechanism do not return a mechanism OID from failing (initial) gss_init_sec_context() and gss_accept_sec_context() while at the same time they return a mechanism-specific minor_status. This may create a difficulty for gss_display_status(minor_status) to identify the particular gssapi mechanims that created this minor status. - The reason for CAT to drop gss_release_oid() and friends from the v2 spec was the incompatibilities between different heap (m)allocators, and the resulting problem for gss_release_oid() to distinguish (originally purely-static) OIDs from dynamic ones created by the gssapi mechanism. On Windows and OS/2, each DLL may use its own/seperate instance of a heap (m)allocater, and considering the explosion of incompaible MSVCRT.DLLs (VS.NET 2003/2005) using the WinSxS scheme, this is actually the norm today for software that meets in the field (and is not produced in a single compile). So it would be useful to re-iterate in the description of gss_release_oid() that all OIDs from the exiting gss-api v2 functions are static/readonly and must NOT be passed to this new optional function. The current wording "by another GSS-API call, specifically ..." sounds ambiguous in a dangerous fashion. I'm not sure who might be the real target audience for the stackable GSS Mech spec. IMHO, it's not the portable applications writer that call gss-api v2. How would a portable application writer benefit from CCM? Would it require a gss-api (multi-)mechanism that used these extensions to provide the benefit in a gss-api v2 transparent fashion? -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 14:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWen-00043p-96; Tue, 07 Nov 2006 14:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWel-00042O-SO for kitten@ietf.org; Tue, 07 Nov 2006 14:30:47 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWej-0002AU-GK for kitten@ietf.org; Tue, 07 Nov 2006 14:30:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA09208 for ; Tue, 7 Nov 2006 20:30:43 +0100 (MEZ) From: Martin Rex Message-Id: <200611071930.UAA16428@uw1048.wdf.sap.corp> Orig-To: jaltman@secure-endpoints.com To: kitten@ietf.org Date: Fri, 3 Nov 2006 19:42:05 +0100 (MET) In-Reply-To: <454B75DE.8030302@secure-endpoints.com> from "Jeffrey Altman" at Nov 3, 6 12:01:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > > Martin: > > Please send this to the list. Even if it is beyond the last call > period. I can't pass a last call without positive feedback and > so far there has been none during the last call period. Actually, *I* do not think the stackable pseudo mechanism and the mechanism inquiry apis should go for standards track due to a significant lack of peer review, and (independent) implementation experience. Standardizing APIs is extremely difficult, and the IETF has a tradition to avoid standardizing APIs. CAT/GSS-API is an exemption, and it took quite a number of active individuals to agree on a useful spec -- which still contains some grey and/or contentious areas. In the past there had been at least two approaches to an authorization API extension for GSS-API (XGSS-API from Bull and GAA), but CAT did not put either one on the standards track. Btw. GSS-API v1 wasn't developed within the IETF either, it was a fairly complete proposal from DEC (desigend for use in DCE). There is one other API standard that *I* consider a failure, and that is GSS-API IDUP. Lack of independet implementation experience is bad for a standard, and particularly bad for an API standard. And lack of independent implementation experience has led to a number of problems in SPKM. The more than questionable use of real digital signatures for message integrity protection and the braindead boasting about "non-repudiation" all over the document (rfc2025) as well as the non-obvious and actually quite product-specific enumeration of crypto-algorithms in the QOP parameter are issues where the problem becomes visible -- for serious reviewers. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 14:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWg3-0004Kv-Tw; Tue, 07 Nov 2006 14:32:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhWg2-0004Jb-O8 for kitten@ietf.org; Tue, 07 Nov 2006 14:32:06 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhWg0-0002Fu-44 for kitten@ietf.org; Tue, 07 Nov 2006 14:32:06 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA26999 for ; Tue, 7 Nov 2006 20:32:02 +0100 (MEZ) From: Martin Rex Message-Id: <200611071932.UAA16458@uw1048.wdf.sap.corp> Orig-To: Nicolas.Williams@sun.com (Nicolas Williams) To: kitten@ietf.org Date: Tue, 7 Nov 2006 20:07:13 +0100 (MET) In-Reply-To: <20061107063129.GY25646@binky.Central.Sun.COM> from "Nicolas Williams" at Nov 7, 6 00:31:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: jaltman@secure-endpoints.com Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > > Two observations: > > - A lot of existing gss-api mechanism do not return a mechanism OID > ^ > implementations, right? Right. > > Unless the header on the initial context token is corrupted there is > always an OID available. > > > from failing (initial) gss_init_sec_context() and gss_accept_sec_context() > > while at the same time they return a mechanism-specific minor_status. > > This may create a difficulty for gss_display_status(minor_status) > > to identify the particular gssapi mechanims that created this > > minor status. > > We have this difficulty now with SPNEGO. I think an explicit mentioning of the issue and the shortcoming in many existing implementations might help to improve the situation in the future. > > > - The reason for CAT to drop gss_release_oid() and friends from > > the v2 spec was the incompatibilities between different > > heap (m)allocators, and the resulting problem for gss_release_oid() > > to distinguish (originally purely-static) OIDs from dynamic ones > > created by the gssapi mechanism. On Windows and OS/2, each DLL > > may use its own/seperate instance of a heap (m)allocater, and > > considering the explosion of incompaible MSVCRT.DLLs (VS.NET 2003/2005) > > using the WinSxS scheme, this is actually the norm today for software > > that meets in the field (and is not produced in a single compile). > > Ah, but the same problem exists with gss_release_buffer(). Nope, it doesn't apply to gss_release_buffer. All >>output<< parameters of type gss_buffer_t are dynamically allocated by the gssapi mechanism and must be passed to gss_release_buffer(). Except for gss_release_buffer(), >>input<< gss_buffer_t parameters are to be considered read-only by a gssapi mechanism implementation. (Nit-picking: the gss_buffer_desc structure is always owned by the application caller, only the contents of gss_buffer_t output parameters are dynamically allocated and therefore owned by the gssapi mechanism). The difference with dynamic OIDs is, that there are several existing gssapi calls that provide gss_OID output parameters, but all of them are read-only/static (because there was no gss_release_oid() in GSS-API v1, and there is none in GSS-API v2u1). You're now about to create gss-api calls that create dynamically allocated OIDs, and that is a significant change in semantics, so it deserves an explicit warning label. The textual description of gss_release_oid() in the GSS-API cbindings draft at the time when rfc2078.txt was published was extremely dangerous. > > > I'm not sure who might be the real target audience for the > > stackable GSS Mech spec. IMHO, it's not the portable applications > > writer that call gss-api v2. > > The same might apply to SPNEGO. No, not really. SPNEGO was designed so that the portable application callers should be able to transparently benefit from it. SPNEGO doesn't need any additional API calls, and the more "portable" the application, the more likely simple client components will "just work", indepent on what mechanism(s) the administrator installs. > > > require a gss-api (multi-)mechanism that used these extensions > > to provide the benefit in a gss-api v2 transparent fashion? > > No, it wouldn't. The extended mech inquiry functions are there to make > it possible to safely construct composite mechanisms; without these the > composite mechanisms can only be pre-configured. I meant a (gssapi mechanism of the composite type, i.e. one combines existing gssapi mechanisms, but looks like a seperate gssapi mechanism to a portable application. As you might have noticed, there is a real problem with resource management (gss_buffer_t and gss_OID_set) when trying to build a multi-mechanism on top of several existing gss-api mechanisms or a single- or multi-mechanism of the composite type, because you either need to memorize where dynamically allocated gss_OID_set and gss_buffer_t originated, or you need to blindly copy them on output and have the top layer become the owner / resource manager and avoid the problem of not knowing what to do if gss_release_oid_set or gss_release_buffer is called. For message protection, this results in extra copying of data. When not using a "standardized" API and building a monolithic multi-mechanism, one can optimize by either using the same heap (m)allocator, or by always having the top layer allocate the return buffer and provide them to the lower layers. Therefore a kind of callback like gss_alloc_buffer(), offered by the intermediate "multi-mech or composite-mech glue" and called by the lower-layer gssapi mechanism might reduce the amount of copying. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 15:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX7W-0001U1-FX; Tue, 07 Nov 2006 15:00:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX7U-0001Rs-Ld for kitten@ietf.org; Tue, 07 Nov 2006 15:00:28 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhX7T-0005EG-8G for kitten@ietf.org; Tue, 07 Nov 2006 15:00:28 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA22258; Tue, 7 Nov 2006 21:00:21 +0100 (MEZ) From: Martin Rex Message-Id: <200611072000.VAA17486@uw1048.wdf.sap.corp> To: jaltman@secure-endpoints.com Date: Tue, 7 Nov 2006 21:00:21 +0100 (MET) In-Reply-To: <4550DD3A.3090409@secure-endpoints.com> from "Jeffrey Altman" at Nov 7, 6 11:23:38 am 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-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Altman wrote: > > Please take this to the list. I just re-sent my Emails on this to kitten@ietf.org > > Martin Rex wrote: > > Nope, it doesn't apply to gss_release_buffer. > > > > All >>output<< parameters of type gss_buffer_t are dynamically allocated > > by the gssapi mechanism and must be passed to gss_release_buffer(). > > It does apply to gss_release_buffer because >>input<< buffers are > allocated by the application and the application developer is too > stupid to know the difference and passes the gss_buffer_t that s/he > allocated into gss_release_buffer. Unfortunately there is little that protects us from unexperienced and sloppy programmers. Even the gss-sample supplied by MIT contained a number of serious bugs including one of these (I don't know whether the one in the MIT distribution got fixed, I fixed my copy in my windows SSPI wrapper gsskrb5-108.zip a while ago. It isn't that hard to write robust and close to error-free code in the C Language, but a lot of code that I've encountered in the OpenSource space is brittle, buggy and uses extremely dangerous coding style, and that includes Motif, X11, OpenSSL and MIT Kerberos. The X11 code snipped in a recent (08-sep-06) posting is a real pain to look at. http://www.securityfocus.com/archive/1/445579/50/1000/threaded A braindead approach to implement a case-insensitive string compare. (I've seen an even worse example a few years ago) Ask a C-programmer to implement strcasecmp/strncasecmp and you will learn a lot about his programming skills (or the lack thereof). If code like this (obviously broken, obvious security problem, very small function, easy to review) is part of X11, then there are very likely thousands of other severe problems still in there. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 15:15:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXLo-0001lF-AG; Tue, 07 Nov 2006 15:15:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXLn-0001l9-7J for kitten@ietf.org; Tue, 07 Nov 2006 15:15:15 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXLm-0006lI-0P for kitten@ietf.org; Tue, 07 Nov 2006 15:15:15 -0500 Received: from [130.129.67.91] (dhcp67-91.ietf67.org [130.129.67.91]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA7KF7JH016434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Nov 2006 15:15:13 -0500 (EST) Message-ID: <4550EA1A.1080008@secure-endpoints.com> Date: Tue, 07 Nov 2006 12:18:34 -0800 From: Jeffrey Altman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: martin.rex@sap.com References: <200611072000.VAA17486@uw1048.wdf.sap.corp> In-Reply-To: <200611072000.VAA17486@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Martin Rex wrote: > Jeffrey Altman wrote: >> Please take this to the list. > > I just re-sent my Emails on this to kitten@ietf.org Thank you. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 15:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXk5-0000Kf-La; Tue, 07 Nov 2006 15:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXk5-0000KV-5r for kitten@ietf.org; Tue, 07 Nov 2006 15:40:21 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXk2-0001La-Pb for kitten@ietf.org; Tue, 07 Nov 2006 15:40:21 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA12813; Tue, 7 Nov 2006 21:40:14 +0100 (MEZ) From: Martin Rex Message-Id: <200611072040.VAA18901@uw1048.wdf.sap.corp> To: martin.rex@sap.com Date: Tue, 7 Nov 2006 21:40:14 +0100 (MET) In-Reply-To: <200611072000.VAA17486@uw1048.wdf.sap.corp> from "Martin Rex" at Nov 7, 6 09:00: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-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: jaltman@secure-endpoints.com, kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Martin Rex wrote: > > It isn't that hard to write robust and close to error-free code > in the C Language, but a lot of code that I've encountered in the > OpenSource space is brittle, buggy and uses extremely dangerous > coding style, and that includes Motif, X11, OpenSSL and MIT Kerberos. To be fair, this problem is *NOT* limited to OpenSource, it is at least as bad in the proprietary code world. My experiences with MIT Kerberos are from around 1996 and with OpenSSL from around 2000. The problem with bad OpenSource code quality is that it is much more likely giving a bad example to a larger (unskilled) audience than closed source code. It is much more available to Internet search engines. More appropriate examples for strcasecmp/strncasecmp are likely found in the BSD c-library or the GNU glibc, but they were probably not changed recently, and therefore might have a lesser chance to show up in search engines than fairly new and broken implementations in application projects... :-\ Sometimes the code is not really broken, just inadequate or inefficient, and therefore giving a bad example. E.g. mkstemp() in Cygwin32 The majority of windows filesystems are case-insensitive, but the alphabet of filesystem-safe characters in cygwin32's mkstemp() inappropriately includes both, the upper and the lower case characters. A lot of base64 decoders use a char * ptr; char * b64_alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ "abcdefghijklmnopqrstuvwxyz" "0123456789+/"; ... ptr = strchr(b64_alphabet, *src); if ( ptr!=NULL ) { n = ptr - b64_alphabet; Although this code does _not_ contain an error, it should be painfully obvious to a decent programmer that it is extremely inefficient. Sorry for getting way off topic. Any Responses/comment perferably as private emails and not to the kitten list. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 15:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXoL-0003GO-1W; Tue, 07 Nov 2006 15:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhXoJ-0003GC-JI for kitten@ietf.org; Tue, 07 Nov 2006 15:44:43 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhXoG-0001rd-8R for kitten@ietf.org; Tue, 07 Nov 2006 15:44:43 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7KidZC017781 for ; Tue, 7 Nov 2006 12:44:39 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7KicEr017057 for ; Tue, 7 Nov 2006 13:44:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7Kicx5028154; Tue, 7 Nov 2006 14:44:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7KibD3028153; Tue, 7 Nov 2006 14:44:37 -0600 (CST) Date: Tue, 7 Nov 2006 14:44:37 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20061107204436.GD25646@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <454B75DE.8030302@secure-endpoints.com> <200611071930.UAA16428@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611071930.UAA16428@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Nov 03, 2006 at 07:42:05PM +0100, Martin Rex wrote: > Jeffrey Altman wrote: > > > > Martin: > > > > Please send this to the list. Even if it is beyond the last call > > period. I can't pass a last call without positive feedback and > > so far there has been none during the last call period. > > Actually, *I* do not think the stackable pseudo mechanism and the > mechanism inquiry apis should go for standards track due to a > significant lack of peer review, and (independent) implementation > experience. That's not a reason to never get to Standards Track. That may be a reason to fail the WGLC and have another round some time down the line. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 16:03:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY6G-00028z-Ic; Tue, 07 Nov 2006 16:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhY6F-00027H-1U for kitten@ietf.org; Tue, 07 Nov 2006 16:03:15 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhY6D-0004V0-LZ for kitten@ietf.org; Tue, 07 Nov 2006 16:03:15 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA27871; Tue, 7 Nov 2006 22:03:07 +0100 (MEZ) From: Martin Rex Message-Id: <200611072103.WAA19795@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 7 Nov 2006 22:03:08 +0100 (MET) In-Reply-To: <20061107204436.GD25646@binky.Central.Sun.COM> from "Nicolas Williams" at Nov 7, 6 02:44:37 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Fri, Nov 03, 2006 at 07:42:05PM +0100, Martin Rex wrote: > > Jeffrey Altman wrote: > > > > > > Martin: > > > > > > Please send this to the list. Even if it is beyond the last call > > > period. I can't pass a last call without positive feedback and > > > so far there has been none during the last call period. > > > > Actually, *I* do not think the stackable pseudo mechanism and the > > mechanism inquiry apis should go for standards track due to a > > significant lack of peer review, and (independent) implementation > > experience. > > That's not a reason to never get to Standards Track. That may be a > reason to fail the WGLC and have another round some time down the line. Maybe the IESG take on this has *SIGNIFICANTLY* changed in the last years. But the message from Jeff Schiller up until 1998 was clear: The IETF does NOT do APIs, and GSS-API was an exemption, and on the bottom line it was really expensive (resource-wise in the IETF), because it took many participants in the security area so many years to agree on GSS-API v2. APIs, and especially abstract APIs are quite complex, and the IETF standardization process requires a lot of effort, unless you intend to abuse it for pure rubber-stamping. There is no IETF standard for PAM, and still it is being used successfully. I do not see a benefit from having an IETF "proposed standard" tag on these proposals. However, the cost to update or fix a proposed standard will be enormous. A BCP document on how to use gssapi would provide a much greater benefit for the community than these documents, and - coincidentally - we already have that issue on the kitten wg agenda... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 16:07:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYA5-000400-K9; Tue, 07 Nov 2006 16:07:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYA3-0003zn-LW for kitten@ietf.org; Tue, 07 Nov 2006 16:07:11 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYA2-0004zN-9C for kitten@ietf.org; Tue, 07 Nov 2006 16:07:11 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7L7994025600 for ; Tue, 7 Nov 2006 13:07:09 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7L7951007109 for ; Tue, 7 Nov 2006 14:07:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7L79j2028172; Tue, 7 Nov 2006 15:07:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7L799g028171; Tue, 7 Nov 2006 15:07:09 -0600 (CST) Date: Tue, 7 Nov 2006 15:07:09 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20061107210708.GF25646@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20061107204436.GD25646@binky.Central.Sun.COM> <200611072103.WAA19795@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611072103.WAA19795@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Nov 07, 2006 at 10:03:08PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Fri, Nov 03, 2006 at 07:42:05PM +0100, Martin Rex wrote: > > > Jeffrey Altman wrote: > > > > > > > > Martin: > > > > > > > > Please send this to the list. Even if it is beyond the last call > > > > period. I can't pass a last call without positive feedback and > > > > so far there has been none during the last call period. > > > > > > Actually, *I* do not think the stackable pseudo mechanism and the > > > mechanism inquiry apis should go for standards track due to a > > > significant lack of peer review, and (independent) implementation > > > experience. > > > > That's not a reason to never get to Standards Track. That may be a > > reason to fail the WGLC and have another round some time down the line. > > Maybe the IESG take on this has *SIGNIFICANTLY* changed in the last > years. But the message from Jeff Schiller up until 1998 was clear: > The IETF does NOT do APIs, and GSS-API was an exemption, and > on the bottom line it was really expensive (resource-wise in > the IETF), because it took many participants in the security area > so many years to agree on GSS-API v2. We've been over this. We've been chartered. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 16:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYa4-0006Bn-9G; Tue, 07 Nov 2006 16:34:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYa2-0006Bd-De for kitten@ietf.org; Tue, 07 Nov 2006 16:34:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYa0-0000P7-JD for kitten@ietf.org; Tue, 07 Nov 2006 16:34:02 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7LY0BC014705 for ; Tue, 7 Nov 2006 14:34:00 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7LXxwZ000718 for ; Tue, 7 Nov 2006 14:33:59 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7LXx2X028188; Tue, 7 Nov 2006 15:33:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7LXxSH028187; Tue, 7 Nov 2006 15:33:59 -0600 (CST) Date: Tue, 7 Nov 2006 15:33:59 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20061107213358.GG25646@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20061107204436.GD25646@binky.Central.Sun.COM> <200611072103.WAA19795@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611072103.WAA19795@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Nov 07, 2006 at 10:03:08PM +0100, Martin Rex wrote: > I do not see a benefit from having an IETF "proposed standard" tag > on these proposals. However, the cost to update or fix a > proposed standard will be enormous. Now that's another story. It may be that we should have different "tags" for APIs than for protocols. That might have been useful input to the NEWTRK WG back before it concluded. As it is these are the RFC categories we have. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 16:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYid-0004XH-7c; Tue, 07 Nov 2006 16:42:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYib-0004Rr-JF for kitten@ietf.org; Tue, 07 Nov 2006 16:42:53 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYia-0001WN-71 for kitten@ietf.org; Tue, 07 Nov 2006 16:42:53 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA09832; Tue, 7 Nov 2006 22:42:43 +0100 (MEZ) From: Martin Rex Message-Id: <200611072142.WAA21258@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 7 Nov 2006 22:42:43 +0100 (MET) In-Reply-To: <20061107210708.GF25646@binky.Central.Sun.COM> from "Nicolas Williams" at Nov 7, 6 03:07:09 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: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > > > > Maybe the IESG take on this has *SIGNIFICANTLY* changed in the last > > years. But the message from Jeff Schiller up until 1998 was clear: > > The IETF does NOT do APIs, and GSS-API was an exemption, and > > on the bottom line it was really expensive (resource-wise in > > the IETF), because it took many participants in the security area > > so many years to agree on GSS-API v2. > > We've been over this. We've been chartered. Look at the goals and milestones of the charter. Either a BCP or a GSS-API v2u2 is on top of that list and should be long done... I'm not against making your API extenstions an IETF standard eventually, but I violently opposed to making it an IETF standard in the very near future without serious peer review and independent implementation experience. I'm also ok with having discussion about these APIs on the Kitten mailing list. But... When I joined the IETF in May 1995, CAT was trying to finish GSS-API v2. Look at how long it took CAT to finish what is known as rfc2743/2744. It took me several years to review the specs and come up with lots of comments, review and implementation experience. I'm glad that GSS-API v2 wasn't submitted in 1995. GSS-API v2 would have been significantly less clear and less useful back then. Having the documents at draft status for so many years was good for the quality/usability of the final document (i.e. the standard), but at the same time it is fairly alien to the IETF process of creating standards (charter,milestones). Before we submit new API extensions that include printable input or outputs, we should make a recommendation/guideline on i18n/l10n for such printables -- as we all know, that issue is still open even for the existing GSS-API v2u1 (with the c-bindings spec recommending the use of iso-latin-1). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 16:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYla-00088W-Oa; Tue, 07 Nov 2006 16:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYlZ-00088F-FP for kitten@ietf.org; Tue, 07 Nov 2006 16:45:57 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYlU-0001sZ-Vp for kitten@ietf.org; Tue, 07 Nov 2006 16:45:57 -0500 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA7LjmHe025520 for ; Tue, 7 Nov 2006 13:45:48 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kA7LjlUm011539 for ; Tue, 7 Nov 2006 14:45:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kA7Ljl5L028199; Tue, 7 Nov 2006 15:45:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7LjlNa028198; Tue, 7 Nov 2006 15:45:47 -0600 (CST) Date: Tue, 7 Nov 2006 15:45:47 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20061107214547.GH25646@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , kitten@ietf.org References: <20061107210708.GF25646@binky.Central.Sun.COM> <200611072142.WAA21258@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611072142.WAA21258@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org Subject: Re: Working Group Last Call: Stackable Generic Security Service 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: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Nov 07, 2006 at 10:42:43PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > > > > > Maybe the IESG take on this has *SIGNIFICANTLY* changed in the last > > > years. But the message from Jeff Schiller up until 1998 was clear: > > > The IETF does NOT do APIs, and GSS-API was an exemption, and > > > on the bottom line it was really expensive (resource-wise in > > > the IETF), because it took many participants in the security area > > > so many years to agree on GSS-API v2. > > > > We've been over this. We've been chartered. > > Look at the goals and milestones of the charter. > Either a BCP or a GSS-API v2u2 is on top of that list > and should be long done... We do what we can and when we can. We're volunteers. If the IESG has a problem with our milestones they can tell us. > I'm not against making your API extenstions an IETF standard eventually, > but I violently opposed to making it an IETF standard in the > very near future without serious peer review and independent > implementation experience. We're in the process of obtaining review. > I'm also ok with having discussion about these APIs on the Kitten > mailing list. But... And if you weren't? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Nov 07 17:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZMe-0002ws-Gr; Tue, 07 Nov 2006 17:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYuN-0003Vr-Fu for kitten@ietf.org; Tue, 07 Nov 2006 16:55:03 -0500 Received: from irvbhxw02.quest.com ([12.106.87.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYuG-00031h-8p for kitten@ietf.org; Tue, 07 Nov 2006 16:55:03 -0500 Received: from [10.100.0.16] ([10.20.36.132]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 13:54:42 -0800 Message-ID: <45510098.6050601@quest.com> Date: Wed, 08 Nov 2006 07:54:32 +1000 From: David Leonard User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nicolas Williams References: <45507F6D.8030100@quest.com> <20061107163008.GZ25646@binky.Central.Sun.COM> In-Reply-To: <20061107163008.GZ25646@binky.Central.Sun.COM> X-OriginalArrivalTime: 07 Nov 2006 21:54:42.0732 (UTC) FILETIME=[54BD6EC0:01C702B7] X-Spam-Score: 0.5 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-Mailman-Approved-At: Tue, 07 Nov 2006 17:24:15 -0500 Cc: kitten@ietf.org Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: , Content-Type: multipart/mixed; boundary="===============0244529726==" Errors-To: kitten-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0244529726== Content-Type: multipart/alternative; boundary="------------050301020303080908000204" This is a multi-part message in MIME format. --------------050301020303080908000204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >> In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be >> returned. I think it should be expected that a future caller could be >> searching for an attribute OID that the implementation doesn't know about. >> > > GSS_Indicate_mechs_by_attr() could just return an empty OID set instead > of GSS_BAD_MECH_ATTR. See below. > Yes, I think it should. >> s 3.5.3 does not mention language/locale/encoding with the short_desc >> and long_desc description output of GSS_Display_mech_attr(). Is that >> deliberate? Could I assume it will sensitive to the 'current' locale, >> and return UTF-8? I notice RFC2743 doesn't address this with the other >> GSS_Display calls, so maybe this is addressed more generally? >> > > RFC2743 does not address this, no. RFC2744 says "Latin-1." > Thanks for the RFC2744/Latin-1 pointer. Also, should the two tables in the draft correspond to the short and long descriptions from GSS_Display_mech_attr()? That is to ask was it your intent that the short and long text of (say) GSS_C_MA_MECH_CONCRETE in English should be "concrete-mech" and "Indicates that a mech is neither a pseudo- mechanism nor a composite mechanism" respectively? I ask this as implementation guidance, but perhaps the draft might benefit by explicitly recommending such an approach? (Otherwise the meanings of long and short are floating) This also leads to the idea of (ab)using GSS_Display_mech_attr() to search for an attribute OID by its short description. That strikes me as a pretty attractive thing to do when processing human-entered configuration files. Sadly, it's precluded because "human-readable" doesn't mean "matchable to what a human writes" (but it does make me wonder about human-convenient namespace for OIDs.) > ... > Note that here GSS_BAD_MECH_ATTR is useful. > > Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR. > I think keep it BAD, which is consistent with GSS_BAD_MECH and is used to mean "unrecognized" amongst other things. Thanks! David Leonard --------------050301020303080908000204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: 
In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be 
returned. I think it should be expected that a future caller could be 
searching for an attribute OID that the implementation doesn't know about.
    

GSS_Indicate_mechs_by_attr() could just return an empty OID set instead
of GSS_BAD_MECH_ATTR.  See below.

Yes, I think it should.


  

    
s 3.5.3 does not mention language/locale/encoding with the short_desc 
and long_desc description output of GSS_Display_mech_attr(). Is that 
deliberate? Could I assume it will sensitive to the 'current' locale, 
and return UTF-8? I notice RFC2743 doesn't address this with the other 
GSS_Display calls, so maybe this is addressed more generally?
    

  

  

RFC2743 does not address this, no.  RFC2744 says "Latin-1."
  





Thanks for the RFC2744/Latin-1 pointer.



Also, should the two tables in the draft correspond to the short and
long descriptions from GSS_Display_mech_attr()? That is to ask was it
your intent that the short and long text of (say)
GSS_C_MA_MECH_CONCRETE in English should be "concrete-mech" and
"Indicates that a mech is neither a pseudo- mechanism nor a composite
mechanism" respectively? I ask this as implementation guidance, but
perhaps the draft might benefit by explicitly recommending such an
approach? (Otherwise the meanings of long and short are floating)



This also leads to the idea of (ab)using GSS_Display_mech_attr() to
search for an attribute OID by its short description. That strikes me
as a pretty attractive thing to do when processing human-entered
configuration files. Sadly, it's precluded because "human-readable"
doesn't mean "matchable to what a human writes" (but it does make me
wonder about human-convenient namespace for OIDs.)





  
...
Note that here GSS_BAD_MECH_ATTR is useful.

Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR.
  





I think keep it BAD, which is consistent with GSS_BAD_MECH and is used
to mean "unrecognized" amongst other things.



Thanks!



David Leonard




--------------050301020303080908000204--


--===============0244529726==
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

--===============0244529726==--




From kitten-bounces@lists.ietf.org Tue Nov 07 17:55:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhZr3-0000bl-9x; Tue, 07 Nov 2006 17:55:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZr1-0000ad-Mu
	for kitten@ietf.org; Tue, 07 Nov 2006 17:55:39 -0500
Received: from nwkea-mail-4.sun.com ([192.18.42.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZr0-0002og-5S
	for kitten@ietf.org; Tue, 07 Nov 2006 17:55:39 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kA7MtbZa009677
	for ; Tue, 7 Nov 2006 14:55:37 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kA7MtaXL013087
	for ; Tue, 7 Nov 2006 15:55:36 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kA7MtZEG028221; Tue, 7 Nov 2006 16:55:35 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA7MtZEG028220; 
	Tue, 7 Nov 2006 16:55:35 -0600 (CST)
Date: Tue, 7 Nov 2006 16:55:35 -0600
From: Nicolas Williams 
To: David Leonard 
Message-ID: <20061107225534.GI25646@binky.Central.Sun.COM>
Mail-Followup-To: David Leonard , kitten@ietf.org
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45510098.6050601@quest.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: kitten@ietf.org
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Wed, Nov 08, 2006 at 07:54:32AM +1000, David Leonard wrote:
> Nicolas Williams wrote:
> >>In s3.5.1 I do not understand how GSS_BAD_MECH_ATTR could ever be 
> >>returned. I think it should be expected that a future caller could be 
> >>searching for an attribute OID that the implementation doesn't know about.
> >>    
> >
> >GSS_Indicate_mechs_by_attr() could just return an empty OID set instead
> >of GSS_BAD_MECH_ATTR.  See below.
> >  
> 
> Yes, I think it should.

OK, I think that's reasonable.

> >>s 3.5.3 does not mention language/locale/encoding with the short_desc 
> >>and long_desc description output of GSS_Display_mech_attr(). Is that 
> >>deliberate? Could I assume it will sensitive to the 'current' locale, 
> >>and return UTF-8? I notice RFC2743 doesn't address this with the other 
> >>GSS_Display calls, so maybe this is addressed more generally?
> >>    
> >
> >RFC2743 does not address this, no.  RFC2744 says "Latin-1."
> >  
> 
> Thanks for the RFC2744/Latin-1 pointer.

Wait for the slides for today's meeting to be posted :)

> Also, should the two tables in the draft correspond to the short and 
> long descriptions from GSS_Display_mech_attr()? That is to ask was it 
> your intent that the short and long text of (say) GSS_C_MA_MECH_CONCRETE 
> in English should be "concrete-mech" and "Indicates that a mech is 
> neither a pseudo- mechanism nor a composite mechanism" respectively? I 
> ask this as implementation guidance, but perhaps the draft might benefit 
> by explicitly recommending such an approach? (Otherwise the meanings of 
> long and short are floating)

Implementors would be free to use whatever shodt/long desc they wish,
provided that the semantics they express agree with those described in
the document.  The semantics of these attributes though are fixed or can
be extended only in ways that are backwards compatible if we ever need
to.

> This also leads to the idea of (ab)using GSS_Display_mech_attr() to 
> search for an attribute OID by its short description. That strikes me as 
> a pretty attractive thing to do when processing human-entered 
> configuration files. Sadly, it's precluded because "human-readable" 
> doesn't mean "matchable to what a human writes" (but it does make me 
> wonder about human-convenient namespace for OIDs.)

Oh yes, the short description is useful precisely for that.  I suppose
that means that the short-desc should not be translated in message
catalogs.

> >...
> >Note that here GSS_BAD_MECH_ATTR is useful.
> >
> >Perhaps we should rename GSS_BAD_MECH_ATTR to GSS_UNKNOWN_MECH_ATTR.
> >  
> 
> I think keep it BAD, which is consistent with GSS_BAD_MECH and is used 
> to mean "unrecognized" amongst other things.

OK.

Thanks,

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 07 21:56:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhdcE-0003OE-4y; Tue, 07 Nov 2006 21:56:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdcD-0003O3-13
	for kitten@ietf.org; Tue, 07 Nov 2006 21:56:37 -0500
Received: from biscayne-one-station.mit.edu ([18.7.7.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdcB-0000QM-MZ
	for kitten@ietf.org; Tue, 07 Nov 2006 21:56:37 -0500
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	kA82uSAb029380; Tue, 7 Nov 2006 21:56:29 -0500 (EST)
Received: from [130.129.71.82] (dhcp71-82.ietf67.org [130.129.71.82])
	(authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kA82uQeP019343
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
	Tue, 7 Nov 2006 21:56:28 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
From: Ken Raeburn 
Date: Tue, 7 Nov 2006 18:56:22 -0800
To: kitten@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Scanned-By: MIMEDefang 2.42
X-Spam-Score: -5.599
X-Spam-Flag: NO
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
Subject: comments on java bindings update, draft-ietf-kitten-rfc2853bis-02
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Jeff was complaining because not enough people had reviewed the java  
bindings, so I took a look.  Not that I'm any great expert on Java,  
but I do okay with English and sometimes even with GSSAPI...

The abstract says in part:

      This document
    updates the Java bindings for the GSS-API that are specified in
    "Generic Security Service API version 2 : Java Bindings" (RFC2853).
    This document obsoletes RFC2853 by making specific and incremental
    clarifications and corrections to it in response to  
identification of
    transcription errors and implementation experience.  The note-worthy
    changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853,
    which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and  
7.8.1 of
    this document, where numerical constants were either added or
    modified.

But aside from this, I didn't see a detailed description of just  
what's changed from the previous version.  (I didn't go back and  
check the email archives though.)  A non-normative section listing  
the changes from RFC 2853 would've been helpful.

So I poked at the two versions with Emacs a bit, stripping out page  
headers and footers and line breaks and comparing what was left.  I  
think my list covers everything changed, and I've got comments on  
some of the changes:

* minor grammatical fixes, basic text changes in the intro relating  
to this being an update

* changes to various number assignments, new status codes added

* description of some error codes as returned only during context  
establishment is duplicated in initial list of status codes, not just  
buried toward the back of the document

* reordered entries in some tables

* added labels "Figure 3" through "Figure 9" to various tables,  
though the labels aren't always on the same page as the table being  
labeled (e.g., "Figure 3" at the top of page 32, describing the table  
that's on page 31); where are Figures 1 and 2?  Can the labels just  
go away?

* java syntax tweaks (array parameters, missing return types)

* specify values for INITIATE_AND_ACCEPT and friends in a bunch of  
places (isn't one enough?), where they weren't specified at all in  
rfc2853

* status code values being specified in a couple of places now  
(5.12.1, 7.8.1); I didn't check for consistency

* change NT_HOSTBASED_SERVICE OID value from the deprecated value to  
the current one (as described in the C bindings in RFC 2744); the new  
version has a typo ("Unites States", which is also present in RFC 2744)

* change text describing lifetime constants from "must be set to..."  
to "value of constant is..."

* clarify GSSCredential.getUsage() to say it return the flag "as a  
union over all mechanisms".  I assume this means the union of all  
functionality in each of the mechanisms, so initiate-only for one and  
accept-only for another means you get INITIATE_AND_ACCEPT back?

* added some missing references

* flattened some sections, like:
- old: 6.4.3 initSecContext, 6.4.3.1 example code for 6.4.3, 6.4.4  
initSecContext, 6.4.4.1 example code for 6.4.4, 6.4.5  
acceptSecContext, 6.4.5.1 example code for 6.4.5, ...
- new: 7.4.3 initSecContext, 7.4.4 example code for 7.4.3, 7.4.5  
initSecContext, 7.4.6 example code for 7.4.5, 7.4.7 acceptSecContext,  
7.4.8 example code for 7.4.7

I think I like the old structure better, personally.  Some of the  
bits of example code are small enough that I think you could just  
merge them into the preceding sections.  It's a pretty minor point,  
though.

* removed duplicated parameter names in descriptions in getMIC  
description in (old) 6.4.15

* added required IANA Considerations section, even though there are  
no such considerations

* corrected name of References section

* updated IPR & Copyright, new authors' addresses

* inserted the usual "conventions used in this document" section,  
before the introduction (resulting in a renumbering of sections  
through the whole document), even though the key words described  
there are not actually used in the document; I haven't checked the  
rules, but I would hope we can omit it in that case

RFC 2744 inconsistencies notwithstanding, I think this spec should  
use consistent style for specifying OID values.  Is it "iso(1)" or "1 
(iso)"?

So, I've mentioned above things that were changed and some minor  
issues I spotted looking at the changes.  I haven't actually *read  
through* the new version in all its 105-page glory, so far.  But most  
of the changes seem strictly mechanical (section renumbering) or  
localized, so I think it's safe to say the new version is at least as  
good as the old one, with a few minor issues noted above.

Ken

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 08 10:29:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhpMF-00052e-WE; Wed, 08 Nov 2006 10:28:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpME-00052Z-Pq
	for kitten@ietf.org; Wed, 08 Nov 2006 10:28:54 -0500
Received: from brmea-mail-2.sun.com ([192.18.98.43])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpMB-0004JV-EJ
	for kitten@ietf.org; Wed, 08 Nov 2006 10:28:54 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kA8FSo7V018631
	for ; Wed, 8 Nov 2006 08:28:50 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kA8FSovk028928
	for ; Wed, 8 Nov 2006 08:28:50 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kA8FSoXL028661
	for ; Wed, 8 Nov 2006 09:28:50 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA8FSk17028660
	for kitten@ietf.org; Wed, 8 Nov 2006 09:28:46 -0600 (CST)
Date: Wed, 8 Nov 2006 09:28:46 -0600
From: Nicolas Williams 
To: kitten@ietf.org
Message-ID: <20061108152845.GP25646@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
Subject: Toughts on IAKERB and stackable pseudo-mechs
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

The chief problem to resolve in making a mechanism like IAKERB stackable
is this: how to communicate the raw credentials it acquires to the
mechanism stacked below.

The obvious answer is to use a GSS-API CREDENTIAL HANDLE, but the
question is how to get one given only a Kerberos V Ticket and session
key.

And the answer to that is that a number of implementors have been
pursuing mechanism-specific extensions like gss_krb5_acquire_cred_with_X().

These extensions still go through multi-mechglue, in some way.

I have a workspace with a gss_krb5_acquire_cred_with_ccache() that will
soon enough go into OpenSolaris, for example, and we already have
extensions like gss_acquire_cred_with_password().  I believe MIT and
Heimdal have similar sorts of extensions.

So, as long as such extensions extensions are provided by the
multi-mechglue and the concrete mechanisms then IAKERB can be a
stackable mechanism.

Note too that specifying IAKERB as a stackable mechanism does not force
anyone to implement it that way -- you can still implement it
monolythically, as one might implement the mechanism Larry presented.
Conversely, one might implement the mechanism presented by Larry
non-monolythically much as one might implement a stackable mechanism
non-monolythically.

Something much more generic than IAKERB, like the IP-tunneling
pseudo-mechanism that Sam posited at the meeting yesterday, cannot be
implementated in this way, as there just is no way for such a mechanism
to transparently tunnel traffic generated by the mechanism stacked
below.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 08 10:34:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GhpRq-0000HW-Hv; Wed, 08 Nov 2006 10:34:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GhpRp-0000Cx-BU
	for kitten@ietf.org; Wed, 08 Nov 2006 10:34:41 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhpRn-00057j-Vr
	for kitten@ietf.org; Wed, 08 Nov 2006 10:34:41 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kA8FYdc6010367
	for ; Wed, 8 Nov 2006 07:34:39 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kA8FYcpi004808
	for ; Wed, 8 Nov 2006 08:34:38 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kA8FYcQc028670
	for ; Wed, 8 Nov 2006 09:34:38 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA8FYckZ028669
	for kitten@ietf.org; Wed, 8 Nov 2006 09:34:38 -0600 (CST)
Date: Wed, 8 Nov 2006 09:34:38 -0600
From: Nicolas Williams 
To: kitten@ietf.org
Message-ID: <20061108153437.GQ25646@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: 9182cfff02fae4f1b6e9349e01d62f32
Cc: 
Subject: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Sam asked how to avoid having two semantically equivalent composite
mechanisms that differ in stacking order.  This was in the context of
IAKERB as a stackable pseudo-mechanism.  Sam pointed out that CCM and
IAKERB could be stacked together in either order on the Kerberos V
mechanism and the semantics of the resulting two composite mechanisms
should be the same.

I just posted a note about close coupling between IAKERB and the
Kerberos V mechanism -- that to implement IAKERB non-monolythically one
would need a krb5 mechanism-specific GSS extension.  This does not mean
that IAKERB must be stacked directly above the krb5 mech as the CCM mech
might provide such an extension too as a simple pass-through, but it
does suggest that this close coupling should lead to composition rules
for IAKERB like:

 - IAKERB MUST be stacked only above a concrete mechanism
 - IAKERB MUST be stacked only above a mechanisms that has the
   GSS_C_MA_ACQ_CRED_W_KRB5_TIX attribute[*]

[*] which I just made up and which would mean that the mech provides a
    gss_acquire_cred_with_krb5_tickets() extension or some such.


Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 08 11:04:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ghpui-00056M-LS; Wed, 08 Nov 2006 11:04:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghpuh-00054m-4c
	for kitten@ietf.org; Wed, 08 Nov 2006 11:04:31 -0500
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghpld-0007ZO-G5
	for kitten@ietf.org; Wed, 08 Nov 2006 10:55:11 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kA8Ft8Ww011732
	for ; Wed, 8 Nov 2006 08:55:08 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kA8Ft8AI023406
	for ; Wed, 8 Nov 2006 08:55:08 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kA8Ft88K028688
	for ; Wed, 8 Nov 2006 09:55:08 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kA8Ft8j9028687
	for kitten@ietf.org; Wed, 8 Nov 2006 09:55:08 -0600 (CST)
Date: Wed, 8 Nov 2006 09:55:08 -0600
From: Nicolas Williams 
To: kitten@ietf.org
Message-ID: <20061108155507.GE26436@binky.Central.Sun.COM>
Mail-Followup-To: kitten@ietf.org
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20061108153437.GQ25646@binky.Central.Sun.COM>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: 
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Wed, Nov 08, 2006 at 09:34:37AM -0600, Nicolas Williams wrote:
>  - IAKERB MUST be stacked only above a concrete mechanism
>  - IAKERB MUST be stacked only above a mechanisms that has the
>    GSS_C_MA_ACQ_CRED_W_KRB5_TIX attribute[*]

The result should be that while both IAKERB and CCM will gladly stack
above krb5, and CCM will gladly stack above IAKERB-krb5, IAKERB will not
stack above CCM-krb5.

It may not always be possible to purposefully construct composition
rules in order to prevent multiple equivalent compositions.  But in
practice the number of stackable pseudo-mechanisms will be small; we've
posited a small number of them:

 - CCM
 - compression
 - bound concurrent authentication of multiple client principals
 - IAKERB

 - GSS-TLS w/ krb5 per-msg tokens could easily be constructed as a
   stackable pseudo-mechanism if there was a krb5-specific GSS extension
   for creating fully established security contexts out of key material
   (and NAME objects, which in the case of GSS-TLS would be
   GSS_C_NO_NAME -- the app would see the NAME objects from GSS-TLS,
   which would correspond to the asserted PKIX cert names).

I can probably think of afew more.

We can construct composition rules so that CCM never stacks above
compression, multi-auth mechs never stack above CCM, IAKERB never stacks
above CCM and GSS-TLS never stacks above CCM.

It requires having mechanism attributes that reflect what the mechanisms
do (e.g., compression transforms wrap token data, and CCM would lose
such transformations as it doesn't use the underlying mech's per-msg
tokens for its own per-msg tokens when the channel is bound, therefore
CCM does not want to stack above compression) and careful consideration
of each stackable pseudo-mechanism's composition rules.

If the rules we construct today leave us with a handful of equivalent
composite mechs that differ only in stacking order a few years down the
line when new stackable mechs come along, well, that wouldn't be so bad,
and can be dealt with in any of a number of ways, including, if we think
it safe, ignoring the problem.

There might be an argument here for having a formal language for
composition rules, so that rules can be added through configuration when
we discover that new rules are needed.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 04:34:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gi6I1-00052D-HA; Thu, 09 Nov 2006 04:33:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi6I1-000528-4W
	for kitten@ietf.org; Thu, 09 Nov 2006 04:33:41 -0500
Received: from smtp.microsoft.com ([131.107.115.212])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi6Ht-00086Z-Nc
	for kitten@ietf.org; Thu, 09 Nov 2006 04:33:41 -0500
Received: from mailout5.microsoft.com (157.54.69.148) by
	TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with
	Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 01:33:32 -0800
Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.154]) by
	mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 9 Nov
	2006 01:33:25 -0800
Received: from tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) by
	IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 01:33:24 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com
	(157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com
	(157.54.70.186)
	with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 01:33:23 -0800
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com
	([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com
	with
	Microsoft SMTPSVC(6.0.3790.2786);	 Thu, 9 Nov 2006 01:33:23 -0800
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, 9 Nov 2006 01:33:06 -0800
Message-ID: 
In-Reply-To: <20061108155507.GE26436@binky.Central.Sun.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Stacking order
Thread-Index: AccDT6/lA1oQEIYDTHGGIbywbbw1bQAkU22g
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@binky.Central.Sun.COM>
From: "Liqiang(Larry) Zhu" 
To: Nicolas Williams , 
X-OriginalArrivalTime: 09 Nov 2006 09:33:23.0740 (UTC)
	FILETIME=[1A055DC0:01C703E2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: 
Subject: RE: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

The use of WS-KRB-HEADER header clearly means that IAKERB is not generic
enough. It can only be stacked over variants of Kerberos protocols: U2U
or RFC4120 Kerberos.

I suspect it might be a bit over engineering to specify IAKERB as a
stackable mechanism. The complexity does not justify the benefits at
this point.

-- larry


-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20
Sent: Wednesday, November 08, 2006 7:55 AM
To: kitten@ietf.org
Subject: Re: Stacking order

On Wed, Nov 08, 2006 at 09:34:37AM -0600, Nicolas Williams wrote:
>  - IAKERB MUST be stacked only above a concrete mechanism
>  - IAKERB MUST be stacked only above a mechanisms that has the
>    GSS_C_MA_ACQ_CRED_W_KRB5_TIX attribute[*]

The result should be that while both IAKERB and CCM will gladly stack
above krb5, and CCM will gladly stack above IAKERB-krb5, IAKERB will not
stack above CCM-krb5.

It may not always be possible to purposefully construct composition
rules in order to prevent multiple equivalent compositions.  But in
practice the number of stackable pseudo-mechanisms will be small; we've
posited a small number of them:

 - CCM
 - compression
 - bound concurrent authentication of multiple client principals
 - IAKERB

 - GSS-TLS w/ krb5 per-msg tokens could easily be constructed as a
   stackable pseudo-mechanism if there was a krb5-specific GSS extension
   for creating fully established security contexts out of key material
   (and NAME objects, which in the case of GSS-TLS would be
   GSS_C_NO_NAME -- the app would see the NAME objects from GSS-TLS,
   which would correspond to the asserted PKIX cert names).

I can probably think of afew more.

We can construct composition rules so that CCM never stacks above
compression, multi-auth mechs never stack above CCM, IAKERB never stacks
above CCM and GSS-TLS never stacks above CCM.

It requires having mechanism attributes that reflect what the mechanisms
do (e.g., compression transforms wrap token data, and CCM would lose
such transformations as it doesn't use the underlying mech's per-msg
tokens for its own per-msg tokens when the channel is bound, therefore
CCM does not want to stack above compression) and careful consideration
of each stackable pseudo-mechanism's composition rules.

If the rules we construct today leave us with a handful of equivalent
composite mechs that differ only in stacking order a few years down the
line when new stackable mechs come along, well, that wouldn't be so bad,
and can be dealt with in any of a number of ways, including, if we think
it safe, ignoring the problem.

There might be an argument here for having a formal language for
composition rules, so that rules can be added through configuration when
we discover that new rules are needed.

Nico
--=20

_______________________________________________
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@lists.ietf.org Thu Nov 09 13:07:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiEIp-0003iv-Io; Thu, 09 Nov 2006 13:07:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEIo-0003id-QR
	for kitten@ietf.org; Thu, 09 Nov 2006 13:07:02 -0500
Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEIn-0007sO-Fi
	for kitten@ietf.org; Thu, 09 Nov 2006 13:07:02 -0500
Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com
	[68.175.91.105])
	by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id
	kA9I6wkq007947
	for ; Thu, 9 Nov 2006 13:06:58 -0500 (EST)
Received: from [130.129.67.91] by secure-endpoints.com
	(Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3)
	with ESMTP id md50000034397.msg
	for ; Thu, 09 Nov 2006 13:10:35 -0500
Message-ID: <45536F12.9030600@secure-endpoints.com>
Date: Thu, 09 Nov 2006 10:10:26 -0800
From: Jeffrey Altman 
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Kitten , saag@mit.edu,
	Sam Hartman , housley@vigilsec.com
X-Enigmail-Version: 0.94.0.0
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Thu, 09 Nov 2006 13:10:35 -0500
	(not processed: message from valid local sender)
X-MDRemoteIP: 130.129.67.91
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Cc: 
Subject: IETF67 Summary of Kitten WG Meeting
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.com
List-Id: Common Authentication Technologies - Next Generation
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0150108370=="
Errors-To: kitten-bounces@lists.ietf.org

This is a cryptographically signed message in MIME format.

--===============0150108370==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms080302010900070003090704"

This is a cryptographically signed message in MIME format.

--------------ms080302010900070003090704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

The Kitten working group met at IETF67 on Tuesday afternoon session II.

The presentation materials are available at:

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67#wg-kitten

The Audio Stream is available at

http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-tue-noon.mp3

The Jabber Logs are available at:

http://www3.ietf.org/meetings/ietf-logs/kitten/2006-11-07.html

===================================================================================

Document Status
---------------

Desired Enhancements to GSSAPI Version 3 Naming
 - draft-ietf-kitten-gss-naming-04.txt
 - IESG approved; Waiting for RFC publication

GSS-API Domain-Based Service Names
 - draft-ietf-kitten-gssapi-domain-based-names-04.txt
 - IETF Last Call complete

GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism
 - draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt
 - IETF Last Call complete

GSS-APIv2 Extension for Storing Delegated Credentials
 - draft-williams-gssapi-store-deleg-creds
 - Ready for Working Group Last Call

Extended Generic Security Service Mechanism Inquiry APIs
 - draft-ietf-kitten-extended-mech-inquiry-02.txt
 - In Working Group Last Call - Please review

Stackable Generic Security Service Pseudo-Mechanisms
 - draft-ietf-kitten-gssapi-stackable-pseudo-mechs-02.txt
 - In Working Group Last Call - Please review

Generic Security Service API Version 2 : Java Bindings Update
 - draft-ietf-kitten-rfc2853bis-01.txt
 - In Working Group Last Call - Please review

=========================================================================

Proposed Charter Revision
-------------------------

Charter and Milestone Revisions being reviewed by the IESG.
Charter removes work item for defining channels for use in channel
bindings.  Charter adds permission to address internationalization issues.

=========================================================================

Technical Discussion
--------------------

* The WG reviewed the outstanding AD comments on "GSS-API Domain-Based
  Service Names".  The working group will confirm consensus of decisions
  on the mailing list.

* WGLC: An Update to the Java GSS-API specification - Reviewers Needed

      Shan Emery and will Leif Johansson will review document.
      Need to Java language experts reviewers.

      2 weeks to the review to complete

* WGLC: Stackable mechs / Extended mech inquiry APIs.

    3 people sending comments in the last few days
    More reviewers needed

    Jeffery Hutzelman and Ken R will review document

* Internationalization Consensus

    GSS-API v2u1 specifies "ISO Latin-1" in existing gss_display_name
    and gss_display_status functions.

    WG consensus is that new functions providing "Unicode" and "Locale"
    specific output will be specified in future extensions.

* Presentation: Leif Johansson on HTTP GSSAPI Negotiate replacement
   	
  http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
  http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

  Please review.

* Presentation: Larry Zhu on Kerberos for Web Services

 - needs new name
 - permits client/kdc traffic through a GSS-API proxy
 - must be extended to handle change password protocol

* Presentation: Larry Zhu on PKU2U

 - peer to peer kerberos.  no need for a KDC
 - transmits Kerberos PDUs inside GSS-API tokens


* Implementation Experience

  A concern was raised regarding the lack of running code for the
  GSS-API extensions in WGLC.

Jeffrey Altman
Kitten Chair


--------------ms080302010900070003090704
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX
DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o
fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U
8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0
ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD
A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo
pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v
L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0
0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL
zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4
TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV
GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07
E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX
lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB
gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax
myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc
6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDkxODEwMjZaMCMGCSqGSIb3DQEJBDEWBBTf+GOc
lxhUJyErl1WcnjdXQJy0pjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ
KoZIhvcNAQEBBQAEggEAHSSGanCliiP3x3zjLJmTTEibyt+QOCMSiAxuPB5m0g0cBp4Qivnu
IzM4ZACwjYUciA6huCPzUPQ1uzPE+FU4QS0HI79coOAmtV06CsYYhcXjYlUf4x18qeMnIrw5
+MPAXKRAEe43Kz97k0nKPbAyfPYZL02j34Xx6xHmTmkESecmadrv7LJYIVCxRYoMTeVIYFWY
A0qxlh8N+RlLsEuoPWo0hbBtilBRCPLstykiWBpUxaoMQEHXUn/TDS3Ulz6W03CTsoKXb3X6
+4SWL0dbjKRwrDV7n2ZcH2/yw8SbCgC+C9CNuvsi7ZfL79kR6ZqggGxK9ocvOOH6QfY7c+V9
XQAAAAAAAA==
--------------ms080302010900070003090704--



--===============0150108370==
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

--===============0150108370==--





From kitten-bounces@lists.ietf.org Thu Nov 09 14:27:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiFYc-00036Q-Jv; Thu, 09 Nov 2006 14:27:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFYb-00033N-Ge
	for kitten@ietf.org; Thu, 09 Nov 2006 14:27:25 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiFVM-0001Vi-95
	for kitten@ietf.org; Thu, 09 Nov 2006 14:24:06 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 46A793BE71;
	Thu,  9 Nov 2006 20:23:49 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 28139-01-7; Thu,  9 Nov 2006 20:23:49 +0100 (CET)
Received: from [130.129.67.52] (dhcp67-52.ietf67.org [130.129.67.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 1354B3BE40;
	Thu,  9 Nov 2006 20:23:47 +0100 (CET)
Message-ID: <45538042.5020301@it.su.se>
Date: Thu, 09 Nov 2006 20:23:46 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Kitten 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.373 tagged_above=-99 required=7 tests=[AWL=0.292,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Lisa Dusseault 
Subject: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org


At the informal bar-bof yesterday in San Diego it was decided that I should
send my drafts describing a new http gss authentication mechanism to
this list.

Note that these drafts are not intended for inclusion in the kitten
charter at
this or any future time. They are only presented to this list for review
by gss
experts.

By way of background this draft (and the related draft describing channel
bindings for http+tls) describes a successor (but not update) to  the 
negotiate
http auth mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal motivation for this work was requirements from the calcify
wg who
expressed the need for a better authentication mechanism (than plain
passwords)
for applications using http as a transport but not using a browser as a
client.

Please note that this is a 00 version and new versions with
modifications based
on discussions from yesterday are forthcoming.

http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

       Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 15:22:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiGPL-0007LF-Qx; Thu, 09 Nov 2006 15:21:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGPK-0007L2-Tr
	for kitten@ietf.org; Thu, 09 Nov 2006 15:21:54 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGPI-0002TO-Jd
	for kitten@ietf.org; Thu, 09 Nov 2006 15:21:54 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id 5C21442B61;
	Thu,  9 Nov 2006 15:21:44 -0500 (EST)
Date: Thu, 9 Nov 2006 15:21:42 -0500
From: Michael B Allen 
To: Leif Johansson 
Message-Id: <20061109152142.479582b0.mba2000@ioplex.com>
In-Reply-To: <45538042.5020301@it.su.se>
References: <45538042.5020301@it.su.se>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

I don't speak for kitten and I'm not familiar with the TLS channel binding
thing but the only flaw in the Negotiate method that really that really
jumps out is the conflict between stateful GSSAPI and stateless HTTP. How
does your method address this issue?

For example consider a client that pipelines 10 requests. The server
response to the first and the client submits another token. How will
you distinguish secondary or teriary tokens from one another?

What happends if the 5th request in a pipeline fails GSS?

What happends if the 5th request in a pipeline sends connection: close?

These are the sort of things that cause problems with mechanisms that
require more than one exchange (e.g. I suspect this is a source of
mysterious NTLM failures reported occasionally).

Mike

On Thu, 09 Nov 2006 20:23:46 +0100
Leif Johansson  wrote:

> http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 16:21:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiHKN-00007k-9e; Thu, 09 Nov 2006 16:20:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHKL-00007X-Vl
	for kitten@ietf.org; Thu, 09 Nov 2006 16:20:49 -0500
Received: from smtp1.su.se ([130.237.162.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHKJ-00057R-LT
	for kitten@ietf.org; Thu, 09 Nov 2006 16:20:49 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp1.su.se (Postfix) with ESMTP id C621674099;
	Thu,  9 Nov 2006 22:20:32 +0100 (CET)
Received: from smtp1.su.se ([127.0.0.1])
	by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 19810-01-23; Thu,  9 Nov 2006 22:20:32 +0100 (CET)
Received: from [130.129.67.52] (dhcp67-52.ietf67.org [130.129.67.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp1.su.se (Postfix) with ESMTP id 4654E7404D;
	Thu,  9 Nov 2006 22:20:27 +0100 (CET)
Message-ID: <45539B99.5050408@it.su.se>
Date: Thu, 09 Nov 2006 22:20:25 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Michael B Allen 
References: <45538042.5020301@it.su.se>
	<20061109152142.479582b0.mba2000@ioplex.com>
In-Reply-To: <20061109152142.479582b0.mba2000@ioplex.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.103 tagged_above=-99 required=7 tests=[AWL=0.562,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> I don't speak for kitten and I'm not familiar with the TLS channel binding
> thing but the only flaw in the Negotiate method that really that really
> jumps out is the conflict between stateful GSSAPI and stateless HTTP. How
> does your method address this issue?
>
>   
If I understand your question correctly the gss draft aims to solve this
problem by having the
server send state back to the client (state which is also used to do
fast reauth) with the challenge.
There are several ways to implement this, including short-cuts if you
use kerberos and proposed
extensions to allow exporting unfinished contexts from gssapi.

    Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 16:59:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiHva-0007cQ-EJ; Thu, 09 Nov 2006 16:59:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHvZ-0007bt-OE
	for kitten@ietf.org; Thu, 09 Nov 2006 16:59:17 -0500
Received: from nwk-ea-fw-1.sun.com ([192.18.42.249])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHvU-0002LQ-0R
	for kitten@ietf.org; Thu, 09 Nov 2006 16:59:17 -0500
Received: from d1-sfbay-10.sun.com ([192.18.39.120])
	by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA9Lx6hE003842
	for ; Thu, 9 Nov 2006 13:59:06 -0800 (PST)
Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com
	(Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
	id <0J8H00101GXX2S00@d1-sfbay-10.sun.com>
	(original mail from Seema.Malkani@Sun.COM) for kitten@ietf.org; Thu,
	09 Nov 2006 13:59:06 -0800 (PST)
Received: from [129.145.128.115] by d1-sfbay-10.sun.com
	(Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
	with ESMTPSA id <0J8H000J3H2G7RPD@d1-sfbay-10.sun.com>; Thu,
	09 Nov 2006 13:59:06 -0800 (PST)
Date: Thu, 09 Nov 2006 13:58:58 -0800
From: Seema Malkani 
In-reply-to: 
To: Ken Raeburn 
Message-id: <4553A4A2.3060809@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-15
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
References: 
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041221
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Cc: kitten@ietf.org
Subject: Re: comments on java bindings update,
	draft-ietf-kitten-rfc2853bis-02
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Seema.Malkani@Sun.COM
List-Id: Common Authentication Technologies - Next Generation
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Thanks for the review, Ken.

Ken Raeburn wrote On 11/07/06 18:56,:

> Jeff was complaining because not enough people had reviewed the java  
> bindings, so I took a look.  Not that I'm any great expert on Java,  
> but I do okay with English and sometimes even with GSSAPI...
>
> The abstract says in part:
>
>       This document
>     updates the Java bindings for the GSS-API that are specified in
>     "Generic Security Service API version 2 : Java Bindings" (RFC2853).
>     This document obsoletes RFC2853 by making specific and incremental
>     clarifications and corrections to it in response to  
> identification of
>     transcription errors and implementation experience.  The note-worthy
>     changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853,
>     which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and  
> 7.8.1 of
>     this document, where numerical constants were either added or
>     modified.
>
> But aside from this, I didn't see a detailed description of just  
> what's changed from the previous version.  (I didn't go back and  
> check the email archives though.)  A non-normative section listing  
> the changes from RFC 2853 would've been helpful.

The Abstract has a summary of changes, listing the specific section 
updates. Would a list of changes in an Appendix section at the end of 
the draft be helpful ?

>
> So I poked at the two versions with Emacs a bit, stripping out page  
> headers and footers and line breaks and comparing what was left.  I  
> think my list covers everything changed, and I've got comments on  
> some of the changes:
>
> * minor grammatical fixes, basic text changes in the intro relating  
> to this being an update
>
> * changes to various number assignments, new status codes added

The GSS status code update is the one of the significant update to RFC 
2853. The GSS error code values use for GSS exceptions were incorrect in 
the original RFC 2853.

>
> * description of some error codes as returned only during context  
> establishment is duplicated in initial list of status codes, not just  
> buried toward the back of the document

RFC 2853 defined the GSS error codes in section 4.12.1. The Static 
constants defined in Java class are listed in section 6.8.1

RFC 2853 update now defines the GSS error codes in section 5.12.1, and 
static constants in section 7.8.1

>
> * reordered entries in some tables

GSS error code values have been updated, that resulted in the 
re-ordering to be sequential.

>
> * added labels "Figure 3" through "Figure 9" to various tables,  
> though the labels aren't always on the same page as the table being  
> labeled (e.g., "Figure 3" at the top of page 32, describing the table  
> that's on page 31); where are Figures 1 and 2?  Can the labels just  
> go away?

RFC 2853 was written in text format, hence labeling was easier to add. 
And now RFC 2853 Update has been written in XML format, the labeling 
comes from the standard xml tags.

>
> * java syntax tweaks (array parameters, missing return types)
>
> * specify values for INITIATE_AND_ACCEPT and friends in a bunch of  
> places (isn't one enough?), where they weren't specified at all in  
> rfc2853

RFC 2853 defined the Credential usage Static constants in section 6.3.2, 
but missed defining the usage values.

This draft defines the Credential usage values in section 7.3.2

>
> * status code values being specified in a couple of places now  
> (5.12.1, 7.8.1); I didn't check for consistency

GSS status code values in RFC 2853 were not consistent. The draft now 
defines in GSS error code values that are consistent.

>
> * change NT_HOSTBASED_SERVICE OID value from the deprecated value to  
> the current one (as described in the C bindings in RFC 2744); the new  
> version has a typo ("Unites States", which is also present in RFC 2744)

This needs to be fixed, I'll make the update.

{ iso(1) member-body(2) United States(840) mit(113554) infosys(1) 
gssapi(2) generic(1) service_name(4) }

>
> * change text describing lifetime constants from "must be set to..."  
> to "value of constant is..."

This update defines the recommended value.

>
> * clarify GSSCredential.getUsage() to say it return the flag "as a  
> union over all mechanisms".  I assume this means the union of all  
> functionality in each of the mechanisms, so initiate-only for one and  
> accept-only for another means you get INITIATE_AND_ACCEPT back?

This needs to be fixed, it should be:

Returns the credential usage flag.  The return value will be one of
GSSCredential.INITIATE_ONLY, GSSCredential.ACCEPT_ONLY, or
GSSCredential.INITIATE_AND_ACCEPT.

I'll make the update.

>
> * added some missing references
>
> * flattened some sections, like:
> - old: 6.4.3 initSecContext, 6.4.3.1 example code for 6.4.3, 6.4.4  
> initSecContext, 6.4.4.1 example code for 6.4.4, 6.4.5  
> acceptSecContext, 6.4.5.1 example code for 6.4.5, ...
> - new: 7.4.3 initSecContext, 7.4.4 example code for 7.4.3, 7.4.5  
> initSecContext, 7.4.6 example code for 7.4.5, 7.4.7 acceptSecContext,  
> 7.4.8 example code for 7.4.7
>
> I think I like the old structure better, personally.  Some of the  
> bits of example code are small enough that I think you could just  
> merge them into the preceding sections.  It's a pretty minor point,  
> though.
>
> * removed duplicated parameter names in descriptions in getMIC  
> description in (old) 6.4.15
>
> * added required IANA Considerations section, even though there are  
> no such considerations

This was required, as mentioned by IETF chair Jeffrey Altman.

>
> * corrected name of References section
>
> * updated IPR & Copyright, new authors' addresses
>
> * inserted the usual "conventions used in this document" section,  
> before the introduction (resulting in a renumbering of sections  
> through the whole document), even though the key words described  
> there are not actually used in the document; I haven't checked the  
> rules, but I would hope we can omit it in that case

The keywords defined in the Normative References are used in the draft. 
Can you clarify what keyword are you referring to ?

>
> RFC 2744 inconsistencies notwithstanding, I think this spec should  
> use consistent style for specifying OID values.  Is it "iso(1)" or "1 
> (iso)"?

RFC 4120, RFC 2744, RFC2743 all define iso(1). This draft follows the 
same. Is this not the correct style ?

>
> So, I've mentioned above things that were changed and some minor  
> issues I spotted looking at the changes.  I haven't actually *read  
> through* the new version in all its 105-page glory, so far.  But most  
> of the changes seem strictly mechanical (section renumbering) or  
> localized, so I think it's safe to say the new version is at least as  
> good as the old one, with a few minor issues noted above.
>
> Ken
>
Seema

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 18:09:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiJ1j-0003BO-FN; Thu, 09 Nov 2006 18:09:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ1h-0003Al-O4
	for kitten@ietf.org; Thu, 09 Nov 2006 18:09:41 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJ1f-0002pv-EP
	for kitten@ietf.org; Thu, 09 Nov 2006 18:09:41 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 812CE3BF1B;
	Fri, 10 Nov 2006 00:09:24 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 13829-01-6; Fri, 10 Nov 2006 00:09:24 +0100 (CET)
Received: from [130.129.67.52] (dhcp67-52.ietf67.org [130.129.67.52])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 47D0E3BE87;
	Fri, 10 Nov 2006 00:09:23 +0100 (CET)
Message-ID: <4553B51E.9080006@it.su.se>
Date: Fri, 10 Nov 2006 00:09:18 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Tim Alsop 
References: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.381 tagged_above=-99 required=7 tests=[AWL=0.284,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Tim Alsop wrote:
> Leif,
>
> Have you considered using SASL over HTTP with GSS-API, as described in :
>
> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt 
>
> I was under the impression that the above draft was the preferred method
> to improve on the HTTP negotiate approach.
>
>
>   
I am under the impression that the proposed SASL mechanism doesn't
support channel
bindings, partially because channel bindings have been a notoriously
difficult problem to get
right in SASL space. Personally I din't see the value of adding the
extra layer of glue.

    Cheers Leif


_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 09 18:26:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiJHf-0006Hz-Gs; Thu, 09 Nov 2006 18:26:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJHe-0006Hu-Pv
	for kitten@ietf.org; Thu, 09 Nov 2006 18:26:10 -0500
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJHd-00053l-Dl
	for kitten@ietf.org; Thu, 09 Nov 2006 18:26:10 -0500
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141])
	by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP
	id kA9NPvHv032098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 9 Nov 2006 15:25:57 -0800
X-Auth-Received: from dhcp66-171.ietf67.org (dhcp66-171.ietf67.org
	[130.129.66.171]) (authenticated authid=rlmorgan)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id
	kA9NPuJG006499
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 9 Nov 2006 15:25:56 -0800
Date: Thu, 9 Nov 2006 15:26:00 -0800 (PST)
From: "RL 'Bob' Morgan" 
X-X-Sender: rlmorgan@perf.cac.washington.edu
To: Leif Johansson 
In-Reply-To: <4553B51E.9080006@it.su.se>
Message-ID: 
References: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
	<4553B51E.9080006@it.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.5.0.283055,
	Antispam-Data: 2006.11.9.151433
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: Kitten , Lisa Dusseault ,
	Tim Alsop 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org


More significantly, draft-nystrom-http-sasl-12.txt only works when 
persistent connections are used, which is a showstopper.  Hence the 
text in http-gss:

    session.  Instead opaque identifiers in the GSS challenge option
    field are optionally used together with channel bindings to provide a
    way to share a security context over several HTTP connections.

  - RL "Bob"

> Tim Alsop wrote:
>> Have you considered using SASL over HTTP with GSS-API, as described in :
>>
>> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt
>>
>> I was under the impression that the above draft was the preferred method
>> to improve on the HTTP negotiate approach.
>>
> I am under the impression that the proposed SASL mechanism doesn't 
> support channel bindings, partially because channel bindings have been a 
> notoriously difficult problem to get right in SASL space. Personally I 
> din't see the value of adding the extra layer of glue.
>
>    Cheers Leif
>
>
> _______________________________________________
> 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@lists.ietf.org Fri Nov 10 09:43:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiXbW-0005Pg-P9; Fri, 10 Nov 2006 09:43:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiTYx-0000Md-S9
	for kitten@ietf.org; Fri, 10 Nov 2006 05:24:43 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiIPJ-0006zL-Mq
	for kitten@ietf.org; Thu, 09 Nov 2006 17:30:01 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiIC3-00035Q-Sx
	for kitten@ietf.org; Thu, 09 Nov 2006 17:16:22 -0500
Received: from rly03a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly03a.srv.mailcontrol.com (MailControl) with ESMTP id
	kA9MGC6J010487
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 9 Nov 2006 22:16:13 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[212.158.48.250])
	by rly03a.srv.mailcontrol.com (MailControl) id kA9MG1nA010007
	for kitten@ietf.org; Thu, 9 Nov 2006 22:16:01 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly03a-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kA9MFxjh009940; Thu, 09 Nov 2006 22:16:01 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Thu, 9 Nov 2006 22:16:02 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
In-Reply-To: <45538042.5020301@it.su.se>
From: "Tim Alsop" 
To: "Leif Johansson" , "Kitten" 
X-Scanned-By: MailControl A-07-06-75 (www.mailcontrol.com) on 10.65.1.113
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
X-Mailman-Approved-At: Fri, 10 Nov 2006 09:43:38 -0500
Cc: Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Leif,

Have you considered using SASL over HTTP with GSS-API, as described in :

http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt=20

I was under the impression that the above draft was the preferred method
to improve on the HTTP negotiate approach.

Thanks,
Tim

-----Original Message-----
From: Leif Johansson [mailto:leifj@it.su.se]=20
Sent: 09 November 2006 19:24
To: Kitten
Cc: Lisa Dusseault
Subject: Please review: http gss authentication mech


At the informal bar-bof yesterday in San Diego it was decided that I
should
send my drafts describing a new http gss authentication mechanism to
this list.

Note that these drafts are not intended for inclusion in the kitten
charter at
this or any future time. They are only presented to this list for review
by gss
experts.

By way of background this draft (and the related draft describing
channel
bindings for http+tls) describes a successor (but not update) to  the=20
negotiate
http auth mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal motivation for this work was requirements from the calcify
wg who
expressed the need for a better authentication mechanism (than plain
passwords)
for applications using http as a transport but not using a browser as a
client.

Please note that this is a 00 version and new versions with
modifications based
on discussions from yesterday are forthcoming.

http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt

       Cheers Leif

_______________________________________________
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@lists.ietf.org Fri Nov 10 11:21:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiZ7U-0003oh-EZ; Fri, 10 Nov 2006 11:20:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZ7S-0003oG-CM
	for kitten@ietf.org; Fri, 10 Nov 2006 11:20:42 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZ7Q-00026x-WD
	for kitten@ietf.org; Fri, 10 Nov 2006 11:20:42 -0500
Received: from rly03a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly03a.srv.mailcontrol.com (MailControl) with ESMTP id
	kAAGKTVu017272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 10 Nov 2006 16:20:30 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[212.158.48.250])
	by rly03a.srv.mailcontrol.com (MailControl) id kAAGJimJ015317
	for kitten@ietf.org; Fri, 10 Nov 2006 16:19:44 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly03a-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kAAGJc5C013635; Fri, 10 Nov 2006 16:19:44 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Fri, 10 Nov 2006 16:19:42 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299547@postman-pat.csafe.local>
In-Reply-To: <4553B51E.9080006@it.su.se>
From: "Tim Alsop" 
To: "Leif Johansson" 
X-Scanned-By: MailControl A-07-06-75 (www.mailcontrol.com) on 10.65.1.113
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Kitten , Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Leif,

Regarding :

> I am under the impression that the proposed SASL mechanism doesn't
support channel
> bindings, partially because channel bindings have been a notoriously
difficult problem to get
> right in SASL space. Personally I din't see the value of adding the
extra layer of glue.

My understanding is that, if SASL is using GSS/Kerberos to protect HTTP
communications, then GSS channel bindings can be used, so SASL does not
need to have direct support for channel bindings. This is an advantage
of using a multi-layered architecture.

Cheers,
Tim

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 10 11:24:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiZAs-0004oO-H6; Fri, 10 Nov 2006 11:24:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZAr-0004o3-2t
	for kitten@ietf.org; Fri, 10 Nov 2006 11:24:13 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZAp-0002eK-Ho
	for kitten@ietf.org; Fri, 10 Nov 2006 11:24:13 -0500
Received: from rly05a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly05a.srv.mailcontrol.com (MailControl) with ESMTP id
	kAAGO70e021065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 10 Nov 2006 16:24:07 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[212.158.48.250])
	by rly05a.srv.mailcontrol.com (MailControl) id kAAGNPTk019332
	for kitten@ietf.org; Fri, 10 Nov 2006 16:23:25 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly05a-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kAAGNMwR019202; Fri, 10 Nov 2006 16:23:25 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Fri, 10 Nov 2006 16:23:27 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299548@postman-pat.csafe.local>
In-Reply-To: 
From: "Tim Alsop" 
To: "RL 'Bob' Morgan" ,
	"Leif Johansson" 
X-Scanned-By: MailControl A-07-06-75 (www.mailcontrol.com) on 10.65.1.115
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Kitten , Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Bob,

Since the draft for SASL-HTTP is not yet an RFC, is there any reason why
changes cannot be proposed to allow it to support non-persistent
connections ?

It just seems strange to me that this draft has undergone a lot of work
by many people, and because of some functionality that is missing from
it (e.g. support for non-persistent connections) it is being suggested
that a new draft should be progressed instead. Is this the way that
standards are normally progressed ?

Regards,
Tim=20

-----Original Message-----
From: RL 'Bob' Morgan [mailto:rlmorgan@washington.edu]=20
Sent: 09 November 2006 23:26
To: Leif Johansson
Cc: Tim Alsop; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech


More significantly, draft-nystrom-http-sasl-12.txt only works when=20
persistent connections are used, which is a showstopper.  Hence the=20
text in http-gss:

    session.  Instead opaque identifiers in the GSS challenge option
    field are optionally used together with channel bindings to provide
a
    way to share a security context over several HTTP connections.

  - RL "Bob"

> Tim Alsop wrote:
>> Have you considered using SASL over HTTP with GSS-API, as described
in :
>>
>> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt
>>
>> I was under the impression that the above draft was the preferred
method
>> to improve on the HTTP negotiate approach.
>>
> I am under the impression that the proposed SASL mechanism doesn't=20
> support channel bindings, partially because channel bindings have been
a=20
> notoriously difficult problem to get right in SASL space. Personally I

> din't see the value of adding the extra layer of glue.
>
>    Cheers Leif
>
>
> _______________________________________________
> 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@lists.ietf.org Sun Nov 12 14:49:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjLJs-0005f6-0y; Sun, 12 Nov 2006 14:48:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKfn-0008Dd-1n
	for kitten@ietf.org; Sun, 12 Nov 2006 14:07:19 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjKfk-0000Zb-6A
	for kitten@ietf.org; Sun, 12 Nov 2006 14:07:19 -0500
Received: from localhost (localhost [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 5687D14228B;
	Sun, 12 Nov 2006 11:07:07 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 03864-08; Sun, 12 Nov 2006 11:07:05 -0800 (PST)
Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net
	[69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 32039142266;
	Sun, 12 Nov 2006 11:07:05 -0800 (PST)
In-Reply-To: <45538042.5020301@it.su.se>
References: <45538042.5020301@it.su.se>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: 
From: Lisa Dusseault 
Date: Sun, 12 Nov 2006 11:07:03 -0800
To: Leif Johansson 
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
X-Mailman-Approved-At: Sun, 12 Nov 2006 14:48:42 -0500
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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="===============1763322061=="
Errors-To: kitten-bounces@lists.ietf.org


--===============1763322061==
Content-Type: multipart/alternative; boundary=Apple-Mail-11-367629644


--Apple-Mail-11-367629644
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I've done an early (not for nits) review of this draft.

Major architectural concern: I am not enough of a GSS expert to know  
if this mechanism offers enough information in each roundtrip for a  
server to be able to reconstruct who the request is from and where  
they are in the authentication process.  The spec only mentions  
passing GSS tokens resulting from various API calls, and not how  
these tokens can be used to recover state, or what other state the  
server must store to put all this together, and how long the server  
must store that.  For HTTP server farms and non-persistent connection  
scenarios, it's important to explain this stuff somewhere.

Major standardization concern: This work is based on an Informational  
RFC, yet it's marked as intended for Standard Track.  I am dubious  
about a variance for a downref for RFC4559, for various reasons we  
can discuss if it's not obvious or others disagree.

Other work todo on this spec, besides the todos already mentioned in  
the spec:
	- Add a swimlane diagram showing client requests and server  
responses and what GSS stuff goes in each.
	- Much more discussion and spec text necessary on the "client  
initiates authentication feature".  Although I would like to see this  
feature become a standard, it's not actually tied to GSS, and I think  
this feature From kitten-bounces@lists.ietf.org Sun Nov 12 14:49:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjLJs-0005f6-0y; Sun, 12 Nov 2006 14:48:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjKfn-0008Dd-1n
	for kitten@ietf.org; Sun, 12 Nov 2006 14:07:19 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjKfk-0000Zb-6A
	for kitten@ietf.org; Sun, 12 Nov 2006 14:07:19 -0500
Received: from localhost (localhost [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 5687D14228B;
	Sun, 12 Nov 2006 11:07:07 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 03864-08; Sun, 12 Nov 2006 11:07:05 -0800 (PST)
Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net
	[69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 32039142266;
	Sun, 12 Nov 2006 11:07:05 -0800 (PST)
In-Reply-To: <45538042.5020301@it.su.se>
References: <45538042.5020301@it.su.se>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: 
From: Lisa Dusseault 
Date: Sun, 12 Nov 2006 11:07:03 -0800
To: Leif Johansson 
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9
X-Mailman-Approved-At: Sun, 12 Nov 2006 14:48:42 -0500
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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="===============1763322061=="
Errors-To: kitten-bounces@lists.ietf.org


--===============1763322061==
Content-Type: multipart/alternative; boundary=Apple-Mail-11-367629644


--Apple-Mail-11-367629644
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I've done an early (not for nits) review of this draft.

Major architectural concern: I am not enough of a GSS expert to know  
if this mechanism offers enough information in each roundtrip for a  
server to be able to reconstruct who the request is from and where  
they are in the authentication process.  The spec only mentions  
passing GSS tokens resulting from various API calls, and not how  
these tokens can be used to recover state, or what other state the  
server must store to put all this together, and how long the server  
must store that.  For HTTP server farms and non-persistent connection  
scenarios, it's important to explain this stuff somewhere.

Major standardization concern: This work is based on an Informational  
RFC, yet it's marked as intended for Standard Track.  I am dubious  
about a variance for a downref for RFC4559, for various reasons we  
can discuss if it's not obvious or others disagree.

Other work todo on this spec, besides the todos already mentioned in  
the spec:
	- Add a swimlane diagram showing client requests and server  
responses and what GSS stuff goes in each.
	- Much more discussion and spec text necessary on the "client  
initiates authentication feature".  Although I would like to see this  
feature become a standard, it's not actually tied to GSS, and I think  
this feature could not easily go to Proposed Standard unless it met  
with solid approval from HTTP implementors. There are many details  
still unspecified (some questions at bottom of this email, not  
guaranteed to be a complete list of issues).
	- I'd personally prefer MUST-language that does not say that the  
client or server "MUST call gss_foo_bar".   Instead, the requirements  
could be that the client or server MUST use the token that would  
result from a call to gss_foo_bar.  This may be an un-GSS way of  
doing things :)
	- Explain the limits on the number of roundtrips (current spec text  
says "This process continues until either an error occurs or the GSS- 
API layer has successfully completed...").

Lisa

Open questions on client initiating HTTP Authentication
	- How does the client know it may send an empty Authorization header  
-- what if it tries this with a server not supporting HTTP-GSS?
	- May the server respond with any WWW-Authenticate value whatsoever  
or only HTTP-GSS?
	- Can the server assume from the empty Authorization header that the  
client supports HTTP-GSS?  What about assuming support other mechanisms?
	- How would a GUI client (browser or rich client) know whether to  
present a "Login" button?  Imagine a client browsing a publicly- 
readable archive in HTML or WebDAV -- with anonymous read requests,  
the may see all kinds of documents.  Yet if the client can  
authenticate and get more permissions, the client might see new stuff  
(e.g. additional documents, links to edit documents, or with WebDAV  
see write permission available on ACL queries and know to enable  
"upload" and "change" UIs in response).
	- What method would the empty Authorization header go on? Any? Only  
GET? MUST the server handle it or can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif Johansson wrote:

>
> At the informal bar-bof yesterday in San Diego it was decided that  
> I should
> send my drafts describing a new http gss authentication mechanism to
> this list.
>
> Note that these drafts are not intended for inclusion in the kitten
> charter at
> this or any future time. They are only presented to this list for  
> review
> by gss
> experts.
>
> By way of background this draft (and the related draft describing  
> channel
> bindings for http+tls) describes a successor (but not update) to  the
> negotiate
> http auth mech which hopes to solve some of the drawbacks of this
> mechanism.
> The orginal motivation for this work was requirements from the calcify
> wg who
> expressed the need for a better authentication mechanism (than plain
> passwords)
> for applications using http as a transport but not using a browser  
> as a
> client.
>
> Please note that this is a 00 version and new versions with
> modifications based
> on discussions from yesterday are forthcoming.
>
> http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
> http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt
>
>        Cheers Leif


--Apple-Mail-11-367629644
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1


I've done an early (not for =
nits) review of this draft.=A0

Major architectural =
concern: I am not enough of a GSS expert to know if this mechanism =
offers enough information in each roundtrip for a server to be able to =
reconstruct who the request is from and where they are in the =
authentication process.=A0 The spec only mentions passing GSS tokens =
resulting from various API calls, and not how these tokens can be used =
to recover state, or what other state the server must store to put all =
this together, and how long the server must store that.=A0 For HTTP =
server farms and non-persistent connection scenarios, it's important to =
explain this stuff somewhere.=A0=A0

Major standardization =
concern: This work is based on an Informatcould not easily go to Proposed Standard unless it met  
with solid approval from HTTP implementors. There are many details  
still unspecified (some questions at bottom of this email, not  
guaranteed to be a complete list of issues).
	- I'd personally prefer MUST-language that does not say that the  
client or server "MUST call gss_foo_bar".   Instead, the requirements  
could be that the client or server MUST use the token that would  
result from a call to gss_foo_bar.  This may be an un-GSS way of  
doing things :)
	- Explain the limits on the number of roundtrips (current spec text  
says "This process continues until either an error occurs or the GSS- 
API layer has successfully completed...").

Lisa

Open questions on client initiating HTTP Authentication
	- How does the client know it may send an empty Authorization header  
-- what if it tries this with a server not supporting HTTP-GSS?
	- May the server respond with any WWW-Authenticate value whatsoever  
or only HTTP-GSS?
	- Can the server assume from the empty Authorization header that the  
client supports HTTP-GSS?  What about assuming support other mechanisms?
	- How would a GUI client (browser or rich client) know whether to  
present a "Login" button?  Imagine a client browsing a publicly- 
readable archive in HTML or WebDAV -- with anonymous read requests,  
the may see all kinds of documents.  Yet if the client can  
authenticate and get more permissions, the client might see new stuff  
(e.g. additional documents, links to edit documents, or with WebDAV  
see write permission available on ACL queries and know to enable  
"upload" and "change" UIs in response).
	- What method would the empty Authorization header go on? Any? Only  
GET? MUST the server handle it or can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif Johansson wrote:

>
> At the informal bar-bof yesterday in San Diego it was decided that  
> I should
> send my drafts describing a new http gss authentication mechanism to
> this list.
>
> Note that these drafts are not intended for inclusion in the kitten
> charter at
> this or any future time. They are only presented to this list for  
> review
> by gss
> experts.
>
> By way of background this draft (and the related draft describing  
> channel
> bindings for http+tls) describes a successor (but not update) to  the
> negotiate
> http auth mech which hopes to solve some of the drawbacks of this
> mechanism.
> The orginal motivation for this work was requirements from the calcify
> wg who
> expressed the need for a better authentication mechanism (than plain
> passwords)
> for applications using http as a transport but not using a browser  
> as a
> client.
>
> Please note that this is a 00 version and new versions with
> modifications based
> on discussions from yesterday are forthcoming.
>
> http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt
> http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt
>
>        Cheers Leif


--Apple-Mail-11-367629644
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1


I've done an early (not for =
nits) review of this draft.=A0

Major architectural =
concern: I am not enough of a GSS expert to know if this mechanism =
offers enough information in each roundtrip for a server to be able to =
reconstruct who the request is from and where they are in the =
authentication process.=A0 The spec only mentions passing GSS tokens =
resulting from various API calls, and not how these tokens can be used =
to recover state, or what other state the server must store to put all =
this together, and how long the server must store that.=A0 For HTTP =
server farms and non-persistent connection scenarios, it's important to =
explain this stuff somewhere.=A0=A0

Major standardization =
concern: This work is based on an Informational RFC, yet it's marked as =
intended for Standard Track.=A0 I am dubious about a variance for a =
downref for RFC4559, for various reasons we can discuss if it's not =
obvious or others disagree.

Other work todo on this =
spec, besides the todos already mentioned in the spec:
	- Add a =
swimlane diagram showing client requests and server responses and what =
GSS stuff goes in each.
	- Much more discussion and spec =
text necessary on the "client initiates authentication feature".=A0 =
Although I would like to see this feature become a standard, it's not =
actually tied to GSS, and I think this feature could not easily go to =
Proposed Standard unless it met with solid approval from HTTP =
implementors. There are many details still unspecified (some questions =
at bottom of this email, not guaranteed to be a complete list of =
issues).=A0
	- I'd personally prefer =
MUST-language that does not say that the client or server "MUST call =
gss_foo_bar".=A0 =A0Instead, the requirements could be that the client =
or server MUST use the token that would result from a call to =
gss_foo_bar.=A0 This may be an un-GSS way of doing things =
:)
	=
- Explain the limits on the number of roundtrips (current spec =
text says "This process continues until either an error occurs or the =
GSS-API=A0layer has successfully completed...").

Lisa

Open questions on client =
initiating HTTP Authentication
	- How =
does the client know it may send an empty Authorization header -- what =
if it tries this with a server not supporting HTTP-GSS?
	- May the =
server respond with any WWW-Authenticate value whatsoever or only =
HTTP-GSS?
	-=A0Can the server assume from =
the empty Authorization header that the client supports HTTP-GSS?=A0 =
What about assuming support other mechanisms?
	- How =
would a GUI client (browser or rich client) know whether to present a =
"Login" button?=A0 Imagine a client browsing a publicly-readable archive =
in HTML or WebDAV -- with anonymous read requests, the may see all kinds =
of documents.=A0 Yet if the client can authenticate and get more =
permissions, the client might see new stuff (e.g. additional documents, =
links to edit documents, or with WebDAV see write permission available =
on ACL queries and know to enable "upload" and "change" UIs in =
response).
	- What method would the empty =
Authorization header go on? Any? Only GET? MUST the server handle it or =
can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif =
Johansson wrote:


At the informal bar-bof yesterday in San Diego it =
was decided that I should
send my =
drafts describing a new http gss authentication mechanism to
this list.

Other work todo on this =
spec, besides the todos already mentioned in the spec:
	- Add a =
swimlane diagram showing client requests and server responses and what =
GSS stuff goes in each.
	- Much more discussion and spec =
text necessary on the "client initiates authentication feature".=A0 =
Although I would like to see this feature become a standard, it's not =
actually tied to GSS, and I think this feature could not easily go to =
Proposed Standard unless it met with solid approval from HTTP =
implementors. There are many details still unspecified (some questions =
at bottom of this email, not guaranteed to be a complete list of =
issues).=A0
	- I'd personally prefer =
MUST-language that does not say that the client or server "MUST call =
gss_foo_bar".=A0 =A0Instead, the requirements could be that the client =
or server MUST use the token that would result from a call to =
gss_foo_bar.=A0 This may be an un-GSS way of doing things =
:)
	=
- Explain the limits on the number of roundtrips (current spec =
text says "This process continues until either an error occurs or the =
GSS-API=A0layer has successfully completed...").

Lisa

Open questions on client =
initiating HTTP Authentication
	- How =
does the client know it may send an empty Authorization header -- what =
if it tries this with a server not supporting HTTP-GSS?
	- May the =
server respond with any WWW-Authenticate value whatsoever or only =
HTTP-GSS?
	-=A0Can the server assume from =
the empty Authorization header that the client supports HTTP-GSS?=A0 =
What about assuming support other mechanisms?
	- How =
would a GUI client (browser or rich client) know whether to present a =
"Login" button?=A0 Imagine a client browsing a publicly-readable archive =
in HTML or WebDAV -- with anonymous read requests, the may see all kinds =
of documents.=A0 Yet if the client can authenticate and get more =
permissions, the client might see new stuff (e.g. additional documents, =
links to edit documents, or with WebDAV see write permission available =
on ACL queries and know to enable "upload" and "change" UIs in =
response).
	- What method would the empty =
Authorization header go on? Any? Only GET? MUST the server handle it or =
can it ignore?

On Nov 9, 2006, at 11:23 AM, Leif =
Johansson wrote:


At the informal bar-bof yesterday in San Diego it =
was decided that I should
send my =
drafts describing a new http gss authentication mechanism to
this list.

Note that these drafts are not =
intended for inclusion in the kitten
charter =
at
this or any future time. They are only =
presented to this list for review
by =
gss
experts.

By way =
of background this draft (and the related draft describing =
channel
bindings for http+tls) describes =
a successor (but not update) to=A0 =
the=A0
negotiate
http auth =
mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal =
motivation for this work was requirements from the calcify
wg who
expressed the =
need for a better authentication mechanism (than plain
passwords)
for =
applications using http as a transport but not using a browser as =
a
client.

Please note that this is a 00 =
version and new versions with
modifications =
based
on discussions from yesterday =
are forthcoming.


=A0=A0 =A0 =A0 =
Cheers Leif
 

=

--Apple-Mail-11-367629644--


--===============1763322061==
Content-Type: text/plain; charsetn-left: 0px; min-height: =
14px; ">
Note that these drafts are not =
intended for inclusion in the kitten
charter =
at
this or any future time. They are only =
presented to this list for review
by =
gss
experts.

By way =
of background this draft (and the related draft describing =
channel
bindings for http+tls) describes =
a successor (but not update) to=A0 =
the=A0
negotiate
http auth =
mech which hopes to solve some of the drawbacks of this
mechanism.
The orginal =
motivation for this work was requirements from the calcify
wg who
expressed the =
need for a better authentication mechanism (than plain
passwords)
for =
applications using http as a transport but not using a browser as =
a
client.

Please note that this is a 00 =
version and new versions with
modifications =
based
on discussions from yesterday =
are forthcoming.


=A0=A0 =A0 =A0 =
Cheers Leif
 

=

--Apple-Mail-11-367629644--


--===============1763322061==
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

--===============1763322061==--


From kitten-bounces@lists.ietf.org Sun Nov 12 14:49:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjLJs-0005fB-4h; Sun, 12 Nov 2006 14:48:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjL80-0000XO-04
	for kitten@ietf.org; Sun, 12 Nov 2006 14:36:28 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjL7x-0005wI-Hj
	for kitten@ietf.org; Sun, 12 Nov 2006 14:36:27 -0500
Received: from localhost (localhost [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 0D16F142274;
	Sun, 12 Nov 2006 11:36:25 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 17407-04; Sun, 12 Nov 2006 11:36:23 -0800 (PST)
Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net
	[69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 85196142260;
	Sun, 12 Nov 2006 11:36:23 -0800 (PST)
In-Reply-To: 
References: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
	<4553B51E.9080006@it.su.se>
	
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8AB168F6-F0EC-465A-8949-C710C13E93FB@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault 
Date: Sun, 12 Nov 2006 11:36:21 -0800
To: Tim Alsop 
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
X-Mailman-Approved-At: Sun, 12 Nov 2006 14:48:42 -0500
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Tim,

Most of the history of why the HTTP-SASL draft died in IETF last call  
in 2004 can be found in the IETF I-D Tracker.  Look for "more detail"  
links under comments from Eric Rescorla, Joe Orton, Roy Fielding and  
myself.   I believe this link will work: https://datatracker.ietf.org/ 
public/pidtracker.cgi?command=view_id&dTag=6611&rfc_flag=0

We followed this up with conversations over lunch in person with  
Alexey Melnikov, Sam and others, also back in 2004, and concluded  
that the group at hand couldn't at that time think up an architecture  
that would tie SASL to HTTP without breaking intermediaries.

HTTP proxies, connections and state interact in a very complicated  
way and there is a great deal of "deployed reality" in addition to  
the specs.  I consider myself an HTTP expert yet I find it very  
difficult to be confident when this kind of thing will really work  
(you can see this from my comments in the I-D tracker from 2004,  
where I caught some issues but missed several even deeper  
architectural issues).  For example, today when a client request with  
an Authorization header resul="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

--===============1763322061==--


From kitten-bounces@lists.ietf.org Sun Nov 12 14:49:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjLJs-0005fB-4h; Sun, 12 Nov 2006 14:48:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjL80-0000XO-04
	for kitten@ietf.org; Sun, 12 Nov 2006 14:36:28 -0500
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjL7x-0005wI-Hj
	for kitten@ietf.org; Sun, 12 Nov 2006 14:36:27 -0500
Received: from localhost (localhost [127.0.0.1])
	by laweleka.osafoundation.org (Postfix) with ESMTP id 0D16F142274;
	Sun, 12 Nov 2006 11:36:25 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1])
	by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 17407-04; Sun, 12 Nov 2006 11:36:23 -0800 (PST)
Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net
	[69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id 85196142260;
	Sun, 12 Nov 2006 11:36:23 -0800 (PST)
In-Reply-To: 
References: <0D8F2EFD3A10E24DAEEA48EA6DA07D3029953B@postman-pat.csafe.local>
	<4553B51E.9080006@it.su.se>
	
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8AB168F6-F0EC-465A-8949-C710C13E93FB@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault 
Date: Sun, 12 Nov 2006 11:36:21 -0800
To: Tim Alsop 
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
X-Mailman-Approved-At: Sun, 12 Nov 2006 14:48:42 -0500
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Tim,

Most of the history of why the HTTP-SASL draft died in IETF last call  
in 2004 can be found in the IETF I-D Tracker.  Look for "more detail"  
links under comments from Eric Rescorla, Joe Orton, Roy Fielding and  
myself.   I believe this link will work: https://datatracker.ietf.org/ 
public/pidtracker.cgi?command=view_id&dTag=6611&rfc_flag=0

We followed this up with conversations over lunch in person with  
Alexey Melnikov, Sam and others, also back in 2004, and concluded  
that the group at hand couldn't at that time think up an architecture  
that would tie SASL to HTTP without breaking intermediaries.

HTTP proxies, connections and state interact in a very complicated  
way and there is a great deal of "deployed reality" in addition to  
the specs.  I consider myself an HTTP expert yet I find it very  
difficult to be confident when this kind of thing will really work  
(you can see this from my comments in the I-D tracker from 2004,  
where I caught some issues but missed several even deeper  
architectural issues).  For example, today when a client request with  
an Authorization header results in a 401 Unauthorized response, it  
means game over.  Are there deployed caches or firewalls or client  
libraries that make that assumption and depend on it ( which would be  
untrue for at least one interchange in every use of HTTP-GSS)?  I  
would hope not, but experience with deployed HTTP reality has led me  
to conclude that it's a festering minefield (how's that for mixed  
metaphors) of unwarranted assumptions and implementation-by-imitation.

Lisa

On Nov 9, 2006, at 3:26 PM, RL 'Bob' Morgan wrote:

>
> More significantly, draft-nystrom-http-sasl-12.txt only works when  
> persistent connections are used, which is a showstopper.  Hence the  
> text in http-gss:
>
>    session.  Instead opaque identifiers in the GSS challenge option
>    field are optionally used together with channel bindings to  
> provide a
>    way to share a security context over several HTTP connections.
>
>  - RL "Bob"
>
>> Tim Alsop wrote:
>>> Have you considered using SASL over HTTP with GSS-API, as  
>>> described in :
>>>
>>> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt
>>>
>>> I was under the impression that the above draft was the preferred  
>>> method
>>> to improve on the HTTP negotiate approach.
>>>
>> I am under the impression that the proposed SASL mechanism doesn't  
>> support channel bindings, partially because channel bindings have  
>> been a notoriously difficult problem to get right in SASL space.  
>> Personally I din't see the value of adding the extra layer of glue.
>>
>>    Cheers Leif
>>
>>
>> _______________________________________________
>> 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





ts in a 401 Unauthorized response, it  
means game over.  Are there deployed caches or firewalls or client  
libraries that make that assumption and depend on it ( which would be  
untrue for at least one interchange in every use of HTTP-GSS)?  I  
would hope not, but experience with deployed HTTP reality has led me  
to conclude that it's a festering minefield (how's that for mixed  
metaphors) of unwarranted assumptions and implementation-by-imitation.

Lisa

On Nov 9, 2006, at 3:26 PM, RL 'Bob' Morgan wrote:

>
> More significantly, draft-nystrom-http-sasl-12.txt only works when  
> persistent connections are used, which is a showstopper.  Hence the  
> text in http-gss:
>
>    session.  Instead opaque identifiers in the GSS challenge option
>    field are optionally used together with channel bindings to  
> provide a
>    way to share a security context over several HTTP connections.
>
>  - RL "Bob"
>
>> Tim Alsop wrote:
>>> Have you considered using SASL over HTTP with GSS-API, as  
>>> described in :
>>>
>>> http://tools.ietf.org/wg/sasl/draft-nystrom-http-sasl-12.txt
>>>
>>> I was under the impression that the above draft was the preferred  
>>> method
>>> to improve on the HTTP negotiate approach.
>>>
>> I am under the impression that the proposed SASL mechanism doesn't  
>> support channel bindings, partially because channel bindings have  
>> been a notoriously difficult problem to get right in SASL space.  
>> Personally I din't see the value of adding the extra layer of glue.
>>
>>    Cheers Leif
>>
>>
>> _______________________________________________
>> 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@lists.ietf.org Mon Nov 13 15:41:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjicE-00047h-Gn; Mon, 13 Nov 2006 15:41:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjiYT-000294-Kz
	for kitten@ietf.org; Mon, 13 Nov 2006 15:37:21 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjiMU-0002Af-N0
	for kitten@ietf.org; Mon, 13 Nov 2006 15:25:01 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 00C3E3BF52;
	Mon, 13 Nov 2006 21:24:47 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 13298-01-25; Mon, 13 Nov 2006 21:24:46 +0100 (CET)
Received: from [83.178.14.190] (m83-178-14-190.cust.tele2.se [83.178.14.190])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 56F3E3BF2C;
	Mon, 13 Nov 2006 21:24:45 +0100 (CET)
Message-ID: <4558D48A.9080208@it.su.se>
Date: Mon, 13 Nov 2006 21:24:42 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Lisa Dusseault 
References: <45538042.5020301@it.su.se>
	
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.648 tagged_above=-99 required=7 tests=[AWL=0.017,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Lisa Dusseault wrote:
> I've done an early (not for nits) review of this draft. 
>
> Major architectural concern: I am not enough of a GSS expert to know
> if this mechanism offers enough information in each roundtrip for a
> server to be able to reconstruct who the request is from and where
> they are in the authentication process.  The spec only mentions
> passing GSS tokens resulting from various API calls, and not how these
> tokens can be used to recover state, or what other state the server
> must store to put all this together, and how long the server must
> store that.  For HTTP server farms and non-persistent connection
> scenarios, it's important to explain this stuff somewhere. 
Noted.
>
> Major standardization concern: This work is based on an Informational
> RFC, yet it's marked as intended for Standard Track.  I am dubious
> about a variance for a downref for RFC4559, for various reasons we can
> discuss if it's not obvious or others disagree.
>
The intent is only to use RFC4559 as a non-normative reference. The
specification shouldn't contain any
normative references on RFC4559 but I would like to include the
non-normative reference both as help
for implementors and to explain what the historical basis for this
specification is.
> Other work todo on this spec, besides the todos already mentioned in
> the spec:
> - Add a swimlane diagram showing client requests and server responses
> and what GSS stuff goes in each.
That will certainly increase readability.
> - Much more discussion and spec text necessary on the "client
> initiates authentication feature".  Although I would like to see this
> feature become a standard, it's not actually tied to GSS, and I think
> this feature could not easily go to Proposed Standard unless it met
> with solid approval from HTTP implementors. There are many details
> still unspecified (some questions at bottom of this email, not
> guaranteed to be a complete list of issues).
I have gotten similar feedback from other reviewers too.
>  
> - I'd personally prefer MUST-language that does not say that the
> client or server "MUST call gss_foo_bar".   Instead, the requirements
> could be that the client or server MUST use the token that would
> result from a call to gss_foo_bar.  This may be an un-GSS way of doing
> things :)
I was looking for a better way to write this. This sounds like a win and
I don't think it is very un-GSS at all.
> - Explain the limits on the number of roundtrips (current spec text
> says "This process continues until either an error occurs or the
> GSS-API layer has successfully completed...").
>
That may be more difficult. In practice there are few situations where
more than (say) 5 roundtrips are
ever needed and in many cases 1 or 2 are enough but in general GSS have
few hard limits. The same
question came up during the discussion of GSS-TLS on friday. I don't
have a good answer to this at
this time.
> Lisa
>
> /Open questions on client initiating HTTP Authentication/
> - How does the client know it may send an empty Authorization header
> -- what if it tries this with a server not supporting HTTP-GSS?
> - May the server respond with any WWW-Authenticate value whatsoever or
> only HTTP-GSS?
> - Can the server assume from the empty Authorization header that the
> client supports HTTP-GSS?  What about assuming support other mechanisms?
If I understand these questions correctly I believe they will be
alleviated by following Cyrus Daboos suggestion to
use the attribute=value-pair ABNF which RFC4559 decided not to use for
some reason. I.e "GSS challenge=<> "
instead of "GSS <>".
> - How would a GUI client (browser or rich client) know whether to
> present a "Login" button?  Imagine a client browsing a
> publicly-readable archive in HTML or WebDAV -- with anonymous read
> requests, the may see all kinds of documents.  Yet if the client can
> authenticate and get more permissions, the client might see new stuff
> (e.g. additional documents, links to edit documents, or with WebDAV
> see write permission available on ACL queries and know to enable
> "upload" and "change" UIs in response).
How does a client ever know that?
> - What method would the empty Authorization header go on? Any? Only
> GET? MUST the server handle it or can it ignore?

Again I wonder if this problem goes away with better ABNF...

       Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 13 15:54:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjioi-0005nY-Vz; Mon, 13 Nov 2006 15:54:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjioi-0005nT-L0
	for kitten@ietf.org; Mon, 13 Nov 2006 15:54:08 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjioh-00070F-BJ
	for kitten@ietf.org; Mon, 13 Nov 2006 15:54:08 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id C9AC83BEC9;
	Mon, 13 Nov 2006 21:54:06 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 14295-01-43; Mon, 13 Nov 2006 21:54:06 +0100 (CET)
Received: from [83.178.14.190] (m83-178-14-190.cust.tele2.se [83.178.14.190])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 9B9AF3BE2B;
	Mon, 13 Nov 2006 21:54:05 +0100 (CET)
Message-ID: <4558DB6C.9050005@it.su.se>
Date: Mon, 13 Nov 2006 21:54:04 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Lisa Dusseault 
References: <45538042.5020301@it.su.se>
	
	<4558D48A.9080208@it.su.se>
	<0A4A1315-61E9-4438-9DFC-4D2BBFB206C4@osafoundation.org>
In-Reply-To: <0A4A1315-61E9-4438-9DFC-4D2BBFB206C4@osafoundation.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.649 tagged_above=-99 required=7 tests=[AWL=0.016,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



>
> Some of these need English text.  An ABNF telling me that the
> WWW-Authenticate header can contain "GSS challenge=<>" doesn't
> actually guarantee that the server sending such a header supports GSS
> although I think that is a reasonable inference. :)  I think it's
> really text elsewhere which talks about *empty* headers, and it's not
> clear what the empty Authorization header means.  Does it mean "I want
> to authenticate but I'm not telling you anything about which
> authentication mechanisms I might support"?  Does it mean "I want to
> authenticate and by the way I support GSS"? 
>
The former of course! There is no sense in putting any authentication
mechanism before the others at this point :-)

I'd say you raise a good point - the question of how to do negotiation
of authentication mechanism in HTTP is
perhaps too big a bite for this specification, especially since there
are all the issues involving downgrade attacks
etc. For the purpose of HTTP-GSS possibly all I need is that the client
can initiate authentication when it knows
that the server supports it and wants to do a handle-based fast reauth.

This is all tied in with channel-bindings which imo makes it unlikely
that the client will want to initiate auth in the
general case since the first "please authenticate" challenge from the
server will also serve to establish cb to the
underlying tls if one exists.

          Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 13 19:08:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjlq5-0006jo-P1; Mon, 13 Nov 2006 19:07:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjlq4-0006jI-7d
	for kitten@ietf.org; Mon, 13 Nov 2006 19:07:44 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjlq2-0008DF-QA
	for kitten@ietf.org; Mon, 13 Nov 2006 19:07:44 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id BAA10383;
	Tue, 14 Nov 2006 01:07:11 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611140007.BAA02672@uw1048.wdf.sap.corp>
To: rlmorgan@washington.edu (RL 'Bob' Morgan)
Date: Tue, 14 Nov 2006 01:07:10 +0100 (MET)
In-Reply-To:  from
	"RL 'Bob' Morgan" at Nov 9, 6 03:26:00 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

RL 'Bob' Morgan wrote:
> More significantly, draft-nystrom-http-sasl-12.txt only works when 
> persistent connections are used, which is a showstopper.

Microsoft's implementation (rfc4559) also support only persistent
connections.  The request-reply is basically half-duplex until
the security context is established, and after that it becomes
regular HTTP/1.1 connection: keep-alive.  In none of the successive
requests on the persistent channel is it visible that there was
a GSS-API based authentication in the beginning.

Every new communication channel requires a new gss/spnego
authentication handhshake.

A gss-api based authentication is fairly expensive and requires
at least two tokens (under spnego), so a full authentication of
every request would be prohibitively expensive.

On the server-side, binding the lifetime of the gssapi security
context to the socket of the persistent connection is IMHO quite
sensible.


There is a certain problem of such a communication scheme with
reverse proxies, ssl accellerators and load balancers, which may have
difficulties providing persistent connections.
"Request pooling/aggregation" between the (server-side) middle-box
and the backend might be difficult.


> Hence the 
> text in http-gss:
> 
>     session.  Instead opaque identifiers in the GSS challenge option
>     field are optionally used together with channel bindings to provide a
>     way to share a security context over several HTTP connections.

I don't really understand what you mean by that, but it really doesn't
sound right.


Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
because his CCM mechanism desperately needs them).  (Traditional)
channel bindings break many architectures in a horrible fashion because
they link characteristics from entirely seperate communication layers
and fail with the addition of the first middle-box to the communication
path (proxy,app-level gateway,firewall).


A much better approach to "forking" sessions that were authenticated
in rfc4559-style is that the application issues a (cryptgraphically strong)
session re-authentication token which the client needs to re-send with
*every* new request.

The existing rfc4559 with SPNEGO&Kerberos uses a 2-token security
context establishment, so if the application issues a session
re-authentication token which the client adds to every request,
then this scheme works even with servers-side reverse proxies
and load-balancers that pool&aggregate requests over a small
number of connections between the middle-box and the backend.


Traditional Web-Browsers have only limited functionality to replicate
session authentication tokens in successor requests.
 - basic authentication credentials
 - cookies
however only cookies can be set on request of the server.

It would have been a good idea to have the browser replicate
a server-issued (crypgraphically strong) token on a www-authenticate:
header field for every successive request after a gss/spnego handshake,
but it appears the designers of the rfc4559 authentication scheme forgot to
specify this, so right now, the use of non-persistent cookies and
a preference or requirement of an SSL/TLS protected communication channel
is probably the most portable design approach (with the least impact
on the creative features of middle-boxes).  If reverse proxies with
load balacing to the backend are involved, the session re-authentication
token must contain enough plaintext information for the reverse proxy
to find the backend server that created this session for repeated
or new network connections.


-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 13 22:03:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjoZj-00028y-TI; Mon, 13 Nov 2006 22:03:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjoZh-00028c-U7
	for kitten@ietf.org; Mon, 13 Nov 2006 22:03:01 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjoZg-00015d-Ld
	for kitten@ietf.org; Mon, 13 Nov 2006 22:03:01 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id 168C542B6E;
	Mon, 13 Nov 2006 22:02:51 -0500 (EST)
Date: Mon, 13 Nov 2006 22:02:41 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061113220241.7470cb4f.mba2000@ioplex.com>
In-Reply-To: <200611140007.BAA02672@uw1048.wdf.sap.corp>
References: 
	<200611140007.BAA02672@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, 14 Nov 2006 01:07:10 +0100 (MET)
Martin Rex  wrote:

> A gss-api based authentication is fairly expensive and requires
> at least two tokens (under spnego), so a full authentication of
> every request would be prohibitively expensive.

SPNEGO sites currently authenticate every request and I don't recall
people complaining that much (unless perhaps NTLM is getting in the way).

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 07:38:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjxYO-0002ut-Vo; Tue, 14 Nov 2006 07:38:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjxYN-0002un-Vx
	for kitten@ietf.org; Tue, 14 Nov 2006 07:38:15 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjxYM-0004QN-IF
	for kitten@ietf.org; Tue, 14 Nov 2006 07:38:15 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id E24B13BF6D;
	Tue, 14 Nov 2006 13:38:00 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 28674-01-64; Tue, 14 Nov 2006 13:38:00 +0100 (CET)
Received: from [83.178.6.25] (m83-178-6-25.cust.tele2.se [83.178.6.25])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id F3C7C3BF6E;
	Tue, 14 Nov 2006 13:37:15 +0100 (CET)
Message-ID: <4559B845.3070104@it.su.se>
Date: Tue, 14 Nov 2006 13:36:21 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: martin.rex@sap.com
References: <200611140007.BAA02672@uw1048.wdf.sap.corp>
In-Reply-To: <200611140007.BAA02672@uw1048.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.649 tagged_above=-99 required=7 tests=[AWL=0.016,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Martin Rex wrote:


>> text in http-gss:
>>
>>     session.  Instead opaque identifiers in the GSS challenge option
>>     field are optionally used together with channel bindings to provide a
>>     way to share a security context over several HTTP connections.
>>     
>
> I don't really understand what you mean by that, but it really doesn't
> sound right.
>
>   
Maybe the next revision will be more clear on this point.
> Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
>   
Nor do I.
> because his CCM mechanism desperately needs them).  (Traditional)
> channel bindings break many architectures in a horrible fashion because
> they link characteristics from entirely seperate communication layers
> and fail with the addition of the first middle-box to the communication
> path (proxy,app-level gateway,firewall).
>
>
> A much better approach to "forking" sessions that were authenticated
> in rfc4559-style is that the application issues a (cryptgraphically strong)
> session re-authentication token which the client needs to re-send with
> *every* new request.
>
>   
This is essentially what http-gss specifies! I wanted to avoid explicit
dependencies on GSS-API
for the context identifiers, which is why I only mentioned
gss_export_sec_context in an implementation
note at the end. I can think of several ways in which a server-farm
(say) could maintain state in
such a way that a random token would be the preferred way communicate
state over a cryptographic
token.

> The existing rfc4559 with SPNEGO&Kerberos uses a 2-token security
> context establishment, so if the application issues a session
> re-authentication token which the client adds to every request,
> then this scheme works even with servers-side reverse proxies
> and load-balancers that pool&aggregate requests over a small
> number of connections between the middle-box and the backend.
>   
But this doesn't work for all GSS-API mechanisms which is the goal. I'm
not interested in
a solution which only provides support for a single kerberos GSS-API
mechanism.

          Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 09:07:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjyw9-0008R2-7f; Tue, 14 Nov 2006 09:06:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjyw8-0008Qq-4S
	for kitten@ietf.org; Tue, 14 Nov 2006 09:06:52 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjyw6-0007UT-PJ
	for kitten@ietf.org; Tue, 14 Nov 2006 09:06:52 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id PAA26147;
	Tue, 14 Nov 2006 15:05:49 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611141405.PAA10535@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Tue, 14 Nov 2006 15:05:49 +0100 (MET)
In-Reply-To: <20061113220241.7470cb4f.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 13, 6 10:02:41 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> Martin Rex  wrote:
> >
> > A gss-api based authentication is fairly expensive and requires
> > at least two tokens (under spnego), so a full authentication of
> > every request would be prohibitively expensive.
> 
> SPNEGO sites currently authenticate every request and I don't recall
> people complaining that much (unless perhaps NTLM is getting in the way).

When I checked the headers of the requests with HTTPwatch when
using negotiate between MSIE 6 and IIS, then the authentication
exchange (and www-authenticate headers) were only visible on
the first request of a new connection.

About the performance impact:  there is a lot of code out there
in "productive" environments which is a real performance killer,
especially Apache in reverse-proxy scenarios (doesn't implement
client-side SSL session caching, can not do request aggregation,
fragments request headers like crazy).

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 09:18:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjz7L-00068n-7L; Tue, 14 Nov 2006 09:18:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjz7J-00068E-7e
	for kitten@ietf.org; Tue, 14 Nov 2006 09:18:25 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjz7G-0000Wo-Ux
	for kitten@ietf.org; Tue, 14 Nov 2006 09:18:25 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 1B5353BED2;
	Tue, 14 Nov 2006 15:18:08 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 07948-01-60; Tue, 14 Nov 2006 15:18:07 +0100 (CET)
Received: from [83.178.6.25] (m83-178-6-25.cust.tele2.se [83.178.6.25])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id A4DC93BF84;
	Tue, 14 Nov 2006 15:18:00 +0100 (CET)
Message-ID: <4559D017.8010200@it.su.se>
Date: Tue, 14 Nov 2006 15:17:59 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: martin.rex@sap.com
References: <200611141405.PAA10535@uw1048.wdf.sap.corp>
In-Reply-To: <200611141405.PAA10535@uw1048.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.65 tagged_above=-99 required=7 tests=[AWL=0.015,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org


>
> About the performance impact:  there is a lot of code out there
> in "productive" environments which is a real performance killer,
> especially Apache in reverse-proxy scenarios (doesn't implement
> client-side SSL session caching, can not do request aggregation,
> fragments request headers like crazy).
>
>
>   
I have to agree with Martin here - just because its been deployed
doesn't mean it can't
be improved upon.

       Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 11:08:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk0q3-0003Wk-EU; Tue, 14 Nov 2006 11:08:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0q2-0003WW-5U
	for kitten@ietf.org; Tue, 14 Nov 2006 11:08:42 -0500
Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0pz-0001Y8-AX
	for kitten@ietf.org; Tue, 14 Nov 2006 11:08:42 -0500
Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com
	[68.175.91.105])
	by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id
	kAEG8YgO022047
	for ; Tue, 14 Nov 2006 11:08:36 -0500 (EST)
Received: from [192.168.1.13] by secure-endpoints.com
	(Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3)
	with ESMTP id md50000034847.msg
	for ; Tue, 14 Nov 2006 11:09:11 -0500
Message-ID: <4559EA2B.5000201@secure-endpoints.com>
Date: Tue, 14 Nov 2006 11:09:15 -0500
From: Jeffrey Altman 
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Seema.Malkani@Sun.COM
References: 
	<4553A4A2.3060809@Sun.COM>
In-Reply-To: <4553A4A2.3060809@Sun.COM>
X-Enigmail-Version: 0.94.0.0
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Tue, 14 Nov 2006 11:09:11 -0500
	(not processed: message from valid local sender)
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kitten@ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
Cc: kitten@ietf.org, Ken Raeburn 
Subject: Re: comments on java bindings update,
	draft-ietf-kitten-rfc2853bis-02
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.com
List-Id: Common Authentication Technologies - Next Generation
	
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1790195014=="
Errors-To: kitten-bounces@lists.ietf.org

This is a cryptographically signed message in MIME format.

--===============1790195014==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=sha1; boundary="------------ms060501040706000908010302"

This is a cryptographically signed message in MIME format.

--------------ms060501040706000908010302
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Speaking as an individual, not as Chair.

Seema Malkani wrote:
> Thanks for the review, Ken.
> 
> Ken Raeburn wrote On 11/07/06 18:56,:
> 
>> Jeff was complaining because not enough people had reviewed the java 
>> bindings, so I took a look.  Not that I'm any great expert on Java, 
>> but I do okay with English and sometimes even with GSSAPI...
>>
>> The abstract says in part:
>>
>>       This document
>>     updates the Java bindings for the GSS-API that are specified in
>>     "Generic Security Service API version 2 : Java Bindings" (RFC2853).
>>     This document obsoletes RFC2853 by making specific and incremental
>>     clarifications and corrections to it in response to 
>> identification of
>>     transcription errors and implementation experience.  The note-worthy
>>     changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853,
>>     which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and 
>> 7.8.1 of
>>     this document, where numerical constants were either added or
>>     modified.
>>
>> But aside from this, I didn't see a detailed description of just 
>> what's changed from the previous version.  (I didn't go back and 
>> check the email archives though.)  A non-normative section listing 
>> the changes from RFC 2853 would've been helpful.
> 
> The Abstract has a summary of changes, listing the specific section
> updates. Would a list of changes in an Appendix section at the end of
> the draft be helpful ?

The Abstract is just that "an abstract".  It summarizes the contents
of the document so that readers do not have to examine all 100+ pages
to determine if the document is meaningful to them.

In this particular case, since this document replaces the previous
one and does not update it, I think the abstract needs to be corrected.
This document obsoletes RFC2853.  I agree with Ken that the list of
changes should be specified in an Appendix.  The list of changes should
be sufficiently complete so that someone who implemented RFC2853 can
determine whether or not their implementation is still compliant.

>> So I poked at the two versions with Emacs a bit, stripping out page 
>> headers and footers and line breaks and comparing what was left.  I 
>> think my list covers everything changed, and I've got comments on 
>> some of the changes:
>>
>> * minor grammatical fixes, basic text changes in the intro relating 
>> to this being an update
>>
>> * changes to various number assignments, new status codes added
> 
> The GSS status code update is the one of the significant update to RFC
> 2853. The GSS error code values use for GSS exceptions were incorrect in
> the original RFC 2853.

In the Appendix of changes should be a table that indicates what the
wrong values were and what the correct values are.

>> * added labels "Figure 3" through "Figure 9" to various tables, 
>> though the labels aren't always on the same page as the table being 
>> labeled (e.g., "Figure 3" at the top of page 32, describing the table 
>> that's on page 31); where are Figures 1 and 2?  Can the labels just 
>> go away?
> 
> RFC 2853 was written in text format, hence labeling was easier to add.
> And now RFC 2853 Update has been written in XML format, the labeling
> comes from the standard xml tags.

You might want to check on the XML2RFC list to see if there is a better
way of handling table labels.

>> * java syntax tweaks (array parameters, missing return types)
>>
>> * specify values for INITIATE_AND_ACCEPT and friends in a bunch of 
>> places (isn't one enough?), where they weren't specified at all in 
>> rfc2853
> 
> RFC 2853 defined the Credential usage Static constants in section 6.3.2,
> but missed defining the usage values.
> 
> This draft defines the Credential usage values in section 7.3.2

This should be explicitly stated in the Appendix.

>> * status code values being specified in a couple of places now 
>> (5.12.1, 7.8.1); I didn't check for consistency
> 
> GSS status code values in RFC 2853 were not consistent. The draft now
> defines in GSS error code values that are consistent.

>> * change NT_HOSTBASED_SERVICE OID value from the deprecated value to 
>> the current one (as described in the C bindings in RFC 2744); the new 
>> version has a typo ("Unites States", which is also present in RFC 2744)
> 
> This needs to be fixed, I'll make the update.
> 
> { iso(1) member-body(2) United States(840) mit(113554) infosys(1)
> gssapi(2) generic(1) service_name(4) }
> 
>>
>> * change text describing lifetime constants from "must be set to..." 
>> to "value of constant is..."
> 
> This update defines the recommended value.

Is this value a SHOULD or a MUST?

Is this a change from RFC2853?

>> * corrected name of References section
>>
>> * updated IPR & Copyright, new authors' addresses
>>
>> * inserted the usual "conventions used in this document" section, 
>> before the introduction (resulting in a renumbering of sections 
>> through the whole document), even though the key words described 
>> there are not actually used in the document; I haven't checked the 
>> rules, but I would hope we can omit it in that case
> 
> The keywords defined in the Normative References are used in the draft.
> Can you clarify what keyword are you referring to ?

I suspect Ken is referring to:

MUST, SHOULD, SHOULD NOT, MUST NOT, ....

>> RFC 2744 inconsistencies notwithstanding, I think this spec should 
>> use consistent style for specifying OID values.  Is it "iso(1)" or "1
>> (iso)"?
> 
> RFC 4120, RFC 2744, RFC2743 all define iso(1). This draft follows the
> same. Is this not the correct style ?

Ken's point is that you should be consistent within this document.  A
quick scan shows both styles:

 { iso(1) member-body(2) United States(840) mit(113554)
   infosys(1) gssapi(2) generic(1) machine_uid_name(2) }

 { 1(iso), 3(org), 6(dod), 1(internet), 5(security),
   6(nametypes), 3(gss-anonymous-name)

I prefer the first.  I agree with Ken, please make them consistent.

Jeffrey Altman

--------------ms060501040706000908010302
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX
DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o
fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U
8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0
ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD
A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo
pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v
L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0
0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL
zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4
TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV
GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07
E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX
lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB
gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax
myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc
6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID
YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMTQxNjA5MTVaMCMGCSqGSIb3DQEJBDEWBBQ8k70x
R41oiu9OsAWRg05C3gCaojBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB
BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ
KoZIhvcNAQEBBQAEggEAFa7VVRbI9Ugi76a0m5pQN7ytosXYWqdF9J74Th51Xy7DLwpcjDZl
42z9fL3ixqDOgzlJ6zvQRULZVdsuI9HLIBDlhdfy8l2IRiHR1ETAUmqTI3fSMRmE6mDVvXzq
ou2bd3d85uVdoPjkQgJUTL0dG5kFByzSxv+lwsNPOY5VREjJw59jr8ybn16+xq9WfBSrRHQn
ATbua1BbtVZc+gDjUJVKic7LiIXCr6qQbL5yuNkQx6gbRbCzfXLpf0/ubaP92eLIMGVZnOOS
PPtUtnUSzW3d72IVyE0dF29a8Ekm/rVCtJqxNKQFkMk25Wc1HjTvN2ru/Xj3VoAWUmvXQLNu
UQAAAAAAAA==
--------------ms060501040706000908010302--



--===============1790195014==
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

--===============1790195014==--





From kitten-bounces@lists.ietf.org Tue Nov 14 12:14:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk1rO-0001f0-TU; Tue, 14 Nov 2006 12:14:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1rN-0001eZ-Ia
	for kitten@ietf.org; Tue, 14 Nov 2006 12:14:09 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk1rM-0003Pc-5m
	for kitten@ietf.org; Tue, 14 Nov 2006 12:14:09 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id AE1F642B8C;
	Tue, 14 Nov 2006 12:14:01 -0500 (EST)
Date: Tue, 14 Nov 2006 12:13:58 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061114121358.5cf55da4.mba2000@ioplex.com>
In-Reply-To: <200611141405.PAA10535@uw1048.wdf.sap.corp>
References: <20061113220241.7470cb4f.mba2000@ioplex.com>
	<200611141405.PAA10535@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, 14 Nov 2006 15:05:49 +0100 (MET)
Martin Rex  wrote:

> Michael B Allen wrote:
> > 
> > Martin Rex  wrote:
> > >
> > > A gss-api based authentication is fairly expensive and requires
> > > at least two tokens (under spnego), so a full authentication of
> > > every request would be prohibitively expensive.
> > 
> > SPNEGO sites currently authenticate every request and I don't recall
> > people complaining that much (unless perhaps NTLM is getting in the way).
> 
> When I checked the headers of the requests with HTTPwatch when
> using negotiate between MSIE 6 and IIS, then the authentication
> exchange (and www-authenticate headers) were only visible on
> the first request of a new connection.

That's not what I see with IIS on Windows 2003 SBS. At no time does the
client get a response without the request having a Negotiate token. I
still have the capture if you'd like to see it.

> About the performance impact:  there is a lot of code out there
> in "productive" environments which is a real performance killer,
> especially Apache in reverse-proxy scenarios (doesn't implement
> client-side SSL session caching, can not do request aggregation,
> fragments request headers like crazy).

I'm not advocating authenticating every request. I'm just trying to help
out with the facts of the case which is that in at least my case every
request is authenticated which suggests that "prohibitively expensive"
is misleading. GSSAPI acceptor authentication is not *that* expensive
since there's no network communication involved (provided the acceptor
has loaded it's credential already).

It would be nice to curb redundant authentications but you do realize it
could be tricky on top of HTTP. You're talking about associating state
with a socket when most HTTP server implementations, Servlet containers,
PHP scripts, etc only give you a *session* which is more abstract
and not directly mapped to the client's socket. You would have to get
the local port and put state in a map.

Note that if you have to put state in a map by port you could do that
now with Negotiate auth so it's not clear to me what benifit this new
mechanism would provide wrt redundant authentications.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 14:21:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk3q1-00073F-9k; Tue, 14 Nov 2006 14:20:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3q0-00073A-L9
	for kitten@ietf.org; Tue, 14 Nov 2006 14:20:52 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk3pz-0004vr-88
	for kitten@ietf.org; Tue, 14 Nov 2006 14:20:52 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id UAA05312;
	Tue, 14 Nov 2006 20:20:31 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611141920.UAA25038@uw1048.wdf.sap.corp>
To: lisa@osafoundation.org (Lisa Dusseault)
Date: Tue, 14 Nov 2006 20:20:31 +0100 (MET)
In-Reply-To: <4EA1EE39-1F7F-438D-8E2A-2E9F65539948@osafoundation.org> from
	"Lisa Dusseault" at Nov 13, 6 04:30:11 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: b4a0a5f5992e2a4954405484e7717d8c
Cc: kitten@ietf.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Lisa Dusseault wrote:
> 
> HTTP pipelining does make the use of server-issued tokens difficult  
> unless the tokens have a certain lifetime beyond just one request.

I don't think it is a problem with pipelining.  There might be a problem
with page caching of a web browser depending on how it is implemented
(or configured).

In case that you're referring to HTTP/1.1 rfc2616 secion 8.1.2.2,
then a client that attempts pipelining will already have to deal
gracefully with every situation where the server does not behave
in the expected fashion or wants to close the reason for whatever
server-internal reasons.

A client, that sends out 10 requests on a new connection to a server
that expects authentication according to rfc4559, might receive 10
401 Unauthorized in a row -- or, not unlikely experience connection
closure when the second or third (pipelined) request still doesn't
contain a reaction to the initial 401 Unauthorized server response.

Connection: keep-alive is also not a sticky characteristic,
it may be cancelled with every new response from the server,
invalidating any request that might have optimistically been
sent in advance.


In the normal course of action, a web browser does not start
out requesting more than a single URL from a new server.
It starts with a single URL, which initiates the authentication
handshake.  Once the initial reply is received, it may contain
frames and lots of embedded objects, for which the request
paralellization is started.  Pipelining will work on the
initial persistent connection, but newly created parallel
connections will be forced through the same authentication
handshake in the rfc4559 model, where the authentication is
strictly bound to the persistent communication channel.

If a session re-authentication token is issued (e.g. by the application
layer as a result of a successful rfc4559 authentication) and sent
to the client as a non-persistent cookie, then the client may
re-use this cookie even on parallel and later communication channels.

The drawback of the "session re-authentication token" is that it
is something like a lifetime-limited disclosing authentication,
and it could be stolen an replayed.  Checking the client-IP-Address
on new requests does not necessarily help (middle-boxes!),
might inconvenience clients in certain mobile environments even
without middle-boxes.  Checking the SSL/TLS session id might
not be possible (again: SSL-terminating middle-boxes, like
reverse proxies, SSL-accellerators, load-balancers).


HTTP and Web-Browsers are a pretty bad foundation for building
stateful (state-heavy) client-server applications.  However, it will
likely take some more years before top-level management accepts
this, gets off the hype and agrees to go back to dedicated
persistent communication channels and real interactive communication
protocols instead of HTTP.


The better the band-aids that we produce for the existing flawed
approaches, the longer will our pain and suffering last.  :-\


-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 14:48:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk4GK-0001yB-S0; Tue, 14 Nov 2006 14:48:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4GK-0001y6-0k
	for kitten@ietf.org; Tue, 14 Nov 2006 14:48:04 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4GI-0000fy-Jo
	for kitten@ietf.org; Tue, 14 Nov 2006 14:48:04 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id UAA13764;
	Tue, 14 Nov 2006 20:47:54 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611141947.UAA26421@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Tue, 14 Nov 2006 20:47:52 +0100 (MET)
In-Reply-To: <20061114121358.5cf55da4.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 14, 6 12:13:58 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> > When I checked the headers of the requests with HTTPwatch when
> > using negotiate between MSIE 6 and IIS, then the authentication
> > exchange (and www-authenticate headers) were only visible on
> > the first request of a new connection.
> 
> That's not what I see with IIS on Windows 2003 SBS. At no time does the
> client get a response without the request having a Negotiate token. I
> still have the capture if you'd like to see it.

I just retried -- my logs contain a single negotiate handshake in
the beginning (the html page), and everything else (all seperate
objects embedded in the page) are without, definitely!

In my case, the session was using SSL/TLS (properties says SSLv3 128-bit RC4).

> 
> I'm not advocating authenticating every request. I'm just trying to help
> out with the facts of the case which is that in at least my case every
> request is authenticated which suggests that "prohibitively expensive"
> is misleading. GSSAPI acceptor authentication is not *that* expensive
> since there's no network communication involved (provided the acceptor
> has loaded it's credential already).

When public key crypto is involved in the authentication, then the
performance impact is significant, similar to SSL full handshake vs.
SSL session resume from the cache.

On my machine, SSL session resume from the cache (entire resume handshake)
is 3 millisec, whereas the full SSL handshake is ~40 milliseconds.  On
slower machines (e.g. Unix RISC machines), the difference that I measure
is even higher.

An order of a magnitude is what *I* consider prohibitive.

> 
> It would be nice to curb redundant authentications but you do realize it
> could be tricky on top of HTTP. You're talking about associating state
> with a socket when most HTTP server implementations, Servlet containers,
> PHP scripts, etc only give you a *session* which is more abstract
> and not directly mapped to the client's socket. You would have to get
> the local port and put state in a map.
> 
> Note that if you have to put state in a map by port you could do that
> now with Negotiate auth so it's not clear to me what benifit this new
> mechanism would provide wrt redundant authentications.

As soon as you have to keep state on the backend, it is fairly easy
to create&use a session token that can be used for session re-authentication.


The server creates and issues that session re-authentication token,
so can make this token useful in many respects.


Look at the SSL session ID issued by an SSL/TLS server.  OpenSSL is
pretty dumb when creating SSL session IDs.  An SSL session ID is
32 Bytes long, so when the server creates a session ID, it might
be a good idea to make the session ID useful:

   - fill >=16 bytes with a cryptographically strong random number
     so that attackers can not guess SSL session IDs

   - use >= 8 bytes for a monotonically increasing integer so
     that (a) there will never be collisions on SSL session IDs
     and  (b) you get near-perfect hash values for 2^n hash lookup tables
              for free

and as a result, the server may become more efficient in SSL session
cache management by not having to perform a hash function and
not having to check the cache for a collision when creating a new
session ID. (This only applies to the server-side cache and session ID,
of course).


-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 14:58:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk4QF-0005eA-63; Tue, 14 Nov 2006 14:58:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4QE-0005dj-Lf
	for kitten@ietf.org; Tue, 14 Nov 2006 14:58:18 -0500
Received: from smtpde03.sap-ag.de ([155.56.68.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4QA-00026w-8n
	for kitten@ietf.org; Tue, 14 Nov 2006 14:58:16 -0500
Received: from sap-ag.de (smtpde03)
	by smtpde03.sap-ag.de (out) with ESMTP id UAA05334;
	Tue, 14 Nov 2006 20:57:45 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611141957.UAA26651@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Tue, 14 Nov 2006 20:57:45 +0100 (MET)
In-Reply-To: <20061114121358.5cf55da4.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 14, 6 12:13:58 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-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> I'm not advocating authenticating every request. I'm just trying to help
> out with the facts of the case which is that in at least my case every
> request is authenticated which suggests that "prohibitively expensive"
> is misleading. GSSAPI acceptor authentication is not *that* expensive
> since there's no network communication involved (provided the acceptor
> has loaded it's credential already).

The other issue that one should not forget: A lot of user authentication
systems have some kind of account lockout functionality, so the
combination of "authenticate every request" with "immediate pipelining
of 10 requests" may have quite negative consequences when there's
something wrong with the credentials (typo in password).  NTLM
is password-based, IAKERB might be, and so may be others.

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 15:10:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk4bq-0001kF-QU; Tue, 14 Nov 2006 15:10:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4bp-0001k9-OI
	for kitten@ietf.org; Tue, 14 Nov 2006 15:10:17 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4bo-0004Ct-G2
	for kitten@ietf.org; Tue, 14 Nov 2006 15:10:17 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id D684D42B6F;
	Tue, 14 Nov 2006 15:10:09 -0500 (EST)
Date: Tue, 14 Nov 2006 15:10:04 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061114151004.7f1b5d39.mba2000@ioplex.com>
In-Reply-To: <200611141920.UAA25038@uw1048.wdf.sap.corp>
References: <4EA1EE39-1F7F-438D-8E2A-2E9F65539948@osafoundation.org>
	<200611141920.UAA25038@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Session Token and Delegation (was Re: Please review: http gss
 authentication mech)
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Note that delegation could become a problem if session re-authentication
tokens are used. If a request wants to initiate auth with another tier
(e.g. a database) and use a delegated credential established in a previous
request you would need to save the delegated credential somewhere which
is a potential security hazard on an HTTP server (e.g. someone could
put something in their cgi-bin that impersonates someone else).

Mike

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 15:13:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk4en-0002Fn-Gq; Tue, 14 Nov 2006 15:13:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4em-0002Fd-L8
	for kitten@ietf.org; Tue, 14 Nov 2006 15:13:20 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4el-0004aV-CL
	for kitten@ietf.org; Tue, 14 Nov 2006 15:13:20 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id 5AA8C42B6F;
	Tue, 14 Nov 2006 15:13:15 -0500 (EST)
Date: Tue, 14 Nov 2006 15:13:13 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061114151313.02344b46.mba2000@ioplex.com>
In-Reply-To: <200611141920.UAA25038@uw1048.wdf.sap.corp>
References: <4EA1EE39-1F7F-438D-8E2A-2E9F65539948@osafoundation.org>
	<200611141920.UAA25038@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Preemptive Authentication by Clients (was Re: Please review: http
 gss authentication mech)
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Note that there is a different place where considerable performance
improvements could be attained.

If clients know, based on previous experience with the server, that the
server will require authentication they could preemtively submit a token
and eliminate one round trip per authenticated request. So each request
would still be authenticated but eliminating redundant requests would
improve performance more than eliminating redundant authentications
since the former involves relatively slow network communication.

IE actually sort of does this now. If you do a POST request and IE
has previously determined that authentication is required, it will
preemptively submit an authentication token (it may also, leave out the
POST data but it may only do this for NTLM, I don't recall if the POST
data is left out if a pre-emptive Kerberos token is sent).

There is one problem with IE's implementation of this preemptive behavior
however. Once it determines that the server requires authentication it
preemtively authenticates for ALL paths. This is undesireable if you
only want to protect part of your content.

Therefore, it would be desireable for the response token to include a
flag that indicates authentication was not necessary. In this way clients
could preemtively authenticate but then stop when told it was unnecessary.

Mike

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 15:17:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk4ix-0005N9-Aw; Tue, 14 Nov 2006 15:17:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4iw-0005Mx-14
	for kitten@ietf.org; Tue, 14 Nov 2006 15:17:38 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4iu-0005K6-Ll
	for kitten@ietf.org; Tue, 14 Nov 2006 15:17:38 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id VAA21566;
	Tue, 14 Nov 2006 21:17:31 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611142017.VAA27762@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Tue, 14 Nov 2006 21:17:31 +0100 (MET)
In-Reply-To: <20061114151004.7f1b5d39.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 14, 6 03:10:04 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Session Token and Delegation (was Re: Please review: http gss
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> Note that delegation could become a problem if session re-authentication
> tokens are used. If a request wants to initiate auth with another tier
> (e.g. a database) and use a delegated credential established in a previous
> request you would need to save the delegated credential somewhere which
> is a potential security hazard on an HTTP server (e.g. someone could
> put something in their cgi-bin that impersonates someone else).

That is a problem of credential-delegation within a gss-api authentication.
A session-reauthentication token is nothing more like a session ID
that contains enough cryptographic random bits to make it non-predictable.

Whether the application on the server side attaches a gssapi context
handle or a delegated credential to that server side state is
entirely independent from the use of a session reauthentication token.

*I* always thought that credential delegation and impersonation are
dangerously flawed concepts, and in the last 10 years I have not
heard convincing arguments for their use/existence.

(I consider credential forwarding on explicit request of the user
 something entirely different than credential delegation).

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 17:15:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk6Yu-0004SY-Ml; Tue, 14 Nov 2006 17:15:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6Yt-0004Qh-P6
	for kitten@ietf.org; Tue, 14 Nov 2006 17:15:23 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6Yr-0006ho-CO
	for kitten@ietf.org; Tue, 14 Nov 2006 17:15:23 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id 8721842B6F;
	Tue, 14 Nov 2006 17:15:04 -0500 (EST)
Date: Tue, 14 Nov 2006 17:15:02 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061114171502.21a629ff.mba2000@ioplex.com>
In-Reply-To: <200611141947.UAA26421@uw1048.wdf.sap.corp>
References: <20061114121358.5cf55da4.mba2000@ioplex.com>
	<200611141947.UAA26421@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, 14 Nov 2006 20:47:52 +0100 (MET)
Martin Rex  wrote:

> On my machine, SSL session resume from the cache (entire resume handshake)
> is 3 millisec, whereas the full SSL handshake is ~40 milliseconds.  On
> slower machines (e.g. Unix RISC machines), the difference that I measure
> is even higher.
> 
> An order of a magnitude is what *I* consider prohibitive.

Ok, well we're not talking about SSL. We're talking about decrypting
a token with a symmetric cipher. The extra round trip HTTP clients go
through to determine that the server wants auth in the first place takes
an order of magnitude longer than decypting a Kerberos ticket.

> > Note that if you have to put state in a map by port you could do that
> > now with Negotiate auth so it's not clear to me what benifit this new
> > mechanism would provide wrt redundant authentications.
> 
> As soon as you have to keep state on the backend, it is fairly easy
> to create&use a session token that can be used for session re-authentication.

There's one major problem with using sessions to store authentication
data. You're assuming that the data is valid in all processes sharing the
session. There can be multiple processes on different servers. Clusers
for example may try to serialize sessions which would invalidate things
like Kerberos tickets. Browsers frequently open multiple sockets that
will share a session but not the same httpd worker process.

Stateful authentication over HTTP is tricky buisness. Basically you
have to assume a default posture of failure. Meaning if ANYTHING is
not optimal for state to be valid just return 401 and make the client
reauthenticate. If the token is deserialized on a different node, 401. If
the client doesn't submit a token and there's no session token, 401. If
the session token is old, 401. If you get a pipeline of unauthenticated
requests, 401 every one of them.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 17:23:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk6gf-0000Jh-SJ; Tue, 14 Nov 2006 17:23:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6gf-0000Jc-7c
	for kitten@ietf.org; Tue, 14 Nov 2006 17:23:25 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6gd-0000cr-Um
	for kitten@ietf.org; Tue, 14 Nov 2006 17:23:25 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id 9F03F42B6F;
	Tue, 14 Nov 2006 17:23:19 -0500 (EST)
Date: Tue, 14 Nov 2006 17:23:17 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061114172317.07c45918.mba2000@ioplex.com>
In-Reply-To: <200611141957.UAA26651@uw1048.wdf.sap.corp>
References: <20061114121358.5cf55da4.mba2000@ioplex.com>
	<200611141957.UAA26651@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, 14 Nov 2006 20:57:45 +0100 (MET)
Martin Rex  wrote:

> Michael B Allen wrote:
> > 
> > I'm not advocating authenticating every request. I'm just trying to help
> > out with the facts of the case which is that in at least my case every
> > request is authenticated which suggests that "prohibitively expensive"
> > is misleading. GSSAPI acceptor authentication is not *that* expensive
> > since there's no network communication involved (provided the acceptor
> > has loaded it's credential already).
> 
> The other issue that one should not forget: A lot of user authentication
> systems have some kind of account lockout functionality, so the
> combination of "authenticate every request" with "immediate pipelining
> of 10 requests" may have quite negative consequences when there's
> something wrong with the credentials (typo in password).  NTLM
> is password-based, IAKERB might be, and so may be others.

Oh yes, I know about this very well from doing the JCIFS NTLM Servlet
Filter. NTLM requires a stateful exchange which means you MUST use the
session in which case you can trap and dispose of redundant authentication
attempts good or bad.

Of course Kerberos doesn't have this problem.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 14 19:13:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk8Oj-0006tt-5d; Tue, 14 Nov 2006 19:13:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk8Oi-0006tn-6Q
	for kitten@ietf.org; Tue, 14 Nov 2006 19:13:00 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk8Of-0005NJ-O4
	for kitten@ietf.org; Tue, 14 Nov 2006 19:13:00 -0500
Received: from sap-ag.de (smtpde01)
	by smtpde01.sap-ag.de (out) with ESMTP id BAA19966;
	Wed, 15 Nov 2006 01:12:46 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611150012.BAA10283@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Wed, 15 Nov 2006 01:12:46 +0100 (MET)
In-Reply-To: <20061114171502.21a629ff.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 14, 6 05:15: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-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> On Tue, 14 Nov 2006 20:47:52 +0100 (MET)
> Martin Rex  wrote:
> 
> > On my machine, SSL session resume from the cache (entire resume handshake)
> > is 3 millisec, whereas the full SSL handshake is ~40 milliseconds.  On
> > slower machines (e.g. Unix RISC machines), the difference that I measure
> > is even higher.
> > 
> > An order of a magnitude is what *I* consider prohibitive.
> 
> Ok, well we're not talking about SSL. We're talking about decrypting
> a token with a symmetric cipher. The extra round trip HTTP clients go
> through to determine that the server wants auth in the first place takes
> an order of magnitude longer than decypting a Kerberos ticket.

I'm sorry, I thought we were also talking about how the IETF would use
SPNEGO to negotiate gss-api mechanisms, and that would include mechanisms
using X.509 certificates for authentication.

> 
> > > Note that if you have to put state in a map by port you could do that
> > > now with Negotiate auth so it's not clear to me what benifit this new
> > > mechanism would provide wrt redundant authentications.
> > 
> > As soon as you have to keep state on the backend, it is fairly easy
> > to create&use a session token that can be used for session re-authentication.
> 
> There's one major problem with using sessions to store authentication
> data. You're assuming that the data is valid in all processes sharing the
> session. There can be multiple processes on different servers. Clusers
> for example may try to serialize sessions which would invalidate things
> like Kerberos tickets. Browsers frequently open multiple sockets that
> will share a session but not the same httpd worker process.

Well, no, I'm not making any assumptions.

Installations where the backend state is so tiny that moving it
around between different backend servers is an option scale nowhere.
A scheme that might get used here to "share" an authentication
within a server farm might be a keyed hash, like HMAC, that covers
a shared secret in the server farm to reauthenticate user sessions.

The server farms that I'm dealing with produce backend state in
the megabyte range, and you don't want to move that around with
every little gif icon on every of your pages among backend servers.

Moving the state might be an issue for high-availability scenarios,
but again, you wouldn't move it around for no reason, and a
re-authentication requirement in case of a move would be OK.


> 
> Stateful authentication over HTTP is tricky buisness. Basically you
> have to assume a default posture of failure. Meaning if ANYTHING is
> not optimal for state to be valid just return 401 and make the client
> reauthenticate. If the token is deserialized on a different node, 401. If
> the client doesn't submit a token and there's no session token, 401. If
> the session token is old, 401. If you get a pipeline of unauthenticated
> requests, 401 every one of them.

This is why I'm OK with 2-token Kerberos authentication with rfc4559.  :)

If you do have backend state, but need a server farm to accomodate
the load, then you have two options, either move the state around,
or glue the sessions to the backend servers which are holding the
state.

For _very_ lightweight sessions, the first approach may be OK, 
although it puts a significant burden on the apps in that they have
to completely serialize there state for transfer to other servers.
For heavyweight state sessions, this option simply doesn't exist.

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 15 03:37:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkGH1-0007wI-7r; Wed, 15 Nov 2006 03:37:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkGGz-0007s4-6G
	for kitten@ietf.org; Wed, 15 Nov 2006 03:37:33 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4qa-0006QK-Mo
	for kitten@ietf.org; Tue, 14 Nov 2006 15:25:34 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 8D4343BE42;
	Tue, 14 Nov 2006 21:25:17 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 11673-01-25; Tue, 14 Nov 2006 21:25:17 +0100 (CET)
Received: from [83.178.9.219] (m83-178-9-219.cust.tele2.se [83.178.9.219])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id 3214C3BE30;
	Tue, 14 Nov 2006 21:25:16 +0100 (CET)
Message-ID: <455A262A.2060109@it.su.se>
Date: Tue, 14 Nov 2006 21:25:14 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Michael B Allen 
References: <4EA1EE39-1F7F-438D-8E2A-2E9F65539948@osafoundation.org>	<200611141920.UAA25038@uw1048.wdf.sap.corp>
	<20061114151004.7f1b5d39.mba2000@ioplex.com>
In-Reply-To: <20061114151004.7f1b5d39.mba2000@ioplex.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.65 tagged_above=-99 required=7 tests=[AWL=0.015,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Session Token and Delegation (was Re: Please review: http gss
 authentication mech)
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> Note that delegation could become a problem if session re-authentication
> tokens are used. If a request wants to initiate auth with another tier
> (e.g. a database) and use a delegated credential established in a previous
> request you would need to save the delegated credential somewhere which
> is a potential security hazard on an HTTP server (e.g. someone could
> put something in their cgi-bin that impersonates someone else).
>
> Mike
>
>   
I'll make a note of that for the security considerations section.

       Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 15 15:58:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkRpS-0000uT-GX; Wed, 15 Nov 2006 15:57:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRpQ-0000uJ-Le
	for kitten@ietf.org; Wed, 15 Nov 2006 15:57:52 -0500
Received: from smtpde03.sap-ag.de ([155.56.68.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRpP-0003XA-7r
	for kitten@ietf.org; Wed, 15 Nov 2006 15:57:52 -0500
Received: from sap-ag.de (smtpde03)
	by smtpde03.sap-ag.de (out) with ESMTP id VAA04124;
	Wed, 15 Nov 2006 21:57:33 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611152057.VAA09185@uw1048.wdf.sap.corp>
To: martin.rex@sap.com
Date: Wed, 15 Nov 2006 21:57:33 +0100 (MET)
In-Reply-To: <200611141947.UAA26421@uw1048.wdf.sap.corp> from "Martin Rex" at
	Nov 14, 6 08:47:52 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-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Open mouth, insert foot...

Michael, you were right in some way about negotiate re-doing authentication
all the time.

Martin Rex wrote:
> 
> Michael B Allen wrote:
> > 
> > > When I checked the headers of the requests with HTTPwatch when
> > > using negotiate between MSIE 6 and IIS, then the authentication
> > > exchange (and www-authenticate headers) were only visible on
> > > the first request of a new connection.
> > 
> > That's not what I see with IIS on Windows 2003 SBS. At no time does the
> > client get a response without the request having a Negotiate token. I
> > still have the capture if you'd like to see it.
> 
> I just retried -- my logs contain a single negotiate handshake in
> the beginning (the html page), and everything else (all seperate
> objects embedded in the page) are without, definitely!
> 
> In my case, the session was using SSL/TLS (properties says SSLv3 128-bit RC4).

Well, I did try, but with an IIS that was configured by our local
microsoft experts quite a long time ago and later upgraded (now W2K3 Server).

That particular IIS (to which I don't have adminstrative access)
returns 401 www-authenticate: for both negotiate and ntlm on HTTP:1080,
and my MSIE 6.0 performs negotiate (Kerberos).  As a result I
get back a redirect to the same machine, but https:// (aka port 443)
and trying to get that page results in a 401 www-authenticate for
NTLM only, to which my browser agrees and then all remaining embedded
objects of this servers homepage (50 objects: .js/.css/.jpg/.gif/.wmf/.htc)
are loaded with only one additional 401 -- and that happens at the
beginning of a secondary communication channel (new local port)
according to HTTPwatch.


I just tried to confirm my findings with negotiate/Kerberos instead
of NTLM on a WinXP 64-bit machine that which I can administrate.

Negotiate/Kerberos was fairly easy to activate, but the resulting
HTTPwatch logs were devastating!  It appears that MSIE does blind
pipelining (ouch!) of requests for the embedded object, and IIS forces
reauthentication of every single request with a 401 (ouch ouch!).

It seems that MSIE is not expecting IIS to misbehave in such a stupid
fashion, because MSIE does _not_ send the negotiate token unless the
server asks for it with 401 (which it does, each and every time).


I'm really confused by what I see.
For the NTLM-authentication, the IIS server seems to be holding the state
(and the impersonation token) as long as the network connection persists,
while for negotiate/kerberos, this doesn't work.
MSIE does not seem to expect this.  So when using negotiate/kerberos
with HTTPS, one does not only get the overhead of a full gssapi context
establishment for each and every single object, but also the 401&retry
exchange.  The additional roundtrips hit on the performance, and
the additional gssapi tokens consume network bandwidth.

Here is the result comparing the overhead when retrieving a 216 byte gif:

  NTLM-authenication MSIE6->IIS6:
   request             reply
   GET (315 bytes)     200 (465 bytes)

  Negotiate/Kerberos authentication MSIE6->IIS6:
   GET (315 bytes)     401 (1872 bytes)
   GET (4070 bytes)    200 (715 bytes)

So the performance hit that the server takes by using negotiate/Kerberos
instead of NTLM is: 1 additional network roundtrip, 10x increase in
the total request size, 5x increase in the total reply size,
plus the entire GSS-API processing overhead.

Somehow, this doesn't look like good engineering to me.

At least, rfc4559 doesn't seem to require implementing this in such
an inefficient fashion.

-Martin


_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 15 16:47:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkSb2-0006Sq-TO; Wed, 15 Nov 2006 16:47:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSb1-0006Sc-HE
	for kitten@ietf.org; Wed, 15 Nov 2006 16:47:03 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSaz-0004lL-1D
	for kitten@ietf.org; Wed, 15 Nov 2006 16:47:03 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id A0CC542B61;
	Wed, 15 Nov 2006 16:46:52 -0500 (EST)
Date: Wed, 15 Nov 2006 16:46:35 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061115164635.29d6befc.mba2000@ioplex.com>
In-Reply-To: <200611152057.VAA09185@uw1048.wdf.sap.corp>
References: <200611141947.UAA26421@uw1048.wdf.sap.corp>
	<200611152057.VAA09185@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Wed, 15 Nov 2006 21:57:33 +0100 (MET)
Martin Rex  wrote:

> For the NTLM-authentication, the IIS server seems to be holding the state
> (and the impersonation token) as long as the network connection persists,
> while for negotiate/kerberos, this doesn't work.

Interesting. I thought IIS re-auth'd every request for NTLM too but I've
confirmed your findings - IIS does cache NTLM authentications per socket.

All of this is probably deliberate though. Consider the difference
in overhead.

Negotiate/Kerberos:
  Two round trips between the same nodes and a ticket decryption. That's
  not that bad.

NTLM/NTLMSSP or Negotiate/NTLMSSP:
  Three round trips and a DCERPC over SMB named pipe password check
  with the domain controller which is a different node probably on an
  entirely different subnet.

So authenticating every request with NTLM is indeed "prohibitively
expensive" whereas I would say the Negotiate/Kerberos case is not
(people do it all the time).

Also, NTLM doesn't support delegation and doesn't contain authorization
data so storing NTLM state in the HTTP session doesn't have some
of the issues that Kerberos would. Actually the results of an NTLM
authentication is pretty much useless (you don't even have a signing
key if you're doing pass-through style auth like JCIFS) so there's no
point in saving anything at all - you just associate "authenticated=true"
with the socket (or I guess the session) or something that just indicates
the client was already authenticated.

I still think the best performance improvement would be acquired on
the client side. When a client (e.g. Firefox) encounters a server that
requires authentication, it set's a flag associated with that socket
(I think IE uses the hostname/port or IP/port for HTTP POST request
preemption I mentioned yesterday) indicating that subsequent requests
should preemptively include an initial token. If the server responds
200 OK and no WWW-Authenticate header is sent, the client can clear the
said flag and go back to assuming authentication is no required (this
is important for browsing from protected to non-protected content on the
same server). Note that even if mutual is not requested the server will
respond with a WWW-Authenticate token that is largely empty (at least
with Negotiate it does, old-school NTLM is on the rocks).

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Wed Nov 15 19:16:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkUv8-0008F0-F1; Wed, 15 Nov 2006 19:15:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUv7-0008Ev-3b
	for kitten@ietf.org; Wed, 15 Nov 2006 19:15:57 -0500
Received: from smtpde03.sap-ag.de ([155.56.68.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkUv5-0000ry-Mt
	for kitten@ietf.org; Wed, 15 Nov 2006 19:15:57 -0500
Received: from sap-ag.de (smtpde03)
	by smtpde03.sap-ag.de (out) with ESMTP id BAA03283;
	Thu, 16 Nov 2006 01:15:46 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611160015.BAA19976@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Thu, 16 Nov 2006 01:15:45 +0100 (MET)
In-Reply-To: <20061115164635.29d6befc.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 15, 6 04:46:35 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> Interesting. I thought IIS re-auth'd every request for NTLM too but I've
> confirmed your findings - IIS does cache NTLM authentications per socket.
> 
> NTLM/NTLMSSP or Negotiate/NTLMSSP:
>   Three round trips and a DCERPC over SMB named pipe password check
>   with the domain controller which is a different node probably on an
>   entirely different subnet.
> 
> So authenticating every request with NTLM is indeed "prohibitively
> expensive"

It's true that the NTLM authentication results in significantly
higher overhead on the server side because it involves a round trip
to a domain controller.

> 
>             whereas I would say the Negotiate/Kerberos case is not
> (people do it all the time).

I still do not agree to this.  the Kerberos overhead (and the
much larger token size) is not marginal.

> 
> Also, NTLM doesn't support delegation and doesn't contain authorization
> data so storing NTLM state in the HTTP session doesn't have some
> of the issues that Kerberos would. Actually the results of an NTLM
> authentication is pretty much useless (you don't even have a signing
> key if you're doing pass-through style auth like JCIFS) so there's no
> point in saving anything at all - you just associate "authenticated=true"
> with the socket (or I guess the session) or something that just indicates
> the client was already authenticated.

NTLM and Kerberos both support impersonation, which is necessary for
using the Posix-style Access Control model from the TCB instead of
doing all manually at the application level.  Impersonation is much
more than a simple flag, it might provide adminstrative privileges
to an originally very restricted service account.

NTLM doesn't provide credentials and therefore can not be used to
further authenticate to remote resources, aka. delegation.
(IIRC, delegation is available for machine-local NTLM authentication,
but that isn't a real use case for Web-Servers...).
However, delegation in Kerberos is not enabled by default (and
should never be, for security reasons).  Kerberos delegation is currently
implemented by forwarding the TGT, and the resulting initial context
token isn't exactly small.

I would like it if delegation was the default so that any fellow
developer setting up an IIS on his workstation could harvest TGTs
from every MSIE that connected, e.g. by using Outlook to send
Emails with IMG SRC urls to furnish their sig with a neat picture...


-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 16 16:41:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkoyW-0003P1-Oi; Thu, 16 Nov 2006 16:40:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkoyU-0003Ow-OJ
	for kitten@ietf.org; Thu, 16 Nov 2006 16:40:46 -0500
Received: from nwkea-mail-4.sun.com ([192.18.42.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkoyQ-00043T-AY
	for kitten@ietf.org; Thu, 16 Nov 2006 16:40:46 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAGLef0p021898
	for ; Thu, 16 Nov 2006 13:40:41 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAGLeepX020226
	for ; Thu, 16 Nov 2006 14:40:40 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAGLec9r004842; Thu, 16 Nov 2006 15:40:39 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAGLebQA004841; 
	Thu, 16 Nov 2006 15:40:37 -0600 (CST)
Date: Thu, 16 Nov 2006 15:40:37 -0600
From: Nicolas Williams 
To: Tim Alsop 
Message-ID: <20061116214037.GT25646@binky.Central.Sun.COM>
Mail-Followup-To: Tim Alsop ,
	RL 'Bob' Morgan ,
	Leif Johansson , Kitten ,
	Lisa Dusseault 
References: 
	<0D8F2EFD3A10E24DAEEA48EA6DA07D30299548@postman-pat.csafe.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299548@postman-pat.csafe.local>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Fri, Nov 10, 2006 at 04:23:27PM +0000, Tim Alsop wrote:
> Since the draft for SASL-HTTP is not yet an RFC, is there any reason why
> changes cannot be proposed to allow it to support non-persistent
> connections ?

The GSS-API already has a notion of exported security context.  SASL
does not.

> It just seems strange to me that this draft has undergone a lot of work
> by many people, and because of some functionality that is missing from
> it (e.g. support for non-persistent connections) it is being suggested
> that a new draft should be progressed instead. Is this the way that
> standards are normally progressed ?

It's who shows up and who does the work.  Attending the conferences
helps because the bandwidth between attendees goes way up as compared to
the rest of the year.  So when we had our various bar BoFs and the DIX
BoF we quickly jettisoned SASL -- noone was there to defend it from this
and other objections (e.g., lack of channel binding support[*]).  The DIX
BoF could have been attended via jabber too.

Now, you can push the HTTP-SASL thing now, and get that going.

[*]  The SASL WG is working on channel binding, but the SASL notion of
     channel binding is subtly different from the GSS-API equivalent,
     different in a way that we don't want in this case.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 16 16:50:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gkp7N-0005hM-5H; Thu, 16 Nov 2006 16:49:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkp7L-0005dP-F6
	for kitten@ietf.org; Thu, 16 Nov 2006 16:49:55 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkp7K-0005Tu-3w
	for kitten@ietf.org; Thu, 16 Nov 2006 16:49:55 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAGLnrtI008080
	for ; Thu, 16 Nov 2006 13:49:53 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAGLnqH1023988
	for ; Thu, 16 Nov 2006 14:49:53 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAGLnqYY004855; Thu, 16 Nov 2006 15:49:52 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAGLnqwg004854; 
	Thu, 16 Nov 2006 15:49:52 -0600 (CST)
Date: Thu, 16 Nov 2006 15:49:52 -0600
From: Nicolas Williams 
To: Tim Alsop 
Message-ID: <20061116214952.GU25646@binky.Central.Sun.COM>
Mail-Followup-To: Tim Alsop ,
	Leif Johansson , Kitten ,
	Lisa Dusseault 
References: <4553B51E.9080006@it.su.se>
	<0D8F2EFD3A10E24DAEEA48EA6DA07D30299547@postman-pat.csafe.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299547@postman-pat.csafe.local>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Fri, Nov 10, 2006 at 04:19:42PM +0000, Tim Alsop wrote:
> > I am under the impression that the proposed SASL mechanism doesn't
> support channel
> > bindings, partially because channel bindings have been a notoriously
> difficult problem to get
> > right in SASL space. Personally I din't see the value of adding the
> extra layer of glue.
> 
> My understanding is that, if SASL is using GSS/Kerberos to protect HTTP
> communications, then GSS channel bindings can be used, so SASL does not
> need to have direct support for channel bindings. This is an advantage
> of using a multi-layered architecture.

Your understanding is wrong.

First of all, there's an API issue -- which, since the IETF does not
standardize a SASL API you might hand wave away.

Second, there's a semantic issue, and this is far more important.
Rather than re-hash this here you might want to look at the SASL WG
mailing list archives and the gs2 I-D (draft-ietf-sasl-gs2) and its
evolution.  Then you'll understand why GSS channel bindings in the SASL
"GSSAPI" mechanism are generally not usable.

Third, we need channel binding to TLS to avoid re-doing the GSS (or
SASL) authentication over and over, and so what's the point of using
SASL if the only SASL mechs that would support channel binding were the
GSS-based ones (using SASL/gs2)?  And if channel binding support is
added to SASL MD5-DIGEST, with the same semantics, can't we also add a
GSS-API mechanism that uses the same credentials as MD5-DIGEST?  And why
isn't HTTP MD5-DIGEST good enough anyways?  And what other SASL
mechanisms did you want to use with this?

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 16 17:01:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkpIo-0005jq-Cm; Thu, 16 Nov 2006 17:01:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpIm-0005jh-VR
	for kitten@ietf.org; Thu, 16 Nov 2006 17:01:44 -0500
Received: from cluster-b.mailcontrol.com ([217.68.146.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpIk-00072h-HS
	for kitten@ietf.org; Thu, 16 Nov 2006 17:01:44 -0500
Received: from rly19b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly19b.srv.mailcontrol.com (MailControl) with ESMTP id
	kAGM1SZh023420
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 16 Nov 2006 22:01:31 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[212.158.48.250])
	by rly19b.srv.mailcontrol.com (MailControl) id kAGM1JG5023063
	for kitten@ietf.org; Thu, 16 Nov 2006 22:01:19 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly19b-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kAGM1CVR022865; Thu, 16 Nov 2006 22:01:19 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 16 Nov 2006 22:01:10 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299597@postman-pat.csafe.local>
In-Reply-To: <20061116214037.GT25646@binky.Central.Sun.COM>
From: "Tim Alsop" 
To: "Nicolas Williams" 
X-Scanned-By: MailControl A-07-06-70 (www.mailcontrol.com) on 10.66.1.129
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: Kitten , Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Nico,

Thankyou for explaining the background to SASL-HTTP, and why it has died
... I hadn't seen any mention of it for a few years, but I was under the
impression (wrongly) that there was a rough concensus that SASL-HTTP was
the preferred replacement for the negotiate approach, as used in IE,
Mozilla, IIS, Apache etc. Clearly this is not the case anymore ...

I don't want you to think I have any preferrences, either way - I don't.
If anything, I prefer simpler architectures, as they are less likely to
go wrong and easier to code and debug. So, adding an extra protocol
layer, when it is not absolutely necessary, just makes the solution more
complex than is needed. Taking this into account, it seems that using
HTTP/GSS, instead of HTTP/SASL/GSS is perhaps a better replacement for
the netogitate approach. Obviously, I am over simplifying the
requirements by saying this, and there is a lot more work to be done to
progress the HTTP/GSS approach, and this might also die in the same way
as SASL-HTTP :-)

Thanks again,
Tim

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20
Sent: 16 November 2006 21:41
To: Tim Alsop
Cc: RL 'Bob' Morgan; Leif Johansson; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech

On Fri, Nov 10, 2006 at 04:23:27PM +0000, Tim Alsop wrote:
> Since the draft for SASL-HTTP is not yet an RFC, is there any reason
why
> changes cannot be proposed to allow it to support non-persistent
> connections ?

The GSS-API already has a notion of exported security context.  SASL
does not.

> It just seems strange to me that this draft has undergone a lot of
work
> by many people, and because of some functionality that is missing from
> it (e.g. support for non-persistent connections) it is being suggested
> that a new draft should be progressed instead. Is this the way that
> standards are normally progressed ?

It's who shows up and who does the work.  Attending the conferences
helps because the bandwidth between attendees goes way up as compared to
the rest of the year.  So when we had our various bar BoFs and the DIX
BoF we quickly jettisoned SASL -- noone was there to defend it from this
and other objections (e.g., lack of channel binding support[*]).  The
DIX
BoF could have been attended via jabber too.

Now, you can push the HTTP-SASL thing now, and get that going.

[*]  The SASL WG is working on channel binding, but the SASL notion of
     channel binding is subtly different from the GSS-API equivalent,
     different in a way that we don't want in this case.

Nico
--=20

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 16 17:03:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkpKR-0006DU-3N; Thu, 16 Nov 2006 17:03:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpKP-0006D3-Sm
	for kitten@ietf.org; Thu, 16 Nov 2006 17:03:25 -0500
Received: from cluster-b.mailcontrol.com ([217.68.146.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpKO-0007MN-Fd
	for kitten@ietf.org; Thu, 16 Nov 2006 17:03:25 -0500
Received: from rly37b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly37b.srv.mailcontrol.com (MailControl) with ESMTP id
	kAGM3JI0001642
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Thu, 16 Nov 2006 22:03:21 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[212.158.48.250])
	by rly37b.srv.mailcontrol.com (MailControl) id kAGM2wZ8000786
	for kitten@ietf.org; Thu, 16 Nov 2006 22:02:58 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly37b-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kAGM2rBr000613; Thu, 16 Nov 2006 22:02:58 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 16 Nov 2006 22:02:52 -0000
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299598@postman-pat.csafe.local>
In-Reply-To: <20061116214952.GU25646@binky.Central.Sun.COM>
From: "Tim Alsop" 
To: "Nicolas Williams" 
X-Scanned-By: MailControl A-07-06-75 (www.mailcontrol.com) on 10.66.1.147
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: Kitten , Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Nico,

Thankyou for correcting me, on my assumption related to channel
bindings.

Regards,
Tim=20

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20
Sent: 16 November 2006 21:50
To: Tim Alsop
Cc: Leif Johansson; Kitten; Lisa Dusseault
Subject: Re: Please review: http gss authentication mech

On Fri, Nov 10, 2006 at 04:19:42PM +0000, Tim Alsop wrote:
> > I am under the impression that the proposed SASL mechanism doesn't
> support channel
> > bindings, partially because channel bindings have been a notoriously
> difficult problem to get
> > right in SASL space. Personally I din't see the value of adding the
> extra layer of glue.
>=20
> My understanding is that, if SASL is using GSS/Kerberos to protect
HTTP
> communications, then GSS channel bindings can be used, so SASL does
not
> need to have direct support for channel bindings. This is an advantage
> of using a multi-layered architecture.

Your understanding is wrong.

First of all, there's an API issue -- which, since the IETF does not
standardize a SASL API you might hand wave away.

Second, there's a semantic issue, and this is far more important.
Rather than re-hash this here you might want to look at the SASL WG
mailing list archives and the gs2 I-D (draft-ietf-sasl-gs2) and its
evolution.  Then you'll understand why GSS channel bindings in the SASL
"GSSAPI" mechanism are generally not usable.

Third, we need channel binding to TLS to avoid re-doing the GSS (or
SASL) authentication over and over, and so what's the point of using
SASL if the only SASL mechs that would support channel binding were the
GSS-based ones (using SASL/gs2)?  And if channel binding support is
added to SASL MD5-DIGEST, with the same semantics, can't we also add a
GSS-API mechanism that uses the same credentials as MD5-DIGEST?  And why
isn't HTTP MD5-DIGEST good enough anyways?  And what other SASL
mechanisms did you want to use with this?

Nico
--=20

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 10:54:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl62r-0007Ft-Cq; Fri, 17 Nov 2006 10:54:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl62q-0007Fb-77
	for kitten@ietf.org; Fri, 17 Nov 2006 10:54:24 -0500
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl62k-0005ON-R4
	for kitten@ietf.org; Fri, 17 Nov 2006 10:54:24 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHFsHj4013789
	for ; Fri, 17 Nov 2006 08:54:17 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHFsGCc028033
	for ; Fri, 17 Nov 2006 08:54:17 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHFsFsc005117; Fri, 17 Nov 2006 09:54:15 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHFsEXa005116; 
	Fri, 17 Nov 2006 09:54:14 -0600 (CST)
Date: Fri, 17 Nov 2006 09:54:14 -0600
From: Nicolas Williams 
To: Tim Alsop 
Message-ID: <20061117155413.GX25646@binky.Central.Sun.COM>
Mail-Followup-To: Tim Alsop ,
	RL 'Bob' Morgan ,
	Leif Johansson , Kitten ,
	Lisa Dusseault 
References: <20061116214037.GT25646@binky.Central.Sun.COM>
	<0D8F2EFD3A10E24DAEEA48EA6DA07D30299597@postman-pat.csafe.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D30299597@postman-pat.csafe.local>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Thu, Nov 16, 2006 at 10:01:10PM +0000, Tim Alsop wrote:
> ... I hadn't seen any mention of it for a few years, but I was under the
> impression (wrongly) that there was a rough concensus that SASL-HTTP was
> the preferred replacement for the negotiate approach, as used in IE,
> Mozilla, IIS, Apache etc. Clearly this is not the case anymore ...

It may have been that there was consensus for it in some circles...

When I have discussed HTTP authentication improvements with others SASL
has come up, but usually its problems led to us discarding it.

> I don't want you to think I have any preferrences, either way - I don't.

It's OK to have preferences!

> If anything, I prefer simpler architectures, as they are less likely to
> go wrong and easier to code and debug. So, adding an extra protocol
> layer, when it is not absolutely necessary, just makes the solution more
> complex than is needed. Taking this into account, it seems that using
> HTTP/GSS, instead of HTTP/SASL/GSS is perhaps a better replacement for
> the netogitate approach. Obviously, I am over simplifying the
> requirements by saying this, and there is a lot more work to be done to
> progress the HTTP/GSS approach, and this might also die in the same way
> as SASL-HTTP :-)

So, if SASL didn't have the problems we discussed, or if we had the
energy to fix them, and if the non-GSS SASL mechanisms were highly
desirable and we did not have the energy to specify/implement GSS
equivalents, then SASL would be the better solution because it would
have more mechanisms available to it than the GSS-API.

So it's quite reasonable to see HTTP-SASL as potentially better than
HTTP-GSS.  But in the end I think it's hard to conclude anything other
than that there are no SASL non-GSS mechanisms that we really want to
use in the HTTP + TLS channel binding scenario[*].  It's also easy to
conclude that it's less work to specify HTTP-GSS than to deal with the
SASL issues.

[*] Save DIGEST-MD5, and that has an HTTP binding anyways, and it's fast
    enough that maybe we don't ever care, and we can always specify a
    GSS-API mechanism based on it with little effort.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 11:10:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl6Hr-0000Oi-FZ; Fri, 17 Nov 2006 11:09:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6Hq-0000OS-LI
	for kitten@ietf.org; Fri, 17 Nov 2006 11:09:54 -0500
Received: from cluster-b.mailcontrol.com ([217.68.146.190])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6Hl-0007Er-FC
	for kitten@ietf.org; Fri, 17 Nov 2006 11:09:54 -0500
Received: from rly26b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1])
	by rly26b.srv.mailcontrol.com (MailControl) with ESMTP id
	kAHG9Kfl003385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for ; Fri, 17 Nov 2006 16:09:41 GMT
Received: from submission.mailcontrol.com (submission.mailcontrol.com
	[86.111.216.190])
	by rly26b.srv.mailcontrol.com (MailControl) id kAHG97P1003017
	for kitten@ietf.org; Fri, 17 Nov 2006 16:09:07 GMT
Received: from cybersafe.ltd.uk (dsl-212-23-30-205.zen.co.uk [212.23.30.205])
	by rly26b-eth0.srv.mailcontrol.com (envelope-sender
	Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id
	kAHG8qGh002506; Fri, 17 Nov 2006 16:09:07 +0000 (GMT)
Date: Fri, 17 Nov 2006 16:08:54 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D302995A1@postman-pat.csafe.local>
In-Reply-To: <20061117155413.GX25646@binky.Central.Sun.COM>
From: "Tim Alsop" 
To: "Nicolas Williams" 
X-Scanned-By: MailControl A-07-06-70 (www.mailcontrol.com) on 10.66.1.136
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Kitten , Lisa Dusseault 
Subject: RE: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Nico said>

So, if SASL didn't have the problems we discussed, or if we had the
energy to fix them, and if the non-GSS SASL mechanisms were highly
desirable and we did not have the energy to specify/implement GSS
equivalents, then SASL would be the better solution because it would
have more mechanisms available to it than the GSS-API.

So it's quite reasonable to see HTTP-SASL as potentially better than
HTTP-GSS.  But in the end I think it's hard to conclude anything other
than that there are no SASL non-GSS mechanisms that we really want to
use in the HTTP + TLS channel binding scenario[*].  It's also easy to
conclude that it's less work to specify HTTP-GSS than to deal with the
SASL issues.

Tim said> This makes sense. Thank you again for your explanations, to
bring me upto date on what has been happening with the HTTP-SASL draft.

Take care,
Tim

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 11:26:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl6Xf-00065T-26; Fri, 17 Nov 2006 11:26:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6Xc-000637-Si
	for kitten@ietf.org; Fri, 17 Nov 2006 11:26:13 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6XY-0000j8-EC
	for kitten@ietf.org; Fri, 17 Nov 2006 11:26:12 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id RAA05466;
	Fri, 17 Nov 2006 17:25:54 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611171625.RAA15758@uw1048.wdf.sap.corp>
To: mba2000@ioplex.com (Michael B Allen)
Date: Fri, 17 Nov 2006 17:25:53 +0100 (MET)
In-Reply-To: <20061115164635.29d6befc.mba2000@ioplex.com> from "Michael B
	Allen" at Nov 15, 6 04:46:35 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-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: kitten@ietf.org, Tim.Alsop@CyberSafe.Com, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Michael B Allen wrote:
> 
> All of this is probably deliberate though. Consider the difference
> in overhead.
> 
> Negotiate/Kerberos:
>   Two round trips between the same nodes and a ticket decryption. That's
>   not that bad.
> 
> NTLM/NTLMSSP or Negotiate/NTLMSSP:
>   Three round trips and a DCERPC over SMB named pipe password check
>   with the domain controller which is a different node probably on an
>   entirely different subnet.
> 
> So authenticating every request with NTLM is indeed "prohibitively
> expensive" whereas I would say the Negotiate/Kerberos case is not
> (people do it all the time).

For traditional Kerberos, the computational overhead on the server
to process an AP_REQ and create an AP_REP is "relatively" small,
because it was designed that way.

Microsoft's Kerberos SSP works a little different.  Impersonation
can be performed in two fashions, either by mapping an external
Kerberos principal name to a local account, or (the default case
when KDC is an Active Directory and the Server is also on a
Windows machine), by inclusion of a PAC in the service ticket.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/MSDN_PAC.asp

Now I'm a little confused under what circumstances the KDC signature
on the PAC will be verified.  Verification will likely require a
network roundtrip to a domain controller.  Absence of verification
would allow any acceptor (knowing its own key--which isn't that
unusual) to create arbitrary (local) access tokens:

Quoting from above document:

  Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM)

  The PAC contains two digital signatures: one using the key of the server,
  and one using the key of the KDC. The signatures are present for two
  reasons.  First, the signature with the server's key is present to
  prevent a client from generating their own PAC and sending it to the
  KDC as encrypted authorization data to be included in tickets.
  Second, the signature with the KDC's key is present to prevent
  an untrusted service from forging a ticket to itself with an invalid PAC. 

  [...]

  Security Considerations

  Before the PAC data is used for access control, the PAC_SERVER_CHECKSUM
  signature MUST be checked. This will verify that the provider of the PAC
  data knows the server's secret key.

  Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to verify
  that the PAC was issued from the KDC and not placed in the ticket by
  someone other than the KDC with access to the service key.


And in addition, because of the current habit of IIS6 to 401 for each
and every request, the total for the homepage of our local microsoft
experts compare like this:

   MSIE6->IIS6  with NTLM
     54 requests (50 objects, 2 sockets with 2x 401 exchanges),
     2 full NTLM authentications,
        requiring additional 2.4 KByte MSIE6->IIS6 and 8 KByte IIS6->MSIE6

   MSIE->IIS with Negotiate/Kerberos:
     100 requests (50 objects, 2 sockets, one 401 exchange for each object)
     50 full Kerberos authentications
	requiring additional 200 KByte MSIE6->IIS6 and 100 KByte IIS6->MSIE6
 
Maybe not yet "prohibitive" but undoubtedly with a significant performance
impact.  In case the KDC's signature on the PAC is verified, then
it will become quite expensive.

-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 11:43:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl6o7-00065N-Os; Fri, 17 Nov 2006 11:43:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6o4-00061A-GW
	for kitten@ietf.org; Fri, 17 Nov 2006 11:43:12 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6me-0002nt-77
	for kitten@ietf.org; Fri, 17 Nov 2006 11:41:48 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHGfgMt010298
	for ; Fri, 17 Nov 2006 08:41:43 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHGffoi013604
	for ; Fri, 17 Nov 2006 09:41:41 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHGffmo005153; Fri, 17 Nov 2006 10:41:41 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHGfehG005152; 
	Fri, 17 Nov 2006 10:41:40 -0600 (CST)
Date: Fri, 17 Nov 2006 10:41:40 -0600
From: Nicolas Williams 
To: Lisa Dusseault 
Message-ID: <20061117164140.GZ25646@binky.Central.Sun.COM>
Mail-Followup-To: Lisa Dusseault ,
	Leif Johansson , Kitten 
References: <45538042.5020301@it.su.se>
	
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: e8a67952aa972b528dd04570d58ad8fe
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Sun, Nov 12, 2006 at 11:07:03AM -0800, Lisa Dusseault wrote:
> Major architectural concern: I am not enough of a GSS expert to know  
> if this mechanism offers enough information in each roundtrip for a  
> server to be able to reconstruct who the request is from and where  
> they are in the authentication process.

It has enough information in each roundtrip that:

a) it context tokens for one security context will not get mixed up with
another (and failure will result if they do get mixed up as a result of
implementation bugs),

b) when the context is fully established the server will know who the
client is.

This is done at the GSS-API level by tracking _state_ in a security
context, which is an opaque type, both, client and server side.

To avoid server side state the server will "export" (serialize) and
encrypt the security context after processing each context token and
will send back any output context tokens and the encrypted exported
context to the client.  The client will send subsequent context tokens
and the server's encrypted context back to the server.

Rinse, repeat until the security context is fully established, at which
point, since the set of TLS channels with this client [or its proxy] and
this server [or its concentrator] is now bound to that context the
client and server can now rely on TLS to secure their session without
further GSS sec context establishments.  A cookie, or the encrypted
exported fully established security context can then be used as a
cookie-like object to identify all of a client's requests without
actually having to re-authenticate the client.

>                                          The spec only mentions  
> passing GSS tokens resulting from various API calls, and not how  
> these tokens can be used to recover state, or what other state the  
> server must store to put all this together, and how long the server  
> must store that.  For HTTP server farms and non-persistent connection  
> scenarios, it's important to explain this stuff somewhere.

See above.  The key is being able to export (serialize) server-side
GSS-API state.  The GSS-API appears to allow this only for fully
established security contexts, but we think it's trivial to allow it for
partially established security contexts as well.

> Other work todo on this spec, besides the todos already mentioned in  
> the spec:
>       [...]
> 	- Explain the limits on the number of roundtrips (current spec text  
> says "This process continues until either an error occurs or the GSS- 
> API layer has successfully completed...").

The limits on round-trips are given by the underlying mechanism.  The
client can't force an infinite number of round-trips for a single
security context unless the underlying GSS mechanism gives it a way to
do that (I don't know of any that do, nor do I expect any future mechs
to do that).

Do the HTTP implementations need to know a priori the min/max # of
round-trips?

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 11:57:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl71V-0006Ip-5m; Fri, 17 Nov 2006 11:57:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl71T-0006If-IU
	for kitten@ietf.org; Fri, 17 Nov 2006 11:57:03 -0500
Received: from brmea-mail-1.sun.com ([192.18.98.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl71N-0004lz-Q5
	for kitten@ietf.org; Fri, 17 Nov 2006 11:57:03 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHGuvAM013036
	for ; Fri, 17 Nov 2006 09:56:57 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHGuuvv020298
	for ; Fri, 17 Nov 2006 09:56:57 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHGuuvr005212; Fri, 17 Nov 2006 10:56:56 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHGuukw005211; 
	Fri, 17 Nov 2006 10:56:56 -0600 (CST)
Date: Fri, 17 Nov 2006 10:56:56 -0600
From: Nicolas Williams 
To: Leif Johansson 
Message-ID: <20061117165656.GA25646@binky.Central.Sun.COM>
Mail-Followup-To: Leif Johansson ,
	Lisa Dusseault , Kitten 
References: <45538042.5020301@it.su.se>
	
	<4558D48A.9080208@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4558D48A.9080208@it.su.se>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Mon, Nov 13, 2006 at 09:24:42PM +0100, Leif Johansson wrote:
> Lisa Dusseault wrote:
> > - I'd personally prefer MUST-language that does not say that the
> > client or server "MUST call gss_foo_bar".   Instead, the requirements
> > could be that the client or server MUST use the token that would
> > result from a call to gss_foo_bar.  This may be an un-GSS way of doing
> > things :)
> I was looking for a better way to write this. This sounds like a win and
> I don't think it is very un-GSS at all.

Check out some of the other RFCs and I-Ds that do this (RFC2203,
RFC2222, RFC2228, RFC3645, RFC4462, draft-ietf-sasl-gssapi,
draft-ietf-sasl-gs2).

> > - Explain the limits on the number of roundtrips (current spec text
> > says "This process continues until either an error occurs or the
> > GSS-API layer has successfully completed...").
> >
> That may be more difficult. In practice there are few situations where
> more than (say) 5 roundtrips are
> ever needed and in many cases 1 or 2 are enough but in general GSS have
> few hard limits. The same
> question came up during the discussion of GSS-TLS on friday. I don't
> have a good answer to this at
> this time.

There is always a finite maximum number of round-trips.  There's no API
to inquire what that would be for a given GSS mechanism (or for all
available mechanisms), but a) we could provide such an API, b) such data
could be hardcoded as a last resort.

But, why is this needed?

> > - How would a GUI client (browser or rich client) know whether to
> > present a "Login" button?  Imagine a client browsing a
> > publicly-readable archive in HTML or WebDAV -- with anonymous read
> > requests, the may see all kinds of documents.  Yet if the client can
> > authenticate and get more permissions, the client might see new stuff
> > (e.g. additional documents, links to edit documents, or with WebDAV
> > see write permission available on ACL queries and know to enable
> > "upload" and "change" UIs in response).
> How does a client ever know that?

It might know from: context, configuration, and/or, much more likely,
from application-level data sent by the server.

In the NFSv4 case, for example, the negotiation is at the application
layer (i.e., in NFSv4, not in RPC or RPCSEC_GSS), and the server may
want different mechanisms to be used for different subsets of its
filesystems.

WebDAV should probably follow that model.

And HTML too should follow it.  Meaning we need an element by which the
server can tell the client that "if the user clicks on this, then
authenticate using HTTP-GSS + channel binding to TLS."

Specification of all such app-layer bits are well beyond the scope of
Leif's I-Ds, and, in some cases (e.g., HTML), well beyond the scope of
the IETF.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 12:03:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl77X-0000fp-Ua; Fri, 17 Nov 2006 12:03:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl77W-0000fb-Pw
	for kitten@ietf.org; Fri, 17 Nov 2006 12:03:18 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl77C-0005NO-29
	for kitten@ietf.org; Fri, 17 Nov 2006 12:03:18 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHH2v4m000775
	for ; Fri, 17 Nov 2006 10:02:57 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHH2vjj023484
	for ; Fri, 17 Nov 2006 10:02:57 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHH2uKv005227; Fri, 17 Nov 2006 11:02:56 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHH2ugi005226; 
	Fri, 17 Nov 2006 11:02:56 -0600 (CST)
Date: Fri, 17 Nov 2006 11:02:56 -0600
From: Nicolas Williams 
To: Leif Johansson 
Message-ID: <20061117170256.GB25646@binky.Central.Sun.COM>
Mail-Followup-To: Leif Johansson ,
	Lisa Dusseault , Kitten 
References: <45538042.5020301@it.su.se>
	
	<4558D48A.9080208@it.su.se>
	<0A4A1315-61E9-4438-9DFC-4D2BBFB206C4@osafoundation.org>
	<4558DB6C.9050005@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4558DB6C.9050005@it.su.se>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Mon, Nov 13, 2006 at 09:54:04PM +0100, Leif Johansson wrote:
> > Some of these need English text.  An ABNF telling me that the
> > WWW-Authenticate header can contain "GSS challenge=<>" doesn't
> > actually guarantee that the server sending such a header supports GSS
> > although I think that is a reasonable inference. :)  I think it's
> > really text elsewhere which talks about *empty* headers, and it's not
> > clear what the empty Authorization header means.  Does it mean "I want
> > to authenticate but I'm not telling you anything about which
> > authentication mechanisms I might support"?  Does it mean "I want to
> > authenticate and by the way I support GSS"? 
> >
> The former of course! There is no sense in putting any authentication
> mechanism before the others at this point :-)

I'm not sure that we want to allow that, but, whatever.  The client
could always try each mechanism that it has credentials for, one by one
(even in parallel) until one works or all fail.

> I'd say you raise a good point - the question of how to do negotiation
> of authentication mechanism in HTTP is perhaps too big a bite for this
> specification, especially since there are all the issues involving
> downgrade attacks etc. For the purpose of HTTP-GSS possibly all I need
> is that the client can initiate authentication when it knows that the
> server supports it and wants to do a handle-based fast reauth.

I think we must tackle this.  I think we can avoid the two-layer
negotiation issue without much trouble (but we must avoid it).

> This is all tied in with channel-bindings which imo makes it unlikely
> that the client will want to initiate auth in the
> general case since the first "please authenticate" challenge from the
> server will also serve to establish cb to the
> underlying tls if one exists.

Indeed.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 12:07:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl7Bz-0003Bf-M8; Fri, 17 Nov 2006 12:07:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Bx-0003Ba-Ks
	for kitten@ietf.org; Fri, 17 Nov 2006 12:07:53 -0500
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7Bp-0005qN-R2
	for kitten@ietf.org; Fri, 17 Nov 2006 12:07:53 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHH7jJD021730
	for ; Fri, 17 Nov 2006 09:07:45 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHH7ih5025792
	for ; Fri, 17 Nov 2006 10:07:44 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHH7iTm005234; Fri, 17 Nov 2006 11:07:44 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHH7iRr005233; 
	Fri, 17 Nov 2006 11:07:44 -0600 (CST)
Date: Fri, 17 Nov 2006 11:07:44 -0600
From: Nicolas Williams 
To: Lisa Dusseault 
Message-ID: <20061117170744.GC25646@binky.Central.Sun.COM>
Mail-Followup-To: Lisa Dusseault ,
	Leif Johansson , Kitten 
References: <45538042.5020301@it.su.se>
	
	<20061117164140.GZ25646@binky.Central.Sun.COM>
	<9587C49C-9CE3-42A6-81DA-743784463EAB@osafoundation.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9587C49C-9CE3-42A6-81DA-743784463EAB@osafoundation.org>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Kitten 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Fri, Nov 17, 2006 at 08:51:31AM -0800, Lisa Dusseault wrote:
> On Nov 17, 2006, at 8:41 AM, Nicolas Williams wrote:
> >Do the HTTP implementations need to know a priori the min/max # of
> >round-trips?
> 
> I do not know that the implementations need to know a priori, but I  
> can tell you the implementors will be curious :)

:)

The answer is: there's always a finite max # of RTs, and there's a max
for every mechanism.  Some mechanisms may be subject to future extension
work that changes their max # of RTs, for surely this won't be an issue.

>                                                   Much of what you  
> wrote in response to my questions could be usefully added to a draft,  
> at least for the HTTP-savvy (and perhaps not-so-GSS-savvy) reader's  
> benefit.

OK.  I'll re-read Leif's I-Ds and propose introductory text for the
non-GSS-savvy.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 12:18:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl7Ln-0007t8-4e; Fri, 17 Nov 2006 12:18:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7Ll-0007oC-BV
	for kitten@ietf.org; Fri, 17 Nov 2006 12:18:01 -0500
Received: from www.ioplex.com ([66.220.1.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7JM-0006bm-Or
	for kitten@ietf.org; Fri, 17 Nov 2006 12:15:43 -0500
Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net
	[69.142.196.170])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.ioplex.com (Postfix) with ESMTP id AC8AA42B72;
	Fri, 17 Nov 2006 12:15:26 -0500 (EST)
Date: Fri, 17 Nov 2006 12:15:25 -0500
From: Michael B Allen 
To: martin.rex@sap.com
Message-Id: <20061117121525.38a4925f.mba2000@ioplex.com>
In-Reply-To: <200611171625.RAA15758@uw1048.wdf.sap.corp>
References: <20061115164635.29d6befc.mba2000@ioplex.com>
	<200611171625.RAA15758@uw1048.wdf.sap.corp>
X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: kitten@ietf.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

I suspect we're starting to bore list memebers so I think this will be
my final comment on the topic.

PAC verification does not require communication with the domain
controller.

If you want to come up with a more efficient way of doing this stuff,
great, go for it. I'm just pointing out that people use IIS's Kerberos
auth right now and don't seem to care too much about the performance
impact. We're not talking about doing this stuff over the Internet. At
my last Megacorp job everyone had Gigabit to their workstations.

Mike

On Fri, 17 Nov 2006 17:25:53 +0100 (MET)
Martin Rex  wrote:

> Now I'm a little confused under what circumstances the KDC signature
> on the PAC will be verified.  Verification will likely require a
> network roundtrip to a domain controller. 

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 12:18:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl7MN-0008Jk-Jl; Fri, 17 Nov 2006 12:18:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7MM-0008Gd-0j
	for kitten@ietf.org; Fri, 17 Nov 2006 12:18:38 -0500
Received: from nwkea-mail-4.sun.com ([192.18.42.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7M5-00074G-75
	for kitten@ietf.org; Fri, 17 Nov 2006 12:18:38 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHHIK7c026329
	for ; Fri, 17 Nov 2006 09:18:20 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHHIJWk012193
	for ; Fri, 17 Nov 2006 10:18:19 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHHIJrc005246; Fri, 17 Nov 2006 11:18:19 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHHIIHu005245; 
	Fri, 17 Nov 2006 11:18:18 -0600 (CST)
Date: Fri, 17 Nov 2006 11:18:18 -0600
From: Nicolas Williams 
To: Martin Rex 
Message-ID: <20061117171817.GD25646@binky.Central.Sun.COM>
Mail-Followup-To: Martin Rex ,
	Michael B Allen , kitten@ietf.org,
	lisa@osafoundation.org
References: <20061114151004.7f1b5d39.mba2000@ioplex.com>
	<200611142017.VAA27762@uw1048.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200611142017.VAA27762@uw1048.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Session Token and Delegation (was Re: Please review: http gss
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 14, 2006 at 09:17:31PM +0100, Martin Rex wrote:
> Michael B Allen wrote:
> > 
> > Note that delegation could become a problem if session re-authentication
> > tokens are used. If a request wants to initiate auth with another tier
> > (e.g. a database) and use a delegated credential established in a previous
> > request you would need to save the delegated credential somewhere which
> > is a potential security hazard on an HTTP server (e.g. someone could
> > put something in their cgi-bin that impersonates someone else).
> 
> That is a problem of credential-delegation within a gss-api authentication.

The problem is NOT specific to the GSS-API, it's general.  See below.

> A session-reauthentication token is nothing more like a session ID
> that contains enough cryptographic random bits to make it non-predictable.
> 
> Whether the application on the server side attaches a gssapi context
> handle or a delegated credential to that server side state is
> entirely independent from the use of a session reauthentication token.
> 
> *I* always thought that credential delegation and impersonation are
> dangerously flawed concepts, and in the last 10 years I have not
> heard convincing arguments for their use/existence.

The flaw lies in violating the end-to-end principle.  But,

a) You can always build credential delegation and impersonation above
   the security mechanism if you are in control of the app layers
   between the client and proxy and proxy and service.  See above :)

b) This ship has sailed.  Many deployments exist where edge services
   rely on core services.  In such environments the edge services are
   either all-powerful w.r.t. the core services, or they rely on
   credential delegation and user impersonation to access core service.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 12:28:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gl7VV-0004Cy-MH; Fri, 17 Nov 2006 12:28:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7VT-0004CW-Rn
	for kitten@ietf.org; Fri, 17 Nov 2006 12:28:03 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl7VP-00080m-D9
	for kitten@ietf.org; Fri, 17 Nov 2006 12:28:03 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHHRwqZ024114
	for ; Fri, 17 Nov 2006 10:27:59 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHHRwGA016708
	for ; Fri, 17 Nov 2006 10:27:58 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHHRwtW005257; Fri, 17 Nov 2006 11:27:58 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHHRvij005256; 
	Fri, 17 Nov 2006 11:27:57 -0600 (CST)
Date: Fri, 17 Nov 2006 11:27:57 -0600
From: Nicolas Williams 
To: "Liqiang(Larry) Zhu" 
Message-ID: <20061117172757.GE25646@binky.Central.Sun.COM>
Mail-Followup-To: "Liqiang(Larry) Zhu" ,
	kitten@ietf.org
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@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: 97adf591118a232206bdb5a27b217034
Cc: kitten@ietf.org
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Thu, Nov 09, 2006 at 01:33:06AM -0800, Liqiang(Larry) Zhu wrote:
> The use of WS-KRB-HEADER header clearly means that IAKERB is not generic
> enough.

What's WS-KRB-HEADER?

>         It can only be stacked over variants of Kerberos protocols: U2U
> or RFC4120 Kerberos.

That's OK.

> I suspect it might be a bit over engineering to specify IAKERB as a
> stackable mechanism. The complexity does not justify the benefits at
> this point.

All you have to do to make it a stackable mechanism is this:

a) make the OIDs of the mechs composed with IAKERB be ==
	OID of IAKERB || OID of concrete mech.

b) don't use AP-REQ/AP-REP directly, but instead use the context tokens
   of the concret mechanism.  Which in this case means using AP-REQ/
   AP-REP with the GSS OID header pre-pended.

Of course, for something as closely tied to the underlying mechanism as
IAKERB there would be complexity in implementing as a stackable
mechanism: the need to provide GSS extensions for communicating
credentials acquired by IAKERB to the underlying mechanism.

But the beauty of stackable mechanisms is this: you can choose to
implement them monolythically, or generically -- your choice.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 16:49:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GlBaD-0002pL-Nt; Fri, 17 Nov 2006 16:49:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GlBaC-0002mb-2B
	for kitten@ietf.org; Fri, 17 Nov 2006 16:49:12 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlBa8-0003aQ-Lr
	for kitten@ietf.org; Fri, 17 Nov 2006 16:49:12 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHLn5kM017484
	for ; Fri, 17 Nov 2006 13:49:05 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHLn4PS006965
	for ; Fri, 17 Nov 2006 14:49:05 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHLn0ho005445; Fri, 17 Nov 2006 15:49:00 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHLmwf5005444; 
	Fri, 17 Nov 2006 15:48:58 -0600 (CST)
Date: Fri, 17 Nov 2006 15:48:58 -0600
From: Nicolas Williams 
To: Martin Rex 
Message-ID: <20061117214858.GM25646@binky.Central.Sun.COM>
Mail-Followup-To: Martin Rex ,
	RL 'Bob' Morgan , kitten@ietf.org,
	lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
References: 
	<200611140007.BAA02672@uw1048.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200611140007.BAA02672@uw1048.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 14, 2006 at 01:07:10AM +0100, Martin Rex wrote:
> Traditional Web-Browsers have only limited functionality to replicate
> session authentication tokens in successor requests.
>  - basic authentication credentials
>  - cookies
> however only cookies can be set on request of the server.
> 
> It would have been a good idea to have the browser replicate
> a server-issued (crypgraphically strong) token on a www-authenticate:
> header field for every successive request after a gss/spnego handshake,
> but it appears the designers of the rfc4559 authentication scheme forgot to
> specify this, so right now, the use of non-persistent cookies and
> a preference or requirement of an SSL/TLS protected communication channel
> is probably the most portable design approach (with the least impact
> on the creative features of middle-boxes).  If reverse proxies with
> load balacing to the backend are involved, the session re-authentication
> token must contain enough plaintext information for the reverse proxy
> to find the backend server that created this session for repeated
> or new network connections.

Yes, we shan't forget that.  It's crucial for HTTP 1.0 operation.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Fri Nov 17 17:31:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GlCEu-0004Xq-HZ; Fri, 17 Nov 2006 17:31:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GlCEt-0004Xl-RQ
	for kitten@ietf.org; Fri, 17 Nov 2006 17:31:15 -0500
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlCEm-00084P-RL
	for kitten@ietf.org; Fri, 17 Nov 2006 17:31:15 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAHMV7iH027411
	for ; Fri, 17 Nov 2006 14:31:07 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAHMV7gb000282
	for ; Fri, 17 Nov 2006 15:31:07 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAHMV6or005471; Fri, 17 Nov 2006 16:31:06 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAHMV5KP005470; 
	Fri, 17 Nov 2006 16:31:05 -0600 (CST)
Date: Fri, 17 Nov 2006 16:31:05 -0600
From: Nicolas Williams 
To: Leif Johansson 
Message-ID: <20061117223105.GN25646@binky.Central.Sun.COM>
Mail-Followup-To: Leif Johansson , martin.rex@sap.com,
	kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
References: <200611140007.BAA02672@uw1048.wdf.sap.corp>
	<4559B845.3070104@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4559B845.3070104@it.su.se>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: kitten@ietf.org, lisa@osafoundation.org, Tim.Alsop@CyberSafe.Com
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 14, 2006 at 01:36:21PM +0100, Leif Johansson wrote:
> Martin Rex wrote:
> 
> 
> >> text in http-gss:
> >>
> >>     session.  Instead opaque identifiers in the GSS challenge option
> >>     field are optionally used together with channel bindings to provide a
> >>     way to share a security context over several HTTP connections.
> >>     
> >
> > I don't really understand what you mean by that, but it really doesn't
> > sound right.
> >
> >   
> Maybe the next revision will be more clear on this point.

Basically we want this:

 - Use one GSS-API security context establishment to authenticate the
   initiator<->acceptor AND associate the {initiator, acceptor} pair
   with the set of ALL present and future TLS channels that the same
   client could establish with the same server.

We want that so that between this and fast TLS session resumption
(preferably w/o server-side state -- see RFC4507) we get:

 - really fast session crypto that can be offloaded to existing
   off-the-shelf concentrators

 - proxy traversal (the last client-side proxy being the TLS client)

 - minimal number of authentication exchanges (1 per-session until the
   server expires state or the client logs out[*])

Now, the magic is in identifying that set of TLS channels.

We do this by doing two things:

a) using GSS-API channel binding with the server cert as the channel
   binding data for all those TLS sessions

   and, crucially,

b) having a cookie-like opaque octet string that the client must replay
   over all HTTP w/ TLS sessions to the same server for the same
   session.  This cookie-like object is set by the server and it must be
   confidentiality protected (it's a shared secret).  It references the
   session established as a result of the GSS authentication step.

   and, crucially,

c) relying on TLS cipher suites[**] that use PK for key exchange
   (ephemeral DH key agreement or RSA key transport) + server certs, so
   that the client can always have strong role in key exchange and so
   that the server cert is always strongly bound to the session key
   exchange.

Between (a), (b) and (c) we get the goal described above.

[*]  Hmmm, if we have HTTP-level authentication that establishes
     sessions, shouldn't we have a logout operation as well?  IMO, yes.

[**] Let's never again try to have a single namespace for {key exchange,
     authentication, bulk crypto} algorithm tuples, shall we?

> > Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
> >   
> Nor do I.

I believe there's a fairly large community of IETF participants
(certainly not just Leif and myself) who are interested in channel
binding in general, with various specific purposes.  A topic for another
thread, to be sure, and, IMO, an unnecessary discussion at this point,
but let's tackle the relevant portion of it here:

> > because his CCM mechanism desperately needs them).  (Traditional)
> > channel bindings break many architectures in a horrible fashion because
> > they link characteristics from entirely seperate communication layers
> > and fail with the addition of the first middle-box to the communication
> > path (proxy,app-level gateway,firewall).

Martin,

First, the whole point of channel binding *is* to eliminate MITMs.

Second, in this particular case we are doing our utmost to accomodate
middle boxes, specifically proxies and concentrators, and we manage it
because HTTP is not quite like other protocols in that it is
sufficiently aware of proxies, and because the common TLS use scenario
has anonymous clients and servers authenticated by certificates.

You might ask if the second point isn't in conflict with the first.  In
fact, it is not.  That's because in the HTTP w/ proxies world the MITMs
that we would consider attackers are those that would come between the
client's last proxy and the server's concentrator.

We leave the matter of protecting client<->trusted-proxy and
concentrator<->server communications mostly out of scope, dealing only
with the matter of how the client authenticates its proxies so that
MITMs can't pretend to be one of the client's proxies.

So, as you can see, Leif's proposal breaks nothing in the sense that you
described.  The result should be a protocol that has all of these
characteristics:

 - is based on HTTP 1.0 (thus no need for persistent connections)
 - is based on TLS 1.0

 - works with HTTP 1.1 and TLS 1.1, taking advantage of TLS 1.1
   features, specifically fast session re-establishment w/o server-side
   state (RFC4507)

 - supports environments where client proxies want to see app data
 - supports TLS concentrators

 - is pluggable w.r.t. authentication (through the GSS-API)

 - it relies mostly on off-the-shelf technology, requiring changes ONLY
   to clients' last proxies, clients and servers, but not to all other
   proxies and concentrators

 - has fast connection re-establishement

 - is secure in the stated threat model, namely: active and passive
   attackers between the client's last proxy and the server's
   concentrator

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Sat Nov 18 10:13:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GlRsN-0006D6-Vh; Sat, 18 Nov 2006 10:13:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GlRsN-0006D1-99
	for kitten@ietf.org; Sat, 18 Nov 2006 10:13:03 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlRsK-0002TX-WA
	for kitten@ietf.org; Sat, 18 Nov 2006 10:13:03 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 1B6D23BE9F;
	Sat, 18 Nov 2006 16:12:48 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP
	id 30777-03-12; Sat, 18 Nov 2006 16:12:47 +0100 (CET)
Received: from [10.0.0.11] (1-1-2-20a.rny.sth.bostream.se [82.182.132.64])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id AA6C33BE2D;
	Sat, 18 Nov 2006 16:12:47 +0100 (CET)
Message-ID: <455F22F4.4070303@it.su.se>
Date: Sat, 18 Nov 2006 16:12:52 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Lisa Dusseault , Leif Johansson ,
	Kitten 
References: <45538042.5020301@it.su.se>
	
	<20061117164140.GZ25646@binky.Central.Sun.COM>
	<9587C49C-9CE3-42A6-81DA-743784463EAB@osafoundation.org>
	<20061117170744.GC25646@binky.Central.Sun.COM>
In-Reply-To: <20061117170744.GC25646@binky.Central.Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.589 tagged_above=-99 required=7 tests=[AWL=0.076,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org


>
>   
>>                                                   Much of what you  
>> wrote in response to my questions could be usefully added to a draft,  
>> at least for the HTTP-savvy (and perhaps not-so-GSS-savvy) reader's  
>> benefit.
>>     
>
> OK.  I'll re-read Leif's I-Ds and propose introductory text for the
> non-GSS-savvy.
>
> Nico
>   
Thanks Nico. That will be appreciated.

    Cheers Leif


_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 15:03:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmFM7-0005IN-Oz; Mon, 20 Nov 2006 15:03:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmFM6-0005II-Hl
	for kitten@ietf.org; Mon, 20 Nov 2006 15:03:02 -0500
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmFM2-0002wc-Ch
	for kitten@ietf.org; Mon, 20 Nov 2006 15:03:02 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAKK2vS0015036
	for ; Mon, 20 Nov 2006 13:02:57 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAKK2viA013319
	for ; Mon, 20 Nov 2006 13:02:57 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAKK2uCR007301; Mon, 20 Nov 2006 14:02:56 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAKK2tf1007300; 
	Mon, 20 Nov 2006 14:02:55 -0600 (CST)
Date: Mon, 20 Nov 2006 14:02:55 -0600
From: Nicolas Williams 
To: Leif Johansson 
Message-ID: <20061120200255.GI5938@binky.Central.Sun.COM>
Mail-Followup-To: Leif Johansson ,
	Lisa Dusseault , Kitten 
References: <45538042.5020301@it.su.se>
	
	<20061117164140.GZ25646@binky.Central.Sun.COM>
	<9587C49C-9CE3-42A6-81DA-743784463EAB@osafoundation.org>
	<20061117170744.GC25646@binky.Central.Sun.COM>
	<455F22F4.4070303@it.su.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <455F22F4.4070303@it.su.se>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: Kitten , Lisa Dusseault 
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Sat, Nov 18, 2006 at 04:12:52PM +0100, Leif Johansson wrote:
> > OK.  I'll re-read Leif's I-Ds and propose introductory text for the
> > non-GSS-savvy.

Actually, I think draft-johansson-http-gss-00.txt mostly already has
the necessary text, but it needs to be promoted to higher-level sections
where it will be most visible.  E.g., the second paragraph of section
3.2 says most of what needs to be said, but a more concise version of it
should be in section 3.

The intro should say boldly that the new authentication mechanism does
NOT require use of HTTP/1.1, much less persistent connections.

Section 3, add:

+   HTTP/1.1 persistent connections are not required in spite of the
+   possibility of multi-round-trip GSS-API context token exchanges.
+
+   Instead GSS-API context token exchanges are threaded through the use
+   of an opaque, server-issued token.  This token MAY be an encrypted
+   representation of server-side GSS-API state to support authentication
+   without server state.
+
+   Multiple HTTP with TLS channels are be tied into a single session
+   between the same client and server by using the same mechanism.
+
+   Readers who are not familiar with the GSS-API are referred to
+   RFC2743, particularly section 2.2 (Context-level calls), which
+   describes the functions and high-level protocol used in establishing
+   GSS-API security contexts.


I think we need a very concise description of what we're shooting for.
My suggestion:

    pluggable authentication for HTTP bound to a set of HTTP+TLS
    channels, and with trusted proxy traversal

(is that concise enough?).

Perhaps we could use this in the abstract of draft-johansson-http-tls-cb:

 Abstract
 
    This document specifies a channel concept for HTTP with TLS and a
    representation of that channel which can be used by protocols which
    use channel bindings to delegate session protection to lower layers.
+   Support for trusted proxy traversal is included.
+
+   A related document specifies a pluggable authentication system for
+   HTTP that uses this channel binding construction to bind individual
+   authentication exchanges to the set of current and future HTTP with
+   TLS channels that the same client may establish with the same
+   server.

Section 1 ("Terminology" -- the rfc2119 language) should be made a
sub-section of the Introduction in both I-Ds, or you should tell xml2rfc
to not insert a page break at the end of top-level sections.

The introduction in draft-johansson-http-tls-cb should be updated to
clarify that the channel binding construction described in this I-D can
be used to bind authentication not merely to one channel but to a set of
channels all of which have the same channel binding.

draft-williams-on-channel-binding-00 describes "end-point channel
bindings" which is the type of channel binding that
draft-johansson-http-tls-cb defines for HTTP+TLS.  You may want to
reference draft-williams-on-channel-binding.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 18:04:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmIBq-0001wu-F8; Mon, 20 Nov 2006 18:04:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIBo-0001wP-JY
	for kitten@ietf.org; Mon, 20 Nov 2006 18:04:36 -0500
Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmIBn-0002Ta-A9
	for kitten@ietf.org; Mon, 20 Nov 2006 18:04:36 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
	kAKN4Sm2006861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Nov 2006 18:04:28 -0500 (EST)
Date: Mon, 20 Nov 2006 18:04:27 -0500
From: Jeffrey Hutzelman 
To: Nicolas Williams ,
	David Leonard 
Message-ID: 
In-Reply-To: <20061107225534.GI25646@binky.Central.Sun.COM>
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>	<45510098.6050601@quest.com>
	<20061107225534.GI25646@binky.Central.Sun.COM>
Originator-Info: login-token=Mulberry:01LBKWHpZ6C5J4XQ6fX5DGjcOEzUmzRg+Zh8SDYpI=;
	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: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: kitten@ietf.org, Jeffrey Hutzelman 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



On Tuesday, November 07, 2006 04:55:35 PM -0600 Nicolas Williams 
 wrote:

>> This also leads to the idea of (ab)using GSS_Display_mech_attr() to
>> search for an attribute OID by its short description. That strikes me as
>> a pretty attractive thing to do when processing human-entered
>> configuration files. Sadly, it's precluded because "human-readable"
>> doesn't mean "matchable to what a human writes" (but it does make me
>> wonder about human-convenient namespace for OIDs.)
>
> Oh yes, the short description is useful precisely for that.  I suppose
> that means that the short-desc should not be translated in message
> catalogs.

This sounds very fragile to me.  If the descriptions are provided by the 
implementation, then they could change if an app is linked against a 
different implementation, or even a different version, and with the magic 
of shared libraries, _that_ could happen without the app even knowing it. 
This could be solved by defining the short descriptions to be part of the 
ABI, but then you can't add descriptions for new attribute OID's without 
making what is essentially a backward-incompatible change.

If we think attributes should have mnemonic names suitable for use in 
config files, there should be an explicit interface for this, rather than 
using GSS_Display_mech_attr() "in reverse", and we should either establish 
a registry for such names, or else explain the perils of using them in the 
absence of such a registry.

-- Jeff

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 18:10:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmIH0-00030w-MX; Mon, 20 Nov 2006 18:09:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIH0-000306-6M
	for kitten@ietf.org; Mon, 20 Nov 2006 18:09:58 -0500
Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmIGy-0003Tm-TZ
	for kitten@ietf.org; Mon, 20 Nov 2006 18:09:58 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
	kAKN9rg4006989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Nov 2006 18:09:56 -0500 (EST)
Date: Mon, 20 Nov 2006 18:09:52 -0500
From: Jeffrey Hutzelman 
To: Ken Raeburn , kitten@ietf.org
Message-ID: <01C23436FC550F95023A9F61@sirius.fac.cs.cmu.edu>
In-Reply-To: 
References: 
Originator-Info: login-token=Mulberry:01GyEptYWJnilnbKE2Tp9ZJLKTYOCiVaKIllcaUaE=;
	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: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: Jeffrey Hutzelman 
Subject: Re: comments on java bindings update,
 draft-ietf-kitten-rfc2853bis-02
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



On Tuesday, November 07, 2006 06:56:22 PM -0800 Ken Raeburn 
 wrote:

> Jeff was complaining because not enough people had reviewed the java
> bindings, so I took a look.  Not that I'm any great expert on Java,  but
> I do okay with English and sometimes even with GSSAPI...
>
> The abstract says in part:
>
>       This document
>     updates the Java bindings for the GSS-API that are specified in
>     "Generic Security Service API version 2 : Java Bindings" (RFC2853).
>     This document obsoletes RFC2853 by making specific and incremental
>     clarifications and corrections to it in response to  identification of
>     transcription errors and implementation experience.

A well-written abstract would stop right there.  This...

> The note-worthy
>     changes are in sections 4.12.1, 6.2.2, 6.3.2, and 6.8.1 of RFC2853,
>     which are replaced by the sections 5.12.1, 7.2.2, 7.3.2, and  7.8.1 of
>     this document, where numerical constants were either added or
>     modified.

... belongs in the introduction, but not in the abstract.



> * inserted the usual "conventions used in this document" section,  before
> the introduction (resulting in a renumbering of sections  through the
> whole document), even though the key words described  there are not
> actually used in the document; I haven't checked the  rules, but I would
> hope we can omit it in that case

There is no need for an RFC2119 reference unless requirements keywords from 
that document are actually used.


-- Jeff

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 18:17:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmINo-0006Cd-C7; Mon, 20 Nov 2006 18:17:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmINn-0006CY-Ju
	for kitten@ietf.org; Mon, 20 Nov 2006 18:16:59 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmINj-0004Nc-Qo
	for kitten@ietf.org; Mon, 20 Nov 2006 18:16:59 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAKNGsdW013919
	for ; Mon, 20 Nov 2006 15:16:55 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAKNGssR029750
	for ; Mon, 20 Nov 2006 16:16:54 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAKNGrPi007608; Mon, 20 Nov 2006 17:16:53 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAKNGmoj007607; 
	Mon, 20 Nov 2006 17:16:48 -0600 (CST)
Date: Mon, 20 Nov 2006 17:16:48 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061120231647.GP5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman ,
	David Leonard , kitten@ietf.org
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
	<20061107225534.GI25646@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: c1c65599517f9ac32519d043c37c5336
Cc: kitten@ietf.org, David Leonard 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Mon, Nov 20, 2006 at 06:04:27PM -0500, Jeffrey Hutzelman wrote:
> On Tuesday, November 07, 2006 04:55:35 PM -0600 Nicolas Williams 
>  wrote:
> >>This also leads to the idea of (ab)using GSS_Display_mech_attr() to
> >>search for an attribute OID by its short description. That strikes me as
> >>a pretty attractive thing to do when processing human-entered
> >>configuration files. Sadly, it's precluded because "human-readable"
> >>doesn't mean "matchable to what a human writes" (but it does make me
> >>wonder about human-convenient namespace for OIDs.)
> >
> >Oh yes, the short description is useful precisely for that.  I suppose
> >that means that the short-desc should not be translated in message
> >catalogs.
> 
> This sounds very fragile to me.  If the descriptions are provided by the 
> implementation, then they could change if an app is linked against a 
> different implementation, or even a different version, and with the magic 
> of shared libraries, _that_ could happen without the app even knowing it. 

Maybe we should get rid of the short description entirely then.  Apps
should know these things by their symbolic names and/or OIDs only and be
done.  See below.

> This could be solved by defining the short descriptions to be part of the 
> ABI, but then you can't add descriptions for new attribute OID's without 
> making what is essentially a backward-incompatible change.

I don't see how adding new attributes breaks ABIs.  Can you elaborate?
Or did I misread?

> If we think attributes should have mnemonic names suitable for use in 
> config files, there should be an explicit interface for this, rather than 
> using GSS_Display_mech_attr() "in reverse", and we should either establish 
> a registry for such names, or else explain the perils of using them in the 
> absence of such a registry.

I'm opting for removing them.  Apps could always drop the GSS_C_MA_
prefix to get a mnemonic.  I figure you'll still argue for a function
that can lookup stringified mech attr names (e.g., "CONCRETE"
or "GSS_C_MA_MECH_CONCRETE" as opposed to the symbol
GSS_C_MA_MECH_CONCRETE) and return an OID, and seeing the wisdom of this
I'll add one :)

Thanks,

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 19:17:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmJJV-0002Tg-Cu; Mon, 20 Nov 2006 19:16:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJJT-0002Ta-EW
	for kitten@ietf.org; Mon, 20 Nov 2006 19:16:35 -0500
Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJJP-0003HL-45
	for kitten@ietf.org; Mon, 20 Nov 2006 19:16:35 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
	kAL0GTpq009143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 20 Nov 2006 19:16:30 -0500 (EST)
Date: Mon, 20 Nov 2006 19:16:27 -0500
From: Jeffrey Hutzelman 
To: Nicolas Williams 
Message-ID: <37D450410D255794AF851E93@sirius.fac.cs.cmu.edu>
In-Reply-To: <20061120231647.GP5938@binky.Central.Sun.COM>
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
	<20061107225534.GI25646@binky.Central.Sun.COM>
	
	<20061120231647.GP5938@binky.Central.Sun.COM>
Originator-Info: login-token=Mulberry:01wjCrkCyYIAQOeyMR9a7b/1mi4rtJZCQvpdn1+LA=;
	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: ea4ac80f790299f943f0a53be7e1a21a
Cc: kitten@ietf.org, David Leonard ,
	Jeffrey Hutzelman 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

>> This could be solved by defining the short descriptions to be part of
>> the  ABI, but then you can't add descriptions for new attribute OID's
>> without  making what is essentially a backward-incompatible change.
>
> I don't see how adding new attributes breaks ABIs.  Can you elaborate?
> Or did I misread?

Adding _descriptions_ for new attributes breaks the ABI, because a quality 
implementation will produce useful descriptions for unknown attributes, 
like "unknown-attribute-1.3.6.1.4.1.22484.42.4.1", and that string will no 
longer work when the attribute becomes supported and the description 
changes to "gco-example-attr-1".


>> If we think attributes should have mnemonic names suitable for use in
>> config files, there should be an explicit interface for this, rather
>> than  using GSS_Display_mech_attr() "in reverse", and we should either
>> establish  a registry for such names, or else explain the perils of
>> using them in the  absence of such a registry.
>
> I'm opting for removing them.  Apps could always drop the GSS_C_MA_
> prefix to get a mnemonic.  I figure you'll still argue for a function
> that can lookup stringified mech attr names (e.g., "CONCRETE"
> or "GSS_C_MA_MECH_CONCRETE" as opposed to the symbol
> GSS_C_MA_MECH_CONCRETE) and return an OID, and seeing the wisdom of this
> I'll add one :)

I might make such an argument, after I read the full document.

-- Jeff

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 20 23:01:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmMoa-00056p-Vn; Mon, 20 Nov 2006 23:00:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmMoZ-00056k-KS
	for kitten@ietf.org; Mon, 20 Nov 2006 23:00:55 -0500
Received: from nwkea-mail-5.sun.com ([192.18.42.27])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmMoX-0002LY-Pj
	for kitten@ietf.org; Mon, 20 Nov 2006 23:00:55 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kAL40qV0020575
	for ; Mon, 20 Nov 2006 20:00:53 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kAL40p1d004735
	for ; Mon, 20 Nov 2006 21:00:52 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kAL40o6I007711; Mon, 20 Nov 2006 22:00:50 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAL40noe007710; 
	Mon, 20 Nov 2006 22:00:49 -0600 (CST)
Date: Mon, 20 Nov 2006 22:00:49 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061121040049.GU5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org,
	David Leonard 
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
	<20061107225534.GI25646@binky.Central.Sun.COM>
	
	<20061120231647.GP5938@binky.Central.Sun.COM>
	<37D450410D255794AF851E93@sirius.fac.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37D450410D255794AF851E93@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: kitten@ietf.org, David Leonard 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Mon, Nov 20, 2006 at 07:16:27PM -0500, Jeffrey Hutzelman wrote:
> >>This could be solved by defining the short descriptions to be part of
> >>the  ABI, but then you can't add descriptions for new attribute OID's
> >>without  making what is essentially a backward-incompatible change.
> >
> >I don't see how adding new attributes breaks ABIs.  Can you elaborate?
> >Or did I misread?
> 
> Adding _descriptions_ for new attributes breaks the ABI, because a quality 
> implementation will produce useful descriptions for unknown attributes, 
> like "unknown-attribute-1.3.6.1.4.1.22484.42.4.1", and that string will no 
> longer work when the attribute becomes supported and the description 
> changes to "gco-example-attr-1".

The function in question (GSS_Display_mech_attr()) returns an ERROR
(GSS_S_BAD_MECH_ATTR) for unknown mech attr OIDs, so nothing like
"unknown-attribute-1.3.6.1.4.1.22484.42.4.1" will ever be outut by it.

And you can't argue that adding new mechanism attributes would break the
ABI, not any more than you would argue that adding new mechanisms would.

> >>If we think attributes should have mnemonic names suitable for use in
> >>config files, there should be an explicit interface for this, rather
> >>than  using GSS_Display_mech_attr() "in reverse", and we should either
> >>establish  a registry for such names, or else explain the perils of
> >>using them in the  absence of such a registry.
> >
> >I'm opting for removing them.  Apps could always drop the GSS_C_MA_
> >prefix to get a mnemonic.  I figure you'll still argue for a function
> >that can lookup stringified mech attr names (e.g., "CONCRETE"
> >or "GSS_C_MA_MECH_CONCRETE" as opposed to the symbol
> >GSS_C_MA_MECH_CONCRETE) and return an OID, and seeing the wisdom of this
> >I'll add one :)
> 
> I might make such an argument, after I read the full document.

Note that one could implement such a thing in terms of
GSS_Display_mech_attr().  In pseudo-C-code:

GSS_Mech_attr_name_to_oid(string ma_name) {
    static mech_attrs = {};

    if (isempty(mech_attrs) {
	mechs = GSS_Indicate_mechs_by_attr(
		    desired_mech_attrs = GSS_C_NO_OID_SET,
		    except_mech_attrs = {});

	foreach mech in mechs {
	    mech_attrs += GSS_Inquire_attrs_for_mech(mech);
	}
    }

    for mech_attr in mech_attrs {
	(symbolic_name, description) = GSS_Display_mech_attr(mech_attr);

	if (ma_name == symbolic_name || "GSS_C_MA_" + ma_name == symbolic_name)
	    return (mech_attr);
    }

    return (GSS_C_NO_OID);
}


Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 14:34:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmbNc-0003tz-F7; Tue, 21 Nov 2006 14:34:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmbNb-0003tu-EZ
	for kitten@ietf.org; Tue, 21 Nov 2006 14:34:03 -0500
Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmbNa-0006Uu-19
	for kitten@ietf.org; Tue, 21 Nov 2006 14:34:03 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
	kALJXcwI012010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Nov 2006 14:33:38 -0500 (EST)
Date: Tue, 21 Nov 2006 14:33:38 -0500
From: Jeffrey Hutzelman 
To: Nicolas Williams 
Message-ID: <6A71F080C24954C4889411C8@sirius.fac.cs.cmu.edu>
In-Reply-To: <20061121040049.GU5938@binky.Central.Sun.COM>
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
	<20061107225534.GI25646@binky.Central.Sun.COM>
	
	<20061120231647.GP5938@binky.Central.Sun.COM>
	<37D450410D255794AF851E93@sirius.fac.cs.cmu.edu>
	<20061121040049.GU5938@binky.Central.Sun.COM>
Originator-Info: login-token=Mulberry:01G7GXOIUZDKxn/A+5Ti/Hp7IjzmOi5RCIJsWdUTE=;
	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: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: kitten@ietf.org, David Leonard ,
	Jeffrey Hutzelman 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



On Monday, November 20, 2006 10:00:49 PM -0600 Nicolas Williams 
 wrote:

> On Mon, Nov 20, 2006 at 07:16:27PM -0500, Jeffrey Hutzelman wrote:
>> >> This could be solved by defining the short descriptions to be part of
>> >> the  ABI, but then you can't add descriptions for new attribute OID's
>> >> without  making what is essentially a backward-incompatible change.
>> >
>> > I don't see how adding new attributes breaks ABIs.  Can you elaborate?
>> > Or did I misread?
>>
>> Adding _descriptions_ for new attributes breaks the ABI, because a
>> quality  implementation will produce useful descriptions for unknown
>> attributes,  like "unknown-attribute-1.3.6.1.4.1.22484.42.4.1", and that
>> string will no  longer work when the attribute becomes supported and the
>> description  changes to "gco-example-attr-1".
>
> The function in question (GSS_Display_mech_attr()) returns an ERROR
> (GSS_S_BAD_MECH_ATTR) for unknown mech attr OIDs, so nothing like
> "unknown-attribute-1.3.6.1.4.1.22484.42.4.1" will ever be outut by it.

OK.


> And you can't argue that adding new mechanism attributes would break the
> ABI, not any more than you would argue that adding new mechanisms would.

Yes, I agree that adding new values for which it does not return an error 
is not a backward-incompatible change.


> Note that one could implement such a thing in terms of
> GSS_Display_mech_attr().  In pseudo-C-code:

UGH.  If we think people should have any business doing the mapping in that 
direction, we should just provide the API for it.  If not, not.

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 16:20:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gmd2P-0003tT-4l; Tue, 21 Nov 2006 16:20:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmd2N-0003ss-0w
	for kitten@ietf.org; Tue, 21 Nov 2006 16:20:15 -0500
Received: from nwkea-mail-4.sun.com ([192.18.42.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmd2H-0006RN-9X
	for kitten@ietf.org; Tue, 21 Nov 2006 16:20:15 -0500
Received: from centralmail4brm.central.Sun.COM ([129.147.62.198])
	by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kALLK8Jd025811
	for ; Tue, 21 Nov 2006 13:20:08 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kALLK8YV018156
	for ; Tue, 21 Nov 2006 14:20:08 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kALLK5ft008222; Tue, 21 Nov 2006 15:20:05 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kALLK4Mj008221; 
	Tue, 21 Nov 2006 15:20:04 -0600 (CST)
Date: Tue, 21 Nov 2006 15:20:04 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061121212003.GG5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org,
	David Leonard 
References: <45507F6D.8030100@quest.com>
	<20061107163008.GZ25646@binky.Central.Sun.COM>
	<45510098.6050601@quest.com>
	<20061107225534.GI25646@binky.Central.Sun.COM>
	
	<20061120231647.GP5938@binky.Central.Sun.COM>
	<37D450410D255794AF851E93@sirius.fac.cs.cmu.edu>
	<20061121040049.GU5938@binky.Central.Sun.COM>
	<6A71F080C24954C4889411C8@sirius.fac.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6A71F080C24954C4889411C8@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: kitten@ietf.org, David Leonard 
Subject: Re: draft-ietf-kitten-extended-mech-inquiry-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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 21, 2006 at 02:33:38PM -0500, Jeffrey Hutzelman wrote:
> >Note that one could implement such a thing in terms of
> >GSS_Display_mech_attr().  In pseudo-C-code:
> 
> UGH.  If we think people should have any business doing the mapping in that 
> direction, we should just provide the API for it.  If not, not.

Most apps wouldn't need it, but things like IDEs would, so I would say,
yes, we need such a utility function.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 16:30:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmdCF-0006QK-8j; Tue, 21 Nov 2006 16:30:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmcht-0003OE-9X
	for kitten@ietf.org; Tue, 21 Nov 2006 15:59:05 -0500
Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmcd9-0007EW-DN
	for kitten@ietf.org; Tue, 21 Nov 2006 15:54:19 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170])
	(authenticated bits=0)
	by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
	kALKs5of014836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 21 Nov 2006 15:54:10 -0500 (EST)
Date: Tue, 21 Nov 2006 15:53:45 -0500
From: Jeffrey Hutzelman 
To: Nicolas Williams , kitten@ietf.org
Message-ID: <46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
In-Reply-To: <20061108155507.GE26436@binky.Central.Sun.COM>
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@binky.Central.Sun.COM>
Originator-Info: login-token=Mulberry:01XrkEZsghedqqBHznkTc01fUrO5Hl7X3LLjLLlDk=;
	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: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: Jeffrey Hutzelman 
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



On Wednesday, November 08, 2006 09:55:08 AM -0600 Nicolas Williams 
 wrote:


> It requires having mechanism attributes that reflect what the mechanisms
> do (e.g., compression transforms wrap token data, and CCM would lose
> such transformations as it doesn't use the underlying mech's per-msg
> tokens for its own per-msg tokens when the channel is bound, therefore
> CCM does not want to stack above compression) and careful consideration
> of each stackable pseudo-mechanism's composition rules.

Really, not only do you not want CCM to stack on top of compression, you 
pretty much want compression to stack above anything whose per-message 
tokens might involve encryption of the data.  You probably want CCM to 
stack fairly high, for similar reasons -- if you have a bunch of mechanisms 
whose per-method tokens involve expensive crypto operations, and CCM's 
purpose is to avoid using them, then you want CCM to stack high enough to 
do that.

On the other hand, things like multiple authentication and IAKERB can 
really stack nearly anywhere, but for practical reasons want to be near the 
bottom of the stack.

In fact, after some discussion, I'm not sure making IAKERB stackable is 
such a good idea after all.  The reason is that there needs to be fairly 
tight communication between IAKERB and the underlying Kerberos 
implementation used by the krb5 mechanism.

Ordinarily, as part of building an initial context token, the krb5 
mechanism makes a call to the underlying Kerberos implementation to build 
an AP-REQ, which in turn may result in the Kerberos library communicating 
with a KDC (behind the back of both the application and the GSS mechanism) 
to obtain the needed service ticket.  When IAKERB is in use, it is 
reasonable to assume that communicating directly with the KDC won't work; 
instead, such communication must be mediated by IAKERB, which carries it in 
context tokens transported by the application.

That essentially means the Kerberos API is going to need some form of 
extension which allows the library to hand KDC traffic to the caller for 
transport, instead of opening its own connection.  The GSS mechanism will 
need to provide such a callback, and make use of a mechanism along the 
lines of PAM_CONV_AGAIN/PAM_INCOMPLETE to allow the callback to return 
control back through the Kerberos library to the mechanism proper, which 
can construct a context token to be returned to the application.

Now, as long as IAKERB is a concrete mechanism, rather than a layer stacked 
on top of a Kerberos mechanism, this whole interface can remain private 
between the IAKERB mech and the Kerberos implementation (which need not 
even be exposed to applications).  However, if IAKERB is stackable, then 
the interface between it and the mech stacked below must be well-defined, 
and must include a way for the Kerberos implementation to pass KDC traffic 
up through the concrete Kerberos mechanism to the stacked IAKERB mechanism, 
which encapsulates it in a context token.


> If the rules we construct today leave us with a handful of equivalent
> composite mechs that differ only in stacking order a few years down the
> line when new stackable mechs come along, well, that wouldn't be so bad,
> and can be dealt with in any of a number of ways, including, if we think
> it safe, ignoring the problem.

I don't think ignoring the problem is likely to be unsafe, though it may 
create inconvenient interoperability issues.  Consider GSS-API users like 
SSH key exchange or SASL GS2, where GSS-API mechansim OID's are mapped into 
the available namespace by an irreversible function, in order to avoid 
multi-level negotiation issues.  If multiple stacking orders are possible, 
then the number of composite mechanisms explodes, giving these frameworks a 
huge number of mechanism numbers to deal with -- and some of them have 
limited space for expressing the set of available mechanisms.

Perhaps we just need a last-resort rule, such as ordering otherwise 
equivalent mechanisms by OID, such that 1.3.6.1.4.1.22484.42.4.1 always 
stacks above 1.3.6.1.4.1.22484.42.4.2.

> There might be an argument here for having a formal language for
> composition rules, so that rules can be added through configuration when
> we discover that new rules are needed.

It's easy to come up with a regular way to express dependencies.  Coming up 
with a way to express stacking order is harder, and will require some 
thought.

-- Jeff

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 16:50:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmdVk-0006nv-Cq; Tue, 21 Nov 2006 16:50:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmdVj-0006np-Eb
	for kitten@ietf.org; Tue, 21 Nov 2006 16:50:35 -0500
Received: from brmea-mail-1.sun.com ([192.18.98.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmdVf-0007Ny-Vr
	for kitten@ietf.org; Tue, 21 Nov 2006 16:50:35 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kALLoVSI029439
	for ; Tue, 21 Nov 2006 14:50:31 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kALLoUar018978
	for ; Tue, 21 Nov 2006 14:50:31 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kALLoUhg008237; Tue, 21 Nov 2006 15:50:30 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kALLoU3j008236; 
	Tue, 21 Nov 2006 15:50:30 -0600 (CST)
Date: Tue, 21 Nov 2006 15:50:30 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061121215029.GH5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@binky.Central.Sun.COM>
	<46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: kitten@ietf.org
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 21, 2006 at 03:53:45PM -0500, Jeffrey Hutzelman wrote:
> On Wednesday, November 08, 2006 09:55:08 AM -0600 Nicolas Williams 
>  wrote:
> >If the rules we construct today leave us with a handful of equivalent
> >composite mechs that differ only in stacking order a few years down the
> >line when new stackable mechs come along, well, that wouldn't be so bad,
> >and can be dealt with in any of a number of ways, including, if we think
> >it safe, ignoring the problem.
> 
> I don't think ignoring the problem is likely to be unsafe, though it may 
> create inconvenient interoperability issues.  Consider GSS-API users like 
> SSH key exchange or SASL GS2, where GSS-API mechansim OID's are mapped into 
> the available namespace by an irreversible function, in order to avoid 
> multi-level negotiation issues.  If multiple stacking orders are possible, 
> then the number of composite mechanisms explodes, giving these frameworks a 
> huge number of mechanism numbers to deal with -- and some of them have 
> limited space for expressing the set of available mechanisms.
> 
> Perhaps we just need a last-resort rule, such as ordering otherwise 
> equivalent mechanisms by OID, such that 1.3.6.1.4.1.22484.42.4.1 always 
> stacks above 1.3.6.1.4.1.22484.42.4.2.

I think so too.

> >There might be an argument here for having a formal language for
> >composition rules, so that rules can be added through configuration when
> >we discover that new rules are needed.
> 
> It's easy to come up with a regular way to express dependencies.

The language for the rules is easy.  I'm thinking of:

 - MUST     stack above mechanisms with 
 - MUST NOT stack above mechanisms with 
 - MUST     stack above any of  only
 - MUST NOT stack above any of 

 - SHOULD     stack above mechanisms with 
 - SHOULD NOT stack above mechanisms with 
 - SHOULD     stack above any of  only
 - SHOULD NOT stack above any of 

The SHOULD/SHOULD NOT rules are used when computing a set of composed
mechanisms, but not when validating a composed mechanism (i.e., you can
use such mechanisms but the framework won't advertise them unless told
to by local configuration).

>                                                                   Coming up 
> with a way to express stacking order is harder, and will require some 
> thought.

Well, no, the rules for each stackable mechanism can be constructed so
that by and large only sensible stacks are possible, provided that we
properly model mechanism features.

Only where we have morally equivalent composite mechanisms do we need
some sort of tie breaker -- your proposal is to use an OID sort order
for that, which seems fine by me.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 17:12:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gmdr6-00066T-7f; Tue, 21 Nov 2006 17:12:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmdr4-00066I-ST
	for kitten@ietf.org; Tue, 21 Nov 2006 17:12:38 -0500
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmdr3-0007Bv-Ff
	for kitten@ietf.org; Tue, 21 Nov 2006 17:12:38 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kALMCbHR027257
	for ; Tue, 21 Nov 2006 15:12:37 -0700 (MST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kALMCa6k029497
	for ; Tue, 21 Nov 2006 15:12:36 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kALMCa7W008252; Tue, 21 Nov 2006 16:12:36 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kALMCalm008251; 
	Tue, 21 Nov 2006 16:12:36 -0600 (CST)
Date: Tue, 21 Nov 2006 16:12:36 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061121221235.GI5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@binky.Central.Sun.COM>
	<46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: kitten@ietf.org
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 21, 2006 at 03:53:45PM -0500, Jeffrey Hutzelman wrote:
> On Wednesday, November 08, 2006 09:55:08 AM -0600 Nicolas Williams 
>  wrote:
> 
> >It requires having mechanism attributes that reflect what the mechanisms
> >do (e.g., compression transforms wrap token data, and CCM would lose
> >such transformations as it doesn't use the underlying mech's per-msg
> >tokens for its own per-msg tokens when the channel is bound, therefore
> >CCM does not want to stack above compression) and careful consideration
> >of each stackable pseudo-mechanism's composition rules.
> 
> Really, not only do you not want CCM to stack on top of compression, you 
> pretty much want compression to stack above anything whose per-message 
> tokens might involve encryption of the data.

If you want your data compressed then you want the reverse: compression
must stack above (before) CCM.  That's because CCM does not use the
per-msg protection services of the mech it stacks above of.

And yes, compression has to come before encryption.  So compression
mechs have to stack above, say, a stackable PFS mech.

We can express these constraints using rules like I just described in my
previous post.

>                                               You probably want CCM to 
> stack fairly high, for similar reasons -- if you have a bunch of mechanisms 
> whose per-method tokens involve expensive crypto operations, and CCM's 
> purpose is to avoid using them, then you want CCM to stack high enough to 
> do that.

Right.

> On the other hand, things like multiple authentication and IAKERB can 
> really stack nearly anywhere, but for practical reasons want to be near the 
> bottom of the stack.

Yes.

> In fact, after some discussion, I'm not sure making IAKERB stackable is 
> such a good idea after all.  The reason is that there needs to be fairly 
> tight communication between IAKERB and the underlying Kerberos 
> implementation used by the krb5 mechanism.

Oh, it can be done.  First, stackable doesn't mean that you must have a
non-monolythic implementation.  Second, I can think of a non-monolythic
implementation anyways, imagine a pair of functions like this:

   GSS_Set_proxy_callback_to_cred()
   GSS_Get_proxy_callback_to_cred()

for setting/getting a callback function that mechs like krb5 can use to
send/receive messages to a KDC.

Then IAKERB would be able to provide proxy services to the krb5
mechanism without having to be so tightly bound with it
implementation-wise.

Now, making this callback generic enough that it could cover proxied
communications with KDCs, OCSP responders, CRL DPs, SACRED servers and
what not, that would be the trick :)  (But no worries: just have
different callback for each of those purposes.)

Similarly, we could design a generic proxy mechanism, but every addition
of a new protocol to proxy would require exchanging protocol-specific
routing/authentication information with the proxy.

These callbacks and related functions could be seen as implementations
details.

What I'm trying to illustrate is that making IAKERB "stackable" does not
require non-monolythic implementation, but that it does make clean
non-monolythic implementation possible.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 21 17:54:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GmeV5-0002wA-8C; Tue, 21 Nov 2006 17:53:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeV4-0002w4-J8
	for kitten@ietf.org; Tue, 21 Nov 2006 17:53:58 -0500
Received: from nwkea-mail-1.sun.com ([192.18.42.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmeV3-0001Nb-5a
	for kitten@ietf.org; Tue, 21 Nov 2006 17:53:58 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kALMrubH027802
	for ; Tue, 21 Nov 2006 14:53:56 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kALMrt1L018157
	for ; Tue, 21 Nov 2006 15:53:56 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kALMrtSe008278; Tue, 21 Nov 2006 16:53:55 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kALMrtDd008277; 
	Tue, 21 Nov 2006 16:53:55 -0600 (CST)
Date: Tue, 21 Nov 2006 16:53:55 -0600
From: Nicolas Williams 
To: Jeffrey Hutzelman 
Message-ID: <20061121225354.GJ5938@binky.Central.Sun.COM>
Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org
References: <20061108153437.GQ25646@binky.Central.Sun.COM>
	<20061108155507.GE26436@binky.Central.Sun.COM>
	<46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46FEF3B5E73C36EF86F803FE@sirius.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: kitten@ietf.org
Subject: Re: Stacking order
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Tue, Nov 21, 2006 at 03:53:45PM -0500, Jeffrey Hutzelman wrote:
> Now, as long as IAKERB is a concrete mechanism, rather than a layer stacked 
> on top of a Kerberos mechanism, this whole interface can remain private 
> between the IAKERB mech and the Kerberos implementation (which need not 
> even be exposed to applications).  However, if IAKERB is stackable, then 
> the interface between it and the mech stacked below must be well-defined, 
> and must include a way for the Kerberos implementation to pass KDC traffic 
> up through the concrete Kerberos mechanism to the stacked IAKERB mechanism, 
> which encapsulates it in a context token.

If by "well-defined" you mean "defined in a Standards-Track RFC" then I
don't agree that it has to be done that way but I sure don't mind doing
it only as an abstract API for the purpose of having a more formal
description of how the mechanism works.  But I think I would object to
any *requirement* that C-bindings be standardized just to have IAKERB be
a stackable mechanism.

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Thu Nov 23 15:44:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnLQp-00082h-0W; Thu, 23 Nov 2006 15:44:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLQn-00082c-Ne
	for kitten@ietf.org; Thu, 23 Nov 2006 15:44:25 -0500
Received: from smtpde02.sap-ag.de ([155.56.68.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnLQm-0008Br-9g
	for kitten@ietf.org; Thu, 23 Nov 2006 15:44:25 -0500
Received: from sap-ag.de (smtpde02)
	by smtpde02.sap-ag.de (out) with ESMTP id VAA10934;
	Thu, 23 Nov 2006 21:44:08 +0100 (MEZ)
From: Martin Rex 
Message-Id: <200611232044.VAA19441@uw1048.wdf.sap.corp>
To: Nicolas.Williams@sun.com (Nicolas Williams)
Date: Thu, 23 Nov 2006 21:44:07 +0100 (MET)
In-Reply-To: <20061120200255.GI5938@binky.Central.Sun.COM> from "Nicolas
	Williams" at Nov 20, 6 02:02:55 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-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

Nicolas Williams wrote:
> 
> The intro should say boldly that the new authentication mechanism does
> NOT require use of HTTP/1.1, much less persistent connections.
> 
> Section 3, add:
> 
> +   HTTP/1.1 persistent connections are not required in spite of the
> +   possibility of multi-round-trip GSS-API context token exchanges.
> +
> +   Instead GSS-API context token exchanges are threaded through the use
> +   of an opaque, server-issued token.  This token MAY be an encrypted
> +   representation of server-side GSS-API state to support authentication
> +   without server state.

This appears to be going entirely into the wrong direction (IMHO).

GSS-API is designed as an abstraction accross multiple independent
but interoperable gssapi mechanisms, and this approach is making
a large number of flawed assumptions.

The existing specification of "security context export/import" in
GSS-API does *NOT* support this:

  - security context export/import is only available for fully
    established security contexts

  - security context tokens are entirely implementation-defined
    and will, in general, *NOT* be importable on another machine of
    the same kind (same CPU,OS-Release,same gssapi mechanism implementation),
    let alone servers with different architectures (different OS types,
    different CPUs, word-sizes, byte order, and code-pages/locales).

  - security context tokens are NOT standardized and a MIT Kerberos 5
    will probably not interoperate with Microsoft SSP on exported
    security context information.
    
That doesn't mean that it can not be done for extremely constrained
and well-defined scenarios/setups.  But it is not possible to standardize
behaviour here that is generic in any sense of the word (as how generic
is used in GSS-API).


Besides, trying hard to avoid having to keep backend state on the backend
is first of all a pure academic challenge.  It provides no benefit for the
majority of realworld scenarios.  And in order to make it work,
the entire application stack must be able to support the same approach,
and the continous transfer of the (protected) state of the entire
software stack has a severe impact on the communication bandwidth and
on the processing time for each request, as well as severe constraints
on how extremely homogeneous the backend server farm must be.


Persistent connections and keeping application state on the backend
make life so much easier for application design, and the performance
benefit (CPU-time and communication time) are significant (factors
to magnitudes), depending on the complexity of the application
(static vs. dynamic content) and the amount of (accumulated)
state on the backend and the amount of "uncommitted" changes to
persistent storage of the backend.  Consistency checks between
serialized state and state of the persitent storage as well
as timeout-handling (pending changes, optimistic locks, etc.)
are also much more complicated.  And then you have to deal
with "replay" attacks and distinguishing them from cloned
browser windows, and at some point you realize that stateless
backend is a myth except for dumb static fileserver or pocket calulator
type of applications.


I also have the feeling that the problems of TLS channel bindings
are underestimated.  It is more important to ensure that TLS/SSL-terminating
server-side proxies/loadbalancers have sufficient information to
allow route various indepented SSL/TLS communication channels
(with independent SSL session IDs) to the correct backend server
that is holding the state for the associated application-level session.

How many different SSL/TLS sessions get used during the course of
a single application-level session depends on many different factors.

And how about rollover of the SSL Server cert while the server is up
and there are several thousand active application sessions?

Unless an invalid server cert is installed, the application level
sessions should NOT be harmed.  The SSL/TLS session will need to
be re-negotiated (i.e. every SSL handshake will result in a new
full handshake), but the application-level authentication and
session ought to go unharmed by this.  I certainly wouldn't like
TLS channel bindings to interfere.


-Martin

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Mon Nov 27 12:04:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Goju4-0000uo-UY; Mon, 27 Nov 2006 12:04:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Goju3-0000tx-QS
	for kitten@ietf.org; Mon, 27 Nov 2006 12:04:23 -0500
Received: from nwkea-mail-4.sun.com ([192.18.42.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gojtp-00012h-EJ
	for kitten@ietf.org; Mon, 27 Nov 2006 12:04:23 -0500
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199])
	by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	kARH48rT009070
	for ; Mon, 27 Nov 2006 09:04:08 -0800 (PST)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104])
	by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,
	v2.2) with ESMTP id kARH47GB019777
	for ; Mon, 27 Nov 2006 10:04:07 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1])
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id
	kARH46nT014186; Mon, 27 Nov 2006 11:04:07 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kARH45YE014185; 
	Mon, 27 Nov 2006 11:04:05 -0600 (CST)
Date: Mon, 27 Nov 2006 11:04:05 -0600
From: Nicolas Williams 
To: Martin Rex 
Message-ID: <20061127170405.GM5938@binky.Central.Sun.COM>
Mail-Followup-To: Martin Rex , kitten@ietf.org,
	lisa@osafoundation.org
References: <20061120200255.GI5938@binky.Central.Sun.COM>
	<200611232044.VAA19441@uw1048.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200611232044.VAA19441@uw1048.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: kitten@ietf.org, lisa@osafoundation.org
Subject: Re: Please review: http gss authentication mech
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org

On Thu, Nov 23, 2006 at 09:44:07PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > The intro should say boldly that the new authentication mechanism does
> > NOT require use of HTTP/1.1, much less persistent connections.
> > 
> > Section 3, add:
> > 
> > +   HTTP/1.1 persistent connections are not required in spite of the
> > +   possibility of multi-round-trip GSS-API context token exchanges.
> > +
> > +   Instead GSS-API context token exchanges are threaded through the use
> > +   of an opaque, server-issued token.  This token MAY be an encrypted
> > +   representation of server-side GSS-API state to support authentication
> > +   without server state.
> 
> This appears to be going entirely into the wrong direction (IMHO).

So you've said.

> GSS-API is designed as an abstraction accross multiple independent
> but interoperable gssapi mechanisms, and this approach is making
> a large number of flawed assumptions.
> 
> The existing specification of "security context export/import" in
> GSS-API does *NOT* support this:
> 
>   - security context export/import is only available for fully
>     established security contexts

That's OK because: a) this does not prevent GSS implementations from
supporting this as an extension, b) we can add that extension to the
KITTEN WG charter, c) without this functionality the TLS server simply
needs to keep more state, d) the draft in question already explains this
(in fact, it mentions exported security contexts only in a non-normative
implementation note).  We want a protocol that does not fundamentally
require the server to keep state; the normative GSS-API reference does
not preclude this.

>   - security context tokens are entirely implementation-defined
      ^
      exported

>     and will, in general, *NOT* be importable on another machine of
>     the same kind (same CPU,OS-Release,same gssapi mechanism implementation),
>     let alone servers with different architectures (different OS types,
>     different CPUs, word-sizes, byte order, and code-pages/locales).

That's not an issue here.

>   - security context tokens are NOT standardized and a MIT Kerberos 5
      ^
      exported

>     will probably not interoperate with Microsoft SSP on exported
>     security context information.

See above.

> That doesn't mean that it can not be done for extremely constrained
> and well-defined scenarios/setups.  But it is not possible to standardize
> behaviour here that is generic in any sense of the word (as how generic
> is used in GSS-API).

The draft we're talking about does not require this functionality.

Nico
-- 

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten



From kitten-bounces@lists.ietf.org Tue Nov 28 03:41:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GoyWE-0000zQ-75; Tue, 28 Nov 2006 03:40:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GoyWC-0000zL-Uw
	for kitten@ietf.org; Tue, 28 Nov 2006 03:40:44 -0500
Received: from smtp3.su.se ([130.237.93.228])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoyWB-0007Dp-Hk
	for kitten@ietf.org; Tue, 28 Nov 2006 03:40:44 -0500
Received: from localhost (localhost [127.0.0.1])
	by smtp3.su.se (Postfix) with ESMTP id 4A5C83BE44
	for ; Tue, 28 Nov 2006 09:40:18 +0100 (CET)
Received: from smtp3.su.se ([127.0.0.1])
	by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new,
	port 10024) with LMTP id 28127-01-79 for ;
	Tue, 28 Nov 2006 09:40:17 +0100 (CET)
Received: from [193.11.30.24] (dhcp-wavelan-vo-24.publik.su.se [193.11.30.24])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp3.su.se (Postfix) with ESMTP id D06283BEE3
	for ; Tue, 28 Nov 2006 09:40:13 +0100 (CET)
Message-ID: <456BF5E9.5010707@it.su.se>
Date: Tue, 28 Nov 2006 09:40:09 +0100
From: Leif Johansson 
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Kitten 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at smtp.su.se
X-Spam-Status: No, hits=-1.589 tagged_above=-99 required=7 tests=[AWL=0.076,
	BAYES_00=-1.665]
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: 
Subject: review of draft-ietf-kitten-rfc2853bis-02
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: ,
	
Errors-To: kitten-bounces@lists.ietf.org



I promised to do this (from a Java-programming) perspective at the last
IETF so here goes:

My overall problem with the draft is that it seems to be directed at
both future users of the
API and implementors. For instance it is hardly necessary to explain
that Java has built-in
memory management to an implementor. This split focus makes the document
longer and
harder to follow.

I have decided to ignore any comments I might have made if this API had
not been already
widely deployed.

Apart from a general feeling that IETF api documents are much more
complicated than
they should be: I'm wanting a self-extracting perl-script which
generates the API code and
javadoc really :-)

A couple of specific comments (which in some cases examplify general
problems in the text)

5.1 Package Name

Generally its not considered a good idea to import the entire package
but java programmers
know what to do with packages. Strike the second sentence for brevity.

5.7 Object Identifier Sets

The last sentence of the second paragraph is value-laden and
unnecessary: Use of words like
complicated should (imho) be used very carefully in technical
specifications.

5.13 page 26, 2:nd paragraph:

This seems to violate the (very sensible) principle of never changing
user input data, i.e if
the user says 'foo' to a routine and then asks for something which she
can reasonably expect
to be the same value back it should be 'foo', not 'dc=foo' or 'ou=Foo,c=SE'.

5.14 page 28, last paragraph

This text about channel bindings seems dated. I really think this text
needs attention from Nico
before it goes out.

6.2 last paragraph

The expression "safe for sharing" (occurs elsewhere) is imprecise. If 
thread-safety  is what
is intended this needs to be stated.

         Cheers Leif

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten