From kitten-bounces@lists.ietf.org Mon Jun 04 20:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMTa-0004NO-VW; Mon, 04 Jun 2007 20:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMTZ-0004NF-DF for kitten@lists.ietf.org; Mon, 04 Jun 2007 20:00:41 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvMTY-0005qE-0r for kitten@lists.ietf.org; Mon, 04 Jun 2007 20:00:41 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5500doq007720 for ; Tue, 5 Jun 2007 00:00:39 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJ400K01XUU2M00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@lists.ietf.org; Mon, 04 Jun 2007 18:00:39 -0600 (MDT) Received: from [129.150.48.17] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ4003EQYP2NCE5@mail-amer.sun.com> for kitten@lists.ietf.org; Mon, 04 Jun 2007 18:00:39 -0600 (MDT) Date: Mon, 04 Jun 2007 17:59:51 -0600 From: Shawn M Emery To: kitten@lists.ietf.org Message-id: <4664A777.2050903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070419) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: GSS API v2: C# Bindings X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org The kitten-wg is in need of an editor to continue work on the GSS API v2 C# bindings draft: http://tools.ietf.org/html/draft-ietf-kitten-gssapi-csharp-bindings-00 The editor would be responsible for incorporating any changes from past and future reviewer comments. The past review comments by Horst Reiterer can be found here: http://www1.ietf.org/mail-archive/web/kitten/current/msg00743.html The kitten-wg would also like to have volunteers to review the -00 rev of this document. Thank you, -- Shawn - kitten-wg co-chair _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jun 11 18:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsZ0-0005hu-Ob; Mon, 11 Jun 2007 18:40:42 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HxsYz-0005dc-Ok for kitten-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 18:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxsYz-0005cP-EO for kitten@ietf.org; Mon, 11 Jun 2007 18:40:41 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxsYv-0002SW-Rx; Mon, 11 Jun 2007 18:40:41 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id 43A7761DC3E; Mon, 11 Jun 2007 16:42:03 -0600 (MDT) Message-ID: <466DCFBA.9020001@jabber.org> Date: Mon, 11 Jun 2007 16:42:02 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: kitten@ietf.org Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org Subject: domain-based service names redux 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="===============1596761288==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1596761288== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070703080208020400000503" This is a cryptographically signed message in MIME format. --------------ms070703080208020400000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Warning: I am far from a Kerberos or SASL expert, and this email mostly channels feedback from several XMPP developers (cc'd on this message, also cc'ing sasl@ietf.org). My apologies for any inaccuracies. That said... I'm working to understand if draft-ietf-kitten-gssapi-domain-based-names and draft-ietf-kitten-krb5-gssapi-domain-based-names solve a problem we're having in the XMPP community. As you may know, XMPP (RFC 3920) essentially streams XML over a long-lived TCP connection. Large XMPP deployments tend to require tens of thousands of TCP connections (or more) from clients to a server, with the result that they are often architected with multiple connection managers (perhaps one CM per 10k clients) hooked into a core router. Client connections to the connection managers are often managed through a front-end load balancer. We can visualize as follows (where "CM" is a connection manager and "C" is a client): XMPP ROUTER / | \ CM CM CM \ | / LOAD BALANCER / | \ C C C (Such a solution *could* be managed via SRV, but in practice that is not feasible for some large XMPP deployments.) The problem is that a client doesn't know which CM it has connected to (e.g., cm6.example.com), since that information is hidden by the load balancer in the middle (all clients appear to be connected to the IP address of the load balancer). For non-Kerberos deployments that doesn't matter, but it does matter for Kerberos deployments since a client needs to know the address of its service. My understanding of draft-ietf-kitten-gssapi-domain-based-names is that it should be possible to name a CM in such a deployment as a GSS_C_NT_DOMAINBASED_SERVICE name like so: xmpp@example.com@cm6.example.com Where the form is "service@domain@hostname". In the context of the Kerberos 5 GSS-API mechanism, that would result in a principal name of: xmpp/cm6.example.com/example.com Based on my reading of RFC 4752, I assume that in a SASL exchange using the GSSAPI mechanism, the client can replace GSS_C_NT_HOSTBASED_SERVICE with GSS_C_NT_DOMAINBASED_SERVICE in the following operation (Section 3.1 of RFC 4752): The client calls GSS_Init_sec_context, passing in input_context_handle of 0 (initially), mech_type of the Kerberos V5 GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name equal to output_name from GSS_Import_Name called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of "service@hostname" where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server. Where the asterisk refers to the following note: (*) Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but only when they have a priori knowledge that the servers support alternate name types. Otherwise clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names. It is less clear to me how this service name should be communicated to the XMPP client. Currently in some XMPP implementations the Service Principal Name of the connection manager is returned to the client from the CM after the TCP connection is made (typically after TLS has been negotiated): http://mail.jabber.org/pipermail/xmppwg/2006-April/002379.html This is a mere assertion, but no one in the XMPP community has yet figured out a better method for communicating the CM's name to the client (at least in a way that is deployable in existing organizational environments). Would the use of the GSS_C_NT_DOMAINBASED_SERVICE name provide information that is stronger than a mere assertion by the CM? My reading of draft-ietf-kitten-gssapi-domain-based-names indicates that the "hostname" portion of the GSS_C_NT_DOMAINBASED_SERVICE name may be obtained via insecure service discovery mechanisms (DNS SRV is mentioned) as long as the service and domain are obtained in a secure fashion. Would communication of the GSS_C_NT_DOMAINBASED_SERVICE name after TLS negotiation with the service is complete qualify as obtaining the service and domain in a secure fashion? It seems to me that before TLS is negotiated, communication of the GSS_C_NT_DOMAINBASED_SERVICE name from the CM to the client would indeed be a mere assertion, but that after TLS is negotiated between the XMPP client and server, the client has securely verified the identity of the XMPP server (e.g., the combination of service name "xmpp" and domain name "example.com") and therefore can accept the hostname asserted by the connection manager. (Naturally, that hostname might also be discoverable via SRV through resolution of "_xmpp-client._tcp.example.com.".) If that is right, then the CM could legitimately communicate something like the following to the client after they complete the TLS negotiation (line breaks included for readability only): GSSAPI DIGEST-MD5 PLAIN I freely admit that I may be mistaken, so suggestions from folks in the KITTEN and SASL WGs would be most welcome. Thanks! Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms070703080208020400000503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDYxMTIyNDIwMlowIwYJKoZIhvcNAQkEMRYEFD26NJbwjFNW5dIL1eOuQuapuVWYMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBABiMMw9IicYoDaLMJl2crTpxFQtF25JG1FEbQ9NPF34T ucvWtSmYwpT0Gj3ZSgBUZr/4ZJVlhdhUJwa9Vy2cexycTKgQkqnK/gEQbaK+HiCBmbZE8lwd jwCvqVfeVQalT48E6PzNNR68BBNxoEc1piz/++oCh2Gyj4QiYoOr7x+T3CVxZ4gz74orkcrX 2qXsedU5F+vNw+umFXjsqz1pS//6suZUKjy1ShinyayRYFPwi0gVH4JU517aZwCPyjVkNQQn hy3aIMeU3/gh6j3KuiffnjNJfOUiqMGaMjcgQkC4wxRPfhDeeTSC6Uwj4Pk744IzHOJz+spw p5XDBZaQx1sAAAAAAAA= --------------ms070703080208020400000503-- --===============1596761288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1596761288==-- From kitten-bounces@lists.ietf.org Tue Jun 12 16:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCbz-0000JL-Os; Tue, 12 Jun 2007 16:05:07 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HyCby-0000Ie-7x for kitten-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:05:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCbw-0000G7-An for kitten@ietf.org; Tue, 12 Jun 2007 16:05:04 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCZJ-0004VH-IK; Tue, 12 Jun 2007 16:02:25 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l5CK2DXd028304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 16:02:17 -0400 (EDT) Date: Tue, 12 Jun 2007 16:02:13 -0400 From: Jeffrey Hutzelman To: Peter Saint-Andre , kitten@ietf.org Message-ID: <4B0DFFA50C0FE2C052B56D29@sirius.fac.cs.cmu.edu> In-Reply-To: <466DCFBA.9020001@jabber.org> References: <466DCFBA.9020001@jabber.org> Originator-Info: login-token=Mulberry:014JKSGkr6B44s3QqbExDCiXcEyUVnxgtNB8B/FhI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org, Jeffrey Hutzelman Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Monday, June 11, 2007 04:42:02 PM -0600 Peter Saint-Andre wrote: > It is less clear to me how this service name should be communicated to > the XMPP client. Currently in some XMPP implementations the Service > Principal Name of the connection manager is returned to the client from > the CM after the TCP connection is made (typically after TLS has been > negotiated): > > http://mail.jabber.org/pipermail/xmppwg/2006-April/002379.html > > This is a mere assertion, but no one in the XMPP community has yet > figured out a better method for communicating the CM's name to the client > (at least in a way that is deployable in existing organizational > environments). So, the model we had in mind was that you'd do a SRV record or reverse DNS lookup and use the result of that for the "hostname" part of the domain-based service name, with the "domain" part being whatever domain the client was configured to talk to. Of course, that doesn't work when you use a "transparent" load balancer; as you noted, you need some other way of discovering the hostname. > My reading > of draft-ietf-kitten-gssapi-domain-based-names indicates that the > "hostname" portion of the GSS_C_NT_DOMAINBASED_SERVICE name may be > obtained via insecure service discovery mechanisms (DNS SRV is mentioned) > as long as the service and domain are obtained in a secure fashion. Would > communication of the GSS_C_NT_DOMAINBASED_SERVICE name after TLS > negotiation with the service is complete qualify as obtaining the service > and domain in a secure fashion? No. It is not good enough for the service and domain to be obtained via a secure channel; they also have to come from a trusted source, and the server that is trying to prove its identity to you doesn't qualify. The service is actually easy - it's a constant specified by the application protocol, at both the GSS and SASL layers. The domain is trickier, but only a little - this is the string the user provided (perhaps as part of a URI) that says what domain he wants to talk to. For XMPP, that is probably the name you used for the SRV record lookup. > It seems to me that before TLS is > negotiated, communication of the GSS_C_NT_DOMAINBASED_SERVICE name from > the CM to the client would indeed be a mere assertion, but that after TLS > is negotiated between the XMPP client and server, the client has securely > verified the identity of the XMPP server (e.g., the combination of > service name "xmpp" and domain name "example.com") and therefore can > accept the hostname asserted by the connection manager. (Naturally, that > hostname might also be discoverable via SRV through resolution of > "_xmpp-client._tcp.example.com.".) That seems fishy. I think if you do that, you need to verify that the name the server is asserting matches its certificate. And, of course, that the cert matches what the user asked for. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Jun 12 17:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDWV-0003XZ-68; Tue, 12 Jun 2007 17:03:31 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HyDWT-0003XU-8l for kitten-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 17:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDWS-0003XM-V8 for kitten@ietf.org; Tue, 12 Jun 2007 17:03:28 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDWR-0002LV-Hb; Tue, 12 Jun 2007 17:03:28 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA18040; Tue, 12 Jun 2007 23:03:12 +0200 (MESZ) From: Martin Rex Message-Id: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> To: stpeter@jabber.org (Peter Saint-Andre) Date: Tue, 12 Jun 2007 23:03:11 +0200 (MEST) In-Reply-To: <466DCFBA.9020001@jabber.org> from "Peter Saint-Andre" at Jun 11, 7 04:42:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Peter Saint-Andre wrote: > > XMPP ROUTER > / | \ > CM CM CM > \ | / > LOAD BALANCER > / | \ > C C C > > The problem is that a client doesn't know which CM it has connected to > (e.g., cm6.example.com), since that information is hidden by the load > balancer in the middle (all clients appear to be connected to the IP > address of the load balancer). For non-Kerberos deployments that doesn't > matter, but it does matter for Kerberos deployments since a client needs > to know the address of its service. I never liked hostbased service names ;-) For "old-fashioned" 2-token Kerberos authentication (which is the authentication exchange currently covered by the official Kerberos 5 gssapi mechanisms (rfc-1964 and rfc-4121), the sharing of the server credentials is a problem. (session replay to servers sharing credentials but not sharing the replay cache). If Kerberos user2user authentication is used (exclusively), such a vulnerability from sharing the server credentials does not exist. Microsoft has implemented the 3-token user2user authentication exchange in addition to the 2-token authentication exchange of the IETF-defined Kerberos 5 gssapi mechanism, it has already been available in Windows 2000. The correct approach of using the 2-token exchange in a distributed environment was implemented by DCE many many years ago, but requires a secure directory, something not available in traditional Kerberos. The most sensible and infrastructure-independent approach (i.e. independent of how load-balancing is done within the backend and where within the backend the secure communication is terminated) for traditional Kerberos authentication would be to standardize the user2user authentication exchange and use that (no use of _hostbased_ service names). Today, this option is only available if you go proprietary (or implementation-specific). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 14 14:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu7L-0000Kv-DL; Thu, 14 Jun 2007 14:32:23 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1Hyu7K-0000Kp-LE for kitten-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 14:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu7K-0000Kc-Bc for kitten@ietf.org; Thu, 14 Jun 2007 14:32:22 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyu7G-0004on-RR; Thu, 14 Jun 2007 14:32:22 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id D514361E3D4; Thu, 14 Jun 2007 12:33:45 -0600 (MDT) Message-ID: <46718A09.1000400@jabber.org> Date: Thu, 14 Jun 2007 12:33:45 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: martin.rex@sap.com References: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> In-Reply-To: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux 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="===============1056029414==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1056029414== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020607090701040706010701" This is a cryptographically signed message in MIME format. --------------ms020607090701040706010701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Martin Rex wrote: > Peter Saint-Andre wrote: >> XMPP ROUTER >> / | \ >> CM CM CM >> \ | / >> LOAD BALANCER >> / | \ >> C C C >> >> The problem is that a client doesn't know which CM it has connected to >> (e.g., cm6.example.com), since that information is hidden by the load >> balancer in the middle (all clients appear to be connected to the IP >> address of the load balancer). For non-Kerberos deployments that doesn't >> matter, but it does matter for Kerberos deployments since a client needs >> to know the address of its service. > > I never liked hostbased service names ;-) > > For "old-fashioned" 2-token Kerberos authentication (which is the > authentication exchange currently covered by the official Kerberos 5 > gssapi mechanisms (rfc-1964 and rfc-4121), the sharing of the > server credentials is a problem. (session replay to servers sharing > credentials but not sharing the replay cache). > > If Kerberos user2user authentication is used (exclusively), such a > vulnerability from sharing the server credentials does not exist. > Microsoft has implemented the 3-token user2user authentication exchange > in addition to the 2-token authentication exchange of the IETF-defined > Kerberos 5 gssapi mechanism, it has already been available in Windows 2000. > > The correct approach of using the 2-token exchange in a distributed > environment was implemented by DCE many many years ago, but requires > a secure directory, something not available in traditional Kerberos. > > The most sensible and infrastructure-independent approach (i.e. independent > of how load-balancing is done within the backend and where within > the backend the secure communication is terminated) for traditional > Kerberos authentication would be to standardize the user2user > authentication exchange and use that (no use of _hostbased_ > service names). > > Today, this option is only available if you go proprietary > (or implementation-specific). Not an option. XMPP implementations use the open standards developed by the IETF. That's why I'm asking in this venue. :) It's not clear to me how the session replay attack you mention is specific to the architecture I described. Couldn't an attacker send an earlier ticket even if there is only one service involved (i.e., in my description, only one connection manager)? My understanding of potential objections to the method I described in my previous email is that there is no way for the XMPP client to trust that the connection manager (asserted as cm6.example.com) is associated with the domain (example.com) to which the initiator connected in the first place. But if the client and connection manager have successfully upgraded the XMPP stream to TLS (see Section 5 of RFC 3920), then presumably the connection manager has provided appropriate credentials (e.g., X.509 certificate) that it is indeed so associated. And if the connection manager asserts its GSS_C_NT_DOMAINBASED_SERVICE name only after TLS has been negotiated, then I think the risk is mitigated. What is the attack at that point? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms020607090701040706010701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDYxNDE4MzM0NVowIwYJKoZIhvcNAQkEMRYEFCLmraVd8lbjiqpY+/C4SezfMDXtMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACoyuH7r/ced0Z2T2I2KsG7+uTQ5WrHZSjQvbp6JTqiS E0vfWazC5xoGoxNps/rLA7C+sdDcWyCmB48RT+CSaOATZqp+5sXDPLIgWsXHssmO31W66eLg Q/KprD5LU/MQb1azd3Y07HHZ2+5J1FAx8FIDJKu1JoyGiA+dDlrtSfRINaS2aIvxK+/jf4R1 E3WERNkCv92U8Jh4EHsje64fcKYa5WTjfKq28yEFT/Yk6SA2vxBTK12NqZAXhwa6Z8Z8qjAp 3C/Iy2yJXB1aA02r4Q/Cq/gOVFjGFfSSLKDnyaz5KJS72V+GGcWv6+8gCLPEIIEtvmaC7TDf hU/WVrq40rEAAAAAAAA= --------------ms020607090701040706010701-- --===============1056029414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============1056029414==-- From kitten-bounces@lists.ietf.org Thu Jun 14 15:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyudw-0000Km-7V; Thu, 14 Jun 2007 15:06:04 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1Hyudu-0000Kd-TO for kitten-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 15:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyudu-0000KU-Js for kitten@ietf.org; Thu, 14 Jun 2007 15:06:02 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyuds-0002UK-8w; Thu, 14 Jun 2007 15:06:02 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l5EJ5vMC029691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 15:05:58 -0400 (EDT) Date: Thu, 14 Jun 2007 15:05:57 -0400 From: Jeffrey Hutzelman To: Peter Saint-Andre , martin.rex@sap.com Message-ID: In-Reply-To: <46718A09.1000400@jabber.org> References: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> <46718A09.1000400@jabber.org> Originator-Info: login-token=Mulberry:01gUwwmeu0pQ3Nl6gatMpgCBi+Z8QIgKnuwV7+t8w=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org, Jeffrey Hutzelman Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thursday, June 14, 2007 12:33:45 PM -0600 Peter Saint-Andre wrote: > It's not clear to me how the session replay attack you mention is > specific to the architecture I described. Couldn't an attacker send an > earlier ticket even if there is only one service involved (i.e., in my > description, only one connection manager)? The basic Kerberos protocol provides only a limited amount of reply protection for applications, by requiring that clients include in their request a timestamp which must be "close enough" to the server's clock. The idea is that you get full replay protection by combining this with a cache which stores all messages received within the "close enough" period -- messages that are too old are rejected outright; more recent messages are rejected if they appear in the replay cache. This only works if servers which share the same service key also share the same replay cache. (BTW, the details of Kerberos are getting just a bit far afield for the Kitten list; at the GSS-API layer you're not supposed to care much what mechanism is being used, and at the SASL layer you should care even less). Depending on the application involved, this may not be an issue. For example, some application protocols are designed such that the application messages themselves are protected from replays, or require some sort of initial exchange that makes a replay impossible. Similarly, you have to see a message to replay it, so if you are always using TLS _and checking the server's certificate_, then you need not worry about your credentials being replayed to a server. Of course, servers do not have the luxury of assuming that clients will behave in this way. > My understanding of potential objections to the method I described in my > previous email is that there is no way for the XMPP client to trust that > the connection manager (asserted as cm6.example.com) is associated with > the domain (example.com) to which the initiator connected in the first > place. Right. This is why the domain indicated by the initiator is one of the parts of a domain-based service name; the presumption is that authentication with such a name will succeed only if that server is valid for that domain. > But if the client and connection manager have successfully > upgraded the XMPP stream to TLS (see Section 5 of RFC 3920), then > presumably the connection manager has provided appropriate credentials > (e.g., X.509 certificate) that it is indeed so associated. If that were true, then you wouldn't need a domain-based service name at all. You could potentially just assume that whatever service name the service gives you is valid. However, that's dangerous, as it could allow a "legitimate" but evil server to trick you into carrying out a negotiation to authenticate yourself to some other, unrelated service, and then cut you off and do anything it wants to the other service as you. Also, "the connection manager has provided appropriate credentials" is unfortunately not a very good presumption. Between users ignoring warning dialogs, software that ships with who-knows-what trust anchors, and software that just plain doesn't bother to validate server credentials, it is often the case that a TLS connection is established without the server actually proving its identity. While this may be the best you can do for some authentication methods, I would not count on it for the security of Kerberos authentication, where it clearly is not necessary. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 14 16:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvsT-0002iP-Of; Thu, 14 Jun 2007 16:25:09 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HyvsS-0002iK-8x for kitten-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvsR-0002iC-Vl for kitten@ietf.org; Thu, 14 Jun 2007 16:25:07 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyvsQ-0001Kk-Op; Thu, 14 Jun 2007 16:25:07 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa29549; 14 Jun 2007 16:24 EDT Date: Thu, 14 Jun 2007 16:24:34 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Joe Hildebrand In-Reply-To: <2A660DEF-E6D6-4A8E-970A-65D152495E93@jabber.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: kitten@ietf.org, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, 14 Jun 2007, Joe Hildebrand wrote: > I'm not tracking what you meant by "not necessary". Are you saying > it's OK for the the CM to send it's service principal name to the > client through an insecure channel? No; I'm saying that it is not necessary to make the security of sasl-gss-krb5 dependent on the security of the TLS tunnel over which it is run, and that therefore it would be a poor design choice to introduce such a dependency by specifying a means for obtaining the service principal name that depends on the security of that tunnel. That said, if you are using domain-based service names and doing so correctly, it _is_ OK for the CM to send the hostname part to the client through an insecure channel, as long as the service and domain parts are obtained securely -- for example, from the protocol spec and the user, respectively. That is, if the user wants to talk to the XMPP service at example.com, then the only acceptable value for the service part is "xmpp" (per the spec), and the only acceptable value for the domain part is "example.com" (from the user). The hostname can be obtained from the CM by any means you want. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 14 16:46:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywDF-0001bP-0A; Thu, 14 Jun 2007 16:46:37 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HyvZT-0003oI-V0 for kitten-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvZT-0003mZ-4K for kitten@ietf.org; Thu, 14 Jun 2007 16:05:31 -0400 Received: from dencmdt1.jabber.com ([207.182.164.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvZR-0006sn-Sg; Thu, 14 Jun 2007 16:05:31 -0400 Received: by dencmdt1.jabber.com (Postfix, from userid 88) id 7C4C62D125; Thu, 14 Jun 2007 14:05:29 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on dencmdt1.jabber.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 Received: from dencms1.corp.jabber.com (exchange.jabber.com [207.182.164.150]) by dencmdt1.jabber.com (Postfix) with ESMTP id AF5492D11C; Thu, 14 Jun 2007 14:05:28 -0600 (MDT) Received: from [10.2.1.248] ([10.2.1.248]) by dencms1.corp.jabber.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:05:28 -0600 In-Reply-To: References: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> <46718A09.1000400@jabber.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Jabber-Id: jhildebrand@corp.jabber.com Message-Id: <2A660DEF-E6D6-4A8E-970A-65D152495E93@jabber.com> Content-Transfer-Encoding: 7bit From: Joe Hildebrand Date: Thu, 14 Jun 2007 14:05:25 -0600 To: Jeffrey Hutzelman X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 20:05:28.0407 (UTC) FILETIME=[5A860E70:01C7AEBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 14 Jun 2007 16:46:35 -0400 Cc: kitten@ietf.org, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Jun 14, 2007, at 1:05 PM, Jeffrey Hutzelman wrote: > Also, "the connection manager has provided appropriate credentials" > is unfortunately not a very good presumption. Between users > ignoring warning dialogs, software that ships with who-knows-what > trust anchors, and software that just plain doesn't bother to > validate server credentials, it is often the case that a TLS > connection is established without the server actually proving its > identity. While this may be the best you can do for some > authentication methods, I would not count on it for the security of > Kerberos authentication, where it clearly is not necessary. I'm not tracking what you meant by "not necessary". Are you saying it's OK for the the CM to send it's service principal name to the client through an insecure channel? -- Joe Hildebrand _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jun 14 16:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywGP-0003Wq-1T; Thu, 14 Jun 2007 16:49:53 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HywGN-0003Wl-2I for kitten-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywGM-0003Wd-P0 for kitten@ietf.org; Thu, 14 Jun 2007 16:49:50 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HywGL-0007Fq-7p; Thu, 14 Jun 2007 16:49:50 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id 173D361E41D; Thu, 14 Jun 2007 14:51:16 -0600 (MDT) Message-ID: <4671AA43.9070900@jabber.org> Date: Thu, 14 Jun 2007 14:51:15 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jeffrey Hutzelman References: In-Reply-To: Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Joe Hildebrand , kitten@ietf.org, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux 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="===============0433245137==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0433245137== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050209090202060501000604" This is a cryptographically signed message in MIME format. --------------ms050209090202060501000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > On Thu, 14 Jun 2007, Joe Hildebrand wrote: > >> I'm not tracking what you meant by "not necessary". Are you saying >> it's OK for the the CM to send it's service principal name to the >> client through an insecure channel? > > No; I'm saying that it is not necessary to make the security of > sasl-gss-krb5 dependent on the security of the TLS tunnel over which it is > run, and that therefore it would be a poor design choice to introduce such > a dependency by specifying a means for obtaining the service principal > name that depends on the security of that tunnel. > > > That said, if you are using domain-based service names and doing so > correctly, it _is_ OK for the CM to send the hostname part to the client > through an insecure channel, as long as the service and domain parts are > obtained securely -- for example, from the protocol spec and the user, > respectively. > > That is, if the user wants to talk to the XMPP service at example.com, > then the only acceptable value for the service part is "xmpp" (per the > spec), and the only acceptable value for the domain part is "example.com" > (from the user). The hostname can be obtained from the CM by any means > you want. Aha, OK. In our case it is indeed true that (1) the only acceptable value for the service part is "xmpp" and (2) the domain part will be provided by the user. It also happens to be true that in a typical high-security deployment the hostname of the CM will be communicated from the CM to the user over a TLS-encrypted XML stream; however, at an implementation level TLS is not yet required in XMPP so it possible that the hostname of the CM may be communicated over an XML stream that is not TLS-encrypted -- but you are saying that doesn't matter anyway. BTW this issue will probably not be addressed in rfc3920bis because it is a bit of an edge case that is useful only for certain deployments, but we will probably define an XMPP extension for this functionality in a spec produced by the XMPP Standards Foundation. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms050209090202060501000604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDYxNDIwNTExNVowIwYJKoZIhvcNAQkEMRYEFNpXbJcE2vdov67uwWDwI6awQu5uMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAKVfC7b1auSAmiYFk8jcKLqSKcGasMbRajSgSsOXRDwv NWKBSIEOwolXU46PtKQKbmQHrqrfellBgvTmTzI0LwlMi9LqBZEyb/R/OmPiXKtulu2u9B9G KsSCtwXdpZSyFHXOjZEY2V69i2Rhg/qRLnxtn6lOO3fKxq9qMTEFdzrzQb7KOGl//oCD+XHM fXBRtTJuHkMj7RR2vCVTa1chkNFAb8kAkqelA5TaCjFlo1yN1C+NwKdGSwNGb/kPEtxkFdMg GIGYq3gkfyPaGtzj31Re7mVZMHvcAkZW5bvFs1Sn7/JplftjGmKb2ruZpTI/iD5BH7rsUDrn ooN+diBuOdUAAAAAAAA= --------------ms050209090202060501000604-- --===============0433245137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten --===============0433245137==-- From kitten-bounces@lists.ietf.org Fri Jun 15 00:56:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3qk-00084B-3q; Fri, 15 Jun 2007 00:55:54 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1Hz3qi-00083N-Qb for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 00:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3qi-00083F-Go for kitten@lists.ietf.org; Fri, 15 Jun 2007 00:55:52 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz3qh-0001w0-5x for kitten@lists.ietf.org; Fri, 15 Jun 2007 00:55:52 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5F4toqc001110 for ; Fri, 15 Jun 2007 04:55:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJN00201UJQJ500@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@lists.ietf.org; Thu, 14 Jun 2007 22:55:50 -0600 (MDT) Received: from [129.150.48.17] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJN00IIRV11AVY4@mail-amer.sun.com> for kitten@lists.ietf.org; Thu, 14 Jun 2007 22:55:50 -0600 (MDT) Date: Thu, 14 Jun 2007 22:54:52 -0600 From: Shawn M Emery To: kitten@lists.ietf.org Message-id: <46721B9C.9080307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (X11/20070419) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Agenda Review X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org We've published the agenda proposed for the kitten-wg meeting in July here: http://www3.ietf.org/proceedings/07jul/agenda/kitten.txt Please provide any comments or questions. Thank you, -- Shawn. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 15:47:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHlR-0002HY-6W; Fri, 15 Jun 2007 15:47:21 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzHlP-0002HH-Bi for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHlP-0002Gf-1p for kitten@ietf.org; Fri, 15 Jun 2007 15:47:19 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHlF-0001tm-UG; Fri, 15 Jun 2007 15:47:19 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FJl8oe016853; Fri, 15 Jun 2007 19:47:09 GMT Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5FJl8HN028631; Fri, 15 Jun 2007 13:47:08 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5FJkFrS021088; Fri, 15 Jun 2007 14:46:15 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5FJkDXS021087; Fri, 15 Jun 2007 14:46:13 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 15 Jun 2007 14:46:13 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070615194612.GO19770@Sun.COM> Mail-Followup-To: Martin Rex , Peter Saint-Andre , kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org References: <466DCFBA.9020001@jabber.org> <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex wrote: > I never liked hostbased service names ;-) Well, we undoubtably need principal names for hosts. The service part seems... less necessary. That said, the service name component does simplify privilege separation of different applications running on the same host because each can manage its own keys without impacting the others. Without service names one has to ensure that there is a local facility for handling keys that does not expose them to the apps, at least where said keys can be used by one app against the other (typically that would be symmetric keys in a protocol like Kerberos V). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 16:24:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHva-0007II-6o; Fri, 15 Jun 2007 15:57:50 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzHvY-0007HX-AO for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:57:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHvP-0007BO-HO for kitten@ietf.org; Fri, 15 Jun 2007 15:57:39 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzHug-0006nj-HE; Fri, 15 Jun 2007 15:57:25 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FJuse1026175; Fri, 15 Jun 2007 19:56:54 GMT Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5FJur5r002559; Fri, 15 Jun 2007 13:56:53 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5FJu0LY021104; Fri, 15 Jun 2007 14:56:00 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5FJu0Xk021103; Fri, 15 Jun 2007 14:56:00 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 15 Jun 2007 14:56:00 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070615195559.GQ19770@Sun.COM> Mail-Followup-To: Martin Rex , Peter Saint-Andre , kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org References: <466DCFBA.9020001@jabber.org> <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org Subject: Hostbased service names (Re: domain-based service names redux) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex wrote: > The most sensible and infrastructure-independent approach (i.e. independent > of how load-balancing is done within the backend and where within > the backend the secure communication is terminated) for traditional > Kerberos authentication would be to standardize the user2user > authentication exchange and use that (no use of _hostbased_ > service names). Well, no. The ideal thing to do (as opposed to the *pragmatic* thing to do) is to add a new krb5 mech or extension to the existing mech that uses three tokens, with an option for user-to-user[*], so as to get rid of the need for a replay cache. That has nothing to do with also deprecating the user of hostbased service names. Apps will still need a way to name non-human entities running on specific hosts. And whether we drop the _service_ part of hostbased service names is also an other story. [*] With RFC4120 as it is it is not quite possible to do a three-token user-2-user mechanism; four tokens are required. That's because the initiator has to be the one sending the AP-REQ, but it can't make an AP-REQ until it has obtained the acceptor's Ticket (which has got to be sent no earlier than in the second token since in the GSS-API the initiator always sends the first token). A user-2-user three-token mechanism is possible however, but the spec for it would have to update RFC4120. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 17:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJWt-0001Xr-LL; Fri, 15 Jun 2007 17:40:27 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzJWs-0001Xa-94 for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJWr-0001XS-VZ for kitten@ietf.org; Fri, 15 Jun 2007 17:40:25 -0400 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJWq-0002cp-Iw; Fri, 15 Jun 2007 17:40:25 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 2FA3242B98; Fri, 15 Jun 2007 17:40:16 -0400 (EDT) Date: Fri, 15 Jun 2007 17:40:14 -0400 From: Michael B Allen To: Nicolas Williams Message-Id: <20070615174014.04105aa7.mba2000@ioplex.com> In-Reply-To: <20070615194612.GO19770@Sun.COM> References: <466DCFBA.9020001@jabber.org> <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> <20070615194612.GO19770@Sun.COM> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, Martin Rex , sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 15 Jun 2007 14:46:13 -0500 Nicolas Williams wrote: > On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex wrote: > > I never liked hostbased service names ;-) > > Well, we undoubtably need principal names for hosts. The service part > seems... less necessary. > > That said, the service name component does simplify privilege separation > of different applications running on the same host because each can > manage its own keys without impacting the others. Without service names > one has to ensure that there is a local facility for handling keys that > does not expose them to the apps, at least where said keys can be used > by one app against the other (typically that would be symmetric keys in > a protocol like Kerberos V). Hi Nico, I haven't really been following this thread carefully but I have a thought that may or may not be relevant. When authenticating HTTP clients using Kerberos / GSSPI it's very nice to be able to call gss_accept_sec_context with GSS_C_NO_CREDENTIAL so that the server can choose a key in the keytab suitable for the target principal requested. As I'm sure you're aware HTTP clients do different things to come up with the target SPN. Some just use the hostname in the URL. Some do some canonicalization. If you're doing virtual hosting browsers will send different SPNs. However, rumor has it that if GSS_C_NO_CREDENTIAL is used I think clients can authenticate with services using an SPN that is different from the SPN the ticket was acquired with. Meaning, depending on how accounts are setup, someone might be able to use their FTP ticket to authenticate with HTTP. Anyway I'm thinking about how that might interact with using service name components to implement "privilege separation". Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 18:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKGi-0007pC-DK; Fri, 15 Jun 2007 18:27:48 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzKGh-0007p4-IQ for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 18:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKGh-0007or-8M for kitten@ietf.org; Fri, 15 Jun 2007 18:27:47 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKGg-00033c-Ub; Fri, 15 Jun 2007 18:27:47 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FMRktg019093; Fri, 15 Jun 2007 22:27:46 GMT Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5FMRjJh006165; Fri, 15 Jun 2007 16:27:45 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5FMQppg021241; Fri, 15 Jun 2007 17:26:51 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5FMQpm8021240; Fri, 15 Jun 2007 17:26:51 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 15 Jun 2007 17:26:51 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070615222651.GU19770@Sun.COM> Mail-Followup-To: Michael B Allen , Martin Rex , kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, sasl@ietf.org References: <466DCFBA.9020001@jabber.org> <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> <20070615194612.GO19770@Sun.COM> <20070615174014.04105aa7.mba2000@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070615174014.04105aa7.mba2000@ioplex.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, Martin Rex , sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Jun 15, 2007 at 05:40:14PM -0400, Michael B Allen wrote: > When authenticating HTTP clients using Kerberos / GSSPI it's very nice > to be able to call gss_accept_sec_context with GSS_C_NO_CREDENTIAL so > that the server can choose a key in the keytab suitable for the target > principal requested. No, that's _always_ nice to be able to do :) > As I'm sure you're aware HTTP clients do different things to come up > with the target SPN. Some just use the hostname in the URL. Some do > some canonicalization. If you're doing virtual hosting browsers will > send different SPNs. > > However, rumor has it that if GSS_C_NO_CREDENTIAL is used I think clients > can authenticate with services using an SPN that is different from the > SPN the ticket was acquired with. Meaning, depending on how accounts > are setup, someone might be able to use their FTP ticket to authenticate > with HTTP. Right. Two things: 1) Different services using different acceptor principals shouldn't share acceptor credentials. If they don't share those credentials then this can't happen. 2) Acceptors that use GSS_C_NO_CREDENTIAL should check the target name used by the initiator (see GSS_Inquire_sec_context() and GSS_Display_name()). Unfortunately GSS_Display_name() typically returns a mechanism-specific version of the MN used by the initiator, which means that (2) results in less than generic (vis-a-vis mechanisms) code. We have talked in the past about acceptor credential sets, but, frankly, the GSS-API is complicated enough as it is that (1) is the best way forward here, and an improved version of GSS_Display_name() (which we intend to pursue) would help implementors pursuing (2). > Anyway I'm thinking about how that might interact with using service > name components to implement "privilege separation". See (1). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 18:40:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKTB-0007bs-Cm; Fri, 15 Jun 2007 18:40:41 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzKT9-0007QH-L9 for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 18:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzKT9-0007DT-3V for kitten@ietf.org; Fri, 15 Jun 2007 18:40:39 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzKQY-0004pA-Pt for kitten@ietf.org; Fri, 15 Jun 2007 18:38:00 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FMbsnp017222 for ; Fri, 15 Jun 2007 22:37:58 GMT Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l5FMbs72009603 for ; Fri, 15 Jun 2007 16:37:54 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5FMb0EL021293; Fri, 15 Jun 2007 17:37:00 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5FMax2N021292; Fri, 15 Jun 2007 17:36:59 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 15 Jun 2007 17:36:59 -0500 From: Nicolas Williams To: Michael B Allen Message-ID: <20070615223659.GB20623@Sun.COM> Mail-Followup-To: Michael B Allen , Martin Rex , kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, ietf-sasl@imc.org References: <466DCFBA.9020001@jabber.org> <200706122103.l5CL3B2W029985@fs4113.wdf.sap.corp> <20070615194612.GO19770@Sun.COM> <20070615174014.04105aa7.mba2000@ioplex.com> <20070615222651.GU19770@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070615222651.GU19770@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, Martin Rex , ietf-sasl@imc.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org To clarify, (1) means "run each service with a separate keytab (and rcache) with entries only for the principals that you want the service to be able to accept as." _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jun 15 19:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzLdM-0003bh-0C; Fri, 15 Jun 2007 19:55:16 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1HzLdH-0003Sb-CH for kitten-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 19:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzLdG-0003Rv-Vx for kitten@ietf.org; Fri, 15 Jun 2007 19:55:10 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzLcj-00058L-Sm; Fri, 15 Jun 2007 19:54:40 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA20544; Sat, 16 Jun 2007 01:54:32 +0200 (MESZ) From: Martin Rex Message-Id: <200706152354.l5FNsWOb007515@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Sat, 16 Jun 2007 01:54:32 +0200 (MEST) In-Reply-To: <20070615194612.GO19770@Sun.COM> from "Nicolas Williams" at Jun 15, 7 02:46:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: kitten@ietf.org, jhildebrand@jabber.com, linuxwolf@outer-planes.net, Martin.Rex@sap.com, sasl@ietf.org Subject: Re: domain-based service names redux X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams wrote: > > On Tue, Jun 12, 2007 at 11:03:11PM +0200, Martin Rex wrote: > > I never liked hostbased service names ;-) > > Well, we undoubtably need principal names for hosts. The service part > seems... less necessary. Depends on what you do. In many situations hostbased service names are not only unnecessary, they acutually create significant pain and problem. On which particular "host" a service runs today, and on which it runs tomorrow should be left up to the sysadmin, in many situations a causal user need not and ought not to care about this. None of the X.509-based gssapi mechanims I've seen so far did support hostbased service names. Probably all of our customers that use an X.509-based gssapi mechanism for single sign-on do *NOT* put hostnames into their server's certificates, but instead the name of the distributed system, because it is so much easier if you can share the credentials for all servers in your backend server farm. You also don't have to mess with the ACLs used by backend servers to authenticate each other when you add or change/replace servers. When using domain-based service names, the "service name" should probably not name a protocol, but rather a particular incarnation of a service. Otherwise, one would need a seperate "domain" (DNS-domain, Kerberos Realm) for each independently-managed incarnation of a service talking a particular protocol. A single (independently managed) Web-Server per domain looks like a pretty strong limitation to me, and requiring a seperate domain (or worse, a seperate kerberos realm) per Web-Server is a fairly expensive solution (e.g. when each kerberos realm is equal to a seperate Windows PDC). But if _not_ using the protocol for the service part of the name, the client software has little chance to guess it (or to supply it automatically), it needs to get that information from the user. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten