From kitten-bounces@lists.ietf.org Thu Mar 02 16:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEveN-0007Nb-JX; Thu, 02 Mar 2006 16:47:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuqE-00079Z-Ro for kitten@ietf.org; Thu, 02 Mar 2006 15:56:07 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuoQ-0007WV-8X for kitten@ietf.org; Thu, 02 Mar 2006 15:54:15 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k22KsD4u020717 for ; Thu, 2 Mar 2006 12:54:13 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k22KsCUM027791 for ; Thu, 2 Mar 2006 13:54:13 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k22Ks8vr002578 for ; Thu, 2 Mar 2006 14:54:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k22Ks8Go002577 for kitten@ietf.org; Thu, 2 Mar 2006 14:54:08 -0600 (CST) Date: Thu, 2 Mar 2006 14:54:08 -0600 From: Nicolas Williams To: kitten@ietf.org Message-ID: <20060302205407.GH24187@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: WGLC for domain-based service principal names? 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 Are they ready? Anybody want to review them again? The NFSv4 WG seems to be reaching consensus on a method for discovering a domain's "root" NFSv4 servers based on DNS SRV RRs, and this requires either the use of DNSSEC or domain-based service principal names. It might be useful to the NFSv4 WG to have proposed standard docs for domain-based service principal names that can be referenced from that I-D. The domain-based service principal name I-Ds have been reviewed in the past, but not particularly recently. Should we do a WGLC? Exhort participants to review them [again, in some cases]? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 02 17:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwPP-0003x4-71; Thu, 02 Mar 2006 17:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwPN-0003p9-Ut for kitten@ietf.org; Thu, 02 Mar 2006 17:36:29 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwPM-0000ep-N9 for kitten@ietf.org; Thu, 02 Mar 2006 17:36:29 -0500 Received: from [192.168.1.11] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k22MaRai005587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Mar 2006 17:36:28 -0500 (EST) Message-ID: <440773C8.4010007@columbia.edu> Date: Thu, 02 Mar 2006 17:38:00 -0500 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: kitten@ietf.org References: <20060302205407.GH24187@binky.Central.Sun.COM> In-Reply-To: <20060302205407.GH24187@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Subject: Re: WGLC for domain-based service principal names? 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="===============1446834598==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1446834598== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070002020305060402090100" This is a cryptographically signed message in MIME format. --------------ms070002020305060402090100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > Are they ready? Anybody want to review them again? > > The NFSv4 WG seems to be reaching consensus on a method for discovering > a domain's "root" NFSv4 servers based on DNS SRV RRs, and this requires > either the use of DNSSEC or domain-based service principal names. It > might be useful to the NFSv4 WG to have proposed standard docs for > domain-based service principal names that can be referenced from that > I-D. > > The domain-based service principal name I-Ds have been reviewed in the > past, but not particularly recently. Should we do a WGLC? Exhort > participants to review them [again, in some cases]? > > Nico I agree that we would like to provide the NFSv4 as well as LDAP the ability to use domain service principals. Here are the drafts for reference http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-based-names-01.txt http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-domain-based-names-01.txt There was significant discussion prior to the publication of the drafts and no discussion on the list afterwards. The primary concern before publication was that the specification be compatible with that used by Microsoft. I will request that people review these documents in the next couple of days. If there is nothing jumping out at people, I will issue a WGLC. However, I will require positive signs of support in order to successfully conclude the WGLC. Jeffrey Altman --------------ms070002020305060402090100 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwMzAyMjIzODAwWjAjBgkqhkiG9w0BCQQxFgQUn5ZicTfXdgCTJXezrt75HgynfDMw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAO6dCbTYX9i9jXDG7ZEfCozkh6I9b+BRg3ZyUwgCe QVWi/iaz6j2w0AgLK99IYXpjtGmrsgtF2I4mjurIquRhVIyPsZNK95y6M5HX2Jdfc4HiiSgg RImDrkCTW41bQObKDFm7vYtREgr37CXaXrScWn3MslQpcvC4LPPDZQit14PB3rlTNl7uNUrr S7HDQdHKVQivWLG2TV06N0grhtFe2szDbBtqwZqdljZsAUgZbxBKbMPI0HS+OssagOd5aRF3 AD0elM+V5WXGlpmjtF4okRBkh2PSQXTJoa6iE6dHWHIS1ve3qxSEEi4DkKNIP/J72Mgy2sTe WbusAGKjuT1jkAAAAAAAAA== --------------ms070002020305060402090100-- --===============1446834598== 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 --===============1446834598==-- From kitten-bounces@lists.ietf.org Thu Mar 02 17:43:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwW6-0007Dk-U2; Thu, 02 Mar 2006 17:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEwW5-00079j-Or for kitten@ietf.org; Thu, 02 Mar 2006 17:43:25 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEwW4-0000tG-G6 for kitten@ietf.org; Thu, 02 Mar 2006 17:43:25 -0500 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k22MhNQj002333 for ; Thu, 2 Mar 2006 15:43:24 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k22MhMUO000461 for ; Thu, 2 Mar 2006 15:43:23 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k22MhMdS002921; Thu, 2 Mar 2006 16:43:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k22MhMHC002920; Thu, 2 Mar 2006 16:43:22 -0600 (CST) Date: Thu, 2 Mar 2006 16:43:22 -0600 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060302224322.GD2705@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Altman , kitten@ietf.org References: <20060302205407.GH24187@binky.Central.Sun.COM> <440773C8.4010007@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440773C8.4010007@columbia.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? 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, Mar 02, 2006 at 05:38:00PM -0500, Jeffrey Altman wrote: > I will request that people review these documents in the next couple > of days. If there is nothing jumping out at people, I will issue a > WGLC. Thanks. > However, I will require positive signs of support in order to > successfully conclude the WGLC. Of course. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 02 19:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyQm-0003X4-A7; Thu, 02 Mar 2006 19:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyQl-0003Ug-Cl for kitten@ietf.org; Thu, 02 Mar 2006 19:46:03 -0500 Received: from au.padl.com ([203.13.32.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyQj-0001Ia-Kd for kitten@ietf.org; Thu, 02 Mar 2006 19:46:03 -0500 Received: from au.padl.com (localhost.padl.com [127.0.0.1]) by au.padl.com (8.12.11/8.12.11) with ESMTP id k230jVIZ084756; Fri, 3 Mar 2006 11:45:31 +1100 (EST) (envelope-from lukeh@au.padl.com) Received: (from lukeh@localhost) by au.padl.com (8.12.11/8.12.11/Submit) id k230jQbV084755; Fri, 3 Mar 2006 11:45:26 +1100 (EST) (envelope-from lukeh) From: Luke Howard Message-Id: <200603030045.k230jQbV084755@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: jaltman@columbia.edu References: <20060302205407.GH24187@binky.Central.Sun.COM> <440773C8.4010007@columbia.edu> Date: Fri, 3 Mar 2006 11:45:25 +1100 Versions: dmail (bsd44) 2.6d/makemail 2.10 X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on au.padl.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukeh@padl.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >drafts and no discussion on the list afterwards. The primary concern >before publication was that the specification be compatible with >that used by Microsoft. The Kerberos principal name format appears to be compatible with that used by MS. I guess Larry should take a look though. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 02 20:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyj5-00005H-IU; Thu, 02 Mar 2006 20:04:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEyj4-000057-4M for kitten@ietf.org; Thu, 02 Mar 2006 20:04:58 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEyj2-0001xc-QX for kitten@ietf.org; Thu, 02 Mar 2006 20:04:58 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 2 Mar 2006 17:04:56 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 17:04:55 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 17:04:55 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 17:04:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Mar 2006 17:04:54 -0800 Message-ID: In-Reply-To: <200603030045.k230jQbV084755@au.padl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for domain-based service principal names? Thread-Index: AcY+W+un7B+EM3+LQbCfuzx98ow0PAAAlWDA From: "Liqiang\(Larry\) Zhu" To: , X-OriginalArrivalTime: 03 Mar 2006 01:04:55.0254 (UTC) FILETIME=[7BDC9760:01C63E5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org Subject: RE: WGLC for domain-based service principal names? 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 initial draft was not compatible with the deployed base, and I raised the objection and Nico changed it to be compatible, but I would take a look at the latest version again, report back if there is any red flag. Thx. -----Original Message----- From: Luke Howard [mailto:lukeh@padl.com]=20 Sent: Thursday, March 02, 2006 4:45 PM To: jaltman@columbia.edu Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? >drafts and no discussion on the list afterwards. The primary concern=20 >before publication was that the specification be compatible with that=20 >used by Microsoft. The Kerberos principal name format appears to be compatible with that used by MS. I guess Larry should take a look though. -- Luke -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 04:10:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6Ih-0005ZW-2h; Fri, 03 Mar 2006 04:10:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6Ie-0005ZQ-Ct for kitten@ietf.org; Fri, 03 Mar 2006 04:10:13 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6Ie-0003kP-25 for kitten@ietf.org; Fri, 03 Mar 2006 04:10:12 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Mar 2006 01:10:11 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 01:10:10 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 01:10:10 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 01:10:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 01:10:09 -0800 Message-ID: In-Reply-To: <440773C8.4010007@columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for domain-based service principal names? Thread-Index: AcY+Sda+6OF4KCN/TuC/OFbA3VjgUAAV/XYQ From: "Liqiang\(Larry\) Zhu" To: "Jeffrey Altman" , X-OriginalArrivalTime: 03 Mar 2006 09:10:09.0895 (UTC) FILETIME=[458A3F70:01C63EA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: RE: WGLC for domain-based service principal names? 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 name representations seems unchanged after the initial discussion. "not necessarily and Internat domain name" s/and/an/ I am not sure the following claims are fully justified/demonstrated. If there were other LDAP directories, then clients could not tell which service is authorized to serve which directory, not without assuming a secure method for finding LDAP servers (e.g., DNSSEC). This is a significant, and oft-unstated restriction on users of LDAP. Domain based names can eliminate this problem by allowing LDAP service names to indicate which LDAP directory they are authorized to serve. I would personally believe some facelifting such as the removal of the word TBD help make these ready for WGLC. -- Larry -----Original Message----- From: Jeffrey Altman [mailto:jaltman@columbia.edu]=20 Sent: Thursday, March 02, 2006 2:38 PM To: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? Nicolas Williams wrote: > Are they ready? Anybody want to review them again? >=20 > The NFSv4 WG seems to be reaching consensus on a method for=20 > discovering a domain's "root" NFSv4 servers based on DNS SRV RRs, and=20 > this requires either the use of DNSSEC or domain-based service=20 > principal names. It might be useful to the NFSv4 WG to have proposed=20 > standard docs for domain-based service principal names that can be=20 > referenced from that I-D. >=20 > The domain-based service principal name I-Ds have been reviewed in the > past, but not particularly recently. Should we do a WGLC? Exhort=20 > participants to review them [again, in some cases]? >=20 > Nico I agree that we would like to provide the NFSv4 as well as LDAP the ability to use domain service principals. Here are the drafts for reference http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-domain-base d-names-01.txt http://www.ietf.org/internet-drafts/draft-ietf-kitten-krb5-gssapi-domain -based-names-01.txt There was significant discussion prior to the publication of the drafts and no discussion on the list afterwards. The primary concern before publication was that the specification be compatible with that used by Microsoft. I will request that people review these documents in the next couple of days. If there is nothing jumping out at people, I will issue a WGLC. However, I will require positive signs of support in order to successfully conclude the WGLC. Jeffrey Altman _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 12:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE8B-0001nr-WB; Fri, 03 Mar 2006 12:31:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE8A-0001nl-ON for kitten@ietf.org; Fri, 03 Mar 2006 12:31:54 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFE8A-0005vz-7x for kitten@ietf.org; Fri, 03 Mar 2006 12:31:54 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k23HVrdK028497 for ; Fri, 3 Mar 2006 09:31:53 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k23HVpUO027234 for ; Fri, 3 Mar 2006 10:31:52 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k23HU3de003708; Fri, 3 Mar 2006 11:30:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k23HU2bR003707; Fri, 3 Mar 2006 11:30:02 -0600 (CST) Date: Fri, 3 Mar 2006 11:30:02 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20060303173002.GC3676@binky.Central.Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , Jeffrey Altman , kitten@ietf.org References: <440773C8.4010007@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? 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, Mar 03, 2006 at 01:10:09AM -0800, Liqiang(Larry) Zhu wrote: > The name representations seems unchanged after the initial discussion. No? I'll dig up the e-mails and double check. > "not necessarily and Internat domain name" > > s/and/an/ > > I am not sure the following claims are fully justified/demonstrated. > > If there were other LDAP directories, then > clients could not tell which service is authorized to serve which > directory, not without assuming a secure method for finding LDAP > servers (e.g., DNSSEC). This is a significant, and oft-unstated > restriction on users of LDAP. Which part of this is not justified? Given a client that has no idea who its LDAP servers are but which does have Kerberos V credentials, how can it tell if the LDAP servers discovered through a DNS SRV RR lookup are the ones it should be talking to? With a priori configuration, particularly of trust anchors and/or self-signed cert pre-sharing, sure, the client can throw out fake (spoofed) results. But using only Kerberos V and only host-based service principal naming it cannot tell the difference between two legitimate LDAP servers only one of which is legitimate as a DS for the domain. I have seen environments where there is one set of LDAP servers for the domain's DIT and other sets of LDAP servers for entirely different purposes, but still in the same domain. You might ask "but what administrator would give such other LDAP servers ldap service principal accounts?" -- and that leads to a workaround, but that workaround does not work for NFSv4, where we want to have lots and lots of NFSv4 servers in some large domain, but very few "root" NFSv4 servers. > Domain based names can eliminate this problem by allowing LDAP > service names to indicate which LDAP directory they are authorized to > serve. Is there anything wrong with this? > I would personally believe some facelifting such as the removal of the > word TBD help make these ready for WGLC. Of course. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 12:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEYy-0002Yd-8Z; Fri, 03 Mar 2006 12:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEYw-0002SR-OD for kitten@ietf.org; Fri, 03 Mar 2006 12:59:34 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFEYw-0006tY-DN for kitten@ietf.org; Fri, 03 Mar 2006 12:59:34 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Mar 2006 09:59:33 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:59:32 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:59:32 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 09:59:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 09:59:31 -0800 Message-ID: In-Reply-To: <20060303173002.GC3676@binky.Central.Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for domain-based service principal names? Thread-Index: AcY+6GeqE/ZlbjD1Tn6TVoN1yLFz+AAAl6GQ From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" X-OriginalArrivalTime: 03 Mar 2006 17:59:32.0318 (UTC) FILETIME=[396B5FE0:01C63EEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: kitten@ietf.org Subject: RE: WGLC for domain-based service principal names? 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 =20 Nicolas.Williams@sun.com wrote: > Which part of this is not justified? It is unclear to me how can we leverage the domain based name to obviate DNSSEC, can you elaborate on that? > If there were other LDAP directories, then > clients could not tell which service is authorized to serve which > directory, not without assuming a secure method for finding LDAP > servers (e.g., DNSSEC). This is a significant, and oft-unstated > restriction on users of LDAP. Also I think the word "domain" already has specific meanings, how about "replicated service name" instead, that is more accurate or more specific, isn't it? -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, March 03, 2006 9:30 AM To: Liqiang(Larry) Zhu Cc: Jeffrey Altman; kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? On Fri, Mar 03, 2006 at 01:10:09AM -0800, Liqiang(Larry) Zhu wrote: > The name representations seems unchanged after the initial discussion. No? I'll dig up the e-mails and double check. > "not necessarily and Internat domain name" >=20 > s/and/an/ >=20 > I am not sure the following claims are fully justified/demonstrated. >=20 > If there were other LDAP directories, then > clients could not tell which service is authorized to serve which > directory, not without assuming a secure method for finding LDAP > servers (e.g., DNSSEC). This is a significant, and oft-unstated > restriction on users of LDAP. Which part of this is not justified? Given a client that has no idea who its LDAP servers are but which does have Kerberos V credentials, how can it tell if the LDAP servers discovered through a DNS SRV RR lookup are the ones it should be talking to? With a priori configuration, particularly of trust anchors and/or self-signed cert pre-sharing, sure, the client can throw out fake (spoofed) results. But using only Kerberos V and only host-based service principal naming it cannot tell the difference between two legitimate LDAP servers only one of which is legitimate as a DS for the domain. I have seen environments where there is one set of LDAP servers for the domain's DIT and other sets of LDAP servers for entirely different purposes, but still in the same domain. You might ask "but what administrator would give such other LDAP servers ldap service principal accounts?" -- and that leads to a workaround, but that workaround does not work for NFSv4, where we want to have lots and lots of NFSv4 servers in some large domain, but very few "root" NFSv4 servers. > Domain based names can eliminate this problem by allowing LDAP > service names to indicate which LDAP directory they are authorized to > serve. Is there anything wrong with this? > I would personally believe some facelifting such as the removal of the > word TBD help make these ready for WGLC. Of course. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 13:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEgl-0005U7-Nv; Fri, 03 Mar 2006 13:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEgk-0005PT-Ds for kitten@ietf.org; Fri, 03 Mar 2006 13:07:38 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFEgk-0007Dt-09 for kitten@ietf.org; Fri, 03 Mar 2006 13:07:38 -0500 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k23I7b4u023785 for ; Fri, 3 Mar 2006 10:07:37 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k23I7aUO026224 for ; Fri, 3 Mar 2006 11:07:36 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k23I7ZhG003753; Fri, 3 Mar 2006 12:07:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k23I7Z60003752; Fri, 3 Mar 2006 12:07:35 -0600 (CST) Date: Fri, 3 Mar 2006 12:07:35 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20060303180735.GH3676@binky.Central.Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , Jeffrey Altman , kitten@ietf.org References: <20060303173002.GC3676@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? 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, Mar 03, 2006 at 09:59:31AM -0800, Liqiang(Larry) Zhu wrote: > > Nicolas.Williams@sun.com wrote: > > Which part of this is not justified? > > It is unclear to me how can we leverage the domain based name to obviate > DNSSEC, can you elaborate on that? Sure. Let me give two examples, one using NFSv4 and one using LDAP. With NFSv4 there might be three replicated root servers for, say, sun.com, and hundreds of non-root servers. All of these get nfs/f.q.d.n@SUN.COM principal names, but only the root servers get domain-based service principal names for the 'nfs' service and the 'sun.com' domain. If a client's DNS SRV lookup for sun.com's root NFSv4 servers gets spoofed in an attempt to re-direct the client then the client will not be able to obtain tickets for the non-root servers it is being re-directed to because those servers would not have domain-based service principal accounts for nfs and sun.com. In the case of LDAP sun.com might have one set of LDAP servers for the enterprise, and several unrelated LDAP servers for various purposes, e.g., test, development, meta-directories, etc... Clients configured to use LDAP as a name service should only use the first set, and only that set should have domain-based service principal names for the 'ldap' service and the 'sun.com' domain. The same logic as above protects the client against spoofs. Clients of the other LDAP servers have to be configured to securely find them using something other than DNS SRV RRs. > > If there were other LDAP directories, then > > clients could not tell which service is authorized to serve which > > directory, not without assuming a secure method for finding LDAP > > servers (e.g., DNSSEC). This is a significant, and oft-unstated > > restriction on users of LDAP. > > Also I think the word "domain" already has specific meanings, how about > "replicated service name" instead, that is more accurate or more > specific, isn't it? Yes, "domain" is a bit overloaded. The DNS sense of the word suffices here, I think. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 13:52:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFOA-0004yx-NE; Fri, 03 Mar 2006 13:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFOA-0004wb-5w for kitten@ietf.org; Fri, 03 Mar 2006 13:52:30 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFFO9-0000dz-S1 for kitten@ietf.org; Fri, 03 Mar 2006 13:52:30 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Mar 2006 10:52:29 -0800 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 10:50:50 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 10:50:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 10:50:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 10:50:46 -0800 Message-ID: In-Reply-To: <20060303180735.GH3676@binky.Central.Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for domain-based service principal names? Thread-Index: AcY+7WokjnJOTNpGSEuikBdtMT1RGgABeVRw From: "Liqiang\(Larry\) Zhu" To: "Nicolas Williams" X-OriginalArrivalTime: 03 Mar 2006 18:50:49.0368 (UTC) FILETIME=[637BF180:01C63EF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: kitten@ietf.org Subject: RE: WGLC for domain-based service principal names? 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 Ok, I am happy with the examples. The text in the ID is terse, but otherwise seems to be fine.=20 -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, March 03, 2006 10:08 AM To: Liqiang(Larry) Zhu Cc: Jeffrey Altman; kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? On Fri, Mar 03, 2006 at 09:59:31AM -0800, Liqiang(Larry) Zhu wrote: > =20 > Nicolas.Williams@sun.com wrote: > > Which part of this is not justified? >=20 > It is unclear to me how can we leverage the domain based name to=20 > obviate DNSSEC, can you elaborate on that? Sure. Let me give two examples, one using NFSv4 and one using LDAP. With NFSv4 there might be three replicated root servers for, say, sun.com, and hundreds of non-root servers. All of these get nfs/f.q.d.n@SUN.COM principal names, but only the root servers get domain-based service principal names for the 'nfs' service and the 'sun.com' domain. If a client's DNS SRV lookup for sun.com's root NFSv4 servers gets spoofed in an attempt to re-direct the client then the client will not be able to obtain tickets for the non-root servers it is being re-directed to because those servers would not have domain-based service principal accounts for nfs and sun.com. In the case of LDAP sun.com might have one set of LDAP servers for the enterprise, and several unrelated LDAP servers for various purposes, e.g., test, development, meta-directories, etc... Clients configured to use LDAP as a name service should only use the first set, and only that set should have domain-based service principal names for the 'ldap' service and the 'sun.com' domain. The same logic as above protects the client against spoofs. Clients of the other LDAP servers have to be configured to securely find them using something other than DNS SRV RRs. > > If there were other LDAP directories, then > > clients could not tell which service is authorized to serve which > > directory, not without assuming a secure method for finding LDAP > > servers (e.g., DNSSEC). This is a significant, and oft-unstated > > restriction on users of LDAP. >=20 > Also I think the word "domain" already has specific meanings, how=20 > about "replicated service name" instead, that is more accurate or more > specific, isn't it? Yes, "domain" is a bit overloaded. The DNS sense of the word suffices here, I think. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 03 14:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFYP-0001mq-5L; Fri, 03 Mar 2006 14:03:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFYN-0001ki-GF for kitten@ietf.org; Fri, 03 Mar 2006 14:03:03 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFFYM-0000oP-7Z for kitten@ietf.org; Fri, 03 Mar 2006 14:03:03 -0500 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k23J31SD005747 for ; Fri, 3 Mar 2006 12:03:01 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k23J30pZ004037 for ; Fri, 3 Mar 2006 12:03:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k23J2x3R003881; Fri, 3 Mar 2006 13:02:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k23J2xsF003880; Fri, 3 Mar 2006 13:02:59 -0600 (CST) Date: Fri, 3 Mar 2006 13:02:58 -0600 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20060303190258.GM3676@binky.Central.Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , kitten@ietf.org References: <20060303180735.GH3676@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? 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, Mar 03, 2006 at 10:50:46AM -0800, Liqiang(Larry) Zhu wrote: > Ok, I am happy with the examples. The text in the ID is terse, but > otherwise seems to be fine. Thanks. I'll wordsmith it. Of course, one might wonder if we don't need something else beyond domain-based service principal names, something like "instance-based" service principal names. The LDAP example, in particular, makes me wonder about that. Care to comment on whether we need "instance-based" service principal naming? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 06 00:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG82Q-0008TF-Ea; Mon, 06 Mar 2006 00:13:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG82P-0008TA-DL for kitten@ietf.org; Mon, 06 Mar 2006 00:13:41 -0500 Received: from [69.25.196.180] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG82M-0007Nd-69 for kitten@ietf.org; Mon, 06 Mar 2006 00:13:41 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EBC7D160059; Sun, 5 Mar 2006 21:13:18 -0500 (EST) To: kitten@ietf.org From: Sam Hartman Message-Id: <20060306021318.EBC7D160059@carter-zimmerman.mit.edu> Date: Sun, 5 Mar 2006 21:13:18 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: Request publication of draft-ietf-kitten-gss-naming-04.txt 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 Hi. I've submitted version 04 of my gss naming draft in order to address last call comments received from Martin Rex and reviews from Joe Salowey. I believe this document addresses the comments received. I wrote a long response proposing clarification of a few points. I never received any objections to that response from Martin and received support from Nico. The primary change I've made is added a section explicitly enumerating backward compatibility requirements. I solicit WG review of that section. Besides that, I believe the draft is ready to go to Russ, although that decision is up to Jeff Altman to make. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 06 17:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNzd-0006R9-BP; Mon, 06 Mar 2006 17:15:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNzc-0006PM-3k for kitten@ietf.org; Mon, 06 Mar 2006 17:15:52 -0500 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGNza-0002oD-Sj for kitten@ietf.org; Mon, 06 Mar 2006 17:15:52 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa22360; 6 Mar 2006 17:15 EST Date: Mon, 06 Mar 2006 17:15:21 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , "Liqiang(Larry) Zhu" Message-ID: In-Reply-To: <20060303190258.GM3676@binky.Central.Sun.COM> References: <20060303180735.GH3676@binky.Central.Sun.COM> <20060303190258.GM3676@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01OASz2aJsKE2ETytaa4LjSM926gS/OCyleeE+boQ=; 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: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org Subject: Re: WGLC for domain-based service principal names? 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 Friday, March 03, 2006 01:02:58 PM -0600 Nicolas Williams wrote: > On Fri, Mar 03, 2006 at 10:50:46AM -0800, Liqiang(Larry) Zhu wrote: >> Ok, I am happy with the examples. The text in the ID is terse, but >> otherwise seems to be fine. > > Thanks. I'll wordsmith it. > > Of course, one might wonder if we don't need something else beyond > domain-based service principal names, something like "instance-based" > service principal names. The LDAP example, in particular, makes me > wonder about that. > > Care to comment on whether we need "instance-based" service principal > naming? Maybe, but that's a different name type. For domain-based SPN's, you can use the traditional domain-to-realm mapping to choose a realm name. At the GSSAPI layer, this means you can pass in 'service@host@domain' or whatever it is, and the krb5 mech can determine the right realm, just as it does for host-based service names today. For an instance-based service name, with or without a separate hostname part, there is no way for a krb5 mechanism to choose a correct realm. More generally, for any service using a non-domain-based instance name, the application is going to have to define some independent way to figure out where the server is. It seems to me that instance-based service names at the GSSAPI level are of marginal use, if any. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 06 17:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO99-0000GX-3o; Mon, 06 Mar 2006 17:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGO97-0000GR-Rf for kitten@ietf.org; Mon, 06 Mar 2006 17:25:41 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGO95-0003VJ-CZ for kitten@ietf.org; Mon, 06 Mar 2006 17:25:41 -0500 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k26MPZuf028652 for ; Mon, 6 Mar 2006 15:25:38 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k26MPYUO022771 for ; Mon, 6 Mar 2006 15:25:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k26MPKOY006780; Mon, 6 Mar 2006 16:25:20 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k26MPHKJ006779; Mon, 6 Mar 2006 16:25:17 -0600 (CST) Date: Mon, 6 Mar 2006 16:25:17 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060306222517.GS6271@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , "Liqiang(Larry) Zhu" , kitten@ietf.org References: <20060303180735.GH3676@binky.Central.Sun.COM> <20060303190258.GM3676@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: WGLC for domain-based service principal names? 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 Mon, Mar 06, 2006 at 05:15:21PM -0500, Jeffrey Hutzelman wrote: > On Friday, March 03, 2006 01:02:58 PM -0600 Nicolas Williams > wrote: > >Care to comment on whether we need "instance-based" service principal > >naming? > > Maybe, but that's a different name type. Of course. > For domain-based SPN's, you can > use the traditional domain-to-realm mapping to choose a realm name. At the > GSSAPI layer, this means you can pass in 'service@host@domain' or whatever > it is, and the krb5 mech can determine the right realm, just as it does for > host-based service names today. For an instance-based service name, with > or without a separate hostname part, there is no way for a krb5 mechanism > to choose a correct realm. More generally, for any service using a > non-domain-based instance name, the application is going to have to define > some independent way to figure out where the server is. I think a host part would always be needed, and clients could determine the realm of the service from the realm of the host, but that's clearly not ideal. Excellent point. I'll leave the crossing of the instance-based service principal naming bridge for whoever comes to it. > It seems to me that instance-based service names at the GSSAPI level are of > marginal use, if any. Thanks. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 06 17:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOTP-0000C1-84; Mon, 06 Mar 2006 17:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOTO-0000Bw-Mp for kitten@ietf.org; Mon, 06 Mar 2006 17:46:38 -0500 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGOTO-0004jl-H3 for kitten@ietf.org; Mon, 06 Mar 2006 17:46:38 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa22386; 6 Mar 2006 17:46 EST Date: Mon, 06 Mar 2006 17:46:16 -0500 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <8A1540F0ED556C64FD43257C@sirius.fac.cs.cmu.edu> In-Reply-To: <20060306222517.GS6271@binky.Central.Sun.COM> References: <20060303180735.GH3676@binky.Central.Sun.COM> <20060303190258.GM3676@binky.Central.Sun.COM> <20060306222517.GS6271@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01Nnl746Dh8FeCxPNkaferUs3rsg69rfSj7qlIbPk=; 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: WGLC for domain-based service principal names? 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, March 06, 2006 04:25:17 PM -0600 Nicolas Williams wrote: > I think a host part would always be needed, and clients could determine > the realm of the service from the realm of the host, but that's clearly > not ideal. I don't think that helps at all, in fact. If you have a domain-based service name "service@host@domain", the realm _must_ be determined from the domain part, not the host part, because you don't know the host part authoritatively. If you have an instance-based name "service/instance", you have to somehow know the realm; domain-realm mapping doesn't help you. If you have an instance-based name with host "service/host/instance", you still have to know the realm; domain-realm mapping on the host doesn't help you because you don't know the host authoritatively. Now, I can see a few cases where instance-based krb5 principal names with hosts might be insteresting, but they are all cases where we currently use instance-based names without hosts, but would like not to have to manage a service key shared between hosts (because that's annoying). -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 06 18:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOj9-0008LT-63; Mon, 06 Mar 2006 18:02:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOj8-0008LE-3q for kitten@ietf.org; Mon, 06 Mar 2006 18:02:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGOj7-0005Z8-OZ for kitten@ietf.org; Mon, 06 Mar 2006 18:02:54 -0500 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k26N2rQj027777 for ; Mon, 6 Mar 2006 16:02:53 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k26N2qUO028684 for ; Mon, 6 Mar 2006 16:02:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k26N05wP006818; Mon, 6 Mar 2006 17:00:05 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k26N04Wh006817; Mon, 6 Mar 2006 17:00:04 -0600 (CST) Date: Mon, 6 Mar 2006 17:00:04 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060306230004.GW6271@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org, "Liqiang(Larry) Zhu" References: <20060303180735.GH3676@binky.Central.Sun.COM> <20060303190258.GM3676@binky.Central.Sun.COM> <20060306222517.GS6271@binky.Central.Sun.COM> <8A1540F0ED556C64FD43257C@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A1540F0ED556C64FD43257C@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, "Liqiang\(Larry\) Zhu" Subject: Re: WGLC for domain-based service principal names? 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 Mon, Mar 06, 2006 at 05:46:16PM -0500, Jeffrey Hutzelman wrote: > On Monday, March 06, 2006 04:25:17 PM -0600 Nicolas Williams > wrote: > >I think a host part would always be needed, and clients could determine > >the realm of the service from the realm of the host, but that's clearly > >not ideal. > > I don't think that helps at all, in fact. > > If you have a domain-based service name "service@host@domain", the realm > _must_ be determined from the domain part, not the host part, because you > don't know the host part authoritatively. Yes, which is what we decided to do with domain-based service principal naming. That wouldn't be possible for instance-based SPNs unless they were an extension of domain-based SPNs. Anyways, you've certainly convinced me that this is not something for KITTEN WG to tackle now :) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Mar 08 02:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQx-0005LU-6B; Wed, 08 Mar 2006 02:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0005A2-Mr; Wed, 08 Mar 2006 02:50:02 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGtQo-0001iR-6T; Wed, 08 Mar 2006 02:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k287o19W014772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGtQn-0001cp-UM; Wed, 08 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 02:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: kitten@lists.ietf.org Subject: I-D ACTION:draft-ietf-kitten-gss-naming-04.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : Desired Enhancements to GSSAPI Version 3 Naming Author(s) : S. Hartman Filename : draft-ietf-kitten-gss-naming-04.txt Pages : 16 Date : 2006-3-7 The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms such as public-key mechanisms do not have a single name to be used across all environments. Other mechanisms such as Kerberos may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-kitten-gss-naming-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kitten-gss-naming-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-7205533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kitten-gss-naming-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kitten-gss-naming-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-7205533.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart--