From owner-ietf-cat-wg@lists.Stanford.EDU Mon Aug 2 15:15:19 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28363 for ; Mon, 2 Aug 2004 15:15:18 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i72J8lUa012289 for ietf-cat-wg-out720680; Mon, 2 Aug 2004 12:08:47 -0700 (PDT) Received: from serrano.cc.columbia.edu (IDENT:cu41754@serrano.cc.columbia.edu [128.59.59.142]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i72J8gNK012283 for ; Mon, 2 Aug 2004 12:08:42 -0700 (PDT) Received: from [130.129.131.253] (opene-130-129-131-253.ietf60.ietf.org [130.129.131.253] (may be forged)) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i72J8dFJ010990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Aug 2004 15:08:41 -0400 (EDT) Message-ID: <410E912A.2080708@columbia.edu> Date: Mon, 02 Aug 2004 12:08:26 -0700 From: Jeffrey Altman Organization: No Longer 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) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: Kitten Working Group Today - Please join via Jabber X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020003050003010602000909" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms020003050003010602000909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The Kitten Working Group is taking place today at 15:30 PDT.
Remote participation in the working group will be possible via
the Jabber protocol.

The conference server is "ietf.xmpp.org". The room is "Kitten".

Please make an effort to participate.

Thanks

Jeffrey Altman

--------------ms020003050003010602000909 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 DxcNMDQwODAyMTkwODI2WjAjBgkqhkiG9w0BCQQxFgQUC276nZ+rCVUpVs68Nkwhqrstd3cw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAxoM6WhDZJQUWlZ4c+LnUomS8oq6JrL6obXYOV6Px eqGe1V0UPyd2XT42ZNkJDP+ndyMeZqFMGcov8C/a3+O62yaRi6yYMXvlGqAOufK9RvKapnp3 tmM6cTm316yW/Dhv/XyWQaKTtPMnv88JO/X+9EixpTDta9ZjVv6CuocVrlwuuQcai0YHkRj/ 3R+rZt2JREdabO7qtlbN5T9upx+pxIwDPndZL9hazajzTv2jR3OyUzC2R/3XNBBgtlkDDXiU 206JUYHgJx+rYEEe6pF+hrfpMZV2DFPV0h7iw3m/gyPQHE+adtns0E0mevfHBw9ZEwEI7tdD 3l2fZsVWnWXLegAAAAAAAA== --------------ms020003050003010602000909-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Aug 2 20:37:22 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17931 for ; Mon, 2 Aug 2004 20:37:21 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i730YF1t013949 for ietf-cat-wg-out720680; Mon, 2 Aug 2004 17:34:15 -0700 (PDT) Received: from pecan.cc.columbia.edu (IDENT:cu41754@pecan.cc.columbia.edu [128.59.59.178]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i730Y8NK013943 for ; Mon, 2 Aug 2004 17:34:09 -0700 (PDT) Received: from [130.129.131.132] (opene-130-129-131-132.ietf60.ietf.org [130.129.131.132]) (user=jaltman mech=PLAIN bits=0) by pecan.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i730Y5PP002497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Aug 2004 20:34:06 -0400 (EDT) Message-ID: <410EDD76.7080901@columbia.edu> Date: Mon, 02 Aug 2004 17:33:58 -0700 From: Jeffrey Altman Organization: No Longer 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) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: Jabber Log/Minutes from IETF-60 Kitten BOF X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030407090701090204050905" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030407090701090204050905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you to Ken Hornstein for being scribe.

[14:45] jaltman has entered the room.
[14:45] kitten
[14:45] jas has entered the room.
[14:45] hartmans has entered the room.
[14:45] pbh has entered the room.
[14:56] hartmans has left the room.
You have been disconnected.
You have been disconnected.
You have been disconnected.
You have been disconnected.
Reconnected.
[15:22] jaltman has entered the room.
[15:22] kitten
[15:22] jas has entered the room.
[15:22] pbh has entered the room.
[15:28] rpayn422 has entered the room.
[15:31] peterd has entered the room.
[15:31] kenh has entered the room.
[15:32]<kenh> Jeff Altman is opening the BOF.
[15:32] leg has entered the room.
[15:33]<kenh> Introduction
[15:34]<kenh> Four years since CAT closed, wide deployment has revealed RFCs 2743 and 2744 to be less well-defined that they could be.
[15:34] hartmans has entered the room.
[15:34]<kenh> E.g.: Credentials management, thread safety, channel bindings, ABI stability, mechanism specific extensibility, support for mechanisms without a single canonical name.
[15:35] raeburn has entered the room.
[15:35] tlyu has entered the room.
[15:35]<kenh> Jeff mispronounces my last name, as usual.
[15:36]<kenh> GSS-SPNEGO is flawed; it's not possible to creat interoperable implementations.
[15:36] warlord has entered the room.
[15:36]<kenh> Channel bindings must be definedd to support crypto channels such as TLS, IPSec, SSH and a new GSS mechanism to negotiate channel bindings must be defined.
[15:37]<kenh> Language bindings for C# are desired.
[15:37] dumdidum has entered the room.
[15:37]<kenh> What this BOF is going to try to do is to present some of the problem spaces, and see if enough work is available/appropriate for a WG.
[15:38] leifj has entered the room.
[15:38] jhutz has entered the room.
[15:39]<kenh> First presentation: Doug Engert, Argonne National Labs, presenting about Global Grid Forum & GSS extensions developed as part of the GGF.
[15:39] mlshore has entered the room.
[15:39]<kenh> GGF formed about 5-6 years ago (http://www.ggf.org)
[15:40]<kenh> Standardization of Grid Computing, 400 Organizations/50 countries, next meeting in Brussels.
[15:40]<jas> [are presentations available online, for us participating over internet only?]
[15:40]<kenh> (To jas: Sorry, I don't believe so)
[15:40]<kenh> Characteristics of Grid Computing:
[15:41]<kenh> More than traditional client/server or distributed computing.
[15:41]<kenh> User-to-user, peer-to-peer authentication.
[15:41]<rpayn422> Can they be made available? (As a general question.)
[15:41]<kenh> Users may start servers/services, and two-way delegation.
[15:41]<hartmans> Yes but probably not in real time
[15:41]<kenh> The Globus GSI (http://www.globus.org)
[15:42]<kenh> A GSS-API implementation using TLS/SSL with X.509 certs.
[15:42]<kenh> Delegation using RFC-3820 "Internet X.509 PKI Proxy Certificate Profiles", similar to forwarded Kerberos tickets.
[15:42]<kenh> Initiator and accepter use similar creds.
[15:43]<kenh> Allows user-to-user and self-to-self authentication.
[15:43]<kenh> (e.g., file transfer between two nodes, using a proxy cert)
[15:44] mlshore has left the room.
[15:44]<kenh> GSS-API Extensions GFD-E.024
[15:44]<kenh> http://www.ggf.org/documents/GWD-I-E/GFD-E.024.pdf
[15:45]<kenh> http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-01.txt
[15:45]<kenh> Describe GSS extensions adopted by GGF.
[15:45]<kenh> Details of extensionss:
[15:45]<kenh> Credential import/export.
[15:45]<kenh> Delegation at any time/direction.
[15:45]<kenh> Credential extensions handling.
[15:46]<kenh> Setting of context options.
[15:46] mstjohns has entered the room.
[15:46] sommerfeld has entered the room.
[15:47]<kenh> Credential import/export:
[15:47]<kenh> APIs: gss_export_cred(), gss_import_cred()
[15:47]<kenh> Credentials to a buffer, for things like application saves/reloads.
[15:47]<kenh> Credentials could be saved for use by non-GSS-API apps.
[15:48]<kenh> Applications must be able to accept mmultiple connections, and save/reload delegated creds not tied to process or thread.
[15:48]<kenh> Implemented for GSI and MIT Kerberos.
[15:49]<kenh> (Missing piece from MIT Kerberos is how to export creds within the GSSAPI)
[15:49]<kenh> Concerns with Nico Williams "Creds Store" document:
[15:49]<kenh> Needs more control by application over delegated creds.
[15:49]<kenh> (Uses implicit cred store, but does not address explicit creds stores under application control)
[15:50]<kenh> Refers to GGF GSI extensions implying that the mech needs knowledge of envionment
[15:50]<kenh> Uses Simon's OpenSSH mods as example, but they use KRB5CCNAME environement variable.
[15:51]<kenh> (Nico Wiilliams pointed out at this point that OpenSSH is a bad example, and it doesn't have to be done that way)
[15:51] admcd has entered the room.
[15:51]<kenh> Delegation at any time:
[15:51]<kenh> gss_init_delegation(), gss_accept_delegation()
[15:51]<kenh> Allows credential delegatin after context establishment, may be different creds, delegation is in either direction.
[15:52]<kenh> Credential extensions handling:
[15:52]<kenh> Get mechanism or OID-specific information from credentials. Possible uses: Certificate extensions/Kerberos authorization data.
[15:53]<kenh> Use OID to avoid mechanism API calls.
[15:53] leifj has left the room.
[15:53]<kenh> Setting of context options:
[15:53]<kenh> gss_set_context_option_call()
[15:53]<kenh> Set options for context using an OID. E.g.: Limited delegation, Kerberos forwardable flag, what to do when context expires, set encryption options.
[15:54]<kenh> Additional functional desired:
[15:54]<kenh> Token Framing for every token.
[15:54] avri has entered the room.
[15:54]<kenh> Levels of verbosity with gss_display_status().
[15:54]<kenh> Need a simple authz frunction to access krb5_kuserok() or the gridmap file.
[15:55] rlbob has entered the room.
[15:55]<kenh> The End.
[15:55]<kenh> No questions at this time.
[15:56]<kenh> Jeff Altman: the GGF people have touched on issues that numerous people have discovered (e.g., credential handling, authorization issues).
[15:57]<kenh> jaltman: Perhaps given our experience, we can tackle broader problems with more comfort than we had in the past.
[15:57]<kenh> First presentation by Sam Hartman (no slides)
[15:57]<kenh> Sam: GSS-API has concept called channel bindings.
[15:58]<kenh> Want to be able to make an assertion that the channel you are communication over is the same one you authenticated across.
[15:58]<kenh> GSS-API authors had the concept that you might want to bind to a crypto key you're using for encryption, but they didn't really follow through.
[15:59] ohm has entered the room.
[15:59]<kenh> In RFC 2743, GSSAPI split into language-independent and language-dependent sections.
[15:59] leg has left the room.
[15:59] leg has entered the room.
[15:59] leg has left the room.
[15:59]<kenh> The language-independent portion treated channel bindings as an opaque blob, but it's the sort of thing that mechanisms want to peek into.
[16:00]<kenh> The C-language bindings specified a IP address, and the format for the IP address.
[16:01]<kenh> The revision to the base specification refers to the C-language bindings and says, "Look her to see how channel bindings work". obviously, this is odd.
[16:02]<kenh> The language bindings defines a C structure, which is not a good presentation layer (other minor problems with channel bindings).
[16:02]<kenh> Sam's second presentation: Naming issues with GSSAPI
[16:02]<kenh> (works well for some apps, not so well for others).
[16:02]<kenh> Authentication/Authorization:
[16:03]<kenh> Authentication generates assertions as input to authorizations
[16:03]<kenh> Authorization uses these assertions to make access decisions.
[16:03]<kenh> GSS AUthentication model:
[16:03]<kenh> GSSAPI asserts an authenticated name to both peers.
[16:04]<kenh> All input forms of this name can be canonicalized to a single form which is binary comparable.
[16:04] pbh has left the room.
[16:04]<kenh> Authorization with GSSAPI names:
[16:04] pbh has entered the room.
[16:04] pbh has left the room.
[16:04]<kenh> Canonical forms can be placed on ACLs.
[16:04]<kenh> Without authentication a peer can generate canonical forms.
[16:04]<kenh> More complicated structures.
[16:04]<kenh> You might want to do more complicated things (directories, groups).
[16:04] pbh has entered the room.
[16:05]<kenh> Difficulty of Canonical Forms:
[16:05]<kenh> Names change over time.
[16:05]<kenh> Some mechanisms have no canonical representations.
[16:06] admcd has left the room.
[16:06]<kenh> (e.g., what is the canonical name out of an X.509 cert?)
[16:08] leg has entered the room.
[16:08]<kenh> SubjectAltName creates problems for certificates.
[16:08]<kenh> (e.g., what about email address? Does the GSSAPI not get access to that because it's not part of your DN?)
[16:08]<kenh> (Comment from Bob Morgan: Some cases it's desirable to have the authentication name have only short-term value)
[16:09]<kenh> (comment from Bill Sommerfeld: I realized that if you looked at the X.509 extended key usage attribute, the cert became a lot more understandable, which means that should also be part of the cert's name)
[16:09]<kenh> Desire for new Authentication Assertions:
[16:09]<kenh> Membership in groups.
[16:09]<kenh> Liberty/SAML require more complex assertions
[16:09] ohm has left the room.
[16:09]<kenh> Keeping names the same as people move in organizations.
[16:10]<sommerfeld> correction: If you look at X.509 EKU as part of the principal name, the justification for its existance became reasonable...
[16:12]<kenh> People that have done large Kerberos deployments don't want to look up authz data in directories, they want the info in tickets.
[16:12]<kenh> (Comment from Doug Engert: line between groups and names isn't black & white)
[16:12]<kenh> Possible solutions:
[16:12]<kenh> Name attributes
[16:12]<kenh> Extensions to gss_canonicalize_name()
[16:12]<kenh> Credential extensions.
[16:13]<kenh> (Name attributes: Reviewed by Martin Rex, he brough up a number of things that were already in there).
[16:14]<kenh> Extensions to gss_canonicalize_name() - pretty close to name attributes.
[16:14] Kurt has entered the room.
[16:15]<kenh> (Comment from Nico Williams): Like first two solutions (name attributes, extensions to gss_canonicalize_name())
[16:15] ohm has entered the room.
[16:15]<kenh> Presentation from Nico Williams: Channel Bindings
[16:15]<kenh> Introduction:
[16:16] rpayn422 has left the room.
[16:16]<kenh> Channel bindings allow session protecction at one network layer to be delegated to session protection at another by proving there is no MITM in the lower layer.
[16:16] rpayne has entered the room.
[16:16]<kenh> Why? Performance plus security.
[16:17]<kenh> Concept first described in GSS-APIv2 (rfc2273/2274), but the specs were lacking.
[16:18]<kenh> (This is really relevant for applications that already have transport security, e.g. hardware accelerated encryption)
[16:18]<kenh> Formal Definition (rough; See I-D)
[16:18]<kenh> Mutual auth at app-layer
[16:19]<kenh> App-level end-points exchange integrity-protected proof of knowledge of "channel bindings" for lower layer, secure channel.
[16:19]<kenh> Channel bindings must cryptographically _name_ a channel.
[16:19]<kenh> Examples: TLS, SSHv2
[16:19]<kenh> Channel bindings for TLS: client & server finished messages
[16:20]<kenh> Channel bindings for SSHv2: session ID
[16:20]<kenh> These are crypto bound to the initial TLS/SSHv2 key exchange.
[16:20] mstjohns has left the room.
[16:20] mstjohns has entered the room.
[16:20] mstjohns has left the room.
[16:20]<kenh> TCP/SCTP/UDP/IPSec? It can be done.
[16:20] mstjohns has entered the room.
[16:21]<kenh> NULL bindings? Better than AUTH_SYS for NFS.
[16:21]<kenh> GSS-API & Channel Bindings.
[16:21]<kenh> RFC2743 talks about them, but provides little guidance.
[16:21] mstjohns has left the room.
[16:21]<kenh> RFC2744 provides C structure (and little guidance beyond network addresses)
[16:22]<kenh> channel binding are _not_ negotiable - you either use them, or don't.
[16:22]<kenh> To make GSS channel bindings useful, we did:
[16:22]<kenh> - Provide a generic structure for channel binding data
[16:22]<kenh> - Provide guidance for several types of channel bindings
[16:23]<kenh> - Provide for negotiation of channel bindings by adding a new stackable GSS mechanism.
[16:23] ekr has entered the room.
[16:23]<kenh> Benfits (Overview)
[16:23]<kenh> Avoid double encryption when possible
[16:23]<kenh> (E.g., NFS over IPsec)
[16:23]<kenh> And without Channel Bindings?
[16:24]<kenh> If the lower layer authentication facilities satisfy application needs then there's no need for channel bindings.
[16:24]<kenh> But we expect IPsec w/user certs to be rare.
[16:24] ekr has left the room.
[16:24]<kenh> Performance benefits: RDDP
[16:25]<kenh> RDDP layers between the transport and the application to facilitate receiver zero-copy by addressing interesting buffers in app payloads and direction RNIC to DMA data to correct location.
[16:26]<kenh> IPSec channel: TCP/SCTP connection protected with transport-mode SA's with same protection/authentication for duration of connection.
[16:26]<kenh> New APIs needed to deal with IPsec channels.
[16:27]<kenh> (e.g. draft-ietf-ipsec-apireq-00.txt)
[16:27]<kenh> What about anonymous IPsec?
[16:27]<kenh> Apps that provide for authentication may not care about IDs authentication by IPsec.
[16:28]<kenh> But it would be nice to leverage IPsec for encryption (think hardware encryption).
[16:28]<kenh> Channel binding structure/constructor functions.
[16:29]<kenh> draft-williams-gssapi-channel-bindings-00.txt (not yet published)
[16:29]<kenh> Generalizes structures from RFC2374.
[16:29]<kenh> CCM-BIND: GSS pseudo mechanism
[16:30]<kenh> stacks atop concrete mechs, like Kerberos 5.
[16:30]<kenh> draft-ietf-nfsv4-ccm-02.txt
[16:30]<kenh> Properlyu handles channel bindings proof exchanges.
[16:30]<kenh> Offering CCM signals willingness to use channel bindings.
[16:30] peterd has left the room.
[16:31]<kenh> SASL w/Channel Bindings
[16:31]<kenh> Use SASL GSS-API spec
[16:31]<kenh> And use CCM-BIND, negotiate SASL mechs as usual.
[16:31]<kenh> SPNEGO and channel bindings: pretty much same as SASL (minor changes to SPNEGO)
[16:32]<hartmans> How behind are we? We should make sure we get to discuss the charter
[16:32]<kenh> (no idea, jaltman should know)
[16:33]<kenh> In designing GSS CCM, useful concept noted: generic stackable pseudo-mechs.
[16:33]<kenh> Interfaces needed to make this work.
[16:34] avri has left the room.
[16:34]<jas> (Is draft-williams-gssapi-channel-bindings-00.txt available somewhere? I wonder how it can achieve channel bindings in SASL when the SASL GSS-API demand NULL channel bindings.)
[16:34]<raeburn> I think we're pretty close to on schedule.
[16:35]<kenh> David Black, EMC: IPsec channel bindings can get very "interesting", e.g. fiberchannel node names in IPsec endpoint names.
[16:35]<hartmans> It's available in the id repository
[16:36]<hartmans> I think the SASL text is possibly weak; I don't think the SASL community has reviewed
[16:36]<kenh> Nico: We don't care what the channel bindings are at the IPsec layer.
[16:37]<kenh> David: Not time for full discussion now, just wanted to bring up the issue that the idea of indirect cryptographic binding involves a lot of work.
[16:37]<kenh> Second presentation by Nico: Stackable GSS mechanisms
[16:37]<kenh> Brief history:
[16:38] Kurt has left the room.
[16:38]<kenh> 2000 - LIPKEY, basic-over-SPKM
[16:38]<jas> Re williams-gssapi-channel-bindings: Do you have a URL? I thought it hadn't been submitted yet.
[16:38]<kenh> Early 2003: CCM-BIND (I-D), first stackable GSS pseudo-mechanism.
[16:38]<hartmans> No, the new version hadn't been submitted
[16:39]<kenh> 58th IETF: hallway discussion of mechanism resulted in need for abstraction.
[16:39]<hartmans> hold on
[16:39]<kenh> Glossary: Concrete mechanism - Mech that can be used as-is.
[16:39]<kenh> Pseudo-mech: mech only useful without reference to a concrete mech (e.g., SPNEGO)
[16:40]<hartmans> No, I'm wrong. nfsv4-channel-bindings is what exists of williams-channel-bindings today.
[16:40]<hartmans> Nico may have sent the other draft to the list
[16:40]<kenh> stackable pseudo-mech: mechanism that can be stacked above or combined with a concrete mechanism.
[16:40]<kenh> Introduction:
[16:40] jjavip has entered the room.
[16:40]<kenh> GSS-API mechs exist for Kerberos 5, PKIX (SPKM), and others such as MS NTLMSSP, Sun's mech_dh.
[16:40]<jas> Ok, thanks.
[16:41]<kenh> GSS pseudo-mechanisms exist today - SPNEGO.
[16:41]<kenh> When developing new lightweight pseudo-mech for NFS we expanded on channel bindings and came up with CCM.
[16:42]<kenh> Composite mechs have OID, just like any other mechanism.
[16:42]<kenh> LIPKEY: Almost a stack (does equivalant of basic-over-SSL)
[16:42]<kenh> Other idea for stackable pseudo-mechs:
[16:43]<kenh> Proper channel binding - CCM-BIND
[16:43]<kenh> PFS, Compression, basic-over-*, three party auth.
[16:44]<kenh> Example: Perfect Forward Secrecy.
[16:44]<kenh> Context tokens might contain tokens from lower mech, DH public parameters, and it's own per-message tokens.
[16:45]<kenh> Not all mechanism stacks make sense (e.g., pfs, compress, krb5 is no good, but {compress, pfs, krb5} is okay.
[16:45]<kenh> Complexity - how many valid composites, how to negotiate?
[16:45]<kenh> GSS_indicate_mechs() - don't want to make stackable mechs available to apps.
[16:46]<kenh> Solutions:
[16:46] peterd has entered the room.
[16:46] jjavip has left the room.
[16:46] jjavip has entered the room.
[16:46]<kenh> GSS_indicate_mechs() MUST not indicate stackable mechs and composite mechs (composite mechs okay if explicitly configured to do so).
[16:46]<kenh> New APIs for stackable/composite mechs.
[16:47]<kenh> Composite mech users know what features they want from them,, but why should the knnow the OID of the composite mechs?
[16:47]<kenh> Add API for inquiring mechs by attributes.
[16:47]<kenh> These new APIs are all optional.
[16:48] jis has entered the room.
[16:48]<kenh> Stackable pseudo-mechs should describe constraints on how they can be mixed with others.
[16:48]<kenh> Benefits of new APIs:
[16:48]<kenh> No need to hardcode mechanism OIDs anymore.
[16:49]<kenh> e.g, SSHv2 MUST NOT use SPNEGO, but SPNEGO might get new OIDs.
[16:49]<kenh> Indicating mechs by attributes makes applications more general.
[16:49]<kenh> New APIs (see slides for details, I can't type that fast)
[16:50]<kenh> Mechanism attributes: concrete, stackable, composite, glue, other.
[16:50]<kenh> Depreciated (old krb5 mech OID), non-standard (GSI SSL mech)
[16:51]<kenh> authenticates initiator, acceptor, other.
[16:51]<kenh> draft-williams-gssapi-stackable-pseudo-mechs-00.txt
[16:52]<kenh> No questions;
[16:52]<kenh> next presentation: Wyllys Ingersoll, Sun Microsystems.
[16:52] jjavip has left the room.
[16:52] jjavip has entered the room.
[16:53]<kenh> Change of plans: discussion of C# language bindings by J.K. of Microsoft.
[16:53]<kenh> Not able to get draft out in time.
[16:54]<kenh> First version is just a description of MS's implementation of current GSS-API bindings.
[16:54]<kenh> We are hoping that this will be the right forum.
[16:55]<kenh> Interested in hearing from people who had experience with Java GSSAPI bindings.
[16:55] fp has entered the room.
[16:55]<kenh> Comment from Nico: Seems to me that language bindings are not that hard to design, not sure if you need a WG to do the work, but it may not add much load to the working group.
[16:55]<sommerfeld> api's are hard
[16:56]<kenh> Nico: If you publish it somewhere else, informational draft here would be nice, but have no strong opinion either way.
[16:57]<kenh> Nico: If you're going to have bindings for SSPI's encrypt-in-place functionality, it would be nice to have that functionality in GSSAPI as well.
[16:57]<kenh> Now, presentation from Wyllys:
[16:58]<kenh> Original SPNEGO draft implemented early on by MS.
[16:58]<kenh> When Sun tried to implement it, discovered interop problems with MS implementation.
[16:59]<kenh> Some problems are DER versus BER, explicit versus implicit tagging, mechlist MIC field, only implemented to cover initial list you send (should it also include flags, encoding of the sequence, concatenated OIDs), and more vagarities.
[16:59]<kenh> (Those were all spec issues)
[16:59] dinakar has entered the room.
[17:00]<kenh> Implementation issues: Kerberos OID is wrong, off by one byte, which changes whole OID.
[17:00] Kurt has entered the room.
[17:01]<kenh> Mechlist MIC field not valid for request, and server ignores mechlist MIC field completely.
[17:01] fp has left the room.
[17:02]<kenh> (Problem with server ignoring mechlist MIC is that since the sequence number is incremented on the client but the server does not, the sequence numbers don't match)
[17:02]<kenh> Without using mechlist-MIC, you get SNEGO, not SPNEGO.
[17:03]<kenh> We couldn't find a way of producing a backwards-compatible implementation that followed the spec and interoperated with MS.
[17:03]<hartmans> And that's "secure" single sign-on
[17:03]<warlord> "backwards compatible" with what?
[17:03]<sommerfeld> "secure" "single" "sign"-"on"
[17:03]<hartmans> Microsoft
[17:04]<kenh> One suggestion is to have a flag day among vendors, but that won't likely work.
[17:04]<hartmans> Bill, good point. I can think of ways in which each of those words doesn't apply to the http negotiate mech.
[17:04]<kenh> Another suggestion is to clarify spec and get a new OID.
[17:05]<hartmans> Even if you have a new OID, you need to have a flag day
[17:05]<kenh> End of Wyllys's presentation, slides available later.
[17:05]<kenh> jaltman: Proposed charter.
[17:06]<kenh> Looking at moving two directions at once: informational draft with wisdom for gssapi v2, new draft describing gssapi v3.
[17:08] jis has left the room.
[17:10]<kenh> Paul (?), Cisco: are we voting on this whole thing as one basket, or on individual pieces?
[17:11]<kenh> Nico: The only thing that might break backwards compat is the naming work (no canonical names for some mechs).
[17:11]<kenh> (just as a clarification)
[17:11] jjavip has left the room.
[17:12]<kenh> Open mike for charter items:
[17:12] peterd has left the room.
[17:12]<kenh> Joe Saloway, Cisco: W.R.T channel bindings, might be worth investigating of we can get some commonality from SASL & EAP.
[17:12] leg has left the room.
[17:13]<kenh> Joe: In terms of naming, might need to update existing mechanisms to deal with new naming.
[17:13]<kenh> jaltman: agreed, naming is an open topic still.
[17:14]<kenh> Sam Hartman: The SASL GSSAPI editor is very familiar with our work (couldn't be here today), it would be great if we could get someone from EAP here.
[17:14]<kenh> sam: w.r.t naming, if a mechanism has a home, the work could be done there (e.g., Kerberos in krb-wg), not sure if spkm has a home.
[17:15]<kenh> sam: if people want to drop things, my personal preference is to drop gssapiv2 clarifications.
[17:16]<kenh> nico: w.r.t. channel bindings, I don't think the concept is specific to gssapi, can be generalized to other things. GSSAPI just provides a slot for it, so it's a natural home for it.
[17:17]<kenh> sommerfeld: There may be multiple working groups here (e.g., maybe channel bindings should be it's own WG). Maybe want broader community to work on channel bindings who may not be interested in 'const' in GSSAPI.
[17:18]<kenh> Unknown: May want to check to see if termology w.r.t. channel bindings is same termology as EAP, not sure if it is.
[17:18]<hartmans> EAP has the same chanel bindings problems even if they don't call it channel bindings.
[17:18] dinakar has left the room.
[17:19]<kenh> Joe saloway: there are a couple of drafts that deal with things similar to stackable mechs in EAP.
[17:19]<kenh> nico: Similar things in Kerberos with preauth mechanisms.
[17:20] Kurt has left the room.
[17:20]<jas> Charter: "Specify thread safety extensions"? Has focus shifted from clarifying thread issues (like two threads calling gss_get_mic at the same time), to provide new APIs? What would the new APIs look like? I re-read the thread discussion on the list, but did not find discussion on any thread extensions.
[17:21]<kenh> sam: while it's good we're acknowledging all of this synergy, we do want to get done in a finite time, if we split off into multiple wg's it may prevent that.
[17:22] admcd has entered the room.
[17:22]<kenh> answer to jas's question (from jaltman): I do not believe we're discussing any new APIs.
[17:22]<kenh> Nico: We're just talking about changes in semantics.
[17:23]<kenh> Nico: But some list members believe that's effectively a new API.
[17:24]<kenh> Nico: The big issue is that if you write a threaded GSSAPI program, you lose portability.
[17:25]<kenh> Ken Raeburn: Phrasing of this section of charter (clarification of gssapi v2) is poor; many times, if something is unclear, the answer is, "You just lose".
[17:25]<kenh> jaltman: Idea is similar to Kerberos clarifications: explanations of what apps might expect, and what we thought the spec meant.
[17:26]<jas> fwiw, changing semantics to make threaded use work would be fine by me, but introducing new APIs for threading seem convoluted.
[17:26]<kenh> nico: GSSAPIv3 won't be radically different than v2; should have most of the same APIs. For v2, we could use a preprocessor macro to determine if the GSSAPI implementation is thread-safe or not.
[17:26] rlbob has left the room.
[17:27]<kenh> jas: Everyone agrees with you, and we are not proposing creating new APIs for that purpose.
[17:28]<kenh> Russ Housley (IESG): First big question: Is there community support for this initiative? Some documents already have names behind them, which means that they have editors.
[17:29] admcd has left the room.
[17:29] raeburn has left the room.
[17:29]<kenh> Russ: Question asked: Do people think that this belongs in the IETF? Looks like the consensus is that the answer is "yes".
[17:29] tlyu has left the room.
[17:29] hartmans has left the room.
[17:29] kenh has left the room.
[17:30] dumdidum has left the room.
[17:30] pbh has left the room.
[17:31] warlord has left the room.

--------------ms030407090701090204050905 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 DxcNMDQwODAzMDAzMzU4WjAjBgkqhkiG9w0BCQQxFgQUksgE6sHOjw+TRd95rc7GM78rXJAw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEA2M5Zf1vhj0TYSAd44fpFTNp3ri+5RWkcjanbZcQJ T9UlkIett32bSYeMB0cw2ZzWv7TtAjc9n2R7DoKMxS7jgHYDeSjawXXtQ2Vc6m3S6xBNg/F5 hBiT9qEWrLyNdBlKgzUXFwSAkvuRBadadXq+rvBIzTj+J7YPQTS77/XHjn+lAAEwp9tmPtcX /BuPCxhB9Dp0oE8CMg9qEfD71WbAfurKaR0fPD9MtijyEXgltCKTVudcMj2ofBiiASrqCykR r39dx3sX/damEaZStLAIZS8+b11m0VRlc06Hy40FzXzes66PIBDQaoqlxL8w66ixyFnMa88F Fl12AelPkgGqvQAAAAAAAA== --------------ms030407090701090204050905-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Aug 3 14:03:51 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27602 for ; Tue, 3 Aug 2004 14:03:50 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i73HxTUb000690 for ietf-cat-wg-out720680; Tue, 3 Aug 2004 10:59:29 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i73HxQNK000676 for ; Tue, 3 Aug 2004 10:59:26 -0700 (PDT) Received: from [130.129.132.94] (opene-130-129-132-94.ietf60.ietf.org [130.129.132.94]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i73HxNI7003012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Aug 2004 13:59:24 -0400 (EDT) Message-ID: <410FD27B.90003@columbia.edu> Date: Tue, 03 Aug 2004 10:59:23 -0700 From: Jeffrey Altman Organization: No Longer 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) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU Subject: IETF 60 Kitten BOF Presentations X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070600080203050007080802" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms070600080203050007080802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I have uploaded the presentations from yesterday's meeting to

    http://web.mit.edu/~jaltman/www/kitten/

Speaker                          Title                                                               Filename
Jeffrey Altman                Agenda/Charter                                             ietf60-kitten-agenda-charter.pdf
Doug Engert                   Global Grid Forum GSS requirements           ietf60-kitten-gss-ggf-ext.pdf
Sam Hartman                  GSSAPI Naming Issues                                  ietf60-kitten-hartman.pdf
Nico Williams                  The Need for cryptographic channel             ietf60-kitten-oncbindings.pdf
                                       bindings and CCM
Nico Williams                  Stackable Psuedo Mechanisms                       ietf60-kitten-stackable.pdf
Wyllys Ingersol                 GSSAPI SPNEGO issues                              ietf60-kitten-spnego.pdf

--------------ms070600080203050007080802 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 DxcNMDQwODAzMTc1OTIzWjAjBgkqhkiG9w0BCQQxFgQUEWKJN2L+V40YUPLyZgBz54U8A2Mw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAGywlLi2a165Yl4TxJyB5/tgIRv0Yqrz3TomtVLqB 67kJza3KIRLb+mAv15dYtKOMX3gX41Hq9x/M4mw8bK+95L7Zu8kC7tXMypO5hN+ILDJrGrNr B3DHoIWolpaHEfMRBY49A2PVrba0rG6K+M6dWDCYxZg9N7o/KtNmLCWJ1vzOERKJWLZkDP96 Hn5OS5t2HYlOM+6fvoLsizp7e9up058oegLzNCZJSo+jcmNbMREbIcdfD3pKeWC78Gs1ZVYt k/E8HXPo+Rb1/ksU65wIvFU2FW7xMLA8C/qZkcc0jDL6hsIcPbw0OWfBpLbvNtqTthUOc8aq J7d964lY6o43xAAAAAAAAA== --------------ms070600080203050007080802-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Aug 5 17:08:54 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14631 for ; Thu, 5 Aug 2004 17:08:54 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i75KsEwn016018 for ietf-cat-wg-out720680; Thu, 5 Aug 2004 13:54:14 -0700 (PDT) Received: from cz.mit.edu (opene-130-129-134-175.ietf60.ietf.org [130.129.134.175]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i75KsCNK016013 for ; Thu, 5 Aug 2004 13:54:13 -0700 (PDT) Received: by cz.mit.edu (Postfix, from userid 8042) id D11C81602FC; Thu, 5 Aug 2004 16:52:45 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: Adding a PRF to GSSAPI V3 Message-Id: <20040805205245.D11C81602FC@cz.mit.edu> Date: Thu, 5 Aug 2004 16:52:45 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Hi. Larry, Niico and I would support the idea of adding some sort of PRF to the GSSAPI. The intent of this would be that you have gss_prf that takes a context and some goop as input and returns some psuedo-random goop as output. The output would be constant for a given context and given input goop. This would presumably be a optional feature of GSSAPI. If the list believes that this would be a good idea, I request any changes that are necessary be made to the proposed charter. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Aug 5 17:26:37 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15944 for ; Thu, 5 Aug 2004 17:26:37 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i75LHU2L018192 for ietf-cat-wg-out720680; Thu, 5 Aug 2004 14:17:30 -0700 (PDT) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i75LHRNK018164 for ; Thu, 5 Aug 2004 14:17:28 -0700 (PDT) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA27117 for ; Thu, 5 Aug 2004 16:17:21 -0500 (CDT) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id QAA27060 for ; Thu, 5 Aug 2004 16:17:16 -0500 (CDT) Message-ID: <4112A396.631DA9F0@anl.gov> Date: Thu, 05 Aug 2004 16:16:06 -0500 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Adding a PRF to GSSAPI V3 References: <20040805205245.D11C81602FC@cz.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Sam Hartman wrote: > Hi. Larry, Niico and I would support the idea of adding some sort of > PRF to the GSSAPI. > > The intent of this would be that you have gss_prf that takes a context > and some goop as input and returns some psuedo-random goop as output. > The output would be constant for a given context and given input goop. > This would presumably be a optional feature of GSSAPI. > > If the list believes that this would be a good idea, I request any > changes that are necessary be made to the proposed charter. Great idea. > > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Aug 10 12:36:18 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10269 for ; Tue, 10 Aug 2004 12:36:17 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7AGWu5c026933 for ietf-cat-wg-out720680; Tue, 10 Aug 2004 09:32:56 -0700 (PDT) Received: from smtp2.su.se (smtp2.su.se [130.237.93.212]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7AGWqNK026919 for ; Tue, 10 Aug 2004 09:32:54 -0700 (PDT) Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id E6B33200109; Tue, 10 Aug 2004 18:32:48 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04939-01-12; Tue, 10 Aug 2004 18:32:48 +0200 (CEST) Received: from nutcracker.stacken.kth.se (nutcracker.wtf.stacken.kth.se [130.237.237.2]) by smtp2.su.se (Postfix) with ESMTP id 8D659200001; Tue, 10 Aug 2004 18:32:36 +0200 (CEST) Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id 36FF8F3852; Tue, 10 Aug 2004 17:38:45 +0200 (CEST) To: hartmans@mit.edu (Sam Hartman) Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Adding a PRF to GSSAPI V3 References: <20040805205245.D11C81602FC@cz.mit.edu> From: Love Date: Tue, 10 Aug 2004 17:38:41 +0200 In-Reply-To: <20040805205245.D11C81602FC@cz.mit.edu> (Sam Hartman's message of "Thu, 5 Aug 2004 16:52:45 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Virus-Scanned: by amavisd-new at su.se Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --=-=-= hartmans@mit.edu (Sam Hartman) writes: > Hi. Larry, Niico and I would support the idea of adding some sort of > PRF to the GSSAPI. > > > The intent of this would be that you have gss_prf that takes a context > and some goop as input and returns some psuedo-random goop as output. > The output would be constant for a given context and given input goop. > This would presumably be a optional feature of GSSAPI. > > > If the list believes that this would be a good idea, I request any > changes that are necessary be made to the proposed charter. I find this a good idea as is would be used for the equallent of channel bindings for layer on top of gssapi. What was your intended usage for it ? Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (NetBSD) iQEVAwUAQRjsBXW+NPVfDpmCAQJ6rwf/ddvJo+4iI83jWRnb9m8FaXVMG1slJsF3 ZbTOOADsxZFKL3V47j4ofhSxuh8/j0ahB0SjTwpFXUHbSImKRhRrdDjVaWMOYQy9 +gH0NuPJVqJPHHyhoYnclVL3EaoseEhwKRByxw5ovw9YbeGm25RdA6FITqBNwO5L SoPdpgn97dT0Fbt0QLZZlgHa/UToN2J60JX/TrHnOy26N2BdLNVoGNrEOLKTzT+6 3PuWzvBYhKHXAV5cmtGfq0A3dAhh9Cc9L2mSwbDAcqvAIwKzJGY1I1HzhspIcZbi ptK8S6Z/gxSTPtC7xUqho1iq9HRK/7RtP1Ypej46F8Wf5K3XZfL7TA== =tMXd -----END PGP SIGNATURE----- --=-=-=-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Aug 10 13:25:34 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14504 for ; Tue, 10 Aug 2004 13:25:33 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7AHNDeq001848 for ietf-cat-wg-out720680; Tue, 10 Aug 2004 10:23:13 -0700 (PDT) Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7AHNANK001826 for ; Tue, 10 Aug 2004 10:23:11 -0700 (PDT) Received: by cz.mit.edu (Postfix, from userid 8042) id E36001608DB; Tue, 10 Aug 2004 13:21:51 -0400 (EDT) To: Love Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Adding a PRF to GSSAPI V3 References: <20040805205245.D11C81602FC@cz.mit.edu> From: Sam Hartman Date: Tue, 10 Aug 2004 13:21:51 -0400 In-Reply-To: (lha@stacken.kth.se's message of "Tue, 10 Aug 2004 17:38:41 +0200") 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 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "Love" == Love writes: Love> I find this a good idea as is would be used for the Love> equallent of channel bindings for layer on top of gssapi. Love> What was your intended usage for it ? It could be useful for an EAP GSS mechanism. IT could make the ssh key exchange draft more efficient for mechanisms with PFS support. It could be useful for things like ipsec that really want their own crypto. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Aug 10 15:58:42 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26485 for ; Tue, 10 Aug 2004 15:58:42 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7AJuxB6017022 for ietf-cat-wg-out720680; Tue, 10 Aug 2004 12:56:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.140]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7AJutNK017003 for ; Tue, 10 Aug 2004 12:56:57 -0700 (PDT) Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA18662; Tue, 10 Aug 2004 21:56:32 +0200 (MESZ) From: Martin Rex Message-Id: <200408101956.VAA06922@uw1048.wdf.sap.corp> Subject: Re: Adding a PRF to GSSAPI V3 To: hartmans@mit.edu (Sam Hartman) Date: Tue, 10 Aug 2004 21:56:32 +0200 (MET DST) Cc: ietf-cat-wg@lists.Stanford.EDU In-Reply-To: <20040805205245.D11C81602FC@cz.mit.edu> from "Sam Hartman" at Aug 5, 4 04:52:45 pm Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > Hi. Larry, Niico and I would support the idea of adding some sort of > PRF to the GSSAPI. > > The intent of this would be that you have gss_prf that takes a context > and some goop as input and returns some psuedo-random goop as output. > The output would be constant for a given context and given input goop. > This would presumably be a optional feature of GSSAPI. You mean cryptographically strong pseudo-random goop as output -- similar to SSL/TLS deriving session-keys from a shared master secret? That might be useful for those who want to use gssapi for authenication but do the actual crypto on their own. Having this as an optional extension should be OK. There may be technical and policital reasons why one mechanism or another will not adopt this functionality. The political reasons may be that a gssapi mechanism should be authentication only or authentication plus integrity but no confidentiality (this was how DCE implemented the former US crypto export regulations). Providing cryptographically strong shared secrets to the communication peers of an established security context was incompatible with that regulation. Technical reasons may be that the gssapi mechanism provides authentication only and no means to establish a cryptographically strong shared secret between the communication peers during authentication which could be used as a master secret. Simple challenge-response schemes such as Microsoft's NTLM authentication come to mind. Or authentication based on DSA-certificates. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Aug 10 16:22:22 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00480 for ; Tue, 10 Aug 2004 16:22:22 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7AKF7FD018530 for ietf-cat-wg-out720680; Tue, 10 Aug 2004 13:15:07 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7AKF4NK018511 for ; Tue, 10 Aug 2004 13:15:05 -0700 (PDT) Received: from vons-mac (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i7AKEia65664; Tue, 10 Aug 2004 15:14:45 -0500 X-Mailer: emacs 21.3.50.1 (via feedmail 10 I); VM 7.18 under Emacs 21.3.50.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16665.11444.43871.244066@gargle.gargle.HOWL> Date: Tue, 10 Aug 2004 15:14:44 -0500 To: martin.rex@sap.com Cc: hartmans@mit.edu (Sam Hartman), ietf-cat-wg@lists.Stanford.EDU Subject: Re: Adding a PRF to GSSAPI V3 From: Von Welch Reply-To: Von Welch In-Reply-To: <200408101956.VAA06922@uw1048.wdf.sap.corp> References: <20040805205245.D11C81602FC@cz.mit.edu> <200408101956.VAA06922@uw1048.wdf.sap.corp> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > That might be useful for those who want to use gssapi for authenication > but do the actual crypto on their own. Just wanted to mention that when we were looking at implementing a GSSAPI-based Web Services SecureConversation, we wanted to do just this - GSSAPI tokens for the authentication, generate a session key and then do standard WS-Security after that (basically to leverage existing GSSAPI libraries in WS). So, this sounds useful. Von Martin Rex writes (21:56 August 10, 2004): > Sam Hartman wrote: > > > > Hi. Larry, Niico and I would support the idea of adding some sort of > > PRF to the GSSAPI. > > > > The intent of this would be that you have gss_prf that takes a context > > and some goop as input and returns some psuedo-random goop as output. > > The output would be constant for a given context and given input goop. > > This would presumably be a optional feature of GSSAPI. > > You mean cryptographically strong pseudo-random goop as output -- > similar to SSL/TLS deriving session-keys from a shared master secret? > > That might be useful for those who want to use gssapi for authenication > but do the actual crypto on their own. > > Having this as an optional extension should be OK. > > There may be technical and policital reasons why one mechanism > or another will not adopt this functionality. > > The political reasons may be that a gssapi mechanism should be > authentication only or authentication plus integrity but no confidentiality > (this was how DCE implemented the former US crypto export regulations). > Providing cryptographically strong shared secrets to the communication > peers of an established security context was incompatible with > that regulation. > > Technical reasons may be that the gssapi mechanism provides authentication > only and no means to establish a cryptographically strong shared secret > between the communication peers during authentication which could be > used as a master secret. Simple challenge-response schemes such > as Microsoft's NTLM authentication come to mind. Or authentication > based on DSA-certificates. > > -Martin > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Aug 12 03:05:01 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07937 for ; Thu, 12 Aug 2004 03:05:01 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7C6xR4r017149 for ietf-cat-wg-out720680; Wed, 11 Aug 2004 23:59:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7C6xONK017143 for ; Wed, 11 Aug 2004 23:59:25 -0700 (PDT) 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 i7C6xJJ6003301 for ; Wed, 11 Aug 2004 23:59:19 -0700 (PDT) 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 i7C6xIUT002897 for ; Thu, 12 Aug 2004 00:59:18 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7C6ugd8007570; Thu, 12 Aug 2004 01:56:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.0+Sun/8.13.0/Submit) id i7C6uflW007569; Thu, 12 Aug 2004 01:56:41 -0500 (CDT) Date: Thu, 12 Aug 2004 01:56:41 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-cat-wg@lists.Stanford.EDU Subject: Re: Adding a PRF to GSSAPI V3 Message-ID: <20040812065641.GI892@binky.central.sun.com> References: <20040805205245.D11C81602FC@cz.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040805205245.D11C81602FC@cz.mit.edu> User-Agent: Mutt/1.4.1i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Aug 05, 2004 at 04:52:45PM -0400, Sam Hartman wrote: > Hi. Larry, Niico and I would support the idea of adding some sort of > PRF to the GSSAPI. > > The intent of this would be that you have gss_prf that takes a context > and some goop as input and returns some psuedo-random goop as output. > The output would be constant for a given context and given input goop. > This would presumably be a optional feature of GSSAPI. > > If the list believes that this would be a good idea, I request any > changes that are necessary be made to the proposed charter. I particularly like the ease with which this extension can be defined, both generically and for the Kerberos V mechanism specifically. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Aug 25 08:04:55 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08781 for ; Wed, 25 Aug 2004 08:04:54 -0400 (EDT) From: owner-ietf-cat-wg@lists.Stanford.EDU Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i7PBpKeX018972 for ietf-cat-wg-out720680; Wed, 25 Aug 2004 04:51:20 -0700 (PDT) Received: from corpmailsmtp02.digitalnetworksna.com (corpmailsmtp02.digitalnetworksna.com [209.10.223.203]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i7PBpINK018955 for ; Wed, 25 Aug 2004 04:51:18 -0700 (PDT) Received: from corpvirus1.sc.sonicblue.com (unknown [10.6.2.49]) by corpmailsmtp02.digitalnetworksna.com (Postfix) with SMTP id AFA5217AC for ; Wed, 25 Aug 2004 04:51:11 -0700 (PDT) X-Mailer: Network Associates, Inc. Webshield SMTP, Version 4.5 MR1a Date: Wed Aug 25 05:04:10 2004 To: Subject: [SPAM:#####] Virus Detected by Network Associates, Inc. Webshield SMTP V4.5 MR1a Message-Id: <20040825115111.AFA5217AC@corpmailsmtp02.digitalnetworksna.com> X-Spam: Probability=93%, Report='VBOUNCE 5, FROM_MALFORMED 2.699, INVALID_DATE 1.380, DATE_IN_PAST_06_12 1.203, __VBOUNCE_DETECTED 0, __HAS_MSGID 0, __SANE_MSGID 0, __HAS_X_MAILER 0, __TO_MALFORMED_2 0, BAYES_49_51 0' Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Network Associates WebShield SMTP V4.5 MR1a on corpvirus1 detected virus W32/Netsky.q@MM in attachment msg31650.pif from and it was Deleted. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu