From kitten-bounces@lists.ietf.org Tue May 01 01:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HilP2-0001Jn-6h; Tue, 01 May 2007 01:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HilP1-0001IY-3i for kitten@ietf.org; Tue, 01 May 2007 01:59:55 -0400 Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HilOz-0003bX-PS for kitten@ietf.org; Tue, 01 May 2007 01:59:55 -0400 thread-index: AceLte+dJ3h7t5SxSiqsvUSMMDUCMw== Received: from melmbxw01.prod.quest.corp ([10.20.4.118]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 22:59:52 -0700 Received: from [10.20.36.144] ([10.20.36.144]) by melmbxw01.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 15:59:49 +1000 Message-ID: <4636D78E.1000702@quest.com> Date: Tue, 01 May 2007 16:00:46 +1000 From: "David Leonard" User-Agent: Mozilla Thunderbird 1.0 (X11/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message Importance: normal Priority: normal References: <200705010054.l410sqSY010384@fs4113.wdf.sap.corp> In-Reply-To: <200705010054.l410sqSY010384@fs4113.wdf.sap.corp> Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 May 2007 05:59:49.0821 (UTC) FILETIME=[EDCB3ED0:01C78BB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: kitten@ietf.org, Tom Yu Subject: Re: Pluggable 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 Martin Rex wrote: >Tom Yu wrote: >>The answer to this question determines whether a mechanism has a good >>way to decide when to garbage-collect dynamic state associated with a >>minor_status value. >> =20 > >While a minor_status text containing dynamic situation-specific = information >might be helpful in a small number of situations, it is quite possible >for gssapi mechanisms to get along just fine with a 32-bit flat integer >and no dynamic resources whatsoever. >=20 >With GSS-API v2 I see no other possibility than to use a (ring) buffer >for a small number of past errors, potentially thread-local if that >is an issue. I've seen implementations doing this and it worked well. >If the only thing that's being done is to echo back the entire >offending input parameter, then I don't really see the need. > > =20 Isn't jolding messages in a ring buffer just pushing the problem into a=20 smaller, but still dynamic allocator? Mechanism error messages are most=20 useful when they contain specific information, such as the input=20 parameters perhaps (but more usually a configured filename or setting)=20 and that means dynamically allocated strings. You're right that minor_status codes don't need to be exposed to an=20 application if all you want is the display text. Good riddance to=20 minor_status integers, I say! I'm in two minds about Nico's idea of using the existing pointers as an=20 app context. I call it gssapi v2.5 and it's a bit like a durian. Smells=20 bad, but satisfying. I find it attractive because of the=20 usable-and-workable-right-now aspect, and appalling because it's a hack. = Unless gssapiv3 has something amazing, I reckon use of v2.5 will be=20 effective and could hamper adoption of v3. The complaints against pursuing an OO influence on the GSSAPI are=20 interesting. I didn't intend to suggest that we allow subclassing of the = gssapi and let dependencies get out of hand like the gtk+ example. It's=20 a good warning sign, but my stand is completely the opposite: I'd like=20 to see a flexible control channel between the application and mechanism=20 implementations so we can avoid existing dependencies like=20 gss_krb5_copy_ccache(). Returning to the OO influence idea, I mean=20 moving global state into managed entities (e.g. app contexts), and then=20 re-thinking the GSSAPI functions as methods on those entities. There is already a de facto mapping from the GSSAPI to an ABI so I don't = think we need to worry too much about that. I'm not even sure how a=20 standard ABI could be drafted. d --=20 David Leonard Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 01 07:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiqym-0001Xl-13; Tue, 01 May 2007 07:57:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiqyk-0001Xb-Od for kitten@ietf.org; Tue, 01 May 2007 07:57:10 -0400 Received: from ms-smtp-04.rdc-nyc.rr.com ([24.29.109.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiqyj-0006x4-Ha for kitten@ietf.org; Tue, 01 May 2007 07:57:10 -0400 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-04.rdc-nyc.rr.com (8.13.4/8.13.4) with ESMTP id l41Bv8YW010111 for ; Tue, 1 May 2007 07:57:09 -0400 (EDT) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.6) with ESMTP id md50000051641.msg for ; Tue, 01 May 2007 07:58:48 -0400 Message-ID: <46372B6D.3010908@secure-endpoints.com> Date: Tue, 01 May 2007 07:58:37 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: kitten@ietf.org References: <20070430205906.GY21027@Sun.COM> <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> <20070430222835.GA21027@Sun.COM> <20070501025818.GE21027@Sun.COM> In-Reply-To: <20070501025818.GE21027@Sun.COM> X-Enigmail-Version: 0.95.0 OpenPGP: url=http://pgp.mit.edu X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 01 May 2007 07:58:48 -0400 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 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: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: Re: Pluggable GSSAPI 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="===============0748064928==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0748064928== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080104070602000604030001" This is a cryptographically signed message in MIME format. --------------ms080104070602000604030001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As former chair of this working group I am going to offer the following opinion. Incremental modifications to GSSAPIv2 are not going to provide a satisfying solution. GSSAPIv2 programming is already too confusing for the vast majority of developers. Modifying the semantics of the API such that if X & Y & Z are true then it behaves like v2.5 but otherwise behaves like v2.0 is simply going to be too difficult to learn but more importantly, it will too hard for a developer to determine if the correct set of pieces are available. This thread has raised some very interesting ideas that could be used to improve the usability of the GSSAPI while maintaining a compatible wire protocol. I strongly suggest you focus on developing GSSAPIv3 and do so in such a manner that minimizes the amount of work necessary for a mechanism developer to support both GSSAPIv2 and GSSAPIv3 within the same module. Jeffrey Altman Secure Endpoints Inc. --------------ms080104070602000604030001 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA1MDExMTU4MzdaMCMGCSqGSIb3DQEJBDEWBBQZBOkt CIpsjDcteZCM1eCNhIn+xzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAL5K39QYtLSIFMxafIGpgJueVGr9I5T1a8XCGnedRLEU4hVNq0S/H OeWcP2kXR0w5hWrO+lW3Jd4Ge3o/I0R054FVnDTwSH8goowUE+Tz3aB4ThzHD0duLFbebAw9 HXLWGvt7yQ1RNzId+HqmrkL2yLVzmiPMnHIfp3MuDfYER9ckWXu2/FXI3uNZ+cynFoSFAEpH ULKSS7TwCtYKYR8Uknf2lbbo3LcZyD5T6nTMtzez5zl9bQD7kt442OzElAYP1zrOFvtvNFl/ WnuE3VRUA5JUpTeQzxzHGhgcTk2c7v8qiKl2yO7Lu1ddbJJvYmN8dRr5hkCzA2qWyawapWyn +wAAAAAAAA== --------------ms080104070602000604030001-- --===============0748064928== 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 --===============0748064928==-- From kitten-bounces@lists.ietf.org Tue May 01 11:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuNg-0003nM-Lt; Tue, 01 May 2007 11:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuNg-0003nG-Bv for kitten@ietf.org; Tue, 01 May 2007 11:35:08 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiuNa-0000aE-K5 for kitten@ietf.org; Tue, 01 May 2007 11:35:08 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l41FZ2Lk000436 for ; Tue, 1 May 2007 15:35:02 GMT 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 l41FZ1NQ011732 for ; Tue, 1 May 2007 09:35:01 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l41FXuiA001804; Tue, 1 May 2007 10:33:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l41FXtFZ001803; Tue, 1 May 2007 10:33:55 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 May 2007 10:33:54 -0500 From: Nicolas Williams To: David Leonard Message-ID: <20070501153354.GS21027@Sun.COM> Mail-Followup-To: David Leonard , martin.rex@sap.com, kitten@ietf.org, Tom Yu References: <200705010054.l410sqSY010384@fs4113.wdf.sap.corp> <4636D78E.1000702@quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4636D78E.1000702@quest.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org, Tom Yu Subject: Re: Pluggable 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 On Tue, May 01, 2007 at 04:00:46PM +1000, David Leonard wrote: > I'm in two minds about Nico's idea of using the existing pointers as an > app context. I call it gssapi v2.5 and it's a bit like a durian. Smells > bad, but satisfying. I find it attractive because of the > usable-and-workable-right-now aspect, and appalling because it's a hack. > Unless gssapiv3 has something amazing, I reckon use of v2.5 will be > effective and could hamper adoption of v3. I'm one of those few people outside Malaysia who likes Durian. That might explain it. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 01 11:38:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuR3-0002U4-Kv; Tue, 01 May 2007 11:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuR2-0002SR-8t for kitten@ietf.org; Tue, 01 May 2007 11:38:36 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiuQz-0001Lq-UD for kitten@ietf.org; Tue, 01 May 2007 11:38:36 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l41FcXLU019046 for ; Tue, 1 May 2007 15:38:33 GMT 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 l41FcXIv013359 for ; Tue, 1 May 2007 09:38:33 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l41FbSck001813; Tue, 1 May 2007 10:37:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l41FbRR3001812; Tue, 1 May 2007 10:37:27 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 May 2007 10:37:27 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20070501153727.GT21027@Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20070430205906.GY21027@Sun.COM> <200704302151.l3ULpfSg027927@fs4113.wdf.sap.corp> <20070430222835.GA21027@Sun.COM> <20070501025818.GE21027@Sun.COM> <46372B6D.3010908@secure-endpoints.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46372B6D.3010908@secure-endpoints.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org Subject: Re: Pluggable 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 On Tue, May 01, 2007 at 07:58:37AM -0400, Jeffrey Altman wrote: > As former chair of this working group I am going to offer the following > opinion. Incremental modifications to GSSAPIv2 are not going to provide > a satisfying solution. GSSAPIv2 programming is already too confusing > for the vast majority of developers. Modifying the semantics of the API > such that if X & Y & Z are true then it behaves like v2.5 but otherwise > behaves like v2.0 is simply going to be too difficult to learn but more > importantly, it will too hard for a developer to determine if the > correct set of pieces are available. I'm not so sure. The best part about incremental changes is that it's easier to get them deployed and used. It's all about trade-offs. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 01 16:45:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HizDp-0008HX-EH; Tue, 01 May 2007 16:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HizDn-0008HJ-Vf for kitten@ietf.org; Tue, 01 May 2007 16:45:15 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HizDm-00083g-Lv for kitten@ietf.org; Tue, 01 May 2007 16:45:15 -0400 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 9801F42B61; Tue, 1 May 2007 16:45:07 -0400 (EDT) Date: Tue, 1 May 2007 16:45:01 -0400 From: Michael B Allen To: "David Leonard" Message-Id: <20070501164501.31fe5857.mba2000@ioplex.com> In-Reply-To: <4636D78E.1000702@quest.com> References: <200705010054.l410sqSY010384@fs4113.wdf.sap.corp> <4636D78E.1000702@quest.com> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-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: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org, Tom Yu Subject: Re: Pluggable 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 On Tue, 01 May 2007 16:00:46 +1000 "David Leonard" wrote: > The complaints against pursuing an OO influence on the GSSAPI are > interesting. I didn't intend to suggest that we allow subclassing of the > gssapi and let dependencies get out of hand like the gtk+ example. It's > a good warning sign, but my stand is completely the opposite: I'd like > to see a flexible control channel between the application and mechanism > implementations so we can avoid existing dependencies like > gss_krb5_copy_ccache(). Returning to the OO influence idea, I mean > moving global state into managed entities (e.g. app contexts), and then > re-thinking the GSSAPI functions as methods on those entities. I don't really think that using a context "object" to hold and abstract state and calling functions methods is object orientated programming. To have object orientation you need polymorphism and there is no polymorphism in my example. The API I am pitching just uses a single stateful context to hold and abstract the state of authentication, options, parameters or anything that would otherwise be scattered about and passed to functions that take 10 parameters. As a programmer, it is my experience that the organisation of state used by the krb5_* and ldap_* apis is easier to use and more flexible than other techniques. The procedures and semantics of abstract GSSAPI routines would not change. If anyone feels like this is worth exploring let me know and I'll look into it. I am curious to know if it could be constructed as a stub on top of an existing implementation. Mike _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 02 05:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjBRE-0001K5-C6; Wed, 02 May 2007 05:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjBRD-0001K0-Hq for kitten@ietf.org; Wed, 02 May 2007 05:47:55 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjBRD-0006r2-5Z for kitten@ietf.org; Wed, 02 May 2007 05:47:55 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id LAA26408; Wed, 2 May 2007 11:47:49 +0200 (MESZ) From: Martin Rex Message-Id: <200705020947.l429lnS3023219@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 2 May 2007 11:47:48 +0200 (MEST) In-Reply-To: <20070501032007.GI21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 10:20:07 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: 7aafa0432175920a4b3e118e16c5cb64 Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI 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 Tue, May 01, 2007 at 03:24:19AM +0200, Martin Rex wrote: > > > > while the beauty of GSS-API (at least at the C-level) is that > > you can easily get a large number of fully interoperable > > implementations over many years. We've been doing > > binary plug'n'play with ~15 third-party gssapi mechanism > > for the last 9 years. > > You are reaching. The standard is extensible, the protocol aspects of > it not nearly as complex as the API itself, and as for the bits on the > wire, the API itself defines very little. That's probably why it has the word "generic" in its name. ;-) > > Also, there is no ABI for the C bindings, and that truly sucks. NOT AT ALL. The information in rfc-2744 C-Bindings Appendix B is perfectly sufficient for binary plug'n'play. We always intended to be using GSS-API v2 with binary plug'n'play since 1996 and (aside from buggy and broken gssapi mechanism implementations) it works like a charm. Paired with common sense rfc-2744 Appendix A gssapi.h sample header file and Appendix B Additional constraints for application binary portability it is sufficiently close to an ABI for all practical purposes. (There was one potential problem due to the reference of "xom.h" and the braindead binary-incompatible change of xom.h for 64-bit for the OID_set structure, but that problem cured itself all alone by xom.h and its ilks becoming extinct long ago.) > > > > > For GSS-API, the question would be whether parallel calls > > (in seperate threads) to message protection (=write) and > > message unprotection (=read) on the same gssapi security context handle > > should be supported. > > RPCSEC_GSS depends on it! But you do realize that GSS-API does NOT address multithreading at all, so from the spec alone, one must NOT assume that concurrency is allowed for any of the GSS-API calls. And even gssapi mechanism that support multi-threading in some fashion will NOT automatically allow concurrency on the same object handles (=data structures). If RPCSEC_GSS really _depends_ on this, it will work only with a very small set of hand-selected GSS-API mechanisms and looking at SPNEGO and for plug'n'play would be looking for neverending trouble. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed May 02 06:14:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjBr4-0003vy-JW; Wed, 02 May 2007 06:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjBr2-0003vt-UH for kitten@ietf.org; Wed, 02 May 2007 06:14:36 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjBr2-0001SV-HE for kitten@ietf.org; Wed, 02 May 2007 06:14:36 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id MAA29743; Wed, 2 May 2007 12:14:33 +0200 (MESZ) From: Martin Rex Message-Id: <200705021014.l42AEXEG025102@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 2 May 2007 12:14:33 +0200 (MEST) In-Reply-To: <20070501030627.GF21027@Sun.COM> from "Nicolas Williams" at Apr 30, 7 10:06:28 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: kitten@ietf.org, Martin.Rex@sap.com Subject: Re: Pluggable GSSAPI 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: > > In the C bindings the minor_status parameter is always a OM_uint32 *, it > is always a pointer. And my proposal doesn't change the type, it's > backwards compatible, both for binaries and source. I'm sorry, but you appear to be misled. Look at the function signature of gss_display_status again: (taken from the sample header in rfc-2744, where I just noticed that it lacks an asterisk...): OM_uint32 gss_display_status (OM_uint32 *, /* minor_status */ OM_uint32, /* status_value */ int, /* status_type */ const gss_OID, /* mech_type */ OM_uint32 , /* message_context */ gss_buffer_t /* status_string */ ); The minor_status that gss_display_status() translates into text is the second function parameter and a 32-bit integer, NOT a pointer. The first argument to all gss_api functions is a return parameter to this particular function, and for gss_display_status(), it is likely a local scratch variable that will get ENTIRELY ignored. Quoting from MIT's krb5-1.0.5 gss-sample/gss_misc.c: static void display_status_1(m, code, type) char *m; OM_uint32 code; int type; { OM_uint32 maj_stat, min_stat; gss_buffer_desc msg; OM_uint32 msg_ctx; msg_ctx = 0; while (1) { maj_stat = gss_display_status(&min_stat, code, type, GSS_C_NULL_OID, &msg_ctx, &msg); if (display_file) fprintf(display_file, "GSS-API error %s: %s\n", m, (char *)msg.value); (void) gss_release_buffer(&min_stat, &msg); if (!msg_ctx) break; } } > > > I have seen gssapi mechanism that keep additional state around > > for failed gssapi calls in a pretty useful and fairly robust > > fashion. > > Only by making assumptions about the app's thread model. Wrong. The GSS-API doesn't deal with multi-threading at all, so first of all the app MUST apply the necessary precaution when it does use multi-threading -- in particular if the app wants to be a portable app and run with arbitrary gssapi mechanisms. For multi-threading, this usually means that the app needs to use locking around each GSS-API call, and in the particular case here, the app should hold the lock until after any successor call to gss_display_status() after a failed gss-api call. The app also needs to make sure that the same lock is used for all "protocol abstractions" that might involve the usage of the same gssapi mechanism with the apps process space -- which might be challenging for complex apps, in particular on Microsoft Windows platforms where code duplication in DLLs is much more common than on Posix platforms. If you need efficient multithreading support for GSS-API plus plug'n'play with arbitrary mechanisms, you should really work hard and fast on a GSS-API v3 that provides the necessary API calls (init/finis) and documents exactly what level of concurrency a compliant mechanism must provide. > > > They keep a small ring buffer of dynamically allocated failure messages > > for failed gssapi calls and they related by minor_status code only. > > If one cares for thread-safety, using a small ring buffer per-thread > > might do for that. Cleaning up dynamic thread local storage > > That won't suffice: it assumes threads don't do GSS work for multiple > different peers. In today's world lots of multi-threaded apps don't > dedicate a thread to each peer, instead they are async apps that use > threads for concurrency. Huh? Of course that is sufficient. If the app calls gss_display_status() right after the failed GSS-API call, then this works perfectly fine and 100% reliable. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu May 03 21:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjmjo-0003vg-L8; Thu, 03 May 2007 21:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjmjn-0003vb-Co for kitten@ietf.org; Thu, 03 May 2007 21:37:35 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjmjn-00043r-1v for kitten@ietf.org; Thu, 03 May 2007 21:37:35 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l441bWgW002810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2007 21:37:33 -0400 (EDT) Date: Thu, 03 May 2007 21:37:32 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Nicolas Williams Message-ID: <613D34AFC168EC4053CB05F0@sirius.fac.cs.cmu.edu> In-Reply-To: <200705021014.l42AEXEG025102@fs4113.wdf.sap.corp> References: <200705021014.l42AEXEG025102@fs4113.wdf.sap.corp> Originator-Info: login-token=Mulberry:019lJ9T2C68sNCnfXQKdCtvo3EtHp9hvZjx6u0LNI=; 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: dbb8771284c7a36189745aa720dc20ab Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Pluggable 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 On Wednesday, May 02, 2007 12:14:33 PM +0200 Martin Rex wrote: > Nicolas Williams wrote: >> >> In the C bindings the minor_status parameter is always a OM_uint32 *, it >> is always a pointer. And my proposal doesn't change the type, it's >> backwards compatible, both for binaries and source. > > I'm sorry, but you appear to be misled. Nope. He said that "minor_status" is always a pointer, and he is correct. He said nothing about the "status_value_ parameter to gss_display_status. You're the one who keeps bringing up the issue of the type of that parameter, which is irrelevant to Nico's proposal. > Look at the function signature of gss_display_status again: > (taken from the sample header in rfc-2744, where I just noticed > that it lacks an asterisk...): > > OM_uint32 gss_display_status > (OM_uint32 *, /* minor_status */ > OM_uint32, /* status_value */ > int, /* status_type */ > const gss_OID, /* mech_type */ > OM_uint32 , /* message_context */ > gss_buffer_t /* status_string */ > ); > > The minor_status that gss_display_status() translates into text > is the second function parameter and a 32-bit integer, NOT a pointer. Correct. However, you're missing Nico's point. His proposal is to provide a new operation like this: OM_uint32 gss_create_app_context(OM_uint32 *minor_status); This operation returns results as usual, by returning the major status and storing the minor status in *minor_status. However, if it succeeds it also has the side-effect of informing the GSS provider that any future calls to GSS-API functions with the same minor_status parameter (that is, the same _pointer_, not the same pointed-to value) are part of the same application context. This information can be used by the provider to associate a context with parameters (set by additional new API functions), and also to remember complex error state. So, as an example, when a GSS-API call fails in a way that makes it desirable to pass back dynamic error state(*), it can allocate a dynamic minor status value and store the mapping from that value to the complete error information with the context. Then when gss_display_status is called with "minor_status" being the same pointer as used in previous calls, and status_value set to the dynamically-allocated value, it can look at the context to find the detailed information required to construct a status string for that value. Note that, as Nico pointed out, all of this functionality applies only to applications which call gss_create_app_context. By making that call, such applications indicate that they want the features provided by app contexts and agree to obey the additional constraints imposed by the extended interface. For example, they MUST use the registered minor_status pointer for all GSS-API calls which are part of that context (note that the pointer is still a pointer to an OM_uint32 and is still used to return minor_status values), and they MUST use gss_display_status rather than attempt to interpret or display minor status values directly. (*) Yes, there are situations in which dynamically-allocated minor status values and additional error information are relevant, and a 32-bit namespace with static meaning simply will not cut it. For example, a krb5 mechanism implementation that fails to find a service key may wish to report the name, enctype, and kvno of the service key it as unable to find. Two of these are permitted to be arbitrary 32-bit integers, and the third has a namespace much larger than that. Nico: >> > I have seen gssapi mechanism that keep additional state around >> > for failed gssapi calls in a pretty useful and fairly robust >> > fashion. >> >> Only by making assumptions about the app's thread model. > > Wrong. The GSS-API doesn't deal with multi-threading at all, > so first of all the app MUST apply the necessary precaution when > it does use multi-threading -- in particular if the app wants to > be a portable app and run with arbitrary gssapi mechanisms. > > For multi-threading, this usually means that the app needs to > use locking around each GSS-API call, and in the particular > case here, the app should hold the lock until after any successor > call to gss_display_status() after a failed gss-api call. And this is an assumption you make about the app's threading model. There is nothing in the GSS-API which requires applications to behave in this way, and while it is generally accepted that holding a lock around each call is required, there is nothing in the GSS-API spec which suggests that an application would need to hold a lock around multiple calls in order for a call to gss_display_status to return meaningful results. > Huh? Of course that is sufficient. If the app calls gss_display_status() > right after the failed GSS-API call Sounds like another assumption to me, or perhaps the same one. When designing an API, and especially when extending an existing one, you don't get to make assumptions about what applications do that go beyond what the spec says the MUST do. The GSS-API spec does not discuss threading at all; it certainly does not specify that an application wishing to get meaningful results from gss_display_status MUST make the gss_display_status call before making any other GSS-API call in the same thread. Nico.... I think I like your proposal. It is elegant and probably qualifies as a hack (sense 2). However, it has a fatal flaw - if Martin didn't see what you were getting at, than neither will most mere mortals. I think that in the name of sanity, we need to pass on this one. I think I'm beginning to agree with Jeff on this one - skip the band-aids on GSSAPIv2, and deal with this properly in v3. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 04 00:05:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjp2S-0002VQ-Ug; Fri, 04 May 2007 00:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjp2S-0002P5-6J for kitten@ietf.org; Fri, 04 May 2007 00:05:00 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjp2Q-0005z0-Ot for kitten@ietf.org; Fri, 04 May 2007 00:05:00 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id GAA09147; Fri, 4 May 2007 06:04:52 +0200 (MESZ) From: Martin Rex Message-Id: <200705040404.l4444qIe000817@fs4113.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Fri, 4 May 2007 06:04:52 +0200 (MEST) In-Reply-To: <613D34AFC168EC4053CB05F0@sirius.fac.cs.cmu.edu> from "Jeffrey Hutzelman" at May 3, 7 09:37:32 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, Nicolas.Williams@sun.com, jhutz@cmu.edu Subject: Re: Pluggable GSSAPI 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 Hutzelman wrote: > > Correct. However, you're missing Nico's point. His proposal is to provide > a new operation like this: > > OM_uint32 gss_create_app_context(OM_uint32 *minor_status); > > This operation returns results as usual, by returning the major status and > storing the minor status in *minor_status. However, if it succeeds it also > has the side-effect of informing the GSS provider that any future calls to > GSS-API functions with the same minor_status parameter (that is, the same > _pointer_, not the same pointed-to value) are part of the same application > context. This information can be used by the provider to associate a > context with parameters (set by additional new API functions), and also to > remember complex error state. That would mean that perfectly correct GSS-API v2 application will receive a much less useful error information than GSS-API v2.5 apps that know how to frob gss_create_app_context()? Which would mean that this is *NOT* about a fully backwards compatible change for GSS-API v2 -- I explicitly asked about this! If you want a feature with GSS-API v2, then by all means make it work fully and correctly with the existing spec and portable apps based on it. Otherwise make the necessary changes to the API that you need and go for a backwards incompatible GSS-API v3. A truely portable application should be perfectly fine with a very small number of static buffers. Make it per thread if your mechanism is offering multi-threading beyond GSS-API v2 and the application (ab)uses this. An application with massive parallelism (whether multi-threaded or single-threaded asynchronus) that does *NOT* pick up and error code directly after a failed GSS-API call deserves to loose because it is severely broken. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 04 00:51:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjplT-0003dB-Dl; Fri, 04 May 2007 00:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjplS-0003d3-CK for kitten@ietf.org; Fri, 04 May 2007 00:51:30 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjplS-0001SI-0p for kitten@ietf.org; Fri, 04 May 2007 00:51:30 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l444pT6q013453 for ; Fri, 4 May 2007 04:51:29 GMT 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 l444pSxe001361 for ; Thu, 3 May 2007 22:51:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l444oLN3005023; Thu, 3 May 2007 23:50:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l444oKG8005022; Thu, 3 May 2007 23:50:20 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 May 2007 23:50:20 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070504045019.GA5001@Sun.COM> Mail-Followup-To: Martin Rex , Jeffrey Hutzelman , kitten@ietf.org References: <613D34AFC168EC4053CB05F0@sirius.fac.cs.cmu.edu> <200705040404.l4444qIe000817@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200705040404.l4444qIe000817@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: Pluggable 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 On Fri, May 04, 2007 at 06:04:52AM +0200, Martin Rex wrote: > That would mean that perfectly correct GSS-API v2 application will > receive a much less useful error information than GSS-API v2.5 > apps that know how to frob gss_create_app_context()? No, they *already* receive much less useful error information than they _could_ with this extension. > Which would mean that this is *NOT* about a fully backwards compatible > change for GSS-API v2 -- I explicitly asked about this! Your facts are incorrect (see above), so we don't necessarily have to debate the merits of this [astounding and truly tyranical] view of backward compatibility. Can you actually find a valid technical argument against the proposal? If not then please say so and then attack the proposal from a stylistic or idealistic p.o.v. E.g., "this feels odd and will be difficult to explain without explaining the history of it, so why not do the gss3_* thing instead?" Such arguments are legitimate. They're also subjective. As is any argument for my proposal. This is a choice between pragmatism (incremental change) and. idealism (start from scratch). I can be idealistic at times, so I'm sympathetic. I can also be pragmatic. And let's be absolutely clear: even GSSv3 would have to be backwards compatible with GSSv2 at the application protocol level. Oh, sure, we might introduce new token types for new functionality, but they'd never be produced where app protocols that use GSSv2 wouldn't expect them. I mention this because if you care about the GSS-APIv2u1 then you cannot say "you can't touch this, but you can do what you like in GSSv3" and wash your hands -- you'd have to continue to pay attention and seek to protect the protocol from our supposedly misguided efforts. Both, this proposal (OK, let's call it GSSv2.5) and a GSSv3 approach require some minor editing of existing GSS application code, but the pragmatic approach, GSSv2.5, requires somewhat less editing of application code and *much* less editing of framework/ mechanism code, which means it should be much easier to implement and deploy quickly (meaning: at all). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri May 04 14:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk2H6-0007sZ-Dd; Fri, 04 May 2007 14:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk2H5-0007sU-UB for kitten@ietf.org; Fri, 04 May 2007 14:12:59 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hk2H4-00043n-Lj for kitten@ietf.org; Fri, 04 May 2007 14:12:59 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa24159; 4 May 2007 14:12 EDT Date: Fri, 4 May 2007 14:12:30 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Martin Rex In-Reply-To: <200705040404.l4444qIe000817@fs4113.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: kitten@ietf.org, Nicolas.Williams@sun.com Subject: Re: Pluggable 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 hOn Fri, 4 May 2007, Martin Rex wrote: > Jeffrey Hutzelman wrote: > > > > Correct. However, you're missing Nico's point. His proposal is to provide > > a new operation like this: > > > > OM_uint32 gss_create_app_context(OM_uint32 *minor_status); > > > > This operation returns results as usual, by returning the major status and > > storing the minor status in *minor_status. However, if it succeeds it also > > has the side-effect of informing the GSS provider that any future calls to > > GSS-API functions with the same minor_status parameter (that is, the same > > _pointer_, not the same pointed-to value) are part of the same application > > context. This information can be used by the provider to associate a > > context with parameters (set by additional new API functions), and also to > > remember complex error state. > > That would mean that perfectly correct GSS-API v2 application will > receive a much less useful error information than GSS-API v2.5 > apps that know how to frob gss_create_app_context()? Well, yes. The proposed new interface makes it possible for the GSS-API provider to provide more detailed information than is possible under the current GSS-APIv2 interface. Existing apps should get as much information as they always have; the fact that they can't get more is not reason to impose that limitation on new applications. > Which would mean that this is *NOT* about a fully backwards compatible > change for GSS-API v2 -- I explicitly asked about this! Yes, it is backward-compatible. Existing applications will continue to work the same as they always have. > A truely portable application You keep using this phrase, but what you mean is "an application that not only complies with the spec, but with my preconceptions about what mechanisms must and must not do based on how my own application behaves. I understand you have a fairly complete test suite for verifying that GSS-API mechanisms will work with SAP, and it's useful for finding problems with mechanism implementations. However, the GSS-API specification is defined byb RFC2743, not by your test suite or by your memory of what you or anyone else might have been thinking when it was written. > An application with massive parallelism (whether multi-threaded > or single-threaded asynchronus) that does *NOT* pick up and > error code directly after a failed GSS-API call deserves to loose > because it is severely broken. Again, you are conflating "does not meet my expectations" with "severly broken". They are not the same thing, and you need to stop making assertions to the effect that anything that does not conform to your expectations or philosophy is "broken" or "deserves to lose". That is not how reasonable people develop protocol or API standards. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 08 11:00:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlRAw-0006ZF-OK; Tue, 08 May 2007 11:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlRAv-0006ZA-G9 for kitten@ietf.org; Tue, 08 May 2007 11:00:25 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlRAu-0008O4-9o for kitten@ietf.org; Tue, 08 May 2007 11:00:25 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 955844002; Tue, 8 May 2007 11:00:22 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Tue, 08 May 2007 11:00:22 -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: de4f315c9369b71d7dd5909b42224370 Cc: Subject: Please welcome your new chairs 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'm very pleased to announce the new kitten chairs: Shawn M Emery and Alexey Melnikov Because of previous commitments it may be a while for the new chairs to spin up, but we do expect to meet in Chicago. Shawn is a document author in Kerberos and has been following kitten for a while. Alexey is a chair, working group secretary, and document author. He too has been following kitten. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue May 08 11:42:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlRpl-00012X-JE; Tue, 08 May 2007 11:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlRpk-00012N-CS for kitten@ietf.org; Tue, 08 May 2007 11:42:36 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlRpi-00033P-1W for kitten@ietf.org; Tue, 08 May 2007 11:42:36 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l48FgX7K022931 for ; Tue, 8 May 2007 15:42:33 GMT 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 l48FgXi8015756 for ; Tue, 8 May 2007 09:42:33 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l48FfNd4010635; Tue, 8 May 2007 10:41:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l48FfNPM010634; Tue, 8 May 2007 10:41:23 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 May 2007 10:41:23 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20070508154122.GG10560@Sun.COM> Mail-Followup-To: Sam Hartman , kitten@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-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org Subject: Re: Please welcome your new chairs 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, May 08, 2007 at 11:00:22AM -0400, Sam Hartman wrote: > > > I'm very pleased to announce the new kitten chairs: > > Shawn M Emery > and > Alexey Melnikov > > Because of previous commitments it may be a while for the new chairs > to spin up, but we do expect to meet in Chicago. > > Shawn is a document author in Kerberos and has been following kitten > for a while. Alexey is a chair, working group secretary, and document > author. He too has been following kitten. Excellent. Thank you! _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten