From kitten-bounces@lists.ietf.org Fri Mar 02 16:36:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFQ5-0001yw-V1; Fri, 02 Mar 2007 16:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFQ5-0001yZ-7E for kitten@ietf.org; Fri, 02 Mar 2007 16:36:05 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNFQ3-0002fM-Ke for kitten@ietf.org; Fri, 02 Mar 2007 16:36:05 -0500 Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l22La27u009402 for ; Fri, 2 Mar 2007 16:36:03 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.5) with ESMTP id md50000045413.msg for ; Fri, 02 Mar 2007 16:36:25 -0500 Message-ID: <45E898D1.7000705@secure-endpoints.com> Date: Fri, 02 Mar 2007 16:36:17 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kitten X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Fri, 02 Mar 2007 16:36:25 -0500 (not processed: message from valid local sender) X-Lookup-Warning: EHLO lookup on [192.168.1.13] does not match 24.193.47.99 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: Kitten Meeting at IETF68 has been canceled X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0267197047==" Errors-To: kitten-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0267197047== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020303060207080803080201" This is a cryptographically signed message in MIME format. --------------ms020303060207080803080201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After speaking with our Security Area Director, Sam Hartman, it has been decided that Kitten will not meet at IETF68. Kitten will hold its next meeting in Chicago at IETF69. Jeffrey Altman Kitten Chair --------------ms020303060207080803080201 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAzMDIyMTM2MThaMCMGCSqGSIb3DQEJBDEWBBRTDv2M phz2tIGVouB8ieb8R0dMCTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAdyy7eqP82t+Ym3e/VjlaOJ9Ncj8K2zJ5nBg8jbJ7/IikhYwsuRYy 7OtExu3pUuMBW5WgxDrhTJKXAxjgmZ3Nk2zJNAp3Jzd0JlrvJ7wfxc4Lg1q2R8TFWmT8nxt0 S9Cn0FyJ8xxhAZ6FSEsJyj9Q6aI/YZIExcssxC3NdT18Rd8YGzMBlsdC5hqgrkM8fUEVYGBa brfG8Jr798GC8f5A5dAvfZDuPWsBx/T3LqsKhuJWOHykRkDpG6QODg0aGwvH7FSRX5I/ShjN ylA1223O8mFqUvIqafnH5WDjesRmi/p0s51tZeHGldyWrkMLqXdmtXx7gBssXD4ykmYr7bXD VwAAAAAAAA== --------------ms020303060207080803080201-- --===============0267197047== 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 --===============0267197047==-- From kitten-bounces@lists.ietf.org Wed Mar 14 16:10:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZmf-00084G-4k; Wed, 14 Mar 2007 16:09:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRZme-00084B-I3 for kitten@ietf.org; Wed, 14 Mar 2007 16:09:16 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRZmd-0002Kg-3I for kitten@ietf.org; Wed, 14 Mar 2007 16:09:16 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA07010 for ; Wed, 14 Mar 2007 22:08:59 +0200 (MESZ) From: Martin Rex Message-Id: <200703142008.VAA20302@uw1048.wdf.sap.corp> To: kitten@ietf.org Date: Wed, 14 Mar 2007 21:08:36 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Subject: Last Call: draft-williams-on-channel-binding 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 I know it is in IETF last call (not WG last call) and I'm pretty late (as always). Section 2 Definitions o Cryptographic bindings (bottom of page 5) For example, a PKIX certificate binds a private key to the name of a principal in the trust domain of the certificate's issuer such that a possessor of said private key can act on behalf of the user (or other entity) named by the certificate. A PKIX certificate binds a >>public key<< to the name of a principal, NOT a private key. The public key acts as a verifier for a cryptographic proof-of-possession of a corresponding private key. (And in the traditional PKI, there is no "act on behalf of" (=delegation), the assumption is always always that he who can provide a proof that can be verified with the public key it is the one and only rightful owner asserted by the certificate.) (we don't say that a user speaks for their private keys, but we do say that the user's private keys speak for the user). The private key is NEVER involved in anything the verifier does. The assumptions surrounding the key pair and private key include - the keypair was correctly created - the private key is sufficiently protected from compromise - the owner doesn't compromise/publish the private key on purpose - the keypair is sufficiently strong (long) against brute force attacks - the underlying cryptoalgorithm is sufficiently strong - the registration process is sufficiently reliable to assure that one can not easily get a certificate issued in someone elses name - the involved CAs in a trust hierarchy can not be corrupted to issue certs in someone elses name If the proof-of-possession of a particular protocol involves signing a challenge(data), then each protocol must ensure that NO other usage of a given keypair in any other protocol or scenario will ever request a signature on the same challenge(data). Otherwise a replay (attack) might be possible that does not require possession of the private key. Is the document intended to go to RFC with exactly this annotation: ? 2.1. Properties of channel binding [NOTE: This section needs more work, I'm sure I've missed somethings...] 3.1. The GSS-API and channel binding The GSS-API [RFC2743] provides for the use of channel binding during initialization of GSS-API security contexts, though GSS-API mechanisms are not required to support this facility. Authentication-only GSS-API mechanisms will usually be unable to support channel bindings (due to lack of integrity protection facilities). 4.1. Examples of unique channel bindings For TLS [RFC4346]the TLS session ID is not sufficient as it is assigned by the server, and so could be assigned by an MITM to match a server's. Instead the initial, unencrypted TLS finished messages, either the client's, the server's or both, are sufficient as they are the output of the TLS PRF, keyed with the session key, applied to all handshake material. This applies ONLY for end-to-end TLS scenarios. If there are several consecutive TLS tunnels between the client app and the server app, TLS channel bindings may be entirely impossible, e.g. when the "backend/server" uses TLS-protected channels between backend components to forward or load-balance requests within a backend landscape/farm (SSL-Accellerators, reverse-proxies) that is otherwise transparent for the client. Also keep in mind that authentication is not really used in common HTTPS-scenarios. There is some fairly weak "endpoint identification". I really appreciated the terminology used by EKR in rfc2818, not a single occurance of the word "authentication" (because there is none in HTTPS without client certificates). There is a serious trust gap between the "users intent" and the typo-prone guesstimate of what a user entered into a browsers address bar, or between the "users intent" and the (camouflaged) hostname in an URL of a phishing Email or phishing Website. 8. Security Considerations Channel bindings should be constructed in such a way that revealing the channel bindings of a channel to third parties does not weaken the security of the channel. However, for end-point channel bindings disclosure of the channel bindings may disclose the identities of the peers. In 4.1. it says: Instead the initial, unencrypted TLS finished messages, either the client's, the server's or both, are sufficient as they are the output of the TLS PRF, keyed with the session key, applied to all handshake material. So the general message is that whatever you use for channel bindings may leak. With this premise I would really suggest that a recommendation be added: whenever previously secret information is made part of channel bindings, it should be used in a cryptographically irreversible fashion (hash/mac) and not directly. Cleartext finished messages of a TLS handshake have not normally been available. Although *I* can not directly think of an immediate threat when they become "available" to observers/attackers, I would recommend against it. Appendix A. Sam Hartman for pointing out that channel binding provide a general solution to the channel binding problem, Hmmmm. I haven't yet figured out what this means. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 16 16:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJSa-0001RQ-TA; Fri, 16 Mar 2007 16:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSJSZ-0001Qb-J0 for kitten@lists.ietf.org; Fri, 16 Mar 2007 16:55:35 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSJPk-0004pj-Vj for kitten@lists.ietf.org; Fri, 16 Mar 2007 16:52:42 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 7B38439278; Fri, 16 Mar 2007 16:52:40 -0400 (EDT) Message-ID: <45FB0398.3080406@citi.umich.edu> Date: Fri, 16 Mar 2007 16:52:40 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org, Nicolas Williams Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Section 3 If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. Why state this? In the motivation section, it has been stated that: "there is no trusted third party in such environments." While it is stated that "consequently the Kerberos protocol as defined in [RFC4120] and [RFC4556] is inadequate to provide security services ", this document's writing heavily depends on it and PKU2U is basically rfc4556 where the server is not a KDC. If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section 3.1.3 of [RFC4120]. Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike KDC and principal, acceptor and initiator don't share any secrets. PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of the ticket created by the acceptor. In all cases, GSS_Accept_security_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented a ticket from being issued. If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, what happens when the initiator after processing the error token decides to stop, will the server just hang there in the continue needed state? Is having a MUST for PKINIT's EKUs too restrictive? Since this is a GSS API mechanism what about QoP handling and channel bindings? Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names. Name type NT-X500-PRINCIPAL which is rfc2253 string representation of the distinguished name does not produce a canonical name. What happens when the initiator rejects the AS-REP tokens sent by the acceptor (ie., fails to verify acceptor's certificate)? Does it generate an error token? Perhaps last paragraph of Section 6 can have a more detailed explanation that doesn't require the user to go search for a different draft to find our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm sure i'm missing something but why is there a need to tie AS_REQ/REP to AP_REQ/REP no such ties exist in original Kerberos message flow? Naming needs work. Comments made about naming in SPKM3 apply here. Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 16 17:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSK3T-000191-0e; Fri, 16 Mar 2007 17:33:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSK3S-00018t-BM; Fri, 16 Mar 2007 17:33:42 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSK3Q-0001yi-2Q; Fri, 16 Mar 2007 17:33:42 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l2GLXaNt003239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2007 17:33:37 -0400 (EDT) Date: Fri, 16 Mar 2007 17:33:35 -0400 From: Jeffrey Hutzelman To: Olga Kornievskaia , "Liqiang(Larry) Zhu" Message-ID: <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> In-Reply-To: <45FB0398.3080406@citi.umich.edu> References: <45FB0398.3080406@citi.umich.edu> Originator-Info: login-token=Mulberry:013R2YmUeFDQ0paBAaEJvICHSPz8RkURFKksb+E50=; 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: c1c65599517f9ac32519d043c37c5336 Cc: kitten@lists.ietf.org, Nicolas Williams , andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia wrote: > In all cases, GSS_Accept_security_context() returns > GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a > KRB_AS_REP message if a ticket was created or a KRB_ERROR message if > there was an error while processing the request or the local policy > prevented a ticket from being issued. > > If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, > what happens when the initiator after processing the error token decides > to stop, will the server just hang there in the continue needed state? This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be necessary to make the call again with another token provided by the peer. When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, it should also return an appropriate error status, not GSS_S_CONTINUE_NEEDED. > Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? The token ID for KRB_ERROR is defined in RFC 4121. > Perhaps last paragraph of Section 6 can have a more detailed explanation > that doesn't require the user to go search for a different draft to find > our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm > sure i'm missing something but why is there a need to tie AS_REQ/REP to > AP_REQ/REP no such ties exist in original Kerberos message flow? I'm not entirely sure what you're talking about here. The AS exchange is tied to a later AP exchange via the session key; this is true whether the AS exchange results in a TGT or directly in some other service ticket. However, this does not protect the integrity of the plaintext portion of the AS exchange, and in particular of PA-DATA contained in the AS-REQ, and this is generally considered to be a shortcoming of the current AS exchange. While this is likely to be fixed in the next update to the Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also possible for a higher layer to perform an after-the-fact integrity check of the entire AS exchange, as IAKERB does. Whether this is necessary or a good idea is, of course, up for discussion. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 16 22:02:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOER-0004Yk-HN; Fri, 16 Mar 2007 22:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOEP-0004YF-JQ for kitten@lists.ietf.org; Fri, 16 Mar 2007 22:01:17 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSOEJ-0002h7-7p for kitten@lists.ietf.org; Fri, 16 Mar 2007 22:01:17 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 19:01:10 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 19:01:10 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 19:01:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 19:01:09 -0700 Message-ID: In-Reply-To: <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoEtQO7SIGAeLrSMWmArQGOGajUAAJP2ZA References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman , Olga Kornievskaia X-OriginalArrivalTime: 17 Mar 2007 02:01:09.0740 (UTC) FILETIME=[21C58AC0:01C76838] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Michael.Eisler@netapp.com, Nicolas Williams , kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeff wrote: > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > necessary to make the call again with another token provided by the peer.=20 > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token,=20 > it should also return an appropriate error status, not=20 > GSS_S_CONTINUE_NEEDED. This is not necessary accurate. In the User2User protocol, http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t, the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. =20 -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Friday, March 16, 2007 2:34 PM To: Olga Kornievskaia; Liqiang(Larry) Zhu Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams; Jeffrey Hutzelman Subject: Re: Comments on draft-zhu-pku2u-01.txt On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia=20 wrote: > In all cases, GSS_Accept_security_context() returns > GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a > KRB_AS_REP message if a ticket was created or a KRB_ERROR message if > there was an error while processing the request or the local policy > prevented a ticket from being issued. > > If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error, > what happens when the initiator after processing the error token decides > to stop, will the server just hang there in the continue needed state? This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be=20 necessary to make the call again with another token provided by the peer.=20 When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token,=20 it should also return an appropriate error status, not=20 GSS_S_CONTINUE_NEEDED. > Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? The token ID for KRB_ERROR is defined in RFC 4121. > Perhaps last paragraph of Section 6 can have a more detailed explanation > that doesn't require the user to go search for a different draft to find > our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm > sure i'm missing something but why is there a need to tie AS_REQ/REP to > AP_REQ/REP no such ties exist in original Kerberos message flow? I'm not entirely sure what you're talking about here. The AS exchange is=20 tied to a later AP exchange via the session key; this is true whether the=20 AS exchange results in a TGT or directly in some other service ticket.=20 However, this does not protect the integrity of the plaintext portion of the AS exchange, and in particular of PA-DATA contained in the AS-REQ, and=20 this is generally considered to be a shortcoming of the current AS=20 exchange. While this is likely to be fixed in the next update to the=20 Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also=20 possible for a higher layer to perform an after-the-fact integrity check of=20 the entire AS exchange, as IAKERB does. Whether this is necessary or a=20 good idea is, of course, up for discussion. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 16 22:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOus-0007xx-D6; Fri, 16 Mar 2007 22:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSOuq-0007xK-Q6 for kitten@lists.ietf.org; Fri, 16 Mar 2007 22:45:08 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSOup-0007lq-6D for kitten@lists.ietf.org; Fri, 16 Mar 2007 22:45:08 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 19:45:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 19:45:06 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 19:45:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 19:45:05 -0700 Message-ID: In-Reply-To: <45FB0398.3080406@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoDSFprb0POxqgQbCYxfYgNbK/WwAKwdRg References: <45FB0398.3080406@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia X-OriginalArrivalTime: 17 Mar 2007 02:45:05.0968 (UTC) FILETIME=[45160300:01C7683E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org, Nicolas Williams Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Olga Kornievskaia wrote: > Why state this? In the motivation section, it has been stated that:=20 > "there is no trusted third party in such environments." While it is=20 > stated that "consequently the Kerberos protocol as defined in [RFC4120]=20 > and [RFC4556] is inadequate to provide security services ", this=20 > document's writing heavily depends on it and PKU2U is basically rfc4556=20 > where the server is not a KDC. This is designed for fast session resumption. When the initiator already obtained a service ticket in prior sessions, it can just use that cached ticket right away. > Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike=20 > KDC and principal, acceptor and initiator don't share any secrets.=20 > PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of=20 > the ticket created by the acceptor. RFC4556 updates RFC4120, unless there is something here specific to RFC4556, I do not see the need here. > Since this is a GSS API mechanism what about QoP handling and channel=20 > bindings? These are handled in the same way as described in RFC4121. > This draft does not support non-Kerberos environments. By that I mean, a=20 > Kerberos domain must exist and users of PKU2U must have Kerberos=20 > principal names. How was this deduced? What is a Kerberos domain? And it should not be needed. what environments are not supported? Can you expand on this?=20 > Name type NT-X500-PRINCIPAL which is rfc2253 string representation of=20 > the distinguished name does not produce a canonical name. PKU2U requires little endian order: The Distinguished Name contained in the PKU2U Kerberos principal name MUST begin with the most specific attribute and continue with progressively broader attrbiutes. With this constraint, is there a case where this does not produce a canonical name? > What happens when the initiator rejects the AS-REP tokens sent by the=20 > acceptor (ie., fails to verify acceptor's certificate)? Does it=20 > generate an error token? You can get an error token as in http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t. but typically the acceptor returns an error and aborts. > Naming needs work. Comments made about naming in SPKM3 apply here. Can you point me to the comments, it would help. Thanks for the review. --larry -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Friday, March 16, 2007 1:53 PM To: Liqiang(Larry) Zhu Cc: spkm@ietf.org; kitten@lists.ietf.org; Nicolas Williams; Michael.Eisler@netapp.com; andros@citi.umich.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt Section 3 If initially the initiator has a service ticket to the acceptor, the initiator, acting as the client in the parlance of [RFC4120], performs the client-server authentication exchange according to [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as the server. Why state this? In the motivation section, it has been stated that:=20 "there is no trusted third party in such environments." While it is=20 stated that "consequently the Kerberos protocol as defined in [RFC4120]=20 and [RFC4556] is inadequate to provide security services ", this=20 document's writing heavily depends on it and PKU2U is basically rfc4556=20 where the server is not a KDC. If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the initiator to present to the acceptor and the response is a KRB_AS_REP message generated according to Section 3.1.3 of [RFC4120]. Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike=20 KDC and principal, acceptor and initiator don't share any secrets.=20 PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of=20 the ticket created by the acceptor. In all cases, GSS_Accept_security_context() returns GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a KRB_AS_REP message if a ticket was created or a KRB_ERROR message if there was an error while processing the request or the local policy prevented a ticket from being issued. If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error,=20 what happens when the initiator after processing the error token decides to stop, will the server just hang there in the continue needed state? Is having a MUST for PKINIT's EKUs too restrictive? Since this is a GSS API mechanism what about QoP handling and channel=20 bindings? Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR? This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos=20 principal names. Name type NT-X500-PRINCIPAL which is rfc2253 string representation of=20 the distinguished name does not produce a canonical name. What happens when the initiator rejects the AS-REP tokens sent by the=20 acceptor (ie., fails to verify acceptor's certificate)? Does it=20 generate an error token? Perhaps last paragraph of Section 6 can have a more detailed explanation that doesn't require the user to go search for a different draft to find our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED. I'm sure i'm missing something but why is there a need to tie AS_REQ/REP to=20 AP_REQ/REP no such ties exist in original Kerberos message flow? Naming needs work. Comments made about naming in SPKM3 apply here. Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > =09 > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > =20 > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > =20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Mar 16 23:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSPZu-0004BM-9H; Fri, 16 Mar 2007 23:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSPZs-0004Ac-PM for kitten@lists.ietf.org; Fri, 16 Mar 2007 23:27:32 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSPZm-0004t9-IR for kitten@lists.ietf.org; Fri, 16 Mar 2007 23:27:32 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2H3RQT1021934 for ; Sat, 17 Mar 2007 03:27:26 GMT 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 l2H3ROAo008750 for ; Fri, 16 Mar 2007 21:27:25 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2H3QjiM022705; Fri, 16 Mar 2007 22:26:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2H3QhmY022704; Fri, 16 Mar 2007 22:26:43 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 16 Mar 2007 22:26:43 -0500 From: Nicolas Williams To: "Liqiang(Larry) Zhu" Message-ID: <20070317032642.GH22445@Sun.COM> Mail-Followup-To: "Liqiang(Larry) Zhu" , Jeffrey Hutzelman , Olga Kornievskaia , Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@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: d6b246023072368de71562c0ab503126 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Mar 16, 2007 at 07:01:09PM -0700, Liqiang(Larry) Zhu wrote: > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > > > necessary to make the call again with another token provided by the > peer. > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error > token, > > it should also return an appropriate error status, not > > GSS_S_CONTINUE_NEEDED. > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx > t, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism token -- they are implied. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Mar 17 01:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSRbi-0002Sy-1S; Sat, 17 Mar 2007 01:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSRbg-0002Si-Qs for kitten@lists.ietf.org; Sat, 17 Mar 2007 01:37:32 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSRba-0004jY-FL for kitten@lists.ietf.org; Sat, 17 Mar 2007 01:37:32 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 16 Mar 2007 22:37:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Fri, 16 Mar 2007 22:37:25 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Fri, 16 Mar 2007 22:37:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2007 22:37:24 -0700 Message-ID: In-Reply-To: <20070317032642.GH22445@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdoRDFxJciq5hMNTlqAV+V126leHAAEc/rQ References: <45FB0398.3080406@citi.umich.edu> <729D2796944018A823D6E75A@sirius.fac.cs.cmu.edu> <20070317032642.GH22445@Sun.COM> From: "Liqiang(Larry) Zhu" To: Nicolas Williams X-OriginalArrivalTime: 17 Mar 2007 05:37:25.0494 (UTC) FILETIME=[57EC7960:01C76856] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas.Williams wrote: > Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally > status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism > token -- they are implied. See section 6 of the user2user ID http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx t =20 6. User to User when applied by server policy=20 =20 In the case that the client application doesn't know that a service=20 requires user-to-user authentication, and requests and receives a=20 conventional KRB_AP_REP, the client will send the KRB_AP_REP=20 request, and the server will respond with a KRB_ERROR token as=20 described in RFC1964, with a msg-type of=20 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally=20 pass the TGT in the data field of this error message. In response to=20 this error, the initiator sets flags and returns a=20 GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism=20 described in section 4. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, March 16, 2007 8:27 PM To: Liqiang(Larry) Zhu Cc: Jeffrey Hutzelman; Olga Kornievskaia; Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt On Fri, Mar 16, 2007 at 07:01:09PM -0700, Liqiang(Larry) Zhu wrote: > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be >=20 > > necessary to make the call again with another token provided by the > peer.=20 > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error > token,=20 > > it should also return an appropriate error status, not=20 > > GSS_S_CONTINUE_NEEDED. >=20 > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx > t, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism token -- they are implied. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sat Mar 17 03:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSSyh-0003PX-T8; Sat, 17 Mar 2007 03:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSSyg-0003PO-U9 for kitten@lists.ietf.org; Sat, 17 Mar 2007 03:05:22 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSSyf-00084h-No for kitten@lists.ietf.org; Sat, 17 Mar 2007 03:05:22 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa26374; 17 Mar 2007 3:04 EDT Date: Sat, 17 Mar 2007 03:04:39 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: kitten@lists.ietf.org, Nicolas Williams , andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote: > 6. User to User when applied by server policy > > In the case that the client application doesn't know that a service > requires user-to-user authentication, and requests and receives a > conventional KRB_AP_REP, the client will send the KRB_AP_REP > request, and the server will respond with a KRB_ERROR token as > described in RFC1964, with a msg-type of > KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally > pass the TGT in the data field of this error message. In response to > this error, the initiator sets flags and returns a > GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism > described in section 4. While this is a token carrying a KRB_ERROR, it's not an "error token" in the sense that we're talking about. In the context of Olga's and my comments, an "error token" is one which causes the peer to abort context establishment and return an error status to its caller. Such a token should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is expected. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 08:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSuNw-0001hF-Jm; Sun, 18 Mar 2007 08:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSuNv-0001gz-Ft for kitten@lists.ietf.org; Sun, 18 Mar 2007 08:21:15 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSuNr-0001uh-AO for kitten@lists.ietf.org; Sun, 18 Mar 2007 08:21:15 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2ICLABX024580 for ; Sun, 18 Mar 2007 12:21:10 GMT 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 l2ICL9pf000207 for ; Sun, 18 Mar 2007 06:21:10 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2ICKTU6023283; Sun, 18 Mar 2007 07:20:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2ICKRxU023282; Sun, 18 Mar 2007 07:20:27 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 18 Mar 2007 07:20:27 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20070318122026.GJ22445@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , "Liqiang(Larry) Zhu" , Olga Kornievskaia , Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.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: 93238566e09e6e262849b4f805833007 Cc: "Liqiang\(Larry\) Zhu" , kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote: > > > 6. User to User when applied by server policy > > > > In the case that the client application doesn't know that a service > > requires user-to-user authentication, and requests and receives a > > conventional KRB_AP_REP, the client will send the KRB_AP_REP > > request, and the server will respond with a KRB_ERROR token as > > described in RFC1964, with a msg-type of > > KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally > > pass the TGT in the data field of this error message. In response to > > this error, the initiator sets flags and returns a > > GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism > > described in section 4. > > While this is a token carrying a KRB_ERROR, it's not an "error token" in > the sense that we're talking about. In the context of Olga's and my > comments, an "error token" is one which causes the peer to abort context > establishment and return an error status to its caller. Such a token > should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is > expected. The quoted text does not call this an error token. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 19:24:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4jX-0003s4-7X; Sun, 18 Mar 2007 19:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT4jV-0003rH-RC for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:24:13 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT4jT-0006Xr-P4 for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:24:13 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11472; 18 Mar 2007 19:23 EDT Date: Sun, 18 Mar 2007 19:23:50 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams In-Reply-To: <20070318122026.GJ22445@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Liqiang\(Larry\) Zhu" , kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Sun, 18 Mar 2007, Nicolas Williams wrote: > On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > > On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote: > > > > > 6. User to User when applied by server policy > > > > > > In the case that the client application doesn't know that a service > > > requires user-to-user authentication, and requests and receives a > > > conventional KRB_AP_REP, the client will send the KRB_AP_REP > > > request, and the server will respond with a KRB_ERROR token as > > > described in RFC1964, with a msg-type of > > > KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally > > > pass the TGT in the data field of this error message. In response to > > > this error, the initiator sets flags and returns a > > > GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism > > > described in section 4. > > > > While this is a token carrying a KRB_ERROR, it's not an "error token" in > > the sense that we're talking about. In the context of Olga's and my > > comments, an "error token" is one which causes the peer to abort context > > establishment and return an error status to its caller. Such a token > > should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is > > expected. > > The quoted text does not call this an error token. No, it doesn't, but check the current thread. The current PKU2U document indicates that "In all cases, GSS_Accept_security_context returns GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...". Olga's reading and mine is that this in some cases requires returning GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I define it above; that is, one which the initiator is expected to handle by aborting the context establishment (Olga didn't use the phrase "error token", but I did). Larry quoted the text from section 6 of the Kerberos U2U as a counterexample to my argument that when an error token is emitted, it should always come with a real error code, not GSS_S_CONTINUE_NEEDED. But the quoted text is not actually a counterexample, because although the token described containes a KRB-ERROR, it is not an "error token"; it is intended to trigger the U2U mechanism, which will result in another context token. The case described on page 5 of PKU2U-01 describes a token produced when "there was an error while processing the request or the local policy prevented a ticket from being issued." These are situations in which context establishment cannot continue, and the error token is intended to cause GSS_Init_sec_context to return an appropriate failure code. Since no further tokens are expected, the correct result code is something other than GSS_S_CONTINUE_NEEDED. More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly those cases where the peer is expected to send another token, and no others. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 19:43:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT520-00047X-N1; Sun, 18 Mar 2007 19:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT51z-00045Y-OT for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:43:19 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT51w-0000QH-AH for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:43:19 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 18 Mar 2007 16:43:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.25; Sun, 18 Mar 2007 16:43:13 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Sun, 18 Mar 2007 16:43:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2007 16:43:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: AcdptI8U7IB3T71PTW+fKe4ZaC+ALgAAKfqg References: <20070318122026.GJ22445@Sun.COM> From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman , Nicolas Williams X-OriginalArrivalTime: 18 Mar 2007 23:43:13.0780 (UTC) FILETIME=[31BDC340:01C769B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: spkm@ietf.org, Michael.Eisler@netapp.com, kitten@lists.ietf.org, andros@citi.umich.edu Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org The intention of the text in -01 is that if a KRB-ERROR message should be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be returned.=20 Based on the discussion here, the draft should acknowledge cases where there is an error that is not a KDC error per RFC4120, say for example the acceptor runs out of memory. =20 Jeffrey Hutzelman wrote: > More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly > those cases where the peer is expected to send another token, and no > others. Would it be preferable to return a GSS_S_CONTINUE_NEEDED and a KRB_ERROR in cases where the client is not expected to send another token, for example in the case of a policy error? The error message contains useful information for trouble-shooting. =09 I would not recommend returning an error token when the returned status is NOT GSS_S_CONTINUE_NEEDED, in that cases, most apps would simply throw that away. --larry -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Sunday, March 18, 2007 4:24 PM To: Nicolas Williams Cc: Liqiang(Larry) Zhu; Olga Kornievskaia; Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt On Sun, 18 Mar 2007, Nicolas Williams wrote: > On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote: > > On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote: > > > > > 6. User to User when applied by server policy > > > > > > In the case that the client application doesn't know that a service > > > requires user-to-user authentication, and requests and receives a > > > conventional KRB_AP_REP, the client will send the KRB_AP_REP > > > request, and the server will respond with a KRB_ERROR token as > > > described in RFC1964, with a msg-type of > > > KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally > > > pass the TGT in the data field of this error message. In response to > > > this error, the initiator sets flags and returns a > > > GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism > > > described in section 4. > > > > While this is a token carrying a KRB_ERROR, it's not an "error token" in > > the sense that we're talking about. In the context of Olga's and my > > comments, an "error token" is one which causes the peer to abort context > > establishment and return an error status to its caller. Such a token > > should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is > > expected. > > The quoted text does not call this an error token. No, it doesn't, but check the current thread. The current PKU2U document indicates that "In all cases, GSS_Accept_security_context returns GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...". Olga's reading and mine is that this in some cases requires reinturning GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I define it above; that is, one which the initiator is expected to handle by aborting the context establishment (Olga didn't use the phrase "error token", but I did). Larry quoted the text from section 6 of the Kerberos U2U as a counterexample to my argument that when an error token is emitted, it should always come with a real error code, not GSS_S_CONTINUE_NEEDED. But the quoted text is not actually a counterexample, because although the token described containes a KRB-ERROR, it is not an "error token"; it is intended to trigger the U2U mechanism, which will result in another context token. The case described on page 5 of PKU2U-01 describes a token produced when "there was an error while processing the request or the local policy prevented a ticket from being issued." These are situations in which context establishment cannot continue, and the error token is intended to cause GSS_Init_sec_context to return an appropriate failure code. Since no further tokens are expected, the correct result code is something other than GSS_S_CONTINUE_NEEDED. More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly those cases where the peer is expected to send another token, and no others. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 19:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT53H-0005EK-B4; Sun, 18 Mar 2007 19:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT53F-0005DV-KE for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:44:37 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT53E-0000WS-EZ for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:44:37 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11486; 18 Mar 2007 19:44 EDT Date: Sun, 18 Mar 2007 19:44:29 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: kitten@lists.ietf.org, Nicolas Williams , andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > The intention of the text in -01 is that if a KRB-ERROR message should > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > returned. Why? How does the initiator handle these tokens? If it does so in any way other than by producing a new token, then the acceptor should not be returning GSS_S_CONTINUE_NEEDED. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 19:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59B-0006fc-Pq; Sun, 18 Mar 2007 19:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT59A-0006cU-Pn for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:50:44 -0400 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT599-0000rj-Ev for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:50:44 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Sun, 18 Mar 2007 16:50:42 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Sun, 18 Mar 2007 16:50:33 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Sun, 18 Mar 2007 16:50:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Mar 2007 16:50:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-zhu-pku2u-01.txt Thread-Index: Acdpt2b2vPNGIoTkT72djyquVIaH9wAACNow References: From: "Liqiang(Larry) Zhu" To: Jeffrey Hutzelman X-OriginalArrivalTime: 18 Mar 2007 23:50:34.0205 (UTC) FILETIME=[384148D0:01C769B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Nicolas Williams , Michael.Eisler@netapp.com Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Jeffrey Hutzelman wrote: > Why? How does the initiator handle these tokens? If it does so in any > way other than by producing a new token, then the acceptor should not be > returning GSS_S_CONTINUE_NEEDED. The deployment experience shows that if the client (instead of the acceptor or the KDC) can log the error information, the cost of trouble shooting is significantly lower. If the acceptor returns a KRB_ERROR message with a status that is anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in fact very unlikely that the trouble-shooting information can make it to the client side in order to get logged. --larry -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Sunday, March 18, 2007 4:44 PM To: Liqiang(Larry) Zhu Cc: kitten@lists.ietf.org; Nicolas Williams; andros@citi.umich.edu; Michael.Eisler@netapp.com; spkm@ietf.org Subject: RE: Comments on draft-zhu-pku2u-01.txt On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > The intention of the text in -01 is that if a KRB-ERROR message should > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > returned. Why? How does the initiator handle these tokens? If it does so in any way other than by producing a new token, then the acceptor should not be returning GSS_S_CONTINUE_NEEDED. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Sun Mar 18 19:59:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HO-0004xi-Et; Sun, 18 Mar 2007 19:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HN-0004xd-1s for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:59:13 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT5HL-0001nm-Qe for kitten@lists.ietf.org; Sun, 18 Mar 2007 19:59:13 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11507; 18 Mar 2007 19:58 EDT Date: Sun, 18 Mar 2007 19:58:50 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Liqiang(Larry) Zhu" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Nicolas Williams , Michael.Eisler@netapp.com Subject: RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > Jeffrey Hutzelman wrote: > > Why? How does the initiator handle these tokens? If it does so in > any > > way other than by producing a new token, then the acceptor should not > be > > returning GSS_S_CONTINUE_NEEDED. > > The deployment experience shows that if the client (instead of the > acceptor or the KDC) can log the error information, the cost of trouble > shooting is significantly lower. > > If the acceptor returns a KRB_ERROR message with a status that is > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > fact very unlikely that the trouble-shooting information can make it to > the client side in order to get logged. No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a token to send to the peer". It means "another token is expected from the peer". Any token produced by GSS_Accept_sec_context should be sent to the peer regardless of the returned status code. Behaving otherwise violates the abstraction and will break application protocols which expect the GSS-API to behave as specified, regardless of which mechanism is being used. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 11:26:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJkb-0002t1-QX; Mon, 19 Mar 2007 11:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJka-0002sY-4K; Mon, 19 Mar 2007 11:26:20 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJkM-0003lO-Lj; Mon, 19 Mar 2007 11:26:20 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA12622; Mon, 19 Mar 2007 17:25:34 +0200 (MESZ) From: Martin Rex Message-Id: <200703191525.QAA04217@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 16:25:34 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 07:01:09 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-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt 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 Liqiang wrote: > > Jeff wrote: > > This is a good point. GSS_S_CONTINUE_NEEDED indicates that it will be > > necessary to make the call again with another token provided by the peer. > > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, > > it should also return an appropriate error status, not > > GSS_S_CONTINUE_NEEDED. > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. Returning a KRB_ERROR token along with GSS_S_CONTINUE_NEEDED minor_status from gss_accept_sec_context() is defintely *NOT* allowed by rfc-1964. There seems to be text describing a backward incompatible change in rfc-4121 last paragraph of section 4.1, (top of page 5) which allows such misbehaviour for the specific case of an unknown token ID: If an unknown token identifier (TOK_ID) is received in the initial context establishment token, the receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the returned output token MUST contain a KRB_ERROR message with the error code KRB_AP_ERR_MSG_TYPE [RFC4120]. But since the spec is entirely silent about how the client can continue to produce a successful security context establishment from that point on, it is sufficiently incomplete to be unusuable. SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED status from the beginning, in an undocumented/unspecified fashion, non-interoperable with rfc-1964 based Kerberos implementations. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 11:41:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJzQ-0005AY-DI; Mon, 19 Mar 2007 11:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJzP-00059y-77; Mon, 19 Mar 2007 11:41:39 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJz4-0006H4-Tt; Mon, 19 Mar 2007 11:41:39 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA16274; Mon, 19 Mar 2007 17:38:31 +0200 (MESZ) From: Martin Rex Message-Id: <200703191538.QAA04559@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 16:38:04 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 07:01:09 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-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt 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 Liqiang wrote: > > This is not necessary accurate. In the User2User protocol, > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt, > the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status. IIRC, the user2user implementation shipped by Microsoft uses a mechanism OID different from rfc-1964/rfc-4121. Technically, the "context establishment handshake" is opaque to the application. It is conceivable to define a context establishment handshake that negotiates (optional) features in multiple steps, and the names of intermediate tokens are just an implementation detail. However, the spec of a mechanism ought to be sufficiently clear that everyone can implement optional multi-step negotiations reliably in an interoperable fashion. Retrofitting KRB_ERROR + CONTINUE_NEEDED for rfc-1964 and successors should NOT break implementations based on the original specs, which likely do not support this. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 12:13:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKUO-0006Na-Uu; Mon, 19 Mar 2007 12:13:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKUO-0006N4-Fb for kitten@lists.ietf.org; Mon, 19 Mar 2007 12:13:40 -0400 Received: from dhcp-1226.ietf68.org ([130.129.18.38] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKUN-0002Fz-2q for kitten@lists.ietf.org; Mon, 19 Mar 2007 12:13:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EF41BE031C; Mon, 19 Mar 2007 12:13:22 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman References: Date: Mon, 19 Mar 2007 12:13:22 -0400 In-Reply-To: (Jeffrey Hutzelman's message of "Sun, 18 Mar 2007 19:58:50 -0400 (EDT)") 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Liqiang\(Larry\) Zhu" , Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: >> Jeffrey Hutzelman wrote: > Why? How does the initiator handle >> these tokens? If it does so in any > way other than by >> producing a new token, then the acceptor should not be > >> returning GSS_S_CONTINUE_NEEDED. >> >> The deployment experience shows that if the client (instead of >> the acceptor or the KDC) can log the error information, the >> cost of trouble shooting is significantly lower. >> >> If the acceptor returns a KRB_ERROR message with a status that >> is anything but GSS_S_CONTINUE_NEEDED, there is no guarantee >> and it is in fact very unlikely that the trouble-shooting >> information can make it to the client side in order to get >> logged. Jeffrey> No; you are confused. GSS_S_CONTINUE_NEEDED does not Jeffrey> mean "there is a token to send to the peer". It means Jeffrey> "another token is expected from the peer". Any token Jeffrey> produced by GSS_Accept_sec_context should be sent to the Jeffrey> peer regardless of the returned status code. Jeffrey> Behaving otherwise violates the abstraction and will Jeffrey> break application protocols which expect the GSS-API to Jeffrey> behave as specified, regardless of which mechanism is Jeffrey> being used. I strongly agree with Jeff here. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 12:24:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKeR-0000Vz-9V; Mon, 19 Mar 2007 12:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKeP-0000VO-V9; Mon, 19 Mar 2007 12:24:01 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKeJ-0004Vy-Gq; Mon, 19 Mar 2007 12:24:01 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA12805; Mon, 19 Mar 2007 18:23:43 +0200 (MESZ) From: Martin Rex Message-Id: <200703191623.RAA05635@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 17:23:26 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 16, 7 10:37:24 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt 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 Liqiang wrote: > > Nicolas.Williams wrote: > > Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR?? Normally > > status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism > > token -- they are implied. > > See section 6 of the user2user ID > http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt > > > 6. User to User when applied by server policy > > In the case that the client application doesn't know that a service > requires user-to-user authentication, and requests and receives a > conventional KRB_AP_REP, the client will send the KRB_AP_REP Is it me or should this read KRB_AP_REQ? > request, and the server will respond with a KRB_ERROR token as > described in RFC1964, with a msg-type of > KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally > pass the TGT in the data field of this error message. In response to > this error, the initiator sets flags and returns a > GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism > described in section 4. This "server policy" confuses me. There are potentially 3 issues with AP_REQ/AP_REP exchanges that I can think of: 1) "weak" server key (i.e. server does not have a strong random key) 2) server lacks (or doesn't want to use) replay cache 3) replay caches are not shared across hosts, so a distributed services using a single principal (a single key) instead of the original hostbased services of the original Kerberos 5 design become vulnerable to cross-host replay Protection for (1) would require the KDC to not even issue service tickets, so that the client can not even send a KRB_AP_REQ. Having a Application send a KRB_ERROR upon receiving an rfc-1964 AP_REQ will result in fatal termination of the security context establishment for every conforming implementation of rfc-1964. So this suggestion seems to create an interoperability problem, and the CONTINUE_NEEDED status is an inappropriate return status for gss_accept_sec_context() for a mechanism using the rfc-1964 mechanism OID. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 12:29:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKjh-0002gd-Dc; Mon, 19 Mar 2007 12:29:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKjg-0002gN-C3; Mon, 19 Mar 2007 12:29:28 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKje-0005el-Tg; Mon, 19 Mar 2007 12:29:28 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA00156; Mon, 19 Mar 2007 18:29:18 +0200 (MESZ) From: Martin Rex Message-Id: <200703191629.RAA05702@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 19 Mar 2007 17:29:08 +0100 (MET) In-Reply-To: from "Jeffrey Hutzelman" at Mar 18, 7 07:58:50 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: lzhu@windows.microsoft.com, kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt 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: > > On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > > Jeffrey Hutzelman wrote: > > > Why? How does the initiator handle these tokens? If it does so in any > > > way other than by producing a new token, then the acceptor should not be > > > returning GSS_S_CONTINUE_NEEDED. > > > > The deployment experience shows that if the client (instead of the > > acceptor or the KDC) can log the error information, the cost of trouble > > shooting is significantly lower. > > > > If the acceptor returns a KRB_ERROR message with a status that is > > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > > fact very unlikely that the trouble-shooting information can make it to > > the client side in order to get logged. > > No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a > token to send to the peer". It means "another token is expected from the > peer". Any token produced by GSS_Accept_sec_context should be sent to the > peer regardless of the returned status code. Actually, that is not completely accurate. An application that obtains a context token along with a fatal routine error from one of the context establishment calls (gss_accept_sec_context or gss_init_sec_context) is *NOT* required to send this to the peer. It may do so, but it may also shutdown the communication channel. I expect that a lot of applications will not actually send such a token (ours doesn't). > > Behaving otherwise violates the abstraction and will break application > protocols which expect the GSS-API to behave as specified, regardless of > which mechanism is being used. Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* define a clear method how to continue the context establishment handshake to successful completion is broken on my scorecard. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 13:11:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOb-0002IC-6N; Mon, 19 Mar 2007 13:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOZ-0002Gh-1o; Mon, 19 Mar 2007 13:11:43 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLO6-0004hP-4U; Mon, 19 Mar 2007 13:11:43 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09477; Mon, 19 Mar 2007 19:11:05 +0200 (MESZ) From: Martin Rex Message-Id: <200703191710.SAA06804@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Mon, 19 Mar 2007 18:10:54 +0100 (MET) In-Reply-To: from "Jeffrey Hutzelman" at Mar 18, 7 07:23:50 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: de4f315c9369b71d7dd5909b42224370 Cc: lzhu@windows.microsoft.com, kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt 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: > > More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly > those cases where the peer is expected to send another token, and no > others. I fully agree. Engineering-wise it is a pretty bad idea to cause (server) applications to keep unnecessary state around (a proto security context that will never get established) and remain tied up in the security context establishment loop of the GSS-API security context establishment exchange unless there is a real possibility that the handshake on this security context will be continued and lead to a successful completion. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 13:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLix-0005RC-Pu; Mon, 19 Mar 2007 13:32:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLix-0005Qo-0M; Mon, 19 Mar 2007 13:32:47 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLiS-0000B1-9f; Mon, 19 Mar 2007 13:32:46 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id TAA16256; Mon, 19 Mar 2007 19:31:57 +0200 (MESZ) From: Martin Rex Message-Id: <200703191731.SAA07246@uw1048.wdf.sap.corp> To: lzhu@windows.microsoft.com (Liqiang) Date: Mon, 19 Mar 2007 18:31:51 +0100 (MET) In-Reply-To: from "Liqiang" at Mar 18, 7 04:50:30 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: b280b4db656c3ca28dd62e5e0b03daa8 Cc: andros@citi.umich.edu, Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, jhutz@cmu.edu Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt 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 Liqiang wrote: > > Jeffrey Hutzelman wrote: > > Why? How does the initiator handle these tokens? If it does so in any > > way other than by producing a new token, then the acceptor should not be > > returning GSS_S_CONTINUE_NEEDED. > > The deployment experience shows that if the client (instead of the > acceptor or the KDC) can log the error information, the cost of trouble > shooting is significantly lower. I do not agree. (OT: You might want to convince the MSIE/schannel maintainers, currently you need a debugger to figure our the SSL alert received by MSIE, MSIE itself presents just a useless "it may everything including sunspots" error messages, and its been doing this for 10 years). > > If the acceptor returns a KRB_ERROR message with a status that is > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in > fact very unlikely that the trouble-shooting information can make it to > the client side in order to get logged. IMHO, that is more of an application problem than a Kerberos problem. With your approach, the error and all details will completely hidden from the Server and Server admins. I consider it a real problem when the error is NOT locally reported where it occurs. Whether and how much a client can do for trouble-shooting may be application specific! When helpdesk is called, the only information that is reliably available/accessible is that logged centrally on backends/servers. E.g. when my application notices a "wrong target name in request" type of error, it aborts the security context establishment and returns an error message at the "application level" conveying this error along with the name that the server uses for acquiring his own credentials. (since some gssapi mechanisms are poor at determining this error, my application framing protocol sends the target name along with the initial context establishment token and when gss_accept_sec_context() fails with an error it compares the accompanying target name with its own server name in order to decide whether it sends a "wrong target name" application level error message back to the client. -Martin > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Sunday, March 18, 2007 4:44 PM > To: Liqiang(Larry) Zhu > Cc: kitten@lists.ietf.org; Nicolas Williams; andros@citi.umich.edu; > Michael.Eisler@netapp.com; spkm@ietf.org > Subject: RE: Comments on draft-zhu-pku2u-01.txt > > On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: > > > The intention of the text in -01 is that if a KRB-ERROR message should > > be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be > > returned. > > > Why? How does the initiator handle these tokens? If it does so in any > way other than by producing a new token, then the acceptor should not be > returning GSS_S_CONTINUE_NEEDED. > > > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > SPKM mailing list > SPKM@ietf.org > https://www1.ietf.org/mailman/listinfo/spkm > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 14:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMVR-0004rQ-PC; Mon, 19 Mar 2007 14:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMVQ-0004py-87 for kitten@lists.ietf.org; Mon, 19 Mar 2007 14:22:52 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMUv-0007sR-OX for kitten@lists.ietf.org; Mon, 19 Mar 2007 14:22:52 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id DD8DF396AE; Mon, 19 Mar 2007 14:22:20 -0400 (EDT) Message-ID: <45FED4DC.103@citi.umich.edu> Date: Mon, 19 Mar 2007 14:22:20 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: <45FB0398.3080406@citi.umich.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org, Nicolas Williams Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Liqiang(Larry) Zhu wrote: > This is designed for fast session resumption. When the initiator already > obtained a service ticket in prior sessions, it can just use that cached > ticket right away. > Ok. However, I think that it makes more sense to explain the initial step first (ie., when no security context has been established between the parties), then explain the case of reusing previously acquired credentials. >> Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike KDC and principal, acceptor and initiator don't share any secrets. PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of the ticket created by the acceptor. > RFC4556 updates RFC4120, unless there is something here specific to > RFC4556, I do not see the need here. > The doc states that: The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according to Section 3.2.1 of [RFC4556]. I might be wrong but I believe that the reply message contains PA_PK_AS_REP pre-auth data as pre Section 3.2.2 of rfc4556. If not, ignore my comment. Otherwise, I think clarifying that the reply is not simply AS_REP is important. >> This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names. >> > How was this deduced? What is a Kerberos domain? And it should not be > needed. what environments are not supported? Can you expand on this? Naming of PKU2U participants is defined in terms on Kerberos name forms. Like SPKM3, PKU2U does not assume that the initiator knows the acceptor's certificate (at least there is nothing in the spec that says otherwise). Thus, the initiator needs to create/invent a name for the acceptor and include it in the AS_REQ. The document assume that the name would be in a Kerberos form. At this point, the likelihood that the initiator can create a correct KRB_NT_500_PRINCIPAL name that would eventually be matched to the DN in the acceptor's certificate is low. Thus, the other option is to create a typical Kerberos name "principal_name/instance@realm". The set of "principal_name/instance" names in a given "realm" constitutes a Kerberos domain. Such names must have been established and existed prior the initiator and acceptor's communication. Now that I think about it, I have a question as to how would identification verification work when the certificate say don't have a SAN with principal_name in them? How would you match the "name/instance@realm" name to a DN? >> Name type NT-X500-PRINCIPAL which is rfc2253 string representation of >> the distinguished name does not produce a canonical name. > PKU2U requires little endian order: > > The Distinguished Name contained in the > PKU2U Kerberos principal name MUST begin with the most specific > attribute and continue with progressively broader attrbiutes. > > With this constraint, is there a case where this does not produce a > canonical name? > One example is multi-valued RDNs. I might be wrong but wasn't there a problem (in practice) of having different "string" names for RDN OIDs (or different implementations not knowing a mapping from an oid to a string name of an RDN, thus leading to different string representations). >> Naming needs work. Comments made about naming in SPKM3 apply here. > Can you point me to the comments, it would help. I just realized that the discussion I was referring to occurred prior to the creation of the spkm mailing list. Thus, it was a private discussion that included comments from Nico Williams and Martin Rex. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 16:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOB0-0003Y7-HO; Mon, 19 Mar 2007 16:09:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOAz-0003Tq-Ga for kitten@lists.ietf.org; Mon, 19 Mar 2007 16:09:53 -0400 Received: from citi.umich.edu ([141.211.133.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTOAx-0008LI-2Y for kitten@lists.ietf.org; Mon, 19 Mar 2007 16:09:53 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 5C44239707; Mon, 19 Mar 2007 16:09:50 -0400 (EDT) Message-ID: <45FEEE0D.1010602@citi.umich.edu> Date: Mon, 19 Mar 2007 16:09:49 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: martin.rex@sap.com References: <200703191629.RAA05702@uw1048.wdf.sap.corp> In-Reply-To: <200703191629.RAA05702@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Michael.Eisler@netapp.com, Jeffrey Hutzelman Subject: Re: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Martin Rex wrote: > Jeffrey Hutzelman wrote: > >> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote: >> >>> Jeffrey Hutzelman wrote: >>> >>>> Why? How does the initiator handle these tokens? If it does so in any >>>> way other than by producing a new token, then the acceptor should not be >>>> returning GSS_S_CONTINUE_NEEDED. >>>> >>> The deployment experience shows that if the client (instead of the >>> acceptor or the KDC) can log the error information, the cost of trouble >>> shooting is significantly lower. >>> >>> If the acceptor returns a KRB_ERROR message with a status that is >>> anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in >>> fact very unlikely that the trouble-shooting information can make it to >>> the client side in order to get logged. >>> >> No; you are confused. GSS_S_CONTINUE_NEEDED does not mean "there is a >> token to send to the peer". It means "another token is expected from the >> peer". Any token produced by GSS_Accept_sec_context should be sent to the >> peer regardless of the returned status code. >> > > Actually, that is not completely accurate. > > An application that obtains a context token along with a fatal routine > error from one of the context establishment calls (gss_accept_sec_context > or gss_init_sec_context) is *NOT* required to send this to the peer. > It may do so, but it may also shutdown the communication channel. > I expect that a lot of applications will not actually send such a token > (ours doesn't). > I agree with Jeff that GSS_S_CONTINUE implies another token is coming. I also agree with Martin and disagree with Jeff on the issue of handling an output token when gss_accept_sec_context() fails. What I would like to highlight is the fact that the current draft requires serious clarifications when it comes to handling error cases! GSS API guarantees that an output will be sent if the GSS_S_CONTINUE is returned. Thus if you want to convey error details (KRB-ERROR) to your peer, then you should return GSS_S_CONTINUE. However this brings me back to my original point that the server is left hanging (ie, keeping state). As others pointed out, using up resources on the server is not desirable. As I was looking at error tokens in GSS API in general (and also related to SPKM3), I was scratching my head trying to figure out how can one make use of error tokens as in any GSS mechanism they seem to present the problem we are discussing right now. I came to the conclusion that error tokens can't be used and we just have to do with error status codes. Therefore, I think this spec should be changed to say that on failure an error code should be returned instead of the GSS_S_CONTINUE. I'm not sure whether or not saying the following is beneficial: that KRB-ERROR token could be returned as well but it is up to the GSS application to decide whether such output token is sent to the peer. >> Behaving otherwise violates the abstraction and will break application >> protocols which expect the GSS-API to behave as specified, regardless of >> which mechanism is being used. >> > Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* > define a clear method how to continue the context establishment > handshake to successful completion is broken on my scorecard. > Agreed! _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 16:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOjT-0007eC-OZ; Mon, 19 Mar 2007 16:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOjS-0007X0-Bn for kitten@lists.ietf.org; Mon, 19 Mar 2007 16:45:30 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTOjR-00052T-03 for kitten@lists.ietf.org; Mon, 19 Mar 2007 16:45:30 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 694A33958F; Mon, 19 Mar 2007 16:45:28 -0400 (EDT) Message-ID: <45FEF668.3060209@citi.umich.edu> Date: Mon, 19 Mar 2007 16:45:28 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Michael.Eisler@netapp.com, andros@citi.umich.edu, kitten@lists.ietf.org, spkm@ietf.org, Nicolas Williams Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org If we had GSS TSL (or SPKM3), a security context can be established between an anonymous client and a server with a certificate. If that possible with PKU2U? Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 17:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP8g-00062j-TT; Mon, 19 Mar 2007 17:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP8f-00061T-Eo for kitten@lists.ietf.org; Mon, 19 Mar 2007 17:11:33 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTP8W-0000i7-2M for kitten@lists.ietf.org; Mon, 19 Mar 2007 17:11:33 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 19 Mar 2007 14:11:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Mon, 19 Mar 2007 14:11:23 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3953); Mon, 19 Mar 2007 14:11:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2007 14:10:59 -0700 Message-ID: In-Reply-To: <45FEF668.3060209@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D ACTION:draft-zhu-pku2u-01.txt Thread-Index: AcdqZ5V+lzLZWAgATOqcRQcwAgdEAAAA1gOw References: <45FEF668.3060209@citi.umich.edu> From: "Liqiang(Larry) Zhu" To: Olga Kornievskaia X-OriginalArrivalTime: 19 Mar 2007 21:11:22.0964 (UTC) FILETIME=[25AF5140:01C76A6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Michael.Eisler@netapp.com, Nicolas Williams , kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu Subject: RE: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Yes, this is a supported mode, the client/initiator is anonymous and the acceptor has a certificate. -----Original Message----- From: Olga Kornievskaia [mailto:aglo@citi.umich.edu]=20 Sent: Monday, March 19, 2007 1:45 PM To: Liqiang(Larry) Zhu Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt If we had GSS TSL (or SPKM3), a security context can be established=20 between an anonymous client and a server with a certificate. If that=20 possible with PKU2U? Liqiang(Larry) Zhu wrote: > Here is the updated PKU2U. Please review it and see if it has addressed > all concerns. > > Thanks, > > --Larry > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, February 27, 2007 3:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-zhu-pku2u-01.txt=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Public Key Cryptography Based User-to-User > Authentication - (PKU2U) > Author(s) : L. Zhu, et al. > Filename : draft-zhu-pku2u-01.txt > Pages : 10 > Date : 2007-2-27 > =09 > This document defines the public key cryptography based user-to-user > authentication protocol - PKU2U. This mechanism provides security > services in peer to peer networking environments without requiring a > trusted third party. Furthermore, the binding of PKU2U for the > Generic Security Service Application Program Interface (GSS-API) per > RFC2743 is defined based on RFC4121. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-zhu-pku2u-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zhu-pku2u-01.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > =20 > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > =20 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 19 18:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQ8U-0002po-LC; Mon, 19 Mar 2007 18:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQ8T-0002pd-Fw for kitten@lists.ietf.org; Mon, 19 Mar 2007 18:15:25 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTQ8S-000266-30 for kitten@lists.ietf.org; Mon, 19 Mar 2007 18:15:25 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 76E8C39574; Mon, 19 Mar 2007 18:15:23 -0400 (EDT) Message-ID: <45FF0B7B.6010703@citi.umich.edu> Date: Mon, 19 Mar 2007 18:15:23 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.10 (X11/20070301) MIME-Version: 1.0 To: "Liqiang(Larry) Zhu" References: <45FEF668.3060209@citi.umich.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Michael.Eisler@netapp.com, Nicolas Williams , kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Do you plan to extend the current document and include the details of this case? Liqiang(Larry) Zhu wrote: > Yes, this is a supported mode, the client/initiator is anonymous and the > acceptor has a certificate. > > -----Original Message----- > From: Olga Kornievskaia [mailto:aglo@citi.umich.edu] > Sent: Monday, March 19, 2007 1:45 PM > To: Liqiang(Larry) Zhu > Cc: Michael.Eisler@netapp.com; andros@citi.umich.edu; > kitten@lists.ietf.org; spkm@ietf.org; Nicolas Williams > Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt > > > If we had GSS TSL (or SPKM3), a security context can be established > between an anonymous client and a server with a certificate. If that > possible with PKU2U? > > Liqiang(Larry) Zhu wrote: > >> Here is the updated PKU2U. Please review it and see if it has >> > addressed > >> all concerns. >> >> Thanks, >> >> --Larry >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Tuesday, February 27, 2007 3:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-zhu-pku2u-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Public Key Cryptography Based User-to-User >> Authentication - (PKU2U) >> Author(s) : L. Zhu, et al. >> Filename : draft-zhu-pku2u-01.txt >> Pages : 10 >> Date : 2007-2-27 >> >> This document defines the public key cryptography based user-to-user >> authentication protocol - PKU2U. This mechanism provides security >> services in peer to peer networking environments without requiring >> > a > >> trusted third party. Furthermore, the binding of PKU2U for the >> Generic Security Service Application Program Interface (GSS-API) >> > per > >> RFC2743 is defined based on RFC4121. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> > > >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> > > >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-zhu-pku2u-01.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-zhu-pku2u-01.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Mar 20 07:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcaN-0008QV-Gx; Tue, 20 Mar 2007 07:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcaN-0008QM-4y for kitten@lists.ietf.org; Tue, 20 Mar 2007 07:33:03 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTcaI-0007Ro-7V for kitten@lists.ietf.org; Tue, 20 Mar 2007 07:33:03 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa16160; 20 Mar 2007 7:32 EDT Date: Tue, 20 Mar 2007 07:32:39 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Martin Rex In-Reply-To: <200703191629.RAA05702@uw1048.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: lzhu@windows.microsoft.com, kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 19 Mar 2007, Martin Rex wrote: > An application that obtains a context token along with a fatal routine > error from one of the context establishment calls (gss_accept_sec_context > or gss_init_sec_context) is *NOT* required to send this to the peer. > It may do so, but it may also shutdown the communication channel. > I expect that a lot of applications will not actually send such a token > (ours doesn't). Well, that depends on the specification of the application - some application protocols are as you describe, and some dictate one choice or the other. But the key point here is that CONTINUE_NEEDED means that a token is expected from the peer, and should not be returned otherwise. > Returning CONTINUE_NEEDED status when the mechanism spec does *NOT* > define a clear method how to continue the context establishment > handshake to successful completion is broken on my scorecard. Agree. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Tue Mar 20 07:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcfZ-0003Ox-Lk; Tue, 20 Mar 2007 07:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcfY-0003Op-5Q for kitten@lists.ietf.org; Tue, 20 Mar 2007 07:38:24 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTcfW-0000mm-VI for kitten@lists.ietf.org; Tue, 20 Mar 2007 07:38:24 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa16164; 20 Mar 2007 7:37 EDT Date: Tue, 20 Mar 2007 07:37:57 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Martin Rex In-Reply-To: <200703191731.SAA07246@uw1048.wdf.sap.corp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Liqiang , Michael.Eisler@netapp.com, kitten@lists.ietf.org, spkm@ietf.org, andros@citi.umich.edu Subject: Re: [SPKM] RE: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 19 Mar 2007, Martin Rex wrote: > Whether and how much a client can do for trouble-shooting may > be application specific! When helpdesk is called, the only > information that is reliably available/accessible is that > logged centrally on backends/servers. That is true only if the helpdesk is associated with the people operating the servers, rather than the people supporting the user. OFten these are not the same organization, and the only information available is that recorded on the client. If one of my users reports a problem talking to some remote site, I can, if necessary, examine error logs, attach a debugger to their client, and/or observe the traffic on the wire. Actually getting error data from the server can be essential to making this work. That said, applications should be designed to correctly carry error tokens without requiring that they be returned with GSS_S_CONTINUE_NEEDED, because no mechanism should be doing that. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 26 14:19:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtlq-00011l-HE; Mon, 26 Mar 2007 14:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtlp-00011b-8y; Mon, 26 Mar 2007 14:18:17 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVtlo-0003z0-0H; Mon, 26 Mar 2007 14:18:17 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l2QIICxk009150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2007 14:18:13 -0400 (EDT) Date: Mon, 26 Mar 2007 14:18:12 -0400 From: Jeffrey Hutzelman To: martin.rex@sap.com, Liqiang Message-ID: <40487DBDE3B881E9262059DA@sirius.fac.cs.cmu.edu> In-Reply-To: <200703191525.QAA04217@uw1048.wdf.sap.corp> References: <200703191525.QAA04217@uw1048.wdf.sap.corp> Originator-Info: login-token=Mulberry:01xXZc7C/e0WARwdRt+PSMW1zokxdMqtUy64pR+/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: 52e1467c2184c31006318542db5614d5 Cc: kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, Jeffrey Hutzelman Subject: Re: Comments on draft-zhu-pku2u-01.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Monday, March 19, 2007 04:25:34 PM +0100 Martin Rex wrote: > There seems to be text describing a backward incompatible change in > rfc-4121 last paragraph of section 4.1, (top of page 5) which > allows such misbehaviour for the specific case of an unknown token ID: > > If an unknown token identifier (TOK_ID) is received in the initial > context establishment token, the receiver MUST return > GSS_S_CONTINUE_NEEDED major status, and the returned output token > MUST contain a KRB_ERROR message with the error code > KRB_AP_ERR_MSG_TYPE [RFC4120]. That looks to me like an error in RFC4121. Clearly the status in this case should not be GSS_S_CONTINUE_NEEDED. > SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED > status from the beginning, in an undocumented/unspecified fashion, > non-interoperable with rfc-1964 based Kerberos implementations. Oh, it interoperates, because initiators respond to the KRB-ERROR by returning an error, so the application gives up and never sends a token back. The problem is that returning GSS_S_CONTINUE_NEEDED in this case is likely to confuse a GSS-API application on the acceptor side, because it expects to receive another token from the client. OTOH, since you're describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API construct, this situation is perfectly fine -- SSPI can establish different (even broken) semantics for its applications, and an API translation module such as the one you maintain will have to deal. I'd assume you would do this by "knowing" when the mechanism is Kerberos, peeking inside the token, and turning GSS_S_CONTINUE_NEEDED into something else if the token is a KRB-ERROR token. Ugly, but perhaps necessary. -- Jeff _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Mar 26 18:45:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVxvW-0006ro-98; Mon, 26 Mar 2007 18:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVxvU-0006rE-BR; Mon, 26 Mar 2007 18:44:32 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVxvS-0004QA-Tr; Mon, 26 Mar 2007 18:44:32 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA12475; Tue, 27 Mar 2007 00:44:25 +0200 (MESZ) From: Martin Rex Message-Id: <200703262244.AAA15435@uw1048.wdf.sap.corp> To: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Tue, 27 Mar 2007 00:44:24 +0200 (MET DST) In-Reply-To: <40487DBDE3B881E9262059DA@sirius.fac.cs.cmu.edu> from "Jeffrey Hutzelman" at Mar 26, 7 02:18: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-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: lzhu@windows.microsoft.com, kitten@lists.ietf.org, Nicolas.Williams@sun.com, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu Subject: Re: Comments on draft-zhu-pku2u-01.txt 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: > > On Monday, March 19, 2007 04:25:34 PM +0100 Martin Rex > wrote: > > > There seems to be text describing a backward incompatible change in > > rfc-4121 last paragraph of section 4.1, (top of page 5) which > > allows such misbehaviour for the specific case of an unknown token ID: > > > > If an unknown token identifier (TOK_ID) is received in the initial > > context establishment token, the receiver MUST return > > GSS_S_CONTINUE_NEEDED major status, and the returned output token > > MUST contain a KRB_ERROR message with the error code > > KRB_AP_ERR_MSG_TYPE [RFC4120]. > > That looks to me like an error in RFC4121. Clearly the status in this case > should not be GSS_S_CONTINUE_NEEDED. In principle, such an extension would be OK, provided that the spec was sufficiently clear to provide a fallback continuation of the security context handshake. Compliant gss-api mechanisms are not normally sending context tokens with an unknown TOK_ID, so this change should --in theory-- not break existing conforming implementations. I don't remember that such a change was ever discussed, and I consider it significantly underspecified and hidden. > > > SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED > > status from the beginning, in an undocumented/unspecified fashion, > > non-interoperable with rfc-1964 based Kerberos implementations. > > Oh, it interoperates, because initiators respond to the KRB-ERROR by > returning an error, so the application gives up and never sends a token > back. I know that the KRB_ERROR token is part of rfc1964 and understood by rfc1964 peers, but that is not what I meant. The interoperability that I was refering to was not the indication of an error, but the attempt of recovery that Microsoft has built into their Kerberos SSP and for which the CONTINUE_NEEDED is necessary. Microsoft's Kerberos SSP will perform a second attempt to establish the security context on the same security context handle with another token exchange--and on this feature the other Kerberos 5 implementations will likely not interoperate (because it is not standardized anywhere). > The problem is that returning GSS_S_CONTINUE_NEEDED in this case is > likely to confuse a GSS-API application on the acceptor side, because it > expects to receive another token from the client. OTOH, since you're > describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API > construct, this situation is perfectly fine -- SSPI can establish different > (even broken) semantics for its applications, They can and they do use semantics for SSPI that differ from GSS-API, but that makes them non-conforming to rfc-1964/rfc-4121. (they still use the same wire-format, but the GSS-API standard includes API semantics, not just mechanism wire-format. > An API translation module > such as the one you maintain will have to deal. I'd assume you would do > this by "knowing" when the mechanism is Kerberos, peeking inside the token, > and turning GSS_S_CONTINUE_NEEDED into something else if the token is a > KRB-ERROR token. Ugly, but perhaps necessary. Yup, that's what it will have to do. My wrapper is currently limited to rfc-1964 Kerberos, so it aborts on user2user context establishment tokens and aborts with an error when AcceptSecurityContext returns CONTINUE_NEEDED (because rfc-1964 is limited to 1- and 2-token context establishment handshakes). Another interoperability problem with Microsoft Kerberos is the security context lifetime limit required by rfc-1964. When Microsoft tried to activate that in Windows 2000 beta3 hell broke loose because none of their applications could handle expiring security contexts. So they deliberately ignore it. My gssapi wrapper adds this back in, so that you have consistent behaviour within the entire Kerberos5 infrastructure. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 09:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuIw-0008MK-NG; Thu, 29 Mar 2007 09:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuIv-0008JS-Hp for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:04:37 -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 1HWuIt-0007fo-0z for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:04:37 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2TD3grF026133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 15:03:44 +0200 X-Hashcash: 1:22:070329:ietf-sasl@imc.org::7vFqqYsr3nkyklDv:7EC4 X-Hashcash: 1:22:070329:kitten@lists.ietf.org::jwWvCHbUepwFLqlp:0QUx X-Hashcash: 1:22:070329:password-auth@josefsson.org::WGgLHjMUuwNoYFtd:0OeI From: Simon Josefsson To: ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070329:i-d-announce@ietf.org::QZqc46x7gb4eWmVJ:8kC/ X-Hashcash: 1:22:070329:internet-drafts@ietf.org::sM6IcYiDv7TqPCyp:Q+IU Date: Thu, 29 Mar 2007 15:03:42 +0200 In-Reply-To: (Internet-Drafts@ietf.org's message of "Wed\, 28 Mar 2007 15\:50\:02 -0400") Message-ID: <87tzw4p5g1.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_05, 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: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Hi all! The SASL WG discussed new password-based mechanisms, and there were some discussions at the last meeting to do this through a GSS-API mechanism instead. I mentioned on jabber that I had been working on a draft to do that, and while it is far from finished I thought I'd publish it early to gauge interest in the work. My idea is to specify a challenge/response protocol that is (somewhat) agnostic to the framework (GSS-API or SASL) and then specify how that protocol is used in these two frameworks. Since the wire protocol is highly influenced by GSS-API and SASL concepts, the mappings for how to use the protocol in GSS-API or SASL is just one page. The cryptographic primitive is right now HMAC-SHA-256 but the intention is that other MACs, including non-HMAC based approaches such as AES-CMAC (RFC 4493) can be supported easily. To make it easier to implement this as a SASL mechanism, I'm sure the document could say a lot more. I intend to include sample code for DER length encoding (it is only a few lines of C code), which is something some people consider complex. Providing an entire implementation of the GS2-YGZBCUXPNWNVHSI mechanism would be possible to include, I believe there is not a lot of code to do it. This might make it easier for IMAP/SMTP implementers to start using it quickly. The document is available from the IETF servers, see the announcement below. Comments? I'm cc:ing this to the password-auth mailing list that I created for discussion of the document. Some discussions of the document may be off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to see it discussed elsewhere (let me know!), so consider dropping the IETF lists when starting such a thread. To subscribe to the list, and for other resources related to this effort, see: http://josefsson.org/password-auth/ Even if there isn't much uptake from the SASL community on this idea, I believe having a password-based GSS-API mechanism is an important contribution and I'll continue working on that. How much the document talks about SASL will depend on the interest. Through GS2, it will eventually be possible to use it in SASL anyway. /Simon Internet-Drafts@ietf.org writes: > Title : A Password-based Authentication Protocol > Author(s) : S. Josefsson > Filename : draft-josefsson-password-auth-00.txt > Pages : 16 > Date : 2007-3-28 > > There is a lack of a simple, standardized, secure and modern > password-based mechanism for user authentication in application > protocols. This document specify a challenge/response protocol that > provide password-based authentication services. We describe how the > protocol may be used as a GSS-API mechanism and, using the GS2 > framework, how it may be used as a SASL mechanism. The protocol > supports HMAC-SHA-256 as the mandatory to implement algorithm, and it > supports channel bindings. The intended use is by application > protocol that today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS- > API applications that needs a password based method. The protocol is > applicable to other environments, such as EAP, should the need arise. > > See for more information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 09:18:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuW4-0001z8-HT; Thu, 29 Mar 2007 09:18:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuW4-0001z3-7e for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:18:12 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWuW0-0001uD-SJ for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:18:12 -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 l2TDI8Jo011820 for ; Thu, 29 Mar 2007 13:18:08 GMT 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 l2TDI77c012335 for ; Thu, 29 Mar 2007 07:18:08 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TDHLU8008077; Thu, 29 Mar 2007 08:17:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TDHGxt008076; Thu, 29 Mar 2007 08:17:16 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 08:17:16 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20070329131715.GJ1666@Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org References: <87tzw4p5g1.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tzw4p5g1.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote: > My idea is to specify a challenge/response protocol that is (somewhat) > agnostic to the framework (GSS-API or SASL) and then specify how that > protocol is used in these two frameworks. Since the wire protocol is > highly influenced by GSS-API and SASL concepts, the mappings for how > to use the protocol in GSS-API or SASL is just one page. The I guess it can be one page, since for GSS challenge/response password- based mechs there won't be many name types available, thus not much discussion of naming. Right? Maybe not: presumably acceptor names are used to salt the password, in which case any name type goes and the mech has to specify the relevant mappings from generic name syntax to whatever the mech uses internally. And there's the exported name token format to consider also. But in any case, it needn't be much text, and I've volunteered to write that text. [...] > Comments? > > I'm cc:ing this to the password-auth mailing list that I created for > discussion of the document. Some discussions of the document may be > off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to > see it discussed elsewhere (let me know!), so consider dropping the > IETF lists when starting such a thread. To subscribe to the list, and > for other resources related to this effort, see: Not another mailing list... :/ :) > http://josefsson.org/password-auth/ > > Even if there isn't much uptake from the SASL community on this idea, > I believe having a password-based GSS-API mechanism is an important > contribution and I'll continue working on that. How much the document > talks about SASL will depend on the interest. Through GS2, it will > eventually be possible to use it in SASL anyway. Agreed. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 09:34:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWulB-0001d8-73; Thu, 29 Mar 2007 09:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWul9-0001ae-TM for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:33:47 -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 1HWul8-0004lE-G2 for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:33:47 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2TDXXcl029730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 15:33:33 +0200 From: Simon Josefsson To: ietf-sasl@imc.org References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070329:ietf-sasl@imc.org::cpVdPGJLqYQwc1Lv:Fwfj X-Hashcash: 1:22:070329:password-auth@josefsson.org::grpvszOK7ar5oe0i:4jvF X-Hashcash: 1:22:070329:kitten@lists.ietf.org::7bs1QaxILKRn5e1x:BBoL Date: Thu, 29 Mar 2007 15:33:33 +0200 In-Reply-To: <20070329131715.GJ1666@Sun.COM> (Nicolas Williams's message of "Thu\, 29 Mar 2007 08\:17\:16 -0500") Message-ID: <87bqicp42a.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.1 required=4.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: password-auth@josefsson.org, kitten@lists.ietf.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nicolas Williams writes: > On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote: >> My idea is to specify a challenge/response protocol that is (somewhat) >> agnostic to the framework (GSS-API or SASL) and then specify how that >> protocol is used in these two frameworks. Since the wire protocol is >> highly influenced by GSS-API and SASL concepts, the mappings for how >> to use the protocol in GSS-API or SASL is just one page. The > > I guess it can be one page, since for GSS challenge/response password- > based mechs there won't be many name types available, thus not much > discussion of naming. Right? Maybe not: presumably acceptor names are > used to salt the password, in which case any name type goes and the mech > has to specify the relevant mappings from generic name syntax to > whatever the mech uses internally. And there's the exported name token > format to consider also. I'm not really that familiar with the naming corners of GSS-API... In any case, how to salt the password is an open question. Perhaps the exported name format can be used as the salt value with PKCS#5 PBKDF2? But then you'll need to transfer the PBKDF2 iteration counter, or (worse) fixate it. The iteration counter question is the main reason why I haven't used PBKDF2 yet. That, and I'm not sure PBKDF2 in this protocol actually protects against any valid security threats. > But in any case, it needn't be much text, and I've volunteered to write > that text. Excellent! /Simon _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 09:43:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuur-0008G5-0q; Thu, 29 Mar 2007 09:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuuq-0008G0-Ch for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:43:48 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWuum-00072A-8g for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:43:48 -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 l2TDhhkL020877 for ; Thu, 29 Mar 2007 13:43:43 GMT 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 l2TDhhlu028820 for ; Thu, 29 Mar 2007 07:43:43 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TDgumT008119; Thu, 29 Mar 2007 08:42:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TDgupm008118; Thu, 29 Mar 2007 08:42:56 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 08:42:56 -0500 From: Nicolas Williams To: Simon Josefsson , ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Message-ID: <20070329134256.GN1666@Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070329131715.GJ1666@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: pw-based mech options (Re: draft-josefsson-password-auth-00.txt) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Mar 29, 2007 at 08:17:16AM -0500, Nicolas Williams wrote: > Not another mailing list... :/ :) > > > http://josefsson.org/password-auth/ And moderated to boot. I'd rather we first seek consensus on the SASL list as to whether the WG should take on any new password-based mechanisms, and if so whether to proceed as Sam suggested (spec the mech as a SASL/GS2 mech without reference to the GSS-API and describe its GSS bindings in a separate section/document). Me, I'm all for doing this work in this WG. Of course, there were several options on the table, and we may want to pick one, or maybe two. I volunteered to help with the GSS bits regardless of which options we choose. BTW, about YAP, I get it now: it uses unique channel bindings as a standing for both, server challenge and client nonce. Also, during SAAG EKR suggested to me (via jabber) doing a password- based mechanism as a profile of TLS PSK. Of course, doing password auth in TLS PSK can work and it can even provide a measure of protection against off-line dictionary attacks, but it does not provide for privacy protection of the client identity. If we really want the latter then YAP seems like a good choice for SASL apps running over TLS, else a password-based profile of TLS PSK seems like a better approach. We'd still need a password-based GSS mechanism, but if we push the SASL mechanism to TLS then we effectively wash SASL's hands of a password-based GSS mech. Our options so far: - TLS PSK profile - YAP (which, incidentally, it seems it can't be a GS2 mech, though it can be a SASL mech and it can be a GSS mech) - Traditional challenge/response mechanisms (Simon's, Hexa, etc...) A TLS profile seems un-SASLish, but we (the IETF) could use that too. YAP is neat (one round-trip!), but absolutely depends on an underlying channel with unique channel bindings (else it's replayable). A traditional challenge/response design is needed to have a well rounded SASL/GSS mechanism story. So, my tentative position: - pursue a traditional challenge/response mechanism as a WG item - pursue YAP as a WG item IFF the privacy protection angle is deemed important - pursue a TLS PSK profile as an individual submission or let the TLS WG take it Comments? Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 09:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv99-0000wx-4g; Thu, 29 Mar 2007 09:58:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWv97-0000wU-0I for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:58:33 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWv95-00010N-JB for kitten@lists.ietf.org; Thu, 29 Mar 2007 09:58:32 -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 l2TDwVCt001859 for ; Thu, 29 Mar 2007 13:58:31 GMT 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 l2TDwUVS005179 for ; Thu, 29 Mar 2007 07:58:30 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TDvhSO008132; Thu, 29 Mar 2007 08:57:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TDvhnS008131; Thu, 29 Mar 2007 08:57:43 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 08:57:43 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20070329135743.GO1666@Sun.COM> Mail-Followup-To: Simon Josefsson , ietf-sasl@imc.org, password-auth@josefsson.org, kitten@lists.ietf.org References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> <87bqicp42a.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bqicp42a.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Mar 29, 2007 at 03:33:33PM +0200, Simon Josefsson wrote: > I'm not really that familiar with the naming corners of GSS-API... In You need to specify what name types the mech supports and how to convert from generic name syntaxes (, @) to mechanism- specific syntaxes (which for a password-based mechanism might be the identity function) and what mechanism-specific name types exist, their syntaxes and so on (there wouldn't be any for a password-based mech). And then there's the exported name token format, which for password-based mechs should also be trivial. > any case, how to salt the password is an open question. Perhaps the Well, you'd want to salt it with the server's name, so the verifier is different at each server. Then again, many sites might object. So you might want a two level verifier derivation where the first step is not salted with the server name and the second is -- then one could distribute the output of the first step as the verifier for all servers in a site. > exported name format can be used as the salt value with PKCS#5 PBKDF2? Yes. But there's two names: the client's and the server's. > But then you'll need to transfer the PBKDF2 iteration counter, or > (worse) fixate it. The iteration counter question is the main reason > why I haven't used PBKDF2 yet. That, and I'm not sure PBKDF2 in this > protocol actually protects against any valid security threats. Either negotiate the iteration count or make it part of the mechanism name/OID. Kerberos V uses PBKDF2. I see no reason why we couldn't use it here. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 10:29:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvcW-0003Vm-Pv; Thu, 29 Mar 2007 10:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvcV-0003UT-HY for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:28:55 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvcS-0005CO-4z for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:28:55 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA27354; Thu, 29 Mar 2007 16:28:37 +0200 (MESZ) From: Martin Rex Message-Id: <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 29 Mar 2007 16:28:30 +0200 (MEST) In-Reply-To: <20070329135743.GO1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 08:57:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt 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: > > > any case, how to salt the password is an open question. Perhaps the > > Well, you'd want to salt it with the server's name, so the verifier is > different at each server. Then again, many sites might object. So you > might want a two level verifier derivation where the first step is not > salted with the server name and the second is -- then one could > distribute the output of the first step as the verifier for all servers > in a site. Most challenge-response protocols perform a unidirectional authentication of the client/initiator to the server/acceptor only, and for those the authentication scheme usually does not have a name for the acceptor. I know that the Kerberos gss-api mechanism is "slightly" broken in this respect since it requires a target name for gss_init_sec_context even for unidirectional-only authentication. This requirement is one of the reasons why in many Kerberos scenarios an end-point identification similar to what HTTPoverSSL/TLS does is used instead of a real mutual authentication. One example for a challenge-repsonse authentication with GSS-API style token exchange is Microsoft's NTLM SSP. My GSS-API wrapper for Microsoft's Kerberos SSP also includes a wrapper for Microsoft's NTLM SSP. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 10:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvw5-0001mM-93; Thu, 29 Mar 2007 10:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWvw3-0001mH-MD for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:49:07 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWvw2-0000Ah-8P for kitten@lists.ietf.org; Thu, 29 Mar 2007 10:49:07 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id QAA00554; Thu, 29 Mar 2007 16:48:51 +0200 (MESZ) From: Martin Rex Message-Id: <200703291448.l2TEmonL014308@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 29 Mar 2007 16:48:50 +0200 (MEST) In-Reply-To: <20070329135743.GO1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 08:57:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt 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: > > > any case, how to salt the password is an open question. Perhaps the > > Well, you'd want to salt it with the server's name, so the verifier is > different at each server. Then again, many sites might object. So you > might want a two level verifier derivation where the first step is not > salted with the server name and the second is -- then one could > distribute the output of the first step as the verifier for all servers > in a site. What you seem to be looking/asking for sounds like "channel bindings" rather than name-based mutual authentication of the server (many password-based challenge-response authentication schemes do not provide mutual authentication). Keep in mind that it might be difficult for servers and clients to agree on the same name for the server. Take Microsoft Kerberos as an example: there the server usually doesn't know (and doesn't care) what target name the client is using -- the server will always try to open service tickets by "brute force" using his own secret key. With very few exceptions, service principals don't exist in Microsofts Kerberos, they're mere aliases known to the KDC/Active Directory and may be used by clients/initiators-- A Microsoft server/acceptor normally doesn't know or care what service pricipal aliases exist for his own account and which particular alias was used by a client, it will look at the realm on the service ticket to get the salting right, but entirely ignore the principal name on the ticket. (At least that is what happend with W2K Kerberos when I tested, and it can be verified by setting up two seperate user accounts "b" and "c" with the same password (both enabled for rfc-1964 authentication if W2K3 AD is used). A server started under "b" will then happily establish security contexts with clients that use "b" as the target name as well as clients that use "c" as the target name.) -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 11:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwSE-0001Ii-Ib; Thu, 29 Mar 2007 11:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWwSD-0001Fe-2j for kitten@lists.ietf.org; Thu, 29 Mar 2007 11:22:21 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWwSB-0007D9-9w for kitten@lists.ietf.org; Thu, 29 Mar 2007 11:22:21 -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 l2TFMIW8010542 for ; Thu, 29 Mar 2007 15:22:18 GMT 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 l2TFMI1n010877 for ; Thu, 29 Mar 2007 09:22:18 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TFLUjF008220; Thu, 29 Mar 2007 10:21:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TFLTL5008219; Thu, 29 Mar 2007 10:21:29 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 10:21:29 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070329152128.GQ1666@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329135743.GO1666@Sun.COM> <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > Most challenge-response protocols perform a unidirectional > authentication of the client/initiator to the server/acceptor only, > and for those the authentication scheme usually does not have > a name for the acceptor. Understood. Perhaps then what I should have said is that when mutual authentication is requested then the password should be salted with the acceptor name. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 12:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxC1-0001lo-6G; Thu, 29 Mar 2007 12:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxC0-0001le-4q for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:09:40 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxBy-0007eq-OS for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:09:40 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id SAA16425; Thu, 29 Mar 2007 18:08:54 +0200 (MESZ) From: Martin Rex Message-Id: <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 29 Mar 2007 18:08:33 +0200 (MEST) In-Reply-To: <20070329152128.GQ1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 10:21:29 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: cf4fa59384e76e63313391b70cd0dd25 Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt 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 Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > > Most challenge-response protocols perform a unidirectional > > authentication of the client/initiator to the server/acceptor only, > > and for those the authentication scheme usually does not have > > a name for the acceptor. > > Understood. Perhaps then what I should have said is that when mutual > authentication is requested then the password should be salted with the > acceptor name. At first glance I think it should be OK if some kind of channel bindings are included in (hashed into) the challenge-response exchange. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 12:17:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxJy-00051K-7n; Thu, 29 Mar 2007 12:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxJw-00050m-O2 for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:17:52 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxJv-0000Ej-8S for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:17:52 -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 l2TGHo1u029570 for ; Thu, 29 Mar 2007 16:17:50 GMT 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 l2TGHnVD016521 for ; Thu, 29 Mar 2007 10:17:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TGH2UF008309; Thu, 29 Mar 2007 11:17:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TGH1pp008308; Thu, 29 Mar 2007 11:17:02 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 11:17:01 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070329161701.GA8252@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Thu, Mar 29, 2007 at 06:08:33PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > > > Most challenge-response protocols perform a unidirectional > > > authentication of the client/initiator to the server/acceptor only, > > > and for those the authentication scheme usually does not have > > > a name for the acceptor. > > > > Understood. Perhaps then what I should have said is that when mutual > > authentication is requested then the password should be salted with the > > acceptor name. > > At first glance I think it should be OK if some kind of channel bindings > are included in (hashed into) the challenge-response exchange. Certainly, provided any are available. Last week Kurt proposed a mechanism that requires channel bindings, and called it YAP (yet another ...). It works in just one round-trip (in addition to however many the secure channel required to establish) because the channel binding acts as the server challenge (provided the channel binding is unique in time, else there's a replay attack). Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 12:29:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxVH-0000nb-Kn; Thu, 29 Mar 2007 12:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWxVG-0000nT-Jd for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:29:34 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWxVE-0002BO-6y for kitten@lists.ietf.org; Thu, 29 Mar 2007 12:29:34 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2TGTTZt016330 for ; Thu, 29 Mar 2007 16:29:31 GMT 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 l2TGTSrZ024350 for ; Thu, 29 Mar 2007 10:29:29 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TGSfKQ008318; Thu, 29 Mar 2007 11:28:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TGSe3o008317; Thu, 29 Mar 2007 11:28:40 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 11:28:40 -0500 From: Nicolas Williams To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org Message-ID: <20070329162839.GB8252@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> <20070329161701.GA8252@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070329161701.GA8252@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org A very general password-based challenge-response mechanism that provides optional channel binding and optional mutual authentication in one, one and a half and two round-trips should be feasible: - w/ unique channel bindings -> 1 rt - w/o unique channel bindings + uni-dir authen -> 1 and 1/2 rt - w/o unique channel bindings + mutual auth -> 2 rt Mutual authentication would work the acceptor name into the PBKDF inputs. Uni-directional authentication would not work the acceptor name into the PBKDF (only if no acceptor name was given? or always). I.e., we could merge YAP and the other proposals into one generic mechanism. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 17:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1yd-0004Qe-P7; Thu, 29 Mar 2007 17:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX1yc-0004QN-8v for kitten@lists.ietf.org; Thu, 29 Mar 2007 17:16:10 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX1yW-0004TN-UQ for kitten@lists.ietf.org; Thu, 29 Mar 2007 17:16:10 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2TLG4mR028046 for ; Thu, 29 Mar 2007 21:16:04 GMT 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 l2TLG3ub009601 for ; Thu, 29 Mar 2007 15:16:04 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TLFF5G008519; Thu, 29 Mar 2007 16:15:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TLFEwC008518; Thu, 29 Mar 2007 16:15:14 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 16:15:14 -0500 From: Nicolas Williams To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org Message-ID: <20070329211513.GJ8252@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> <20070329161701.GA8252@Sun.COM> <20070329162839.GB8252@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070329162839.GB8252@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org > I.e., we could merge YAP and the other proposals into one generic > mechanism. Very, very roughly, primarily to illustrate the context token exchanges: IDi = initiator name IDt = target acceptor name IDa = acceptor name (like IDt, but asserted by the acceptor) S = salt derived from IDt or IDa K = PBKDF2(password || S, iteration) R1 = response_function(K, [challenge] || channel bindings || [cnonce]) R2 = response_function2(K, R1) 1/2 rt ( channel bindings and no mutual auth) I -> A: IDi, [IDt,] R1 1 rt ( channel bindings and mutual auth) I -> A: IDi, IDt, R1 A -> I: R2 1 1/2 rt (no channel bindings and no mutual auth) I -> A: IDi, [IDt] A -> I: IDa, challenge I -> A: nonce, R1 2 rt (no channel bindings and mutual auth) I -> A: IDi A -> I: IDa, challenge I -> A: nonce, R1 A -> I: R2 A target name is needed so the acceptor's verifier can be a weak password equivalent (meaning it's a password equivalent only for authenticating to the same acceptor). Therefore it's useful to have a target name even when mutual auth is not requested. A target name is required for mutual auth, of course. The 1 1/2 rt version could add DH key agreement for PFS. And the 2 rt version could add DH key agreement for PFS and some privacy protection of IDi. That is probably not worthwhile for any SASL application, since they tend to have STARTTLS-type options, and for GSS one could always add PFS with stackable mechanisms. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 18:12:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2qp-0003L2-Mb; Thu, 29 Mar 2007 18:12:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2qo-0003Ks-Bi for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:12:10 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2qV-0004py-BC for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:12:10 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA01776; Fri, 30 Mar 2007 00:11:16 +0200 (MESZ) From: Martin Rex Message-Id: <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 30 Mar 2007 00:11:16 +0200 (MEST) In-Reply-To: <20070329211513.GJ8252@Sun.COM> from "Nicolas Williams" at Mar 29, 7 04:15:14 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: 93238566e09e6e262849b4f805833007 Cc: simon@josefsson.org, ietf-sasl@imc.org, Martin.Rex@sap.com, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt 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: > > A target name is needed so the acceptor's verifier can be a weak > password equivalent (meaning it's a password equivalent only for > authenticating to the same acceptor). Therefore it's useful to > have a target name even when mutual auth is not requested. > > A target name is required for mutual auth, of course. To me that seems to be slightly inappropriate terminology. Which particular challenge-response scheme do you have in mind where the server actually performs a mutual authentication, i.e. provides a cryptographic proof of his identity? If the client derives the target name from the network endpoint address (i.e. fqdn-hostname plus service/tcp-port-no) and the server simply "asserts" this name, then this is really a channel binding based on a printable name instead of the low-level network address, but still a channel binding and not an authentication. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 18:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3Gc-0005cH-8W; Thu, 29 Mar 2007 18:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3Ga-0005c5-Km for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:38:48 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3GY-0006Uv-5W for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:38:48 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2TMcjQv017839 for ; Thu, 29 Mar 2007 22:38:45 GMT 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 l2TMci8J020755 for ; Thu, 29 Mar 2007 16:38:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TMbvZ5008635; Thu, 29 Mar 2007 17:37:57 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TMbuHd008634; Thu, 29 Mar 2007 17:37:56 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 17:37:56 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070329223756.GP8252@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329211513.GJ8252@Sun.COM> <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote: > To me that seems to be slightly inappropriate terminology. > > Which particular challenge-response scheme do you have in mind > where the server actually performs a mutual authentication, > i.e. provides a cryptographic proof of his identity? Any where the server stores a secret verifier derived from the password salted with the server's name. If the server sends a response to the client's response that proves it knows the verifier then the client can consider the server to be authenticated to the client. > If the client derives the target name from the network endpoint > address (i.e. fqdn-hostname plus service/tcp-port-no) and > the server simply "asserts" this name, then this is really > a channel binding based on a printable name instead of You're misusing the term "channel binding" here. A server name not associated with some secure channel below the application layer is not a channel binding. > the low-level network address, but still a channel binding and > not an authentication. I really didn't want to talk about server name canonicalization. I wanted to sketch a generic password-based challenge/response mechanism that supports the optional use of channel binding and optional mutual authentication. Yes, I included in my sketch an acceptor-side assertion of its name. This has two purposes that I did not mention. One: when the client doesn't know the server's name the client can simply go ahead and use the asserted server name as the salt -- if the alternative is not to salt the password at all then this is clearly good and not harmful (the client provides material that can be attacked offline regardless of how the password is salted). The other: so the client can output the correct server name to the application which can then prompt the user, or for "fuzzy" server name canonicalization. (I know, you don't have to remind me that the GSS-APIv2u1's GSS_Canonicalize_name() is supposed to be able to canonicalize the given server (or whatever) name securely and out of band w.r.t. security context establishment. But we're talking here too about a mechanism usable outside the context of the GSS-API also, and anyways, that bit of GSS-APIv2u1 semantics is rather cumbersome.) _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 18:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3ST-0004i0-U0; Thu, 29 Mar 2007 18:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3SR-0004hu-V7 for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:51:03 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3SQ-000220-HR for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:51:03 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA20186; Fri, 30 Mar 2007 00:50:43 +0200 (MESZ) From: Martin Rex Message-Id: <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Fri, 30 Mar 2007 00:50:43 +0200 (MEST) In-Reply-To: <20070329223756.GP8252@Sun.COM> from "Nicolas Williams" at Mar 29, 7 05:37:56 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: c1c65599517f9ac32519d043c37c5336 Cc: simon@josefsson.org, ietf-sasl@imc.org, Martin.Rex@sap.com, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt 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, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote: > > To me that seems to be slightly inappropriate terminology. > > > > Which particular challenge-response scheme do you have in mind > > where the server actually performs a mutual authentication, > > i.e. provides a cryptographic proof of his identity? > > Any where the server stores a secret verifier derived from the password > salted with the server's name. If the server sends a response to the > client's response that proves it knows the verifier then the client can > consider the server to be authenticated to the client. Depending on the architecture of the challenge response scheme this may not be easily done. There are legacy systems where the (app)server actually possesses the shared secret and could therefore "prove he knows it". AFAIK, the NTLM authentication on windows differs here. The server doesn't have access to the shared secret, but has a secure channel to a domain controller where he can ask whether a particular combination of challenge and response is acceptable. > > > If the client derives the target name from the network endpoint > > address (i.e. fqdn-hostname plus service/tcp-port-no) and > > the server simply "asserts" this name, then this is really > > a channel binding based on a printable name instead of > > You're misusing the term "channel binding" here. A server name not > associated with some secure channel below the application layer is not a > channel binding. Sorry, but I have to disagree completely. GSS-API has a very "open" concept of channel bindings. You might want to turn your attention to RFC-2744 Section 3.11. which lists all types of channel bindings that "GSS-API v2" knows about. None of what I see there is what I recognize as "secure" channel bindings, but it does have the "GSS_C_AF_INET" type. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Mar 29 19:00:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3b2-0000yK-EC; Thu, 29 Mar 2007 18:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3b0-0000wH-Ey for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:59:54 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX3aw-0005tZ-0b for kitten@lists.ietf.org; Thu, 29 Mar 2007 18:59:54 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l2TMxnrp008328 for ; Thu, 29 Mar 2007 22:59:49 GMT 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 l2TMxmXt017263 for ; Thu, 29 Mar 2007 16:59:49 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l2TMx1nZ008768; Thu, 29 Mar 2007 17:59:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l2TMx0NH008767; Thu, 29 Mar 2007 17:59:00 -0500 (CDT) X-Authentication-Warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Mar 2007 17:59:00 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070329225900.GR8252@Sun.COM> Mail-Followup-To: Martin Rex , simon@josefsson.org, password-auth@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org References: <20070329223756.GP8252@Sun.COM> <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: simon@josefsson.org, ietf-sasl@imc.org, kitten@lists.ietf.org, password-auth@josefsson.org Subject: Re: draft-josefsson-password-auth-00.txt X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Mar 30, 2007 at 12:50:43AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > Any where the server stores a secret verifier derived from the password > > salted with the server's name. If the server sends a response to the > > client's response that proves it knows the verifier then the client can > > consider the server to be authenticated to the client. > > Depending on the architecture of the challenge response scheme > this may not be easily done. > > There are legacy systems where the (app)server actually possesses > the shared secret and could therefore "prove he knows it". Indeed. But that doesn't mean that a generic mechanism in this area must not support salting passwords as I described. > AFAIK, the NTLM authentication on windows differs here. The > server doesn't have access to the shared secret, but has a > secure channel to a domain controller where he can ask whether > a particular combination of challenge and response is acceptable. Yes, proxying should be acceptable. > > You're misusing the term "channel binding" here. A server name not > > associated with some secure channel below the application layer is not a > > channel binding. > > Sorry, but I have to disagree completely. GSS-API has a very > "open" concept of channel bindings. Here we're talking about a mechanism more generic still than a GSS mechanism. Lately when we speak of channel binding we mostly mean it in the "transformed representations of encryption keys) of the underlying communications channel, of protection mechanisms applied to that communications channel," subset of the sense of RFC2743. You may want to comment on draft-williams-on-channel-binding-01.txt; it's in IETF Last Call. > You might want to turn your attention to RFC-2744 Section 3.11. The relevant text is in RFC2743, section 1.1.6, first paragraph. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten