From kitten-bounces@lists.ietf.org Fri Aug 11 17:32:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBebp-0007nb-34; Fri, 11 Aug 2006 17:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBebn-0007jh-NW for kitten@lists.ietf.org; Fri, 11 Aug 2006 17:31:59 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBebm-0000s1-HL for kitten@lists.ietf.org; Fri, 11 Aug 2006 17:31:59 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7AA9232861; Fri, 11 Aug 2006 21:31:58 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GBebm-0002d7-Cq; Fri, 11 Aug 2006 17:31:58 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 11 Aug 2006 17:31:58 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@lists.ietf.org Subject: Last Call: 'Desired Enhancements to GSSAPI Version 3 Naming' to Informational RFC (draft-ietf-kitten-gss-naming) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org The IESG has received a request from the Kitten (GSS-API Next Generation) WG to consider the following document: - 'Desired Enhancements to GSSAPI Version 3 Naming ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04.txt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 14 16:05:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCigS-0001Wg-Lp; Mon, 14 Aug 2006 16:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCigR-0001WZ-H8 for kitten@lists.ietf.org; Mon, 14 Aug 2006 16:05:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCePL-000457-8s for kitten@lists.ietf.org; Mon, 14 Aug 2006 11:31:15 -0400 Received: from smtpsrv0.isis.unc.edu ([152.2.1.139] helo=smtp.unc.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GCduP-0006s9-VC for kitten@lists.ietf.org; Mon, 14 Aug 2006 10:59:22 -0400 Received: from [192.168.1.102] (cpe-024-088-245-078.nc.res.rr.com [24.88.245.78]) (authenticated bits=0) by smtp.unc.edu (8.13.4/8.13.4) with ESMTP id k7EEwwhr004481 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 14 Aug 2006 10:59:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.1) Content-Transfer-Encoding: 7bit Message-Id: <094106E8-F434-4073-A1F2-DF9A99289064@unc.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: kitten@lists.ietf.org From: Simon Spero Date: Mon, 14 Aug 2006 10:58:16 -0400 X-Mailer: Apple Mail (2.752.1) X-Scanned-By: ITS Messaging Systems (outgoing) on 152.2.1.139 X-Spam-Score: -2.0 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Status of gssapi domain based 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 What's the current status of the domain based names? I see Desired Enhancements* went to Last Call on Friday, but the DBN** drafts don't seem to have followed. Are the current drafts going out for Last Call as is? Thanks Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 14 16:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCin2-0004xl-Qu; Mon, 14 Aug 2006 16:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCin1-0004xb-K6 for kitten@lists.ietf.org; Mon, 14 Aug 2006 16:11:59 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCin0-0001z4-BB for kitten@lists.ietf.org; Mon, 14 Aug 2006 16:11:59 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000026761.msg for ; Mon, 14 Aug 2006 16:13:46 -0400 Message-ID: <44E0D978.3090903@secure-endpoints.com> Date: Mon, 14 Aug 2006 16:13:44 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Simon Spero References: <094106E8-F434-4073-A1F2-DF9A99289064@unc.edu> In-Reply-To: <094106E8-F434-4073-A1F2-DF9A99289064@unc.edu> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Mon, 14 Aug 2006 16:13:46 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@lists.ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: kitten@lists.ietf.org Subject: Re: Status of gssapi domain based 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="===============1668304313==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1668304313== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020807010100000703020209" This is a cryptographically signed message in MIME format. --------------ms020807010100000703020209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I will initiate a working group last call on these documents later today. Jeffrey Altman Simon Spero wrote: > What's the current status of the domain based names? > > I see Desired Enhancements* went to Last Call on Friday, but the DBN** > drafts don't seem to have followed. > > Are the current drafts going out for Last Call as is? > > Thanks > Simon > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten --------------ms020807010100000703020209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MTQyMDEzNDRaMCMGCSqGSIb3DQEJBDEWBBQYecv6 l85elaQqvhZrbESgo9ie6TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAWBXJrydFYhYysh/7H3DyA3QoL0PNm1SdyPCjm14JUPCTePTr2rOK Pf9lDqYM5AstIRBN8JC53Gr2Tg1mjM2ekFLQegJxs63pXBfst2JJ2MEn58iLV+wdVlaJtT0h af+3F/M2KbetaVCpOZofOJnBfWyMlyhrlG99/bT73++VeMb2OW99fPDEGXb9pLCxiN9f/Y1u r1XDHmRq5bg+prLvdnU2DPCu3NjBMBd7jxBFpeCDNTgpvH+GrCSpc0mM/LupddoTtFt3Gxt9 qulWNxIZKzDkFP7TlhgZAAWoCWhYmB/xtk/LpRWqGAJbA7Wmn3WwaX831mDyFKL7sg74/Zli tgAAAAAAAA== --------------ms020807010100000703020209-- --===============1668304313== 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 --===============1668304313==-- From kitten-bounces@lists.ietf.org Tue Aug 15 11:09:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD0XL-0007FS-MO; Tue, 15 Aug 2006 11:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD0XK-0007FK-L2; Tue, 15 Aug 2006 11:08:58 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD0XI-0001gm-98; Tue, 15 Aug 2006 11:08:58 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FF8tOt005362; Tue, 15 Aug 2006 09:08:55 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FF8tnF015937; Tue, 15 Aug 2006 09:08:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FF8t8S006102; Tue, 15 Aug 2006 10:08:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FF8s8V006101; Tue, 15 Aug 2006 10:08:54 -0500 (CDT) Date: Tue, 15 Aug 2006 10:08:54 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org Message-ID: <20060815150854.GM4099@binky.Central.Sun.COM> Mail-Followup-To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@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: 08e48e05374109708c00c6208b534009 Cc: Subject: draft-williams-on-channel-binding-00.txt is in the I-D repository 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 Folks, the replacement for draft-ietf-nfsv4-channel-bindings, draft-williams-on-channel-binding-00.txt, is now in the I-D repository. It has also been significantly expanded. Please review. I'd like to ask the security ADs for an IETF Last Call on this I-D soon. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 12:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD258-0004J6-Qn; Tue, 15 Aug 2006 12:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD257-0004Ix-Sk; Tue, 15 Aug 2006 12:47:57 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD256-0007qG-Ew; Tue, 15 Aug 2006 12:47:57 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7FGlZ35012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Aug 2006 18:47:36 +0200 From: Simon Josefsson To: ietf-sasl@imc.org References: <20060815150854.GM4099@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060815:kitten@ietf.org::j5mVpzD0l9CwuIj5:7kF X-Hashcash: 1:22:060815:nfsv4@ietf.org::+nGneS3q6rPkYuDN:0U19 X-Hashcash: 1:22:060815:ietf-sasl@imc.org::2XXieVIurLh6z0z0:BKcp Date: Tue, 15 Aug 2006 18:47:35 +0200 In-Reply-To: <20060815150854.GM4099@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 15 Aug 2006 10:08:54 -0500") Message-ID: <87ac663pzs.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, nfsv4@ietf.org Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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 Nicolas Williams writes: > Folks, the replacement for draft-ietf-nfsv4-channel-bindings, > draft-williams-on-channel-binding-00.txt, is now in the I-D repository. > > It has also been significantly expanded. Please review. I'd like to > ask the security ADs for an IETF Last Call on this I-D soon. Looks good in general. A general design question: What about SASL/GS2 over TLS over SSH over IPSEC? What is the channel bindings for that, is it only the TLS binding? Consider if the application regards the TLS layer as weak (export ciphers) but the SSH layer as strong, would it be permitted to use the SSH channel binding? This sounds to me like it may require negotiation in GS2. Some specific comments: Section 2.1: o The channel bindings for a given type of secure channel MUST be constructed in such a way that an MITM could not easily force the channel bindings of a given channel to match those of another. I'd change this to: o The channel bindings for a given type of secure channel MUST be constructed in such a way that an MITM cannot influence the channel bindings. This drops "easily", and makes the requirement a bit stronger; the MITM should not have any influence over the channel bindings. This: o Unique channel bindings MUST bind not only the key exchange for the secure channel, but also any negotiations and authentication that may have taken place to establish the channel. Sometimes negotiations/authentications are done by other protocols, or even out-of-band over the phone, and the intention was not to cover those things, right? I'm not sure how to phrase it better, though. /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 13:36:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2q5-00021c-UI; Tue, 15 Aug 2006 13:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2q5-00021S-37; Tue, 15 Aug 2006 13:36:29 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2q4-0001yT-1X; Tue, 15 Aug 2006 13:36:29 -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 k7FHaPxE012662; Tue, 15 Aug 2006 11:36:25 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FHaOwY019231; Tue, 15 Aug 2006 11:36:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FHaOr2006263; Tue, 15 Aug 2006 12:36:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FHaNad006262; Tue, 15 Aug 2006 12:36:23 -0500 (CDT) Date: Tue, 15 Aug 2006 12:36:23 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060815173622.GQ4099@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ac663pzs.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: kitten@ietf.org, ietf-sasl@imc.org, nfsv4@ietf.org Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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, Aug 15, 2006 at 06:47:35PM +0200, Simon Josefsson wrote: > Looks good in general. A general design question: Thanks for your comments! > What about SASL/GS2 over TLS over SSH over IPSEC? What is the channel > bindings for that, is it only the TLS binding? Consider if the > application regards the TLS layer as weak (export ciphers) but the SSH > layer as strong, would it be permitted to use the SSH channel binding? > This sounds to me like it may require negotiation in GS2. How might you end up with such a complex stack? Are you thinking of port-forwarding LDAP/IMAP over SSHv2? It seems to me that the right thing would be to bind each channel to the one below, so here the SSHv2 channel would be bound to the IPsec channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the TLS channel, and the only channel that would provide cryptographic session protection would be IPsec. This seems fairly unrealistic though -- aside from port-forwarding I've a hard time imagining how one would end up with such a complex stack. And with port-forwarding the channel binding to SSHv2 would require that the TLS peers know about the SSHv2 channel and its session ID, at which point one might dispense with TLS altogether and just use SASL/GS2 with channel binding to SSHv2 (even the SSHv2 channel is not end2end, unless you want end2end protection, in which case there'd be no need for channel binding of TLS to the SSHv2 channel). Also, we'd have to explain how to bind TLS and SSHv2 to other channels... Consider the examples given so far: - NFSv4, iSCSI, other similar protocols, with channel binding to IPsec - Extended HTTP authentication with channel binding to TLS and the reasons for these examples: - app-layer authentication fits better (NFSv4, HTTP) - app-layer has to be in cleartext relative to a lower layer (NFSv4, iSCSI [iSER]) - better HW support for cryptographic protocols lower in the stack (all) SSHv2 applications don't have the problems that NFSv4 has: they neither multiplex multiple users on one connection, lack applicable user authentication methods, or have the RDDP problem. So channel binding SSHv2 to a lower layer session makes sense only for HW crypto acceleration -- though that alone does make a lot of sense. > Some specific comments: > > Section 2.1: > > o The channel bindings for a given type of secure channel MUST be > constructed in such a way that an MITM could not easily force the > channel bindings of a given channel to match those of another. > > I'd change this to: > > o The channel bindings for a given type of secure channel MUST be > constructed in such a way that an MITM cannot influence the > channel bindings. Why? The crucial requirement is the one I give. > This drops "easily", and makes the requirement a bit stronger; the > MITM should not have any influence over the channel bindings. But the MITM does have some influence over the channel bindings, just not necessarily control over them :) IOW, I think you need to pick a better word than 'influence', and, anyways, I think the stated requirement is sufficiently strong. > This: > > o Unique channel bindings MUST bind not only the key exchange for > the secure channel, but also any negotiations and authentication > that may have taken place to establish the channel. > > Sometimes negotiations/authentications are done by other protocols, or > even out-of-band over the phone, and the intention was not to cover > those things, right? I'm not sure how to phrase it better, though. Well, I don't want to be specific about in-band vs. out of band negotiation. Consider the IPsec case, where we bind to the "identities" (valid cert names, public keys, ...) bound into the KE[*] exchanges that spawn the SAs that protect a given connection's traffic. Here there's not a single negotiation/key exchange/authentication step, but potentially many, nor do we bind to "in-band" ESP/AH things but to KE-specific ones. As for "out-of-band over the phone" -- sorry, but manual protocols are out of scope. The intention is to cover: SSHv2, TLS, IPsec and protocols that have similar design patterns. However, I'd like the text to be generic, and I think this text mostly captures the intended requirement generically. Perhaps we should replace "exchange" with "exchange(s)" to reflect the potential, in the IPsec channel construction case, for having more than one exchange. And it should be clear that the binding can be quite indirect, as it would be in the IPsec case. So: o Unique channel bindings MUST bind not only the key exchange(s) for the secure channel, but also any negotiations and authentication that may have taken place to establish the channel. The binding MAY be indirect, as in the case of end-point channel bindings, where the channel bindings consist of end-point "names" that are strongly bound, through authentication, to the key exchange and negotiation. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 14:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD40J-0000hX-79; Tue, 15 Aug 2006 14:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD40I-0000hM-4D; Tue, 15 Aug 2006 14:51:06 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD40H-0006jO-CP; Tue, 15 Aug 2006 14:51:06 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7FIofex024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Aug 2006 20:50:48 +0200 From: Simon Josefsson To: ietf-sasl@imc.org References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060815:kitten@ietf.org::ikYC78l2wJQZfVh1:8nYv X-Hashcash: 1:22:060815:ietf-sasl@imc.org::jMdudkCSLQL9LNmQ:N6Wi X-Hashcash: 1:22:060815:nfsv4@ietf.org::C9nK9Bfzh76hIjDY:eDn9 Date: Tue, 15 Aug 2006 20:50:41 +0200 In-Reply-To: <20060815173622.GQ4099@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 15 Aug 2006 12:36:23 -0500") Message-ID: <87wt993kam.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: kitten@ietf.org, nfsv4@ietf.org Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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 Nicolas Williams writes: >> What about SASL/GS2 over TLS over SSH over IPSEC? What is the channel >> bindings for that, is it only the TLS binding? Consider if the >> application regards the TLS layer as weak (export ciphers) but the SSH >> layer as strong, would it be permitted to use the SSH channel binding? >> This sounds to me like it may require negotiation in GS2. > > How might you end up with such a complex stack? Are you thinking of > port-forwarding LDAP/IMAP over SSHv2? I'm using IMAP with SASL over TLS over port-forwarded SSH to read my mail every day, and I imagine this (TLS over VPN) isn't too uncommon. Adding IPSEC doesn't seem entirely far fetched, especially if usability of IPSEC improves. > It seems to me that the right thing would be to bind each channel to the > one below, so here the SSHv2 channel would be bound to the IPsec > channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the > TLS channel, and the only channel that would provide cryptographic > session protection would be IPsec. Sounds OK to me, but I'm not sure it is the only solution. > This seems fairly unrealistic though -- aside from port-forwarding I've > a hard time imagining how one would end up with such a complex stack. I'm thinking of port-forwarding. > And with port-forwarding the channel binding to SSHv2 would require that > the TLS peers know about the SSHv2 channel and its session ID, at which > point one might dispense with TLS altogether and just use SASL/GS2 with > channel binding to SSHv2 Implementing all this seems complex. Applications or TLS libraries typically have no idea that it is running over SSH port-forwarding. And SSH implementation usually have no idea that is running over IPSEC. And... > Also, we'd have to explain how to bind TLS and SSHv2 to other channels... ...that seem to require some additional specification work. >> Some specific comments: >> >> Section 2.1: >> >> o The channel bindings for a given type of secure channel MUST be >> constructed in such a way that an MITM could not easily force the >> channel bindings of a given channel to match those of another. >> >> I'd change this to: >> >> o The channel bindings for a given type of secure channel MUST be >> constructed in such a way that an MITM cannot influence the >> channel bindings. > > Why? The crucial requirement is the one I give. > >> This drops "easily", and makes the requirement a bit stronger; the >> MITM should not have any influence over the channel bindings. > > But the MITM does have some influence over the channel bindings, just > not necessarily control over them :) > > IOW, I think you need to pick a better word than 'influence', and, > anyways, I think the stated requirement is sufficiently strong. Thinking more about this, I'd be happy if the "easily" is dropped from your paragraph. If it is only "difficult" (in contrast to "computationally infeasible") to force two channel bindings to be the same, I don't think it is good enough. >> This: >> >> o Unique channel bindings MUST bind not only the key exchange for >> the secure channel, but also any negotiations and authentication >> that may have taken place to establish the channel. >> >> Sometimes negotiations/authentications are done by other protocols, or >> even out-of-band over the phone, and the intention was not to cover >> those things, right? I'm not sure how to phrase it better, though. > > Well, I don't want to be specific about in-band vs. out of band > negotiation. Consider the IPsec case, where we bind to the "identities" > (valid cert names, public keys, ...) bound into the KE[*] exchanges that > spawn the SAs that protect a given connection's traffic. Here there's > not a single negotiation/key exchange/authentication step, but > potentially many, nor do we bind to "in-band" ESP/AH things but to > KE-specific ones. > > As for "out-of-band over the phone" -- sorry, but manual protocols are > out of scope. The intention is to cover: SSHv2, TLS, IPsec and > protocols that have similar design patterns. However, I'd like the text > to be generic, and I think this text mostly captures the intended > requirement generically. SSH host keys are usually verified out of band, if I'm not mistaken. I think authentication of (the source to) keying material in TLS-PSK and TLS-OpenPGP also happens out of band. I understand that the intention isn't to cover those kind of negotiations/authentications, but I'm not sure the text captures this. I don't know what the exact property we are looking for here (in-band vs out-of-band doesn't seem to be it). > Perhaps we should replace "exchange" with "exchange(s)" to reflect the > potential, in the IPsec channel construction case, for having more than > one exchange. And it should be clear that the binding can be quite > indirect, as it would be in the IPsec case. > > So: > > o Unique channel bindings MUST bind not only the key exchange(s) for > the secure channel, but also any negotiations and authentication > that may have taken place to establish the channel. > > The binding MAY be indirect, as in the case of end-point channel > bindings, where the channel bindings consist of end-point "names" > that are strongly bound, through authentication, to the key > exchange and negotiation. Ok. Anyway, the only real concern I have is the GS2-over-TLS-over-SSH-over-IPSEC situation, otherwise I think the document is ready. I'm not sure it should move forward until at least the TLS channel bindings document is close to done too, though. /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 15:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4a7-0003XE-Pf; Tue, 15 Aug 2006 15:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4a7-0003X6-7Z; Tue, 15 Aug 2006 15:28:07 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4a2-00011F-3K; Tue, 15 Aug 2006 15:28:07 -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 k7FJS1ea019028; Tue, 15 Aug 2006 13:28:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FJS0VQ009089; Tue, 15 Aug 2006 13:28:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FJS0I4006299; Tue, 15 Aug 2006 14:28:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FJS0kR006298; Tue, 15 Aug 2006 14:28:00 -0500 (CDT) Date: Tue, 15 Aug 2006 14:28:00 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060815192759.GR4099@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wt993kam.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: kitten@ietf.org, ietf-sasl@imc.org, nfsv4@ietf.org Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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, Aug 15, 2006 at 08:50:41PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > [...] > I'm using IMAP with SASL over TLS over port-forwarded SSH to read my > mail every day, and I imagine this (TLS over VPN) isn't too uncommon. > Adding IPSEC doesn't seem entirely far fetched, especially if > usability of IPSEC improves. VPNs aren't "channels" as far as this spec goes. They're not end2end (nor hop-by-hop proxy systems, like HTTP). > > It seems to me that the right thing would be to bind each channel to the > > one below, so here the SSHv2 channel would be bound to the IPsec > > channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the > > TLS channel, and the only channel that would provide cryptographic > > session protection would be IPsec. > > Sounds OK to me, but I'm not sure it is the only solution. I think it's the simplest, if indeed this is what you want and if the SSHv2 session ID can be obtained by both, the IMAP client and the IMAP server. As it is you called it a VPN, which, IMO, rules channel binding out. > > And with port-forwarding the channel binding to SSHv2 would require that > > the TLS peers know about the SSHv2 channel and its session ID, at which > > point one might dispense with TLS altogether and just use SASL/GS2 with > > channel binding to SSHv2 > > Implementing all this seems complex. Applications or TLS libraries > typically have no idea that it is running over SSH port-forwarding. You'd have to make them aware of what's below. That's one of the problems with channel binding to IPsec: the lack of a) IPsec channels, b) IPsec APIs relevant to IPsec channels. Yes, channel binding requires new interfaces. You've discovered this already in the context of TLS. But it's a generic requirement: any channel you might want to bind to has to export its channel bindings, a minimum of information about what security services it provides, and maybe even more (see security considerations text about cryptographic profiles). > > Also, we'd have to explain how to bind TLS and SSHv2 to other channels... > > ...that seem to require some additional specification work. But noone is asking for that. I'll wait for you to digest my comment about VPNs before counting you as wanting TLS/SSHv2 channel binding. > >> Some specific comments: > [...] > Thinking more about this, I'd be happy if the "easily" is dropped from > your paragraph. If it is only "difficult" (in contrast to > "computationally infeasible") to force two channel bindings to be the > same, I don't think it is good enough. Sure. > [...] > > SSH host keys are usually verified out of band, if I'm not mistaken. Irrelevant for either of the two types of channel bindings described in the draft: a) because an MITM can't obtain the private key to a server's host public key and this public key is worked into the session ID computation, b) because SSHv2 uses ephemeral-ephemeral Diffie-Hellman for key exchange and the result of the initial key exchange too is worked into the session ID computation. So whether you're using an SSHv2 host public key or an SSHv2 session ID as a channel binding an MITM cannot make this binding agree for both, its connection to the client and its connection to the server. > I think authentication of (the source to) keying material in TLS-PSK > and TLS-OpenPGP also happens out of band. Irrelevant, for similar reasons. > Anyway, the only real concern I have is the > GS2-over-TLS-over-SSH-over-IPSEC situation, otherwise I think the > document is ready. I'm not sure it should move forward until at least > the TLS channel bindings document is close to done too, though. Maybe, but I want additional reviews, not least Sam's. Thanks! Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 15:46:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4rj-00014R-3c; Tue, 15 Aug 2006 15:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4ri-00014J-GY; Tue, 15 Aug 2006 15:46:18 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4rh-00045x-5C; Tue, 15 Aug 2006 15:46:18 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FJkG76000049; Tue, 15 Aug 2006 13:46:16 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FJkGDU016769; Tue, 15 Aug 2006 13:46:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FJkGWC006351; Tue, 15 Aug 2006 14:46:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FJkF1Y006350; Tue, 15 Aug 2006 14:46:15 -0500 (CDT) Date: Tue, 15 Aug 2006 14:46:15 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org Message-ID: <20060815194615.GT4099@binky.Central.Sun.COM> Mail-Followup-To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org References: <20060815150854.GM4099@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060815150854.GM4099@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: Re: [nfsv4] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-sasl@imc.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org What mailing list would be approapriate to host reviews of this draft? NFSv4's does not seem apropriate, but then, neither do the other two (SASL, KITTEN). Perhaps SASL, because we've been discussing channel binding issues in the context of SASL/GS2 there. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 18:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD7fg-0008Dr-OO; Tue, 15 Aug 2006 18:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD7ff-0008Dj-Ju; Tue, 15 Aug 2006 18:46:03 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD7fZ-0000Ed-3a; Tue, 15 Aug 2006 18:46:03 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FMjtit028908; Tue, 15 Aug 2006 15:45:56 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FMjsXg001146; Tue, 15 Aug 2006 16:45:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FMjsP8006840; Tue, 15 Aug 2006 17:45:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FMjsO0006839; Tue, 15 Aug 2006 17:45:54 -0500 (CDT) Date: Tue, 15 Aug 2006 17:45:54 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org Message-ID: <20060815224553.GD4099@binky.Central.Sun.COM> Mail-Followup-To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org, saag@mit.edu References: <20060815150854.GM4099@binky.Central.Sun.COM> <20060815194615.GT4099@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060815194615.GT4099@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: saag@mit.edu Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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, Aug 15, 2006 at 02:46:15PM -0500, Nicolas Williams wrote: > What mailing list would be approapriate to host reviews of this draft? > > NFSv4's does not seem apropriate, but then, neither do the other two > (SASL, KITTEN). Perhaps SASL, because we've been discussing channel > binding issues in the context of SASL/GS2 there. Sam suggests the SAAG list (duh!). Reply-to set. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 15 22:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBGD-00015O-8v; Tue, 15 Aug 2006 22:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBGB-000112-6s for kitten@ietf.org; Tue, 15 Aug 2006 22:35:59 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBG9-0008MT-TW for kitten@ietf.org; Tue, 15 Aug 2006 22:35:59 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000026944.msg for ; Tue, 15 Aug 2006 22:37:49 -0400 Message-ID: <44E28500.1000605@secure-endpoints.com> Date: Tue, 15 Aug 2006 22:37:52 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Tue, 15 Aug 2006 22:37:49 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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="===============0126030007==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0126030007== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010800050204020604060409" This is a cryptographically signed message in MIME format. --------------ms010800050204020604060409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten Chair has received a request to submit "GSS-API Domain-Based Service Names and Name Type" to the IESG for publication as a Proposed Standard. Abstract This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) instead of or in addition to a hostname. The primary purpose of domain-based service names is to provide a way to name clustered services after the domain which they service, thereby allowing their clients to authorize the service's servers based on authentication of their names. A two week Working Group Last Call is being initiated to determine if this document is ready for publication. Positive acknowledgment of document review and feedback is requested. The working group last call will terminate at 00:00 EDT 30 August 2006. --------------ms010800050204020604060409 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MTYwMjM3NTJaMCMGCSqGSIb3DQEJBDEWBBTzpClo iSxu89txoHzmQ3SklXG+0DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAqaI85QdOqktZSo6tRlYGyVaUNkLAcStiiaWRgRgcli4o85dipPxs 2g51FN0mxzHUPOQPAcyH9CJYJPOGysNDxyLwtZucp8mUVP6c7v1vjjtn27kuHapof9jWCaIC FoCP7X9/ZaM3i7GhXobOVMky5W3d5DAFmpbAVNZybMd8RPK3u/F/nb69GxCqDUsTTo3Zh/hC rPVNRBXp1I9YbdU/OAIGLofs5nXu5ZcsuaE/CwJuzKGzwtuTsH8YvIKGFthc9ysTY8BFFTuU QDkhV5TD7AggE4W7jbhF1rlMwfJmcwpH9beQKhyG1F0tM7KP9DuHxsLhKwk/qLV7esJZtWBw 9gAAAAAAAA== --------------ms010800050204020604060409-- --===============0126030007== 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 --===============0126030007==-- From kitten-bounces@lists.ietf.org Tue Aug 15 22:38:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBJ3-0001n5-3t; Tue, 15 Aug 2006 22:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDBJ2-0001n0-Ov for kitten@ietf.org; Tue, 15 Aug 2006 22:38:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDBJ0-0008Rg-H7 for kitten@ietf.org; Tue, 15 Aug 2006 22:38:56 -0400 Received: from [192.168.1.13] (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.7/8.13.6) with ESMTP id k7G2cpmd007399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Aug 2006 22:38:51 -0400 (EDT) Message-ID: <44E285B1.1000402@secure-endpoints.com> Date: Tue, 15 Aug 2006 22:40:49 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Kitten , Kerberos WG 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: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: Working Group Last Call: GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism 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="===============1251806309==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1251806309== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000300080207070704010402" This is a cryptographically signed message in MIME format. --------------ms000300080207070704010402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten Chair has received a request to submit "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism" to the IESG for publication as a Proposed Standard. Abstract This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. A two week Working Group Last Call is being initiated in both the Kitten and Kerberos Working Groups to determine if this document is ready for publication. Positive acknowledgment of document review and feedback is requested. The working group last call will terminate at 00:00 EDT 30 August 2006. --------------ms000300080207070704010402 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MTYwMjQwNDlaMCMGCSqGSIb3DQEJBDEWBBSSVU4g 6ZdQwMtPWT1Mb2LpfjG4UDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAB6tXq5v1FYclS+1+3y6KpZTXFrHAfbWuT6W+LnP1cdYsfozIm4/5 nE0FN0K7KcsVpcpod0W3yGyDYYD7z8YPabqS+UomMVMg3bKWpXCyuiyqwh1QrTlzL+QDaiLW rhbs+66Y0fACbh5UBP887m1eFxlGhHG4ciCA3k13sC6JUUCY/YRHLgcRLxa1kZqKppkkQs39 eJZuyqdL9nHz3G2lkqHfmz20Ex8nYc+0NESZEHDi8NBGYDGwjsR45yzfzFPjprT5YJB3SjZj uamRxZXqJInsxzqLcEPLVDmnNUX06QNexk7guaQlLQFdSdkGafhgWGsaH6lobv3glwLrqJzd gwAAAAAAAA== --------------ms000300080207070704010402-- --===============1251806309== 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 --===============1251806309==-- From kitten-bounces@lists.ietf.org Wed Aug 16 12:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOX4-0003ee-Hh; Wed, 16 Aug 2006 12:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDOX3-0003eY-00 for kitten@ietf.org; Wed, 16 Aug 2006 12:46:17 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDOX0-0002xG-M1 for kitten@ietf.org; Wed, 16 Aug 2006 12:46:16 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7GGkDV8011567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 12:46:13 -0400 (EDT) Date: Wed, 16 Aug 2006 12:46:13 -0400 From: Jeffrey Hutzelman To: Kitten , Kerberos WG Message-ID: <77BC4C8941693E58737A3518@sirius.fac.cs.cmu.edu> In-Reply-To: <44E285B1.1000402@secure-endpoints.com> References: <44E285B1.1000402@secure-endpoints.com> Originator-Info: login-token=Mulberry:01KWac8ZPOEWV1sRRyXOTMYMDY0xywmhWW28pWX+Y=; 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: 97adf591118a232206bdb5a27b217034 Cc: Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism 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 Tuesday, August 15, 2006 10:40:49 PM -0400 Jeffrey Altman wrote: > The Kitten Chair has received a request to submit "GSS-API Domain-Based > Service Names Mapping for the Kerberos V GSS Mechanism" > -based-names-02.txt> to the IESG for publication as a Proposed Standard. > > Abstract > > This document describes the mapping of GSS-API domainname-based > service principal names onto Kerberos V principal names. > > A two week Working Group Last Call is being initiated in both the Kitten > and Kerberos Working Groups to determine if this document is ready for > publication. Positive acknowledgment of document review and feedback > is requested. > > The working group last call will terminate at 00:00 EDT 30 August 2006. Note that this document describes a new Kerberos principal name type, in addition to those listed in section 7.5.8 of RFC4120. Per that document, allocation of new values in this space currently requires consensus of the Kerberos working group. Given past discussions on this topic, I will consider an absence of any objections prior to the end of the last call period to indicate consensus to allocate such a value. -- Jeffrey T. Hutzelman (N3NHS) Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 18 10:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5GP-0001rd-SE; Fri, 18 Aug 2006 10:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE5GO-0001rR-Fv; Fri, 18 Aug 2006 10:23:56 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE5GN-0001W0-7u; Fri, 18 Aug 2006 10:23:56 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7D420E00C0; Fri, 18 Aug 2006 10:23:57 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> Date: Fri, 18 Aug 2006 10:23:57 -0400 In-Reply-To: <87ac663pzs.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 15 Aug 2006 18:47:35 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org, ietf-sasl@imc.org, nfsv4@ietf.org Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository 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 >>>>> "Simon" == Simon Josefsson writes: Simon> Nicolas Williams writes: >> Folks, the replacement for draft-ietf-nfsv4-channel-bindings, >> draft-williams-on-channel-binding-00.txt, is now in the I-D >> repository. >> >> It has also been significantly expanded. Please review. I'd >> like to ask the security ADs for an IETF Last Call on this I-D >> soon. Simon> Looks good in general. A general design question: Simon> What about SASL/GS2 over TLS over SSH over IPSEC? What is Simon> the channel bindings for that, is it only the TLS binding? Simon> Consider if the application regards the TLS layer as weak Simon> (export ciphers) but the SSH layer as strong, would it be Simon> permitted to use the SSH channel binding? This sounds to Simon> me like it may require negotiation in GS2. That's the application's problem to decide. I definitely do not think we want every mechanism that supports binding to a channel to need negotiation for this. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 21 18:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHr4-0007n8-RL; Mon, 21 Aug 2006 18:02:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHr4-0007mm-Fa for kitten@ietf.org; Mon, 21 Aug 2006 18:02:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHr4-0002if-E6 for kitten@ietf.org; Mon, 21 Aug 2006 18:02:46 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFHqI-00040K-8K for kitten@ietf.org; Mon, 21 Aug 2006 18:02:01 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D525EE00F2; Mon, 21 Aug 2006 15:14:07 -0400 (EDT) From: Sam Hartman To: Kitten References: <44E28500.1000605@secure-endpoints.com> Date: Mon, 21 Aug 2006 15:14:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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'm a bit concerned that we have not actually thought through how to apply domain based names to any actual application technology. In particular, it looks like all the naming rules for the gssapi mechanism in SASL would have to change in order to use domain based names with SASL. Have we actually thought this through enough that we believe we can write documents describing how to use domain based names without ending up changing details in the domain based name spec? I would feel a lot more comfortable approving this document if it were accompanied by something that actually used domain based names. Absent that, I'd like to see discussion here that shows we've thought through the transition issues. While reviewing the document, I noticed the following: Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased principal with a service name of "ldap", a reasonable approach, provided there is only one logical LDAP directory in a Kerberos realm's domain, and that all ldap servers in that realm serve that one LDAP directory. How does LDAP assume there is one LDAP instance for a given domain? If I have two independent LDAP servers they will have different host principals. I think you only run into problems with SRV records. This needs to be spelled out much more clearly. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 21 18:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIAC-0006PG-Bo; Mon, 21 Aug 2006 18:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFIAB-0006PB-Lw for kitten@ietf.org; Mon, 21 Aug 2006 18:22:31 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFIA8-00061J-5L for kitten@ietf.org; Mon, 21 Aug 2006 18:22:31 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7LMMRcB025782 for ; Mon, 21 Aug 2006 15:22:27 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7LMIFR5023452 for ; Mon, 21 Aug 2006 16:18:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7LMMQsc013246; Mon, 21 Aug 2006 17:22:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7LMMQpI013245; Mon, 21 Aug 2006 17:22:26 -0500 (CDT) Date: Mon, 21 Aug 2006 17:22:26 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060821222225.GI10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten References: <44E28500.1000605@secure-endpoints.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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Kitten Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 21, 2006 at 03:14:07PM -0400, Sam Hartman wrote: > Hi. > > I'm a bit concerned that we have not actually thought through how to > apply domain based names to any actual application technology. Me too. I'm concerned that merely adding a domain component doesn't tell one enough about the purpose of the given service. I could see two LDAP services for a given domain that are distinguished not by the domain they serve (they serve the same domain) but by the schema they use. I'm not sure how to handle this, or whether we want to handle this. See the thread we had on instance naming. > In particular, it looks like all the naming rules for the gssapi > mechanism in SASL would have to change in order to use domain based > names with SASL. The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) mention GSS-API name types, or one name type anyways, GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict API, so I'm not sure that SASL/GS1 constrains us here, or requires updating to truly be able to use the domain-based name type. > Have we actually thought this through enough that we believe we can > write documents describing how to use domain based names without > ending up changing details in the domain based name spec? I have two use cases, and the draft describes them. I think we do know how to use domain-based names, and, IIRC, Microsoft already does. > I would feel a lot more comfortable approving this document if it were > accompanied by something that actually used domain based names. > Absent that, I'd like to see discussion here that shows we've thought > through the transition issues. I believe we've had this discussion, and the draft does discuss applications, though not normatively. If you'd like we could hold up publication of these documents until a document describing, say, the NFSv4 root server location facility (which would use domain-based service names to authenticate NFSv4 domain root servers differently from normal NFSv4 servers) is ready for concurrent publication. > While reviewing the document, I noticed the following: > > > Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V > mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased > principal with a service name of "ldap", a reasonable approach, > provided there is only one logical LDAP directory in a Kerberos > realm's domain, and that all ldap servers in that realm serve that > one LDAP directory. > > How does LDAP assume there is one LDAP instance for a given domain? > If I have two independent LDAP servers they will have different host > principals. > > I think you only run into problems with SRV records. This needs to be > spelled out much more clearly. Yes, I'd intended to mention DNS SRV RRs there. Thanks for catching this. Assuming we add text there about DNS SRV RRs, does your concern go away? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 21 22:13:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFLlO-0006nS-Il; Mon, 21 Aug 2006 22:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFLlN-0006nD-5Q for kitten@ietf.org; Mon, 21 Aug 2006 22:13:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFJKv-0004W1-DF for kitten@ietf.org; Mon, 21 Aug 2006 19:37:41 -0400 Received: from stratton-two-sixty-six.mit.edu ([18.187.6.11] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFJ7g-0006iX-3H for kitten@ietf.org; Mon, 21 Aug 2006 19:24:00 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 41609E00C0; Mon, 21 Aug 2006 19:24:08 -0400 (EDT) From: Sam Hartman To: Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> Date: Mon, 21 Aug 2006 19:24:07 -0400 In-Reply-To: <20060821222225.GI10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 21 Aug 2006 17:22:26 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Aug 21, 2006 at 03:14:07PM -0400, Sam Hartman Nicolas> wrote: >> Hi. >> >> I'm a bit concerned that we have not actually thought through >> how to apply domain based names to any actual application >> technology. Nicolas> Me too. I'm concerned that merely adding a domain Nicolas> component doesn't tell one enough about the purpose of Nicolas> the given service. I could see two LDAP services for a Nicolas> given domain that are distinguished not by the domain Nicolas> they serve (they serve the same domain) but by the schema Nicolas> they use. I'm not sure how to handle this, or whether we Nicolas> want to handle this. See the thread we had on instance Nicolas> naming. You seem to be assuming that the domain in a domain based names has anything to do with the realm. I assume it had to do with the string used for srv record lookups. Why would you have two different ldap schemas in the same srv record rotation? >> In particular, it looks like all the naming rules for the >> gssapi mechanism in SASL would have to change in order to use >> domain based names with SASL. Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) Nicolas> mention GSS-API name types, or one name type anyways, Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or Nicolas> requires updating It is my reading of gs1 that it normatively requires hostbased names. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 11:52:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYY5-00034u-Kp; Tue, 22 Aug 2006 11:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYY3-00032Y-UK for kitten@ietf.org; Tue, 22 Aug 2006 11:52:15 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYY0-0008PV-Hx for kitten@ietf.org; Tue, 22 Aug 2006 11:52:15 -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 k7MFq81s008989 for ; Tue, 22 Aug 2006 09:52:12 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MFq7uH012360 for ; Tue, 22 Aug 2006 09:52:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MFq7tR013732; Tue, 22 Aug 2006 10:52:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MFq7iR013731; Tue, 22 Aug 2006 10:52:07 -0500 (CDT) Date: Tue, 22 Aug 2006 10:52:07 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060822155201.GX10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@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 Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 21, 2006 at 07:24:07PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > You seem to be assuming that the domain in a domain based names has > anything to do with the realm. I assume it had to do with the string > used for srv record lookups. Why would you have two different ldap > schemas in the same srv record rotation? Right, thank you -- you've just made my instance naming concern go away. Perhaps I should add some text specifically describing application use of domain-based names in conjunction with DNS SRV RR lookups. > Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) > Nicolas> mention GSS-API name types, or one name type anyways, > Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict > Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or > Nicolas> requires updating > It is my reading of gs1 that it normatively requires hostbased names. That it does, but to the exclusion of all others? That I'm not sure of; RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor names." Perhaps that was an oversight and we should read it as normatively requiring use of hostbased service principal names for acceptors. If we do this then, then would we be able to update GS1? Should we hold this discussion on the SASL list? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 13:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZzD-0002ZM-Po; Tue, 22 Aug 2006 13:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZzC-0002ZH-O2 for kitten@ietf.org; Tue, 22 Aug 2006 13:24:22 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZzB-0006jX-6Q for kitten@ietf.org; Tue, 22 Aug 2006 13:24:22 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MHOKAi007894 for ; Tue, 22 Aug 2006 10:24:20 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MHOJ64024663 for ; Tue, 22 Aug 2006 11:24:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MHOJ2b013778; Tue, 22 Aug 2006 12:24:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MHOJlB013777; Tue, 22 Aug 2006 12:24:19 -0500 (CDT) Date: Tue, 22 Aug 2006 12:24:19 -0500 From: Nicolas Williams To: Sam Hartman , Kitten Message-ID: <20060822172418.GD10458@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822155201.GX10208@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Sam> It is my reading of gs1 that it normatively requires hostbased names. Sam thinks GS1 excludes use of other name types for acceptors. I think so too, but I'm not sure that GS1/GS2 need updating as much as applications do -- certainly applications that wish to use domain-based names will need updating. I don't read GS1 to prohibit use of other name types but as providing a required name type when a priori knowledge of server support for other name types is not available. Clients and servers wishing to use name types other than hostbased service clearly have to agree a priori and SASL/GS1 implementations have to make it possible (which they might not); there is no negotiation mechanism.. Applications will require updates to use domain-based names. GS1 can be said to be a GSS-API application, thus it would need an update, but SASL/GS1 applications will need updates also, which brings us to: why bother updating GS1 for this then? I think the answer would be "so that SASL/GS1 implementors could know to design their APIs accordingly." Again, the applications we have in mind: LDAP server discovery through DNS SRV RRs, and NFSv4 root server discovery through DNS SRV RRs. If there's any way to insert text into draft-ietf-sasl-gssapi about this then I would opt for that, though it should not mention domain-based name types specifically. Similarly for GS2. Something like: 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. Applications should specify what alternate name types may be used and in what circumstances. > Should we hold this discussion on the SASL list? I'll assume yes. Cross-posting. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 13:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFa5f-0004XC-Tk; Tue, 22 Aug 2006 13:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFa5e-0004X7-GI for kitten@ietf.org; Tue, 22 Aug 2006 13:31:02 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFa5d-000808-1L for kitten@ietf.org; Tue, 22 Aug 2006 13:31:02 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MHV0Rj000421 for ; Tue, 22 Aug 2006 11:31:00 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MHV0se027570 for ; Tue, 22 Aug 2006 11:31:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MHV06K013789; Tue, 22 Aug 2006 12:31:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MHV0A5013788; Tue, 22 Aug 2006 12:31:00 -0500 (CDT) Date: Tue, 22 Aug 2006 12:31:00 -0500 From: Nicolas Williams To: Sam Hartman , Kitten Message-ID: <20060822173059.GY10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822172418.GD10458@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 22, 2006 at 12:24:19PM -0500, Nicolas Williams wrote: > Clients and servers wishing to use name > types other than hostbased service clearly have to agree a priori and > SASL/GS1 implementations have to make it possible (which they might > not); there is no negotiation mechanism.. Well, there will have to be negotiation mechanisms, but these will have to be application-specific. For NFSv4 the mere existence of the relevant SRV RRs should indicate that the given NFSv4 servers support domain-based names. For applications where existing clients already SRV RRs the apps may need to specify a new front label for the SRV RR lookup such that presence of the RRs for the new names indicates support for domain-based names. Yes, I think the domain-based name type I-D should have additional text about this. I will post a proposal later today. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 13:46:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFaKl-0002IE-KI; Tue, 22 Aug 2006 13:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFaKk-0002I8-LA for kitten@ietf.org; Tue, 22 Aug 2006 13:46:38 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFaKi-0002VK-2O for kitten@ietf.org; Tue, 22 Aug 2006 13:46:38 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000027615.msg for ; Tue, 22 Aug 2006 13:48:36 -0400 Message-ID: <44EB4374.1060605@secure-endpoints.com> Date: Tue, 22 Aug 2006 13:48:36 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Hartman , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> In-Reply-To: <20060822172418.GD10458@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Tue, 22 Aug 2006 13:48:36 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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="===============1059126307==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1059126307== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010702060702050102070009" This is a cryptographically signed message in MIME format. --------------ms010702060702050102070009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Speaking as an individual and not as Kitten Chair. Nicolas Williams wrote: > Sam> It is my reading of gs1 that it normatively requires hostbased names. > > Sam thinks GS1 excludes use of other name types for acceptors. > > I think so too, but I'm not sure that GS1/GS2 need updating as much as > applications do -- certainly applications that wish to use domain-based > names will need updating. > > I don't read GS1 to prohibit use of other name types but as providing a > required name type when a priori knowledge of server support for other > name types is not available. Clients and servers wishing to use name > types other than hostbased service clearly have to agree a priori and > SASL/GS1 implementations have to make it possible (which they might > not); there is no negotiation mechanism.. I believe that given the cookbook style language of RFC 2222 that the only reasonable interpretation is that only GSS_C_NT_HOSTBASED_SERVICE was anticipated being used. The lack of a MUST or SHOULD implies to me that the authors never considered the possibility that there might be another name type worth considering or that an alternative usage model for SASL might require the use of an alternate name type. The situation we are now confronting is a desire to use SASL for a usage model that was not previously conceived, authentication involving domain-based service names. The question then appears to me to be more general than the question of whether or not SASL-GSS-1 or SASL-GSS-2 must be updated. Instead it appears to be "does SASL support the concept of authentication with domain-based names at all?" If the answer is 'yes', then the limitations imposed by the cookbook style description of how to call GSS_Import_Name from RFC 2222 must be clarified to indicate when specific name types should be used. If the answer is that SASL does not support authentication using domain-based names, then the SASL working group must decide whether or not it wants to support those use cases in their specification. In either case, I do not believe that answering the SASL question should be a road block on the specification of domain-based service names at the GSS-API layer. Jeffrey Altman --------------ms010702060702050102070009 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MjIxNzQ4MzZaMCMGCSqGSIb3DQEJBDEWBBRZziTp 3gEkDMi05ljCv2FKRnK1sTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEASsFgM5W+WHEdvzE9T9VXqe6VnG09j3LH3cvXEGpFpJhJdRwM4i4s TtSpaDDVyTU5sY33V6NOlf7564q04/emitrvpObRYbx7SVsFphrTDbom9Yr14pqB9N0ILu0q vzOLJUqQyjqr889AQrU+s+NwB/4pAmTF++PETfvdQ1Juffgif0FVquuNPGOOX/85jISJMuVP UawEmboX217Kvcv3CuZdtWcGVHEvPx17YtdOaSn4/YQ46FRK+UoNjvLeiZI5s8aiYBQIzTM/ deyr/T1St0wfPYwq4crkmnUkk9NpJdPuZDnhXFm1sVXLjCPnFbHPacs8nd/EW/DLKECZm6W0 XwAAAAAAAA== --------------ms010702060702050102070009-- --===============1059126307== 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 --===============1059126307==-- From kitten-bounces@lists.ietf.org Tue Aug 22 14:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbGQ-0005A1-E0; Tue, 22 Aug 2006 14:46:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbGO-00059w-Rk for kitten@ietf.org; Tue, 22 Aug 2006 14:46:12 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbGN-0000ah-Ll for kitten@ietf.org; Tue, 22 Aug 2006 14:46:12 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CAFC7E00C0; Tue, 22 Aug 2006 14:46:20 -0400 (EDT) From: Sam Hartman To: Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> Date: Tue, 22 Aug 2006 14:46:20 -0400 In-Reply-To: <20060822155201.GX10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 22 Aug 2006 10:52:07 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Aug 21, 2006 at 07:24:07PM -0400, Sam Hartman Nicolas> wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: You seem to be assuming that the domain in a domain >> based names has anything to do with the realm. I assume it had >> to do with the string used for srv record lookups. Why would >> you have two different ldap schemas in the same srv record >> rotation? Nicolas> Right, thank you -- you've just made my instance naming Nicolas> concern go away. Nicolas> Perhaps I should add some text specifically describing Nicolas> application use of domain-based names in conjunction with Nicolas> DNS SRV RR lookups. Please. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 14:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbHU-0005LJ-Si; Tue, 22 Aug 2006 14:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbHU-0005KY-1J for kitten@ietf.org; Tue, 22 Aug 2006 14:47:20 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbHS-00011Z-SO for kitten@ietf.org; Tue, 22 Aug 2006 14:47:20 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ED3CBE00C0; Tue, 22 Aug 2006 14:47:20 -0400 (EDT) From: Sam Hartman To: Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <20060822173059.GY10208@binky.Central.Sun.COM> Date: Tue, 22 Aug 2006 14:47:20 -0400 In-Reply-To: <20060822173059.GY10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 22 Aug 2006 12:31:00 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Note that for things like krb5,, the existence of the domain based principal may serve as a hint that domain based names are OK. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 15:12:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbg0-0005TP-27; Tue, 22 Aug 2006 15:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbfy-0005TK-LY for kitten@ietf.org; Tue, 22 Aug 2006 15:12:38 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbft-0006dt-4k for kitten@ietf.org; Tue, 22 Aug 2006 15:12:38 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MJCWNu000994 for ; Tue, 22 Aug 2006 12:12:32 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MJCVxF013439 for ; Tue, 22 Aug 2006 13:12:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MJCVnq013987; Tue, 22 Aug 2006 14:12:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MJCVbs013986; Tue, 22 Aug 2006 14:12:31 -0500 (CDT) Date: Tue, 22 Aug 2006 14:12:31 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060822191230.GA10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <20060822173059.GY10208@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: 8ac499381112328dd60aea5b1ff596ea Cc: Kitten , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 22, 2006 at 02:47:20PM -0400, Sam Hartman wrote: > Note that for things like krb5,, the existence of the domain based > principal may serve as a hint that domain based names are OK. But this is very specific to Kerberos V. I would not want to rely on this for negotiation, though I'd be happy with a MAY about it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 15:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbs1-00022P-Px; Tue, 22 Aug 2006 15:25:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbs0-00022K-PQ for kitten@ietf.org; Tue, 22 Aug 2006 15:25:04 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbrz-00025g-J6 for kitten@ietf.org; Tue, 22 Aug 2006 15:25:04 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MJP0qh022763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 15:25:00 -0400 (EDT) Date: Tue, 22 Aug 2006 15:25:00 -0400 From: Jeffrey Hutzelman To: Jeffrey Altman , Sam Hartman , Kitten , ietf-sasl@imc.org Message-ID: <7219F14BB2457B6760CB186F@sirius.fac.cs.cmu.edu> In-Reply-To: <44EB4374.1060605@secure-endpoints.com> References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> Originator-Info: login-token=Mulberry:01ALD1RmoYarpM+23HMy4ltZciLHGH5G5tJSOrNjA=; 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: cf4fa59384e76e63313391b70cd0dd25 Cc: Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey Altman wrote: > In either case, I do not believe that answering the SASL question should > be a road block on the specification of domain-based service names at > the GSS-API layer. Nor do I. I see immediate uses for domain-based service names in a variety of non-SASL applications, including SSH, AFS, and NFSv4, just to name a few. Yes, it may be necessary in some cases to modify the application protocol specifications to allow the use of domain-based names. I don't consider that to be a significant problem. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 15:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc3O-0006k5-Cx; Tue, 22 Aug 2006 15:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc3M-0006k0-Lp for kitten@ietf.org; Tue, 22 Aug 2006 15:36:48 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFc3L-0003vg-Fv for kitten@ietf.org; Tue, 22 Aug 2006 15:36:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C3D7E00C0; Tue, 22 Aug 2006 15:36:48 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> <7219F14BB2457B6760CB186F@sirius.fac.cs.cmu.edu> Date: Tue, 22 Aug 2006 15:36:48 -0400 In-Reply-To: <7219F14BB2457B6760CB186F@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 22 Aug 2006 15:25:00 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Jeffrey Altman , Kitten , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey Jeffrey> Altman Jeffrey> wrote: >> In either case, I do not believe that answering the SASL >> question should be a road block on the specification of >> domain-based service names at the GSS-API layer. Jeffrey> Nor do I. I see immediate uses for domain-based service Jeffrey> names in a variety of non-SASL applications, including Jeffrey> SSH, AFS, and NFSv4, just to name a few. Yes, it may be Jeffrey> necessary in some cases to modify the application Jeffrey> protocol specifications to allow the use of domain-based Jeffrey> names. I don't consider that to be a significant Jeffrey> problem. In order to take the document to the IESG I need to be convinced that it is done. It would be much easier for me to do that if I saw how to adapt existing applications. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 15:38:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc5S-0007NJ-C2; Tue, 22 Aug 2006 15:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFc5R-0007N8-Dt for kitten@ietf.org; Tue, 22 Aug 2006 15:38:57 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFc5P-0004OL-VQ for kitten@ietf.org; Tue, 22 Aug 2006 15:38:57 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MJcsCJ003363 for ; Tue, 22 Aug 2006 12:38:55 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MJcsQ0023375 for ; Tue, 22 Aug 2006 13:38:54 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MJcsMC014165; Tue, 22 Aug 2006 14:38:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MJcs7E014164; Tue, 22 Aug 2006 14:38:54 -0500 (CDT) Date: Tue, 22 Aug 2006 14:38:54 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060822193853.GB10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Kitten Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 22, 2006 at 02:46:20PM -0400, Sam Hartman wrote: > Nicolas> Perhaps I should add some text specifically describing > Nicolas> application use of domain-based names in conjunction with > Nicolas> DNS SRV RR lookups. > > Please. 5. Server discovery, examples Domain-based names are intended for use with applications that may discover servers in insecure ways, particularly applications that use DNS [STD0013] SRV [SRV] resource record lookups and which cannot count on [DNSSEC]. Initiator applications first query DNS for the SRV RRs for a given domainname (e.g., _ldap._tcp..). Then for each SRV RR selected by the application (usually one) the application formats a string of the form @@ For example, "ldap@_ldap.tcp.foo.example.com@ds1.example.com". The initiator application MUST know a priori whether the acceptor is expected to have credentials for domain-based names. Application protocol developers must specify how such a priori knowledge is determined, and in what circumstances fallback to host-based service naming is allowed, if any. See Section 6. 6. Security Considerations ... Negotiation of use of domain-based versus host-based principal naming may be open to downgrade attacks if not designed properly. For example, negotiation of name-type through SRV RR naming conventions is open to downgrade attacks through DNS if DNSSEC is not used. Another example: applications which rely on the Kerberos V GSS-API mechanism [RFC1964] or similar, to negotiate acceptor support for domain-based names in the TGS exchange (i.e., KDC_ERR_S_PRINCIPAL_UNKNOWN implying no acceptor support for domain-based names) are open to downgrade attacks through spoofed KRB-ERROR TGS replies. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 15:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcBS-0001GC-Vb; Tue, 22 Aug 2006 15:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcBR-0001G6-O6 for kitten@ietf.org; Tue, 22 Aug 2006 15:45:09 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcBO-00059B-RW for kitten@ietf.org; Tue, 22 Aug 2006 15:45:09 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MJj588009108 for ; Tue, 22 Aug 2006 12:45:06 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MJj5T8025726 for ; Tue, 22 Aug 2006 13:45:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MJj5Uq014204; Tue, 22 Aug 2006 14:45:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MJj4sj014203; Tue, 22 Aug 2006 14:45:04 -0500 (CDT) Date: Tue, 22 Aug 2006 14:45:04 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060822194504.GC10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , Jeffrey Altman , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> <7219F14BB2457B6760CB186F@sirius.fac.cs.cmu.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: 79899194edc4f33a41f49410777972f8 Cc: Jeffrey Altman , Kitten , ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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, Aug 22, 2006 at 03:36:48PM -0400, Sam Hartman wrote: > In order to take the document to the IESG I need to be convinced that > it is done. It would be much easier for me to do that if I saw how to > adapt existing applications. See text I just posted. Please add suggestions. I am willing to submit an Internet-Draft describing NFSv4 domain root server discovery if it would help. It would essentially contain the text I just posted, using 'nfs' as the GSS-API service name, and '_nfs._tcp..' as the SRV RR name. No negotiation would be provided; instead use of domain-based acceptor names for root servers would be REQUIRED, with the ability to optionally configure use of host-based names for specific domains, or all domains. Such a document would not say much more, if anything, about NFSv4 global namespace construction. I am not sure how quickly such a document could progress, or how quickly it could become an NFSv4 WG item, if at all. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 16:47:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFd9d-0005b8-Er; Tue, 22 Aug 2006 16:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFd9c-0005b3-Hu for kitten@ietf.org; Tue, 22 Aug 2006 16:47:20 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFd9a-0007nB-UU for kitten@ietf.org; Tue, 22 Aug 2006 16:47:20 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000027643.msg for ; Tue, 22 Aug 2006 16:49:18 -0400 Message-ID: <44EB6DCD.1080504@secure-endpoints.com> Date: Tue, 22 Aug 2006 16:49:17 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sam Hartman , Kitten References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822193853.GB10208@binky.Central.Sun.COM> In-Reply-To: <20060822193853.GB10208@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Tue, 22 Aug 2006 16:49:18 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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="===============1096309729==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1096309729== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050207040404030405010203" This is a cryptographically signed message in MIME format. --------------ms050207040404030405010203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Tue, Aug 22, 2006 at 02:46:20PM -0400, Sam Hartman wrote: >> Nicolas> Perhaps I should add some text specifically describing >> Nicolas> application use of domain-based names in conjunction with >> Nicolas> DNS SRV RR lookups. >> >> Please. > > 5. Server discovery, examples > > Domain-based names are intended for use with applications that may > discover servers in insecure ways, particularly applications that use > DNS [STD0013] SRV [SRV] resource record lookups and which cannot count on > [DNSSEC]. > > Initiator applications first query DNS for the SRV RRs for a given > domainname (e.g., _ldap._tcp..). Then for each SRV RR > selected by the application (usually one) the application formats a > string of the form > > @@ > > For example, "ldap@_ldap.tcp.foo.example.com@ds1.example.com". > > The initiator application MUST know a priori whether the acceptor > is expected to have credentials for domain-based names. > > Application protocol developers must specify how such a priori > knowledge is determined, and in what circumstances fallback to > host-based service naming is allowed, if any. See Section 6. > > > 6. Security Considerations > > ... > > Negotiation of use of domain-based versus host-based principal naming > may be open to downgrade attacks if not designed properly. For > example, negotiation of name-type through SRV RR naming conventions > is open to downgrade attacks through DNS if DNSSEC is not used. > > Another example: applications which rely on the Kerberos V GSS-API > mechanism [RFC1964] or similar, to negotiate acceptor support for > domain-based names in the TGS exchange (i.e., > KDC_ERR_S_PRINCIPAL_UNKNOWN implying no acceptor support for > domain-based names) are open to downgrade attacks through spoofed > KRB-ERROR TGS replies. > > > Nico I think this text is on the mark. Jeffrey Altman --------------ms050207040404030405010203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MjIyMDQ5MTdaMCMGCSqGSIb3DQEJBDEWBBSBMS2N ycQA1Y5YCYYNAOpBQWGw0TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAPw29yhm+Qc9a9uBrng79JylEUOpIm5ldBnVrD3ZqzwA2T3lSvEMa lKjWpBF2Fa777He7XABw+Eutlck+oCp8SWdype1YnZwgKJqfJwI2nyQc3ugRDPEK5OmD3VeD YLMq7Mhzt38/sQZwZBcaeQI7+brFvQ2jUDfMidpudbqLUZi1LTY6/2ZprIo3oo7S8xILoVCC zb7ORcNFlaPhn610iGcteDWEVnLdhEzxUnoTIlPL0K6wXIlDgbIR1N5W0k8fyvSEeB9eU5RI hNXoSJjbF0bsuHj8dDiTTTtRDsdJJ0LgKPVgoJ9ImYG+1M037Kc2KJojElKNlyIo25c2lhSM NgAAAAAAAA== --------------ms050207040404030405010203-- --===============1096309729== 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 --===============1096309729==-- From kitten-bounces@lists.ietf.org Tue Aug 22 17:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdTH-0004Ut-Mj; Tue, 22 Aug 2006 17:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdTG-0004Uo-I4 for kitten@ietf.org; Tue, 22 Aug 2006 17:07:38 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdTD-0002oI-20 for kitten@ietf.org; Tue, 22 Aug 2006 17:07:38 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7ML7XBv019092 for ; Tue, 22 Aug 2006 14:07:34 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7ML3JkQ028207 for ; Tue, 22 Aug 2006 15:03:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7ML7X9O014287; Tue, 22 Aug 2006 16:07:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7ML7XCX014286; Tue, 22 Aug 2006 16:07:33 -0500 (CDT) Date: Tue, 22 Aug 2006 16:07:33 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060822210732.GF10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608222035.WAA07403@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 10:35:52PM +0200, Martin Rex wrote: > > That it does, but to the exclusion of all others? That I'm not sure of; > > RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor ^ not > > names." Perhaps that was an oversight and we should read it as > > normatively requiring use of hostbased service principal names for > > acceptors. If we do this then, then would we be able to update GS1? > > > > Should we hold this discussion on the SASL list? > > This seems to be an unfortunate and serious flaw in RFC2222 Think of it as a GSS-API application (or class of applications, as it encompasses all SASL applications that would use the GSS-API through SASL) that was only interested in host-based service names. It is perfectly fine for a GSS-API application to restrict itself to only one kind of peer. So, it's not that serious a flaw. Also, the fix is obvious, obvious enough that I'm not sure that we really need to update SASL/GS1 (RFC222, draft-ietf-sasl-gssapi), but don't mind doing if there's still time for updating draft-ietf-sasl-gssapi and the SASL WG agrees. Think of RFC2222 as specifying a default acceptor name type for all SASL/GS1 applications. For all other acceptor name types the application must know a priori that it may/should/must use such other name types. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdjj-0000tO-BV; Tue, 22 Aug 2006 17:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdji-0000tE-RZ for kitten@ietf.org; Tue, 22 Aug 2006 17:24:38 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdjh-000672-K0 for kitten@ietf.org; Tue, 22 Aug 2006 17:24:38 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MLOa6u026859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 17:24:36 -0400 (EDT) Date: Tue, 22 Aug 2006 17:24:36 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex Message-ID: <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> In-Reply-To: <20060822210732.GF10208@binky.Central.Sun.COM> References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:011xWuD0F9I4MjYCaQCpPefm6H5TpeSSdEitx0DZU=; 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: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 04:07:33 PM -0500 Nicolas Williams wrote: > On Tue, Aug 22, 2006 at 10:35:52PM +0200, Martin Rex wrote: >> > That it does, but to the exclusion of all others? That I'm not sure >> > of; RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor > ^ > not >> > names." Perhaps that was an oversight and we should read it as >> > normatively requiring use of hostbased service principal names for >> > acceptors. If we do this then, then would we be able to update GS1? >> > >> > Should we hold this discussion on the SASL list? >> >> This seems to be an unfortunate and serious flaw in RFC2222 > > Think of it as a GSS-API application (or class of applications, as it > encompasses all SASL applications that would use the GSS-API through > SASL) that was only interested in host-based service names. > > It is perfectly fine for a GSS-API application to restrict itself to > only one kind of peer. > > So, it's not that serious a flaw. Also, the fix is obvious, obvious > enough that I'm not sure that we really need to update SASL/GS1 (RFC222, > draft-ietf-sasl-gssapi), but don't mind doing if there's still time for > updating draft-ietf-sasl-gssapi and the SASL WG agrees. > > Think of RFC2222 as specifying a default acceptor name type for all > SASL/GS1 applications. For all other acceptor name types the > application must know a priori that it may/should/must use such other > name types. Incidentally, I think we can specify separate behavior for GS1 and GS2. The GS1 document is specific to Kerberos, and so we can do things like have it try a domain-based service name and then fall back to a host-based one, though existing libraries could not do that without information from the application as to the hostname of the server. Note, BTW, that when I speak of falling back to a host-based service name, I'm talking about a service name constructed using the service domain name, not a hostname derived from reverse DNS or other insecure sources. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:28:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdnR-0002kO-PP; Tue, 22 Aug 2006 17:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdnQ-0002b3-1Z for kitten@ietf.org; Tue, 22 Aug 2006 17:28:28 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdnO-0006vF-Ix for kitten@ietf.org; Tue, 22 Aug 2006 17:28:28 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MLSPml027811 for ; Tue, 22 Aug 2006 14:28:25 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MLOBau006130 for ; Tue, 22 Aug 2006 15:24:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MLSOfS014321; Tue, 22 Aug 2006 16:28:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MLSOir014320; Tue, 22 Aug 2006 16:28:24 -0500 (CDT) Date: Tue, 22 Aug 2006 16:28:24 -0500 From: Nicolas Williams To: Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org Message-ID: <20060822212824.GG10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822210732.GF10208@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 And yes, there should still be time to so update draft-ietf-sasl-gssapi as it's in Revised ID Needed state. The update would be a small change to the first paragraph of section 3.1. Unfortunately that paragraph is already quite long, and I'd hesitate to make it any longer. Alexey, can we split that paragraph into more manageable chunks? Something like: The client calls GSS_Init_sec_context, passing in o input_context_handle == GSS_C_NO_CONTEXT (initially) o mech_type == the Kerberos V5 GSS-API mechanism [KRB5GSS] o chan_binding == NULL o input_token == NULL o sequence_req_flag == TRUE o integ_req_flag == TRUE o conf_req_flag == TRUE if the client will be requesting a security layer providing confidentiality protection o targ_name -- (see below) [Aside: the spec says to set sequence_req_flag == TRUE, but replay_det_req_flag == TRUE should have sufficed, since SASL is stream- oriented. Oh well.] Typically clients will obtain a NAME for the acceptor by calling GSS_Import_name() with GSS_C_NT_HOSTBASED_SERVICE as the input_name_type and an input_name_string with the form "service@hostname" (see [RFC2743]) where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server. Clients MAY use other name types for servers, but MUST know a priori and as decribed in the protocol's profile, whether such other name types are allowed. Hostbased service SHALL be the default name type for server for any protocol profile which does not specify one. The client then responds with the resulting output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client should expect the server to issue a token in a subsequent challenge. The client must pass the token to another call to GSS_Init_sec_context, repeating the actions in this paragraph. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdoo-0003qE-Jw; Tue, 22 Aug 2006 17:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdon-0003q9-6h for kitten@ietf.org; Tue, 22 Aug 2006 17:29:53 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdol-0007OW-SY for kitten@ietf.org; Tue, 22 Aug 2006 17:29:53 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MLTp2Z012389 for ; Tue, 22 Aug 2006 15:29:51 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MLPbFE006859 for ; Tue, 22 Aug 2006 15:25:37 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MLToTi014330; Tue, 22 Aug 2006 16:29:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MLTodt014329; Tue, 22 Aug 2006 16:29:50 -0500 (CDT) Date: Tue, 22 Aug 2006 16:29:50 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060822212949.GH10208@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 05:24:36PM -0400, Jeffrey Hutzelman wrote: > Incidentally, I think we can specify separate behavior for GS1 and GS2. > The GS1 document is specific to Kerberos, and so we can do things like have > it try a domain-based service name and then fall back to a host-based one, > though existing libraries could not do that without information from the > application as to the hostname of the server. See the proposed security considerations text in my earlier post. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdvu-0007Dk-Dj; Tue, 22 Aug 2006 17:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFdvt-0007Dc-V0 for kitten@ietf.org; Tue, 22 Aug 2006 17:37:13 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdvs-0000dU-OT for kitten@ietf.org; Tue, 22 Aug 2006 17:37:13 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MLbBhL027301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 17:37:12 -0400 (EDT) Date: Tue, 22 Aug 2006 17:37:11 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: In-Reply-To: <20060822212949.GH10208@binky.Central.Sun.COM> References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> <20060822212949.GH10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01ziC8eziIMe8aazT8AZ7s6mWS86ZVVDU7lergBKA=; 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 04:29:50 PM -0500 Nicolas Williams wrote: > On Tue, Aug 22, 2006 at 05:24:36PM -0400, Jeffrey Hutzelman wrote: >> Incidentally, I think we can specify separate behavior for GS1 and GS2. >> The GS1 document is specific to Kerberos, and so we can do things like >> have it try a domain-based service name and then fall back to a >> host-based one, though existing libraries could not do that without >> information from the application as to the hostname of the server. > > See the proposed security considerations text in my earlier post. Your text describes a potential "downgrade" attack. But downgrading to host-based service names is only an attack if it somehow makes the connection less secure. That might be the case if you downgraded from using a domain-based service name to using a host-based name constructed using a hostname from reverse DNS or some other insecure source. But that's not how host-based service names are supposed to work today, and it's not what I was proposing. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe6e-0002ah-OA; Tue, 22 Aug 2006 17:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe6b-0002Mo-JP for kitten@ietf.org; Tue, 22 Aug 2006 17:48:17 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFe6a-0002vU-C6 for kitten@ietf.org; Tue, 22 Aug 2006 17:48:17 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MLmD9E027553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 17:48:13 -0400 (EDT) Date: Tue, 22 Aug 2006 17:48:13 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org Message-ID: <2B32F2817109FAA8617695E6@sirius.fac.cs.cmu.edu> In-Reply-To: <20060822212824.GG10208@binky.Central.Sun.COM> References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <20060822212824.GG10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01cvZoHdxe3ZG+QeCepXSYjAlon0j5KuHfa5aCqHY=; 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: 8b30eb7682a596edff707698f4a80f7d Cc: Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 04:28:24 PM -0500 Nicolas Williams wrote: > Typically clients will obtain a NAME for the acceptor by calling > GSS_Import_name() with GSS_C_NT_HOSTBASED_SERVICE as the > input_name_type and an input_name_string with the form > "service@hostname" (see [RFC2743]) where "service" is the service > name specified in the protocol's profile, and "hostname" is the fully > qualified host name of the server. Clients MAY use other name types > for servers, but MUST know a priori and as decribed in the protocol's > profile, whether such other name types are allowed. Hostbased > service SHALL be the default name type for server for any > protocol profile which does not specify one. No; SASL protocols are mechanism-agnostic, and mechanisms are protocol-agnostic. You cannot require SASL protocol provides to parameterize specific mechanisms in this way. In the case of GS1, I think we can produce something which works and is interoperable with what is deployed today, by using a domain-based service name if the initial init_sec_context works with that name, and falling back to a host-based name otherwise. Note my previous message explaining why there is no attack here, as long as the host-based name is formed correctly. In the case of GS2, we are defining a new protocol which no one has yet deployed. Thus, we have the opportunity to build in a mechanism by which we try establishing a context with a domain-based service name and, if that fails, try again with a host-based service name, all without the app knowing anything about it. In either case, existing SASL libraries will probably require modifications to allow the application to pass down information about the identity of the specific host to which we're authenticating, which is needed in order to construct a domain-based service name. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe8V-0003DV-Sf; Tue, 22 Aug 2006 17:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFe8U-0003Bg-9n for kitten@ietf.org; Tue, 22 Aug 2006 17:50:14 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFe8S-0003UE-UF for kitten@ietf.org; Tue, 22 Aug 2006 17:50:14 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MLoCvK026507 for ; Tue, 22 Aug 2006 15:50:12 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MLjwTt015806 for ; Tue, 22 Aug 2006 15:45:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MLoBa6014348; Tue, 22 Aug 2006 16:50:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MLoB51014347; Tue, 22 Aug 2006 16:50:11 -0500 (CDT) Date: Tue, 22 Aug 2006 16:50:11 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060822215011.GJ10208@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> <20060822212949.GH10208@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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 05:37:11PM -0400, Jeffrey Hutzelman wrote: > >See the proposed security considerations text in my earlier post. > > Your text describes a potential "downgrade" attack. But downgrading to > host-based service names is only an attack if it somehow makes the > connection less secure. That might be the case if you downgraded from > using a domain-based service name to using a host-based name constructed > using a hostname from reverse DNS or some other insecure source. But > that's not how host-based service names are supposed to work today, and > it's not what I was proposing. It's a downgrade attack if the server discovery method is insecure. I need to make that clearer in the sec cons text, particularly in the paragraph that discusses the downgrade due to the lack of integrity protection for KRB-ERROR in the TGS exchange. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeBS-0004SQ-PX; Tue, 22 Aug 2006 17:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeBR-0004S6-0V for kitten@ietf.org; Tue, 22 Aug 2006 17:53:17 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFeBP-00046q-QN for kitten@ietf.org; Tue, 22 Aug 2006 17:53:16 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MLrFgB027671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 17:53:15 -0400 (EDT) Date: Tue, 22 Aug 2006 17:53:15 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: In-Reply-To: <20060822215011.GJ10208@binky.Central.Sun.COM> References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> <20060822212949.GH10208@binky.Central.Sun.COM> <20060822215011.GJ10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01DUKn33eqHFNZjR9gQMDXTqS03gqUdiB6t9VEQ8I=; 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: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 04:50:11 PM -0500 Nicolas Williams wrote: > On Tue, Aug 22, 2006 at 05:37:11PM -0400, Jeffrey Hutzelman wrote: >> > See the proposed security considerations text in my earlier post. >> >> Your text describes a potential "downgrade" attack. But downgrading to >> host-based service names is only an attack if it somehow makes the >> connection less secure. That might be the case if you downgraded from >> using a domain-based service name to using a host-based name constructed >> using a hostname from reverse DNS or some other insecure source. But >> that's not how host-based service names are supposed to work today, and >> it's not what I was proposing. > > It's a downgrade attack if the server discovery method is insecure. No. It's a downgrade if the construction of the host-based service name is insecure. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeDP-0005hM-6x; Tue, 22 Aug 2006 17:55:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeDO-0005h4-52 for kitten@ietf.org; Tue, 22 Aug 2006 17:55:18 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFeDL-0004Id-Oa for kitten@ietf.org; Tue, 22 Aug 2006 17:55:18 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MLtFhq029201 for ; Tue, 22 Aug 2006 15:55:15 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MLp1Eo018174 for ; Tue, 22 Aug 2006 15:51:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MLtE3X014359; Tue, 22 Aug 2006 16:55:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MLtE2N014358; Tue, 22 Aug 2006 16:55:14 -0500 (CDT) Date: Tue, 22 Aug 2006 16:55:14 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060822215513.GK10208@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <20060822212824.GG10208@binky.Central.Sun.COM> <2B32F2817109FAA8617695E6@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B32F2817109FAA8617695E6@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 05:48:13PM -0400, Jeffrey Hutzelman wrote: > On Tuesday, August 22, 2006 04:28:24 PM -0500 Nicolas Williams > wrote: > > > Typically clients will obtain a NAME for the acceptor by calling > > GSS_Import_name() with GSS_C_NT_HOSTBASED_SERVICE as the > > input_name_type and an input_name_string with the form > > "service@hostname" (see [RFC2743]) where "service" is the service > > name specified in the protocol's profile, and "hostname" is the fully > > qualified host name of the server. Clients MAY use other name types > > for servers, but MUST know a priori and as decribed in the protocol's > > profile, whether such other name types are allowed. Hostbased > > service SHALL be the default name type for server for any > > protocol profile which does not specify one. > > No; SASL protocols are mechanism-agnostic, and mechanisms are > protocol-agnostic. You cannot require SASL protocol provides to > parameterize specific mechanisms in this way. Huh? draft-ietf-sasl-gssapi-06 already talks about "protocol profile," by which what is meant is that SASL applications, such as LDAP, IMAP, etcetera, have to provide some parameter or other. In the case of draft-ietf-sasl-gssapi-06 the one parameter that is required of application protocol profiles is the service name for use in hostbased service names. > In the case of GS1, I think we can produce something which works and is > interoperable with what is deployed today, by using a domain-based service > name if the initial init_sec_context works with that name, and falling back > to a host-based name otherwise. Note my previous message explaining why > there is no attack here, as long as the host-based name is formed correctly. How could GS1 implementations possibly do this without the application telling them what domainname to use for domain-based service names? Deriving the domainname from the hostname would be incorrect. No, GS1 cannot do this. > In the case of GS2, we are defining a new protocol which no one has yet > deployed. Thus, we have the opportunity to build in a mechanism by which > we try establishing a context with a domain-based service name and, if that > fails, try again with a host-based service name, all without the app > knowing anything about it. Not unless the application provides a domainname. The application has got to be in control here. > In either case, existing SASL libraries will probably require modifications > to allow the application to pass down information about the identity of the > specific host to which we're authenticating, which is needed in order to > construct a domain-based service name. And the domainname too. Without a doubt SASL/GS* implementations have to present APIs which make use of domain-based names possible, else they cannot make use of domain-based names. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 17:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeFQ-0006Xe-62; Tue, 22 Aug 2006 17:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeFO-0006XZ-Oj for kitten@ietf.org; Tue, 22 Aug 2006 17:57:22 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFeFN-0004di-He for kitten@ietf.org; Tue, 22 Aug 2006 17:57:22 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MLvIQT027750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 17:57:18 -0400 (EDT) Date: Tue, 22 Aug 2006 17:57:18 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: In-Reply-To: References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> <20060822212949.GH10208@binky.Central.Sun.COM> <20060822215011.GJ10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01dZmsQd8BIbXB5CTCqBfcsAwL42z8zSXiDtqmqxk=; 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: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 05:53:15 PM -0400 Jeffrey Hutzelman wrote: > > > On Tuesday, August 22, 2006 04:50:11 PM -0500 Nicolas Williams > wrote: > >> On Tue, Aug 22, 2006 at 05:37:11PM -0400, Jeffrey Hutzelman wrote: >>> > See the proposed security considerations text in my earlier post. >>> >>> Your text describes a potential "downgrade" attack. But downgrading to >>> host-based service names is only an attack if it somehow makes the >>> connection less secure. That might be the case if you downgraded from >>> using a domain-based service name to using a host-based name constructed >>> using a hostname from reverse DNS or some other insecure source. But >>> that's not how host-based service names are supposed to work today, and >>> it's not what I was proposing. >> >> It's a downgrade attack if the server discovery method is insecure. > > No. It's a downgrade if the construction of the host-based service name > is insecure. The mistake is conflating the name of the service with what is returned in a DNS SRV record. The SRV record doesn't tell you the name of the service; it tells you a DNS domain name that's supposed to resolve to the network address you connect to in order to talk to the service. If I want to talk to the 'imap' service for 'imap.srv.cs.cmu.edu', then the correct service name is either 'imap@imap.srv.cs.cmu.edu@some.host' or 'imap@imap.srv.cs.cmu.edu'. It should never be 'imap@some.host'. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 18:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeRy-0002sn-By; Tue, 22 Aug 2006 18:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFeRx-0002sh-8a for kitten@ietf.org; Tue, 22 Aug 2006 18:10:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcjs-0003BK-QK for kitten@ietf.org; Tue, 22 Aug 2006 16:20:44 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFcaz-0001YI-8B for kitten@ietf.org; Tue, 22 Aug 2006 16:11:34 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MKBRjX024289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 16:11:27 -0400 (EDT) Date: Tue, 22 Aug 2006 16:11:27 -0400 From: Jeffrey Hutzelman To: Sam Hartman Message-ID: <322AF6DCAE2E5A13DE1D5F1D@sirius.fac.cs.cmu.edu> In-Reply-To: References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> <7219F14BB2457B6760CB186F@sirius.fac.cs.cmu.edu> Originator-Info: login-token=Mulberry:01RM5MMa42waWQGcSyd0x8oNtAg1zLAsWxQ3qWek4=; 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: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Jeffrey Altman , Kitten , ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Tuesday, August 22, 2006 03:36:48 PM -0400 Sam Hartman wrote: >>>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey > Jeffrey> Altman > Jeffrey> wrote: > > >> In either case, I do not believe that answering the SASL > >> question should be a road block on the specification of > >> domain-based service names at the GSS-API layer. > > Jeffrey> Nor do I. I see immediate uses for domain-based service > Jeffrey> names in a variety of non-SASL applications, including > Jeffrey> SSH, AFS, and NFSv4, just to name a few. Yes, it may be > Jeffrey> necessary in some cases to modify the application > Jeffrey> protocol specifications to allow the use of domain-based > Jeffrey> names. I don't consider that to be a significant > Jeffrey> problem. > > In order to take the document to the IESG I need to be convinced that > it is done. It would be much easier for me to do that if I saw how to > adapt existing applications. Personally, I'd love to be able to assume that if you can get as far as the first call to init_sec_context, then all is well; that's the technique that applications already use to determine whether to offer a GSS-API-based mechanism at all. But, as Nico pointed out, that may not work for every mechanism - there will certainly be mechanims for which clients can get credentials for _any_ service name. So, there needs to be an application-specific negotiation. For SSH key exchange, I'd expect that to take the form of a new family of mechanism names. For SSH user auth, I'd expect clients to try with a domain-based service name, and then fall back to trying the same mechanism with a host-based service name. For _new_ applications, one might simply specify the use of domain-based service names to begin with. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 18:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFesz-0003Et-6N; Tue, 22 Aug 2006 18:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFesx-0003En-Kw for kitten@ietf.org; Tue, 22 Aug 2006 18:38:15 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFesw-0001wu-92 for kitten@ietf.org; Tue, 22 Aug 2006 18:38:15 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA27743; Wed, 23 Aug 2006 00:38:04 +0200 (MESZ) From: Martin Rex Message-Id: <200608222238.AAA08972@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 23 Aug 2006 00:38:04 +0200 (MET DST) In-Reply-To: <20060822215011.GJ10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 22, 6 04:50:11 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: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 05:37:11PM -0400, Jeffrey Hutzelman wrote: > > >See the proposed security considerations text in my earlier post. > > > > Your text describes a potential "downgrade" attack. But downgrading to > > host-based service names is only an attack if it somehow makes the > > connection less secure. That might be the case if you downgraded from > > using a domain-based service name to using a host-based name constructed > > using a hostname from reverse DNS or some other insecure source. But > > that's not how host-based service names are supposed to work today, and > > it's not what I was proposing. > > It's a downgrade attack if the server discovery method is insecure. I > need to make that clearer in the sec cons text, particularly in the > paragraph that discusses the downgrade due to the lack of integrity > protection for KRB-ERROR in the TGS exchange. Hostbased service names as they described in RFC-2743 and as they had been implemented in MIT Kerberos for more than a decade suffer a serious vulnerability. They transform the target name with the help of INsecure DNS lookups. Any kind of transformations on the authenticated name through insecure DNS are a bad idea and implementations should stop suggesting applications to use functionality that -today- is provided through insecure DNS. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 18:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFf1q-000143-Ab; Tue, 22 Aug 2006 18:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFf1o-00013x-E7 for kitten@ietf.org; Tue, 22 Aug 2006 18:47:24 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFf1n-0004cg-2F for kitten@ietf.org; Tue, 22 Aug 2006 18:47:24 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA08971; Wed, 23 Aug 2006 00:47:19 +0200 (MESZ) From: Martin Rex Message-Id: <200608222247.AAA09061@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 23 Aug 2006 00:47:17 +0200 (MET DST) In-Reply-To: <20060822193853.GB10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 22, 6 02:38:54 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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: > > 6. Security Considerations > > ... > > Negotiation of use of domain-based versus host-based principal naming > may be open to downgrade attacks if not designed properly. For > example, negotiation of name-type through SRV RR naming conventions > is open to downgrade attacks through DNS if DNSSEC is not used. > > Another example: applications which rely on the Kerberos V GSS-API > mechanism [RFC1964] or similar, to negotiate acceptor support for > domain-based names in the TGS exchange (i.e., > KDC_ERR_S_PRINCIPAL_UNKNOWN implying no acceptor support for > domain-based names) are open to downgrade attacks through spoofed > KRB-ERROR TGS replies. Downgrade attack? The vulnerability might be magnitude more serious than that. For hostbased service names the transformation as suggested by RFC-2743 and as implemented in MIT Kerberos 5 allows for a >>> FULL COMPROMISE <<< (i.e. failure of the mutual authentication) if the attacker can break into an arbitrary machine of the realm that has a local key for the desired service (every machine has a host service, so this one is the most vulnerable service of all), and then spoof the insecure DNS lookup. Spoofing DNS may also make it easier to redirect the actual network communication. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfMD-0002Pu-E0; Tue, 22 Aug 2006 19:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfMC-0002PV-US for kitten@ietf.org; Tue, 22 Aug 2006 19:08:28 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFfM7-0002bg-9U for kitten@ietf.org; Tue, 22 Aug 2006 19:08:28 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MN8Mdi015433 for ; Tue, 22 Aug 2006 16:08:22 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MN8MOn015402 for ; Tue, 22 Aug 2006 17:08:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MN8LZI014395; Tue, 22 Aug 2006 18:08:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MN8LnP014394; Tue, 22 Aug 2006 18:08:21 -0500 (CDT) Date: Tue, 22 Aug 2006 18:08:21 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060822230820.GM10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20060822193853.GB10208@binky.Central.Sun.COM> <200608222247.AAA09061@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608222247.AAA09061@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Hostname canonicalization (Re: Working Group Last Call: GSS-API Domain-Based Service Names and) 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 One step at a time Martin :) Yes, we know about hostname canonicalization attacks. Perhaps we should focus on that first. If that's your point, say so :) (I do have a proposal for dealing with hostname canonicalization, one that is both, applicable to various mechanisms generally, though the details are specific to each mechanism, and the proposal is really for GSS-APIv3, not v2.) In the end the bottom-line is that applications really should interact with users when hostname canonicalization was performed securely, if insecure hostname canonicalization is performed at all. I argue that some users really do want DNS search lists used in hostname canonicalization because they are very much used to that in traditionally non-GSS applications, such as web browsers. The moment one has DNS search lists securing hostname canonicalization becomes difficult. Think of a PKI-based mechanism, where the client won't know how to really canonicalize[*] the name until it's seen the server's certificate. [*] Forget impractical GSS niceties like gss_canonicalize_name() being supposed to give you the canonical version of the given name -- for a PKI-based mech w/o a secure directory upfront this isn't possible.) Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfO6-0002iY-NJ; Tue, 22 Aug 2006 19:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfO5-0002iL-Lz for kitten@ietf.org; Tue, 22 Aug 2006 19:10:25 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFfO3-0003j0-5I for kitten@ietf.org; Tue, 22 Aug 2006 19:10:25 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MNAML7011686 for ; Tue, 22 Aug 2006 17:10:22 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MNAM2S016045 for ; Tue, 22 Aug 2006 17:10:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MNAM0J014404; Tue, 22 Aug 2006 18:10:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MNAL1r014403; Tue, 22 Aug 2006 18:10:21 -0500 (CDT) Date: Tue, 22 Aug 2006 18:10:21 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060822231021.GN10208@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Martin Rex , hartmans-ietf@mit.edu, kitten@ietf.org References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <20060822212824.GG10208@binky.Central.Sun.COM> <2B32F2817109FAA8617695E6@sirius.fac.cs.cmu.edu> <20060822215513.GK10208@binky.Central.Sun.COM> <4BAEBA67A051B97B1DC8956C@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BAEBA67A051B97B1DC8956C@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 22, 2006 at 06:59:39PM -0400, Jeffrey Hutzelman wrote: > >>In either case, existing SASL libraries will probably require > >>modifications to allow the application to pass down information about > >>the identity of the specific host to which we're authenticating, which > >>is needed in order to construct a domain-based service name. > > > >And the domainname too. > > Yes. Today, the application has to present one name; to do domain-based > names, it has to present two. So? The APIs have to change. Even with your proposal they have to change, and it means that the application has to provide one more parameter. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfP3-0002uo-LI; Tue, 22 Aug 2006 19:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfMa-0002T9-Qu for kitten@ietf.org; Tue, 22 Aug 2006 19:08:52 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFfDi-0000b6-Ek for kitten@ietf.org; Tue, 22 Aug 2006 18:59:44 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MMxdio028786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 18:59:39 -0400 (EDT) Date: Tue, 22 Aug 2006 18:59:39 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <4BAEBA67A051B97B1DC8956C@sirius.fac.cs.cmu.edu> In-Reply-To: <20060822215513.GK10208@binky.Central.Sun.COM> References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <20060822212824.GG10208@binky.Central.Sun.COM> <2B32F2817109FAA8617695E6@sirius.fac.cs.cmu.edu> <20060822215513.GK10208@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01M5tsYp0D4dZ/5uTjZhmc0coNo426z+WgEJrHaRs=; 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 04:55:14 PM -0500 Nicolas Williams wrote: > On Tue, Aug 22, 2006 at 05:48:13PM -0400, Jeffrey Hutzelman wrote: >> No; SASL protocols are mechanism-agnostic, and mechanisms are >> protocol-agnostic. You cannot require SASL protocol provides to >> parameterize specific mechanisms in this way. > > Huh? draft-ietf-sasl-gssapi-06 already talks about "protocol profile," > by which what is meant is that SASL applications, such as LDAP, IMAP, > etcetera, have to provide some parameter or other. In the case of > draft-ietf-sasl-gssapi-06 the one parameter that is required of > application protocol profiles is the service name for use in hostbased > service names. Yes; SASL applications ("protocols", in SASL-speak) are described by a "profile" which describes how to use that application with SASL. One of the things that must be specified is a service name; this is generic to the SASL framework, not specific to that mechanism. >> In either case, existing SASL libraries will probably require >> modifications to allow the application to pass down information about >> the identity of the specific host to which we're authenticating, which >> is needed in order to construct a domain-based service name. > > And the domainname too. Yes. Today, the application has to present one name; to do domain-based names, it has to present two. More later, after we've finished our off-list discussion. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfPa-00035N-2x; Tue, 22 Aug 2006 19:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfN1-0002aM-ST for kitten@ietf.org; Tue, 22 Aug 2006 19:09:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFczW-0005rk-Iw for kitten@ietf.org; Tue, 22 Aug 2006 16:36:54 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFcyb-000268-GG for kitten@ietf.org; Tue, 22 Aug 2006 16:35:59 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA23652; Tue, 22 Aug 2006 22:35:52 +0200 (MESZ) From: Martin Rex Message-Id: <200608222035.WAA07403@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Tue, 22 Aug 2006 22:35:52 +0200 (MET DST) In-Reply-To: <20060822155201.GX10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 22, 6 10:52:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -1.6 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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: > > > Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) > > Nicolas> mention GSS-API name types, or one name type anyways, > > Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict > > Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or > > Nicolas> requires updating > > It is my reading of gs1 that it normatively requires hostbased names. > > That it does, but to the exclusion of all others? That I'm not sure of; > RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor > names." Perhaps that was an oversight and we should read it as > normatively requiring use of hostbased service principal names for > acceptors. If we do this then, then would we be able to update GS1? > > Should we hold this discussion on the SASL list? This seems to be an unfortunate and serious flaw in RFC2222 Hostbased service names are optional for GSS-API mechanisms, and the vast majority of gssapi mechanisms that I know doesn't implement them at all. If SASL does not have a fallback for use with GSS-API mechanisms that do not support hostbased service names, then the GSS-API related part of the spec is seriously broken. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfb9-0008KR-9f; Tue, 22 Aug 2006 19:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfb8-0008KL-Hc for kitten@ietf.org; Tue, 22 Aug 2006 19:23:54 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFfb7-0007NK-2B for kitten@ietf.org; Tue, 22 Aug 2006 19:23:54 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7MNNqfS014959 for ; Tue, 22 Aug 2006 16:23:52 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7MNNpr4019865 for ; Tue, 22 Aug 2006 17:23:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7MNNpkZ014415; Tue, 22 Aug 2006 18:23:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7MNNpx6014414; Tue, 22 Aug 2006 18:23:51 -0500 (CDT) Date: Tue, 22 Aug 2006 18:23:51 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20060822232350.GO10208@binky.Central.Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , kitten@ietf.org, hartmans-ietf@mit.edu References: <20060822155201.GX10208@binky.Central.Sun.COM> <200608222035.WAA07403@uw1048.wdf.sap.corp> <20060822210732.GF10208@binky.Central.Sun.COM> <454CDFCB5B6EBA0FEFB5C348@sirius.fac.cs.cmu.edu> <20060822212949.GH10208@binky.Central.Sun.COM> <20060822215011.GJ10208@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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, hartmans-ietf@mit.edu Subject: Jeff's proposal (Re: Working Group Last Call: GSS-API Domain-Based Service Names and) 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 Jeff H. points out that the main reason to want domain-based names as opposed to hostbased-names-with-domains-as-hostnames is to avoid acceptor credential sharing. In both cases we want to protect initiators from redirection attacks during unprotected server discovery. Jeff would like the Kerberos V GSS mechanism, or SASL/GS* when using the Kerbreos V GSS mechanism to support fallback to hostbased-names-with- domains-as-hostnames when the KDC responds KDC_ERR_S_PRINCIPAL_UNKNOWN to requests for service tickets with domain-based service principal names. I think it's very important to avoid acceptor credential sharing because of the complexities of sharing replay caches (or ensuring that they are not needed) much more than because of any desire not to share keys amongst members of a cluster. I do not entirely oppose such a fallback mechanism -- I agree that there is no downgrade attack there, but there is the issue of replay cache sharing, which does complicate things. Thoughts? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 22 19:48:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfyP-0008AL-DV; Tue, 22 Aug 2006 19:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfyO-0008AG-Gv for kitten@ietf.org; Tue, 22 Aug 2006 19:47:56 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFfyN-0004qH-8V for kitten@ietf.org; Tue, 22 Aug 2006 19:47:56 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7MNlsdX029831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 19:47:54 -0400 (EDT) Date: Tue, 22 Aug 2006 19:47:54 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Nicolas Williams Message-ID: In-Reply-To: <200608222035.WAA07403@uw1048.wdf.sap.corp> References: <200608222035.WAA07403@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:01fKFb1eYJ0EnI7NNWrx+LRBMTkgAD1dTpFok6siE=; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Tuesday, August 22, 2006 10:35:52 PM +0200 Martin Rex wrote: > Nicolas Williams wrote: >> >> > Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi) >> > Nicolas> mention GSS-API name types, or one name type anyways, >> > Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict >> > Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or >> > Nicolas> requires updating >> > It is my reading of gs1 that it normatively requires hostbased names. >> >> That it does, but to the exclusion of all others? That I'm not sure of; >> RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor >> names." Perhaps that was an oversight and we should read it as >> normatively requiring use of hostbased service principal names for >> acceptors. If we do this then, then would we be able to update GS1? >> >> Should we hold this discussion on the SASL list? > > This seems to be an unfortunate and serious flaw in RFC2222 RFC2222 is not current. RFC4422 does not define the GSS-API mechanisms; those are separate documents. > Hostbased service names are optional for GSS-API mechanisms, > and the vast majority of gssapi mechanisms that I know doesn't > implement them at all. You've made this argument before. Mechanisms which do not support host-based service names require the application to understand a mechanism-specific name type. That may be fine for SAP, but it's unacceptably and unnecessarily complex for SASL. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 07:35:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFr1K-0004Oa-UA; Wed, 23 Aug 2006 07:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFr1J-0004OT-6p for kitten@ietf.org; Wed, 23 Aug 2006 07:35:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFr1H-0004qp-Mg for kitten@ietf.org; Wed, 23 Aug 2006 07:35:41 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 12:35:32 +0100 Message-ID: <44EC31AB.80506@isode.com> Date: Wed, 23 Aug 2006 11:44:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Altman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> In-Reply-To: <44EB4374.1060605@secure-endpoints.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Kitten , ietf-sasl@imc.org, Sam Hartman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Jeffrey Altman wrote: >Speaking as an individual and not as Kitten Chair. > >Nicolas Williams wrote: > > >>Sam> It is my reading of gs1 that it normatively requires hostbased names. >> >>Sam thinks GS1 excludes use of other name types for acceptors. >> >>I think so too, but I'm not sure that GS1/GS2 need updating as much as >>applications do -- certainly applications that wish to use domain-based >>names will need updating. >> >>I don't read GS1 to prohibit use of other name types but as providing a >>required name type when a priori knowledge of server support for other >>name types is not available. Clients and servers wishing to use name >>types other than hostbased service clearly have to agree a priori and >>SASL/GS1 implementations have to make it possible (which they might >>not); there is no negotiation mechanism.. >> >> >I believe that given the cookbook style language of RFC 2222 that the >only reasonable interpretation is that only GSS_C_NT_HOSTBASED_SERVICE >was anticipated being used. The lack of a MUST or SHOULD implies to >me that the authors never considered the possibility that there might >be another name type worth considering or that an alternative usage >model for SASL might require the use of an alternate name type. > > I agree with this conclusion (I wasn't working on RFC 2222) >The situation we are now confronting is a desire to use SASL for a >usage model that was not previously conceived, authentication involving >domain-based service names. The question then appears to me to be more >general than the question of whether or not SASL-GSS-1 or SASL-GSS-2 >must be updated. Instead it appears to be "does SASL support the >concept of authentication with domain-based names at all?" > When integrating SASL into SMTP, IMAP and LDAP servers I always assumed that the answer to this question was "yes". >If the answer is 'yes', then the limitations imposed by the cookbook style >description of how to call GSS_Import_Name from RFC 2222 must be >clarified to indicate when specific name types should be used. If the >answer is that SASL does not support authentication using domain-based >names, then the SASL working group must decide whether or not it wants >to support those use cases in their specification. > >In either case, I do not believe that answering the SASL question should >be a road block on the specification of domain-based service names at >the GSS-API layer. > > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 08:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsJ0-0008GR-Ef; Wed, 23 Aug 2006 08:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsIy-0008GA-Df for kitten@ietf.org; Wed, 23 Aug 2006 08:58:00 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsIw-0006p8-0M for kitten@ietf.org; Wed, 23 Aug 2006 08:58:00 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id OAA25859; Wed, 23 Aug 2006 14:57:48 +0200 (MESZ) From: Martin Rex Message-Id: <200608231256.OAA18579@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 23 Aug 2006 14:56:58 +0200 (MET DST) In-Reply-To: from "Jeffrey Hutzelman" at Aug 22, 6 07:47:54 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Nicolas.Williams@sun.com, jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Jeffrey Hutzelman wrote: > > > Hostbased service names are optional for GSS-API mechanisms, > > and the vast majority of gssapi mechanisms that I know doesn't > > implement them at all. > > You've made this argument before. Mechanisms which do not support > host-based service names require the application to understand a > mechanism-specific name type. That may be fine for SAP, but it's > unacceptably and unnecessarily complex for SASL. There seems to be a misunderstanding. An application doesn't need to know the slightest about a gssapi mechanism and the nametypes it supports. gss_import_name() does not require a nametype OID when importing a printable name -- the mechanism is supposed to interpret the input with his preferred nametype; for Kerberos it is a Kerberos principal name. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 09:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsWG-0005Kb-Ro; Wed, 23 Aug 2006 09:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFsWF-0005KW-Fb for kitten@ietf.org; Wed, 23 Aug 2006 09:11:43 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsWD-0000k8-S6 for kitten@ietf.org; Wed, 23 Aug 2006 09:11:43 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NDBfUh004464 for ; Wed, 23 Aug 2006 06:11:41 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NDBeGQ000815 for ; Wed, 23 Aug 2006 07:11:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NDBeCJ015014; Wed, 23 Aug 2006 08:11:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NDBdLF015013; Wed, 23 Aug 2006 08:11:39 -0500 (CDT) Date: Wed, 23 Aug 2006 08:11:39 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060823131138.GU10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Jeffrey Hutzelman , kitten@ietf.org, hartmans-ietf@mit.edu References: <200608231256.OAA18579@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608231256.OAA18579@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, Jeffrey Hutzelman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Wed, Aug 23, 2006 at 02:56:58PM +0200, Martin Rex wrote: > There seems to be a misunderstanding. > > An application doesn't need to know the slightest about a gssapi > mechanism and the nametypes it supports. But application protocol specs can and do specify what name types to use. Think of GS1 as part of the application. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 10:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuBh-0004DD-TZ; Wed, 23 Aug 2006 10:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuBg-0004D5-MB for kitten@ietf.org; Wed, 23 Aug 2006 10:58:36 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuBf-0006ka-8z for kitten@ietf.org; Wed, 23 Aug 2006 10:58:36 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA00897; Wed, 23 Aug 2006 16:55:52 +0200 (MESZ) From: Martin Rex Message-Id: <200608231455.QAA20092@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 23 Aug 2006 16:55:38 +0200 (MET DST) In-Reply-To: <20060823131138.GU10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 23, 6 08:11:39 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Wed, Aug 23, 2006 at 02:56:58PM +0200, Martin Rex wrote: > > There seems to be a misunderstanding. > > > > An application doesn't need to know the slightest about a gssapi > > mechanism and the nametypes it supports. > > But application protocol specs can and do specify what name types to > use. Think of GS1 as part of the application. As far as GSS-API is concerned, the most what an application protocol could do is recommendation. There is no mandatory to implement nametype, so applications cannot mandate one, either. Most of the problems root on misconceptions about authentication, and on the design flaw of Kerberos which requires the initiator to know the name of the acceptor ahead of time, even if the initiator does NOT want to (or is not able to) perform mutual authentication (authenticate the server). By coming up with clever schemes to correctly guess the Kerberos principal name of the acceptor, the initiator may be able to successfully establish a protected communication, but it is not actually performing a real mutual authentication. Hostbased service names canonicalized through insecure DNS is even worse than the weak endpoint identification performed by Web Browsers when using HTTPS. If you add insecure transforms (i.e through an insecure directory lookup, e.g. plain old DNS) on cleverly guessed names, then you will spoil even the weak endpoint identification. The ssh leap-of-faith is much better in this respect, because it realizes the underlying problem and (a) suggests to perform out-of-band endpoint verification on first encounter and (b) memorizes user-acknowledged endpoint identification and enforces future transformations to come to the exact same result. I never liked DCE (primarily because of its licensing scheme when it started), but at least they got the architecture right. A secure Directory service was integral part of the architecture and in order to find the location and instance-specific identity of a distributed service, you would do a directory lookup to acquire these two coneptually seperate pieces of information: network-location (for establishing the network communication) and identity of the service. Requiring hostbased names to work (or even expecting them to work) is about as flawed as expecting that all mankind should consent on and switch to one single commmon human language, one single common identity card, one single programming language, one single computer architecture and CPU, etc. It will not happen and ignorance is not a suitable approach. -Martin common programming language, one single common Computer _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuTy-0003pw-I6; Wed, 23 Aug 2006 11:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuTx-0003pC-2y for kitten@ietf.org; Wed, 23 Aug 2006 11:17:29 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuTv-0002WE-KW for kitten@ietf.org; Wed, 23 Aug 2006 11:17:29 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 16:14:40 +0100 Message-ID: <44EC70A7.8040809@isode.com> Date: Wed, 23 Aug 2006 16:13:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> In-Reply-To: <20060822172418.GD10458@binky.Central.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Kitten , ietf-sasl@imc.org, Sam Hartman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Nicolas Williams wrote: >If there's any way to insert text into draft-ietf-sasl-gssapi about this >then I would opt for that, though it should not mention domain-based >name types specifically. > BTW, DIGEST-MD5 already allows for domain-based names. >Similarly for GS2. Something like: > > 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. > I am Ok with adding this text. > Applications should specify what alternate name types may be > used and in what circumstances. > > Is this a requirement on implementations or protocol specs? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuZR-0006uh-Gg; Wed, 23 Aug 2006 11:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuZP-0006tk-UP for kitten@ietf.org; Wed, 23 Aug 2006 11:23:07 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuZO-00032t-Jm for kitten@ietf.org; Wed, 23 Aug 2006 11:23:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 949BBE00C0; Wed, 23 Aug 2006 11:22:59 -0400 (EDT) From: Sam Hartman To: martin.rex@sap.com References: <200608231455.QAA20092@uw1048.wdf.sap.corp> Date: Wed, 23 Aug 2006 11:22:59 -0400 In-Reply-To: <200608231455.QAA20092@uw1048.wdf.sap.corp> (Martin Rex's message of "Wed, 23 Aug 2006 16:55:38 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: kitten@ietf.org, Nicolas Williams , jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 >>>>> "Martin" == Martin Rex writes: Martin> Nicolas Williams wrote: >> >> On Wed, Aug 23, 2006 at 02:56:58PM +0200, Martin Rex wrote: >> > There seems to be a misunderstanding. >> > >> > An application doesn't need to know the slightest about a >> gssapi > mechanism and the nametypes it supports. >> >> But application protocol specs can and do specify what name >> types to use. Think of GS1 as part of the application. Martin> As far as GSS-API is concerned, the most what an Martin> application protocol could do is recommendation. There is Martin> no mandatory to implement nametype, so applications cannot Martin> mandate one, either. I'm going to get in here early and stop this discussion before it gets out of hand as this has the potential to turn into a real flame war. The IETF has a need for interoperability. The best way we've come up with to get that is to assume that GSS mechanisms used with IETF applications support host based names and to work to make sure that's true. That's why Nico has spent so much time working with the Umich folks on the SPKM3 update discussing host based names. You are completely correct that you have identified several problems with this approach. First, if you see a way of using GSS-API that provides the same or better usability experience to end users for applications like ssh, nfs, etc without relying on host-based names, please let us know. I ask that you do so in another thread. If you would like to engage in a discussion of requirements for such a solution, I'm sure we'd all be happy to have that discussion. Secondly, we generally care about mutual authentication. It would be great to work on things like a version of RFC 4121 that allowed the acceptor to tell you what name to use and that you could later validate that name. (This interacts badly with delegation) It would be great to do a number of other things that reduced the dependence on host based names. ONCE THESE ARE DONE, we can come back and start using them in our protocols. It is not useful to tell us all that systems we have working are fundamentally flawed or to tell us that things we're doing should not be done without providing alternatives. I don't know if that is what you were trying to do, but that's how I read your message. Again, you've identified several areas for future work--we agree. However until we have alternatives, we need host based names. I do not think this discussion is on topic for the domain based names draft. Sam Hartman Security Area Director _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFub7-0007tJ-4Y; Wed, 23 Aug 2006 11:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFub6-0007rq-BN for kitten@ietf.org; Wed, 23 Aug 2006 11:24:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsZp-0001Ka-73 for kitten@ietf.org; Wed, 23 Aug 2006 09:15:25 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFsUl-0001Ue-2S for kitten@ietf.org; Wed, 23 Aug 2006 09:10:16 -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 k7NDAA3g024122 for ; Wed, 23 Aug 2006 07:10:10 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NDAALY000172 for ; Wed, 23 Aug 2006 07:10:10 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NDA9E3015005; Wed, 23 Aug 2006 08:10:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NDA8D2015004; Wed, 23 Aug 2006 08:10:08 -0500 (CDT) Date: Wed, 23 Aug 2006 08:10:08 -0500 From: Nicolas Williams To: Alexey Melnikov Message-ID: <20060823131007.GT10208@binky.Central.Sun.COM> Mail-Followup-To: Alexey Melnikov , Jeffrey Altman , Kitten , ietf-sasl@imc.org, Sam Hartman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> <44EC31AB.80506@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EC31AB.80506@isode.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.5 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Jeffrey Altman , Kitten , ietf-sasl@imc.org, Sam Hartman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Wed, Aug 23, 2006 at 11:44:59AM +0100, Alexey Melnikov wrote: > Jeffrey Altman wrote: > > The question then appears to me to be more > >general than the question of whether or not SASL-GSS-1 or SASL-GSS-2 > >must be updated. Instead it appears to be "does SASL support the > >concept of authentication with domain-based names at all?" > > > When integrating SASL into SMTP, IMAP and LDAP servers I always assumed > that the answer to this question was "yes". Well, RFC4422 does require that a service name always be involved (section 4, item (1)). But it doesn't actually discuss the structure of server names -- it doesn't even mention hostnames or domainnames. What should one take away from this? That SASL is underspecified on purpose in this area? If so then one might conclude that GS1 only provides a default name type for acceptors and that applications are free to use any other name type provided that it's some sort of service name type. Or that SASL is accidentally underspecified and that in practice it only supports host-based service names? In which case the base spec and GS1 and/or GS2 need updating. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:29:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFufW-0001Ik-4d; Wed, 23 Aug 2006 11:29:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFufV-0001Ic-Gs for kitten@ietf.org; Wed, 23 Aug 2006 11:29:25 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFufU-0003n3-9E for kitten@ietf.org; Wed, 23 Aug 2006 11:29:25 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9466FE00C0; Wed, 23 Aug 2006 11:29:27 -0400 (EDT) From: Sam Hartman To: Alexey Melnikov References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> Date: Wed, 23 Aug 2006 11:29:27 -0400 In-Reply-To: <44EC70A7.8040809@isode.com> (Alexey Melnikov's message of "Wed, 23 Aug 2006 16:13:43 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Kitten , ietf-sasl@imc.org, Nicolas Williams Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 >>>>> "Alexey" == Alexey Melnikov writes: Alexey> Nicolas Williams wrote: >> If there's any way to insert text into draft-ietf-sasl-gssapi >> about this then I would opt for that, though it should not >> mention domain-based name types specifically. >> Alexey> BTW, DIGEST-MD5 already allows for domain-based names. >> Similarly for GS2. Something like: >> >> 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. >> Alexey> I am Ok with adding this text. As AD, I'm OK with adding this text if the SASL WG supports it. As an individual, I support this text. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuxV-0000nb-FX; Wed, 23 Aug 2006 11:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuxU-0000nV-CX for kitten@ietf.org; Wed, 23 Aug 2006 11:48:00 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuxR-0006lb-4U for kitten@ietf.org; Wed, 23 Aug 2006 11:48:00 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 16:42:52 +0100 Message-ID: <44EC773D.5010705@isode.com> Date: Wed, 23 Aug 2006 16:41:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Nicolas Williams References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> In-Reply-To: <44EC70A7.8040809@isode.com> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Kitten , ietf-sasl@imc.org, Sam Hartman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Alexey Melnikov wrote: > Nicolas Williams wrote: > >> Applications should specify what alternate name types may be >> used and in what circumstances. > > Is this a requirement on implementations or protocol specs? Also, is this a normative statement or informative? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 11:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFv8T-0005uC-VZ; Wed, 23 Aug 2006 11:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFv8S-0005u6-T9 for kitten@ietf.org; Wed, 23 Aug 2006 11:59:20 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFv8R-0008Qo-NM for kitten@ietf.org; Wed, 23 Aug 2006 11:59:20 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B8EE5E00C0; Wed, 23 Aug 2006 11:59:25 -0400 (EDT) From: Sam Hartman To: Alexey Melnikov References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> Date: Wed, 23 Aug 2006 11:59:24 -0400 In-Reply-To: <44EC773D.5010705@isode.com> (Alexey Melnikov's message of "Wed, 23 Aug 2006 16:41:49 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: Kitten , ietf-sasl@imc.org, Nicolas Williams Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 A sasl mechanism spec SHOULd NOT make requirements on application protocol specs. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:04:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvDn-0000sy-GW; Wed, 23 Aug 2006 12:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvDl-0000so-Rv for kitten@ietf.org; Wed, 23 Aug 2006 12:04:49 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvDk-0000kH-FQ for kitten@ietf.org; Wed, 23 Aug 2006 12:04:49 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 23 Aug 2006 17:01:32 +0100 Message-ID: <44EC7B9E.2020709@isode.com> Date: Wed, 23 Aug 2006 17:00:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Kitten , ietf-sasl@imc.org, Nicolas Williams Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Sam Hartman wrote: >A sasl mechanism spec SHOULd NOT make requirements on application >protocol specs. > > This is one of the reasons why I don't like the last sentence proposed by Nico. Is "application" means "protocol", the sentence violates the SHOULD NOT. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvcN-0005Ih-H1; Wed, 23 Aug 2006 12:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvcM-0005Ia-Ed for kitten@ietf.org; Wed, 23 Aug 2006 12:30:14 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvcI-0005Zh-Pp for kitten@ietf.org; Wed, 23 Aug 2006 12:30:14 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NGU9xi019642 for ; Wed, 23 Aug 2006 09:30:09 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NGPrPm005326 for ; Wed, 23 Aug 2006 10:25:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NGU87G015461; Wed, 23 Aug 2006 11:30:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NGU6wD015460; Wed, 23 Aug 2006 11:30:06 -0500 (CDT) Date: Wed, 23 Aug 2006 11:30:06 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060823163006.GV10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu References: <20060823131138.GU10208@binky.Central.Sun.COM> <200608231455.QAA20092@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608231455.QAA20092@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Wed, Aug 23, 2006 at 04:55:38PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Wed, Aug 23, 2006 at 02:56:58PM +0200, Martin Rex wrote: > > > There seems to be a misunderstanding. > > > > > > An application doesn't need to know the slightest about a gssapi > > > mechanism and the nametypes it supports. > > > > But application protocol specs can and do specify what name types to > > use. Think of GS1 as part of the application. > > As far as GSS-API is concerned, the most what an application protocol > could do is recommendation. There is no mandatory to implement > nametype, so applications cannot mandate one, either. I think this is a bit expansive. Mandating specific name types can be expected to constrain the set of applicable mechanisms, and that's about it. > Hostbased service names canonicalized through insecure DNS > is even worse than the weak endpoint identification > performed by Web Browsers when using HTTPS. There are ways to do hostname canonicalization securely (namely: do no DNS lookups, only append a pre-configured domainname to hostnames that don't appear to be fully qualified). If you want DNS-style search lists (I think users are used to it and expect it) then it gets a bit more complex. > The ssh leap-of-faith is much better in this respect, because it > realizes the underlying problem and (a) suggests to perform > out-of-band endpoint verification on first encounter and > (b) memorizes user-acknowledged endpoint identification and > enforces future transformations to come to the exact same result. But leap-of-faith is just that -- taking a leap of faith. For hostname canonicalization it happens to be a lot less iffy than for ssh server public keys because names are a lot more likely to be meaningful to users than public key fingerprints. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:33:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfL-0006XX-Vn; Wed, 23 Aug 2006 12:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfL-0006XR-3j for kitten@ietf.org; Wed, 23 Aug 2006 12:33:19 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvfJ-0006Fn-PY for kitten@ietf.org; Wed, 23 Aug 2006 12:33:19 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NGXFou008178 for ; Wed, 23 Aug 2006 10:33:15 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NGSx64006907 for ; Wed, 23 Aug 2006 10:28:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NGXE4g015468; Wed, 23 Aug 2006 11:33:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NGXEsA015467; Wed, 23 Aug 2006 11:33:14 -0500 (CDT) Date: Wed, 23 Aug 2006 11:33:14 -0500 From: Nicolas Williams To: Alexey Melnikov Message-ID: <20060823163313.GW10208@binky.Central.Sun.COM> Mail-Followup-To: Alexey Melnikov , Kitten , ietf-sasl@imc.org, Sam Hartman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EC70A7.8040809@isode.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Kitten , Sam Hartman , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Wed, Aug 23, 2006 at 04:13:43PM +0100, Alexey Melnikov wrote: > Nicolas Williams wrote: > > >If there's any way to insert text into draft-ietf-sasl-gssapi about this > >then I would opt for that, though it should not mention domain-based > >name types specifically. > > > BTW, DIGEST-MD5 already allows for domain-based names. Oh! I wish the base SASL spec talked about this sort of thing... > > Applications should specify what alternate name types may be > > used and in what circumstances. > > > > > Is this a requirement on implementations or protocol specs? Application protocol specs. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfk-0006bj-5X; Wed, 23 Aug 2006 12:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvfj-0006be-9C for kitten@ietf.org; Wed, 23 Aug 2006 12:33:43 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvfh-0006Pj-Vc for kitten@ietf.org; Wed, 23 Aug 2006 12:33:43 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NGXfLn023512 for ; Wed, 23 Aug 2006 10:33:41 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NGTPOk007081 for ; Wed, 23 Aug 2006 10:29:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NGXfXb015477; Wed, 23 Aug 2006 11:33:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NGXfqU015476; Wed, 23 Aug 2006 11:33:41 -0500 (CDT) Date: Wed, 23 Aug 2006 11:33:41 -0500 From: Nicolas Williams To: Alexey Melnikov Message-ID: <20060823163340.GX10208@binky.Central.Sun.COM> Mail-Followup-To: Alexey Melnikov , Kitten , ietf-sasl@imc.org, Sam Hartman References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44EC773D.5010705@isode.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Kitten , Sam Hartman , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Wed, Aug 23, 2006 at 04:41:49PM +0100, Alexey Melnikov wrote: > Alexey Melnikov wrote: > > >Nicolas Williams wrote: > > > >> Applications should specify what alternate name types may be > >> used and in what circumstances. > > > >Is this a requirement on implementations or protocol specs? > > Also, is this a normative statement or informative? Normative, like the text in RFC4422, section 4. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvh2-0006ok-A5; Wed, 23 Aug 2006 12:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvh1-0006of-As for kitten@ietf.org; Wed, 23 Aug 2006 12:35:03 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvh0-0006gM-21 for kitten@ietf.org; Wed, 23 Aug 2006 12:35:03 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NGZ1Xs009618 for ; Wed, 23 Aug 2006 10:35:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NGUkOs007912 for ; Wed, 23 Aug 2006 10:30:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NGZ1mZ015486; Wed, 23 Aug 2006 11:35:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NGZ1C5015485; Wed, 23 Aug 2006 11:35:01 -0500 (CDT) Date: Wed, 23 Aug 2006 11:35:01 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060823163500.GY10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Alexey Melnikov , Kitten , ietf-sasl@imc.org References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Kitten , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Wed, Aug 23, 2006 at 11:59:24AM -0400, Sam Hartman wrote: > A sasl mechanism spec SHOULd NOT make requirements on application > protocol specs. The text I proposed had a requirement only for applications that would use name types other than the default. I.e., apps need do nothing unless they want to use domain-based names. But we could work the requirement out. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:42:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvoH-0003VI-Sy; Wed, 23 Aug 2006 12:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFvoG-0003VC-Fe for kitten@ietf.org; Wed, 23 Aug 2006 12:42:32 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFvoF-0008Av-3Q for kitten@ietf.org; Wed, 23 Aug 2006 12:42:32 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA13646; Wed, 23 Aug 2006 18:40:48 +0200 (MESZ) From: Martin Rex Message-Id: <200608231637.SAA21362@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 23 Aug 2006 18:37:25 +0200 (MET DST) In-Reply-To: <20060823131138.GU10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 23, 6 08:11:39 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Wed, Aug 23, 2006 at 02:56:58PM +0200, Martin Rex wrote: > > There seems to be a misunderstanding. > > > > An application doesn't need to know the slightest about a gssapi > > mechanism and the nametypes it supports. > > But application protocol specs can and do specify what name types to > use. Think of GS1 as part of the application. Host-based and domain-based service names are the only names for which an application or protocol might perform an endpoint identification instead of an authentication by deriving the acceptors identity from the network location given by the user or caller. For other names, it will be generally impossible to substitute the authentication with an endpoint identification. If a mutual authentication is to be performed, then the user or caller must know and provide the identity of the acceptor to gss_init_sec_context(). Nametype (OIDs) are difficult to memorize and enter by a user and nametype OIDs may even be non-portable among independent implementations of the same gssapi mechanism -- e.g. with rfc-2025 (SPKM) Therefore GSS-API v2 permits the use of a NULL nametype OID when importing a printable name, which is a request for a mechanisms "native" nametype -- for SPKM usually some kind of printable distinguished name. Applications that call gss-api ought to provide a means for the user to provide the name that is passed to gss_init_sec_context() and is entirely seperate from the network location parameters. Applications should also provide a means to pass along a nametype with the name, but they should not require a nametype and they should not assume/attach a specific nametype (other than NULL) either. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 12:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFw03-0000Hi-7V; Wed, 23 Aug 2006 12:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFw01-0000Hc-KR for kitten@ietf.org; Wed, 23 Aug 2006 12:54:41 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFw00-0001fN-D0 for kitten@ietf.org; Wed, 23 Aug 2006 12:54:41 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 951B3E00C0; Wed, 23 Aug 2006 12:54:36 -0400 (EDT) From: Sam Hartman To: Alexey Melnikov References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> <20060823163500.GY10208@binky.Central.Sun.COM> Date: Wed, 23 Aug 2006 12:54:36 -0400 In-Reply-To: <20060823163500.GY10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 23 Aug 2006 11:35:01 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Kitten , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Aug 23, 2006 at 11:59:24AM -0400, Sam Hartman Nicolas> wrote: >> A sasl mechanism spec SHOULd NOT make requirements on >> application protocol specs. Nicolas> The text I proposed had a requirement only for Nicolas> applications that would use name types other than the Nicolas> default. I.e., apps need do nothing unless they want to Nicolas> use domain-based names. And so I'd prefer it be non-normative. The normative requirement should be stated in terms of the SASL mechanism: The client MAY use another name type if it knows the server will support it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 13:27:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwVR-0008Q0-Nw; Wed, 23 Aug 2006 13:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwVQ-0008Pt-Np for kitten@ietf.org; Wed, 23 Aug 2006 13:27:08 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwVO-0002oA-4e for kitten@ietf.org; Wed, 23 Aug 2006 13:27:08 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NHR56j024619 for ; Wed, 23 Aug 2006 10:27:05 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NHMnQm003545 for ; Wed, 23 Aug 2006 11:22:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NHR4KD015655; Wed, 23 Aug 2006 12:27:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NHR4EH015654; Wed, 23 Aug 2006 12:27:04 -0500 (CDT) Date: Wed, 23 Aug 2006 12:27:04 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060823172650.GZ10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , jhutz@cmu.edu, kitten@ietf.org, hartmans-ietf@mit.edu 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: b280b4db656c3ca28dd62e5e0b03daa8 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: More side issues (Re: Working Group Last Call: GSS-API Domain-Based Service Names and) 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 [New thread. I'm breaking threading.] On Wed, Aug 23, 2006 at 06:37:25PM +0200, Martin Rex wrote: > Host-based and domain-based service names are the only names for > which an application or protocol might perform an endpoint > identification instead of an authentication by deriving the > acceptors identity from the network location given by the > user or caller. In all cases when the initiator provides a target_name it must have come from somewhere, and user input is just fine. Just because historically Kerberos V mechanism implementations have performed (and some still do) insecure hostname canonicalization does not mean that using user-provided hostnames is inherently insecure. (Or were you making a different point?) > For other names, it will be generally impossible to substitute > the authentication with an endpoint identification. I guess so. I don't have much experience with acceptors that lack hostbased service names or other well-known/formed names (think "kadmin/admin"). > If a mutual authentication is to be performed, then the > user or caller must know and provide the identity of the > acceptor to gss_init_sec_context(). Yes. > Nametype (OIDs) are difficult to memorize and enter by a user and > nametype OIDs may even be non-portable among independent implementations > of the same gssapi mechanism -- e.g. with rfc-2025 (SPKM) That's why we have GSS_C_NT_* symbols associated with name type OIDs. Yes, I know, given a pluggable GSS-API implementation you could not count on new name type OIDs being present in the header file (assuming C bindings) that comes with the pluggable GSS-API framework you're using and yet the name type may be available through specific mechanism plug-ins. In such cases portable applications have a high incentive to hardcode the constant octet strings whose values are the encoded OIDs for the desired name types. I'm not sure I feel too much sympathy -- we're talking about constant strings. > Therefore GSS-API v2 permits the use of a NULL nametype > OID when importing a printable name, which is a request for > a mechanisms "native" nametype -- for SPKM usually some kind > of printable distinguished name. We are aware. SPKM might want to deal with subjectAltNames, BTW. > Applications that call gss-api ought to provide a means for the user > to provide the name that is passed to gss_init_sec_context() and > is entirely seperate from the network location parameters. I doubt many users would actually use such a facility, but on principle I agree. > Applications should also provide a means to pass along a nametype > with the name, but they should not require a nametype and they > should not assume/attach a specific nametype (other than NULL) either. Here I don't agree. Standards-Track Internet applications that use the GSS-API have, do, should and will continue to require support for of host-based (and now, I hope, domain-based) service names. They should NOT preclude use of other name types for acceptors, IMO, but it is perfectly legitimate to require support for specific name types -- in some cases it is even legitimate to require use of specific name types. Examples: SSHv2, DNS GSS-TSIG[1], SASL/GS1 and SASL/GS1 applications. Interestingly, neither NFSv4 nor RPCSEC_GSS say a word about the subject (the latter shouldn't, but the former should!). [1] GSS-TSIG doesn't say "host-based service names are required" directly, but strongly implies it. Sigh. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 23 13:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwmg-0000Jo-LG; Wed, 23 Aug 2006 13:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFwmf-0000Jj-CA for kitten@ietf.org; Wed, 23 Aug 2006 13:44:57 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFwmc-0005nA-UT for kitten@ietf.org; Wed, 23 Aug 2006 13:44:57 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NHisTD015166 for ; Wed, 23 Aug 2006 11:44:54 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7NHecvA011176 for ; Wed, 23 Aug 2006 11:40:38 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7NHisM7015668; Wed, 23 Aug 2006 12:44:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7NHisLb015667; Wed, 23 Aug 2006 12:44:54 -0500 (CDT) Date: Wed, 23 Aug 2006 12:44:54 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060823174453.GA10208@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Alexey Melnikov , Kitten , ietf-sasl@imc.org References: <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> <20060823163500.GY10208@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: 8ac499381112328dd60aea5b1ff596ea Cc: Kitten , Alexey Melnikov , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Wed, Aug 23, 2006 at 12:54:36PM -0400, Sam Hartman wrote: > And so I'd prefer it be non-normative. The normative requirement > should be stated in terms of the SASL mechanism: The client MAY use > another name type if it knows the server will support it. Sure. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Aug 24 13:01:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIaH-0007Oy-NV; Thu, 24 Aug 2006 13:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIaG-0007Ot-49 for kitten@ietf.org; Thu, 24 Aug 2006 13:01:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIaE-0001ce-Mf for kitten@ietf.org; Thu, 24 Aug 2006 13:01:36 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 24 Aug 2006 18:01:22 +0100 Message-ID: <44EDDB29.4010303@isode.com> Date: Thu, 24 Aug 2006 18:00:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams References: <44E28500.1000605@secure-endpoints.com> <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EB4374.1060605@secure-endpoints.com> <44EC31AB.80506@isode.com> <20060823131007.GT10208@binky.Central.Sun.COM> In-Reply-To: <20060823131007.GT10208@binky.Central.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Kitten , Sam Hartman , ietf-sasl@imc.org Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Nicolas Williams wrote: >On Wed, Aug 23, 2006 at 11:44:59AM +0100, Alexey Melnikov wrote: > > >>Jeffrey Altman wrote: >> >>> The question then appears to me to be more >>>general than the question of whether or not SASL-GSS-1 or SASL-GSS-2 >>>must be updated. Instead it appears to be "does SASL support the >>>concept of authentication with domain-based names at all?" >>> >>> >>When integrating SASL into SMTP, IMAP and LDAP servers I always assumed >>that the answer to this question was "yes". >> >> >Well, RFC4422 does require that a service name always be involved >(section 4, item (1)). > Yes, however mechanisms are free not to use it and many mechanisms don't. >But it doesn't actually discuss the structure of >server names -- it doesn't even mention hostnames or domainnames. > > I think this is a mechanism specific issue. But I might be convinced that I am wrong. Anyway, I think GSS1 should be updated to allow for other name types. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 25 13:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfJ2-0002gD-5H; Fri, 25 Aug 2006 13:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfJ1-0002fl-C5 for kitten@ietf.org; Fri, 25 Aug 2006 13:17:19 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfIy-000349-UJ for kitten@ietf.org; Fri, 25 Aug 2006 13:17:19 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 25 Aug 2006 18:17:02 +0100 Message-ID: <44EF305C.3000603@isode.com> Date: Fri, 25 Aug 2006 18:16:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Nicolas Williams References: <20060821222225.GI10208@binky.Central.Sun.COM> <20060822155201.GX10208@binky.Central.Sun.COM> <20060822172418.GD10458@binky.Central.Sun.COM> <44EC70A7.8040809@isode.com> <44EC773D.5010705@isode.com> <20060823163500.GY10208@binky.Central.Sun.COM> <20060823174453.GA10208@binky.Central.Sun.COM> In-Reply-To: <20060823174453.GA10208@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Kitten , ietf-sasl@imc.org, Sam Hartman Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type 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 Nicolas Williams wrote: >On Wed, Aug 23, 2006 at 12:54:36PM -0400, Sam Hartman wrote: > > >>And so I'd prefer it be non-normative. The normative requirement >>should be stated in terms of the SASL mechanism: The client MAY use >>another name type if it knows the server will support it. >> >> > >Sure. > > Ok, I've added the following text: 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. I.e. I removed the last sentence you've proposed. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 25 16:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGiIg-0003d5-Px; Fri, 25 Aug 2006 16:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGiIg-0003d0-8D for kitten@ietf.org; Fri, 25 Aug 2006 16:29:10 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGiIc-000231-Os for kitten@ietf.org; Fri, 25 Aug 2006 16:29:10 -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 k7PKT5Hw000268 for ; Fri, 25 Aug 2006 14:29:06 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7PKT5mP003687 for ; Fri, 25 Aug 2006 14:29:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7PKS5la029663; Fri, 25 Aug 2006 15:28:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7PKRdCC029657; Fri, 25 Aug 2006 15:27:39 -0500 (CDT) Date: Fri, 25 Aug 2006 15:27:39 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060825202738.GW10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Alexey Melnikov , kitten@ietf.org, ietf-sasl@imc.org, hartmans-ietf@mit.edu References: <44EF305C.3000603@isode.com> <200608251756.TAA18643@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608251756.TAA18643@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, Alexey Melnikov , ietf-sasl@imc.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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, Aug 25, 2006 at 07:56:33PM +0200, Martin Rex wrote: > There seems to be a significant misunderstanding in how GSS-API works. I interpret your post as saying, in so many words, that the right thing to do is to speak of "host-based service" not the specific name type GSS_C_NT_HOSTBASED_SERVICE in prescribing what an initiator application ought to do, since, after all, the application could use mechanism-specific equivalents. Is that correct? If so I agree but I am not sure that I care. Perhaps if you suggested new text? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 25 17:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjEs-0006n2-HW; Fri, 25 Aug 2006 17:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGjEr-0006mw-Mi for kitten@ietf.org; Fri, 25 Aug 2006 17:29:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGgL4-0007VT-PJ for kitten@ietf.org; Fri, 25 Aug 2006 14:23:30 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGfv7-0002iY-Tb for kitten@ietf.org; Fri, 25 Aug 2006 13:56:44 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA07221; Fri, 25 Aug 2006 19:56:33 +0200 (MESZ) From: Martin Rex Message-Id: <200608251756.TAA18643@uw1048.wdf.sap.corp> To: alexey.melnikov@isode.com (Alexey Melnikov) Date: Fri, 25 Aug 2006 19:56:33 +0200 (MET DST) In-Reply-To: <44EF305C.3000603@isode.com> from "Alexey Melnikov" at Aug 25, 6 06:16:12 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: -1.8 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: kitten@ietf.org, hartmans-ietf@mit.edu, ietf-sasl@imc.org, Nicolas.Williams@sun.com Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Alexey Melnikov wrote: > > Ok, I've added the following text: > 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. > > I.e. I removed the last sentence you've proposed. There seems to be a significant misunderstanding in how GSS-API works. The nametype used by the client identifies the encoding (syntax&semantics) of the printable name used by the client to authenticate the server (in case of mutual authentication), or use as a hint to the gssapi about the target (acceptor) for mechanisms such as Kerberos 5, even with unidirectional authentication. So this nametype is something that the local gssapi mechanism of the client needs to understand&support, and the (human) user of the client needs to use the respective syntax&semantics for the accompanying printable name. i.e. an SSH client using Kerberos 5 gssapi for authentication could use network location (hostabc.f.q.d.n,tcp,port22) plus a) the SSH client could automagically assert /---- nametype ------\ /---- printable name ----\ hostbased service name "ssh@hostabc.f.q.d.n" to identify the acceptor b) or the user might explictly supply hostbased service name "ssh@hostabc.f.q.d.n" to authenticate or the acceptor c) or the user might explictly supply kerberos principal name "host/hostabc.f.q.d.n@SOME.REALM" to authenticate or the acceptor An SSH client using an SPKM gssapi for authentication will usually get an error message when trying to use hostbased service names, and have to explicitly supply a name: NULL name type "CN=hostabc.f.q.d.n,UID=ssh,O=Foo Inc.,C=US" or proprietary name type "CN=hostabc.f.q.d.n,UID=ssh,O=Foo Inc.,C=US" In general, the server never gets to see what kind of name and nametype the client used to create the gss_name_t "target_name" that it passes to gss_init_sec_context(). (none of the gssapi mechanisms that I know passes this name along. Kerberos 5 passes it to the KDC for acquiring a (service) ticket, SPKM-like mechanisms use it to verify the subject DName of the acceptor from the acceptors certificate that arrives with the second context level token (the first reply token sent from acceptor back to initiator). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 25 20:05:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlfd-0004aF-6C; Fri, 25 Aug 2006 20:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGldX-0004E7-0p for kitten@ietf.org; Fri, 25 Aug 2006 20:02:55 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlZC-0002iA-7o for kitten@ietf.org; Fri, 25 Aug 2006 19:58:27 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA16764; Sat, 26 Aug 2006 01:58:20 +0200 (MESZ) From: Martin Rex Message-Id: <200608252358.BAA26981@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Sat, 26 Aug 2006 01:58:19 +0200 (MET DST) In-Reply-To: <20060825202738.GW10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 25, 6 03:27:39 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: kitten@ietf.org, alexey.melnikov@isode.com, ietf-sasl@imc.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Fri, Aug 25, 2006 at 07:56:33PM +0200, Martin Rex wrote: > > There seems to be a significant misunderstanding in how GSS-API works. > > I interpret your post as saying, in so many words, that the right thing > to do is to speak of "host-based service" not the specific name type > GSS_C_NT_HOSTBASED_SERVICE in prescribing what an initiator application > ought to do, since, after all, the application could use > mechanism-specific equivalents. > > Is that correct? > > If so I agree but I am not sure that I care. Perhaps if you suggested > new text? The text I didn't like talks about "what the server supports", but that is inappropriate when talking about the target_name used by the initiator. : 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 The server might be using SPKM from vendor a (which does NOT support the hostbased service nametype), use credentials with an X.509 that from a CA that issued it with a special naming convention. Now if the client is using a different SPKM implementation that implement GSS_C_NT_HOSTBASED_SERVICE and performs some sort of endpoint identification (instead of an authentication) as proposed for SPKM3, then you would have the situation that the server doesn't support hostbased service names, and still the client might succeed in using it. In a different (Kerberos-based) installation, an SSH-Server might be running with a hostbased service name and a special ssh/hostabc.f.q.d.n principal and a service mapping function ssh@somehost -> ssh/somehost.f.q.d.n while the client might be using a different service mapping ssh@somehost -> host/somehost.f.q.d.n. This will cause the client to fail the authentication when trying to use the hostbased service name. But if the client uses ssh/somehost.f.q.d.n with the Kerberos principal nametype directly the context establishment will succeed. So whether a hostbased service name can be used depends primarily on (a) does the initiators gssapi mechanism implementation implement this nametype (b) does the initiators gssapi mechanism implementation's service mapping function transform a given hostbased service name to the correct principal name as used by the server (this might be a local configuration issue). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Aug 25 23:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGofL-00076H-8i; Fri, 25 Aug 2006 23:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGofJ-00074R-Oe for kitten@ietf.org; Fri, 25 Aug 2006 23:16:57 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGofF-00047o-OK for kitten@ietf.org; Fri, 25 Aug 2006 23:16:57 -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 k7Q3Gr8a002883 for ; Fri, 25 Aug 2006 21:16:53 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7Q3GlGR005209 for ; Fri, 25 Aug 2006 21:16:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7Q3FpD3020271; Fri, 25 Aug 2006 22:15:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7Q3FdV0020270; Fri, 25 Aug 2006 22:15:39 -0500 (CDT) Date: Fri, 25 Aug 2006 22:15:39 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060826031538.GH10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , alexey.melnikov@isode.com, kitten@ietf.org, ietf-sasl@imc.org, hartmans-ietf@mit.edu References: <20060825202738.GW10208@binky.Central.Sun.COM> <200608252358.BAA26981@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608252358.BAA26981@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: kitten@ietf.org, alexey.melnikov@isode.com, ietf-sasl@imc.org, hartmans-ietf@mit.edu Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and 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 Sat, Aug 26, 2006 at 01:58:19AM +0200, Martin Rex wrote: > The text I didn't like talks about "what the server supports", but that > is inappropriate when talking about the target_name used by the initiator. OK, it really should be something like "what the server has acceptor credentials for." > Now if the client is using a different SPKM implementation that > implement GSS_C_NT_HOSTBASED_SERVICE and performs some sort of > endpoint identification (instead of an authentication) as proposed for > SPKM3, then you would have the situation that the server doesn't > support hostbased service names, and still the client might succeed > in using it. Because it has credentials that authenticate the hostbased service that the client wanted. The details of how that happens are not relevant here. > In a different (Kerberos-based) installation, an SSH-Server might be running > with a hostbased service name and a special ssh/hostabc.f.q.d.n principal > and a service mapping function ssh@somehost -> ssh/somehost.f.q.d.n > [...] A server that did this could not interoperate with a client that merely followed RFC4462 and didn't provide an option by which the user could provide an alternate service name. This is why it's important for our specifications to tell us about acceptor naming. Even if the Kerberos V GSS-API mechanism allowed the acceptor to tell the initiator what its name is (and we could define a new version of the krb5 mechanisms, with a new OID, that did this), the client would still have to know to use GSS_C_NO_NAME and then tell the user what name was authenticated and ask if that's OK, or otherwise authorize the authenticated acceptor name to the actual server/whatever name provided by the client. These are instructions that have to be provided by the application protocol specific for at the common mode of operation, otherwise we can't have interop. > So whether a hostbased service name can be used depends primarily on > > (a) does the initiators gssapi mechanism implementation implement > this nametype > > (b) does the initiators gssapi mechanism implementation's service > mapping function transform a given hostbased service name to > the correct principal name as used by the server (this might be > a local configuration issue). (c) does the acceptor have acceptor credentials for that name. This is important for mechanisms which, as you point out repeatedly, don't allow the initiator to discover the acceptor's name instead of having to always provide it upfront. Tough. Kerberos V is the interoperable mechanism we have, and hostbased service naming is the interoperable form of server naming. Can we go beyond this? SASL/GS1 is not going to depart from hostbased service naming as the minimum requirement and common name type for interoperability -- though we may add more. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 16:18:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHnYo-0006GN-82; Mon, 28 Aug 2006 16:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHnYl-0006G2-2w; Mon, 28 Aug 2006 16:18:15 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHnYk-0003Xp-Te; Mon, 28 Aug 2006 16:18:15 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D8C5A32900; Mon, 28 Aug 2006 20:18:14 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GHnYk-0006tr-P2; Mon, 28 Aug 2006 16:18:14 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 28 Aug 2006 16:18:14 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org The IESG has received a request from the Simple Authentication and Security Layer WG to consider the following document: - 'The Kerberos V5 ("GSSAPI") SASL mechanism ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-11. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-07.txt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 17:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHowf-0000gM-4z; Mon, 28 Aug 2006 17:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHowe-0000gD-Bw; Mon, 28 Aug 2006 17:47:00 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHowY-00053A-Or; Mon, 28 Aug 2006 17:47:00 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7SLksXX021484; Mon, 28 Aug 2006 15:46:54 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7SLkris014720; Mon, 28 Aug 2006 15:46:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7SLkqbm024196; Mon, 28 Aug 2006 16:46:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7SLkpPV024195; Mon, 28 Aug 2006 16:46:51 -0500 (CDT) Date: Mon, 28 Aug 2006 16:46:51 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060828214650.GR10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , iesg@ietf.org, kitten@ietf.org, ietf-sasl@imc.org References: 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: 4adaf050708fb13be3316a9eee889caa Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, Aug 28, 2006 at 01:39:42PM -0700, Mark Crispin wrote: > > I request consideration of the following changes prior to publication. > > Page 4, first paragraph, please change: > [...] When calling the GSS_Init_sec_context the client > MUST pass the integ_req_flag of TRUE. > to > [...] When calling the GSS_Init_sec_context the client > SHOULD pass the integ_req_flag of TRUE. > > Otherwise, publication of this document would have the effect of declaring > existing deployed software to be non-compliant. I agree that this change > is desirable, but I disagree about retroactively declaring existing > software broken. If the WG feels strongly enough, it'd be alright to have > something in the security considerations saying that earlier versions did > not require the integ_req_flag, but all new implementations ought to have > it and old implementations fixed. Since this is all specific to the Kerberos V GSS-API mechanism I think the value of this flag is irrelevant, so this change should not render any earlier implementations non-compliant in terms of their on-the-wire behaviour. (At least one implementation of the Kerberos V GSS mechanism used to leave out confidentiality protection, but none, to my knowledge, fails to provide MIC and/or wrap tokens when integ_req_flag == false in the call to GSS_Init_sec_context().) > Suggested changes (this is just cosmetic): > > Page 5, second paragraph, change > [...] chan_binding of NULL > to: > [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS > > Similarly for page 7 in the third paragraph of the Security > Considerations. GSS_C_NO_CHANNEL_BINDINGS is only defined in the C bindings of the GSS-API (RFC2744), whereas the base GSS-API specification (RFC2743) uses "NULL" to mean "no channel bindings" (e.g., "...where NULL channel bindings..." and "[w]hen non-NULL channel bindings are provided"). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpI7-0002Nv-Au; Mon, 28 Aug 2006 18:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpHn-00028k-CK; Mon, 28 Aug 2006 18:08:51 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpCJ-0001BJ-Sc; Mon, 28 Aug 2006 18:03:13 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D9732E00C0; Mon, 28 Aug 2006 18:03:16 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: Date: Mon, 28 Aug 2006 18:03:16 -0400 In-Reply-To: (Mark Crispin's message of "Mon, 28 Aug 2006 13:39:42 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: I don't think this change will create an interoperability problem. gss_wrap only works if the context has integrity. I believe that it is impossible for an implementation to interoperate with RFC 2222 or this spec unless integrity is available in the context as both this spec and RFC 2222 require gss_wrap to work. The reason most everything works in practice is that GSS implementations tend to provide integrity even when it is not explicitly requested. I required this change from the working group and do not think I'm willing to take the document to the IESG unless integ_flag remains a must. I am willing to listen to your arguments though and would be especially interested in cases where this change creates a wire protocol change. - --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:45:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpr4-0005xR-9K; Mon, 28 Aug 2006 18:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpr2-0005x5-IY; Mon, 28 Aug 2006 18:45:16 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpqz-0000R4-0H; Mon, 28 Aug 2006 18:45:16 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7SMjCOW019474; Mon, 28 Aug 2006 15:45:12 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7SMjBk7026188; Mon, 28 Aug 2006 16:45:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7SMjAZS024339; Mon, 28 Aug 2006 17:45:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7SMjANj024338; Mon, 28 Aug 2006 17:45:10 -0500 (CDT) Date: Mon, 28 Aug 2006 17:45:10 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060828224510.GT10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , iesg@ietf.org, kitten@ietf.org, ietf-sasl@imc.org References: <20060828214650.GR10208@binky.Central.Sun.COM> <20060828220819.GS10208@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, Aug 28, 2006 at 03:33:45PM -0700, Mark Crispin wrote: > On Mon, 28 Aug 2006, Nicolas Williams wrote: > >>>Since this is all specific to the Kerberos V GSS-API mechanism I think > >>>the value of this flag is irrelevant, so this change should not render > >>>any earlier implementations non-compliant in terms of their on-the-wire > >>>behaviour. > >>In that case, it's all the more reason to use SHOULD instead of MUST. > >Why? MUST would be correct and happens not to break earlier > >implementations. What's the downside? I don't see any. See below. > > Joe Mooch GSSAPI replaces MIT GSSAPI. Mooch GSSAPI suddenly breaks all my > installations. > > Joe Mooch points the finger of blame on me for not following a > specification that was issued years *AFTER* the code was released. Your implementation would break regardless of what the new doc says, so Joe Mooch and you would lose if MIT did what you posit. It wouldn't break if your implementation followed the new spec, that's true, but your old implementation's compliance would hardly make Joe Mooch feel any better, particularly if MIT could claim compliance for the change that you posit. You'd be on the hook either way. No existing GSS-API multi-mechanism library implementor should do what you posit. Yes, it's possible, it's just not probable, not remotely probable, and, anyways, your claims of compliance would do nothing for your users. > But the problem is that if this were to pass, the egg would be on my face, > even though I implemented RFC 2222 in good faith according to the > specification. I don't agree. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpvg-0008Hy-UQ; Mon, 28 Aug 2006 18:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpvf-0008Hd-2a; Mon, 28 Aug 2006 18:50:03 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpvd-0001EU-N2; Mon, 28 Aug 2006 18:50:03 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7SMo1IH026115; Mon, 28 Aug 2006 16:50:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7SMo0nt027583; Mon, 28 Aug 2006 16:50:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7SMo08X024391; Mon, 28 Aug 2006 17:50:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7SMo0Ud024390; Mon, 28 Aug 2006 17:50:00 -0500 (CDT) Date: Mon, 28 Aug 2006 17:50:00 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060828224959.GU10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , Sam Hartman , iesg@ietf.org, kitten@ietf.org, ietf-sasl@imc.org References: 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, Aug 28, 2006 at 03:21:18PM -0700, Mark Crispin wrote: > On Mon, 28 Aug 2006, Sam Hartman wrote: > >I don't think this change will create an interoperability problem. > >gss_wrap only works if the context has integrity. I believe that it > >is impossible for an implementation to interoperate with RFC 2222 or > >this spec unless integrity is available in the context as both this > >spec and RFC 2222 require gss_wrap to work. > > The "I believe" part scares me. Are you kidding? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpx0-0000SK-W2; Mon, 28 Aug 2006 18:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHnvX-00032P-Lx; Mon, 28 Aug 2006 16:41:47 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHnvW-00070f-B0; Mon, 28 Aug 2006 16:41:47 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SKfj74001336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 13:41:45 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SKfifj028117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 13:41:45 -0700 Date: Mon, 28 Aug 2006 13:39:42 -0700 (Pacific Daylight Time) From: Mark Crispin To: iesg@ietf.org In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Mon, 28 Aug 2006 18:51:25 -0400 Cc: kitten@ietf.org, ietf-sasl@imc.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 I request consideration of the following changes prior to publication. Page 4, first paragraph, please change: [...] When calling the GSS_Init_sec_context the client MUST pass the integ_req_flag of TRUE. to [...] When calling the GSS_Init_sec_context the client SHOULD pass the integ_req_flag of TRUE. Otherwise, publication of this document would have the effect of declaring existing deployed software to be non-compliant. I agree that this change is desirable, but I disagree about retroactively declaring existing software broken. If the WG feels strongly enough, it'd be alright to have something in the security considerations saying that earlier versions did not require the integ_req_flag, but all new implementations ought to have it and old implementations fixed. Suggested changes (this is just cosmetic): Page 5, second paragraph, change [...] chan_binding of NULL to: [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS Similarly for page 7 in the third paragraph of the Security Considerations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpx1-0000Td-8h; Mon, 28 Aug 2006 18:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHptb-0007Xj-Ak; Mon, 28 Aug 2006 18:47:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpii-0007fp-Cl; Mon, 28 Aug 2006 18:36:40 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHpVq-0003iG-LG; Mon, 28 Aug 2006 18:23:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SMNLOM006042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 15:23:21 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SMNLCl025674 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 15:23:21 -0700 Date: Mon, 28 Aug 2006 15:21:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.5 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 28 Aug 2006 18:51:25 -0400 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Sam Hartman wrote: > I don't think this change will create an interoperability problem. > gss_wrap only works if the context has integrity. I believe that it > is impossible for an implementation to interoperate with RFC 2222 or > this spec unless integrity is available in the context as both this > spec and RFC 2222 require gss_wrap to work. The "I believe" part scares me. > The reason most everything works in practice is that GSS > implementations tend to provide integrity even when it is not > explicitly requested. I implemented according to RFC 2222. RFC 2222 did not require integ_flag to be set, and was silent on the issue. Upon seeing the Last Call, I saw this change (which I did not see listed as being a change from RFC 2222), and made the change to the development version my code. But this does not change the installed base. > I required this change from the working group and do not think I'm > willing to take the document to the IESG unless integ_flag remains a > must. Can we do some sort of compromise, such as these stipulations: All new client implementations MUST set integ_flag. RFC 2222 implementations were not required to set integ_flag. This was based upon an implicit assumption that clients could assume integrity even when not explicitly requested. This assumption is hereby deprecated. Because RFC 2222 client authors were not warned about this implicit assumption, GSSAPI implementations MUST implicitly set integ_flag if the client does not set it. [This renders the assumption into a MUST even though it is deprecated.] > I am willing to listen to your arguments though and would be > especially interested in cases where this change creates a wire > protocol change. The thing is, I don't know. There are multiple GSSAPI implementations. You're asking me to put faith that nothing will happen to cause an 8 year old RFC 2222 compliant implementation to break over the wire. I'm not trying to block the change; I'm just trying to ameliorate a potential bad consequence. Traditionally, the IETF has declined to break an installed base that was implemented in good faith. I hope that this tradition is maintained. I also hope that we are not in technical disagreement, just in wordsmithing. Thanks, -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 18:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpx1-0000Sa-3q; Mon, 28 Aug 2006 18:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHphu-0000mG-H7; Mon, 28 Aug 2006 18:35:50 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpht-0007bY-3U; Mon, 28 Aug 2006 18:35:50 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SMZm3X015149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 15:35:48 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SMZlaP029082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 15:35:47 -0700 Date: Mon, 28 Aug 2006 15:33:45 -0700 (Pacific Daylight Time) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060828220819.GS10208@binky.Central.Sun.COM> Message-ID: References: <20060828214650.GR10208@binky.Central.Sun.COM> <20060828220819.GS10208@binky.Central.Sun.COM> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 28 Aug 2006 18:51:25 -0400 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Nicolas Williams wrote: >>> Since this is all specific to the Kerberos V GSS-API mechanism I think >>> the value of this flag is irrelevant, so this change should not render >>> any earlier implementations non-compliant in terms of their on-the-wire >>> behaviour. >> In that case, it's all the more reason to use SHOULD instead of MUST. > Why? MUST would be correct and happens not to break earlier > implementations. What's the downside? I don't see any. See below. Joe Mooch GSSAPI replaces MIT GSSAPI. Mooch GSSAPI suddenly breaks all my installations. Joe Mooch points the finger of blame on me for not following a specification that was issued years *AFTER* the code was released. >> However, a change in the GSSAPI shared library could, without change to >> the client code itself, render a client that fails to set integ_req_flag >> non-compliant over-the-wire. So we shouldn't count upon this. > I think that would be really wrong on the part of the implementor That's the problem. I've had 30+ years of bad experience with "it would be really wrong [so don't worry about it happening]" that subsequently happened and caused horrendous problems. > but > even assuming it's possible I really doubt that this could happen to old > implementations of the SASL "GSSAPI" mechanism, and if it did and they > had not set integ_req_flag == TRUE then they would, in fact, fail to > operate. But the problem is that if this were to pass, the egg would be on my face, even though I implemented RFC 2222 in good faith according to the specification. The IETF once had a tradition of not pulling the rug out from implementors who followed the specification in good faith. Is this now abolished? > Protocol-wise this change is a no-op, so I fail to see how old > implementations become non-compliant -- you'd have to trace their > execution to determine that they are non-compliant w.r.t. API use. That MAY be the case with the GSSAPI implementations that are KNOWN to you (and me). But there is no surety that this is, or will be, the case. I agree that there seems to be no technical problem now; but can't we PLEASE come up with suitable wordsmithing to preclude possible problems in the future? If RFC 2222 compatibility can not be maintained, then please change the mechanism name to GSSAPIrev1 so that any negotiation using the name GSSAPI will be known to comply with RFC 2222. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 19:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqC4-00006g-Ow; Mon, 28 Aug 2006 19:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqC3-00006P-2p; Mon, 28 Aug 2006 19:06:59 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqC1-00037w-Mb; Mon, 28 Aug 2006 19:06:59 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SN6umq032014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 16:06:56 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SN6uPn012416 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 16:06:56 -0700 Date: Mon, 28 Aug 2006 16:04:53 -0700 (Pacific Daylight Time) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060828224510.GT10208@binky.Central.Sun.COM> Message-ID: References: <20060828214650.GR10208@binky.Central.Sun.COM> <20060828220819.GS10208@binky.Central.Sun.COM> <20060828224510.GT10208@binky.Central.Sun.COM> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Nicolas Williams wrote: > Your implementation would break regardless of what the new doc says, so > Joe Mooch and you would lose if MIT did what you posit. Yes, but the difference is that I can point at RFC 2222, and say that I comply with RFC 2222. If you make a change to GSSAPI that breaks an RFC 2222 compliant implementation of the GSSAPI SASL method, the onus is on you. > It wouldn't break if your implementation followed the new spec, that's > true, but your old implementation's compliance would hardly make Joe > Mooch feel any better, particularly if MIT could claim compliance for > the change that you posit. You'd be on the hook either way. Not at all, because my code complies with RFC 2222 and RFC 2222 says nothing about integ_flag. As currently written, this change retroactively labels RFC 2222 compliant implementations as non-compliant. Maybe my memory is faulty, but I can't recall a case where the IETF has done this to implementations written in good faith to older versions of the standards. In fact, I remember an IETF that has bent over backwards to avoid doing such a thing, even to the point of absurdity (as can be seen in USEFOR and NNTPEXT). > No existing GSS-API multi-mechanism library implementor should do what > you posit. Yes, it's possible, it's just not probable, not remotely > probable, and, anyways, your claims of compliance would do nothing for > your users. I know from past experience that SUN objects vigorously when a proposal has the effect of putting it in such a position. You shouldn't expect me to be sanguine. All that is necessary is to document that: 1) RFC 2222 was silent on the matter of integ_flag. 2) RFC 2222 compliant implementations could have omitted integ_flag. 3) This worked because GSSAPI implementations implicitly set integ_flag even if omitted. 4) Clients that followed RFC 2222 assumed (3), but the implementors of those clients may not have known that they did so. 5) The ability of a client to assume (3) is deprecated. 6) To preserve RFC 2222 compatibility, GSSAPI implementations MUST do (3) even though its assumption is deprecated. 7) As a consequence of (5), RFC 2222 implementors are on notice to add integ_flag in updates. Based upon what y'all have said, none of the above changes anyone's code, other than putting RFC 2222 implementors on notice that they need to add the setting of integ_flag. I have already done so. But it prevents a possible future problem, one you categorize as "not remotely probable". If this is just a bit of wordsmithing and not a technical change, why not do it? What purpose is served by creating a possible future problem that is "not remotely probable"? Isn't the point of a Last Call to uncover such issues, and resolve them? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 19:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqGL-0002bG-HA; Mon, 28 Aug 2006 19:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqGK-0002aU-2g; Mon, 28 Aug 2006 19:11:24 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqGI-0003yD-N0; Mon, 28 Aug 2006 19:11:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SNBL7g025049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 16:11:22 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SNBLbB006306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 16:11:21 -0700 Date: Mon, 28 Aug 2006 16:09:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060828224959.GU10208@binky.Central.Sun.COM> Message-ID: References: <20060828224959.GU10208@binky.Central.Sun.COM> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Nicolas Williams wrote: >>> I don't think this change will create an interoperability problem. >>> gss_wrap only works if the context has integrity. I believe that it >>> is impossible for an implementation to interoperate with RFC 2222 or >>> this spec unless integrity is available in the context as both this >>> spec and RFC 2222 require gss_wrap to work. >> The "I believe" part scares me. > Are you kidding? No, I am not kidding. "I believe" implies "I don't know". The past 30+ years of Internet protocol development history are littered with instances in which people *believed* (in good faith) that something was the case, convinced others to act (in good faith) on the presumption that those beliefs were correct. Much later, those beliefs were proven incorrect. Please lets get the wordsmithing right, so that we base our actions upon precise text in specifications rather than our beliefs! Thank you! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 19:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqK2-0004sR-0M; Mon, 28 Aug 2006 19:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqK1-0004sJ-1G; Mon, 28 Aug 2006 19:15:13 -0400 Received: from [2001:4f8:3:ba:2e0:18ff:fe02:efec] (helo=boole.openldap.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqJx-0004Wk-IB; Mon, 28 Aug 2006 19:15:13 -0400 Received: from gypsy.OpenLDAP.org (71-80-218-136.dhcp.crcy.nv.charter.com [71.80.218.136] (may be forged)) by boole.openldap.org (8.13.6/8.13.6) with ESMTP id k7SNEdni058074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Aug 2006 23:14:53 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060828155202.02301db8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 16:14:19 -0700 To: Mark Crispin From: "Kurt D. Zeilenga" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 At 03:21 PM 8/28/2006, Mark Crispin wrote: >Can we do some sort of compromise, such as these stipulations: > >All new client implementations MUST set integ_flag. I dislike such MUSTs. An old client should be conformant to the old specification. A new client should be conformant to the new specification. The new specification should discuss known interoperability problems between implementations of the new and old specifications. My understanding is that there are no known interoperability problems to discuss. This I-D should note the change was made and why in the Changes Since RFC 2222 section. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 19:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqaj-0005CR-QA; Mon, 28 Aug 2006 19:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqai-0005C2-Cl; Mon, 28 Aug 2006 19:32:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpSD-00051D-8o; Mon, 28 Aug 2006 18:19:37 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHp6F-0002tG-Im; Mon, 28 Aug 2006 17:56:57 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SLusLK030854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 14:56:54 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SLurw3024897 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 14:56:54 -0700 Date: Mon, 28 Aug 2006 14:54:51 -0700 (Pacific Daylight Time) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060828214650.GR10208@binky.Central.Sun.COM> Message-ID: References: <20060828214650.GR10208@binky.Central.Sun.COM> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.5 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Nicolas Williams wrote: > Since this is all specific to the Kerberos V GSS-API mechanism I think > the value of this flag is irrelevant, so this change should not render > any earlier implementations non-compliant in terms of their on-the-wire > behaviour. In that case, it's all the more reason to use SHOULD instead of MUST. > (At least one implementation of the Kerberos V GSS mechanism used to > leave out confidentiality protection, but none, to my knowledge, fails > to provide MIC and/or wrap tokens when integ_req_flag == false in the > call to GSS_Init_sec_context().) However, a change in the GSSAPI shared library could, without change to the client code itself, render a client that fails to set integ_req_flag non-compliant over-the-wire. So we shouldn't count upon this. I just don't want a path where my old installed base is retroactively declared non-compliant, or a trap laid where external events could change that base to become non-compliant. It's an entirely different matter if the old code is not "non-compliant" but has (potential) behavior that is "deprecated" in favor of the new code which follows the new rule. > GSS_C_NO_CHANNEL_BINDINGS is only defined in the C bindings of the > GSS-API (RFC2744), whereas the base GSS-API specification (RFC2743) uses > "NULL" to mean "no channel bindings" (e.g., "...where NULL channel > bindings..." and "[w]hen non-NULL channel bindings are provided"). OK, consider that one withdrawn. Thanks. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 20:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrMm-0006F6-9H; Mon, 28 Aug 2006 20:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrMl-0006Ej-N3; Mon, 28 Aug 2006 20:22:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpS5-00051D-7f; Mon, 28 Aug 2006 18:19:29 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHpHK-00037a-7T; Mon, 28 Aug 2006 18:08:23 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7SM8Lsp005546; Mon, 28 Aug 2006 15:08:21 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7SM8Ksf022636; Mon, 28 Aug 2006 16:08:21 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7SM8Kf8024241; Mon, 28 Aug 2006 17:08:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7SM8KLn024240; Mon, 28 Aug 2006 17:08:20 -0500 (CDT) Date: Mon, 28 Aug 2006 17:08:20 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060828220819.GS10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , iesg@ietf.org, kitten@ietf.org, ietf-sasl@imc.org References: <20060828214650.GR10208@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: -2.5 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, Aug 28, 2006 at 02:54:51PM -0700, Mark Crispin wrote: > On Mon, 28 Aug 2006, Nicolas Williams wrote: > >Since this is all specific to the Kerberos V GSS-API mechanism I think > >the value of this flag is irrelevant, so this change should not render > >any earlier implementations non-compliant in terms of their on-the-wire > >behaviour. > > In that case, it's all the more reason to use SHOULD instead of MUST. Why? MUST would be correct and happens not to break earlier implementations. What's the downside? I don't see any. See below. > >(At least one implementation of the Kerberos V GSS mechanism used to > >leave out confidentiality protection, but none, to my knowledge, fails > >to provide MIC and/or wrap tokens when integ_req_flag == false in the > >call to GSS_Init_sec_context().) > > However, a change in the GSSAPI shared library could, without change to > the client code itself, render a client that fails to set integ_req_flag > non-compliant over-the-wire. So we shouldn't count upon this. I think that would be really wrong on the part of the implementor, but even assuming it's possible I really doubt that this could happen to old implementations of the SASL "GSSAPI" mechanism, and if it did and they had not set integ_req_flag == TRUE then they would, in fact, fail to operate. > I just don't want a path where my old installed base is retroactively > declared non-compliant, or a trap laid where external events could change > that base to become non-compliant. It's an entirely different matter if > the old code is not "non-compliant" but has (potential) behavior that is > "deprecated" in favor of the new code which follows the new rule. Protocol-wise this change is a no-op, so I fail to see how old implementations become non-compliant -- you'd have to trace their execution to determine that they are non-compliant w.r.t. API use. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 20:44:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrhf-0001C2-EH; Mon, 28 Aug 2006 20:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrhe-00014a-Mq; Mon, 28 Aug 2006 20:43:42 -0400 Received: from [2001:4f8:3:ba:2e0:18ff:fe02:efec] (helo=boole.openldap.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHrhb-0002X4-A2; Mon, 28 Aug 2006 20:43:42 -0400 Received: from gypsy.OpenLDAP.org (71-80-218-136.dhcp.crcy.nv.charter.com [71.80.218.136] (may be forged)) by boole.openldap.org (8.13.6/8.13.6) with ESMTP id k7T0hWd7062057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 00:43:33 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060828173953.03ac56e8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 17:43:09 -0700 To: Mark Crispin From: "Kurt D. Zeilenga" In-Reply-To: References: <7.0.1.0.0.20060828155202.02301db8@OpenLDAP.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 At 04:20 PM 8/28/2006, Mark Crispin wrote: >On Mon, 28 Aug 2006, Kurt D. Zeilenga wrote: >>I dislike such MUSTs. An old client should be conformant >>to the old specification. A new client should be conformant >>to the new specification. The new specification should discuss >>known interoperability problems between implementations of the new >>and old specifications. My understanding is that there are >>no known interoperability problems to discuss. > >Doesn't that depend upon the GSSAPI implementation? As indicated by my comments, yes. Kurt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 21:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsNf-0008EK-2p; Mon, 28 Aug 2006 21:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsNd-0008E2-CD; Mon, 28 Aug 2006 21:27:05 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHsNa-0001Zr-TX; Mon, 28 Aug 2006 21:27:05 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 29C2DE00C0; Mon, 28 Aug 2006 21:27:07 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: Date: Mon, 28 Aug 2006 21:27:07 -0400 In-Reply-To: (Mark Crispin's message of "Mon, 28 Aug 2006 15:21:18 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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. This mesage is less organized than it should be. It may be easier to chat on the phone than to have too many more round trips here. >>>>> "Mark" == Mark Crispin writes: Mark> On Mon, 28 Aug 2006, Sam Hartman wrote: >> I don't think this change will create an interoperability >> problem. gss_wrap only works if the context has integrity. I >> believe that it is impossible for an implementation to >> interoperate with RFC 2222 or this spec unless integrity is >> available in the context as both this spec and RFC 2222 require >> gss_wrap to work. Mark> The "I believe" part scares me. It's a really strong belief. Factors that contribute to this belief: * Neither RFC 2222 nor this spec specify what to do if integrity protection is not available on a context. * gss_wrap only works if integrity protection is available. * The caller will call gss_unwrap on the input token. There is no way under RFC 1964 nor RFC 4121 to produce a token without integrity protection. >> I required this change from the working group and do not think >> I'm willing to take the document to the IESG unless integ_flag >> remains a must. Mark> Can we do some sort of compromise, such as these Mark> stipulations: Mark> All new client implementations MUST set integ_flag. Mark> RFC 2222 implementations were not required to set Mark> integ_flag. This was based upon an implicit assumption that Mark> clients could assume integrity even when not explicitly Mark> requested. This assumption is hereby deprecated. Actually, the change is in updating from RFC 1509 to RFC 2743. RFC 1509 against which 2222 was written did not provide integ_flag. Mark> Because RFC 2222 client authors were not warned about this Mark> implicit assumption, GSSAPI implementations MUST implicitly Mark> set integ_flag if the client does not set it. [This renders Mark> the assumption into a MUST even though it is deprecated.] No, I'm not willing to revisit this aspect of 2743 for a SASL document. >> I am willing to listen to your arguments though and would be >> especially interested in cases where this change creates a wire >> protocol change. Mark> The thing is, I don't know. There are multiple GSSAPI Mark> implementations. You're asking me to put faith that nothing Mark> will happen to cause an 8 year old RFC 2222 compliant Mark> implementation to break over the wire. Mark> I'm not trying to block the change; I'm just trying to Mark> ameliorate a potential bad consequence. Mark> Traditionally, the IETF has declined to break an installed Mark> base that was implemented in good faith. I hope that this Mark> tradition is maintained. The IETF does make incompatible changes when there is a reason to do so. Fixing a security problem seems like a good reason to me. Integrity protection of the security layer parameters is really important and is a MUST in RFC 4222. Personally, if I had to choose between breaking a few old implementations and making it sure that security worked, I would do so. But I don't think we're making that choice. I think setting the integ_flag is an important change in upgrading an application from RFC 1509 to RFC 2743. Besides that, with the Kerberos mechanisms, I believe that it tends not to result in a wire change. If it does result in a wire change it changes a flag bit in the RFC 1964 header. I know that my implementation always forces this bit to be set regardless of whether the user specifies the flag in the init_sec_ctx API call. So, I have high confidence that we would have noticed if any SASL acceptors fail to work when that flag bit is set. I think the only problem situation I can think of is an SASL server that fails to work when the integ_avail flag is set in the first context token but supports gss_wrap anyway. That is, a SASL server that supports integrity except when it is turned on, in which case it fails. That server seems quite broken to me. A more serious problem case is a client that does not support gss_wrap when integ_flag is not set in gss_init_sec_ctx. I believe such a client could not possibly work with RFC 2222 or this spec. However I think such a client is compatible with GSS-API. In conclusion, I'm not at all sure what the possible behaviors are when integ_flag is not set. By far the most common behavior seems to be working just fine. The second likely behavior seems to be failing to interoperate at all. It also seems possible that someone would manage to provide an implementation that is insecure when integ_flag is not set; I am unaware of such an implementation. The interoperability story when integ_flag is set seems much better--we know it's supposed to work and we have strong evidence it works in practice from interoperability events. Everything that has successfully tested against an MIT client will work fine. Everything that has been in one of the Kerberos interoperability events will work fine. Every server that supports integrity at the GSS-API layer will work fine. If you accept and ignore the integrity flag when you don't support it (this is the standard GSS-API behavior), you will ork fine. The failure case I can think of is a server that actually supports integrity but claims not to support integrity and rejects the connection when integ_avail is set. I will choose avoiding more realistic interoperability problems and the unlikely but possible unprotected security layer exchange to avoiding what seems to me like a very unlikely interoperability problem caused by the spec change. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Aug 28 21:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsSW-0001cS-K1; Mon, 28 Aug 2006 21:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHsSV-0001bK-1B; Mon, 28 Aug 2006 21:32:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqVQ-0007NA-2l; Mon, 28 Aug 2006 19:27:00 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHqR2-0005QY-TF; Mon, 28 Aug 2006 19:22:31 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SNMRLe028491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Aug 2006 16:22:28 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7SNMRXx009015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Aug 2006 16:22:27 -0700 Date: Mon, 28 Aug 2006 16:20:24 -0700 (Pacific Daylight Time) From: Mark Crispin To: "Kurt D. Zeilenga" In-Reply-To: <7.0.1.0.0.20060828155202.02301db8@OpenLDAP.org> Message-ID: References: <7.0.1.0.0.20060828155202.02301db8@OpenLDAP.org> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.28.100944 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 28 Aug 2006, Kurt D. Zeilenga wrote: > I dislike such MUSTs. An old client should be conformant > to the old specification. A new client should be conformant > to the new specification. The new specification should discuss > known interoperability problems between implementations of the new > and old specifications. My understanding is that there are > no known interoperability problems to discuss. Doesn't that depend upon the GSSAPI implementation? > This I-D should note the change was made and why in the Changes > Since RFC 2222 section. I agree. It should document the implicit assumption in RFC 2222 and deprecate it, so that people understand what is being talked about. IMHO, it should also make this assumption mandatory in GSSAPI implementations (which in theory just preserves the status quo) that may be called by RFC 2222 implementations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 15:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI92a-00036j-T7; Tue, 29 Aug 2006 15:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI92Z-00036b-Mf; Tue, 29 Aug 2006 15:14:27 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI92Y-0002hS-Cy; Tue, 29 Aug 2006 15:14:27 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7TJEJmT023248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 15:14:19 -0400 (EDT) Date: Tue, 29 Aug 2006 15:14:19 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Mark Crispin Message-ID: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:011a+IGD8X/Ywh+gCZCC24h2whv0Nc4wFCJLZ9Cy8=; 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, August 28, 2006 09:27:07 PM -0400 Sam Hartman wrote: > >> I required this change from the working group and do not think > >> I'm willing to take the document to the IESG unless integ_flag > >> remains a must. > > Mark> Can we do some sort of compromise, such as these > Mark> stipulations: > > Mark> All new client implementations MUST set integ_flag. > > Mark> RFC 2222 implementations were not required to set > Mark> integ_flag. This was based upon an implicit assumption that > Mark> clients could assume integrity even when not explicitly > Mark> requested. This assumption is hereby deprecated. > > Actually, the change is in updating from RFC 1509 to RFC 2743. RFC > 1509 against which 2222 was written did not provide integ_flag. Right. RFC2743 makes it quite clear that callers which do not set integ_req_flag may not be able to make use of integrity services. It also addresses the interoperability issues with applications written against older versions of the API, recommending that mechanisms behave as if the flag were set when the caller is known to be using the old API. [ For the record, RFC2222 references RFC2078, not 1509. But it appears that the integ_req_flag and conf_req_flag bits were not defined for GSS_Init_sec_context until GSS-API v2.1. ] > The IETF does make incompatible changes when there is a reason to do > so. Fixing a security problem seems like a good reason to me. > Integrity protection of the security layer parameters is really > important and is a MUST in RFC 4222. Personally, if I had to choose > between breaking a few old implementations and making it sure that > security worked, I would do so. > > But I don't think we're making that choice. I think setting the > integ_flag is an important change in upgrading an application from RFC > 1509 to RFC 2743. Right. If your SASL implementation is written against a GSS-API v1 library, then you have nothing to worry about, because that flag did not exist then. If you have been linking it against a v2 library, then you had to deal with the API changes in v2, and if you failed to not that you needed to set integ_req_flag, then that is your own problem. Since this version of the SASL GSSAPI mechanism is being updated to use a new version of the GSS-API, it is appropriate and necessary to update it to reflect new requirements placed on the users of that API. Note that even if the new document were silent on this issue, you would _still_ be required to set the flag if you wanted integrity services to work, because that is a requirement of RFC2743. The language we're arguing about is intended to make that clear to implementors of this mechanism. > Besides that, with the Kerberos mechanisms, I > believe that it tends not to result in a wire change. If it does > result in a wire change it changes a flag bit in the RFC 1964 header. Yes, depending on the GSS-API krb5 mechanism implementation, setting or not setting the integ_req_flag might result in a change to the bit in the wire protocol which conveys the request from initiator to acceptor. However, there is no additional negotiation or setup involved, and the Wrap/Unwrap and GetMic/VerifyMIC operations defined in RFC4121 (and RFC1964) work regardless of the value of this flag. In short... An RFC2222 implementation using GSS-API v1 will work just fine. An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will work. An RFC2222 implementation using GSS-API v2.1 without integ_req_flag is already wrong, but probably works anyway. A different GSS-API v2.1 library would be entirely within its rights to make it not work, under the existing GSS-API specification. RFC2222, RFC4422, and this spec have nothing to do with it. A new implementation of RFC4422 and this spec would need to comply with the requirements of RFC2743, including the need to set integ_req_flag if it wants integrity services. An implementation that failed to do so would be noncompliant, but would probably work anyway; however, it would be entirely within the rights of an GSS-API v2.1 Kerberos mechanism implementation to break this. Given that this is the first version of this mechanism based on GSS-API v2.1, and that version introduces new requirements upon its callers that were not present in previous versions of the GSS-API, we would be remiss if we did not pass those requirements on to implementations of this mechanism. In particular, without this requirement, it would be possible for a "correct", compliant implementation to fail to interoperate. That would be wrong, so we must avoid it. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 17:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAtC-0001Lg-Tf; Tue, 29 Aug 2006 17:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAqV-0000nR-If; Tue, 29 Aug 2006 17:10:07 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAgG-00061r-Bq; Tue, 29 Aug 2006 16:59:33 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7TKxUdP017213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 13:59:30 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7TKxUlY022733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 13:59:30 -0700 Date: Tue, 29 Aug 2006 13:57:28 -0700 (Pacific Daylight Time) From: Mark Crispin To: Jeffrey Hutzelman In-Reply-To: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.134443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.6 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 29 Aug 2006, Jeffrey Hutzelman wrote: > Right. RFC2743 makes it quite clear that callers which do not set > integ_req_flag may not be able to make use of integrity services. It also > addresses the interoperability issues with applications written against older > versions of the API, recommending that mechanisms behave as if the flag were > set when the caller is known to be using the old API. Can you elaborate on "when the caller is known to be using the old API"? How does my RFC 2222 compliant caller identify itself as using the old API (or the new API)? As far as I know, the only thing that I needed to do to become compliant with the new draft was to add GSS_C_INTEG_FLAG to the other flags in the 6th argument to gss_init_sec_context(). Does that change my application from an old API to a new API? > Right. If your SASL implementation is written against a GSS-API v1 library, > then you have nothing to worry about, because that flag did not exist then. > If you have been linking it against a v2 library, then you had to deal with > the API changes in v2, and if you failed to not that you needed to set > integ_req_flag, then that is your own problem. Say what??? I have no idea what version of GSSAPI I implemented against. I followed the instructions in RFC 2222. I look in my /usr/kerberos/include/gssapi/gssapi.h and see that there is a GSS_C_INTEG_FLAG defined with the other flags that can be supplied to the 6th argument to gss_init_sec_context. I assume, in good faith, that that is what you are talking about when you say "integ_req_flag"; just like I assume, in good faith, that the gss_init_sec_context() function is what you are talking about when you refer to GSS_Init_sec_context. If now you're saying me that this is all something different, then what on earth are you talking about? There is no "integ_req_flag" or "GSS_Init_sec_context". If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is not in the "old API"? If this is the "new API", then how does my code, written to comply with RFC 2222, build under it? Last but not least, why is it my problem that I didn't do something that the (still current) specification never said that I had to do? "But Mr. Dent, the plans have been available in the local planning office for the last nine months." "On display? I eventually had to go down to the cellar to find them...It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" > Since this version of the SASL GSSAPI mechanism is being updated to use a new > version of the GSS-API, it is appropriate and necessary to update it to > reflect new requirements placed on the users of that API. Note that even if > the new document were silent on this issue, you would _still_ be required to > set the flag if you wanted integrity services to work, because that is a > requirement of RFC2743. The language we're arguing about is intended to make > that clear to implementors of this mechanism. I don't want (or not want) integrity services to work. I want the GSSAPI SASL mechanism to work; that is, to authenticate to a Kerberos 5 server. All I knew of integity services was the optional part for privacy and integrity in SASL which I wasn't using -- meaning that, as far as I knew, this did not apply to me. Now you tell me that it does, and that it's all my fault for making the false assumption that I had integrity when I did not. The problem with that is that it assumes that I, implementing from RFC 2222, knew enough about the internals of GSSAPI to make that kind of assumption. RFC 2222 goes to great efforts to hide what GSSAPI does. If it didn't, I doubt very much that I would use GSSAPI instead of doing the Kerberos protocol myself. That way, I wouldn't have to deal with surprises like "You must set this bit when you call GSSAPI. True, we didn't tell you about it back then, but it's still your fault for not knowing about it." > Yes, depending on the GSS-API krb5 mechanism implementation, setting or not > setting the integ_req_flag might result in a change to the bit in the wire > protocol which conveys the request from initiator to acceptor. However, > there is no additional negotiation or setup involved, and the Wrap/Unwrap and > GetMic/VerifyMIC operations defined in RFC4121 (and RFC1964) work regardless > of the value of this flag. I don't quite understand this, but will assume that the next paragraph explains it: > An RFC2222 implementation using GSS-API v1 will work just fine. > An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will work. > An RFC2222 implementation using GSS-API v2.1 without integ_req_flag is > already wrong, but probably works anyway. What is "an RFC2222 implementation...with integ_req_flag"? RFC 2222 is silent on the matter. Doesn't the addition of integ_req_flag upgrade an RFC 2222 implementation to RFC xxxx (where xxxx is whatever number gets assigned to this new document)? If it does not upgrade the implementation from RFC 2222 to RFC xxxx (I read the draft and I didn't see any other matter that call for a change), why not and what else do I need to do? > A different GSS-API v2.1 library > would be entirely within its rights to make it not work, under the existing > GSS-API specification. RFC2222, RFC4422, and this spec have nothing to do > with it. I strongly disagree. Either this is a bug in RFC 2222, or is an incompatibility in GSSAPI 2.1 that broke RFC 2222. Either way, it is not a good thing that this came to pass, and the innocent implementors who followed RFC 2222 are not to blame for the situation. > A new implementation of RFC4422 and this spec would need to comply with the > requirements of RFC2743, including the need to set integ_req_flag if it wants > integrity services. An implementation that failed to do so would be > noncompliant, but would probably work anyway; however, it would be entirely > within the rights of an GSS-API v2.1 Kerberos mechanism implementation to > break this. If this is so, do you agree that this is an incompatible (and unfortunate) change in GSSAPI 2.1? What is wrong with adding in two bits of advice: (1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD continue to act as if integ_req_flag is always set. Since you said that this is how known GSSAPI 2.1 implementations work, this doesn't change anything. (2) RFC 2222 implementors MUST take note of the new requirement to set integ_req_flag, and MUST upgrade their implementations. Although all known GSSAPI 2.1 implementations treat it as set, this behavior can not be relied upon. I don't think that this is that much to ask; and I think that this accomplishes the goals that you set out to accomplish. >In > particular, without this requirement, it would be possible for a "correct", > compliant implementation to fail to interoperate. That would be wrong, so we > must avoid it. What is the scenario that you envision? I'm worried about the scenario of a RFC 2222 compliant implementation failing to interoperate. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 17:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAu4-00027Z-8b; Tue, 29 Aug 2006 17:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAq7-0000gp-I5 for kitten@ietf.org; Tue, 29 Aug 2006 17:09:43 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAlh-00075R-Ew for kitten@ietf.org; Tue, 29 Aug 2006 17:05:10 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000028121.msg for ; Tue, 29 Aug 2006 17:07:17 -0400 Message-ID: <44F4AC5C.4060109@secure-endpoints.com> Date: Tue, 29 Aug 2006 17:06:36 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov References: <20060829205723.GM10458@binky.Central.Sun.COM> In-Reply-To: <20060829205723.GM10458@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Tue, 29 Aug 2006 17:07:17 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Subject: Re: Proposed updates for domain-based drafts 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="===============0687456448==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0687456448== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040607010709050700090101" This is a cryptographically signed message in MIME format. --------------ms040607010709050700090101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nico, Thank you for writing this summary. I am going to extend the WGLC for one week in order to provide time for specific text to be proposed and for consensus to be reached. Jeffrey Altman Kitten Chair Nicolas Williams wrote: > Issues that came up: > > - Sam wanted a better outline of how applications might use > domain-based names. I'm not sure whether Sam wants text for the > drafts or merely discussion on the list. > > - Sam and Jeff H. were concerned about the SASL framework vis-a-vis > domain-based names. > > - Jeff Hutzelman wanted > > - A clarification on just what is a "domain" > > - A new feature in the Kerberos V GSS-API mechanism relating to > domain-based names: initiator-side fallback on hostbased naming > with domainnames as hostnames with acceptor-side acceptor > credential sharing. > > > To address Sam's main comment I propose re-writing the introduction to > explain that domain-based names are intended to provide protection to > applications utilizing insecure service discovery methods. Additionally > the specification of what domainname to be used in the domain part of > domain-based names will be left to applications. Some applications may > use SRV RR names as domainnames (e.g., _tcp._foosvc.example.com), others > may use plain domainnames (e.g., example.com). Finally, I propose a new > section containing Informative descriptions of how NFSv4 and LDAP > clients (ignoring SASL naming issues; see below) would perform service > discovery using DNS SRV RR queries and domain-based service names for > servers named in the SRV RRs. I will send text tonight, hopefully. > > With respect to SASL I believe there is nothing for either of these two > I-Ds to say on the matter. I believe applications and SASL/GS1 and/or > SASL/GS2 will require updating to specify use of domain-based names in > SASL contexts. I don't believe that we absolutely must update the SASL > base specification to introduce new kinds of server names, but I don't > mind us doing so -- either way the I-Ds we're considering in this WGLC > are unaffected. > > After some off-line discussion with Jeff about his proposed new feature > we reached a compromise. We propose the following change to > draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt: > > - GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal > - names as follows: > + GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V > + principal names as follows: > > This will allow for a future document that specifies Jeff's fallback > feature. > > Nico --------------ms040607010709050700090101 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MjkyMTA2MzZaMCMGCSqGSIb3DQEJBDEWBBTmiG3+ T1r0H4u2oXRyCXZQ/Cv9PTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAiXYcpLB9IKQUahnAGaTr7rTzHFRDz8VbZJQbHQwSTmAwjJ6ref3H Y7wcCGpkmel6Oteuz08Pk4QLKywwueEb/on70kPToemiH48nm4qkIqdaoq7KURz3G5TT37pl s7DuLiyUA7XBj5HpNu/J4/NQ91tgnn+laRXsPfM3Ml1aOG8UeLrwGk1nUMAP8Jc6AHBIU+MG +5tMKnMgDZQ+G8Gt8qrF5C2fW4G2fbJTW7WUeDR/aT6pLVBTP4pY18bnLs0yQuHEsnCSOVWU irOvExIp/wxNTk/HwwBk0nqntdJ8aztnV4Dg+9ImHGSQP5mWTKB9CWfFawNCJMyHW132tMyE wAAAAAAAAA== --------------ms040607010709050700090101-- --===============0687456448== 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 --===============0687456448==-- From kitten-bounces@lists.ietf.org Tue Aug 29 17:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAzN-0007fD-If; Tue, 29 Aug 2006 17:19:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAzM-0007Z5-38; Tue, 29 Aug 2006 17:19:16 -0400 Received: from cpe-68-175-91-105.nyc.res.rr.com ([68.175.91.105] helo=www.secure-endpoints.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAzK-0000Yl-0Z; Tue, 29 Aug 2006 17:19:16 -0400 Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.6) with ESMTP id md50000028123.msg; Tue, 29 Aug 2006 17:21:22 -0400 Message-ID: <44F4AFE7.4070006@secure-endpoints.com> Date: Tue, 29 Aug 2006 17:21:43 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: secure-endpoints.com, Tue, 29 Aug 2006 17:21:22 -0400 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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="===============1027352094==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1027352094== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040406050102000805040203" This is a cryptographically signed message in MIME format. --------------ms040406050102000805040203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mark Crispin wrote: > What is wrong with adding in two bits of advice: > > (1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD > continue to act as if integ_req_flag is always set. > > Since you said that this is how known GSSAPI 2.1 implementations work, > this doesn't change anything. > > (2) RFC 2222 implementors MUST take note of the new requirement to set > integ_req_flag, and MUST upgrade their implementations. Although all > known GSSAPI 2.1 implementations treat it as set, this behavior can > not be relied upon. > Mark, does the text proposed by Sam Hartman meet your needs? if so, can we reach consensus on that text and move on? Jeffrey Altman --------------ms040406050102000805040203 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA4MjkyMTIxNDNaMCMGCSqGSIb3DQEJBDEWBBSXhi2L 1y37QBFfGg0jFa+hYD+k5zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAq/vl8P5uj/mAZZ1M29B0qSrb1iZW1CxI1y/binKT6OPOBBaUjnkW y4Fz5BKKoSc4mXli/LciVouGYDvUNmGqQplImorgkViajlkHLSQKL4YqyBMJTYBjMj53kqug 42j7WJys8ABQPXmO35YLFZ5BaKGZ9jQH8nRTb2ZYp+fAmQXpuDv7kkTj9cGTYHTZIRYnmXLx JWCvbOlYCIQZRcaEeu+IB59KPIJ7yiXyUbqur0VuYGbHvxn6Z1Xi2kV/or/xuEnMnzyuG+eU V7Vmxx6v1z5P5csklnjjNcCbL1XsL4OCTNO8rDijaYRUgJbVTOXZ5P1YS/uqHeVK+Ud5+sg6 0AAAAAAAAA== --------------ms040406050102000805040203-- --===============1027352094== 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 --===============1027352094==-- From kitten-bounces@lists.ietf.org Tue Aug 29 17:22:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB2E-0000cT-9T; Tue, 29 Aug 2006 17:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB2C-0000cO-CV for kitten@ietf.org; Tue, 29 Aug 2006 17:22:12 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIB2A-0000wv-RB for kitten@ietf.org; Tue, 29 Aug 2006 17:22:12 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7TKw60t009288 for ; Tue, 29 Aug 2006 13:58:06 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7TKvt4f023764 for ; Tue, 29 Aug 2006 14:58:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7TKvPR1026200; Tue, 29 Aug 2006 15:57:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7TKvOj5026199; Tue, 29 Aug 2006 15:57:24 -0500 (CDT) Date: Tue, 29 Aug 2006 15:57:24 -0500 From: Nicolas Williams To: kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov Message-ID: <20060829205723.GM10458@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: Proposed updates for domain-based drafts 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 Issues that came up: - Sam wanted a better outline of how applications might use domain-based names. I'm not sure whether Sam wants text for the drafts or merely discussion on the list. - Sam and Jeff H. were concerned about the SASL framework vis-a-vis domain-based names. - Jeff Hutzelman wanted - A clarification on just what is a "domain" - A new feature in the Kerberos V GSS-API mechanism relating to domain-based names: initiator-side fallback on hostbased naming with domainnames as hostnames with acceptor-side acceptor credential sharing. To address Sam's main comment I propose re-writing the introduction to explain that domain-based names are intended to provide protection to applications utilizing insecure service discovery methods. Additionally the specification of what domainname to be used in the domain part of domain-based names will be left to applications. Some applications may use SRV RR names as domainnames (e.g., _tcp._foosvc.example.com), others may use plain domainnames (e.g., example.com). Finally, I propose a new section containing Informative descriptions of how NFSv4 and LDAP clients (ignoring SASL naming issues; see below) would perform service discovery using DNS SRV RR queries and domain-based service names for servers named in the SRV RRs. I will send text tonight, hopefully. With respect to SASL I believe there is nothing for either of these two I-Ds to say on the matter. I believe applications and SASL/GS1 and/or SASL/GS2 will require updating to specify use of domain-based names in SASL contexts. I don't believe that we absolutely must update the SASL base specification to introduce new kinds of server names, but I don't mind us doing so -- either way the I-Ds we're considering in this WGLC are unaffected. After some off-line discussion with Jeff about his proposed new feature we reached a compromise. We propose the following change to draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt: - GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal - names as follows: + GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V + principal names as follows: This will allow for a future document that specifies Jeff's fallback feature. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 17:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8s-00040K-8o; Tue, 29 Aug 2006 17:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIB8q-000407-NL; Tue, 29 Aug 2006 17:29:04 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIB8o-0001iA-AS; Tue, 29 Aug 2006 17:29:04 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA18906; Tue, 29 Aug 2006 23:28:55 +0200 (MESZ) From: Martin Rex Message-Id: <200608292128.XAA27487@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 29 Aug 2006 23:28:54 +0200 (MET DST) In-Reply-To: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> from "Jeffrey Hutzelman" at Aug 29, 6 03:14:19 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-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf-sasl@imc.org, kitten@ietf.org, iesg@ietf.org, MRC@cac.washington.edu, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Jeffrey Hutzelman wrote: > > Right. RFC2743 makes it quite clear that callers which do not set > integ_req_flag may not be able to make use of integrity services. It also > addresses the interoperability issues with applications written against > older versions of the API, recommending that mechanisms behave as if the > flag were set when the caller is known to be using the old API. There seems to be a misunderstanding about the "conf_req_flag" and "integ_req_flags". The only reason why these flags were added to GSS-API v2(u1) was to enable negotiating mechanisms (=SPNEGO) to consider them when making a choice for the most appropriate common gssapi mechanism. It was NOT intended to be a requirement for the initiator to assert these flags as a general prerequisite in order to use the message protection services. Keep in mind that the acceptor still doesn't have the opportunity to indicate such "requirements", so the gssapi mechanism must always assume that the acceptor wants them. The absence of the request for message protection services may result in a negotiating mechanism to negotiate a mechanism that doesn't have message protection services (based on its configured preference), although there might have been a common gssapi mechanism that would have provided such services (and which would have been preferred if the initiator had asserted these flags). A gssapi mechanism that implements message protection services but refuses them if the newly added "conf_req_flag" and "integ_req_flag" weren't passed in during gss_init_sec_context() must be considered seriously broken. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 18:24:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC0N-0007jW-10; Tue, 29 Aug 2006 18:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIC0M-0007gh-B9; Tue, 29 Aug 2006 18:24:22 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBsd-00074J-Cb; Tue, 29 Aug 2006 18:16:23 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7TMGH5r000544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 18:16:18 -0400 (EDT) Date: Tue, 29 Aug 2006 18:16:17 -0400 From: Jeffrey Hutzelman To: Mark Crispin Message-ID: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> In-Reply-To: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> Originator-Info: login-token=Mulberry:01y3PZ9jXbTmoXvlF3/vEJZWLlECFSp1I46AdbAfM=; 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: 515708a075ffdf0a79d1c83b601e2afd Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Tuesday, August 29, 2006 01:57:28 PM -0700 Mark Crispin wrote: > On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote: >> Right. RFC2743 makes it quite clear that callers which do not set >> integ_req_flag may not be able to make use of integrity services. It >> also addresses the interoperability issues with applications written >> against older versions of the API, recommending that mechanisms behave >> as if the flag were set when the caller is known to be using the old >> API. > > Can you elaborate on "when the caller is known to be using the old API"? Nope; I was paraphrasing RFC2743. I don't know what scenario its authors were envisioning, but I assume it involved some sort of out-of-band knowledge. >> Right. If your SASL implementation is written against a GSS-API v1 >> library, then you have nothing to worry about, because that flag did >> not exist then. If you have been linking it against a v2 library, then >> you had to deal with the API changes in v2, and if you failed to not >> that you needed to set integ_req_flag, then that is your own problem. > > Say what??? > > I have no idea what version of GSSAPI I implemented against. You used an API without paying attention to what version of the API you were using? How is that my problem? > I followed > the instructions in RFC 2222. ... without reading the documents to which it referred, apparently. This is precisely the reason for stating the requirement to set integ_req_flag in this new document - because if we don't, then people implementing the mechanism won't bother to read the GSS-API documents, even though they're writing what is essentially a GSS-API application, and will miss this requirement. > I look in my /usr/kerberos/include/gssapi/gssapi.h and see that there is > a GSS_C_INTEG_FLAG defined with the other flags that can be supplied to > the 6th argument to gss_init_sec_context. I assume, in good faith, that > that is what you are talking about when you say "integ_req_flag"; just > like I assume, in good faith, that the gss_init_sec_context() function is > what you are talking about when you refer to GSS_Init_sec_context. RFC 2743 defines the GSS-API v2.1, which is an abstract API. This is what protocol specifications such as RFC 4422 or the present GSS-API SASL mechanism document need to reference. It describes the semantics of the GSS-API along with a few wire protocol bits. If you are actually _implementing_ a protocol that uses the GSS-API, then you also need to read the language bindings document for the language you are using; for C, this is RFC 2743. It is this document that tells you how GSS-API data types are represented in that language, what the values of constants are, the actual names of functions to call, etc. So yes, when I refer to GSS_Init_sec_context, which is an operation provided by the abstract API, that is the same as the C-language function gss_init_sec_context(), and the Java method GSSContext.initSecContext(). > If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is > not in the "old API"? If this is the "new API", then how does my code, > written to comply with RFC 2222, build under it? Well, given that GSS_C_INTEG_FLAG exists, I'd guess that the library you're building against is an implementation of GSS-API v2.1. To be sure, you should probably check whatever documentation came with it. Presumably, your code builds because the API was designed to be (mostly) backward-compatible. I agree that the "mostly" is unfortunate and creates an increased burden for the developer of GSS-API-using applications, since existing users of GSS_Init_sec_context may build even though the interface changed in a backward-incompatible way. > I don't want (or not want) integrity services to work. You're calling GSS_Wrap. RFC2743 is clear on what you have to do for that to work. True, RFC2078 said no such thing, and your implementation is compliant with 2222 and 2078, at least in this respect. If you want to upgrade to an implementation of the new API, you have to make whatever changes are required to do so. The present discussion is about a specification that is being upgraded from using RFC2078 to using RFC2743, and about a change that is required as a result of that upgrade. > Now you tell me that it does, and that it's all my fault for making the > false assumption that I had integrity when I did not. The problem with > that is that it assumes that I, implementing from RFC 2222, knew enough > about the internals of GSSAPI to make that kind of assumption. Right; you read RFC2222 and apparently didn't bother to read 2078 or 1509 in detail. That's kind of poor, but it's also to be expected, and it's why 2222 and the present document and other specifications of GSS-API-using applications need to be specific about these things. The other thing you also did, apparently, was to take your RFC2222 implementation and use it with a newer version of the GSS-API than was used by that document. Now, RFC2222 couldn't possibly have warned you about changes required by RFC2743. The new specification can, and should. > RFC 2222 goes to great efforts to hide what GSSAPI does. >From application protocol designers and implementors, not from mechanism implementors. You wouldn't expect to implement TCP without understanding IP, would you? > That way, I wouldn't have to deal with surprises like > "You must set this bit when you call GSSAPI. True, we didn't tell you > about it back then, but it's still your fault for not knowing about it." You'd have the same problem if you wrote your application against an older version of some Kerberos API (note that there is no standardized one) and then built it against a newer version with different requirements, or against a different implementation with different requirements. When RFC2222 was written, its authors told you about what you needed to do in order to use the version of the GSS-API that was available at that time. Now, we're telling you what you need to do in order to use the version of the GSS-API that's available now. What you're suggesting is that the new spec _not_ document a new requirement of the GSS-API, because your implementation which was designed for the old GSS-API fails to meet the requirements of the new one. That's just insane. >> An RFC2222 implementation using GSS-API v1 will work just fine. >> An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will >> work. An RFC2222 implementation using GSS-API v2.1 without >> integ_req_flag is already wrong, but probably works anyway. > > What is "an RFC2222 implementation...with integ_req_flag"? RFC 2222 is > silent on the matter. I mean an RFC2222 implementation, built against a RFC2743 implementation, which sets integ_req_flag in its calls to GSS_Init_sec_context. In other words, what _should_ be the result of forward-porting an existing RFC2222 implementation to the new API. > If it does not upgrade the implementation from RFC 2222 to RFC xxxx (I > read the draft and I didn't see any other matter that call for a change), > why not and what else do I need to do? If that's the only change, then yes, making the change brings you into compliance with the new spec. But for the purpose of this discussion, I wasn't going to make any assumptions about whether there were other changes. >> A different GSS-API v2.1 library >> would be entirely within its rights to make it not work, under the >> existing GSS-API specification. RFC2222, RFC4422, and this spec have >> nothing to do with it. > > I strongly disagree. Either this is a bug in RFC 2222, or is an > incompatibility in GSSAPI 2.1 that broke RFC 2222. It's not a bug in 2222; the flag didn't exist then. It's also not a change in GSSAPI 2.1 that broke 2222, because 2222 refers to RFC2078, which defines GSSAPI 2.0. There's a reason why we generally make references to immutable identifiers like RFC's, rather than to STD numbers, and this situation illustrates that reason perfectly. I will agree that GSSAPI v2.1 is incompatible with older versions in this respect. I'll even agree that the new functionality could have been added in a way that was not backward-incompatible. However, that was over 6 years ago, before I was involved in the IETF, and it's pretty much a done deal now. > Either way, it is not > a good thing that this came to pass, and the innocent implementors who > followed RFC 2222 are not to blame for the situation. Implementors who followed RFC 2222, including using an implementation of the GSS-API as specified in RFC 2078, are indeed not to blame for the situation. Those who updated their implementations to use a newer implementation of the GSS-API without dealing with new requirements that RFC 2222 could not possibly have known about, have less of a leg to stand on. Remember, a large part of the _reason_ for the present document is to update the GSS-API SASL mechanism spec to reflect those new requirements. Sometimes being ahead of the curve hurts. In this case, it won't, really, because the likelyhood that you're actually going to see an interoperability problem is vanishingly small. > If this is so, do you agree that this is an incompatible (and > unfortunate) change in GSSAPI 2.1? Yes, but it's too late to do anything about it. > What is wrong with adding in two bits of advice: > > (1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD > continue to act as if integ_req_flag is always set. > > Since you said that this is how known GSSAPI 2.1 implementations > work, > this doesn't change anything. IMHO, imposing requirements on implementors of the GSS-API is out of scope for this working group. Perhaps the chairs would care to comment? > (2) RFC 2222 implementors MUST take note of the new requirement to set > integ_req_flag, and MUST upgrade their implementations. Although all > known GSSAPI 2.1 implementations treat it as set, this behavior can > not be relied upon. RFC 2222 is immutable. To say "RFC 2222 implementors MUST..." is nonsensical. Implementors of _this_ spec already MUST set the flag, and anything that's not an implementation of this spec is not subject to the requirement anyway. I would not object to non-normative text to the effect that because RFC 2222 was based on an older version of the GSS-API spec, implementations of this mechanism as described in RFC 2222 might not be setting integ_req_flag. >> In >> particular, without this requirement, it would be possible for a >> "correct", compliant implementation to fail to interoperate. That >> would be wrong, so we must avoid it. > > What is the scenario that you envision? > > I'm worried about the scenario of a RFC 2222 compliant implementation > failing to interoperate. Well, if that happens, nothing we can say here is going to prevent it. Failing to set the flag may result in GSS_Wrap breaking. If so, nothing we can do at the SASL layer will change that. If not, it's going to work anyway. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 19:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDRA-000834-2F; Tue, 29 Aug 2006 19:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDR9-00082v-5c; Tue, 29 Aug 2006 19:56:07 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIDR7-00013p-N2; Tue, 29 Aug 2006 19:56:07 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id BAA17682; Wed, 30 Aug 2006 01:55:57 +0200 (MESZ) From: Martin Rex Message-Id: <200608292355.BAA00855@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Wed, 30 Aug 2006 01:55:56 +0200 (MET DST) In-Reply-To: from "Sam Hartman" at Aug 28, 6 09:27:07 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-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: kitten@ietf.org, MRC@CAC.Washington.EDU, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Sam Hartman wrote: > > It's a really strong belief. > Factors that contribute to this belief: > > * Neither RFC 2222 nor this spec specify what to do if integrity > protection is not available on a context. > > * gss_wrap only works if integrity protection is available. > > * The caller will call gss_unwrap on the input token. There is no way > under RFC 1964 nor RFC 4121 to produce a token without integrity protection. For many years no-one in the cat-ietf working group had thought about gssapi mechanisms that do not have message integrity. They simply didn't exist. When one vendor/implementor proposed an authentication-only gssapi mechanism during an IETF meeting (gave a presentation), people started wondering about the implications. It was realized that GSS-API (high level and C-bindings) did not cover this case. It is unspecified what the message protection functions will do in that case. gss_getmic()/gss_verifymic() are likely going to fail (but aren't required to). gss_getmic() definitely MUST NOT return an empty output token, however. gss_wrap() might work, and for the sake of simplistic application level protocol framing it would be useful if gss_wrap()/gss_unwrap() actually worked even when no integrity protection was provided. IMHO, having get_mic/verify_mic and wrap/unwrap succeed in absence of messsage integrity services might easily give an application a false sense of security. gss_wrap/gss_unwrap can only indicate availability/unavailability of confidentiality in a non-ambiguous way, it can not do that with message integrity. QOPs are non-portable. But ultimately, it is un(der)specified at the GSS-API level, So the general recommendation of the GSS-API spec becomes even more important: an application ought to check context attributes when context establishment succeeds and decide whether it wants to use the resulting security context or not--because a GSS-API mechanism ought to successfully establish a security context even when it doesn't meet the callers desires. The server/accepter doesn't have a means to indicates its desires/requirements, anyway. > > A more serious problem case is a client that does not support gss_wrap > when integ_flag is not set in gss_init_sec_ctx. I believe such a > client could not possibly work with RFC 2222 or this spec. However I > think such a client is compatible with GSS-API. I think that a client (gsssapi mechanism implementation capable of message integrity protection) is both non-compliant with GSS-API and seriously broken if it denies message integrity services only because the initiator didn't assert integ_req_flag when it called gss_init_sec_context(). The wording in RFC2743 is to improve "portability" for applications even for newer negotiating mechanisms. It was never meant to imply that it would be OK for gssapi mechanism implementations to make stupid backwards incompatible changes just for the sake of the fun of it. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 20:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE5t-00012P-4e; Tue, 29 Aug 2006 20:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE5r-0000zb-IA for kitten@ietf.org; Tue, 29 Aug 2006 20:38:11 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIE5q-0008TP-79 for kitten@ietf.org; Tue, 29 Aug 2006 20:38:11 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7U0c6uZ003860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 20:38:06 -0400 (EDT) Date: Tue, 29 Aug 2006 20:38:06 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov Message-ID: <1D4168226C33C62D4056349E@sirius.fac.cs.cmu.edu> In-Reply-To: <20060829205723.GM10458@binky.Central.Sun.COM> References: <20060829205723.GM10458@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01xg8Q3DB3hVASWohd+Y1AS12BRwdNQ4kzhD5B/I8=; 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: 2086112c730e13d5955355df27e3074b Cc: Jeffrey Hutzelman Subject: Re: Proposed updates for domain-based drafts 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 Tuesday, August 29, 2006 03:57:24 PM -0500 Nicolas Williams wrote: > Issues that came up: > > - Sam wanted a better outline of how applications might use > domain-based names. I'm not sure whether Sam wants text for the > drafts or merely discussion on the list. Neither am I, but I thought the original point was to demonstrate that domain-based names as specified are workable in practice. To that end, I will note that there is an existing widely-deployed implementation of LDAP using GSS-krb5 with domain-based service names substantially as specified here. We've also discussed how to make use of them in SSH and in NFSv4, and in neither case is the answer Kerberos-specific. It seems clear that the determination of when to use the domain-based name form must be made by the application. In the case of NFSv4, the client knows a priori whether it is supposed to be mounting an individual fileserver or the root of a namespace belonging to some domain, and domain-based names are used only in the latter case. Referrals always list the names of one or more specific servers, and the mounts resulting from them would always use host-based names. In the case of SSH, the use of domain-based names for key exchange would be negotiated by the use of an alternate family of algorithm names; an SSH server would be required to know whether it possesses suitable acceptor credentials for use with domain-based names, and only advertise the mechanism in that case. This is similar to the current model, in which an SSH server only advertises support for GSS-API mechanisms for which it has acceptor credentials. I don't think it's necessary for this document to describe how domain-based names might be used in existing protocols. In fact, I believe that doing so may be actively harmful, because it may lead to people treating such text as if it were a mature protocol specification rather than a proof-of-concept, possibly even after a real spec has been published. > - A clarification on just what is a "domain" You haven't actually said anything here in response to this, but we discussed this offline and I believe we came to the conclusion that the determination of the correct domain to use is up to the application. In particular, we have between us seen at least three possible choices, depending on the intended use: - For services for which service for a specified domain is provided by one or more servers identified by SRV records or some similar mechanism, you probably want to use the same base domain name used to construct the names of SRV records. For example, if you are connecting to the LDAP service for the domain EXAMPLE.ORG, you'd look for DNS SRV records under the name _ldap._tcp.EXAMPLE.ORG, and use a domain-based service name like LDAP@example.org@ldap1.example.org. This is probably the correct model for LDAP, and also for NFSv4. - For services for which service for a single name may be provided by one or more servers sharing a name, you probably want to use the shared name as the domain name, and obtain hostnames by reverse resolution. This is the model I'd expect to see used for SSH (for example, to provide a pool of time-sharing machines behind a single hostname). - Nico envisioned services in which one might provide different "instances" for the same domain name, which would necessitate building domain-based service names using the full name used to construct SRV records (for example, FOOBAR@_foobar._tcp.example.com@foobar1.example.com) and/or attach some instance designator to the domain name. I can't think of any concrete examples where this is needed, but that doesn't mean that there aren't any, or that there can't be any in the future. Essentially, the correct choice of name form really needs to be up to the application, or at least to something above the GSS-API layer. We might provide examples like the ones I just gave, but I don't think that's necessary, either; the existing text seems fine on this point. > - A new feature in the Kerberos V GSS-API mechanism relating to > domain-based names: initiator-side fallback on hostbased naming > with domainnames as hostnames with acceptor-side acceptor > credential sharing. > With respect to SASL I believe there is nothing for either of these two > I-Ds to say on the matter. I believe applications and SASL/GS1 and/or > SASL/GS2 will require updating to specify use of domain-based names in > SASL contexts. I don't believe that we absolutely must update the SASL > base specification to introduce new kinds of server names, but I don't > mind us doing so -- either way the I-Ds we're considering in this WGLC > are unaffected. I believe there is clearly work to be done in this area as it relates to SASL. The question of whether and when to use domain-based names and of what domain name to use needs to be answered, and in the case of SASL, it is likely to be application-specific. However, we need to be careful not to introduce unnecessary complexity or a need for applications to have mechanism-specific knowledge. In any event, I agree with Nico that neither of Kitten's domain-based name drafts need to address the SASL question. > After some off-line discussion with Jeff about his proposed new feature > we reached a compromise. We propose the following change to > draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt: > > - GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal > - names as follows: > + GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V > + principal names as follows: > > This will allow for a future document that specifies Jeff's fallback > feature. In fact, it retains nearly all the strength of the original statement, while still allowing for compliant implementations that can be configured to map domain-based names differently. I believe that SHOULD as defined in RFC2119 is quite strong enough for this purpose. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 20:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE8W-0001xx-3B; Tue, 29 Aug 2006 20:40:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE8U-0001xR-N8; Tue, 29 Aug 2006 20:40:54 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIE8S-0000Ta-PG; Tue, 29 Aug 2006 20:40:54 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0epgn021406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 17:40:51 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0epgs025118 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 17:40:51 -0700 Date: Tue, 29 Aug 2006 17:38:49 -0700 (Pacific Daylight Time) From: Mark Crispin To: Jeffrey Hutzelman In-Reply-To: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.172443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P3_4 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 29 Aug 2006, Jeffrey Hutzelman wrote: >> I have no idea what version of GSSAPI I implemented against. > You used an API without paying attention to what version of the API you were > using? How is that my problem? At the time that RFC 2222 came out, there was no mention of backward incompatibility in GSSAPI versions, nor of tests to determine which version to use. Do you expect that, years ago, I would somehow use some crystal ball to know about something happened in the future? >> I followed >> the instructions in RFC 2222. > ... without reading the documents to which it referred, apparently. What are you talking about? RFC 2222 refers to RFC 2078. RFC 2078 says nothing whatsoever about integ_req_flag. RFC 2078 talks about GSSAPI versions, but says little about them other than passing references to interfaces maintained for compatibility with earlier versions. > This is > precisely the reason for stating the requirement to set integ_req_flag in > this new document - because if we don't, then people implementing the > mechanism won't bother to read the GSS-API documents, even though they're > writing what is essentially a GSS-API application, and will miss this > requirement. Regardless of whether that statement is true or not, it does not apply to me. I read RFC 2078. Cover to cover. I did what it said. > RFC 2743 defines the GSS-API v2.1, which is an abstract API. My code was written two years before RFC 2743 existed!! RFC 2743 may have superceded RFC 2078. However, the normative reference in RFC 2222 is to RFC 2078. That didn't change when RFC 2743 was released. You can not declare a RFC 2222 implementation to be broken, defective, or whatever for not complying with a specification that did not even exist when the implementation was written. > If you are actually _implementing_ a protocol that uses the GSS-API, then you > also need to read the language bindings document for the language you are > using; for C, this is RFC 2743. Has CMU built a working time machine, and have they sent that time machine back to 1998? If not, please explain how, in 1998, an implementor could possibly comply with the requirements of RFC 2743 which was issued in 2000. >> If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is >> not in the "old API"? If this is the "new API", then how does my code, >> written to comply with RFC 2222, build under it? > Well, given that GSS_C_INTEG_FLAG exists, I'd guess that the library you're > building against is an implementation of GSS-API v2.1. To be sure, you > should probably check whatever documentation came with it. That is not a particularly helpful comment. Not everybody uses a system that they personally built from individual libraries. Many people use systems that were built from others. > Presumably, your code builds because the API was designed to be (mostly) > backward-compatible. I agree that the "mostly" is unfortunate and creates an > increased burden for the developer of GSS-API-using applications, since > existing users of GSS_Init_sec_context may build even though the interface > changed in a backward-incompatible way. Here's the crux of the matter. Both RFC 2078 and RFC 2743 talk about "full, transparent backward compatibility" and the necessity to maintain the GSS_Sign, GSS_Verify, GSS_Seal, and GSS_Unseal interfaces for backward compatibility. What's new in RFC 2743 is this text, buried in 2.2.1: [...] It is important to recognize, however, that the inclusion of these flags (which are newly defined for GSS-V2) introduces a backward incompatibility with callers implemented to GSS-V1, where the flags were not defined. Since no GSS-V1 callers would set these flags, even if per-message services are desired, GSS-V2 mechanism implementations which enable such services selectively based on the flags' values may fail to provide them to contexts established for GSS-V1 callers. It may be appropriate under certain circumstances, therefore, for such mechanism implementations to infer these service request flags to be set if a caller is known to be implemented to GSS-V1. This text is wrong in saying "GSS-V2" because RFC 2078 is silent on this matter and describes Version 2. It's actually newly defined for Version 2, Update 1. In any case, RFC 2222 callers are known to be implemented to pre-V2.1 versions of GSSAPI. > You're calling GSS_Wrap. RFC2743 is clear on what you have to do for that to > work. True, RFC2078 said no such thing, and your implementation is compliant > with 2222 and 2078, at least in this respect. If you want to upgrade to an > implementation of the new API, you have to make whatever changes are required > to do so. I want the existing installed base to continue to work. I'll happily update new releases to comply with the draft (replacing RFC 2222), which uses RFC 2743 normatively rather than RFC 2078. I object to the implication that it is somehow my fault that in 1998 I lacked the clairvoyance to know about an incompatible change that would take place in 2000. I object to my existing releases being labelled non-compliant. >> Now you tell me that it does, and that it's all my fault for making the >> false assumption that I had integrity when I did not. The problem with >> that is that it assumes that I, implementing from RFC 2222, knew enough >> about the internals of GSSAPI to make that kind of assumption. > Right; you read RFC2222 and apparently didn't bother to read 2078 or 1509 in > detail. That's kind of poor, but it's also to be expected Just where did you get that notion? I read RFC 2078. Cover to cover. I am starting to get angry. Please point to text in RFC 2078 that states the requirement to have ESP to know that an incompatible change would take place two years later. Please point to text in RFC 2078 that implies that GSSAPI would be so callous about the question of background incompatibility. I also see that RFC 2743 practically apologizes for creating a backwards incompatibility on page 97: [...] (Note: this facility introduces a backward incompatibility with GSS-V1 callers, discussed in Section 2.2.1; this implication was recognized and accepted in working group discussion.) Quite frankly, the working group did a lousy job, both in creating the incompatibility and in failing to communicate it to people who had used RFC 2078 in the past. > The other thing you also did, apparently, was to take your RFC2222 > implementation and use it with a newer version of the GSS-API than was used > by that document. How the hell am I supposed to know that? Do you really believe that, prior to any compilation, a developer goes and checks the version numbers and seeks out the release notes of every single API, DLL, shared library, etc. ad nauseum that his application might use? > Now, RFC2222 couldn't possibly have warned you about > changes required by RFC2743. The new specification can, and should. And I made the change in the new release. But that doesn't do anything about the tens of thousands of copies released using the information in the old documents. >> RFC 2222 goes to great efforts to hide what GSSAPI does. > From application protocol designers and implementors, not from mechanism > implementors. You wouldn't expect to implement TCP without understanding IP, > would you? Have you ever implemented a TCP? I have. I've also done an NCP. One thing that you learn from the experience is to keep layers separate, and treat published interfaces as holy. > You'd have the same problem if you wrote your application against an older > version of some Kerberos API If I had known that the Kerberos API developers were so incompetant in maintaining API compatibility, I would have implemented the entire protocol by hand. That way, I wouldn't be vulnerable to capricious changes in the API. They may change the bits on the wire, but not without breaking their software as much as they break mine. > When RFC2222 was written, its authors told you about what you needed to do in > order to use the version of the GSS-API that was available at that time. Now, > we're telling you what you need to do in order to use the version of the > GSS-API that's available now. It is still incumbent upon GSSAPI to maintain backwards compatibility. > What you're suggesting is that the new spec _not_ document a new requirement > of the GSS-API, because your implementation which was designed for the old > GSS-API fails to meet the requirements of the new one. That's just insane. I never said any such thing. I said that the fact that this is a new requirement needs to be explicitly documented in a changes section; and furthermore there should be a recommendation (as there is in RFC 2743) that GSSAPI implementations not enforce this requirement due to backward compatibility for RFC 2222 implementations. >> What is "an RFC2222 implementation...with integ_req_flag"? RFC 2222 is >> silent on the matter. > I mean an RFC2222 implementation, built against a RFC2743 implementation, > which sets integ_req_flag in its calls to GSS_Init_sec_context. In other > words, what _should_ be the result of forward-porting an existing RFC2222 > implementation to the new API. How does that differ from an RFC xxxx implementation (where xxxx is whatever RFC number this draft gets)? You still haven't answered what happens with the RFC 2222 implementations that are already out there. Nobody wants (or not wants) them to be built against RFC 2743. It just happens. > It's not a bug in 2222; the flag didn't exist then. > It's also not a change in GSSAPI 2.1 that broke 2222, because 2222 refers to > RFC2078, which defines GSSAPI 2.0. There's a reason why we generally make > references to immutable identifiers like RFC's, rather than to STD numbers, > and this situation illustrates that reason perfectly. In that case, then this new draft can not define the GSSAPI SASL mechanism, because that mechanism is defined by RFC 2222 and the new draft is incompatible. The new draft must therefore define the GSSAPIv21 SASL mechanism. > I will agree that GSSAPI v2.1 is incompatible with older versions in this > respect. I'll even agree that the new functionality could have been added in > a way that was not backward-incompatible. However, that was over 6 years > ago, before I was involved in the IETF, and it's pretty much a done deal now. What were you doing before you were involved in the IETF? > Implementors who followed RFC 2222, including using an implementation of the > GSS-API as specified in RFC 2078, are indeed not to blame for the situation. > Those who updated their implementations to use a newer implementation of the > GSS-API without dealing with new requirements that RFC 2222 could not > possibly have known about, have less of a leg to stand on. I am not aware of having updated my implementation to use a newer implementation of GSSAPI. What you think that I did so? Do you think that compiling my application after 2000 constitutes "updating my implementation to use a newer version of GSSAPI"? >> (2) RFC 2222 implementors MUST take note of the new requirement to set >> integ_req_flag, and MUST upgrade their implementations. Although all >> known GSSAPI 2.1 implementations treat it as set, this behavior can >> not be relied upon. > RFC 2222 is immutable. To say "RFC 2222 implementors MUST..." is > nonsensical. Implementors of _this_ spec already MUST set the flag, and > anything that's not an implementation of this spec is not subject to the > requirement anyway. RFC 2222 implementors need to be informed. Their implementations may break, depending upon the caprice of whomever supplies the GSSAPI. Currently, the fact that RFC 2222 does not require the flag effectively prevents GSSAPI implementations from enforcing the requirement. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 20:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE9s-0002hH-Ih; Tue, 29 Aug 2006 20:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIE9r-0002h4-KT; Tue, 29 Aug 2006 20:42:19 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIE9q-0000ZS-9N; Tue, 29 Aug 2006 20:42:19 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0gHlb021739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 17:42:17 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0gHZ2025294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 17:42:17 -0700 Date: Tue, 29 Aug 2006 17:40:15 -0700 (Pacific Daylight Time) From: Mark Crispin To: Martin Rex In-Reply-To: <200608292355.BAA00855@uw1048.wdf.sap.corp> Message-ID: References: <200608292355.BAA00855@uw1048.wdf.sap.corp> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.172443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Martin, thank you. Now, can we get something to this effect in the document? On Wed, 30 Aug 2006, Martin Rex wrote: > I think that a client (gsssapi mechanism implementation capable of > message integrity protection) is both non-compliant with GSS-API > and seriously broken if it denies message integrity services > only because the initiator didn't assert integ_req_flag when it > called gss_init_sec_context(). > > The wording in RFC2743 is to improve "portability" for applications > even for newer negotiating mechanisms. It was never meant to > imply that it would be OK for gssapi mechanism implementations > to make stupid backwards incompatible changes just for the sake > of the fun of it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 20:43:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEBN-0003cU-Ig; Tue, 29 Aug 2006 20:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEBN-0003bx-3P; Tue, 29 Aug 2006 20:43:53 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIEBK-0000mn-Oa; Tue, 29 Aug 2006 20:43:53 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0hn2O022115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 17:43:50 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U0hnfC016354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 17:43:49 -0700 Date: Tue, 29 Aug 2006 17:41:47 -0700 (Pacific Daylight Time) From: Mark Crispin To: Jeffrey Altman In-Reply-To: <44F4AFE7.4070006@secure-endpoints.com> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.172443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 29 Aug 2006, Jeffrey Altman wrote: > does the text proposed by Sam Hartman meet your needs? It helps. Could some part of what Martin Rex wrote also be incorporated? Thanks, -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 21:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEX6-0003qD-UJ; Tue, 29 Aug 2006 21:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEX5-0003pD-87; Tue, 29 Aug 2006 21:06:19 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIELi-0002rH-Ua; Tue, 29 Aug 2006 20:54:36 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7U0sWaL004313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 20:54:32 -0400 (EDT) Date: Tue, 29 Aug 2006 20:54:32 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Sam Hartman Message-ID: <235FC6DBADC35F0FCA9257EC@sirius.fac.cs.cmu.edu> In-Reply-To: <200608292355.BAA00855@uw1048.wdf.sap.corp> References: <200608292355.BAA00855@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:01f7A8JOkYsZjL+7Slsi5skxYic08G5LXsJWqJtTA=; 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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: kitten@ietf.org, MRC@cac.washington.edu, ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Wednesday, August 30, 2006 01:55:56 AM +0200 Martin Rex wrote: > So the general recommendation of the GSS-API spec becomes even > more important: an application ought to check context attributes > when context establishment succeeds and decide whether it wants > to use the resulting security context or not Yes; this is an absolute requirement, because as defined the API is allowed to give you a context that doesn't meet your needs. This is why RFC4462, for example, clearly spells out the flags that must be checked after context establishment. I'd really prefer to see this document do the same, but we've had that argument. > The server/accepter > doesn't have a means to indicates its desires/requirements, > anyway. True, but it does have the means to check that its requirements are met by the established context. I've always believed that is was sufficient to have the input provided only by one party because both parties are implementations of the same protocol, and thus if you have a protocol in which only the acceptor generates tokens requiring integrity services, the initiator is still aware of it and can indicate the need for that service. Again, I cite RFC 4462 as an example of this -- in SSH key exchange, the SSH server acts as GSSAPI acceptor, and calls GSS_GetMic to generate the only message token ever produced using that context. The initiator never calls GSS_GetMIC, but is nonetheless required to set integ_req_flag, because the protocol requires integrity service. >> A more serious problem case is a client that does not support gss_wrap >> when integ_flag is not set in gss_init_sec_ctx. I believe such a >> client could not possibly work with RFC 2222 or this spec. However I >> think such a client is compatible with GSS-API. > > I think that a client (gsssapi mechanism implementation capable of > message integrity protection) is both non-compliant with GSS-API > and seriously broken if it denies message integrity services > only because the initiator didn't assert integ_req_flag when it > called gss_init_sec_context(). > > The wording in RFC2743 is to improve "portability" for applications > even for newer negotiating mechanisms. It was never meant to > imply that it would be OK for gssapi mechanism implementations > to make stupid backwards incompatible changes just for the sake > of the fun of it. "For the fun of it" ? Of course not. However, I can envision a mechanism for which providing integrity or confidentiality services requires an extra round trip at context establishment time, and which avoids that round trip if those services were not requested. Such a mechanism would be _unable_ to provide those services on a context if they had not been requested (and, of course, would not indicate their availability on such a context). RFC2743 indicates that these flags are provided "primarily to provide information to negotiating mechanisms" (Appendix B), but does not preclude other uses of that information. In fact, it says the following (2.2.1): ... Since no GSS-V1 callers would set these flags, even if per-message services are desired, GSS-V2 mechanism implementations which enable such services selectively based on the flags' values may fail to provide them to contexts established for GSS-V1 callers. This text clearly permits the existence of mechanisms which selectively enable confidentiality and/or integrity services on the basis of whether they are requested during context establishment. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 21:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFKJ-0008Nj-Vo; Tue, 29 Aug 2006 21:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFKJ-0008Nb-2w; Tue, 29 Aug 2006 21:57:11 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIFKI-0003Kc-HM; Tue, 29 Aug 2006 21:57:11 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7U1v5gT005607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 21:57:05 -0400 (EDT) Date: Tue, 29 Aug 2006 21:57:05 -0400 From: Jeffrey Hutzelman To: Mark Crispin Message-ID: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> In-Reply-To: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> Originator-Info: login-token=Mulberry:01GlqOx4TCAztmpQZITdi+NrHMxfKhjgeHz7wsUNo=; 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: d11a451997816a91a305dcb5ab1b85dd Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Tuesday, August 29, 2006 05:38:49 PM -0700 Mark Crispin wrote: >> RFC 2743 defines the GSS-API v2.1, which is an abstract API. > > My code was written two years before RFC 2743 existed!! > > RFC 2743 may have superceded RFC 2078. However, the normative reference > in RFC 2222 is to RFC 2078. That didn't change when RFC 2743 was > released. That is _exactly_ my point. Your implementation of RFC 2222 is compliant, as long as it is based on an implementation of RFC 2078, as specified. As soon as you compiled and linked your code against a library that implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant with RFC 2222. > You can not declare a RFC 2222 implementation to be broken, defective, or > whatever for not complying with a specification that did not even exist > when the implementation was written. I'm not doing any such thing. The present document does not do any such thing. Implementations of the _present_ document will be compliant only if they use the version of the GSS-API as specified in RFC 2743, and then only if they set integ_req_flag, as required under that spec for applications which wish to use integrity services. >> Presumably, your code builds because the API was designed to be (mostly) >> backward-compatible. I agree that the "mostly" is unfortunate and >> creates an increased burden for the developer of GSS-API-using >> applications, since existing users of GSS_Init_sec_context may build >> even though the interface changed in a backward-incompatible way. > > Here's the crux of the matter. Both RFC 2078 and RFC 2743 talk about > "full, transparent backward compatibility" and the necessity to maintain > the GSS_Sign, GSS_Verify, GSS_Seal, and GSS_Unseal interfaces for > backward compatibility. > > What's new in RFC 2743 is this text, buried in 2.2.1: > > [...] It is important to recognize, however, that > the inclusion of these flags (which are newly defined for GSS-V2) > introduces a backward incompatibility with callers implemented to > GSS-V1, where the flags were not defined. Since no GSS-V1 callers > would set these flags, even if per-message services are desired, > GSS-V2 mechanism implementations which enable such services > selectively based on the flags' values may fail to provide them to > contexts established for GSS-V1 callers. It may be appropriate under > certain circumstances, therefore, for such mechanism implementations > to infer these service request flags to be set if a caller is known > to be implemented to GSS-V1. > > This text is wrong in saying "GSS-V2" because RFC 2078 is silent on this > matter and describes Version 2. It's actually newly defined for Version > 2, Update 1. That is correct; the change actually occurred in Version 2, Update 1. I have no idea why this text talks about GSS-v1 vs GSS-v2 rather than about GSS-v2 vs GSS-v2u1, but the principle is the same. >> You're calling GSS_Wrap. RFC2743 is clear on what you have to do for >> that to work. True, RFC2078 said no such thing, and your >> implementation is compliant with 2222 and 2078, at least in this >> respect. If you want to upgrade to an implementation of the new API, >> you have to make whatever changes are required to do so. > > I want the existing installed base to continue to work. The existing installed base of RFC2222-compliant implementations will continue to work. Any installed base consisting of code that started as an RFC2222-compliant implementation and then had its GSS-v2 replaced by GSS-v2u1 is not compliant with anything, but will probably work anyway. > I'll happily update new releases to comply with the draft (replacing RFC > 2222), which uses RFC 2743 normatively rather than RFC 2078. And compliant implementations of the new draft, using RFC4422 and RFC2743, will also work, provided the requirement we are talking about is met. If we removed the requirement, then "compliant" implementations that fail to meet it might still fail to interoperate. Again, that's unlikely, but only because the present document is restricted to the Kerberos mechanism. > I object to the implication that it is somehow my fault that in 1998 I > lacked the clairvoyance to know about an incompatible change that would > take place in 2000. I object to my existing releases being labelled > non-compliant. Do you seriously think anyone is going to fault your RFC2222 implementation for not being compliant with the new specification? I doubt it. It is _not_ a requirement, and never has been, that a new protocol specification be written such that older implementations be compliant with the new spec. That would be silly, as it would essentially prevent the introduction of new features. What is and has been at least strongly desired, if not actually required, is that a new protocol specification be written such that compliant implementations of the old version will interoperate with compliant implementations of the new version. I believe we have done that here. > I read RFC 2078. Cover to cover. I am starting to get angry. I'm sorry; I misspoke, and probably more than once. What I meant to say was that you apparently did not read RFC2743 before starting to use a newer GSSAPI library based on it. I say that because I fail to understand how you could have read RFC 2743 and _not_ noticed the warning about the backward incompatibility. I suppose you could have seen the warning and not realized it was relevant to what you were doing, but you can hardly fault RFC 2222 for not pointing out the issue. And chances are that even if you did, you _still_ have nothing to worry about, because (a) the library you are using probably sets the bit on the wire even if you don't request it (b) the library you are using implements GSS_Wrap correctly, including producing tokens with correct integrity checks, even if you didn't request integrity service (if this were not true, you'd already be seeing serious interop problems) (c) the chance that any acceptor you talk to will fail to implement GSS_Unwrap correctly even if the bit was not set on the wire is vanishingly small(*) Nonetheless, you've said several times that you shouldn't need to understand the internals of GSS-API. To a certain extent, I agree with that sentiment, which is why things like the need to set integ_req_flag need to be spelled out in the SASL GSSAPI mechanism specification. Otherwise, someone's going to miss it. > I also see that RFC 2743 practically apologizes for creating a backwards > incompatibility on page 97: > [...] (Note: this facility introduces a > backward incompatibility with GSS-V1 callers, discussed in Section > 2.2.1; this implication was recognized and accepted in working > group discussion.) > > Quite frankly, the working group did a lousy job, both in creating the > incompatibility and in failing to communicate it to people who had used > RFC 2078 in the past. I agree that the working group did a lousy job in creating the incompatibility, particularly since I can see a trivial way they could have avoided the problem. However, I take no responsibility for that; I wasn't involved in the IETF when that document was published. I disagree that they failed to communicate the incompatibility to users of RFC 2078. I think it was entirely reasonable of them to expect that users of RFC 2078 who wanted to use the new version would read RFC 2743, which points out the problem in two places. >> The other thing you also did, apparently, was to take your RFC2222 >> implementation and use it with a newer version of the GSS-API than was >> used by that document. > > How the hell am I supposed to know that? > > Do you really believe that, prior to any compilation, a developer goes > and checks the version numbers and seeks out the release notes of every > single API, DLL, shared library, etc. ad nauseum that his application > might use? I expect you to know the versions of things your building against, yes, at least in the cases where it's relevant. This is a documented interface which has multiple versions; I believe it's reasonable to expect you to know what version you're using. I certainly know of plenty of software which checks at build time that the available libraries are suitable for its needs, and I also know of some very widely used libraries whose API's are well-known for changing significantly at the drop of a hat. > One thing that you learn from the experience is to keep layers separate, > and treat published interfaces as holy. And another thing you learn, or should, is that stable interfaces, aren't. As you pointed out, RFC 2222 refers to 2078, not 2743. There's a good reason for that. Specifications change. Using a stable reference means that the meaning of RFC 2222 doesn't change out from under you. > It is still incumbent upon GSSAPI to maintain backwards compatibility. No, it's not. I agree that it would be best if it did so, >> What you're suggesting is that the new spec _not_ document a new >> requirement of the GSS-API, because your implementation which was >> designed for the old GSS-API fails to meet the requirements of the new >> one. That's just insane. > > I never said any such thing. You objected to the MUST. > I said that the fact that this is a new requirement needs to be > explicitly documented in a changes section; and furthermore there should > be a recommendation (as there is in RFC 2743) that GSSAPI implementations > not enforce this requirement due to backward compatibility for RFC 2222 > implementations. GSS-API implementors are not implementors of this document. A recommendation to them in this document is useless, because they have no reason to read it. > How does that differ from an RFC xxxx implementation (where xxxx is > whatever RFC number this draft gets)? I believe I answered that in the following paragraph. It shouldn't differ at all, provided there are no other differences between the present document and the mechanism as specified in RFC 2222(*). I say "shouldn't" because there is always the possibility of an error. (*) At this point, I feel compelled to point out to observers that RFC 2222 contains the previous versions of both the base SASL specification, now RFC 4422, and the SASL GSSAPI mechanism which is the subject of the present document. > You still haven't answered what happens with the RFC 2222 implementations > that are already out there. Nobody wants (or not wants) them to be built > against RFC 2743. It just happens. That is true, it does happen. In fact, it is frequently the case that some spec "A" refers to a particular verison of spec "B", but implementations of "A" become commonplace in which the "B" component has been replaced by a newer version. I agree that as protocol designers and implementors, we should strive to make those cases work whenever possible, because the alternative is an unsustainable tangled mass of different versions of things. So, what happens when code that was written as an implementation of RFC 2222 in terms of some GSS-v2 is instead built against GSS-v2u1? Well, the usual thing happens - you end up with something that is technically not compliant with any specification, but works just fine. Let me repeat that... Your existing deployed code will work JUST FINE. If someone comes to you and tells you they built it against a newer GSS-API library and it didn't work, you say "well, it was designed for the version of GSS-API specified by RFC 2222; if you want to use something newer, you may have to upgrade". I don't think that's at all unreasonable. >> It's not a bug in 2222; the flag didn't exist then. >> It's also not a change in GSSAPI 2.1 that broke 2222, because 2222 >> refers to RFC2078, which defines GSSAPI 2.0. There's a reason why we >> generally make references to immutable identifiers like RFC's, rather >> than to STD numbers, and this situation illustrates that reason >> perfectly. > > In that case, then this new draft can not define the GSSAPI SASL > mechanism, because that mechanism is defined by RFC 2222 and the new > draft is incompatible. No; that is not the case. RFC 2222 implementations will not be compliant with the new draft, but that's to be expected. They _will_ interoperate with implementations of the new draft. This is not a different mechanism. >> I will agree that GSSAPI v2.1 is incompatible with older versions in >> this respect. I'll even agree that the new functionality could have >> been added in a way that was not backward-incompatible. However, that >> was over 6 years ago, before I was involved in the IETF, and it's >> pretty much a done deal now. > > What were you doing before you were involved in the IETF? I don't think that's relevant to the present discussion, and I doubt the entire memberships of the SASL and Kitten WG's and the entire IESG are interested in the tangent. I'll be happy to take it offline, if you wish. >> the GSS-API as specified in RFC 2078, are indeed not to blame for the >> situation. Those who updated their implementations to use a newer >> implementation of the GSS-API without dealing with new requirements >> that RFC 2222 could not possibly have known about, have less of a leg >> to stand on. > > I am not aware of having updated my implementation to use a newer > implementation of GSSAPI. What you think that I did so? > > Do you think that compiling my application after 2000 constitutes > "updating my implementation to use a newer version of GSSAPI"? Not if you compiled it against a GSS-v2 library. If you compiled it against a GSS-v2u1 library, then yes. Or rather, that would be "using a newer version of GSSAPI without making changes to your application", but that's what I meant. > Currently, the fact that RFC 2222 does not require the flag effectively > prevents GSSAPI implementations from enforcing the requirement. No, it doesn't. It means that code intended as an RFC 2222 implementation may not work if built against the wrong GSS-API library. But since the reality is that they almost certainly will, I really think you're making a mountain out of a molehill. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 22:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFqo-0005JO-Bx; Tue, 29 Aug 2006 22:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFqn-0005ID-1O; Tue, 29 Aug 2006 22:30:45 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIFpw-0000JZ-Mm; Tue, 29 Aug 2006 22:29:54 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7U2ThCB006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 22:29:44 -0400 (EDT) Date: Tue, 29 Aug 2006 22:29:43 -0400 From: Jeffrey Hutzelman To: Mark Crispin , iesg@ietf.org Message-ID: <4A113AAA82F668DBA2401EE9@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01z9is8jlAIWYbIyRzAlbcYWZK4x1WDCU8TdpXBVg=; 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: d185fa790257f526fedfd5d01ed9c976 Cc: kitten@ietf.org, ietf-sasl@imc.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, August 28, 2006 01:39:42 PM -0700 Mark Crispin wrote: > I request consideration of the following changes prior to publication. > > Page 4, first paragraph, please change: > [...] When calling the GSS_Init_sec_context the client > MUST pass the integ_req_flag of TRUE. > to > [...] When calling the GSS_Init_sec_context the client > SHOULD pass the integ_req_flag of TRUE. > > Otherwise, publication of this document would have the effect of > declaring existing deployed software to be non-compliant. I agree that > this change is desirable, but I disagree about retroactively declaring > existing software broken. If the WG feels strongly enough, it'd be > alright to have something in the security considerations saying that > earlier versions did not require the integ_req_flag, but all new > implementations ought to have it and old implementations fixed. We've been arguing in another thread, but I think that's starting to get too convoluted and maybe we can make things a little simpler. Your original concern as stated above seems to be that the MUST in the present draft "declares existing deploted software to be non-compliant". I do not believe that is the case. Certainly existing deployed software will be non-complient _with the new specification_, but that's OK. If it complies with RFC 2222, then it will _interoperate_ with implementations of the new draft, which is all that is needed. As discussed, the quoted requirement, which is new in this version, reflects a change in the GSS-API. The API change is backward-incompatible, meaning that code written to the old API may not obtain the expected results when linked against the new API. RFC 2222 specified the use of the old API (the new one did not yet exist), while this document specifies the use of the new; thus the difference. You also expressed concern about what would happen when application code written to RFC 2222 is built against a new version of the API without changes to reflect the API change. The answer is that the result would be technically noncompliant with RFC 2222 (but only with respect to the choice GSS-API version) and would also fail to meet the new requirement introduced by RFC 2743 (of course, there's no reason to expect it to do so), but that it will almost certainly work anyway. This is particularly true with respect to the Kerberos GSS-API mechanism, to which the present spec is limited, because that mechanism does not prescribe any differences in behavior depending on whether the integ_req_flag is set. Sam proposed text describing the reason for the new requirement. Aside from the references to RFC 1508 where RFC 2078 should be referenced, I have no objections to that text. Martin Rex discussed the history of integ_req_flag, and his view of what its intended purpose was, and you (Mark) proposed including some portion of that in the present document. While I have no doubt that much of what he says is true (and, in fact, it is partially supported by RFC 2743), Martin's explanation is not normative, and RFC 2743 does not restrict the use of these flags to the uses described by Martin. Thus, I would consider the addition of such text to constitute an attempt to make a normative change to GSS-API Version 2 Update 1, and thus out of scope for this document and for the SASL working group. I also believe that such a change would be backward-incompatible, compounding the original error, and thus is unsuitable for inclusion in any update to GSS-API Version 2 (KITTEN is chartered to produce such an update, but is constrained from including incompatible changes). However, KITTEN is also chartered to produce a possibly-incompatible GSS-API Version 3, and should take care to learn from this discussion. In particular, at a minimum a GSS-API v3 should provide a mechanism by which it can be clearly distinguished from earlier versions of the API, as well as a mechanism by which future incompatible updates can be detected. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Aug 29 22:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIG6o-0003Py-E6; Tue, 29 Aug 2006 22:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIG6n-0003Pf-FR; Tue, 29 Aug 2006 22:47:17 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIG6k-0002p9-Td; Tue, 29 Aug 2006 22:47:17 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U2lDaJ020183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 19:47:13 -0700 X-Auth-Received: from Shimo-Tomobiki.panda.com ([38.100.227.2]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U2lBHj026082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Aug 2006 19:47:12 -0700 Date: Tue, 29 Aug 2006 19:47:10 -0700 From: Mark Crispin To: Jeffrey Hutzelman In-Reply-To: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.192442 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, 29 Aug 2006, Jeffrey Hutzelman wrote: > As soon as you compiled and linked your code against a library that > implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant > with RFC 2222. That is not an acceptable outcome. > And compliant implementations of the new draft, using RFC4422 and RFC2743, > will also work, provided the requirement we are talking about is met. If we > removed the requirement, then "compliant" implementations that fail to meet > it might still fail to interoperate. Again, that's unlikely, but only > because the present document is restricted to the Kerberos mechanism. That's what the GSSAPI mechanism > Do you seriously think anyone is going to fault your RFC2222 implementation > for not being compliant with the new specification? I doubt it. If it suddenly breaks, they will. That's what happens when software breaks. And should that happen, I will not have kind things to say about the people involved with GSSAPI. > It is _not_ a requirement, and never has been, that a new protocol > specification be written such that older implementations be compliant with > the new spec. That would be silly, as it would essentially prevent the > introduction of new features. It is most certainly a requirement that a protocol specification update not break compliant implementations written to an earlier specification. If an incompatibility must be introduced, there is a versioning mechanism that enables the new stuff only between consenting implementations. > What is and has been at least strongly desired, if not actually required, is > that a new protocol specification be written such that compliant > implementations of the old version will interoperate with compliant > implementations of the new version. I believe we have done that here. No you have not. You have said that merely recompiling the software against a GSSAPI library that happens to be v2.1 will break software written before v2.1 exists -- and with NO notification to the person doing the recompilation. That ain't interoperability. >> I read RFC 2078. Cover to cover. I am starting to get angry. > I'm sorry; I misspoke, and probably more than once. What I meant to say was > that you apparently did not read RFC2743 before starting to use a newer > GSSAPI library based on it. I recompile my implementation. How the hell am I supposed to know what RFC the GSSAPI library is based upon? I didn't install GSSAPI. How the hell is anyone building my software supposed to know what RFC the GSSAPI library is based upon? It is idiotic to require that someone doing a "make" command must read some set of obtuse RFCs first, on the possibility that some OTHER software changed unbeknownst to that person. > And chances are that even if you did, you _still_ have nothing to worry > about, because > (a) the library you are using probably sets the bit on the wire even if > you don't request it Then make that "probably" into a SHOULD, due to the compatibility issue. > (b) the library you are using implements GSS_Wrap correctly, including > producing tokens with correct integrity checks, even if you didn't > request integrity service (if this were not true, you'd already be > seeing serious interop problems) Another SHOULD that is currently missing and needs to be there due to the compatibility issue. > (c) the chance that any acceptor you talk to will fail to implement > GSS_Unwrap correctly even if the bit was not set on the wire is > vanishingly small(*) A third SHOULD that is currently missing and needs to be there due to the compatibility issue. > Nonetheless, you've said several times that you shouldn't need to understand > the internals of GSS-API. To a certain extent, I agree with that sentiment, > which is why things like the need to set integ_req_flag need to be spelled > out in the SASL GSSAPI mechanism specification. Otherwise, someone's going to > miss it. Needs to be spelled out for new implementations. That doesn't help the tens of thousands of older versions out there. > I disagree that they failed to communicate the incompatibility to users of > RFC 2078. I think it was entirely reasonable of them to expect that users of > RFC 2078 who wanted to use the new version would read RFC 2743, which points > out the problem in two places. You falsely assume that a user of RFC 2078 has nothing to do but to read new RFCs, especially when the project to develop RFC 2078 software has finished and all that is being done now is *using* that software. > I expect you to know the versions of things your building against, yes, at > least in the cases where it's relevant. This is a documented interface which > has multiple versions; I believe it's reasonable to expect you to know what > version you're using. That is totally unreasonable. > And another thing you learn, or should, is that stable interfaces, aren't. As > you pointed out, RFC 2222 refers to 2078, not 2743. There's a good reason > for that. Specifications change. Using a stable reference means that the > meaning of RFC 2222 doesn't change out from under you. But the meaning has changed. You claim that, magically, RFC 2222 software suddenly has to comply with RFC 2743; and that this magic happens at the time that some "make" command is done. > >>> What you're suggesting is that the new spec _not_ document a new >>> requirement of the GSS-API, because your implementation which was >>> designed for the old GSS-API fails to meet the requirements of the new >>> one. That's just insane. >> I never said any such thing. > You objected to the MUST. I suggested that the MUST be a SHOULD. Given the stated desire to make this be a requirement in new implementations, I backed off for a SHOULD in GSSAPI that preserved compatibility -- something that purportedly every GSSAPI implementation already does. > GSS-API implementors are not implementors of this document. A recommendation > to them in this document is useless, because they have no reason to read it. RFC 2222 implementors are not implementors of RFC 2743. A requirement that RFC 2222 implementors follow RFC 2743 is useless, because they have no reason to read RFC 2743. Therefore, because RFC 2222 does not require the flag, GSSAPI implementations used by RFC 2222 software are forbidden to require it. All GSSAPI implementors must have a magic crystal ball. And they must know about this even if they didn't read RFC 2222. Happy now? > Your existing deployed code will work JUST FINE. > If someone comes to you and tells you they built it against a newer GSS-API > library and it didn't work, you say "well, it was designed for the version of > GSS-API specified by RFC 2222; if you want to use something newer, you may > have to upgrade". I don't think that's at all unreasonable. Please remind me never to buy a product from any company that you work at. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 00:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIHlO-0005lo-83; Wed, 30 Aug 2006 00:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIHlM-0005ld-NS; Wed, 30 Aug 2006 00:33:16 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIHlL-0007Im-Cw; Wed, 30 Aug 2006 00:33:16 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7U4X882009428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 00:33:08 -0400 (EDT) Date: Wed, 30 Aug 2006 00:33:08 -0400 From: Jeffrey Hutzelman To: Mark Crispin Message-ID: <7A692D3BA9139D7CDE7B55EB@sirius.fac.cs.cmu.edu> In-Reply-To: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Originator-Info: login-token=Mulberry:01d2jXpeHQTBnDs08mquYHFA7aDtD+nFDk3QUKreg=; 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Tuesday, August 29, 2006 07:47:10 PM -0700 Mark Crispin wrote: > On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote: >> As soon as you compiled and linked your code against a library that >> implementated RFC 2743/2744 instead of RFC 2078, it ceased to be >> compliant with RFC 2222. > > That is not an acceptable outcome. Acceptable or not, it's what happens. RFC 2222 makes reference to RFC 2078; using another version is noncompliant. If you prefer, you can think of your source code as complying with RFC 2222 and RFC 2078, and of RFC 2078 and RFC 2743 being incompatible with each other in such a way that your 2078-user might break when linked against a 2743-provider. The effect is the same. >> And compliant implementations of the new draft, using RFC4422 and >> RFC2743, will also work, provided the requirement we are talking about >> is met. If we removed the requirement, then "compliant" >> implementations that fail to meet it might still fail to interoperate. >> Again, that's unlikely, but only because the present document is >> restricted to the Kerberos mechanism. > > That's what the GSSAPI mechanism Huh? Looks like something got cut out here. >> It is _not_ a requirement, and never has been, that a new protocol >> specification be written such that older implementations be compliant >> with the new spec. That would be silly, as it would essentially >> prevent the introduction of new features. > > It is most certainly a requirement that a protocol specification update > not break compliant implementations written to an earlier specification. > If an incompatibility must be introduced, there is a versioning mechanism > that enables the new stuff only between consenting implementations. What do you mean by "break" here? We _are_ talking about the SASL GSSAPI mechanism, right? There is nothing in draft-ietf-sasl-gssapi-07.txt that breaks implementations of the SASL GSSAPI mechanism as defined in RFC 2222 7.2. > You have said that merely recompiling the software against a GSSAPI > library that happens to be v2.1 will break software written before v2.1 > exists -- and with NO notification to the person doing the recompilation. Actually, I've said it _may_ break that software, but probably won't. Not because I think that's a good way for things to be, but because that's the way things _are_. I'm confused as to what change you think should be made to draft-ietf-sasl-gssapi-07.txt to change this. We seem to agree that the CAT working group made a mistake back in 1999 or so when RFC 2743 was written. In fact, we seem to be in violent agreement on that point. Can we stop wasting time on it? In fact, I'm going to try to prune any threads which are merely reexpressions of how much you hate the backward-incompatible change or how wrong it was or how I must be making all sorts of ludicrous assumptions when I tell you that the API has changed and there's nothing we can do about it. >> (a) the library you are using probably sets the bit on the wire even if >> you don't request it >> (b) the library you are using implements GSS_Wrap correctly, including >> producing tokens with correct integrity checks, even if you didn't >> request integrity service (if this were not true, you'd already be >> seeing serious interop problems) >> (c) the chance that any acceptor you talk to will fail to implement >> GSS_Unwrap correctly even if the bit was not set on the wire is >> vanishingly small(*) So, these are predictions I made about your software, based on the assumption that it is probably compiled against one of a small number of widely-deployed implementations of the Kerberos GSS-API mechanism which happen to have these behaviors (actually, (c) is not a prediction about your software, but about software yours is likely to talk to). You seem to be suggesting that someone somewhere should produce a document which changes the behavior of existing implementations of that mechanism which do not already behave as described above. I don't see that happening. I also don't see a change to the GSS-API, Version 2 imposing those requirements on all mechanisms, partly because the "bit on the wire" in question is specific to the Kerberos mechanism and partly because not all mechanisms support integrity service at all. You could propose an update to the Kerberos GSS-API mechanism which makes those recommendations. The appropriate place to do so would be in the Kerberos working group, which is currently working on a (minor) update to that mechanism. This change isn't really in scope for that update, but if you can convince the working group to accept it, I don't think there will be a problem (note: the responsible AD might overrule me here, but I don't think he will). >> Nonetheless, you've said several times that you shouldn't need to >> understand the internals of GSS-API. To a certain extent, I agree with >> that sentiment, which is why things like the need to set integ_req_flag >> need to be spelled out in the SASL GSSAPI mechanism specification. >> Otherwise, someone's going to miss it. > > Needs to be spelled out for new implementations. Good, we agree on that. This document is for new implementations. It can't very well tell old implementations what to do. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 01:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIINp-0004ih-Bp; Wed, 30 Aug 2006 01:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIINn-0004gP-LT; Wed, 30 Aug 2006 01:12:59 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIINm-00072p-D6; Wed, 30 Aug 2006 01:12:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 27316E00C0; Wed, 30 Aug 2006 01:12:56 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Date: Wed, 30 Aug 2006 01:12:55 -0400 In-Reply-To: (Mark Crispin's message of "Tue, 29 Aug 2006 19:47:10 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: Mark> It is most certainly a requirement that a protocol Mark> specification update not break compliant implementations Mark> written to an earlier specification. Speaking as an AD, the above is not a requirement of the IETF process. It is a very good idea unless other concerns override. Mark> If an incompatibility Mark> must be introduced, there is a versioning mechanism that Mark> enables the new stuff only between consenting Mark> implementations. Again, a very good idea. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 01:21:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIVW-0008RA-9F; Wed, 30 Aug 2006 01:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIVU-0008Qw-OF; Wed, 30 Aug 2006 01:20:56 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIVR-0008R5-Ae; Wed, 30 Aug 2006 01:20:56 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5KqDx002143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 22:20:52 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5Kp7Y007949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 22:20:51 -0700 Date: Tue, 29 Aug 2006 22:20:50 -0700 (PDT) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <200608292128.XAA27487@uw1048.wdf.sap.corp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.220442 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Wed, 30 Aug 2006, Sam Hartman wrote: > Do you believe such a mechanism violates a normative requirement of RFC 2743? > If so, which requirement (textual citation appreciated)? Upon reading RFC 2743, it's difficult to say. Parts of the document imply a concern for backwards compatibility, but then there's this text on page 47: [...] It is important to recognize, however, that the inclusion of these flags (which are newly defined for GSS-V2) introduces a backward incompatibility with callers implemented to GSS-V1, where the flags were not defined. Since no GSS-V1 callers would set these flags, even if per-message services are desired, GSS-V2 mechanism implementations which enable such services selectively based on the flags' values may fail to provide them to contexts established for GSS-V1 callers. That's the problem statement. It then goes on to say: [...] It may be appropriate under certain circumstances, therefore, for such mechanism implementations to infer these service request flags to be set if a caller is known to be implemented to GSS-V1. What's stunningly absent here are any IETF normative qualifier words such as MUST [NOT], SHOULD [NOT], MAY, etc. In reading this, I really don't know what, precisely, this means. I don't know how this passed review with such ambiguous wording, but it did; so we have to guess what it all means. What makes this all more complicated is the fact that the document being considered is "The Kerberos V5 (GSSAPI) SASL mechanism". Throughout this, I have presumed that this means that the "mechanism implementation" is also Kerberos V5; and that therefore within the context of this document we can discount all other mechanism implementations. Is Kerberos V5 a mechanism implementation that "enable[s per-message] services selectively based upon the flags' value"? If so, is it "appropriate" for Kerberos V5 to infer these service request flags to be set? How does GSSAPI know that the caller is implemented to GSS-V1? If not (the Kerberos V5 mechanism implementation always enables these services), isn't the flag redundant? Is the inclusion of the flag is not because it is necessary, but rather to provide a growth path for the GSSAPI SASL mechanism to support future mechanism implementations other than Kerberos V5? If so, this can be stated with wording such as: The Kerberos V5 mechanism implementation always infers the integ_req_flag. However, to provide for future extensibility, GSSAPI SASL implementations that comply with this specification MUST explicitly set the integ_req_flag. The first sentence makes Mark Crispin happy. The second sentence establishes the new requirement and makes everybody else. Everybody is happy, we all go home. > Or are you saying that such a mechanism would be poorly designed? If > the ladder, I completely agree. If the former, I'm not finding the > text, but that doesn't mean it isn't there. I guess the question is if there is a meaningful implementation of the Kerberos V5 mechanism implementation that does not infer integ_req_flag (given that there is testimoney that one currently does not exist). If there isn't, why not say so. In such a case, I don't see why this document can not modify RFC 2743. If that isn't palatable, I believe that whatever WG is current can create an implementation recommendations document for GSSAPI that simply says "The Kerberos V5 implementation mechanism should always infer integ_req_flag". If, on the other hand, it is meaningful to implement the Kerberos V5 implementation mechanism that way, saying that such an implementation is "poorly designed" doesn't help. Since no such implementation currently exists, once again I don't see why there can't be a quick Informative RFC produced as a "GSSAPI Implementation Recommendations" to head it off. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 01:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIZD-0001aw-Ut; Wed, 30 Aug 2006 01:24:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIZD-0001aP-2V; Wed, 30 Aug 2006 01:24:47 -0400 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIZB-0000v3-Me; Wed, 30 Aug 2006 01:24:47 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5Oi28011999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 22:24:45 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5OhXK008135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 22:24:44 -0700 Date: Tue, 29 Aug 2006 22:24:43 -0700 (PDT) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.220442 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Sam Hartman wrote: > Statements about what GSS-API mechanisms should or should not do do > not belong in a SASL document. This document specifically discusses the Kerberos V5 GSSAPI mechanism and no other GSSAPI mechanism. Does that assist describing what happens vis a vis the integ_req_flag? > If you can phrase something in terms of a recommendation for SASL > implementations complying with this spec (not with RFC 2222), we can > look at it. My previous message to you offered a strawman, in the presumption that the integ_req_flag is not technically necessary today, but is made mandatory for some other reason (whether cosmetic or to allow for the extension of the GSSAPI SASL for other GSSAPI mechanisms besides Kerberos V5). I don't know if the presumption is correct though. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 01:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIsA-0001Kz-CP; Wed, 30 Aug 2006 01:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIs9-0001Kj-7b; Wed, 30 Aug 2006 01:44:21 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIs7-00046x-RW; Wed, 30 Aug 2006 01:44:21 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5iIfx023195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 22:44:19 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U5iHx9004631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 22:44:18 -0700 Date: Tue, 29 Aug 2006 22:44:17 -0700 (PDT) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.222443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Sam Hartman wrote: > Mark> It is most certainly a requirement that a protocol > Mark> specification update not break compliant implementations > Mark> written to an earlier specification. > Speaking as an AD, the above is not a requirement of the IETF process. > It is a very good idea unless other concerns override. Is there an overriding concern? If so, what is it? > Mark> If an incompatibility > Mark> must be introduced, there is a versioning mechanism that > Mark> enables the new stuff only between consenting > Mark> implementations. > Again, a very good idea. I'm glad that you agree. Do we need to abandon the GSSAPI SASL mechanism in favor of the GSSAPIrev1 SASL mechanism? We have testimony that the bits on the wire are the same. We have testimony that all known GSSAPI implementations infer, at least in the case of Kerberos V5. Nonetheless, it is *very* frightening to be told that working RFC 2222 code may suddenly break, and that it's all the fault of the guy who gives a "make" command without first determining what version of the GSSAPI library is installed and reading the entire GSSAPI RFC for that version of the library. [And if I was the sort of clown who didn't read RFCs, I wouldn't have picked up on that obscure point during Last Call, much less raised all this fuss!] Can we avoid that scenario? We have as a given that the old code won't change, otherwise it becomes new code that doesn't have the issue. Is there something in new code that can be done to say "you don't need to infer with me", and state that code that fails to do that thing is old code and therefore must get auto-infer? Can we simply issue an Informational RFC of GSSAPI Implementation Recommendations that says "not implying integ with K5 breaks RFC 2222 implementations, so don't do it"? Being Informational, it's non-normative and requires minimal review. However, it would still be helpful should someone does what you yourself say would be "badly-designed". It'll fully satisfy my concerns. I believe that the WG, or even as an individual submission, can reasonably do such an Informational RFC. I volunteer to write it if you'll give the OK. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 02:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIJSD-0006lv-Va; Wed, 30 Aug 2006 02:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIJSC-0006lT-6N; Wed, 30 Aug 2006 02:21:36 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIJSA-0000wB-NW; Wed, 30 Aug 2006 02:21:36 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U6LXwU015047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Aug 2006 23:21:33 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7U6LWDA006537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2006 23:21:32 -0700 Date: Tue, 29 Aug 2006 23:21:31 -0700 (PDT) From: Mark Crispin To: Jeffrey Hutzelman In-Reply-To: <7A692D3BA9139D7CDE7B55EB@sirius.fac.cs.cmu.edu> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <7A692D3BA9139D7CDE7B55EB@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.29.230443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Jeffrey Hutzelman wrote: > Acceptable or not, it's what happens. RFC 2222 makes reference to RFC 2078; > using another version is noncompliant. > > If you prefer, you can think of your source code as complying with RFC 2222 > and RFC 2078, and of RFC 2078 and RFC 2743 being incompatible with each other > in such a way that your 2078-user might break when linked against a > 2743-provider. The effect is the same. That's not acceptable. It is not valid to presume that someone building software has the slightest clue about the nature of the GSSAPI library. Without that presumption it is not possible to declare differential behavior based upon having such a clue. > You seem to be suggesting that someone somewhere should produce a document > which changes the behavior of existing implementations of that mechanism > which do not already behave as described above. No. I am suggesting that if (as is repeatedly claimed) all GSSAPI implementations infer the integ flag for the Kerberos V5 mechanism AND that it is "poorly designed" (as Sam and Martin have stated) for an implementation to do otherwise, that some document state that GSSAPI implementations SHOULD infer the integ flag for the Kerberos V5 mechanism. It is not unheard-of for the IETF to produce documents that say something to the effect that "such-and-such is a good idea, so do it; however, such-and-such other thing is a bad idea, so don't do it." These documents are called Implementation Recommendations, and they move matters of this from folklore and "well-known expert Mr. Jones says that this is the way to do it" into RFCs that can be referred to when a question comes up. I don't understand why you are so opposed to doing this; especially since there is a real interoperability problem otherwise. We are supposed to solve problems, not block others from obtaining a resolution to their problems. Problem: Tens of thousands of copies of software implemented in good faith according to RFC 2222 are in the field. If some fool produces an RFC 2743 implementation that, as Sam says is "poorly designed", the RFC 2222 software will break with no changed to that software. The implementor of the RFC 2222 software has already made the necessary change to the next version, but that doesn't help all the copies that are out in the field. Proposed Solution: Produce some document advising RFC 2743 implementors of the problem with RFC 2222 implementors, and that they SHOULD infer integ (the way all other known GSSAPI implementations do) in Kerberos V5 to avoid the problem. If you don't like my proposed solution, then come up with one which solves the problem equally well. Something that does not involve crystal balls or forcing some poor schmuck who does a "make" to figure out which 100-page RFC applies to the libraries installed on his system. > I also don't see a change to the GSS-API, Version 2 imposing those > requirements on all mechanisms, partly because the "bit on the wire" in > question is specific to the Kerberos mechanism and partly because not all > mechanisms support integrity service at all. I never said anything about "all mechanisms". The document is an update to RFC 2222 for the GSSAPI SASL mechanism, which is specific to Kerberos V5. What mechanisms other than Kerberos V5 mechanisms do is of no consequence to RFC 2222 implementations. It may be of consequence to other applications and specifications which are affected by this incompatible change to GSSAPI, but that isn't my problem to solve; nor is it a problem for the RFC 2222 replacement. This document replaces RFC 2222, and the problem in question directly affects implementors of the protocol in question. This document solves the problem for new implementations, but not for the existing implementations in the field. The latter needs to be solved. > You could propose an update to the Kerberos GSS-API mechanism which makes > those recommendations. The appropriate place to do so would be in the > Kerberos working group, which is currently working on a (minor) update to > that mechanism. That may be, but in that case this document ("The Kerberos V5 SASL mechanism) should be blocked pending action by the Kerberos WG on this question. Otherwise, that precludes the possibility of the Kerberos WG bouncing some portion of the problem back. > Good, we agree on that. This document is for new implementations. > It can't very well tell old implementations what to do. Nonetheless, it needs to concern itself with interoperability with old implementations. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 02:56:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIJzy-0004Sl-Lu; Wed, 30 Aug 2006 02:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIJzw-0004SP-Qz; Wed, 30 Aug 2006 02:56:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIJg-0005i1-U9; Wed, 30 Aug 2006 01:08:44 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GII7A-0000PV-5D; Wed, 30 Aug 2006 00:55:49 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4C511E00C0; Wed, 30 Aug 2006 00:55:51 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> Date: Wed, 30 Aug 2006 00:55:51 -0400 In-Reply-To: (Mark Crispin's message of "Tue, 29 Aug 2006 17:41:47 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.5 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Jeffrey Altman , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: Mark> On Tue, 29 Aug 2006, Jeffrey Altman wrote: >> does the text proposed by Sam Hartman meet your needs? Mark> It helps. Could some part of what Martin Rex wrote also be Mark> incorporated? Statements about what GSS-API mechanisms should or should not do do not belong in a SASL document. If you can phrase something in terms of a recommendation for SASL implementations complying with this spec (not with RFC 2222), we can look at it. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 03:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKU2-0007tM-4Q; Wed, 30 Aug 2006 03:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIKU0-0007t5-NN; Wed, 30 Aug 2006 03:27:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIJn-0005ds-Ae; Wed, 30 Aug 2006 01:08:51 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GII1m-0000Ie-I7; Wed, 30 Aug 2006 00:50:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9E9ABE00C0; Wed, 30 Aug 2006 00:50:09 -0400 (EDT) From: Sam Hartman To: martin.rex@sap.com References: <200608292128.XAA27487@uw1048.wdf.sap.corp> Date: Wed, 30 Aug 2006 00:50:09 -0400 In-Reply-To: <200608292128.XAA27487@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 29 Aug 2006 23:28:54 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.5 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: kitten@ietf.org, MRC@cac.washington.edu, ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 >>>>> "Martin" == Martin Rex writes: Martin> A gssapi mechanism that implements message protection Martin> services but refuses them if the newly added Martin> "conf_req_flag" and "integ_req_flag" weren't passed in Martin> during gss_init_sec_context() must be considered seriously Martin> broken. Do you believe such a mechanism violates a normative requirement of RFC 2743? If so, which requirement (textual citation appreciated)? Or are you saying that such a mechanism would be poorly designed? If the ladder, I completely agree. If the former, I'm not finding the text, but that doesn't mean it isn't there. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 10:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQs5-0007Nb-Ba; Wed, 30 Aug 2006 10:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIQs4-0007NN-4C; Wed, 30 Aug 2006 10:16:48 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIQs1-0004dY-Lz; Wed, 30 Aug 2006 10:16:48 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA29136; Wed, 30 Aug 2006 16:16:23 +0200 (MESZ) From: Martin Rex Message-Id: <200608301416.QAA25932@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Wed, 30 Aug 2006 16:16:19 +0200 (MET DST) In-Reply-To: from "Sam Hartman" at Aug 30, 6 00:50:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ietf-sasl@imc.org, kitten@ietf.org, iesg@ietf.org, MRC@cac.washington.edu, jhutz@cmu.edu Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Sam Hartman wrote: > > Martin> A gssapi mechanism that implements message protection > Martin> services but refuses them if the newly added > Martin> "conf_req_flag" and "integ_req_flag" weren't passed in > Martin> during gss_init_sec_context() must be considered seriously > Martin> broken. > > Do you believe such a mechanism violates a normative requirement of RFC 2743? > If so, which requirement (textual citation appreciated)? The reason for the change was really only the negotiating mechanisms. There is no requirement for application to assert conf_req_flag or integ_req_flag as a prerequisite to use these services. It was not in rfc2078 and rfc1508, and it is not in rfc2443. The conf_req_flag and integ_req_flag provide informatory inputs to the GSS-API implementation as to whether, respectively, per-message confidentiality and per-message integrity services will be required on the context. This information is important as an input to negotiating mechanisms. It is important to recognize, however, that the inclusion of these flags (which are newly defined for GSS-V2) introduces a backward incompatibility with callers implemented to GSS-V1, where the flags were not defined. The reason why a negotiation mechanism might need the initiator to assert these flags is so that it can remove all mechanisms from the negotiation that do not fulfil this requirement, so that it will not happen that the server (who has the privilege to select) can not select a mechanism which does not fulfil the requirements of the initiator. However, the absence of a requirement on the side of the initiator does *NOT* imply that the initiator does not want to use message protection services! All of the "request flags" for context attributes are _options_ at the discretion of the caller (initiator). > > Or are you saying that such a mechanism would be poorly designed? If > the ladder, I completely agree. If the former, I'm not finding the > text, but that doesn't mean it isn't there. If the mechanism does not need additional round trips, and if the mechanism has previously been doing it correctly, then I think such a backwards incompatible change would be not only "poor design", but also non-conforming. The paragraph in rfc-2743 carries an explicit "backwards incompatibility" warning label, and it is sufficiently inconsistent/unclear that it can not be used as an excuse for just about every conceivable misbehaviour. Back then, many of the participants of CAT mostly cared about those scenarios that they were using or envisioning themselves, and as I said, the absence of integrity protection services didn't exist until late into GSS-API v2 (in spite of the context attribute integ_avail). You'll realize that when trying to figure out what gss_wrap()/gss_unwrap() is supposed to do when integrity protection is not available. It's not really specified. In order to facilitate application design, someone proposed that gss_wrap() and gss_unwrap() should be a no-op when integrity protection is not available, i.e. passing out what was passed in. However, the total absense of framing would break the GSS-API architecture. Zero-length tokens (context-length and message protection) are alien to GSS-API. Zero-length application data is OK and explicitly mentioned in GSS-API v2; it is used by secure FTP. I picked on a lot of areas of both documents in those areas that I felt weren't sufficiently clear for the scenarios that I was interested in. Interestingly, my code had been asserting the conf_req and integ_req flags from the beginning (in 1995), I wasn't actually aware that these flags had NOT been input parameters in GSS-API v1. MIT Kerberos never had a problem with this and C-Bindings say that unrecognized context request flags must be ignored by a mechanism. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 11:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRXn-0006w9-Hy; Wed, 30 Aug 2006 10:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRXm-0006uH-2D; Wed, 30 Aug 2006 10:59:54 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIRXk-0005oN-Mc; Wed, 30 Aug 2006 10:59:54 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA10080; Wed, 30 Aug 2006 16:59:45 +0200 (MESZ) From: Martin Rex Message-Id: <200608301455.QAA27062@uw1048.wdf.sap.corp> To: MRC@CAC.Washington.EDU (Mark Crispin) Date: Wed, 30 Aug 2006 16:55:50 +0200 (MET DST) In-Reply-To: from "Mark Crispin" at Aug 28, 6 01:39:42 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Mark Crispin wrote: > > I request consideration of the following changes prior to publication. > > Page 4, first paragraph, please change: > [...] When calling the GSS_Init_sec_context the client > MUST pass the integ_req_flag of TRUE. > to > [...] When calling the GSS_Init_sec_context the client > SHOULD pass the integ_req_flag of TRUE. In my reading, RFC-2743 does not contain a MUST either, only a recommendation in non-normative words, which amounts to a SHOULD. > > Suggested changes (this is just cosmetic): > > Page 5, second paragraph, change > [...] chan_binding of NULL > to: > [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS For several GSS-API calls explicit text was added to specify what (kind of default) behaviour should occur if a empty/NULL value was supplied as certain input parameters. For this purpose, several additional symbolic constants were added. John Wray probably added the constants for all of the types in the header file, but the NO_CHANNEL_BINDINGS never made it into the high level spec because it wasn't discussed (channel bindings were a rarely used feature, which is why so few gssapi mechanisms implement them). The use of a GSS_C_NO_* symbol instead of NULL was *not* meant to allow other values, just to give them a more readable name. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 11:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS0C-0003wG-CB; Wed, 30 Aug 2006 11:29:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS0B-0003u3-4X; Wed, 30 Aug 2006 11:29:15 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIS07-0003hq-KY; Wed, 30 Aug 2006 11:29:15 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UFTBwP019739; Wed, 30 Aug 2006 09:29:11 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UFTAMO029474; Wed, 30 Aug 2006 09:29:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UFT9MN026767; Wed, 30 Aug 2006 10:29:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UFT8gY026766; Wed, 30 Aug 2006 10:29:08 -0500 (CDT) Date: Wed, 30 Aug 2006 10:29:08 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830152859.GL10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , Jeffrey Hutzelman , kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.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: 93238566e09e6e262849b4f805833007 Cc: kitten@ietf.org, Sam Hartman , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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, Aug 29, 2006 at 07:47:10PM -0700, Mark Crispin wrote: > On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote: > >As soon as you compiled and linked your code against a library that > >implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant > >with RFC 2222. > > That is not an acceptable outcome. Implementors of C bindings of the GSS-API (RFC2744) should do library versioning to prevent this problem. Similarly for other language bindings of the GSS-API. Therefore this should not be a possible outcome. If it is then it is because either: a) you screwed up, and/or b) your GSS-API implementor screwed up. We cannot prevent implementor/deployer mistakes. We might warn about ones that we can imagine and which we think are likely, but we can't imagine all possible implementor/deployer mistakes. I think you're making a tempest in a teapot. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 11:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS3e-0004lf-2e; Wed, 30 Aug 2006 11:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIS3c-0004l1-0H; Wed, 30 Aug 2006 11:32:48 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIS3a-0004IU-Oi; Wed, 30 Aug 2006 11:32:47 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7E74DE00C0; Wed, 30 Aug 2006 11:32:48 -0400 (EDT) From: Sam Hartman To: martin.rex@sap.com References: <200608301416.QAA25932@uw1048.wdf.sap.corp> Date: Wed, 30 Aug 2006 11:32:48 -0400 In-Reply-To: <200608301416.QAA25932@uw1048.wdf.sap.corp> (Martin Rex's message of "Wed, 30 Aug 2006 16:16:19 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kitten@ietf.org, MRC@cac.washington.edu, ietf-sasl@imc.org, iesg@ietf.org, jhutz@cmu.edu Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 >>>>> "Martin" == Martin Rex writes: Martin> If the mechanism does not need additional round trips, and Martin> if the mechanism has previously been doing it correctly, Martin> then I think such a backwards incompatible change would be Martin> not only "poor design", but also non-conforming. I don't see the argument that this is non-conforming. I do completely agree with you about the motivation of the flags and about the problems caused by such a mechanism. I also agree that the IETF would not standardize such a mechanism. I have no problem updating RFC 2743 to say that either this should be (or is) non-conforming. I just don't think today's text says that clearly enough. I don't think such an update should block the SASL document. Thanks for your information on the motivation of these flags. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 11:41:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISBd-0000Ty-Ub; Wed, 30 Aug 2006 11:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISBd-0000Tq-K1; Wed, 30 Aug 2006 11:41:05 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISBc-0005JO-2e; Wed, 30 Aug 2006 11:41:05 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UFf1OX018389; Wed, 30 Aug 2006 09:41:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UFf1Ko004551; Wed, 30 Aug 2006 09:41:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UFf0ts026778; Wed, 30 Aug 2006 10:41:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UFexF9026777; Wed, 30 Aug 2006 10:40:59 -0500 (CDT) Date: Wed, 30 Aug 2006 10:40:59 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060830154058.GM10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , MRC@CAC.Washington.EDU, kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <20060828214650.GR10208@binky.Central.Sun.COM> <200608301504.RAA27365@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608301504.RAA27365@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, MRC@CAC.Washington.EDU, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Wed, Aug 30, 2006 at 05:04:46PM +0200, Martin Rex wrote: > GSS-API is a child of DCE, and DCE originally intended to provide > an integrity-only Kerberos for export (due to US crypto export regulation). Did DCE ever ship like that? If so then that would make two implementations that did :) > However, the availability of confidentiality protection wasn't > a result of the initiator not requesting confidentiality protection > (how could it -- these flags weren't available in GSS-API v1). Also, the implementation simply didn't have the confidentiality protection protection code, so even with those flags it could not provide it. > It was supposed to be a (lack of)feature of a particular implementation, > and intended to go smooth on the application. I think it is non-smooth, but whatever. > As I said, however, absence of message integrity is un(der)specified. Something to clarify. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 11:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISSk-0007Xm-MT; Wed, 30 Aug 2006 11:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISSj-0007VW-5u; Wed, 30 Aug 2006 11:58:45 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISSh-0008Ni-UF; Wed, 30 Aug 2006 11:58:45 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EACF0E00C0; Wed, 30 Aug 2006 11:58:46 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> Date: Wed, 30 Aug 2006 11:58:46 -0400 In-Reply-To: (Mark Crispin's message of "Tue, 29 Aug 2006 22:24:43 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: Mark> On Wed, 30 Aug 2006, Sam Hartman wrote: >> Statements about what GSS-API mechanisms should or should not >> do do not belong in a SASL document. Mark> This document specifically discusses the Kerberos V5 GSSAPI We don't know. We know that the behavior is well-defined if you set the integ_req flag. RFC 1964 and 4121 fairly strongly imply that integrity service is always available but don't actually say so. It would be really stupid to implement a Kerberos GSS-API mechanism that made integrity service optionally available. Several people from the Kerberos community including myself have come forward and said they have never run into such a mechanism. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:01:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISUo-0001Gi-IA; Wed, 30 Aug 2006 12:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISUn-0001E9-3A; Wed, 30 Aug 2006 12:00:53 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISUl-0000T0-SA; Wed, 30 Aug 2006 12:00:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AA7FAE00C0; Wed, 30 Aug 2006 12:00:52 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Date: Wed, 30 Aug 2006 12:00:52 -0400 In-Reply-To: (Mark Crispin's message of "Tue, 29 Aug 2006 22:44:17 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: Mark> On Wed, 30 Aug 2006, Sam Hartman wrote: It is most certainly Mark> a requirement that a protocol specification update not break Mark> compliant implementations written to an earlier Mark> specification. >> Speaking as an AD, the above is not a requirement of the IETF >> process. It is a very good idea unless other concerns >> override. Mark> Is there an overriding concern? If so, what is it? Interoperability. If you set the flag, your code will work against existing and past acceptors. If you do not set the flag, your code may end up failing against some acceptors. Mark> If an incompatibility must be introduced, there is a Mark> versioning mechanism that enables the new stuff only between Mark> consenting implementations. >> Again, a very good idea. Mark> I'm glad that you agree. Mark> Do we need to abandon the GSSAPI SASL mechanism in favor of Mark> the GSSAPIrev1 SASL mechanism? I think not because we're talking about the same wire protocol. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISn3-0000XG-73; Wed, 30 Aug 2006 12:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISn2-0000X8-Jp; Wed, 30 Aug 2006 12:19:44 -0400 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISn1-0003pt-7z; Wed, 30 Aug 2006 12:19:44 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGJgTv004016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 09:19:42 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGJfeC020055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 09:19:41 -0700 Date: Wed, 30 Aug 2006 09:19:40 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830152859.GL10208@binky.Central.Sun.COM> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.84942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > Implementors of C bindings of the GSS-API (RFC2744) should do library > versioning to prevent this problem. Similarly for other language > bindings of the GSS-API. I agree. But they didn't do that. > Therefore this should not be a possible outcome. If it is then it is > because either: a) you screwed up, and/or b) your GSS-API implementor > screwed up. (b) has happened. They probably did not realize that there would be a problem; they thought that all they had to do was substitute their new bits and all the old software would continue to work. They probably acted in good faith. After all, the GSSAPI specification goes to length to talk about backwards compatibility except for this one wart. I acted in good faith too; and most certainly I did not "screw up" by not knowing, in 1998, about a change made in 2000. > We cannot prevent implementor/deployer mistakes. We might warn about > ones that we can imagine and which we think are likely, but we can't > imagine all possible implementor/deployer mistakes. That is all true. Nonetheless, you can (and should!) deal with a problem which has now been identified. > I think you're making a tempest in a teapot. Were you aware that RFC 822 allowed your email address to be: Nicolas (as in the saint) . Williams @ sun (not moon) . (not org) com in headers? Does your MUA handle it? Some do, many do not! The concensus of all the network experts 25 or so years ago was that nobody would actually be crazy enough to do such a thing. RFC 2822 specifically forbids it today, because it became a tempest in a teapot (and a rather nasty one). After a few experiences like this, you learn not to disregard tempests in teapots. It may not always be possible to anticipate, and thus prevent, one from popping up. But once once does, you deal with it. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT01-0007mU-8W; Wed, 30 Aug 2006 12:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GISzz-0007ju-NA; Wed, 30 Aug 2006 12:33:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISzz-0007TN-LV; Wed, 30 Aug 2006 12:33:07 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GISyU-0003m4-NA; Wed, 30 Aug 2006 12:31:37 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGVXtR020992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 09:31:33 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGVWqo020514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 09:31:33 -0700 Date: Wed, 30 Aug 2006 09:31:32 -0700 (PDT) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.90942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Sam Hartman wrote: > We don't know. We know that the behavior is well-defined if you set > the integ_req flag. RFC 1964 and 4121 fairly strongly imply that > integrity service is always available but don't actually say so. Well, we've identified a work item for somebody, haven't we? > It would be really stupid to implement a Kerberos GSS-API mechanism > that made integrity service optionally available. Several people from > the Kerberos community including myself have come forward and said > they have never run into such a mechanism. If this discussion was taking place 20 years ago, the word of a recognized authority (such as Sam Hartman) that "this isn't a problem" would be enough for me. Unfortunately, I have experienced too many episodes since then in which I trusted the word of a recognized authority -- and understood the issue myself! -- only to have it blow up in my face years later at the hands of someone who refuses to recognize the authority (or the mailing list archive!), insists that only the specification is normative, and that given an ambiguity the interpretation that harms my implementation is the correct one. The worst part about it is that such individuals are correct. The recognized authority and mailing list archive are not normative; only the specification is normative. And if the specification allows leeway then you don't have a leg to stand on when you complain about it. I think that this discussion has gone long enough that it can't be swept under the rug. The problem needs to be tackled. It is of little consequence to me precisely how it is tackled, as long as it is tackled. And no, "it's your fault for building with the wrong version of the library" does not constitute tackling the problem. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT86-0001XQ-Se; Wed, 30 Aug 2006 12:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIT85-0001XI-Sd; Wed, 30 Aug 2006 12:41:29 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIT84-0000P4-Eu; Wed, 30 Aug 2006 12:41:29 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge2) with ESMTP id k7UGf7QB009623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 18:41:07 +0200 From: Simon Josefsson To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060830:ietf-sasl@imc.org::uk8afaDrhrkpHhP2:1srj X-Hashcash: 1:22:060830:jhutz@cmu.edu::Fbs3nvSTWKP9L87K:2pXV X-Hashcash: 1:22:060830:hartmans-ietf@mit.edu::nMdWXI6S+1TTZXvA:7Vx4 X-Hashcash: 1:22:060830:kitten@ietf.org::lHNUt+1kjOnEwGl9:RUTE X-Hashcash: 1:22:060830:iesg@ietf.org::D15a3kifJIDo8f1r:sb8j X-Hashcash: 1:22:060830:mrc@cac.washington.edu::vMxQZBMRap/uS6Wy:ZpBd Date: Wed, 30 Aug 2006 18:41:07 +0200 In-Reply-To: <20060830152859.GL10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 30 Aug 2006 10:29:08 -0500") Message-ID: <87odu2dvmk.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, Sam Hartman , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Nicolas Williams writes: > On Tue, Aug 29, 2006 at 07:47:10PM -0700, Mark Crispin wrote: >> On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote: >> >As soon as you compiled and linked your code against a library that >> >implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant >> >with RFC 2222. >> >> That is not an acceptable outcome. > > Implementors of C bindings of the GSS-API (RFC2744) should do library > versioning to prevent this problem. Similarly for other language > bindings of the GSS-API. > > Therefore this should not be a possible outcome. If it is then it is > because either: a) you screwed up, and/or b) your GSS-API implementor > screwed up. > > We cannot prevent implementor/deployer mistakes. We might warn about > ones that we can imagine and which we think are likely, but we can't > imagine all possible implementor/deployer mistakes. None of the GSS-API libraries I've worked with provides library versioning that corresponds to the GSS-API revision. Several Kerberos GSS-API mechanisms (including MIT's) support the integ_req flag without implementing all of GSS-API v2u1, or even all of v2. The versioning of GSS-API is not consistently visible at the API level. In practice, it is difficult to tell which GSS-API version a particular implementation supports (e.g., MIT supports some but not all of v2u1). So I don't think the above is a realistic or constructive way to look at this. While I agree with Sam that keeping the recommendation of asserting the integ_req flag is the right thing, I agree with Mark that we should look at the deployed based here, and be careful to not invalidate old implementations. Whether RFC 2222 reference RFC 2078 or RFC 2743 is an academic aspect -- the important aspect is what happens with the programs that are, and will be, deployed. Adding an implementation note to explain the situation seems like the best solution to me. /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITFX-0004kx-UL; Wed, 30 Aug 2006 12:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITFW-0004kc-FB; Wed, 30 Aug 2006 12:49:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITFW-00023y-Da; Wed, 30 Aug 2006 12:49:10 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIT8w-00044p-Mq; Wed, 30 Aug 2006 12:42:24 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGgLs8025135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 09:42:21 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UGgK7u023548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 09:42:21 -0700 Date: Wed, 30 Aug 2006 09:42:20 -0700 (PDT) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.91942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Sam Hartman wrote: > Interoperability. If you set the flag, your code will work against > existing and past acceptors. If you do not set the flag, your code > may end up failing against some acceptors. What created this interoperability problem? Did it exist in 1994, when RFC 1731 was written? Did it exist in 1997, when RFC 2222 was written? Did it exist in 1998, when my code was written? Did it exist in 2000, when RFC 2743 was written? Does it exist today, prior to the publication of draft-ietf-sasl-gssapi? I think that we all agree that when draft-ietf-sasl-gssapi is published, the problem will exist. As matters stand, if the problem exists, it is a specification bug: RFC 2222 is the standard for the GSSAPI SASL mechanism, and RFC 2743 created an interoperability problem. I understand that draft-ietf-sasl-gssapi intends to fix the problem by establishing a requirement for new implementations. All fine and good. But it doesn't fix the problem for the implementations out there. "Document and depreciate" is an acceptable solution for old software. > Mark> Do we need to abandon the GSSAPI SASL mechanism in favor of > Mark> the GSSAPIrev1 SASL mechanism? > I think not because we're talking about the same wire protocol. Doesn't that presuppose that the interoperability problem is only theoretical in nature? If so, why not declare the theory mandatory for the specific scope of K5 in the GSSAPI SASL mechanism? -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 12:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITGW-000572-Bn; Wed, 30 Aug 2006 12:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITGU-00054B-FN; Wed, 30 Aug 2006 12:50:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIRtV-0001eo-I5; Wed, 30 Aug 2006 11:22:21 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIRl0-0001Y9-U0; Wed, 30 Aug 2006 11:13:36 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id RAA06042; Wed, 30 Aug 2006 17:11:53 +0200 (MESZ) From: Martin Rex Message-Id: <200608301504.RAA27365@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 30 Aug 2006 17:04:46 +0200 (MET DST) In-Reply-To: <20060828214650.GR10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 28, 6 04:46:51 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-SAP: out X-Spam-Score: -2.1 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, MRC@CAC.Washington.EDU, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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: > > (At least one implementation of the Kerberos V GSS mechanism used to > leave out confidentiality protection, but none, to my knowledge, fails > to provide MIC and/or wrap tokens when integ_req_flag == false in the > call to GSS_Init_sec_context().) GSS-API is a child of DCE, and DCE originally intended to provide an integrity-only Kerberos for export (due to US crypto export regulation). However, the availability of confidentiality protection wasn't a result of the initiator not requesting confidentiality protection (how could it -- these flags weren't available in GSS-API v1). It was supposed to be a (lack of)feature of a particular implementation, and intended to go smooth on the application. As I said, however, absence of message integrity is un(der)specified. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 13:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITqa-0003Xq-6n; Wed, 30 Aug 2006 13:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITqZ-0003Wq-87; Wed, 30 Aug 2006 13:27:27 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITq4-0002CH-0c; Wed, 30 Aug 2006 13:26:57 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id CCE18E00C0; Wed, 30 Aug 2006 13:27:03 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <44F4AFE7.4070006@secure-endpoints.com> Date: Wed, 30 Aug 2006 13:27:03 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 30 Aug 2006 09:31:32 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 make it painfully clear what my position is: I care very littel about code compatibility: I think it is entirely reasonable for the IETF to publish a new spec that requires you to write code to comply with and that your existing code does not comply with. I think that we need to have a reason for doing so but that the bar is rather low. I suspect we disagree strongly about this point. I care a great deal about wire compatibility. I think it is a big problem when we change a protocol in such a way that a new client cannot work with an old server or in which a old client cannot work with a new server. Sometimes we need to do that; generally we use versioning mechanisms or new protocols when we do. I have seen no claim that the wire protocol described in RFC 2222 differs from the wire protocol described in this draft. Thus I think we have met our primary compatibility objective. I agree with you and Jeff that the way in which integ_req flag was introduced into RFC 2743 may be ill-considered. I agree with you that it would be appropriate to update the Kerberos V mechanism to require integrity be available all the time. I disagree that this spec should block on such an update. --Sam _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 13:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrJ-00044Z-Ew; Wed, 30 Aug 2006 13:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrI-0003h9-AN; Wed, 30 Aug 2006 13:28:12 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITdj-0007tD-2j; Wed, 30 Aug 2006 13:14:12 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A1180E00C0; Wed, 30 Aug 2006 13:14:19 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> Date: Wed, 30 Aug 2006 13:14:19 -0400 In-Reply-To: <87odu2dvmk.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 30 Aug 2006 18:41:07 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Simon" == Simon Josefsson writes: Simon> Adding an implementation note to explain the situation Simon> seems like the best solution to me. I'm happy with a non-normative implementation note. I've proposed text which has received a luke-warm reception. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 13:28:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrQ-00048K-9T; Wed, 30 Aug 2006 13:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrK-000464-I5; Wed, 30 Aug 2006 13:28:14 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITcb-0007g7-Ud; Wed, 30 Aug 2006 13:13:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A5572E00C0; Wed, 30 Aug 2006 13:12:48 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> Date: Wed, 30 Aug 2006 13:12:47 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 30 Aug 2006 09:42:20 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Mark, I think we're going in circles here. Question to the world at large: is anyone else still confused about this or believe we're taking the wrong approach? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 13:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITtw-0005T9-5m; Wed, 30 Aug 2006 13:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITtv-0005T4-97 for kitten@ietf.org; Wed, 30 Aug 2006 13:30:55 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITts-0003jK-A3 for kitten@ietf.org; Wed, 30 Aug 2006 13:30:55 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA26066; Wed, 30 Aug 2006 19:30:33 +0200 (MESZ) From: Martin Rex Message-Id: <200608301730.TAA01962@uw1048.wdf.sap.corp> To: hartmans-ietf@mit.edu (Sam Hartman) Date: Wed, 30 Aug 2006 19:30:32 +0200 (MET DST) In-Reply-To: from "Sam Hartman" at Aug 30, 6 11:32:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: kitten@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Sam Hartman wrote: > > >>>>> "Martin" == Martin Rex writes: > > Martin> If the mechanism does not need additional round trips, and > Martin> if the mechanism has previously been doing it correctly, > Martin> then I think such a backwards incompatible change would be > Martin> not only "poor design", but also non-conforming. > > I don't see the argument that this is non-conforming. I do completely > agree with you about the motivation of the flags and about the > problems caused by such a mechanism. I also agree that the IETF would > not standardize such a mechanism. > > I have no problem updating RFC 2743 to say that either this should be > (or is) non-conforming. I just don't think today's text says that > clearly enough. Updating (rev'ing) rfc-2743 will require resources, but is not going to fix a poorly designed installed base. Trying to get rid of abiguity in a spec that has been there for so many years is likely very difficult. Right now rfc-2743 does NOT require applications to assert integ_req_flag or conf_req_flag if they desire to use it later on, so the SASL document should not use a MUST, but rather a SHOULD for asserting the integ_req_flag. There is some wording that gssapi mechanism implementors may use as an excuse for poor design decisions breaking applications, but there are many issue where a spec-weasel could argue why some fancy misbehaviour (that likely breaks some apps in one way or another) should be "OK" with the GSS-API spec. We get regular calls from vendors asking whether creating an interactive popup requesting input from a user from within a gssapi function would be OK with us, and I regularly deny that-- although it is not explicitly forbidden by the GSS-API spec, it is a pretty bad idea and will break our application (and probably others) in several scenarios (timeout-related) and therefore we do not allow it for "interoperability certification" with our application. One vendor showed up with a GSS-API mechanism that unconditionally applied confidentiality protection during gss_wrap(), even if the application didn't ask for it. Although this is not strictly forbidden by GSS-API, I consider it a bad idea. Our application can be configured to use three "protection" level when using GSS-API: - authentication only - data integrity protection - data integrity and confidentiality protection if the second level (data integrity protection) is used, our application uses gss_getmic/gss_verifymic and _not_ gss_wrap/gss_unwrap, so the attempt of the gssapi mechanism to "enforce" confidentiality during gss_wrap doesn't work. If the first level (authentication only) is requested, no message protection services are called by our application, which is the most portable approach. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 13:38:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIU0m-0000Dy-B1; Wed, 30 Aug 2006 13:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIU0k-0000Dp-P6; Wed, 30 Aug 2006 13:37:58 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIU0j-00060M-BG; Wed, 30 Aug 2006 13:37:58 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UHburV015399; Wed, 30 Aug 2006 10:37:56 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UHbZjQ027698; Wed, 30 Aug 2006 11:37:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UHatOc026904; Wed, 30 Aug 2006 12:37:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UHaspn026903; Wed, 30 Aug 2006 12:36:54 -0500 (CDT) Date: Wed, 30 Aug 2006 12:36:54 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060830173653.GT10208@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , Mark Crispin , kitten@ietf.org, Sam Hartman , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87odu2dvmk.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf-sasl@imc.org, kitten@ietf.org, iesg@ietf.org, Mark Crispin , Sam Hartman , Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 06:41:07PM +0200, Simon Josefsson wrote: > None of the GSS-API libraries I've worked with provides library > versioning that corresponds to the GSS-API revision. Several Kerberos > GSS-API mechanisms (including MIT's) support the integ_req flag > without implementing all of GSS-API v2u1, or even all of v2. The > versioning of GSS-API is not consistently visible at the API level. Is this because they've never made backwards-incompatible changes, such as requiring use of integ_req_flag in order to get integrity protection? Would that not be a valid response by implementors who did not version their GSS libraries, that they will change the major version number only when they make backwards-incompatible changes? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUMF-0001Fc-NU; Wed, 30 Aug 2006 14:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUMD-0001FF-L4; Wed, 30 Aug 2006 14:00:09 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIUMC-0002d1-95; Wed, 30 Aug 2006 14:00:09 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA00551; Wed, 30 Aug 2006 19:59:41 +0200 (MESZ) From: Martin Rex Message-Id: <200608301759.TAA02881@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 30 Aug 2006 19:59:41 +0200 (MET DST) In-Reply-To: <20060830152859.GL10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 30, 6 10:29:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf-sasl@imc.org, kitten@ietf.org, iesg@ietf.org, MRC@CAC.Washington.EDU, hartmans-ietf@mit.edu, jhutz@cmu.edu Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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: > > Implementors of C bindings of the GSS-API (RFC2744) should do library > versioning to prevent this problem. Similarly for other language > bindings of the GSS-API. I violently disagree. ;-) The (first) SPNEGO document (rfc-2478) predates rfc-2743/44, Appendix B of the C-Bindings (rfc-2744) makes explict recommendations for binary plug'n'play, and already RFC-1508 has the notion of "applications portable accross different mechanisms". While it is perfectly OK for a particular gssapi mechanism to be hardwired to a particular application with esoteric, non-portable or plain stupid features, it is definitely against the spirit and design goals of the GSS-API spec. Portable applications, as well as protocol specs that are not intended to be hardwired to only a particular gssapi mechanism should be conservative ("portable" in the GSS-API sense) in their requirements and be prepared to meet any one from a number of possible gssapi mechanisms at runtime. SPNEGO does not require that all mechanisms that it negotiates have the same maturity levels, it may be a mixture of old v1 and brand-new v2u1 mechanisms. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUWg-0005TJ-QL; Wed, 30 Aug 2006 14:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUWf-0005So-Dl; Wed, 30 Aug 2006 14:10:57 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIUWd-0003rv-Qp; Wed, 30 Aug 2006 14:10:57 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UHdgGO017089; Wed, 30 Aug 2006 10:39:42 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UHdQmR028473; Wed, 30 Aug 2006 11:39:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UHdGZK026912; Wed, 30 Aug 2006 12:39:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UHdGOO026911; Wed, 30 Aug 2006 12:39:16 -0500 (CDT) Date: Wed, 30 Aug 2006 12:39:16 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830173915.GU10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 10:20:00AM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >Did you link statically? If so, there's no issue. > > I don't know. It depends upon how the system provider set up links to the > GSSAPI library. > > >Did you link dynamically? > > I don't know. It depends upon how the system provider set up links to the > GSSAPI library. > > >If so, did the library version change? > > I don't know. I have no way of knowing. > > Please refer to Simon's message. See my response to Simon's message. Basically, I would consider the lack of major number changes in any implementor's GSS-API libraries as indication of commitment to not having made backwards-incompatible changes. Or at least that's what I think *you*, as a customer/user should demand of your vendors. > >And the implementor is still acting in good faith by not breaking > >backwards compatibility. > > I'm confused. What entity is offering surety that this is, and will > remain, the case? The implementor. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUkX-0002tz-4I; Wed, 30 Aug 2006 14:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIUkW-0002tT-Ec; Wed, 30 Aug 2006 14:25:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITy4-0004sh-Md; Wed, 30 Aug 2006 13:35:12 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GITnj-00058m-2V; Wed, 30 Aug 2006 13:24:31 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7UHOLGJ028890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 13:24:21 -0400 (EDT) Date: Wed, 30 Aug 2006 13:24:21 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Simon Josefsson Message-ID: In-Reply-To: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> Originator-Info: login-token=Mulberry:01UTKolLuaHQidfSAVhLDYA+ik37/YZiG+p9b5h7I=; 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: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wednesday, August 30, 2006 01:14:19 PM -0400 Sam Hartman wrote: >>>>>> "Simon" == Simon Josefsson writes: > > > Simon> Adding an implementation note to explain the situation > Simon> seems like the best solution to me. > > I'm happy with a non-normative implementation note. I've proposed > text which has received a luke-warm reception. If I recall correctly, Mark found your text acceptable, and so did I. However, I believe Mark thought more was needed. Unfortunately, I'm having trouble understanding what, beyond your text, Mark would like us to do _in this document_. Mark, can you spell out exactly what further change you'd like to see to draft-ietf-sasl-gssapi-07.txt, beyond Sam's proposed text? I know you've probably said already, but I'd like to cut through some of the weeds here to give Sam and the chairs a clear picture of what dispute remains, if any, that needs to be addressed before this document can move forward. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVCj-0006A2-KY; Wed, 30 Aug 2006 14:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVCh-00069o-RE; Wed, 30 Aug 2006 14:54:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GISfh-00027T-TI; Wed, 30 Aug 2006 12:12:09 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GISDr-0002UD-SJ; Wed, 30 Aug 2006 11:43:26 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UFhMXb010277; Wed, 30 Aug 2006 08:43:23 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UFhMfk005422; Wed, 30 Aug 2006 09:43:22 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UFhMnT026789; Wed, 30 Aug 2006 10:43:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UFhML1026788; Wed, 30 Aug 2006 10:43:22 -0500 (CDT) Date: Wed, 30 Aug 2006 10:43:22 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20060830154321.GN10208@binky.Central.Sun.COM> Mail-Followup-To: Martin Rex , Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <200608301455.QAA27062@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608301455.QAA27062@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.5 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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 Wed, Aug 30, 2006 at 04:55:50PM +0200, Martin Rex wrote: > In my reading, RFC-2743 does not contain a MUST either, only a recommendation > in non-normative words, which amounts to a SHOULD. RFC2743 does not use RFC2119 terminology at all. Just what RFC2743 requires, recommends or allows is sometimes a matter of interpretation. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVEC-0006vc-22; Wed, 30 Aug 2006 14:55:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVEB-0006vU-DX; Wed, 30 Aug 2006 14:55:55 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVE9-000055-Sb; Wed, 30 Aug 2006 14:55:55 -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 k7UItrcn010292; Wed, 30 Aug 2006 12:55:53 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UItgNG001168; Wed, 30 Aug 2006 12:55:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UItHs9026982; Wed, 30 Aug 2006 13:55:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UItH0N026981; Wed, 30 Aug 2006 13:55:17 -0500 (CDT) Date: Wed, 30 Aug 2006 13:55:17 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830185516.GA10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 11:35:57AM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >See my response to Simon's message. Basically, I would consider the > >lack of major number changes in any implementor's GSS-API libraries as > >indication of commitment to not having made backwards-incompatible > >changes. > > I agree with the sentiment. Nonetheless, to date, vendors (including > SUN!) have not made such commitments and repeatedly shy away from making > any such commitment. Absolutely we have. MIT is committed to a number of things, such as ABI backwards compatibility for all their public MIT krb5 interfaces (including the GSS C bindings). Sun is also strongly committed to backwards compatibility for Stable (Committed) interfaces, and when appropriate we consider behaviour to be an interface. We would not make backwards-incompatible changes to libgss without bumping the library version number, and we wouldn't deprecate old versions of it without at least a year's warning before the minor release where they would be deprecated. Marc, the reality is that vendors try hard to avoid customer complaints about backwards incompatibility by avoiding breaking backwards compatibility in the first place. If Sun broke libgss and/or mech_krb5 so that not setting GSS_C_INTEG_FLAG leads to gss_get/verify_mic() and/or gss_wrap/unwrap() failing, then I'd expect: a) customers to complain and high-priority bugs to be filed, b) Sun to fix those bugs. I'm pretty sure that MIT would make/makes the same commitment. The only difference being: the set of interfaces to which they commit, their release taxonomy and schedules, and amount of warning they give for obsolescence. But you might not be using MIT directly, but another vendor (or Linux distro) that bundles MIT, and they may make additional commitments (e.g., Solaris uses MIT source code, but our commitments are somewhat stronger than MIT's). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 14:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVFW-0007Ba-VX; Wed, 30 Aug 2006 14:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVFW-0007BN-AD; Wed, 30 Aug 2006 14:57:18 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVFU-0000Gz-OT; Wed, 30 Aug 2006 14:57:18 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UIvFm2002538; Wed, 30 Aug 2006 11:57:15 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UIv5gW001866; Wed, 30 Aug 2006 12:57:15 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UIui94026991; Wed, 30 Aug 2006 13:56:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UIuit4026990; Wed, 30 Aug 2006 13:56:44 -0500 (CDT) Date: Wed, 30 Aug 2006 13:56:44 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830185644.GB10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@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: 93238566e09e6e262849b4f805833007 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 11:48:21AM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >Is this because they've never made backwards-incompatible changes, such > >as requiring use of integ_req_flag in order to get integrity protection? > > I don't know. Do you? See my other reply just now about vendor commitments to interface stability. > >Would that not be a valid response by implementors who did not version > >their GSS libraries, that they will change the major version number only > >when they make backwards-incompatible changes? > > GSSAPI violates this; V2 specifically states that it does not make > backward-incompatible changes. If so then the only reasonable conclusion is that integ_req_flag == FALSE MUST NOT imply that integrity protection is not available. Can we stop now? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVPn-0003Px-6i; Wed, 30 Aug 2006 15:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVPl-0003Pp-Ln; Wed, 30 Aug 2006 15:07:53 -0400 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVPk-00027K-B7; Wed, 30 Aug 2006 15:07:53 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UJ7pKN005963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 12:07:51 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UJ7oq0001623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 12:07:50 -0700 Date: Wed, 30 Aug 2006 12:07:49 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830185516.GA10208@binky.Central.Sun.COM> Message-ID: References: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@binky.Central.Sun.COM> <20060830185516.GA10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.113942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_MEDIA_2_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > Marc, the reality is that vendors try hard to avoid customer complaints > about backwards incompatibility by avoiding breaking backwards > compatibility in the first place. This is all fine and good, but the reality is that they don't always succeed. SUN is not immune. Nor do all vendors make such commitments. We live in an imperfect world. Good faith doesn't always exist, and those of good faith sometimes blunder. Nor do vendors do a particularly good job of taking responsibility/blame even when it is their fault. My 30-odd year collection of horror stories is best suited for discussion at a bar, over large (and continuously refilled) pitchers of beer. If we can prevent this particular problem from being added to the collection, we should. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVR6-0004YO-R4; Wed, 30 Aug 2006 15:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVR4-0004YF-Sk; Wed, 30 Aug 2006 15:09:14 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVR3-0002RD-Ad; Wed, 30 Aug 2006 15:09:14 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UJ9C2J007598; Wed, 30 Aug 2006 12:09:12 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UJ91e6007126; Wed, 30 Aug 2006 13:09:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UJ8fMf027012; Wed, 30 Aug 2006 14:08:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UJ8fFE027011; Wed, 30 Aug 2006 14:08:41 -0500 (CDT) Date: Wed, 30 Aug 2006 14:08:41 -0500 From: Nicolas Williams To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Message-ID: <20060830190840.GN10458@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@binky.Central.Sun.COM> <20060830185516.GA10208@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060830185516.GA10208@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Note too: I don't speak for MIT. As for Sun's commitment to stability, see attributes(5). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:09:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVRd-0004c4-6K; Wed, 30 Aug 2006 15:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVRb-0004bv-K7; Wed, 30 Aug 2006 15:09:47 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITjO-0000uL-KQ; Wed, 30 Aug 2006 13:20:03 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UHK1CL006776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 10:20:01 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UHK0sJ007542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 10:20:01 -0700 Date: Wed, 30 Aug 2006 10:20:00 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830164418.GP10208@binky.Central.Sun.COM> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.94942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > Did you link statically? If so, there's no issue. I don't know. It depends upon how the system provider set up links to the GSSAPI library. > Did you link dynamically? I don't know. It depends upon how the system provider set up links to the GSSAPI library. > If so, did the library version change? I don't know. I have no way of knowing. Please refer to Simon's message. > If > not, did the implementor break apps that don't set the integ_req_flag? I don't know. I have no way of knowing. > Has the implementor not assured you that they wouldn't do that in a > future release? I don't know who the implementor is, much less have talked with him or her to get such assurances. > C library versioning is non-standard. Yes. > And the implementor is still acting in good faith by not breaking > backwards compatibility. I'm confused. What entity is offering surety that this is, and will remain, the case? -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVev-0001oT-6L; Wed, 30 Aug 2006 15:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVet-0001oI-VD; Wed, 30 Aug 2006 15:23:31 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVes-0004Zs-Dp; Wed, 30 Aug 2006 15:23:31 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UJNT1D027108; Wed, 30 Aug 2006 12:23:29 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UJN8pZ013058; Wed, 30 Aug 2006 13:23:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UJMDlP027027; Wed, 30 Aug 2006 14:22:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UJMDql027026; Wed, 30 Aug 2006 14:22:13 -0500 (CDT) Date: Wed, 30 Aug 2006 14:22:13 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830192212.GC10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@binky.Central.Sun.COM> <20060830185516.GA10208@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: 7655788c23eb79e336f5f8ba8bce7906 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 12:07:49PM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >Marc, the reality is that vendors try hard to avoid customer complaints > >about backwards incompatibility by avoiding breaking backwards > >compatibility in the first place. > > This is all fine and good, but the reality is that they don't always > succeed. SUN is not immune. Nor do all vendors make such commitments. We can't guarantee that we won't break anything -- bugs happen. But we provide support, and support means fixing bugs when they happen. And what we consider a bug as a lot to do with commitment to interface stability. This is getting silly. Either you accept vendor commitments and hold us to them or you don't, but if you do and the commitment is there then please stop arguing "but you might break it accidentally!" -- yes, we might, but that's not a useful argument here. And if you don't accept these commitments then you have no case anyways because nothing we do here can possibly make you happy. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:24:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVff-0002BV-Jd; Wed, 30 Aug 2006 15:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVfd-0002BN-QU; Wed, 30 Aug 2006 15:24:17 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVfc-0004di-FJ; Wed, 30 Aug 2006 15:24:17 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UJOFLW023490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 12:24:15 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UJOESZ015646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 12:24:15 -0700 Date: Wed, 30 Aug 2006 12:24:14 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830185644.GB10208@binky.Central.Sun.COM> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.115942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > If so then the only reasonable conclusion is that integ_req_flag == > FALSE MUST NOT imply that integrity protection is not available. So how would this be stated in the document? Application: integ_req_flag MUST be set K5 GSSAPI/SASL: integ_req_flag is implied set, regardless of whether or not it was set by the application Something like: Implementation note: RFC 2222 did not have the requirement, added in this revision, that integ_req_flag be set by the caller to GSS_Init_sec_context(). There is no means by which GSSAPI can know that the caller complies with RFC 2222 or with this update. Therefore, and notwithstanding the language on page 47 of RFC 2743, a GSSAPI implementation MUST imply that integ_req_flag is set when used for the GSSAPI (Kerberos v5) SASL mechanism. or perhaps (weaker, but alright): Implementation note: RFC 2222 did not have the requirement, added in this revision, that integ_req_flag be set by the caller to GSS_Init_sec_context(). Therefore, the language on page 47 of RFC 2743 is to be interpreted as indicating that a GSSAPI (Kerberos v5) SASL mechanism caller to GSS_Init_sec_context() that does not set integ_req_flag complies with RFC 2222 and not with this revision. To maintain interoperability, the GSSAPI layer SHOULD infer integ_req_flag as set, as described on page 47 of RFC 2743. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 15:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVqs-0006vZ-Er; Wed, 30 Aug 2006 15:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIVqr-0006u8-Gf; Wed, 30 Aug 2006 15:35:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIV4n-0007DV-2L; Wed, 30 Aug 2006 14:46:13 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIUuu-0007ca-48; Wed, 30 Aug 2006 14:36:02 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UIZwEV030137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 11:35:59 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UIZvTd024967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 11:35:58 -0700 Date: Wed, 30 Aug 2006 11:35:57 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830173915.GU10208@binky.Central.Sun.COM> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.110942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > See my response to Simon's message. Basically, I would consider the > lack of major number changes in any implementor's GSS-API libraries as > indication of commitment to not having made backwards-incompatible > changes. I agree with the sentiment. Nonetheless, to date, vendors (including SUN!) have not made such commitments and repeatedly shy away from making any such commitment. We do not live in an ideal world; and (to paraphrase Simon) it is not realistic nor constructive to point out that the problem does not exist in an ideal world. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLF-00019x-4a; Wed, 30 Aug 2006 16:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLD-00018u-Pc; Wed, 30 Aug 2006 16:07:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWLD-0002Jt-Nl; Wed, 30 Aug 2006 16:07:15 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIVnX-0000hK-9q; Wed, 30 Aug 2006 15:32:27 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UJWQmK006510; Wed, 30 Aug 2006 13:32:26 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UJWGsM016820; Wed, 30 Aug 2006 13:32:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UJVKGo027047; Wed, 30 Aug 2006 14:31:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UJVKH0027046; Wed, 30 Aug 2006 14:31:20 -0500 (CDT) Date: Wed, 30 Aug 2006 14:31:20 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830193119.GE10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@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: -2.5 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 12:24:14PM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >If so then the only reasonable conclusion is that integ_req_flag == > >FALSE MUST NOT imply that integrity protection is not available. > > So how would this be stated in the document? It doesn't have to be. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLG-0001BO-NR; Wed, 30 Aug 2006 16:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLE-00019S-8G; Wed, 30 Aug 2006 16:07:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWLE-0002O1-6k; Wed, 30 Aug 2006 16:07:16 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIVmS-0000fh-Ny; Wed, 30 Aug 2006 15:31:22 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA18425; Wed, 30 Aug 2006 21:30:53 +0200 (MESZ) From: Martin Rex Message-Id: <200608301930.VAA05629@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 30 Aug 2006 21:30:50 +0200 (MET DST) In-Reply-To: <20060830185644.GB10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 30, 6 01:56:44 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-SAP: out X-Spam-Score: -2.2 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, mrc@CAC.Washington.EDU, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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: > > > GSSAPI violates this; V2 specifically states that it does not make > > backward-incompatible changes. > > If so then the only reasonable conclusion is that integ_req_flag == > FALSE MUST NOT imply that integrity protection is not available. YES! I tried to say this in so many ways. > > Can we stop now? Yes, please. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLF-00019x-4a; Wed, 30 Aug 2006 16:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLD-00018u-Pc; Wed, 30 Aug 2006 16:07:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWLD-0002Jt-Nl; Wed, 30 Aug 2006 16:07:15 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIVnX-0000hK-9q; Wed, 30 Aug 2006 15:32:27 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UJWQmK006510; Wed, 30 Aug 2006 13:32:26 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UJWGsM016820; Wed, 30 Aug 2006 13:32:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UJVKGo027047; Wed, 30 Aug 2006 14:31:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UJVKH0027046; Wed, 30 Aug 2006 14:31:20 -0500 (CDT) Date: Wed, 30 Aug 2006 14:31:20 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830193119.GE10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@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: -2.5 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 12:24:14PM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >If so then the only reasonable conclusion is that integ_req_flag == > >FALSE MUST NOT imply that integrity protection is not available. > > So how would this be stated in the document? It doesn't have to be. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLG-0001BO-NR; Wed, 30 Aug 2006 16:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWLE-00019S-8G; Wed, 30 Aug 2006 16:07:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWLE-0002O1-6k; Wed, 30 Aug 2006 16:07:16 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIVmS-0000fh-Ny; Wed, 30 Aug 2006 15:31:22 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA18425; Wed, 30 Aug 2006 21:30:53 +0200 (MESZ) From: Martin Rex Message-Id: <200608301930.VAA05629@uw1048.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 30 Aug 2006 21:30:50 +0200 (MET DST) In-Reply-To: <20060830185644.GB10208@binky.Central.Sun.COM> from "Nicolas Williams" at Aug 30, 6 01:56:44 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-SAP: out X-Spam-Score: -2.2 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: kitten@ietf.org, mrc@CAC.Washington.EDU, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to 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: > > > GSSAPI violates this; V2 specifically states that it does not make > > backward-incompatible changes. > > If so then the only reasonable conclusion is that integ_req_flag == > FALSE MUST NOT imply that integrity protection is not available. YES! I tried to say this in so many ways. > > Can we stop now? Yes, please. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWar-0003H4-8v; Wed, 30 Aug 2006 16:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWap-0003Fn-LY; Wed, 30 Aug 2006 16:23:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITFR-0001yf-VK; Wed, 30 Aug 2006 12:49:05 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GITAq-00047N-Q8; Wed, 30 Aug 2006 12:44:25 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UGiKH3017020; Wed, 30 Aug 2006 10:44:20 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UGiJop003460; Wed, 30 Aug 2006 10:44:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UGiJkC026847; Wed, 30 Aug 2006 11:44:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UGiJNZ026846; Wed, 30 Aug 2006 11:44:19 -0500 (CDT) Date: Wed, 30 Aug 2006 11:44:19 -0500 From: Nicolas Williams To: Mark Crispin Message-ID: <20060830164418.GP10208@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@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: -2.5 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 09:19:40AM -0700, Mark Crispin wrote: > On Wed, 30 Aug 2006, Nicolas Williams wrote: > >Implementors of C bindings of the GSS-API (RFC2744) should do library > >versioning to prevent this problem. Similarly for other language > >bindings of the GSS-API. > > I agree. But they didn't do that. > > >Therefore this should not be a possible outcome. If it is then it is > >because either: a) you screwed up, and/or b) your GSS-API implementor > >screwed up. > > (b) has happened. They probably did not realize that there would be a > problem; they thought that all they had to do was substitute their new > bits and all the old software would continue to work. Did you link statically? If so, there's no issue. Did you link dynamically? If so, did the library version change? If not, did the implementor break apps that don't set the integ_req_flag? Has the implementor not assured you that they wouldn't do that in a future release? > They probably acted in good faith. After all, the GSSAPI specification > goes to length to talk about backwards compatibility except for this one > wart. C library versioning is non-standard. And the implementor is still acting in good faith by not breaking backwards compatibility. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWmg-00019I-7T; Wed, 30 Aug 2006 16:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWme-000192-Vw; Wed, 30 Aug 2006 16:35:36 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWmc-0006VZ-FE; Wed, 30 Aug 2006 16:35:36 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge2) with ESMTP id k7UKZB6o011813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 22:35:11 +0200 From: Simon Josefsson To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060830:iesg@ietf.org::Al4fE0E1biVJ7Nwq:9t7n X-Hashcash: 1:22:060830:kitten@ietf.org::uqL5d1vDmfpUf+g6:CHIL X-Hashcash: 1:22:060830:jhutz@cmu.edu::Vn5k8WbxFVSJmi1Z:H4VF X-Hashcash: 1:22:060830:hartmans-ietf@mit.edu::XCzoTi8PgtMLoea7:Io+T X-Hashcash: 1:22:060830:ietf-sasl@imc.org::wOqJTPbSfunAU8s8:e3gv X-Hashcash: 1:22:060830:mrc@cac.washington.edu::JftttjdGpBoKgrau:O+Q3 Date: Wed, 30 Aug 2006 22:35:11 +0200 In-Reply-To: <20060830173653.GT10208@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 30 Aug 2006 12:36:54 -0500") Message-ID: <87hczudksg.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Nicolas Williams writes: > On Wed, Aug 30, 2006 at 06:41:07PM +0200, Simon Josefsson wrote: >> None of the GSS-API libraries I've worked with provides library >> versioning that corresponds to the GSS-API revision. Several Kerberos >> GSS-API mechanisms (including MIT's) support the integ_req flag >> without implementing all of GSS-API v2u1, or even all of v2. The >> versioning of GSS-API is not consistently visible at the API level. > > Is this because they've never made backwards-incompatible changes, such > as requiring use of integ_req_flag in order to get integrity protection? Yes, perhaps. > Would that not be a valid response by implementors who did not version > their GSS libraries, that they will change the major version number only > when they make backwards-incompatible changes? That question seem to assumes that changing the major version number of the GSS-API library would be noticed by anyone. I don't think this is the case in practice. I don't know any programmatic way to discover the major library version nor the GSS-API revision from the GSS-API library that I use in my SASL library. Is there one? The situation is complicated because I typically only ship source code. What would be useful for application writers would be to check which GSS-API revision a particular GSS-API library implements, preferably both at build-time (for C, perhaps a CPP symbol) and during run-time (a new API). /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWov-0003yB-6C; Wed, 30 Aug 2006 16:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWot-0003y3-9b; Wed, 30 Aug 2006 16:37:55 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWor-0006na-Sg; Wed, 30 Aug 2006 16:37:55 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge2) with ESMTP id k7UKbak5012065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 22:37:36 +0200 From: Simon Josefsson To: Sam Hartman References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060830:kitten@ietf.org::+mnph6KGKiq9SI5p:eI6 X-Hashcash: 1:22:060830:jhutz@cmu.edu::Dgj3tMbgYiQf3FVF:BpxO X-Hashcash: 1:22:060830:ietf-sasl@imc.org::N6Qxc1HX6gIeE3Pn:I4qD X-Hashcash: 1:22:060830:iesg@ietf.org::brBzvxI58oqHENoJ:JQDI X-Hashcash: 1:22:060830:mrc@cac.washington.edu::vMPDwW3VzB/cl3GI:CN6N X-Hashcash: 1:22:060830:hartmans-ietf@mit.edu::L/dQWjBqfdIg6KDV:CEcR Date: Wed, 30 Aug 2006 22:37:36 +0200 In-Reply-To: (Sam Hartman's message of "Wed, 30 Aug 2006 13:14:19 -0400") Message-ID: <87ac5mdkof.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > > Simon> Adding an implementation note to explain the situation > Simon> seems like the best solution to me. > > I'm happy with a non-normative implementation note. I've proposed > text which has received a luke-warm reception. I think your text is OK. It may be tweaked further, but I don't have any concrete suggestions. The point is to make the reader aware that there is a potential problem here. I don't think anyone will think of checking the GSS-API revision of the GSS-API library they use otherwise. /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 16:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIX9j-000511-CY; Wed, 30 Aug 2006 16:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIX9h-00050q-VD; Wed, 30 Aug 2006 16:59:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIVKS-0000uS-9D; Wed, 30 Aug 2006 15:02:24 -0400 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIV6t-00084r-VU; Wed, 30 Aug 2006 14:48:26 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UImMv8007723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 11:48:23 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UImL1E028750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Aug 2006 11:48:22 -0700 Date: Wed, 30 Aug 2006 11:48:21 -0700 (PDT) From: Mark Crispin To: Nicolas Williams In-Reply-To: <20060830173653.GT10208@binky.Central.Sun.COM> Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.112443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, 30 Aug 2006, Nicolas Williams wrote: > Is this because they've never made backwards-incompatible changes, such > as requiring use of integ_req_flag in order to get integrity protection? I don't know. Do you? > Would that not be a valid response by implementors who did not version > their GSS libraries, that they will change the major version number only > when they make backwards-incompatible changes? GSSAPI violates this; V2 specifically states that it does not make backward-incompatible changes. Perhaps you meant that backwards-incompatible changes are made only when the major version number is change. If so, GSSAPI violates this as well; the change was made between V2 and V2.1, not (as falsely claimed by RFC 2743) between V1 and V2. How does notification work for a change in major version number? In particular, what change is made to GSSAPI, so that someone who does a "make" of an application that picks up the wrong version of GSSAPI gets an error, and consequently is obliged to make some edit to the application to comply with the new version of GSSAPI? Which standards document (not necessarily IETF) mandates all this? Vendors have a long history of being quite careless on this point, and I would love to have a standard to fling at the next violator. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 17:50:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXwW-0004ac-U6; Wed, 30 Aug 2006 17:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXwV-0004aN-Fk; Wed, 30 Aug 2006 17:49:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWKB-00028B-RF; Wed, 30 Aug 2006 16:06:11 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIWK2-0001ks-Cg; Wed, 30 Aug 2006 16:06:04 -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 k7UK61dV000018; Wed, 30 Aug 2006 14:06:01 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UK5kWn000532; Wed, 30 Aug 2006 14:06:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UK4p1d027068; Wed, 30 Aug 2006 15:04:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UK4pSI027067; Wed, 30 Aug 2006 15:04:51 -0500 (CDT) Date: Wed, 30 Aug 2006 15:04:50 -0500 From: Nicolas Williams To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org Message-ID: <20060830200449.GO10458@binky.Central.Sun.COM> Mail-Followup-To: Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <20060830164418.GP10208@binky.Central.Sun.COM> <20060830173915.GU10208@binky.Central.Sun.COM> <20060830185516.GA10208@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060830185516.GA10208@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.5 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 I suppose I should clarify that vendors, Sun included, don't always fix all bugs. My point is that the particular bug you are concerned about would very likely be considered a bug by Sun (oh, I personally can't guarantee even that much, that's true also). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 18:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIYgv-00029y-Mf; Wed, 30 Aug 2006 18:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIYgu-00029a-8k; Wed, 30 Aug 2006 18:37:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIXN3-0002qX-5n; Wed, 30 Aug 2006 17:13:13 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIX5e-0004HU-RZ; Wed, 30 Aug 2006 16:55:16 -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 k7UKtDwu007249; Wed, 30 Aug 2006 14:55:13 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UKsgJ3021368; Wed, 30 Aug 2006 14:55:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UKsHte027438; Wed, 30 Aug 2006 15:54:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UKsGV0027437; Wed, 30 Aug 2006 15:54:16 -0500 (CDT) Date: Wed, 30 Aug 2006 15:54:16 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060830205415.GA27432@binky.Central.Sun.COM> Mail-Followup-To: Simon Josefsson , Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, Sam Hartman , iesg@ietf.org, Jeffrey Hutzelman References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <87hczudksg.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hczudksg.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf-sasl@imc.org, kitten@ietf.org, iesg@ietf.org, Mark Crispin , Sam Hartman , Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 10:35:11PM +0200, Simon Josefsson wrote: > > Would that not be a valid response by implementors who did not version > > their GSS libraries, that they will change the major version number only > > when they make backwards-incompatible changes? > > That question seem to assumes that changing the major version number > of the GSS-API library would be noticed by anyone. I don't think this > is the case in practice. I don't know any programmatic way to > discover the major library version nor the GSS-API revision from the > GSS-API library that I use in my SASL library. Is there one? The > situation is complicated because I typically only ship source code. If you dynamically link against one version of a library and that version is replaced by a new major version something very noticeable should happen. Of course we're in the realm of platform-specific details. I'm done with this thread. I'm not sure what else can be said of any value that could affect the consensus. For the record: I believe no changes are needed to this I-D with regards to integ_req_flag. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 18:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIYue-0000l5-DZ; Wed, 30 Aug 2006 18:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIYuc-0000jz-Pd; Wed, 30 Aug 2006 18:51:58 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIYub-00083G-HJ; Wed, 30 Aug 2006 18:51:58 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4E1BCE00C0; Wed, 30 Aug 2006 18:51:56 -0400 (EDT) From: Sam Hartman To: Mark Crispin References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@binky.Central.Sun.COM> Date: Wed, 30 Aug 2006 18:51:56 -0400 In-Reply-To: (Mark Crispin's message of "Wed, 30 Aug 2006 12:24:14 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org, Nicolas Williams Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 >>>>> "Mark" == Mark Crispin writes: Mark> RFC 2222 did not have the requirement, added in this Mark> revision, that integ_req_flag be set by the caller to Mark> GSS_Init_sec_context(). There is no means by which GSSAPI Mark> can know that the caller complies with RFC 2222 or with this Mark> update. Mark> Therefore, the language on page 47 of RFC 2743 is to be Mark> interpreted as indicating that a GSSAPI (Kerberos v5) SASL Mark> mechanism caller to GSS_Init_sec_context() that does not set Mark> integ_req_flag complies with RFC 2222 and not with this Mark> revision. To maintain interoperability, the GSSAPI layer Mark> SHOULD infer integ_req_flag as set, as described on page 47 Mark> of RFC 2743. Both of these requirements attempt to place normative changes on gss mechanisms; that's inappropriate for this document. I think the best you can do is: Therefore, RFC 2222 implementations will not work with GSS implementations that require integ_req_flag to be true. No implementations of RFC 1964 or RFC 4121 that require integ_req_flag to be true are believed to exist and it is expected that any future update to RFC 4121 will require that integrity be available even in not explicitly requested by the application. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 19:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZSd-0006BL-Sn; Wed, 30 Aug 2006 19:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZSc-0006B5-My; Wed, 30 Aug 2006 19:27:06 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIZSa-0004eW-DI; Wed, 30 Aug 2006 19:27:06 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7UNR38D023750; Wed, 30 Aug 2006 17:27:03 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7UNQhMO025383; Wed, 30 Aug 2006 17:27:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7UNQNhf027715; Wed, 30 Aug 2006 18:26:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7UNQMKZ027714; Wed, 30 Aug 2006 18:26:22 -0500 (CDT) Date: Wed, 30 Aug 2006 18:26:22 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060830232621.GE27432@binky.Central.Sun.COM> Mail-Followup-To: Sam Hartman , Mark Crispin , kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org References: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wed, Aug 30, 2006 at 06:51:56PM -0400, Sam Hartman wrote: > I think the best you can do is: > > Therefore, RFC 2222 implementations will not work with GSS > implementations that require integ_req_flag to be true. No > implementations of RFC 1964 or RFC 4121 that require integ_req_flag to > be true are believed to exist and it is expected that any future > update to RFC 4121 will require that integrity be available even in > not explicitly requested by the application. I will not object to this text. I do not think it necessary. I would also not object to adding a reference to the compatibility note in RFC2743, section 2.2.1 -- think of mechglue's that too could require the caller set these flags in order to be able to use the corresponding per-message token services. I believe that the compatibility note in RFC2743, section 2.2.1, is clear that implementations which enforce the incompatible change must distinguish between GSS-API v1 and v2 callers. I believe therefore that no compliant GSS-API implementation, mechglue or mechanism, can break RFC2222 SASL/GS1 implementations. That makes this whole thing a non-issue. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Aug 30 19:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZWT-00089B-Ex; Wed, 30 Aug 2006 19:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZWS-000891-DV; Wed, 30 Aug 2006 19:31:04 -0400 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIZWR-00055v-1V; Wed, 30 Aug 2006 19:31:04 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UNV1Cm016578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Aug 2006 16:31:02 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k7UNV14r019273 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Aug 2006 16:31:01 -0700 Date: Wed, 30 Aug 2006 16:29:00 -0700 (Pacific Daylight Time) From: Mark Crispin To: Sam Hartman In-Reply-To: Message-ID: References: <5B68D79CC001A4898FDA9C85@sirius.fac.cs.cmu.edu> <869CB502DAE20AF76784381D@sirius.fac.cs.cmu.edu> <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@binky.Central.Sun.COM> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.30.160942 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: kitten@ietf.org, ietf-sasl@imc.org, iesg@ietf.org, Nicolas Williams Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 If this the best that can be done, then please do it. Thanks. On Wed, 30 Aug 2006, Sam Hartman wrote: > I think the best you can do is: > > Therefore, RFC 2222 implementations will not work with GSS > implementations that require integ_req_flag to be true. No > implementations of RFC 1964 or RFC 4121 that require integ_req_flag to > be true are believed to exist and it is expected that any future > update to RFC 4121 will require that integrity be available even in > not explicitly requested by the application. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Aug 31 11:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIorb-00054J-LA; Thu, 31 Aug 2006 11:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIorZ-00053s-J0; Thu, 31 Aug 2006 11:53:53 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIorY-0004ZX-B7; Thu, 31 Aug 2006 11:53:53 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7VFrjsH004371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 11:53:45 -0400 (EDT) Date: Thu, 31 Aug 2006 11:53:45 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman Message-ID: <2BC6E3AD4EE926F560E80F81@sirius.fac.cs.cmu.edu> In-Reply-To: <20060830232621.GE27432@binky.Central.Sun.COM> References: <184A806BC1D07A91FE656117@sirius.fac.cs.cmu.edu> <20060830152859.GL10208@binky.Central.Sun.COM> <87odu2dvmk.fsf@latte.josefsson.org> <20060830173653.GT10208@binky.Central.Sun.COM> <20060830185644.GB10208@binky.Central.Sun.COM> <20060830232621.GE27432@binky.Central.Sun.COM> Originator-Info: login-token=Mulberry:01SqiUhLQQCfiW8wwFfSbE8+Eay6/R3A23HcLpgCg=; 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: d6b246023072368de71562c0ab503126 Cc: kitten@ietf.org, Mark Crispin , ietf-sasl@imc.org, iesg@ietf.org, Jeffrey Hutzelman Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi) 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 Wednesday, August 30, 2006 06:26:22 PM -0500 Nicolas Williams wrote: > On Wed, Aug 30, 2006 at 06:51:56PM -0400, Sam Hartman wrote: >> I think the best you can do is: >> >> Therefore, RFC 2222 implementations will not work with GSS >> implementations that require integ_req_flag to be true. No >> implementations of RFC 1964 or RFC 4121 that require integ_req_flag to >> be true are believed to exist and it is expected that any future >> update to RFC 4121 will require that integrity be available even in >> not explicitly requested by the application. > > I will not object to this text. I do not think it necessary. I concur. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Aug 31 13:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIq6U-0001Tp-5y; Thu, 31 Aug 2006 13:13:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIq6S-0001K1-G1 for kitten@ietf.org; Thu, 31 Aug 2006 13:13:20 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIq6P-0002y2-Py for kitten@ietf.org; Thu, 31 Aug 2006 13:13:20 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7VHDGml011274 for ; Thu, 31 Aug 2006 10:13:17 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7VHDBJ1018190 for ; Thu, 31 Aug 2006 11:13:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7VHCe6a029078; Thu, 31 Aug 2006 12:12:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7VHCe2k029077; Thu, 31 Aug 2006 12:12:40 -0500 (CDT) Date: Thu, 31 Aug 2006 12:12:40 -0500 From: Nicolas Williams To: kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov Message-ID: <20060831171239.GB29007@binky.Central.Sun.COM> Mail-Followup-To: kitten@ietf.org, ietf-sasl@imc.org, ietf-krb-wg@anl.gov References: <20060829205723.GM10458@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060829205723.GM10458@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: Subject: Text (Re: Proposed updates for domain-based drafts) 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 Proposed changes to draft-ietf-kitten-gssapi-domain-based-names-02.txt below. The changes amount to: - recast the purpose of domain-based names, namely: protecting applicationst that use insecure server discovery - clarify that the meaning of "domain" here is application specific - Provide non-normative examples - Add references Comments? Abstract This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) instead of or in addition to a hostname. The primary purpose of - domain-based service names is to provide a way to name clustered - services after the domain which they service, thereby allowing their - clients to authorize the service's servers based on authentication of - their names. + domain-based names is to provide a measure of protection to + applications that utilize insecure service discovery protocols. This + is achieved by providing a way to name clustered services after the + domain which they service, thereby allowing their clients to + authorize the service's servers based on authentication of their + service names. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . 5 4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . 6 - 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Examples of domain-based names . . . . . . . . . . . . . . . 6 + 5. Application protocol examples . . . . . . . . . . . . . . . 7 + 5.1. NFSv4 domain-wide namespace root server discovery . . . . . 7 + 5.2. LDAP server discovery . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 [...] 2. Introduction - The use of hostbased principal names for domain-wide services - presents the problem of how to distinguish between an instance of a - hostbased service that is authorized to respond for a domain and one - that isn't. + Some applications need to discover the names of servers for a + specific resource. Some common methods for server discovery are + insecure, e.g., queries for DNS [RFC1035] SRV resource records + [RFC2782] without using DNSSEC [RFC4033] and subject to attacks + whereby a client can be re-directed to incorrect and possibly + malicious servers. A client may even be re-directed to a server that + has credentials for itself and may thus authenticate itself to the + client, and yet it could be incorrect or malicious (because it has + been compromised, say). - Consider LDAP. LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V - mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased - principal with a service name of "ldap", a reasonable approach, - provided there is only one logical LDAP directory in a Kerberos - realm's domain, and that all ldap servers in that realm serve that - one LDAP directory. An network might have multiple, distinct LDAP - services, but only one LDAP "name service"; if so then clients could - not tell which LDAP service principals are 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 allow for GSS-API [RFC2743] initiator applications + (clients) to authorize acceptor principals (servers) to serve the + resource for which the client used insecure server discovery without + either securing the server discovery method nor requiring an + additional protocol for server authorization -- either a discovered + server has credentials for authenticating the domain-based service + names that it is intended to respond to, or it does not. + Availability of valid credentials for authenticating domain-based + names embodies the authorization of a given server to a domain-wide + service. - Domain based names can eliminate this problem: the use of domain- - based names should imply that the given host is a server for the - official LDAP name service of the given domain. - - Notwithstanding the LDAP example the use of domain-based principal - names for LDAP is not actually specified here and will be specified - in a separate document. - A domain-based name consists of three required elements: o a service name o a domain name o a hostname + For the purposes of domain-based names a "domain" is defined by the + applications that use domain-based names. An application protocol + might use a simple DNS domainname, such as "example.com" for naming, + while another it might use the DNS domainname of the SRV RRs it + queries (e.g., "_tcp._foo.example.com"), and yet another may use + something that does not resemble a DNS domainname. Application + protocol specifications that provide for use of domain-based service + names MUST define the domain-portion of their domain-based names. [...] 4. Query and Display Syntaxes There is a single name syntax for domain-based names. The syntax is: domain-based-name := - | '@' '@' + '@' '@' - Note that for Internet domain names the trailing '.' is not and MUST - NOT be included in the domain name (or hostname) parts of the display - form GSS-API domain-based MNs. + Note that for Internet domain names the trailing '.' MUST NOT be + included in the hostname part of the display form GSS-API domain- + based MNs; hostnames MUST NOT contain '@'. +4.1. Examples of domain-based names + These examples are not normative: + o ldap@example.tld@ds1.example.tld + o nfs@example.tld@nfsroot1.example.tld -5. Examples +5. Application protocol examples - o ldap@example.tld@ds1.example.tld + The following examples are not normative. They describe how the + author envisions two applications' use of domain-based names. - o kadmin@example.tld@kdc1.example.tld +5.1. NFSv4 domain-wide namespace root server discovery + Work is ongoing to provide a method for constructing domain-wide + NFSv4 [RFC3530] filesystem namespaces where there is a single "root" + with one or more servers (replicas) and multiple filesystems glued + into the namespace through use of "referrals." Clients could then + construct a "global" namespace through use of the DNS domain + hierarchy. + Here clients would always know, from context, when they need to find + the root servers for a given DNS domain. Root server discovery would + be performed using DNS SRV RR lookups, without using DNSSEC where + DNSSEC has not been deployed. + When using RPCSEC_GSS [RFC2203] for security NFSv4 clients would then + use domain-based names to ensure that that the servers named in the + SRV RRs are in fact authorized to be the NFSv4 root servers for the + target domain. +5.2. LDAP server discovery + LDAP clients using the GSS-API through SASL too would benefit from + use of domain-based names to protect server discovery through + insecure DNS SRV RR lookups, much as described above. + Unlike NFSv4 clients, not all LDAP clients may always know from + context when they should use domain-based names. That's because + existing clients may use host-based naming to authenticate servers + discovered through SRV RR lookups. Changing such clients to use + domain-based naming when domain-based acceptor credentials have not + been deployed to LDAP servers, or when LDAP servers have not been + modified to allow use of domain-based naming, would break + interoperability. That is, there is a legacy server interoperability + issue here. Therefore LDAP clients may require additional + configuration at deployment time to enable (or disable) use of + domain-based naming. + Note: whether SASL [RFC4422] or its GSS-API bridges [I-D.ietf-sasl- + gssapi] [I-D.josefsson-sasl-gs2] require updates in order allow use + of domain-based names is not relevant to the theory of how domain- + based naming would protect LDAP clients' server discovery. 6. Security Considerations Use of GSS-API domain-based names may not be negotiable by some GSS- API mechanisms, and some acceptors may not support GSS-API domain- based names. In such cases initiators are left to fallback on the use of hostbased names, in which case the initiators MUST also verify that the acceptor's hostbased name is authorized to provide the given service for the domain that the initiator had wanted. The above security consideration also applies to all GSS-API initiators who lack support for domain-based service names. [...] 7.1. Normative + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. -7.2. Informative + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. - [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", - RFC 1964, June 1996. + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. - [RFC2222] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. +7.2. Informative - [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. + [I-D.ietf-sasl-gssapi] + Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", + draft-ietf-sasl-gssapi-06 (work in progress), June 2006. + [I-D.josefsson-sasl-gs2] + Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2 + Mechanism Family", draft-josefsson-sasl-gs2-00 (work in + progress), November 2005. + [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol + Specification", RFC 2203, September 1997. + [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., + Beame, C., Eisler, M., and D. Noveck, "Network File System + (NFS) version 4 Protocol", RFC 3530, April 2003. + [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and + Security Layer (SASL)", RFC 4422, June 2006. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten