From kitten-bounces@ietf.org Sat Mar 5 15:33:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14975; Sat, 5 Mar 2005 15:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7fzJ-00036o-UE; Sat, 05 Mar 2005 15:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fxK-0003pV-L0; Sat, 05 Mar 2005 15:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7fxH-0003pQ-4D for kitten@megatron.ietf.org; Sat, 05 Mar 2005 15:32:55 -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 PAA14963 for ; Sat, 5 Mar 2005 15:32:52 -0500 (EST) Received: from [130.129.135.239] (wireless-130-129-135-239.ietf62.ietf.org [130.129.135.239]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j25KWqBU001389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 5 Mar 2005 15:32:53 -0500 (EST) Message-ID: <4229F39F.8030608@columbia.edu> Date: Sat, 05 Mar 2005 12:59:59 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Subject: SPNEGO (draft-ietf-kitten-2478bis-05.txt) to be sent to IESG 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="===============0967518851==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 This is a cryptographically signed message in MIME format. --===============0967518851== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090709010509020503080904" This is a cryptographically signed message in MIME format. --------------ms090709010509020503080904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit After reviewing the discussions on the mailing list since the end of the WGLC and receiving confirmation that the ASN.1 is valid, I believe the working group has acheived consensus and draft-ietf-kitten-2478bis-05.txt is ready to be sent to the IESG. Jeffrey Altman Kitten Chair --------------ms090709010509020503080904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMzA1MTc1OTU5WjAjBgkqhkiG9w0BCQQxFgQUeOE6Uv/pyKYO4qYT6kuae3mLp7Uw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAS9PFTX1ZcH60AWwQbz3GrnzLwQ6aAp+ceIJxvWag EgAPbSo6O4fcwoRrzjvoF3Up4IAa0SJ/fI44rQVitXMxHDOqd4RJ/0kZx9FrleWy2PvEX3Xq +nOPTEuRSHqoBFkQm+j47Yy2H0APqwhNQuDnNrDncALbX6ImloErM+LHdHgc70ZArCWvR7HV yJXAMUp1agAo97ng27lfuuYR8QPyk2Vgk0DCibjkD/iACKJmD7qbO6JqB/WxP3L29MzdProM cajyirJQFjyqQJDnw6vQMRyvF+B/72/O/bNht6AT0fRi0tnODrIbzEf00PicF0JQIIWFhRe7 WnYhFjDuOA9t8gAAAAAAAA== --------------ms090709010509020503080904-- --===============0967518851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0967518851==-- From kitten-bounces@ietf.org Mon Mar 7 16:14:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04704; Mon, 7 Mar 2005 16:14:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Pav-0006st-Gb; Mon, 07 Mar 2005 16:16:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8PWh-0007JP-24; Mon, 07 Mar 2005 16:12:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8PWf-0007JA-SC for kitten@megatron.ietf.org; Mon, 07 Mar 2005 16:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04541 for ; Mon, 7 Mar 2005 16:12:27 -0500 (EST) Received: from mailman.vintela.com ([192.41.60.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8PYt-0006pr-Fl for kitten@ietf.org; Mon, 07 Mar 2005 16:14:49 -0500 Received: (qmail 25375 invoked by uid 6010); 7 Mar 2005 21:12:14 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.013581 secs); 07 Mar 2005 21:12:14 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 7 Mar 2005 21:12:14 -0000 Received: from hotrod.vintela.com ([10.1.40.120]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Mar 2005 14:12:15 -0700 From: Matt Peterson Organization: Vintela, Inc To: Nicolas.Williams@sun.com Date: Mon, 7 Mar 2005 14:12:15 -0700 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200503071412.15639.mpeterson@vintela.com> X-OriginalArrivalTime: 07 Mar 2005 21:12:15.0886 (UTC) FILETIME=[56B812E0:01C5235A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Nicolas, We've been watching the "kitten" WG for a while now. =A0I'm sending this=20 email to you, in particular, because I believe that the work you've been=20 doing with drafts to propse GSS-API extension APIs are an extremely=20 important area of discussion. With your work on stackable-pseudo-mechs=20 (which I need to read again) it appears as though you have flexibility=20 in mind. =A0I've thought of writing a draft, but decided to email you and=20 CC the list for input first. The prospective of a namespace registry and ability to submit GSS-API=20 extensions is an very significant step the right direction. =A0I was very=20 pleased to see the draft. =A0However, from an implementation standpoint =A0 (i.e. from people who are investigating the inclusion of selected=20 GSSAPI extensions in their products) =A0I'm still have a concern how=20 extended API functionality would actually be deployed. =A0 I guess the main problem I'd like to avoid is application developers=20 linking to a *particular* GSSAPI implemention for extension=20 funtionality. The result, the system administrator would be left with=20 only the flexability of the run-time linker's configuration when=20 deploying the application. =A0Often times we see applications actually=20 shipping product with their own GSSAPI implementation to ensure proper=20 behavior -- which is sort of contrary to having written to an API=20 abstraction in the first place. ;-/ =A0 You'd expect that 3rd party =A0 GSSAPI providers would be want the option of implementing the=20 extensions (on their own time frame) and ship product that can be=20 easiliy deployed with one (or more) applications. =A0Incidentally, I can=20 seed the need for GSSAPI mplementations (even for the same mechanism=20 OID) needing to coexist and be configured on a *per-application* basis. What I'm thinking of is the ability for the system administrator (not=20 the application developer) to select a GSSAPI implementation via=20 configuration file that is suitable for a particular application (i.e.=20 supports the GSS-API extensions that the application was written to). =A0 At the same time the application should be able to recover gracefully=20 when configured to use a GSS-API implementation that lacks the=20 necessary API extensions. =A0Basically, something that works a little=20 like PAM, but allows plugability configuration for GSSAPI. =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Application | =A0 =A0 =A0 =A0 =A0 =A0 =A0 +------+------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (1)=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 ,---------. =A0 =A0 =A0 =A0 =A0 =A0 =A0 +------+-------------+ =A0 =A0 =A0 =A0 =A0,` = =A0 =A0 =A0 =A0 =A0 `. =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "pluggable" GSSAPI +---------. =A0pgssapi.con= f ) =A0 =A0 =A0 =A0 =A0 +---+ =A0 =A0(pgssapi.so) =A0 =A0| =A0 (2) =A0 =A0`. = =A0 =A0 =A0 =A0 =A0 ,' =A0 =A0 =A0 (3) | =A0 +--------------------+ =A0 =A0 =A0 =A0 =A0 =A0`------= =2D--' =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0d =A0| =A0 +-------------------------------------+ =A0 =A0 =A0 =A0l =A0+---+ /usr/local/lib/mit/libgssapi.so =A0 =A0 | =A0 =A0 =A0 =A0o =A0| =A0 +-------------------------------------+ =A0 =A0 =A0 =A0p =A0| =A0 =A0 =A0 =A0e =A0| =A0 +-------------------------------------+ =A0 =A0 =A0 =A0n =A0+---+ /usr/local/lib/heimdal/libgssapi.so | =A0 =A0 =A0 =A0=A0 | =A0 +-------------------------------------+ =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 +-------------------------------------+ =A0 =A0 =A0 =A0 =A0 +---+ /opt/xyz/lib/libxyz.so =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------------------------------------+ In the diagram above, pgssapi.conf would map application identifiers=20 (similar to PAM) to a gssapi implementation. =A0The only requirement to=20 make something like the above a reality would be a draft (which I'd=20 write) describing 1) an API extension for pluggability that allows the=20 application to specify the application identifier (similar to=20 pam_start() pam_end() but simpler), 2) a recommendation for return code=20 for NOT_IMPLEMENTED that allows the application to graceful fail (i.e.=20 display or log a message that directs the system administrator to fix=20 the gssapi configuration) 3) symantics (possibly syntax and grammar) of=20 the config file. In the end I think encouraging extension to the GSSAPI, as long as it=20 follows proper namespace considerations, will be a very good thing for=20 ubiquity of GSS. =A0If this is the case, system administrators and=20 application developers would thank us if we provided an elegant way for=20 them to deploy applications with a veriety (and mixture) of GSS API=20 implementations. =46or simplicity in this email I've restricted my examples to C bindings=20 and run-time shared object linkage. =A0However, I think that the concepts=20 would apply to other interpreted language bindings (Java and C#)...=20 Yes, I realize that Solaris has a gssapi.conf that allows per-mechanism=20 OID configuration. =A0What I'm introducing here is per-application GSSAPI=20 config which is different in an important way -- especially when=20 considering the (new) ability to implement IANA registered extension=20 APIs. Please comment. Thanks, =2D- Matt Peterson Vintela, Inc _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 00:32:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23835; Tue, 8 Mar 2005 00:32:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8XMv-0002ng-Lx; Tue, 08 Mar 2005 00:34:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8XKU-0003a3-Fn; Tue, 08 Mar 2005 00:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8XKS-0003Zs-Sa for kitten@megatron.ietf.org; Tue, 08 Mar 2005 00:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23824 for ; Tue, 8 Mar 2005 00:32:21 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8XMn-0002nT-1r for kitten@ietf.org; Tue, 08 Mar 2005 00:34:49 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j285WNhl005762 for ; Mon, 7 Mar 2005 22:32:23 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j285WMaa002366 for ; Mon, 7 Mar 2005 22:32:22 -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 j285UfJa000479; Mon, 7 Mar 2005 23:30:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j285Ud7H000478; Mon, 7 Mar 2005 23:30:39 -0600 (CST) Date: Mon, 7 Mar 2005 23:30:39 -0600 From: Nicolas Williams To: Matt Peterson Message-ID: <20050308053039.GK1007@binky.Central.Sun.COM> Mail-Followup-To: Matt Peterson , kitten@ietf.org References: <200503071412.15639.mpeterson@vintela.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline In-Reply-To: <200503071412.15639.mpeterson@vintela.com> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by brmea-mail-3.sun.com id j285WNhl005762 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable On Mon, Mar 07, 2005 at 02:12:15PM -0700, Matt Peterson wrote: [...] > I guess the main problem I'd like to avoid is application developers=20 > linking to a *particular* GSSAPI implemention for extension=20 > funtionality. The result, the system administrator would be left with=20 > only the flexability of the run-time linker's configuration when=20 > deploying the application. =A0Often times we see applications actually=20 > shipping product with their own GSSAPI implementation to ensure proper=20 > behavior -- which is sort of contrary to having written to an API=20 > abstraction in the first place. ;-/ =A0 You'd expect that 3rd party =A0 > GSSAPI providers would be want the option of implementing the=20 > extensions (on their own time frame) and ship product that can be=20 > easiliy deployed with one (or more) applications. What you are talking about is language-specific bindings and compile-, link- and/or run-time detection of extensions availability. And, really, you're talking about the C bindings specifically, as it's typically easier to deal with run-time detection of API availability portably in higher-level languages than in C. We're aware of this. My intention is to provide at least for compile-time detection of extensions availability, as that's probably the best we can do _portably_ -- that's C for you. Of course, on platforms that provide weak symbols and so on you can do much better, and for a small set of platforms you can even do so portably, but I'm not sure we can use that in our I-Ds. Incidentally, my individual submission I-D on stackable mechanisms has become two KITTEN WG work items which I did submit on time to the I-D repository, but which unfortunately did not get published on time. One of those drafts provides for extended intquiry functionality that could be used to detect, at run-time, the availability of whatever the application needs. The extended inquiry functions don't solve the problem that the C language doesn't have standard run-time linker/loader environments though, but for most other languages it'll do quite well. > =A0Incidentally, I ca= n=20 > seed the need for GSSAPI mplementations (even for the same mechanism=20 > OID) needing to coexist and be configured on a *per-application* basis. I don't. > What I'm thinking of is the ability for the system administrator (not=20 > the application developer) to select a GSSAPI implementation via=20 > configuration file that is suitable for a particular application (i.e.=20 > supports the GSS-API extensions that the application was written to). =A0 I don't see why you'd want this. > At the same time the application should be able to recover gracefully=20 > when configured to use a GSS-API implementation that lacks the=20 > necessary API extensions. =A0 See above. > =A0Basically, something that works a little=20 > like PAM, but allows plugability configuration for GSSAPI. I don't understand this. [...] > In the end I think encouraging extension to the GSSAPI, as long as it=20 > follows proper namespace considerations, will be a very good thing for=20 > ubiquity of GSS. =A0If this is the case, system administrators and=20 > application developers would thank us if we provided an elegant way for= =20 > them to deploy applications with a veriety (and mixture) of GSS API=20 > implementations. >=20 > For simplicity in this email I've restricted my examples to C bindings=20 > and run-time shared object linkage. =A0However, I think that the concep= ts=20 > would apply to other interpreted language bindings (Java and C#)...=20 See above, particularly with respect to the extended inquiry functions. > Yes, I realize that Solaris has a gssapi.conf that allows per-mechanism= =20 > OID configuration. /etc/gss/mech And note that the OID really ought not have to be configured there, just the mech shared objects. Nico --=20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 12:08:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18895; Tue, 8 Mar 2005 12:08:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iEn-0001hj-TQ; Tue, 08 Mar 2005 12:11:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iBk-0001ae-UB; Tue, 08 Mar 2005 12:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8iBj-0001aK-V8 for kitten@megatron.ietf.org; Tue, 08 Mar 2005 12:08:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18791 for ; Tue, 8 Mar 2005 12:08:04 -0500 (EST) Received: from mailman.vintela.com ([192.41.60.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8iE6-0001fH-HS for kitten@ietf.org; Tue, 08 Mar 2005 12:10:37 -0500 Received: (qmail 2618 invoked by uid 6010); 8 Mar 2005 17:07:53 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.013002 secs); 08 Mar 2005 17:07:53 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 8 Mar 2005 17:07:52 -0000 Received: from hotrod.vintela.com ([10.1.40.120]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 8 Mar 2005 10:07:53 -0700 From: Matt Peterson Organization: Vintela, Inc To: Nicolas Williams Date: Tue, 8 Mar 2005 10:07:51 -0700 User-Agent: KMail/1.6.2 References: <200503071412.15639.mpeterson@vintela.com> <20050308053039.GK1007@binky.Central.Sun.COM> In-Reply-To: <20050308053039.GK1007@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200503081007.51986.mpeterson@vintela.com> X-OriginalArrivalTime: 08 Mar 2005 17:07:53.0777 (UTC) FILETIME=[5DD58A10:01C52401] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Nick, On Monday 07 March 2005 10:30 pm, Nicolas Williams wrote: > Incidentally, my individual submission I-D on stackable mechanisms > has become two KITTEN WG work items which I did submit on time to the > I-D repository, but which unfortunately did not get published on > time. > > One of those drafts provides for extended intquiry functionality that > could be used to detect, at run-time, the availability of whatever > the application needs. The extended inquiry functions don't solve > the problem that the C language doesn't have standard run-time > linker/loader environments though, but for most other languages it'll > do quite well. Right, I didn't see the original draft because I only searched on=20 "kitten" drafts. Would it be possible for you to email the now=20 separate kitten drafts? I'd like to give them a good read before I=20 comment further on this thread. > > Incidentally, I > > can see the need for GSSAPI mplementations (even for the same > > mechanism OID) needing to coexist and be configured on a > > *per-application* basis. > > I don't. I think there are important arguments (some more commercial than=20 technical) for allowing this kind of flexibility. With out it I think=20 the GSSAPI is less attractive to prospective 3rd party (non-OS)=20 implementors. Your extended inquiry functions might just do the trick=20 so I'll spare the rhetoric until I've had a chance to look through the=20 draft. > [...] > > In the end I think encouraging extension to the GSSAPI, as long as > > it follows proper namespace considerations, will be a very good > > thing for ubiquity of GSS. =A0If this is the case, system > > administrators and application developers would thank us if we > > provided an elegant way for them to deploy applications with a > > veriety (and mixture) of GSS API implementations. > > See above, particularly with respect to the extended inquiry > functions. > Again, I think it would be best to read through the draft describing the=20 extended inquiry functionality before I comment further. Thanks, =2D- Matt Peterson _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 12:48:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25142; Tue, 8 Mar 2005 12:48:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8irI-00033J-8V; Tue, 08 Mar 2005 12:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ioC-0001Cp-AT; Tue, 08 Mar 2005 12:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ioB-0001Ay-1O for kitten@megatron.ietf.org; Tue, 08 Mar 2005 12:47:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25045 for ; Tue, 8 Mar 2005 12:47:47 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8iqa-00032R-Jn for kitten@ietf.org; Tue, 08 Mar 2005 12:50:22 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j28HllZO024068 for ; Tue, 8 Mar 2005 09:47:47 -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 j28Hlkeu005667 for ; Tue, 8 Mar 2005 10:47:47 -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 j28Hk470001039; Tue, 8 Mar 2005 11:46:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j28Hjxcm001038; Tue, 8 Mar 2005 11:45:59 -0600 (CST) Date: Tue, 8 Mar 2005 11:45:59 -0600 From: Nicolas Williams To: Matt Peterson Message-ID: <20050308174559.GN1007@binky.Central.Sun.COM> Mail-Followup-To: Matt Peterson , kitten@ietf.org References: <200503071412.15639.mpeterson@vintela.com> <20050308053039.GK1007@binky.Central.Sun.COM> <200503081007.51986.mpeterson@vintela.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503081007.51986.mpeterson@vintela.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org Subject: Re: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Tue, Mar 08, 2005 at 10:07:51AM -0700, Matt Peterson wrote: > On Monday 07 March 2005 10:30 pm, Nicolas Williams wrote: [...] > Right, I didn't see the original draft because I only searched on > "kitten" drafts. Would it be possible for you to email the now > separate kitten drafts? I'd like to give them a good read before I > comment further on this thread. Sure. > > > Incidentally, I > > > can see the need for GSSAPI mplementations (even for the same > > > mechanism OID) needing to coexist and be configured on a > > > *per-application* basis. > > > > I don't. > > I think there are important arguments (some more commercial than > technical) for allowing this kind of flexibility. With out it I think > the GSSAPI is less attractive to prospective 3rd party (non-OS) > implementors. Your extended inquiry functions might just do the trick > so I'll spare the rhetoric until I've had a chance to look through the > draft. The C bindings for the GSS-API do not define an ABI, and I don't think we can define one now, so I'm afraid that you can't just switch between GSS-API implementations without recompiling C applications -- the best we can do is let each platform vendor define a C ABI for the GSS-API for their platform, then 3rd party GSS-API implementors could match said ABI and then, on platforms with run-time linker/loaders, one could switch between GSS implementations without recompiling. Some RTLDs support fancy features such as weak symbols, RTLD interfaces (e.g., dlopen(), dlsym(), etc...), filters, auxiliary filters, and so on. Where you have such features and a C ABI for the GSS-API then C applications can detect the availability of GSS extensions at run-time and act accordingly. That's all good, but we're not going to describe all that in any KITTEN Standards track document as C RTLD environments are not standardized. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 13:21:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28234; Tue, 8 Mar 2005 13:21:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jMv-0003l1-0i; Tue, 08 Mar 2005 13:23:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jIt-0003qC-GR; Tue, 08 Mar 2005 13:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8jIs-0003q7-0I for kitten@megatron.ietf.org; Tue, 08 Mar 2005 13:19:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28104 for ; Tue, 8 Mar 2005 13:19:30 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jLH-0003jI-Tt for kitten@ietf.org; Tue, 08 Mar 2005 13:22:05 -0500 Received: from [130.129.139.208] ([130.129.139.208]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j28IJUiQ015500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Mar 2005 13:19:31 -0500 (EST) Message-ID: <422DECFE.7080400@columbia.edu> Date: Tue, 08 Mar 2005 12:20:46 -0600 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org References: <200503071412.15639.mpeterson@vintela.com> <20050308053039.GK1007@binky.Central.Sun.COM> <200503081007.51986.mpeterson@vintela.com> <20050308174559.GN1007@binky.Central.Sun.COM> In-Reply-To: <20050308174559.GN1007@binky.Central.Sun.COM> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: Re: Flexibility in implementing and deploying GSS-API extensions. 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="===============1524045107==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a cryptographically signed message in MIME format. --===============1524045107== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080206070107010602030309" This is a cryptographically signed message in MIME format. --------------ms080206070107010602030309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > The C bindings for the GSS-API do not define an ABI, and I don't think > we can define one now Construction of an ABI for GSS is out of scope for this working group. The specification of an API for GSS is a rare exception for the IETF. The IETF will not take the step of defining a standard ABI for GSS or any other protocol implementation. Jeffrey Altman --------------ms080206070107010602030309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMzA4MTgyMDQ2WjAjBgkqhkiG9w0BCQQxFgQUIw56lKY4++8+dTMaRhu4I8FlRmIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAsmbh/S33X9CLjbRMajEkm3x8BQLg0fQwWrZDVdnr wJpJt91elz4YwZqrUinlP5xdih5ft3oOCnyROyVqGcmG7HM07u+UcItE8NFsqs4t5cn8/CqW ocZ6bmmjPYs850iKqmm4ZAHU2d2M47KnYEq+U9GfQ5iieHqCv0gXfSxl+nHgErZ2LG/yD/nq zV9zsRMIDvw7X4kb7Q+aUnJjIER3mRFf0Yfwhmu2oMA8J17naJrw1cH5coQdYqdNP2tGHw8P /FG6fiOeCYYuP8QmzwLMeAyJG7dOdtUL83cMSrmqD4hkCuUepzJTzOIulnsEHrU7JrkZuOrw opVw2nxPfTwWOgAAAAAAAA== --------------ms080206070107010602030309-- --===============1524045107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1524045107==-- From kitten-bounces@ietf.org Tue Mar 8 14:16:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03559; Tue, 8 Mar 2005 14:16:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kEb-00053C-Mh; Tue, 08 Mar 2005 14:19:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kBm-0000Hn-0o; Tue, 08 Mar 2005 14:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kBk-0000Hf-Hi for kitten@megatron.ietf.org; Tue, 08 Mar 2005 14:16:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03502 for ; Tue, 8 Mar 2005 14:16:09 -0500 (EST) Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kE6-000524-4y for kitten@ietf.org; Tue, 08 Mar 2005 14:18:43 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA06699; Tue, 8 Mar 2005 20:15:51 +0100 (MEZ) From: Martin Rex Message-Id: <200503081915.UAA15053@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 8 Mar 2005 20:15:52 +0100 (MET) In-Reply-To: <20050308174559.GN1007@binky.Central.Sun.COM> from "Nicolas Williams" at Mar 8, 5 11:45:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 8bit Cc: kitten@ietf.org Subject: Re: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > The C bindings for the GSS-API do not define an ABI, and I don't think > we can define one now, so I'm afraid that you can't just switch between > GSS-API implementations without recompiling C applications -- the best > we can do is let each platform vendor define a C ABI for the GSS-API for > their platform, then 3rd party GSS-API implementors could match said ABI > and then, on platforms with run-time linker/loaders, one could switch > between GSS implementations without recompiling. Although the GSS-API doesn't define an ABI, we have been successfully using binary plug'n'play with multiple third-party GSS-API mechanisms during the last 6 years. The definitions in the sample gssapi.h Header file in the GSS-API C-Bindings document provide most of the information for binary plug'n'play interoperability (at least if you ignore the "xom.h"-nonsense). > > Some RTLDs support fancy features such as weak symbols, RTLD interfaces > (e.g., dlopen(), dlsym(), etc...), filters, auxiliary filters, and so > on. Where you have such features and a C ABI for the GSS-API then C > applications can detect the availability of GSS extensions at run-time > and act accordingly. Our application uses runtime dynamic loading through dlopen()/dlsym() (and other platform-specific incarnations), and maybe except for such exotic platforms as IBM OS/400 and IBM OS/390 Open Edition, they're *extremely* similar. There are a few gotchas, particularly on some of the Unix platforms, related to the (s)brk-based heap management, global symbol space, symbol overloading, thread local storage and shared library initialization, which may cause one or the other headache. On some Unix platforms there are incompatibilities between single-threaded and multi-threaded code. If you're lucky the System-loader prevents incompatible combinations upfront (Reliant Unix), otherwise you may receive strange program malfunctions or crashes (Digital Unix, HP/Compaq Tru64). Some vendors seem to have silently abandoned traditional single-threaded code in newer OS Releases to hide the underlying problem (AIX,Solaris,Linux) in many/most/all scenarios. What Unix vendors unfortunately haven't fixed so far, is their habit of constantly making incompatible changes to their OS-Releases (system-libraries) and compilers, which amounts to a royal PITA. On Windows NT, I can ship a single DLL that works on all Win32-Platforms (starting with Win95A) up to W2K3, for use with single and multi-threaded Apps. For each of the Unix platforms we support, we have to provide between 3 and 10 different binaries... Unfortunately GNU GCC/glibc/libc++ is doing just as bad as all commercial Unix vendors. > > That's all good, but we're not going to describe all that in any KITTEN > Standards track document as C RTLD environments are not standardized. They may not be standardized, but they're sufficiently alike these days. Figuring out the right compiler/linker options and figuring out how shared library initialization works (which might be necessary if one wants to put C++ code into a shared library) is significantly harder that calling the platform-specific RTLD. My gsstest program contains a simple abstraction for thr RTLD for all of the platforms we support, and it seems that it can load the Kerberos shared libraries that Unix vendors are shipping these days (HP had initially goofed their 64-bit library, but they fixed it). So the lack of an official ABI might be much less of a roadblock than you think. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 15:12:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12293; Tue, 8 Mar 2005 15:12:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l6H-0007R6-1M; Tue, 08 Mar 2005 15:14:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l2o-0002mM-Hl; Tue, 08 Mar 2005 15:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8l2m-0002iw-Mv for kitten@megatron.ietf.org; Tue, 08 Mar 2005 15:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12103 for ; Tue, 8 Mar 2005 15:11:02 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8l5D-0007Op-Pd for kitten@ietf.org; Tue, 08 Mar 2005 15:13:37 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j28KB1ZO005494 for ; Tue, 8 Mar 2005 12:11:02 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j28KB1aa018564 for ; Tue, 8 Mar 2005 13:11:01 -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 j28K9JkE001378; Tue, 8 Mar 2005 14:09:19 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j28K9JTd001377; Tue, 8 Mar 2005 14:09:19 -0600 (CST) Date: Tue, 8 Mar 2005 14:09:19 -0600 From: Nicolas Williams To: Martin Rex Message-ID: <20050308200918.GP1007@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , mpeterson@vintela.com, kitten@ietf.org References: <20050308174559.GN1007@binky.Central.Sun.COM> <200503081915.UAA15053@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503081915.UAA15053@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org Subject: Re: Flexibility in implementing and deploying GSS-API extensions. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On Tue, Mar 08, 2005 at 08:15:52PM +0100, Martin Rex wrote: > Nicolas Williams wrote: [...] > Although the GSS-API doesn't define an ABI, we have been successfully using > binary plug'n'play with multiple third-party GSS-API mechanisms > during the last 6 years. > > The definitions in the sample gssapi.h Header file in the GSS-API > C-Bindings document provide most of the information for binary > plug'n'play interoperability (at least if you ignore the "xom.h"-nonsense). But we cannot standardize a C ABI for the GSS-API, not even on a per-platform basis because some vendors may not want to provide meaningful compatibility guarantees. > What Unix vendors unfortunately haven't fixed so far, is their habit > of constantly making incompatible changes to their OS-Releases > (system-libraries) and compilers, which amounts to a royal PITA. Mind you, Sun is very careful about such changes. See attributes(5) and the man pages for any interfaces you depend on to see what commitment Sun makes as to future compatibility. [...] > > That's all good, but we're not going to describe all that in any KITTEN > > Standards track document as C RTLD environments are not standardized. > > They may not be standardized, but they're sufficiently alike these days. [...] I think we can give implementors, and more specifically, platform implementors, guidance, but we really cannot provide normative text on this subject. > So the lack of an official ABI might be much less of a roadblock than > you think. It's not much of a roadblock for what you do, I know, but it is, IMO, a significant roadblock to inclusion of normative text in a standards track RFC. Now, when the C language gains standardized linker and/or RTLD interfaces and OS vendors commit to C ABIs for the GSS-API, then we can standardize a C ABI here. Until then the best we can do is give informative guidance on this. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 16:09:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19762; Tue, 8 Mar 2005 16:09:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8m03-000120-9H; Tue, 08 Mar 2005 16:12:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lwH-0005tv-Ut; Tue, 08 Mar 2005 16:08:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lwF-0005tk-Tz for kitten@megatron.ietf.org; Tue, 08 Mar 2005 16:08:24 -0500 Received: from newodin.ietf.org ([10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19629 for ; Tue, 8 Mar 2005 16:08:21 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D8lwF-00018o-Cd; Tue, 08 Mar 2005 16:08:23 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 08 Mar 2005 16:08:23 -0500 Cc: kitten@ietf.org Subject: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Kitten (GSS-API Next Generation) WG to consider the following document: - 'The Simple and Protected GSS-API Negotiation Mechanism ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kitten-2478bis-05.txt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 16:28:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21702; Tue, 8 Mar 2005 16:28:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mIe-0001bc-No; Tue, 08 Mar 2005 16:31:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mDK-00008z-70; Tue, 08 Mar 2005 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mDI-00008u-4M for kitten@megatron.ietf.org; Tue, 08 Mar 2005 16:26:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21404 for ; Tue, 8 Mar 2005 16:25:56 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mFi-0001Vc-UB for kitten@ietf.org; Tue, 08 Mar 2005 16:28:32 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id j28LPXPv066580 for ; Wed, 9 Mar 2005 08:25:34 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id j28LPXYB066579; Wed, 9 Mar 2005 08:25:33 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200503082125.j28LPXYB066579@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: kitten@ietf.org Date: Wed, 9 Mar 2005 08:25:33 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: Re: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Has there been any interop testing between multiple implementations yet? I offered our implementation to Larry for testing but I know he has been busy. -- Luke >From: The IESG >Subject: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard >To: IETF-Announce >Cc: kitten@ietf.org >Date: Tue, 08 Mar 2005 16:08:23 -0500 > >The IESG has received a request from the Kitten (GSS-API Next Generation) WG >to consider the following document: > >- 'The Simple and Protected GSS-API Negotiation Mechanism ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-22. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-kitten-2478bis-05.txt > > >_______________________________________________ >Kitten mailing list >Kitten@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/kitten -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 16:48:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23446; Tue, 8 Mar 2005 16:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mbv-000238-2Z; Tue, 08 Mar 2005 16:51:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mZA-0002x8-9B; Tue, 08 Mar 2005 16:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mZ5-0002wc-Uk for kitten@megatron.ietf.org; Tue, 08 Mar 2005 16:48:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23424 for ; Tue, 8 Mar 2005 16:48:29 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mbX-00022H-Ur for kitten@ietf.org; Tue, 08 Mar 2005 16:51:05 -0500 Received: from [130.129.139.208] ([130.129.139.208]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j28LmRM3007837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Mar 2005 16:48:29 -0500 (EST) Message-ID: <422E1DF9.3050605@columbia.edu> Date: Tue, 08 Mar 2005 15:49:45 -0600 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lukeh@padl.com References: <200503082125.j28LPXYB066579@au.padl.com> In-Reply-To: <200503082125.j28LPXYB066579@au.padl.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: kitten@ietf.org Subject: Re: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' 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: , Content-Type: multipart/mixed; boundary="===============1265594997==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a cryptographically signed message in MIME format. --===============1265594997== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010609010405060702070501" This is a cryptographically signed message in MIME format. --------------ms010609010405060702070501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Luke Howard wrote: > Has there been any interop testing between multiple implementations > yet? > > I offered our implementation to Larry for testing but I know he has > been busy. > > -- Luke Luke: I am working to arrange for interop testing during the IETF Last Call period. Please offer your implementation to Wyllys Ingersol at Sun Microsystems as well. Thanks. Jeffrey Altman --------------ms010609010405060702070501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMzA4MjE0OTQ1WjAjBgkqhkiG9w0BCQQxFgQUUZNyhduWbBQEtYdP39DwCMwPoPQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAVERZ6CwmgDKKWVJD+VejVT2/t0EfxXFUr5TCh1xe dwX0XyPU82FhIjgpEjjzPj23p8oT4zYlZ+LHRTBCCY4xeqMd4REVDlC2Z2gWrMl3vD3B1eHa NZqoEI531LE9p42hhbXJchfBMkZXtGFG1QTs+VWTC6HvNLl9/AJcMXVe1VeEdNWhsHyxXuwS w06QEedxWu4e6IU3X+paRUZCRUS9TbtGMDo5R4Zau9E62R2Ac53KaLEbTFkatMVxHoBA7kx8 fMG13jKPAeUjzmgs/GbbUXWxQbDgF7ztWRwn1a2UHImHAiAhMkOrLtFH0aUuZZpqg2aju7Rr nSSs8+ftOv2BtAAAAAAAAA== --------------ms010609010405060702070501-- --===============1265594997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1265594997==-- From kitten-bounces@ietf.org Tue Mar 8 16:59:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24563; Tue, 8 Mar 2005 16:59:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mmE-0002I8-RM; Tue, 08 Mar 2005 17:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mgB-0003pI-LW; Tue, 08 Mar 2005 16:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mgA-0003pD-FD for kitten@megatron.ietf.org; Tue, 08 Mar 2005 16:55:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24217 for ; Tue, 8 Mar 2005 16:55:47 -0500 (EST) Received: from wireless-130-129-135-90.ietf62.ietf.org ([130.129.135.90] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mib-0002BB-OF for kitten@ietf.org; Tue, 08 Mar 2005 16:58:23 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id E7E8AE0063; Tue, 8 Mar 2005 16:55:37 -0500 (EST) To: lukeh@padl.com References: <200503082125.j28LPXYB066579@au.padl.com> From: Sam Hartman Date: Tue, 08 Mar 2005 16:55:37 -0500 In-Reply-To: <200503082125.j28LPXYB066579@au.padl.com> (Luke Howard's message of "Wed, 9 Mar 2005 08:25:33 +1100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: kitten@ietf.org Subject: Re: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >>>>> "Luke" == Luke Howard writes: Luke> Has there been any interop testing between multiple Luke> implementations yet? That's not a requirement for proposed standard but it would be nice. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 18:01:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28702; Tue, 8 Mar 2005 18:01:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nkO-0003R8-Cv; Tue, 08 Mar 2005 18:04:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ngc-00035t-4T; Tue, 08 Mar 2005 18:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8nga-00035o-GW for kitten@megatron.ietf.org; Tue, 08 Mar 2005 18:00:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28641 for ; Tue, 8 Mar 2005 18:00:17 -0500 (EST) Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8nj2-0003PP-Mm for kitten@ietf.org; Tue, 08 Mar 2005 18:02:54 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id j28Mxw4T075257; Wed, 9 Mar 2005 09:59:58 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id j28MxvXa075256; Wed, 9 Mar 2005 09:59:57 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200503082259.j28MxvXa075256@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: hartmans-ietf@mit.edu References: <200503082125.j28LPXYB066579@au.padl.com> Date: Wed, 9 Mar 2005 09:59:57 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org Subject: Re: Last Call: 'The Simple and Protected GSS-API Negotiation Mechanism' to Proposed Standard X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>>> "Luke" == Luke Howard writes: > > Luke> Has there been any interop testing between multiple > Luke> implementations yet? > >That's not a requirement for proposed standard but it would be nice. Ah, my bad then. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Tue Mar 8 21:56:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16927; Tue, 8 Mar 2005 21:56:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8rPG-00081m-Sr; Tue, 08 Mar 2005 21:58:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rM0-0003Iu-9K; Tue, 08 Mar 2005 21:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rLy-0003Io-PL for kitten@megatron.ietf.org; Tue, 08 Mar 2005 21:55:18 -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 VAA16871 for ; Tue, 8 Mar 2005 21:55:16 -0500 (EST) Received: from [130.129.139.208] ([130.129.139.208]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j292tDBW014697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Mar 2005 21:55:17 -0500 (EST) Message-ID: <422E65DB.4010703@columbia.edu> Date: Tue, 08 Mar 2005 20:56:27 -0600 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Subject: IETF62 Kitten Working Group Meeting - Please participate 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="===============1093833504==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 This is a cryptographically signed message in MIME format. --===============1093833504== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040408010001050305070006" This is a cryptographically signed message in MIME format. --------------ms040408010001050305070006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The Kitten WG meeting will occur this Wednesday, 1:00-3:00 Central Standard Time. I would like to encourage folks to participate in the meeting, even if you are unable to attend in person. As usual, a Jabber chat room will be available so that folks not present in person can follow along and contribute. Information on joining the chat room is available at http://www.xmpp.org/ietf-chat.html In addition, there will be a one-way MP3 audio stream available, allowing remote participants to hear everything that goes on during the meeting. Information on the audio feed is appended to the end of this message. We will be meeting in the 'Duluth' room, which is currently channel 6. I will try to make the agenda and presentation slides available on the working group web page at http://web.mit.edu/jaltman/www/kitten/ietf62/ by the time the meeting starts. To this end, and to help the meeting run more smoothly, I would like to receive slides from all presenters by 10pm tonight (please let me know if you need more time). -- Jeff -----Forwarded Message----- From: Joel Jaeggli To: ietf@ietf.org Subject: MP3 audio streaming for IETF 62 Date: Sun, 06 Mar 2005 06:04:33 -0800 Just to recap: IETF 62 inagurates a new streaming effort. Instead of covering only two rooms it is our intention to cover all eight. Instead of multicast video delivery, unicast audio-only. It is our hope that this new effort will provide more useful timely and accessible access to the proceedings of the IETF as they happen. An internet draft decribing what the effort is intended to do, and the efforts up to this point is available at: http://www.ietf.org/internet-drafts/draft-jaeggli-ietftv-ng-00.txt Streams are delivered as 64Kb/s unicast-http-streamed mp3 audio, a popular and relativly standard way to deliver internet radio. Most platforms should have a client immediatly available (windows media player, quicktime, real, winamp, vlc, mplayer, zinf etc) capable of playing back the stream. Information on getting access to the streams is available from the webpage located at: http://videolab.uoregon.edu/events/ietf/ietf62.html Streaming begins March 7th 0900 CST 1500 GMT Regards Joel Jaeggli -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 --------------ms040408010001050305070006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMzA5MDI1NjI3WjAjBgkqhkiG9w0BCQQxFgQUg9j1DbN3jEUDNCpN0JH/joSXbfAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAAYCCUk7tdP/QSsnoTj9fCc+pDbKSRUckse1A2Ka9 b3sEbWghVWU2eWl07WaZCVfWlqPOoPTg41i53CS1RZrTga8W9N1M8soP1cXr2L3d+Fevgn/n 4rEU9SGFlfy37munCCe7qc14UuDUdgKIqqEF9/DGxzziumTqHplZXBlisLHLQnHQntsj0G/V qyexWYhI4fHsJkB7792mEFa/lmu5XIFJ74QJ8OJlhPn7bZ8JN1yihyZ/U9Ox+2n1UWY3U2b5 Dz5d8ILPsnKnHMv/piLXGyAAfbJAJKjS/IrMl0iKUDhfUkqJpnbbfFbUkZrnKXiz7OuXQmO1 WRCvoS6v1FCH9QAAAAAAAA== --------------ms040408010001050305070006-- --===============1093833504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1093833504==-- From kitten-bounces@ietf.org Wed Mar 9 22:38:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25279; Wed, 9 Mar 2005 22:38:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9EY1-0002kS-Qh; Wed, 09 Mar 2005 22:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9EUt-0002YZ-G3; Wed, 09 Mar 2005 22:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9EUs-0002YU-LH for kitten@megatron.ietf.org; Wed, 09 Mar 2005 22:38:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25241 for ; Wed, 9 Mar 2005 22:38:00 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9EXa-0002ja-IZ for kitten@ietf.org; Wed, 09 Mar 2005 22:40:51 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2A3bxX8003467; Wed, 9 Mar 2005 20:37:59 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2A3bwQp020682; Wed, 9 Mar 2005 22:37:58 -0500 (EST) From: Bill Sommerfeld To: Sam Hartman In-Reply-To: References: Content-Type: text/plain Message-Id: <1110425871.9167.2.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 09 Mar 2005 21:37:53 -0600 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: New naming draft submitted X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit On Sun, 2005-02-20 at 15:42, Sam Hartman wrote: > I've submitted draft-ietf-kitten-gss-naming-01.txt. I think this one > is readyish for last-call, but would like to ask Nico and Martin to > review it and tell me what's broken and then consider the next > revision for a real last call. Some text I wrote for a (now expired, hopefully soon to be resurrected) draft on IPsec API requirements took a slightly different approach at the question of naming. Here's an excerpt: 8. WHO This is perhaps the most tricky part of the problem. Existing IPsec key management protocols provide a wide variety of authentication methods -- preshared secrets, public key, Kerberos, X.509 certificates, etc., There are several potential uses for names provided by IPsec: 8.1 OPAQUE IDENTITY It should be possible to determine that two IPsec-protected communications conducted within a short to medium time frame were with the same authenticated peer; it should be possible to use a received identity to initiate a communication back to that identity. Example cases: connectionless replies; linking ftp control and data connections. The application need only be able to determine if two identities are equal. 8.2 AUDITING It should be possible for an application to construct a log entry naming the peer. 8.3 ACCESS CONTROL While policy rules may allow traffic to be blocked entirely, it's often necessary for a program to provide services to mutually suspicious clients. It should be possible for a service to make appropriate access control decisions based on the identity of the peer; in addition, the peer's certificate may contain interesting SubjectAltName or other attributes which may have relevance for the application; it may also be possible for the system to derive other attributes from the peer's identity. 8.4 ATTRIBUTES/CREDENTIALS [Mission Creep Alert] In many cases, an application is not so much interested in the peer's name, but rather in some other attribute of the peer. Exactly where and how to map from long-term keys to these attributes needs to be nailed down; it may well be that this is best left as a local issue. Some of this is probably out of scope for the working group; however, we should not preclude others from building on this. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Mar 10 15:44:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04510; Thu, 10 Mar 2005 15:44:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9UYn-0006OJ-2m; Thu, 10 Mar 2005 15:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UV3-0003IC-Ik; Thu, 10 Mar 2005 15:43:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9UV2-0003I4-8B for kitten@megatron.ietf.org; Thu, 10 Mar 2005 15:43:16 -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 PAA04330 for ; Thu, 10 Mar 2005 15:43:13 -0500 (EST) Received: from [130.129.139.208] ([130.129.139.208]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j2AKhAFC000198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2005 15:43:10 -0500 (EST) Message-ID: <4230B1AB.202@columbia.edu> Date: Thu, 10 Mar 2005 14:44:27 -0600 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Cc: Sam Hartman , Russ Housley Subject: IETF62 GSS API Next Generation (Kitten) WG Summary Report 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="===============0629939188==" Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a cryptographically signed message in MIME format. --===============0629939188== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010806040109080409040706" This is a cryptographically signed message in MIME format. --------------ms010806040109080409040706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kitten met on Wednesday afternoon at IETF62. There were approximately 30 attendees in the room plus we were joined by several participants using a combination of Audio Stream and Jabber. Presentations are available: http://web.mit.edu/jaltman/www/kitten/ietf62/ At the meeting we were happy to announce that draft-ietf-kitten-2478bis-05 has been sent to the IESG and will be in IETF Last Call until March 22. There are two other drafts, draft-ietf-kitten-krb5-gssapi-prf-02 and draft-ietf-kitten-gssapi-prf-02 which are ready for WG Last Call. Nico Williams updated the working group on the status of the drafts: draft-ietf-kitten-extended-mech-inquiry draft-ietf-kitten-gssapi-channel-bindings draft-ietf-kitten-gssapi-domain-based-names draft-ietf-kitten-gssapi-extensions-iana draft-ietf-kitten-gssapi-store-cred draft-ietf-kitten-gssapi-v3-guide-to draft-ietf-kitten-krb5-gssapi-domain-based-names draft-ietf-kitten-stackable-pseudo-mechs We need review from the group. Sam Hartman updated us on the status of draft-ietf-kitten-gss-naming One more draft will be issued to include feedback received and then send it to WG Last Call. The editors of the Java/C# drafts could not attend. The chair provided an update on drafts: draft-ietf-kitten-gssapi-rfc2853-update-for-csharp draft-ietf-kitten-rfc2853bis The current drafts contain changes to be applied to rfc 2853. The next step is to merge the two existing drafts with the contents of rfc 2853 and publish a new draft to obsolete rfc 2853. The Milestones due this month on an initial draft of an informational document pulling together notes from the mail archive of proposed clarifications to GSS API Version 2 Update 1. Matt Peterson volunteered to assign this task to a member of his staff. The working group also held a discussion on the possibility of merging the construction of mechanisms for GSS, SASL and EAP. Action Items: * Sam Hartman to submit revision to GSS Naming draft. * Chair to ask Martin Rex to review GSS Naming draft. * Chair to issue WG Last Call on GSS Naming draft after review (if appropriate). * Chair to ask Uri Blumenthal to review PRF drafts. * Chair to issue WGLC for PRF drafts * Chair to update milestones --------------ms010806040109080409040706 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMzEwMjA0NDI3WjAjBgkqhkiG9w0BCQQxFgQUSH8vP+6MROQvPIV9ZOqlqnhNWVYw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEALC5sWbEockhdibxNt6zkizRhZPuyoGhmZqpVROVa iMFJwFtsppmwPbbr+SyfiAdvaundFaDzP1RX2bL6dxR5OMmV2klT+aPtpi6sXxEld2MvibE/ oBSpuZ+Wa+jJGvAzdLSRAMhcJ6u1iTqzfAxKMNdFDGfWmhjuhDiMutDVirB+2iGvGHTRkZfQ KKMnE9Sj7mO6hXFlfDw/MQWs8R0FFusJl3njpGnCMc9BMUFCJg+7jEcJ5jmeerq+FSx4sBR4 55pykfWq3XxCrvEpmC0ymnak5yw2m6RkpoVVOFfUnTDTZqfFAbiNfRHIO4GqpgZxDYTI47Wc FCuHVQc4GZ++XAAAAAAAAA== --------------ms010806040109080409040706-- --===============0629939188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0629939188==-- From kitten-bounces@ietf.org Thu Mar 10 20:12:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28415; Thu, 10 Mar 2005 20:12:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Ykh-0002UZ-QL; Thu, 10 Mar 2005 20:15:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9YhT-0001Ue-Rt; Thu, 10 Mar 2005 20:12:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9YhS-0001UW-BV for kitten@megatron.ietf.org; Thu, 10 Mar 2005 20:12:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28412 for ; Thu, 10 Mar 2005 20:12:18 -0500 (EST) Received: from mailman.vintela.com ([192.41.60.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9YkM-0002U9-Fz for kitten@ietf.org; Thu, 10 Mar 2005 20:15:22 -0500 Received: (qmail 28266 invoked by uid 6010); 11 Mar 2005 01:12:09 -0000 Received: from mpeterson@vintela.com by mailman.vintela.com by uid 6008 with qmail-scanner-1.20 (clamuko: 0.65. spamassassin: 2.63. Clear:RC:1(10.1.10.5):. Processed in 0.012734 secs); 11 Mar 2005 01:12:09 -0000 Received: from unknown (HELO mail.vintela.com) (10.1.10.5) by mailman.vintela.com with SMTP; 11 Mar 2005 01:12:09 -0000 Received: from hotrod.vintela.com ([10.1.40.120]) by mail.vintela.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 18:12:09 -0700 From: Matt Peterson Organization: Vintela, Inc To: Jeffrey Altman , kitten@ietf.org Date: Thu, 10 Mar 2005 18:12:08 -0700 User-Agent: KMail/1.6.2 References: <4230B1AB.202@columbia.edu> In-Reply-To: <4230B1AB.202@columbia.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200503101812.08165.mpeterson@vintela.com> X-OriginalArrivalTime: 11 Mar 2005 01:12:09.0854 (UTC) FILETIME=[596E89E0:01C525D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Subject: Vintela's particpation in Kitten. X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Greetings, In a previous email Jeff suggested that I might want to make a quick introduction and write a little about why Vintela has is interested in Kitten. The short (marketing) version is that Vintela writes software for Unix (Linux, Solaris, HPUX, AIX and other flavors) that allows Unix to integrate with Microsoft backend solutions (Active Directory, Group Policy, SMS, and MOM). Microsoft has made an equity investment in Vintela and we've maintained a good relationship working with Microsoft in numerous accounts that deploy Unix software with Microsoft Solutions. Vintela has always been interested in standards we've done quite a bit in with standards both in implementation and participation in standards bodies. Our particular interest in Kitten is provide input and resources so that GSSAPI might become more common in application software. Too many developers generate mechanism specific code which makes it difficult to use applications with 3rd party security solutions (like Vintela's authentication product -- which contains a Microsoft-centric kerb GSSAPI implementation). On Thursday 10 March 2005 01:44 pm, Jeffrey Altman wrote: > The Milestones due this month on an initial draft of an informational > document pulling together notes from the mail archive of proposed > clarifications to GSS API Version 2 Update 1. Matt Peterson > volunteered to assign this task to a member of his staff. I've asked David Leonard (dleonard@vintela.com) to become involved as a resource for Kitten. Dave Leonard is based in Brisbane Australia. He's a Unix software engineer with good OSS development experience and the right personality for IETF work. He's even volunteered to take on the task of look through the mail archives so that he can learn a bit of history and come up to speed on the issues. Dleonard will also be the resource that will work on a draft that follow-up Sam's draft-ietf-kitten-gss-naming-01.txt if (or when) it is necessary. On this note... Dleonard is ready to start. Jeff, can you please forward him the links to the archives, and the start/end dates so he doesn't browse a bunch irrelevant archive posts. We'll also need a bit of direction on the best way to proceed with a possible follow-up to draft-ietf-kitten-gss-naming-01.txt Cheers, -- Matt Peterson _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Mar 14 18:09:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02124; Mon, 14 Mar 2005 18:09:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAykZ-00025z-M0; Mon, 14 Mar 2005 18:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAyg1-0007PK-Eb; Mon, 14 Mar 2005 18:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAyfz-0007P8-8h for kitten@megatron.ietf.org; Mon, 14 Mar 2005 18:08:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02007 for ; Mon, 14 Mar 2005 18:08:40 -0500 (EST) Received: from cpe-24-28-76-59.austin.res.rr.com ([24.28.76.59] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAyjg-000255-Dg for kitten@ietf.org; Mon, 14 Mar 2005 18:12:33 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 6ACBAE0063; Mon, 14 Mar 2005 18:08:22 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Date: Mon, 14 Mar 2005 18:08:22 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Meeting on 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Nico and I got together today to discuss naming. We were mostly trying to focus on API considerations for the name attributes proposal. We didn't end up getting that far because we ended up running into some more fundamental design issues. We believe there are roughly three types of attributes: * Attributes added/set on a name * Attributes communicated from the context/credentials * Attributes mapped from other attributes. There are two types of mapped attributes. The first are mechanism-specific expansions of container attributes. For example the MS PAC might get split into attributes for user sids, group sids, etc. The other type of mapped attribute tends to be platform or attribute specific. For example, Nico wants a way of mappying a gss name into uids and gids of the local platform based on the attributes of that name. You might have local policy that said to prefer some NFS-based authzdata for Kerberos, then to prefer some PAC based data, then to try an attribute certificate, etc. We assume that attributes are labeled by OIDs. It is critical that the OID not convey any information about how trusted the name is. For example, there might be an OID for some Kerberos authorization data element. It might be possible to get the same OID through a SubjectAltName in a cert, or through some other mechanism. Trust of name attributes will be critical. Trust levels include: * Asserted by the peer * Set locally * Authenticated by the credential * Mapped from an authenticated attribute by an authenticated mechanism It may be necessary to discuss which specific entity is authenticting authentic assertions. We hope not. note that Kerberos authorization data is typically only asserted by the peer. Authorization data issued by the KDC or some other authority where the signature is verified can be trusted as authenticated by the credential. Similarly, an attribute certificate would be an assertion by the peer unless the CA is trusted and the attribute cert is bound to a subject of a public key cert used in the authentication. We discussed iterators for the naming API. Ideally we'd like to have an interface that returns a set of attribute names and then for each of those have operations to get the values associated with the attribbute. I'm going to go talk to UI designers and see how well this model can be made to interact with object frameworks etc. I suspect we may have problems in this regard. We're not clear that the second type of mapped attribute (mapping gss names to platform attributes) belongs in the GSS name proper. It may be a good idea to have a similar set of APIs along side the naming APIs to deal with this case. We realize that container attributes will require particular care especially in how their contents are expanded. We believe that the representation of names should not be language specific. In particular, we believe that the values of attributes should be network representations, not pointers to language-binding specific structures. Along with this, we only believe that name attributes having network representations are suited for use with GSSAPI. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Mon Mar 14 21:56:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24640; Mon, 14 Mar 2005 21:56:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2IE-0004NP-NH; Mon, 14 Mar 2005 22:00:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2CQ-0006qU-F1; Mon, 14 Mar 2005 21:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2CP-0006qP-Je for kitten@megatron.ietf.org; Mon, 14 Mar 2005 21:54:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24432 for ; Mon, 14 Mar 2005 21:54:23 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2G8-0004FF-GX for kitten@ietf.org; Mon, 14 Mar 2005 21:58:17 -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 j2F2sMNV002919 for ; Mon, 14 Mar 2005 18:54:22 -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 j2F2sLeu028595 for ; Mon, 14 Mar 2005 19:54:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j2F2qZos005471; Mon, 14 Mar 2005 20:52:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2F2qYrJ005470; Mon, 14 Mar 2005 20:52:34 -0600 (CST) Date: Mon, 14 Mar 2005 20:52:34 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20050315025234.GX1007@binky.Central.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.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: kitten@ietf.org Subject: Re: Meeting on 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@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Thank you for this wonderful summary of our discussions on naming! Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Wed Mar 30 13:24:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26431; Wed, 30 Mar 2005 13:24:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhz2-0007L5-CZ; Wed, 30 Mar 2005 13:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhr2-0004Um-Qk; Wed, 30 Mar 2005 13:23:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGhr1-0004Uc-2k for kitten@megatron.ietf.org; Wed, 30 Mar 2005 13:23:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26363 for ; Wed, 30 Mar 2005 13:23:44 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGhxx-0007Ju-Hi for kitten@ietf.org; Wed, 30 Mar 2005 13:30:58 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j2UINhRr004822 for ; Wed, 30 Mar 2005 11:23:43 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j2UINheu010149 for ; Wed, 30 Mar 2005 11:23:43 -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 j2UILkEF015959 for ; Wed, 30 Mar 2005 12:21:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2UILjkf015958 for kitten@ietf.org; Wed, 30 Mar 2005 12:21:45 -0600 (CST) Date: Wed, 30 Mar 2005 12:21:45 -0600 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20050330182145.GJ10412@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: I-Ds rescued from limbo X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad The following I-Ds have finally become available in the IETF I-D repository: - draft-ietf-kitten-extended-mech-inquiry-00.txt - draft-ietf-kitten-stackable-pseudo-mechs-00.txt Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@ietf.org Thu Mar 31 13:09:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18288; Thu, 31 Mar 2005 13:09:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4E3-0000jU-EF; Thu, 31 Mar 2005 13:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH45T-000202-CT; Thu, 31 Mar 2005 13:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH45R-0001zx-Jd for kitten@megatron.ietf.org; Thu, 31 Mar 2005 13:08:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18144 for ; Thu, 31 Mar 2005 13:08:06 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH4CY-0000ec-IY for kitten@ietf.org; Thu, 31 Mar 2005 13:15:34 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2VI80NV025778 for ; Thu, 31 Mar 2005 10:08:00 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j2VI7uac015870 for ; Thu, 31 Mar 2005 11:07:56 -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 j2VI5xqL006024; Thu, 31 Mar 2005 12:05:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j2VI5sHm006023; Thu, 31 Mar 2005 12:05:54 -0600 (CST) Date: Thu, 31 Mar 2005 12:05:54 -0600 From: Nicolas Williams To: ietf-krb-wg@anl.gov Message-ID: <20050331180553.GQ16131@binky.Central.Sun.COM> Mail-Followup-To: ietf-krb-wg@anl.gov, kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org Subject: enctype negotiation and GSS naming extensions X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kitten-bounces@ietf.org Errors-To: kitten-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At MN I said I did not oppose Larry's Kerberos enctype negotiation proposal. I'm less sure now. You may recall that at the interim meeting at Boulder we decided that extensions would add a typed hole, distinct from authorization-data, to the authenticator and AP-REP. We'd argued over whether it was proper to overload authorization-data and decided that it was not. Larry's proposal overloads authorization-data by using it to transport a client's enctype proposal to the server. I am still inclined to agree that enctype negotiation is an allowable overloading of authorization-data, but the GSS-API naming extensions we're discussing at the KITTEN WG give me pause. Basically, whenever we add an authorization-data type that isn't really about authorization then all things that might interpret authorization-data need to know what to make of them. At the very least non-authorization AD types must be non-critical (i.e., must be in AD-IF-RELEVANT AD containers). That's clear and surely we all agree on that point. But if there's a generic API to get at the authorization-data from an authenticator or ticket, then how do we ensure that non-authorization- related AD elements aren't passed to the application, particularly when the API and the application both need to be able to deal with unknown AD types? Or is this not an issue? That is, apps that make use of such extended naming APIs should just ignore unknown, non-critical name attributes? And how would we design enctype negotiation if we could start with extended Kerberos V, rather than rfc1510/clarifications Kerberos V? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten