From kitten-bounces@lists.ietf.org Mon Dec 05 16:42:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjO64-0002iG-64; Mon, 05 Dec 2005 16:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjO62-0002i3-Gl for kitten@megatron.ietf.org; Mon, 05 Dec 2005 16:42:06 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15028 for ; Mon, 5 Dec 2005 16:41:16 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EjO61-0000U2-4r; Mon, 05 Dec 2005 16:42:05 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 05 Dec 2005 16:42:05 -0500 Cc: kitten mailing list , Internet Architecture Board , RFC Editor Subject: Protocol Action: 'A PRF API extension for the GSS-API' to Proposed Standard 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 The IESG has approved the following documents: - 'A PRF API extension for the GSS-API ' as a Proposed Standard - 'A PRF for the Kerberos V GSS-API Mechanism ' as a Proposed Standard These documents are products of the Kitten (GSS-API Next Generation) Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-prf-07.txt Technical Summary These documents define a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Programming Interface (GSS-API) for keying application protocols given an established GSS-API security context and provide an implementation of that extension for the Kerberos V mechanism. The primary intended use of this function is to key secure session layers that don't or cannot use GSS-API per- message MIC (message integrity check) and wrap tokens for session Working Group Summary The Kitten working group participants are solidly behind this document. There were two areas of contention during its development. First, representatives of the Samba team desired that the PRF be designed to be compatible with the key export methods implemented by Microsoft for use with CIFS. The working group consensus was that following Microsoft's direction would have compromised the security and usefulness of the PRF functionality. Second, there was a desire to include a Java Binding for the prf() method. The Java Binding was removed from the document due to both a technical disagreement within the working group related to how it should be implemented as well as conflicts between IETF and Java Community Process processes. Protocol Quality There are no shipping implementations of this extension although there has been broad review and no concerns have been raised regarding the ability to implement the interfaces defined. Several vendors including MIT's Kerberos team, Heimdal and Sun Microsystems have indicated a desire to implement the extension. Ken Raeburn, Uri Blumenthal and Joe Salowey provided significant review. This document has been reviewed for the IESG by Sam hartman. Note to RFC Editor In draft-ietf-kitten-krb5-gssapi-prf, replace the citation to [rfc1964] with a citation to [cfx] and remove the reference entry for [rfc1964] Just before section 2, delete the paragraph beginning "mechanisms may limit the output" and ending with "requested." In draft-ietf-kitten-gssapi-prf, replace the reference to RFC 1750 with a reference to RFC 4086. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Dec 09 12:39:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmD1-0004jH-He; Fri, 09 Dec 2005 12:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkmD1-0004iG-0z for kitten@megatron.ietf.org; Fri, 09 Dec 2005 12:39:03 -0500 Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.29.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05751 for ; Fri, 9 Dec 2005 12:38:05 -0500 (EST) Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB9HcvPr003670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Dec 2005 12:38:58 -0500 (EST) Message-ID: <4399C1ED.4090604@columbia.edu> Date: Fri, 09 Dec 2005 12:42:05 -0500 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.93.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Cc: Subject: Minutes for IETF 64 Kitten meeting uploaded 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="===============0037792773==" Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0037792773== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040805000708090507090006" This is a cryptographically signed message in MIME format. --------------ms040805000708090507090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit to the IETF 64 Proceedings Site. --------------ms040805000708090507090006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUxMjA5MTc0MjA1WjAjBgkqhkiG9w0BCQQxFgQU5T1Hv+tyFoT5JzVeE1WoPWp9vhAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAB++bi4BO7KpUZdXGj1Wk4qgp8z3bVx8DDeruwQGF cwsKukLUK75DdEORgnqUFhfBhcwA/IopzP/ZPjrUUKp36sAcvlFT8tMgD8YsPExzCzUjmakB KZ1LUW+JoXS9OOfV2Z83beZs/FGp9lM9MePiabIdIS0dlOOSx3Tp8CDPLb4/lZ+GdF9Npqf9 7mNsenTOJhyUVGm03ITg+e7NuSkccM6zgzC307IwSI4LE6Ya4YuLxJgUW373tx1IBHDvT5tw 4x7E+7N1MXFEVbrC2t6JbSPeCXaid6CYmDYVkVW/TTw+hh6JCORWGSw0vK8H8M+ZVmeaENPU KD3DLM1iLiNRtwAAAAAAAA== --------------ms040805000708090507090006-- --===============0037792773== 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 --===============0037792773==-- From kitten-bounces@lists.ietf.org Mon Dec 19 16:24:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSUN-0000jz-5t; Mon, 19 Dec 2005 16:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSUJ-0000gN-Ns for kitten@megatron.ietf.org; Mon, 19 Dec 2005 16:24:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14846 for ; Mon, 19 Dec 2005 16:23:05 -0500 (EST) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoSWb-0005nl-Cm for kitten@ietf.org; Mon, 19 Dec 2005 16:26:30 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0610EE0070; Mon, 19 Dec 2005 16:23:53 -0500 (EST) To: martin.rex@sap.com References: <200511222038.VAA10945@uw1048.wdf.sap.corp> From: Sam Hartman Date: Mon, 19 Dec 2005 16:23:53 -0500 In-Reply-To: <200511222038.VAA10945@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 22 Nov 2005 21:38:49 +0100 (MET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Cc: kitten@ietf.org Subject: Re: Work Group Last Call: Desired Enhancements to GSSAPI Naming 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 >>>>> "Martin" == Martin Rex writes: Martin> Sorry for not having read and commented on this draft Martin> earlier. Understood. It would have been great to get your comments sooner but I'm glad that we have them now. Martin> I have a different perception about gssapi naming issues Martin> than what is described in this document. You expected Martin> that, didn't you :) Yes, although I'm not actually sure our perceptions are all that different when we get down to what we're actually trying to accomplish. One thing I'll say up front is that it sounds like I didn't make it clear enough that this document is about GSS V3 extensions. I'm not talking about changing GSS V2 behavior. Martin> General comments: Martin> First of all, I'd like the issue of authorization (which Martin> includes group memberships, attributes, etc.) to remain Martin> entirely seperate from authentication in GSS-API. Martin> Where authorization is desired (be it in a pseudo-generic Martin> fashion or as proprietary as gssapi mechanism implement it Martin> today), it should be done through an entirely seperate set Martin> of API calls and not be hacked into the existing naming Martin> API. We considered that approach. However you have to tie it together with the rest of GSS-API somehow in order to take advantage of it in a pseudo-generic manner. Nico and I found two possible ties. The first is to tie it in both at the credential level and at the context level. You would need to tie it in both places because for asking question about credentials before you have a context, you need it tied into the credential mechanism. You want it tied into contexts so acceptors can ask questions about authorization. The other alternative is to tie it into names. The working group has already adopted a work item that presumes this will be tied into names rather than done another way. This work item was presented in Paris and featured prominently in the minutes. I'd argue that there is a moderate barrier to revisiting the fundamental approach we're considering here, but it is not impossible to do. I do prefer to bind things into the name. I think that's a fairly natural extension of what the GSS name construct means. The name becomes all the authenticated assertions that are being made by the mechanism or that are carried by the mechanism. I think that's consistent with thinking going on in other areas that have considered naming. I also believe that the benefits of having one set of APIs rather than two ties both to extensions and credentials are important. Martin> Any kind of hacking up / overloading the naming API is Martin> likely to break existing applications. Keeping existing applications working with existing mechanisms is an absolute requirement of this work. Keeping existing applications working with new mechanisms that provide GSSAPI V2 functionality is also an absolute requirement. If we allow GSS V3 mechanisms that would not be valid GSS V2 mechanisms, then I don't think we can guarantee that existing applications would work with those mechanisms. I think that's the only way in which we should break compatibility and I believe we need to have a discussion to make sure that an existing application does not accidentally get a GSS V3 mechanism that is missing features for GSS V2 It's certainly been the intent of my draft that if you use the existing naming APIs you get behavior that will not break existing applications. Would it address some of your concerns if I added a section on backward compatibility requirements? Martin> With seperate API calls, Martin> it will be much easier for the application to distinguish Martin> whether and which additional attributes, group Martin> memberships, etc. are available, the application will not Martin> have to frob existing API calls in new ways and try to Martin> make sense of the results. I believe that Nico's proposed implementation of a solution to the problems outlined in my draft actually has this property. Applications that do not use new API calls will get GSS V2 behavior when the mechanism provides all functionality required by GSS V2 I agree this is a requirement. Martin> Comments on specific sections: Martin> Section 2. Kerberos Naming Martin> The existing scheme of binary canonical names for ACLs is Martin> perfect. No gssapi (v2) mechanism should ever be allowed Martin> to fail gss_export_name() for a mechanism name (MN). We agree completely on this point. Is there text in the draft that caused you to believe I thought otherwise? Can you suggest additional text to make this more clear? Martin> Remember that ACLs may be large (could be more than a Martin> million entries; we have around 40000 entries on some of Martin> our systems and we already have customers with 200000 Martin> entries), so an ACL lookup that would not only require a Martin> linear search, but also costly transformations on each Martin> entry would be prohibitively expensive. I completely agree. You need to be able to have a fixed set of binary strings you search your ACL for. When adding an entry to an ACL you need to easily produce a binary key that can be stored on that ACL and search for with a hash lookup or other efficient mechanism. I'd like to see cases where there are multiple identities that a GSS V3 application searches for on an ACL rather than the single entry that GSS V2 searches for. But for large ACLs, you are completely right that binary comparison is the only way to go. Martin> Implementing an Enterprise Name could be done in a Martin> straightforward and fully GSS-API v2 compliant fashion! Martin> I consider an Enterprise Name an extension of the Kerberos Martin> protocol, so the necessary provisions to make it work Martin> transparently for GSS-API v2 apps is with the Kerberos Martin> GSS-API mechanism. Martin> If Enterprise Names are implemented in a way that they Martin> entirely replace the original Kerberos principal names at Martin> the GSS-API level, then the existing model would work just Martin> fine. I agree that you could do this. However as I discuss, you sometimes want the enterprise name and you sometimes want the regular principal. My goal is to give GSS V3 acceptors access to both identities. You even discuss this problem later on; I've pulled that text up in my reply. [begin repeated text] Martin> And one should also not forget that quite a number of Martin> sysadmins and managers see it as a feature that they Martin> effectively revoke access rights by issuing new Martin> credentials to a user that moves to a different department Martin> or (sub)division within a company, and I can see as many Martin> advantages as there are inconveniences. [end repeated text] This argues strongly for allowing GSS V3 applications to get access to both identities so they can make a decision about which entry goes on the ACL. Martin> In the representation of the exported names, they Martin> should receive a different OID in the generic framing than Martin> traditional Kerberos principal names, but I don't see a Martin> problem with that (there, the wording of GSS-API v2 would Martin> only need a slight adjustment, but no actual change). Of Martin> course, Kerberos must be able to distinguish Enterprise Martin> Names them from traditional Kerberos Principal names for Martin> the purpose of ACL maintenance (printable to exported Martin> binary conversion), but that should be fine. *I* wouldn't Martin> mind if that meant a new nametype -- this is why the Martin> nametypes parameter exists in gss_import_name(). I agree we could choose this approach for V2 applications. I agree that if we do allow V3 applications to get to both identities we will need to have different OIDs for each identity. Martin> There really is no need to make things any more Martin> complicated at the GSS-API level and for GSS-API portable Martin> applications. For GSS V2 applications, I completely agree with you. The whole point of GSS V3 is to add new functionality; that does involve a bit of complexity. Martin> Section 3. X.509 Names Martin> There are plenty of reasons why particular certificates Martin> may not be usable with a particular SPKM-like gssapi Martin> mechanism, not just "it has an empty DName". Many CAs Martin> issue certificates with strict limits on their usability Martin> in order to defend their business model... Yes. One of the ways they do this is by including KeyPurposeIDs or KeyUsage certificate extensions. We need a way to get access to this in GSS V3 applications. Martin> The decision which subjectAltName extension should be used Martin> might be difficult to decide. * should there be a Martin> seperate subjectAltName extension for every application? Martin> - this would require a registry for apps to preven Martin> collisions/ambiguity - this would grow the size of Martin> certificates with every new app - it would require a new Martin> or different certificate for every new app or should there Martin> rather be a list of subjectAltNames and each application Martin> should search for best fit (or leave the mechanism default Martin> if the app doesn't recognize any)? Probably closer to the second than to the first. Note however that there is a PKIX draft based on SRV record tags that would make it fairly easy to have a SAN for each application. My belief is that whatever the decision, GSS V3 applications should be able to get to all the identifiers they can understand. I agree that reasonable defaults would be useful here. Martin> It also depends of the capabilities or willingness of the Martin> CA to issue specially tailored certs. I assume that Martin> sysadmins/customers today would like to start with Martin> subjectAltNames encoded into a RDN component today Martin> (because that is what their current CA software would Martin> allow them to do), and eventually switch to using a real Martin> subjectAltName extension whenever the software supports Martin> that switch (preferable: a migration). That will, of Martin> course, require the necessary hooks (hacks) in the gssapi Martin> mechanism implementation. :) I actually think many CAs today support the DNSName and RFC822Name SANs. But yes, your point is well taken. I don't see however how what you are saying is in conflict with what my draft says. Martin> One possibility would be to add one new gssapi call Martin> gss_set_nametypes_preference(gss_OID mech, gss_OID_set Martin> nametypes ) where the application can tell the gssapi Martin> mechanism which nametype(s) should be used when Martin> gss_display_name() is called and when gss_export_name() is Martin> called. The gssapi mechanism needs to be configurable by Martin> the sysadmin for the list of attributes that are going to Martin> be present in certificates (and a fallback identifier or Martin> fallback preference list if the attribute is not present). Martin> From that admin-configured list, the gssapi mechanism will Martin> should use those nametype(s) which it implements for the Martin> output of gss_display_name() and gss_export_name(), and Martin> show that to the application when it calls Martin> gss_inquire_names_for_mech(). We actually had a proposal to do this to improve the GSS V2 experience. We believed that for GSS V3 native applications, the application should have access to all possible identities. There was no one interested in doing the work to write and implement this function for V2 applications. If you would be interested in documenting it, I think the WG would agree it is a good idea. If not, perhaps you can find someone to volunteer. Either way I don't think this eliminates the need for a V3 solution. Martin> With a call like gss_set_nametype_preferences(), we could Martin> additionally solve the character set issue that currently Martin> exists in GSS-API v2: by defining a Pseudo-nametype OID Martin> "GSS_C_NT_USE_UTF8_PRINTABLES" we could provide a Martin> mechanism-independent forward migration path for the Martin> encoding of the printable output of gss_display_name(). Martin> If the supplied mech_oid is GSS_C_NULL_OID, then the Martin> preference list should equally apply to all mechanisms of Martin> a multi-mechanism. Do you believe my draft should discuss character set issues and GSS naming? Martin> No matter what we define or implement, the sysadmins will Martin> have to change all of their ACLs at least one more time if Martin> they want to make any use of those features. Agreed. Martin> And one should also not forget that quite a number of Martin> sysadmins and managers see it as a feature that they Martin> effectively revoke access rights by issuing new Martin> credentials to a user that moves to a different department Martin> or (sub)division within a company, and I can see as many Martin> advantages as there are inconveniences. Agreed. Martin> If the ACLs do *NOT* distinguish between "access granted Martin> based on identity" and "access granted based on Martin> role/authority/membership" then it will be impossible to Martin> come up with a silver bullet to the user rename/relocate Martin> within organization problem. Agreed. Thus I think ACLs should make this distinction. Martin> 4. Composite Name , Name Attibutes Martin> There is an extremely high lock-in potential in Martin> authorization information besides the authentication Martin> itself, no matter whether one looks at X.509v3 certificate Martin> extensions, contents of a Microsoft PAC or a DCE privilege Martin> certificate or something along those lines. Martin> Once you start depending on those attributes in your Martin> application, you may no longer be able to support gssapi Martin> mechanisms or authentication schemes that do not provide Martin> this information. This SIGNIFICANTLY reduces the Martin> portability of the application. I agree that if you take advantages of these extensions, you will either need to have reasonable fall-back behavior or require mechanisms/infrastructure where the attributes are available. I believe we have different applications for which both approaches are needed. Martin> The other significant issue with this is that all existing Martin> schemes do not scale well, and the way they work this Martin> isn't going to change. There is a fairly low limit on the Martin> number of group memberships on Microsoft Windows, and in Martin> the current architecture, the attributes always travel the Martin> wire during authentication. This creates a bandwidth Martin> issue and it also means that fine-grained authorization Martin> (with 1000+ capabilities/authorizations) may be entirely Martin> impossible with certain applications. I don't think this is an argument against making information available to GSS applications. Martin> A lot of security architectures assume that everything can Martin> be mapped to a filesystem with ACLs on files. Once you Martin> learn how business process work, you have to realize that Martin> this perception is extremely flawed, and Posix-style ACLs Martin> are a dead-end road for some types of applications. I don't understand how the argument about ACLs and filesystems applies to my draft in general or to this section in particular. Can you help me better understand the connection? Martin> The use of GSS-API based authorization information is Martin> something that can only be used by entirely new designed Martin> applications once the necessary apis and gssapi mechanisms Martin> and authorization infrastructure&configuration is Martin> available -- very few, if any, legacy application will use Martin> it (and I do mean "legacy application" here, not simple Martin> network file services). Agreed. Martin> If you look at the GSS-API spec, it was invented with Martin> legacy applications in mind, which is why it has a clear Martin> focus on authentication and proctection of the Martin> communication, and doesn't touch the details of Martin> authorization (in the base spec). Sure. GSS does a great job of that. However people are now finding that they want to take a more active role in their applications' security decisions. In order to do that, they want to add new features to GSS. In other words, GSS has been sufficiently successful it needs new capabilities. Martin> 4.3 Handling of gss_export_name Martin> An authentication mechanism for which gss_export_name can Martin> not meaningfully be defined is so seriously broken that it Martin> should not be considered a GSS-API mechanism, i.e. if a Martin> mechanism can not be used by a portable gssapi-based Martin> application that requires name-based authentication, then Martin> this mechanism is not generic enough to deserve the term Martin> "Genenric Security Service". So, I agree it would not be a valid GSS V2 mechanism. I don't understand why we cannot expand the scope of GSS mechanisms to deal with mechanisms from the EAP/AAA space that do not meet all existing GSS requirements. The goal is to be able to rite applications that work with more traditional GSS mechanisms and with these more limited mechanisms. I think that is a reasonable goal. I agree that we need to make it clear that not all applications will work with these mechanisms. We need to have clear portability guidelines and labels. However I think that GSS is a good API even in these cases. I think it would be unfortunate to require people to use GSS for some mechanisms and some other new API for other mechanisms. Martin> 7. Selection of Source Identity Martin> This interpretation in the document is somewhat too Martin> strict: I'm sorry I got it wrong; it was based on your comments to the cat and kitten list. Martin> Currently GSS-API credentials represent a single Martin> mechanism name. that is, by the time credentials are Martin> acquired, a particular single identity must be chosen for Martin> each mechanism in the credential. All these identities Martin> must correspond to a single mechanism independent name. Martin> If the initiator passes GSS_C_NO_NAME into Martin> gss_acquire_cred() along with a set of OIDs, the mechanism Martin> is permitted to delay the selection of an actual Martin> credential until this handle is passed into Martin> gss_init_sec_context(), (or when it is passed to Martin> gss_inquire_cred() or gss_inquire_cred_by_mech() with an Martin> output handle for the name or when the credentials have Martin> individual lifetimes.) Only those characteristics of Martin> GSS-API objects (contexts,credentials) that are revealed Martin> to the application caller must be nailed down once they're Martin> revealed, unrevealed characteristics may delay their Martin> resolution until a GSS-API call needs them to take a Martin> particular fixed value. A call to gss_init_sec_context() Martin> and gss_accept_sec_context() which returns GSS_S_COMPLETE Martin> will have to nail down the particular name in an Martin> explicitly supplied credential for the suceeding Martin> mechanism, as does gss_inquire_cred_by_mech() or Martin> gss_inquire_cred() for the default mechanism. I think that having to resolve the name when passed into gss_inquire_cred is enough of a problem that we want to relax it for V3. Or rather I think we may want to be able to resolve the name given a specific target. Martin> Addition of a new API call like Martin> gss_acquire_cred_for_target() might be easier to deal with Martin> by a gssapi mechanism, but it would be preferable if the Martin> necessary magic happens already within the existing Martin> GSS-API v2 calls because that is what the existing Martin> GSS-API-based apps are calling. We've mostly concluded that changing the behavior of existing apps in this manner would produce an unacceptable user experience. We'd rather V2 mechanisms and apps continue to work as they do because that's what users and application authors expect. Thanks so much for your comments. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Dec 20 16:21:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoorr-000505-UO; Tue, 20 Dec 2005 16:17:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoorp-0004yv-2v for kitten@megatron.ietf.org; Tue, 20 Dec 2005 16:17:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15850 for ; Tue, 20 Dec 2005 16:16:46 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoou8-00015u-Vk for kitten@ietf.org; Tue, 20 Dec 2005 16:20:23 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jBKLHb4u000596 for ; Tue, 20 Dec 2005 13:17:37 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jBKLHagr027404 for ; Tue, 20 Dec 2005 14:17:36 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jBKLH8CL025595; Tue, 20 Dec 2005 15:17:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jBKLH43e025594; Tue, 20 Dec 2005 15:17:04 -0600 (CST) Date: Tue, 20 Dec 2005 15:17:04 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20051220211704.GU18698@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , martin.rex@sap.com, kitten@ietf.org References: <200511222038.VAA10945@uw1048.wdf.sap.corp> 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: 140baa79ca42e6b0e2b4504291346186 Cc: kitten@ietf.org Subject: Re: Work Group Last Call: Desired Enhancements to GSSAPI Naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@lists.ietf.org Errors-To: kitten-bounces@lists.ietf.org On Mon, Dec 19, 2005 at 04:23:53PM -0500, Sam Hartman wrote: > Martin> I have a different perception about gssapi naming issues > Martin> than what is described in this document. You expected > Martin> that, didn't you :) > > Yes, although I'm not actually sure our perceptions are all that > different when we get down to what we're actually trying to > accomplish. > > One thing I'll say up front is that it sounds like I didn't make it > clear enough that this document is about GSS V3 extensions. I'm not > talking about changing GSS V2 behavior. Let us be more specific: these are extensions are based on the GSS-API v2, update 1, but are inteded to form part of the GSS-API v3. So you might say "these are extensions to the GSS-API v2u1" in a sense, though they don't actually modify the GSS-APIv2u1. > Martin> General comments: > > Martin> First of all, I'd like the issue of authorization (which > Martin> includes group memberships, attributes, etc.) to remain > Martin> entirely seperate from authentication in GSS-API. > > Martin> Where authorization is desired (be it in a pseudo-generic > Martin> fashion or as proprietary as gssapi mechanism implement it > Martin> today), it should be done through an entirely seperate set > Martin> of API calls and not be hacked into the existing naming > Martin> API. > > We considered that approach. However you have to tie it together with > the rest of GSS-API somehow in order to take advantage of it in a > pseudo-generic manner. Indeed. Suppose you have a GSS-API application already. Now you want to add support for getting at things like {Kerberos V ticket authorization-data, SAML attributes/assertions, PKIX certificate extensions, etc...} -- how should you have to modify your existing GSS-API application to get at such data? The two choices are: a) dump the GSS-API, but not the GSS-API mechanisms, and use another API to the same mechanisms that provides access to the data you need or b) notice that the GSS-API v2 provides three opaque data types that could be extended by the addition of functions/methods that operate on said opaque data types to provide access to the data you need (and term said additional functions/methods a new version of the GSS-API) Now, why on Earth would one want to replace the GSS-API with another API that provides the same basic functionality plus the required additional functionality instead of adding functions the base GSS-API v2u1 (and call it the GSS-API v3)? And what might preclude (b)? I think it's clear that there's no reason whatsoever to preclude (b). Now, that leaves the issue of how best to hook said additional functionality to the GSS-API: > Nico and I found two possible ties. > > The first is to tie it in both at the credential level and at the > context level. You would need to tie it in both places because for > asking question about credentials before you have a context, you need > it tied into the credential mechanism. You want it tied into contexts > so acceptors can ask questions about authorization. > > The other alternative is to tie it into names. > > [...] (Clarification for lurkers: here "name" refers to the opaque data type called "NAME" in the GSS-API, and is very much like an 'object' in that there are constructor, destructor and accessor methods to deal with NAME objects. The existing Java bindings treat the NAME type as an object, and the C bindings arguably do as well, with the actual C type implemented as a pointer or an integral object index.) For all the reasons that Sam gives I agree that GSS-API "names" are the right place to connect this functionality. > Martin> Any kind of hacking up / overloading the naming API is > Martin> likely to break existing applications. > > Keeping existing applications working with existing mechanisms is an > absolute requirement of this work. Keeping existing applications > working with new mechanisms that provide GSSAPI V2 functionality is > also an absolute requirement. If we allow GSS V3 mechanisms that > would not be valid GSS V2 mechanisms, then I don't think we can > guarantee that existing applications would work with those mechanisms. > I think that's the only way in which we should break compatibility and > I believe we need to have a discussion to make sure that an existing > application does not accidentally get a GSS V3 mechanism that is > missing features for GSS V2 The way to do this is to list the features that a valid GSS-API v2 mechanism MUST provide and then state that GSS_Indicate_mechs() MUST NOT indicate mechanisms which do not provide at least that set of features. For the rest, I agree with or have little to add to much of the rest of Sam's reply, so I won't quote it all. > [...] > Martin> Implementing an Enterprise Name could be done in a > Martin> straightforward and fully GSS-API v2 compliant fashion! > > Martin> I consider an Enterprise Name an extension of the Kerberos > Martin> protocol, so the necessary provisions to make it work > Martin> transparently for GSS-API v2 apps is with the Kerberos > Martin> GSS-API mechanism. > > Martin> If Enterprise Names are implemented in a way that they > Martin> entirely replace the original Kerberos principal names at > Martin> the GSS-API level, then the existing model would work just > Martin> fine. > > I agree that you could do this. However as I discuss, you sometimes > want the enterprise name and you sometimes want the regular principal. > My goal is to give GSS V3 acceptors access to both identities. You > even discuss this problem later on; I've pulled that text up in my > reply. I think we should aim for generic extensions, not mechanism-specific extensions. Yes, we could add a gss_krb5_authzdata_step() function, or some such, but that wouldn't be generic, so we'd have different functions for mechanisms that utilize, say, PKIX credentials, or something else. Given that there are folks working of clarifying/ updating SPKM (and or, as I advocate, replacing it with a DTLS-based mechanism) and that there are folks working on SAML-based GSS-API mechanisms, all of which may be able to deliver similar "authorization- data," I think we should aim for a generic API. Note that the proposed API would not preclude access to raw Kerberos V Ticket/Authenticator authorization-data. Indeed, with the proposed generic API such mechanism-specific extensions are not only not precluded but may also be provided through the generic functions using mechanism-specific "name attribute" OIDs. > [...] > Martin> 4. Composite Name , Name Attibutes > > Martin> There is an extremely high lock-in potential in > Martin> authorization information besides the authentication > Martin> itself, no matter whether one looks at X.509v3 certificate > Martin> extensions, contents of a Microsoft PAC or a DCE privilege > Martin> certificate or something along those lines. > > Martin> Once you start depending on those attributes in your > Martin> application, you may no longer be able to support gssapi > Martin> mechanisms or authentication schemes that do not provide > Martin> this information. This SIGNIFICANTLY reduces the > Martin> portability of the application. > > I agree that if you take advantages of these extensions, you will > either need to have reasonable fall-back behavior or require > mechanisms/infrastructure where the attributes are available. I > believe we have different applications for which both approaches are > needed. Agreed. Note too that name attributes need not necessarily have been directly tied to one's or one's peer's credentials. The GSS_Get_name_attribute() function may perform directory lookups to satisfy a particular request, for example, though it may also obtain the information from an actual Ticket, certificate, etc... The particular mechanism used is of little interest except in so far as establishing trust in the data returned is concerned -- but I believe the proposal addresses this. In fact, one might argue, nay, I do hereby argue that there exist GSS-API v2 applications which do just that: perform directory lookups relating to a given GSS name to obtain additional data relevant to authorization, THEREFORE all that extensions such as GSS_Get_name_attribute() do is opaquely provide an optimization whereby such data may be delivered by GSS-API mechanisms. I believe this insight alone should extenguish concerns about ACL maintenance, etc... I have examples of such applications. > [...] > Martin> The use of GSS-API based authorization information is > Martin> something that can only be used by entirely new designed > Martin> applications once the necessary apis and gssapi mechanisms > Martin> and authorization infrastructure&configuration is > Martin> available -- very few, if any, legacy application will use > Martin> it (and I do mean "legacy application" here, not simple > Martin> network file services). > > Agreed. I *strongly* disagree. See my point directly above. Thanks so much for your comments, and replies, Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten