From owner-ietf-sasl Tue Jun 6 08:50:05 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05976 for ietf-sasl-bks; Tue, 6 Jun 2000 08:50:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05972 for ; Tue, 6 Jun 2000 08:50:04 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13425 for ; Tue, 6 Jun 2000 08:58:18 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22630 for ; Tue, 6 Jun 2000 08:58:11 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27374 for ; Tue, 6 Jun 2000 08:56:32 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO37C@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Date: Tue, 06 Jun 2000 08:54:58 -0700 From: Chris Newman Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt To: Magnus Nystrom , ietf-sasl@imc.org Message-id: <1367452.3169270498@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom wrote: > FYI. Comments and feedback is welcome and solicited. I skimmed the document. I'm sorry I don't have time to chase down all the X.509/FIPS references necessary to grok the spec. (1) It seems to have far too many things marked "OPTIONAL". This makes the protocol more complex than necessary. Preferably the only OPTIONAL items should be the differences between one-way and mutual auth. RandomC certainly has no business being optional. (2) I don't understand the value of this if the client cert is optional. Doesn't that mean the server has to store the certs for every possible client in order to guarantee interoperability? Or am I missing something? (3) I presume this factors in the DNS name of the server which the client intends to communicate with -- usually the only information the client has about the server. Where can I read the rules for how that is used? Is that put in the EntityB field? Is the case where multiple physical servers answer for the same domain name considered? Is it possible for each physical server to have a different private key in that case? (4) I don't see a clear statement of how to determine the authorization identity (user to log in as, which may be different from the user whose private key is used). If this is buried somewhere in X.509 specs, please draw attention to it in the spec. (5) The reference to RFC 1738 should be updated to RFC 2396. (6) Is there a fast re-authentication option, or should TLS be used when that's needed? Note that many POP clients make a connection every 5 minutes to check mail, and some IMAP clients make a new connection every time a new folder is opened so a fast re-authentication protocol could be important for scalability. (7) Is there an open-source implementation of RFC 2459? If not, this seems much more complex than TLS where I can just grab OpenSSL and let it do all the work. (8) The IETF has a policy (the "Munich Mandate") which prohibits making patented algorithms mandatory to implement when there's and unpatented equivalent. I consider the recommendation to implement the RSA algorithm inappropriate given that policy. Since this is a set of mechanisms rather than a protocol, the recommendation is not necessary for interoperability so you could simply remove it. Alternatively you could change it to recommend DSA, or wait until after September 20th for standardization. - Chris From owner-ietf-sasl Tue Jun 6 08:49:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05944 for ietf-sasl-bks; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05940 for ; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13253 for ; Tue, 6 Jun 2000 08:58:01 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28012 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27362 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO279@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 21:51:30 -0700 From: Chris Newman Subject: RE: SASL GSSAPI draft In-reply-to: To: "Linn, John" , "'Ken Hornstein'" , jgmyers@netscape.com Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Message-id: <850698.3169230690@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" wrote: > It's certainly true that an SPNEGO token won't be usefully processable by > a target which doesn't support SPNEGO. If, however, a GSS implementation > can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that > GSS implementation is being used with SASL, it may not be too much > incremental effort to make GSS_MECH_A and GSS_MECH_B also available for > negotiation at the SASL level. There's a security vs. interoperability > tradeoff, since the SPNEGO negotiation is protected but the SASL > negotiation isn't. I'd suggest recommending, not discouraging, support > for SPNEGO for use where available and appropriate, but also recommending > configurable support to allow negotiation of individual GSS mechanisms at > the SASL level. Some problems with recommending SPNEGO in SASL: There are standards-compliant email servers deployed which only support Kerberos 5 (GSSAPI SASL) and don't support SPNEGO. Any email server which only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards track) for Kerberos 5 support is hostile both to the installed base of standards-compliant servers and to the deployment of Kerberos 5. If admins encounter an interop problem when trying to upgrade security, the first thing they usually do is back out the security upgrade. We don't want that to happen. I suspect the protection provided by SPNEGO will be irrelevant to most SASL-based protocols in practice because they'll get integrity protection from either TLS or IPsec prior to the SASL negotiation if they want it at all. So it just doesn't seem to be worth the extra round trip(s), IMHO. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if > none of the GSS mechanisms are available. If (1), the client is most > easily served by performing the negotiation (and exposing the individual > GSS mechanisms) at the SASL level. Given the prospect of (2), however, > it'd be good to be able to negotiate among the available GSS mechanisms > in an SPNEGO-protected manner. I'm very uncomfortable with options in security protocols. Every option can double the complexity of a security analysis of the software. I suspect that any benefit gained by making SPNEGO an option will be outweighed by the cost of a security analysis of both codepaths and the interaction between various security polices and SPNEGO/SASL mechanism lists. - Chris From owner-ietf-sasl Tue Jun 6 15:49:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15161 for ietf-sasl-bks; Tue, 6 Jun 2000 15:49:30 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15157 for ; Tue, 6 Jun 2000 15:49:29 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56MnuO13661 for ; Tue, 6 Jun 2000 15:49:56 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVR93C00.HR0; Tue, 6 Jun 2000 15:57:12 -0700 Message-ID: <393D812E.8D123B88@netscape.com> Date: Tue, 06 Jun 2000 15:54:38 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7A4108F79C32C4FD17956951" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7A4108F79C32C4FD17956951 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > Okay, I saw only a message from Bill Ricker asking about SPNEGO, > posting by you, and Paul Leach's reply. I recall some other exchange when I first published a draft, but haven't located it. It doesn't much matter, we're having a good discussion about this now. > Having said that .... I > think that a client that sent a SPNEGO token to a SPNEGO-unaware > server would fail. I have been thinking for a while on how to > migrate to clients & servers supporting SPNEGO, and I haven't come > up with any good ideas yet (if I'm missing something obvious, then > please let me know). I don't think you can make this work and maintain SPNEGO's security requirement to protect the negotiation of mechanism. A man in the middle could make it appear to each side that the other does not support SPNEGO, thus forcing a downgrade to the weakest mechanism. If you are willing to take this risk, forgoing this property of SPNEGO, then the propsal to negoitate the mechanism directly through SASL instead of through SPNEGO is simpler. > This presumes that the app will have to have special-case code to > determine which mechanisms exist and to apply policy information > to the mechanism list; I'm not sure how you'll do that without > giving the app knowledge of each mechanism, which would kinda defeat > part of the purpose of GSSAPI. I have a hard time imaging this done > in practice (it seems that you can give SPNEGO some policy constraints, > but it doesn't give you the ability to do the ordering you want). Typically, a SASL library has both policy constrants and a mechanism preference ordering. Usually the preferences are ordered from strongest mechanism to weakest, but sometimes the cost of obtaining a credential affects this. For example, if the SASL library has a Kerberos credential available, it may want to use Kerberos over any mechanism that will need to prompt the user. --------------ms7A4108F79C32C4FD17956951 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIyNTQzOVowIwYJKoZIhvcNAQkEMRYEFJFTsgpttt09 IoHjQ4t45VWOxQMlMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAYrx0vJLB5W0xTTs+3FYOyFqRMCSV8E/yQ15mr+XPU6XL F5ykhvMhCH2fIlKoSFrkdLzFCUKSg1hB/Ll26ZA/+ufPiViWbWE5CVDcm0K80vitFaB87wkN fhnUFr7ooXmIS2H8H7GpIMe4hhQlzWTyBigKVJ5BgSYAPDUoCJVgi6w= --------------ms7A4108F79C32C4FD17956951-- From owner-ietf-sasl Tue Jun 6 16:13:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA15383 for ietf-sasl-bks; Tue, 6 Jun 2000 16:13:40 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15378 for ; Tue, 6 Jun 2000 16:13:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NHPw08710 for ; Tue, 6 Jun 2000 16:17:25 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRA7O00.CTM; Tue, 6 Jun 2000 16:21:24 -0700 Message-ID: <393D876B.5DC135F2@netscape.com> Date: Tue, 06 Jun 2000 16:21:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn John" CC: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44C1D113AC5AE39E0F921503" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms44C1D113AC5AE39E0F921503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > There's a security vs. interoperability tradeoff, since the > SPNEGO negotiation is protected but the SASL negotiation isn't. The design criterion I've used in preparing the draft is that one should not trade away interoperability unless there exists a requirement in a site's security policy which is incompatible with that interoperability. > I'd suggest > recommending, not discouraging, support for SPNEGO for use where available > and appropriate, but also recommending configurable support to allow > negotiation of individual GSS mechanisms at the SASL level. The applicable requirement in the current draft is: In any case, there is no down-negotiation security consideration with using the strongest mechanism and set of options the implementation supports, so for interoperability that mechanism and set of options MUST be negotiable without using the "GSS-SPNEGO" mechanism. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if none > of the GSS mechanisms are available. If (1), the client is most easily > served by performing the negotiation (and exposing the individual GSS > mechanisms) at the SASL level. Given the prospect of (2), however, it'd be > good to be able to negotiate among the available GSS mechanisms in an > SPNEGO-protected manner. If your security policy allows the negotiation of a weak mechanism outside of SPNEGO, then what benefit are you gaining from SPNEGO? An active attacker can make it appear that SPNEGO is not suppported by the other side, removing all benefit of SPNEGO over SASL mechainsm negotiation. This is why I discourage rather than encourage SPNEGO underneath SASL. Unless you have a security policy of allowing certain mechanisms only when their negotiation has been protected, the SPNEGO negotiation protection doesn't buy you anything. This particular security policy is explicitly mentioned in the draft as a reason to violate the SHOULD NOT directive against SPNEGO under SASL. --------------ms44C1D113AC5AE39E0F921503 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIzMjExNlowIwYJKoZIhvcNAQkEMRYEFNVm9y3JzG4m ZTtkVAIIRPY2eYc6MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAmk9WHFo4eyYhkQ4ETuGpyANwwAcjbnn052pPoH0Ou4zD 4hFNvNZN9BSIjHnMMeMW4ZpkCeJQEAP9GFMpS3rIzZeoQXjQtRDUlOYvQbecH7rg9mDTybY+ q/3ASKEJM6yvcdChQQYg+Y29iCV2/J/r9pMhtdd4yTiLAHeQf+ITPwU= --------------ms44C1D113AC5AE39E0F921503-- From owner-ietf-sasl Tue Jun 6 16:55:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18711 for ietf-sasl-bks; Tue, 6 Jun 2000 16:55:47 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18704 for ; Tue, 6 Jun 2000 16:55:45 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NuFO22674 for ; Tue, 6 Jun 2000 16:56:15 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRC5W00.JX4 for ; Tue, 6 Jun 2000 17:03:32 -0700 Message-ID: <393D914B.3FEBD002@netscape.com> Date: Tue, 06 Jun 2000 17:03:23 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5EBBBA0BCDF14825170DA5B8" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms5EBBBA0BCDF14825170DA5B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I second Chris Newman's comments, though I think that if this is intended for standardization then waiting for September 20 is better than switching to DSA. I'd appreciate it if you could expand on why you want to do this as a SASL mechanism instead of using a combination of TLS and the EXTERNAL SASL mechanism. My experience with implementing this stuff is that the key and certificate management aspects are far harder to implement than the protocol aspects. Each of the important protocols has an extension to start a TLS negotiation on a previously unprotected connection. At the latest MailConnect, there were quite a few implementations of these STARTTLS extensions. Only three of these companies supported client certs, this was up from one company the previous year. A product implementing only this draft will not interoperate with a product implementing only the combination of TLS and EXTERNAL. TLS does appear to have won the X.509 space and is gaining implementation momentum. I think this draft is approaching the wrong problem. --------------ms5EBBBA0BCDF14825170DA5B8 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNzAwMDMyNFowIwYJKoZIhvcNAQkEMRYEFOQ2w36fvM1N 2obU4EoevVUWtmq2MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGALFHw1flmrJp1XESJfKEAZEDOmtGVf+9ws0puzDd2klV6 8Zy3+QCN4qBnhZfn8Mm7GkGEeLD6oWbbu4lGWncNSWciZgOcTxVtEoufQcCDCMiB66Qh3NiS TCEu/BtFN1kHJAkxRAZg0o4omsIi23hN1K+nEE3U70HOhaz+PEFXy/0= --------------ms5EBBBA0BCDF14825170DA5B8-- From owner-ietf-sasl Tue Jun 6 19:01:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA04731 for ietf-sasl-bks; Tue, 6 Jun 2000 19:01:38 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA04721 for ; Tue, 6 Jun 2000 19:01:36 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 18:45:50 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 18:45:53 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD021.244B91F6" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Tue, 6 Jun 2000 18:38:55 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EB8@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QE4de/K5YKnZcShqLBlUQP9UeSAACYjog From: "Paul Leach" To: "John Myers" , X-OriginalArrivalTime: 07 Jun 2000 01:45:53.0859 (UTC) FILETIME=[1DE3B130:01BFD022] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: John Myers [mailto:jgmyers@netscape.com] > Sent: Tuesday, June 06, 2000 5:03 PM > To: ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > TLS does > appear to have won the X.509 space and is gaining implementation > momentum. I think this draft is approaching the wrong problem. I concur completely. Paul ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: John Myers [mailto:jgmyers@netscape.com]
> Sent: Tuesday, June 06, 2000 5:03 PM
> To: ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>  TLS does
> appear to have won the X.509 space and is = gaining implementation
> momentum.  I think this draft is = approaching the wrong problem.

I concur completely.

Paul

------_=_NextPart_001_01BFD021.244B91F6-- From owner-ietf-sasl Wed Jun 7 10:17:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11530 for ietf-sasl-bks; Wed, 7 Jun 2000 10:17:24 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11524 for ; Wed, 7 Jun 2000 10:17:21 -0700 (PDT) Received: (qmail 22791 invoked from network); 7 Jun 2000 17:25:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:25:40 -0000 Received: (qmail 19734 invoked by uid 1183); 7 Jun 2000 17:25:57 -0000 Date: Wed, 7 Jun 2000 19:25:57 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul and John, Thanks for your views. However, IMHO, TLS is not always suitable, for several reasons. Among them are: -(partially quoting from a posting by P. Fahn, Certicom, sent to another list:) Many network architectures today have "untrusted" middlemen (gateways, proxies, translators, formatters, and it is not unlikely that architectures like this will increase in numbers. The end users and content providers and application developers should be able to put in security on top of all the middlemen, at the application layer. And middlemen want the same thing to avoid the liability that comes with seeing all the plaintext. Since one will not always have simple two-party network topologies, simple transport-layer channel security will not always be enough. -As mentioned in the draft, TLS is more complex and does not carry the concept of separate authentication and authorization identities. Regards, -- Magnus On Tue, 6 Jun 2000, Paul Leach wrote: > > -----Original Message----- > > From: John Myers [mailto:jgmyers@netscape.com] > > Sent: Tuesday, June 06, 2000 5:03 PM > > To: ietf-sasl@imc.org > > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > TLS does appear to have won the X.509 space and is gaining > > implementation momentum. I think this draft is approaching the > > wrong problem. > > I concur completely. > > Paul From owner-ietf-sasl Wed Jun 7 10:21:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11657 for ietf-sasl-bks; Wed, 7 Jun 2000 10:21:13 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11653 for ; Wed, 7 Jun 2000 10:21:11 -0700 (PDT) Received: (qmail 22849 invoked from network); 7 Jun 2000 17:29:31 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:29:31 -0000 Received: (qmail 19949 invoked by uid 1183); 7 Jun 2000 17:29:48 -0000 Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, Many thanks for your comments and suggestions for improvements. My response below. On Tue, 6 Jun 2000, Chris Newman wrote: > --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom > wrote: > > FYI. Comments and feedback is welcome and solicited. > > I skimmed the document. I'm sorry I don't have time to chase down all the > X.509/FIPS references necessary to grok the spec. > > (1) It seems to have far too many things marked "OPTIONAL". This makes the > protocol more complex than necessary. Preferably the only OPTIONAL items > should be the differences between one-way and mutual auth. RandomC > certainly has no business being optional. Right, we will change this in the next draft. > (2) I don't understand the value of this if the client cert is optional. > Doesn't that mean the server has to store the certs for every possible > client in order to guarantee interoperability? Or am I missing something? Yes, client CertData should probably be mandatory. > (3) I presume this factors in the DNS name of the server which the client > intends to communicate with -- usually the only information the client has > about the server. Where can I read the rules for how that is used? Is > that put in the EntityB field? Is the case where multiple physical servers > answer for the same domain name considered? Is it possible for each > physical server to have a different private key in that case? Yes it is. Only requirement is that the server is able to see that the client intended to communicate with it - if, e.g., there is a round-robin DNS, then for all intent and purposes involved servers are the same (from the client's perspective). It could be that the DNS name is a SHOULD (or even a MUST?). > (4) I don't see a clear statement of how to determine the authorization > identity (user to log in as, which may be different from the user whose > private key is used). If this is buried somewhere in X.509 specs, please > draw attention to it in the spec. Correct, thanks for the observation. There should be an explicit, but optional, authorization id included. If not included, the server will have to use the authenticated id. > (5) The reference to RFC 1738 should be updated to RFC 2396. Right. > (6) Is there a fast re-authentication option, or should TLS be used when > that's needed? Note that many POP clients make a connection every 5 > minutes to check mail, and some IMAP clients make a new connection every > time a new folder is opened so a fast re-authentication protocol could be > important for scalability. No, there is no fast re-authentication option. One could add one (for example by letting the entities negotiate a session secret) but it is our feeling that this would complicate the mechanism unnecessarily. > (7) Is there an open-source implementation of RFC 2459? If not, this seems > much more complex than TLS where I can just grab OpenSSL and let it do all > the work. Certificate-handling open-source is certainly available,e.g. as part of OpenSSL, and ssleay, but the Jonah PKIX freeware library is another alternative, I guess. > (8) The IETF has a policy (the "Munich Mandate") which prohibits making > patented algorithms mandatory to implement when there's and unpatented > equivalent. I consider the recommendation to implement the RSA algorithm > inappropriate given that policy. Since this is a set of mechanisms rather > than a protocol, the recommendation is not necessary for interoperability > so you could simply remove it. Alternatively you could change it to > recommend DSA, or wait until after September 20th for standardization. Right, the latter was (and is) our intent. Thanks, -- Magnus From owner-ietf-sasl Wed Jun 7 18:18:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28339 for ietf-sasl-bks; Wed, 7 Jun 2000 18:18:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28327 for ; Wed, 7 Jun 2000 18:18:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e581MAw02792 for ; Wed, 7 Jun 2000 18:22:10 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTANN00.SZ5 for ; Wed, 7 Jun 2000 18:26:11 -0700 Message-ID: <393EF62D.90D04494@netscape.com> Date: Wed, 07 Jun 2000 18:26:05 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDBB2633BB5C5E1273A580AC7" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msDBB2633BB5C5E1273A580AC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. --------------msDBB2633BB5C5E1273A580AC7 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAxMjYwNlowIwYJKoZIhvcNAQkEMRYEFNLKjvs652s1 3hpbQ538rPu1D4gFMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAvfFI/2UTzJneXp+zjtV7J/OaBzCnOpXj4nnMVel1FKtp PMVFH+xY7+uOSpMd+//MIz52ZxEDjTRnPydmdzbIuyPp/cqvMEWfMSXcY9ew20iU2+Alhvfn dkxVFQVhHyHZQaD5PEzR2utRl1yZ+I2N1oAlgljteehtHUn68LxnuhU= --------------msDBB2633BB5C5E1273A580AC7-- From owner-ietf-sasl Wed Jun 7 18:42:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03460 for ietf-sasl-bks; Wed, 7 Jun 2000 18:42:39 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03456 for ; Wed, 7 Jun 2000 18:42:37 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 11:53:37 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 11:54:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I must have blinked. I thought the statement at issue was that TLS is a good poit-to-point solution but that it can't be used where middle-men are involved (DMZs, for example). In particular, SASL/EXTERNAL cannot be used. I don't believe TLS is a session layer protocol, either. Its purpose and implementation are as a network layer look-alike. Wherever TCP is found, TLS may be shimmed in. So, it provides neither transport nor session services. I also can't understand references to SASL services and then proposing to use TLS without client certificates. Even if SASL/EXTERNAL could be used, it would be useless without client certificates. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 11:26 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. From owner-ietf-sasl Wed Jun 7 19:15:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA07811 for ietf-sasl-bks; Wed, 7 Jun 2000 19:15:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07806 for ; Wed, 7 Jun 2000 19:15:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e582FqO27378 for ; Wed, 7 Jun 2000 19:15:52 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTDAO00.43B for ; Wed, 7 Jun 2000 19:23:12 -0700 Message-ID: <393F0386.999E2B34@netscape.com> Date: Wed, 07 Jun 2000 19:23:02 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B5289C8F322EAB542625529" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4B5289C8F322EAB542625529 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. --------------ms4B5289C8F322EAB542625529 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAyMjMwM1owIwYJKoZIhvcNAQkEMRYEFMiF+TX6lseM ob/o6bout1yKNb3jMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAV73BHMxgBYKU97UJf3JKIsXOTz6EuGEqSii/u38gpKSB 2K+qNF6dfOR+0BYAZHkmapbGZ4ounLf26zJzP+SVeopndZmC1B7RvBD24o2/Y4DAp7aL7GAx UEvbxMHs9b1Bduw8mBGFMXxLW1o5ulzQRtgir+ADM5YaQk6Gepcqj48= --------------ms4B5289C8F322EAB542625529-- From owner-ietf-sasl Wed Jun 7 19:43:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12202 for ietf-sasl-bks; Wed, 7 Jun 2000 19:43:59 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12197 for ; Wed, 7 Jun 2000 19:43:55 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 12:54:56 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 12:56:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An example. We are going to attempt an authenticated logon through a DMZ. Therefore, we have my host, HostA, the DMZ host, HostB, and the destination host, HostC. I connect to HostB (thinking that it is HostC, if I understand how a DMZ works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, so I send my client certificate. The connection is established. I logon, specifying SASL/EXTERNAL. HostB receives the logon and passes it to HostC. HostC does not have my client certificate and rejects the logon. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 12:23 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. From owner-ietf-sasl Wed Jun 7 19:56:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13917 for ietf-sasl-bks; Wed, 7 Jun 2000 19:56:14 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13906 for ; Wed, 7 Jun 2000 19:56:13 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA19901; Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Message-Id: <200006080304.XAA19901@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org Cc: John Gardiner Myers In-reply-to: <393EF62D.90D04494@netscape.com> Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: <393EF62D.90D04494@netscape.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry From owner-ietf-sasl Wed Jun 7 20:16:08 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA16280 for ietf-sasl-bks; Wed, 7 Jun 2000 20:16:08 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16276 for ; Wed, 7 Jun 2000 20:16:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e583Jxw13107 for ; Wed, 7 Jun 2000 20:19:59 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTG3Z00.RX6 for ; Wed, 7 Jun 2000 20:23:59 -0700 Message-ID: <393F1110.3519635F@netscape.com> Date: Wed, 07 Jun 2000 20:20:50 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms950CC6E5C461642C245C16E9" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms950CC6E5C461642C245C16E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. --------------ms950CC6E5C461642C245C16E9 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA0MjA1MFowIwYJKoZIhvcNAQkEMRYEFFrxOtQjML9w BiJMIEgrxTXT4NdeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAShVpt1Osg2dAgbR7knhyk1wcSCDNoMDdAy/23Z9UcRpyYrnb/m1HjikgfNFH671P lwbkbwCEu8+tD7UUR8C1IT9OXHXq+3617HL2TUin1biSUvq5g1CYQNAuiaN2nVQQmaBSpuaP 0VsOQPNScZ2GfBAa3vFuDpo/BS9qLGrLD7A= --------------ms950CC6E5C461642C245C16E9-- From owner-ietf-sasl Wed Jun 7 21:07:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20750 for ietf-sasl-bks; Wed, 7 Jun 2000 21:07:05 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20746 for ; Wed, 7 Jun 2000 21:07:02 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:18:03 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:19:15 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But then you are NOT using SASL/EXTERNAL because HostC is simply validating HostB and not HostA! For example, if we were using X.509 authentication, the certification path and token would actually travel end-to-end and HostC would indeed receive credentials from HostA. This really IS an application protocol. What you are talking about is a link protocol. Your remarks about TLS being a session or application protocol are simply wrong. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 13:21 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. From owner-ietf-sasl Wed Jun 7 21:23:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA21074 for ietf-sasl-bks; Wed, 7 Jun 2000 21:23:53 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21065 for ; Wed, 7 Jun 2000 21:23:50 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:34:51 +1000 Message-ID: From: "Ramsay, Ron" To: Lawrence Greenfield , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:36:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry, I'm fascinated by [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" Can I substitute: S: "Authentication failed. Try PLAIN"? Ron. -----Original Message----- From: Lawrence Greenfield [mailto:leg+@andrew.cmu.edu] Sent: Thursday, 8 June 2000 13:05 To: ietf-sasl@imc.org Cc: John Gardiner Myers Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry From owner-ietf-sasl Wed Jun 7 21:50:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA25424 for ietf-sasl-bks; Wed, 7 Jun 2000 21:50:32 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25417 for ; Wed, 7 Jun 2000 21:50:31 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e584sOw19763 for ; Wed, 7 Jun 2000 21:54:24 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTKHB00.00E for ; Wed, 7 Jun 2000 21:58:23 -0700 Message-ID: <393F2732.ADB491F3@netscape.com> Date: Wed, 07 Jun 2000 21:55:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms878058F0A2C4ADC712311B67" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms878058F0A2C4ADC712311B67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > HostB and not HostA! In the example I provided in my last message, I am using EXTERNAL between HostA and HostB. Any SASL mechanism, including EXTERNAL, that supports an authorization id field can be used between HostB and HostC. This is analogous to the example you provided, since that example showed a TLS security association being established between HostA and HostB. > For example, if we were using X.509 authentication, the certification path > and token would actually travel end-to-end and HostC would indeed receive > credentials from HostA. If you instead want to establish a security association between HostA and HostC, then HostB should forward the TLS records through between HostA and HostC. > This really IS an application protocol. What you are talking about is a link > protocol. Your remarks about TLS being a session or application protocol are > simply wrong. I'm sorry, I don't see the argument behind these assertions. What difference between TLS and SASL makes TLS a "link" protocol as opposed to an "application" protocol? In your HostA, HostB, HostC situation, how would you handle a SASL negotiation using a mechanism that provides perfect forward secrecy of the identity being authenticated? --------------ms878058F0A2C4ADC712311B67 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA1NTUxNVowIwYJKoZIhvcNAQkEMRYEFGsWQc0PMKXP NDc6eeuaFQLO1pJaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAKVyPxEv0/RGmrO71WAzwBy4i3rUetOPVSjXBvsHmAdb2mbQeM+xryFua7XDnHUh0 mEimCMfSzqGC5g1CxbjfOK3cXnDvokvP/T18gj7KpGOQ4xK24yNnkVrKr9s2IqSlX6L3VrFD vMCwB5EcVfs2NwhK2nlKjltHHTn+5yJoG3A= --------------ms878058F0A2C4ADC712311B67-- From owner-ietf-sasl Wed Jun 7 22:46:35 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29884 for ietf-sasl-bks; Wed, 7 Jun 2000 22:46:35 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29880 for ; Wed, 7 Jun 2000 22:46:34 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e585l8O11218 for ; Wed, 7 Jun 2000 22:47:08 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTN2Q00.9YN for ; Wed, 7 Jun 2000 22:54:26 -0700 Message-ID: <393F3454.564F543D@netscape.com> Date: Wed, 07 Jun 2000 22:51:18 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms81E3B4AA457C0A57A98237DE" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms81E3B4AA457C0A57A98237DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > Can I substitute: > > S: "Authentication failed. Try PLAIN"? Sure. You can even do this as soon as the client sends: C: a AUTHENTICATE "TLS" or even replace all the SASL mechanisms in the banner with just PLAIN. Or you can replace legitimate TLS records with TLS fatal alerts. Protocol spoofers can do all sorts of interesting things if the endpoints have a sufficiently lax security policy. Which brings up an interesting point about the draft. There's no point having the mechanism support mutual authentication because the mechanism doesn't support any security layers. It's useless for the server to prove its identity to the client since the moment the SASL negotiation is over either side could be talking to anybody. --------------ms81E3B4AA457C0A57A98237DE 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA2NTExOFowIwYJKoZIhvcNAQkEMRYEFEmf6VjK05/s TrX6SJpjrIiSHdHHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAAQLP/ptLQO7JQ25oHE/YHur79/vuU+yuONglhRK/8ZM75cEEi0IF6sIOP/VlUs8Z YeWEMbt2/PNzKG+8v8znJIIECNWLSkCDdmU5FdiRgB2a4qiJiy74QYksm8yGrKjtnTErf9ey rtRaDJ5yc6/P7SqLilaVNuwPJ+e66tJEdGU= --------------ms81E3B4AA457C0A57A98237DE-- From owner-ietf-sasl Thu Jun 8 10:27:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03210 for ietf-sasl-bks; Thu, 8 Jun 2000 10:27:19 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03205 for ; Thu, 8 Jun 2000 10:27:16 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 10:19:13 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 8 Jun 2000 10:25:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD16C.7CC39E72" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Thu, 8 Jun 2000 10:10:46 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QpOmxZOqfIAyMRzCjRDN/0Aj3YQAyCxTA From: "Paul Leach" To: "Magnus Nystrom" , Cc: X-OriginalArrivalTime: 08 Jun 2000 17:25:08.0436 (UTC) FILETIME=[7E3F7940:01BFD16E] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Wednesday, June 07, 2000 10:26 AM > To: ietf-sasl@imc.org > Cc: robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Dear Paul and John, >=20 > Thanks for your views. However, IMHO, TLS is not always suitable, for > several reasons. Among them are: >=20 > -(partially quoting from a posting by P. Fahn, Certicom, sent to > another list:) Many network architectures today have > "untrusted" middlemen (gateways, proxies, translators,=20 > formatters, Allowing an "untrusted" middleman to translate or re-format information flowing through it smacks of a recipe for disaster. Surely you mis-speak. Paul ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Wednesday, June 07, 2000 10:26 AM
> To: ietf-sasl@imc.org
> Cc: robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Dear Paul and John,
>
> Thanks for your views. However, IMHO, TLS is not = always suitable, for
> several reasons. Among them are:
>
> -(partially quoting from a posting by P. Fahn, = Certicom, sent to
>  another list:) Many network architectures = today have
>  "untrusted" middlemen (gateways, = proxies, translators,
> formatters,

Allowing an "untrusted" middleman to = translate or re-format information flowing through it smacks of a recipe = for disaster. Surely you mis-speak.

Paul

------_=_NextPart_001_01BFD16C.7CC39E72-- From owner-ietf-sasl Thu Jun 8 12:34:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05481 for ietf-sasl-bks; Thu, 8 Jun 2000 12:34:59 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05476 for ; Thu, 8 Jun 2000 12:34:57 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 456E465F; Thu, 8 Jun 2000 12:43:24 -0700 (PDT) Received: by mail-proxy-2.amazon.com id MAA09585; Thu, 8 Jun 2000 12:43:23 -0700 (PDT) Message-ID: <393FF694.4EEB1D21@amazon.com> Date: Thu, 08 Jun 2000 12:40:04 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Myers Cc: Linn John , "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Myers wrote: > > This is why I discourage rather than encourage SPNEGO underneath SASL. > Unless you have a security policy of allowing certain mechanisms only > when their negotiation has been protected, the SPNEGO negotiation > protection doesn't buy you anything. This particular security policy is > explicitly mentioned in the draft as a reason to violate the SHOULD NOT > directive against SPNEGO under SASL. As long as major applications, like say LDAP or IMAP for example, are in love with SASL (Honestly, do you blame them? Good grief, look at the prototype for gss_init_sec_context() some time!), don't you think it's worthwhile to at least go to the effort to add a modicum of real security to it? I mean, the only SASL mech worth a darn security-wise at the moment is GSS-API. I struggled with this for a while, then realized that if both sides really want a secure connection, then can simply decide they're only going to support one SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, everybody wins. So I would think that an SPNEGO SASL mech would be a good thing, because well-designed implementations of application protocols could be configured to only support one SASL mech (SPNEGO), so that we get real negotiation of a security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around it. Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords" that you would want to avoid by policy configuration. I believe that the best we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so that SASL (which isn't going away) will support SPNEGO as an available option in the vast majority of implementations. Dave From owner-ietf-sasl Fri Jun 9 02:42:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00469 for ietf-sasl-bks; Fri, 9 Jun 2000 02:42:30 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA00465 for ; Fri, 9 Jun 2000 02:42:27 -0700 (PDT) Received: (qmail 46938 invoked from network); 9 Jun 2000 09:50:54 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 09:50:54 -0000 Received: (qmail 2908 invoked from network); 9 Jun 2000 09:51:11 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 09:51:11 -0000 Date: Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: Paul Leach cc: ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security From owner-ietf-sasl Fri Jun 9 02:56:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01404 for ietf-sasl-bks; Fri, 9 Jun 2000 02:56:42 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01400 for ; Fri, 9 Jun 2000 02:56:40 -0700 (PDT) Received: (qmail 47102 invoked from network); 9 Jun 2000 10:05:09 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 10:05:09 -0000 Received: (qmail 3519 invoked from network); 9 Jun 2000 10:05:26 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 10:05:26 -0000 Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: John Myers cc: Robert Zuccherato , ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <393F2732.ADB491F3@netscape.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear John, On Wed, 7 Jun 2000, John Myers wrote: > "Ramsay, Ron" wrote: > > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > > HostB and not HostA! > > In the example I provided in my last message, I am using EXTERNAL > between HostA and HostB. Any SASL mechanism, including EXTERNAL, that > supports an authorization id field can be used between HostB and HostC. > > This is analogous to the example you provided, since that example showed > a TLS security association being established between HostA and HostB. > > > For example, if we were using X.509 authentication, the certification path > > and token would actually travel end-to-end and HostC would indeed receive > > credentials from HostA. > > If you instead want to establish a security association between HostA > and HostC, then HostB should forward the TLS records through between > HostA and HostC. The TLS endpoint isn't always the same as the application endpoint and that is the very reason for this proposal. Maybe this should be made more explicit in the draft. > > This really IS an application protocol. What you are talking about is a link > > protocol. Your remarks about TLS being a session or application protocol are > > simply wrong. > > I'm sorry, I don't see the argument behind these assertions. What > difference between TLS and SASL makes TLS a "link" protocol as opposed > to an "application" protocol? IMHO, since it is possible to "insert" SASL in many higher-level protocols it is a useful mechanism when, for one reason or another, lower level protocols (I include TLS here) terminates at a gateway or similar, or the application using the SASL-enabled protocol is unable to run TLS for one reason or another, but is still capable of doing public-key operations. > In your HostA, HostB, HostC situation, how would you handle a SASL > negotiation using a mechanism that provides perfect forward secrecy of > the identity being authenticated? Just so we are talking about the same thing here: Perfect forward secrecy = Disclosing one key/authentication does not give an attacker the possibility to reuse that information in subsequent exchanges. The proposed protocol is vulnerable to session hi-jacking, this fact is also mentioned in the draft, and true also for other SASL mechanisms not inserting a security layer. -- Magnus From owner-ietf-sasl Fri Jun 9 03:07:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02566 for ietf-sasl-bks; Fri, 9 Jun 2000 03:07:53 -0700 (PDT) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02558 for ; Fri, 9 Jun 2000 03:07:51 -0700 (PDT) Received: from 209-6-126-154.c4-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([209.6.126.154] helo=PIXIE) by smtp03.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 130Lps-0004aD-00; Fri, 9 Jun 2000 06:16:20 -0400 Message-ID: <01ca01bfd1fb$07f9c870$9a7e06d1@aa.net> From: "Scott Guthery" To: "Magnus Nystrom" , "Paul Leach" Cc: , References: Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Fri, 9 Jun 2000 06:11:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: WAP, for example. Cheers, Scott ----- Original Message ----- From: Magnus Nystrom To: Paul Leach Cc: ; Sent: Friday, June 09, 2000 5:50 AM Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security From owner-ietf-sasl Fri Jun 9 05:05:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10792 for ietf-sasl-bks; Fri, 9 Jun 2000 05:05:49 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10787 for ; Fri, 9 Jun 2000 05:05:47 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA16307; Fri, 9 Jun 2000 08:14:05 -0400 (EDT) Date: Fri, 9 Jun 2000 8:14:05 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems to me that the fact that you have untrusted middlemen is even more reason why you would use TLS. You do not trust them, therefore you must protect your data end to end. You allow the middlemen to proxy, translate, ... the connection and then you perform an end to end authentication and encryption. > > Dear Paul, > > No, I am not mis-speaking. There are in fact architectures like this. > > -- Magnus > > On Thu, 8 Jun 2000, Paul Leach wrote: > > > > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Wednesday, June 07, 2000 10:26 AM > > > To: ietf-sasl@imc.org > > > Cc: robert.zuccherato@entrust.com > > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > > > > Dear Paul and John, > > > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > > several reasons. Among them are: > > > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > > another list:) Many network architectures today have > > > "untrusted" middlemen (gateways, proxies, translators, > > > formatters, > > > > Allowing an "untrusted" middleman to translate or re-format information > > flowing through it smacks of a recipe for disaster. Surely you > > mis-speak. > > > > Paul > > > > -- Magnus > Magnus Nystrom Email: magnus@rsasecurity.com > RSA Security > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org From owner-ietf-sasl Fri Jun 9 08:11:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA22310 for ietf-sasl-bks; Fri, 9 Jun 2000 08:11:45 -0700 (PDT) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22300 for ; Fri, 9 Jun 2000 08:11:42 -0700 (PDT) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA12479; Fri, 9 Jun 2000 08:20:12 -0700 (PDT) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA06713 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by networking.Stanford.EDU (8.8.6/8.8.5) with ESMTP id MAA11365 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA24850 for rfc-dist-outgoing; Thu, 8 Jun 2000 11:06:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24843 for ; Thu, 8 Jun 2000 11:06:56 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA18853; Thu, 8 Jun 2000 11:07:36 -0700 (PDT) Message-Id: <200006081807.LAA18853@boreas.isi.edu> To: rfc-dist@isi.edu Subject: RFC 2831 on Digest SASL Mechanism Cc: rfc-ed@isi.edu Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:07:36 -0700 From: RFC Editor Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2831 Title: Using Digest Authentication as a SASL Mechanism Author(s): P. Leach, C. Newman Status: Standards Track Date: May 2000 Mailbox: paulle@microsoft.com, chris.newman@innosoft.com Pages: 27 Characters: 58124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-leach-digest-sasl-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2831.txt This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2831 --OtherAccess Content-Type: Message/External-body; name="rfc2831.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Jun 9 09:33:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01240 for ietf-sasl-bks; Fri, 9 Jun 2000 09:33:21 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01236 for ; Fri, 9 Jun 2000 09:33:20 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 09:20:58 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 09:29:20 -0700 content-class: urn:content-classes:message Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD22E.E0481654" X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 09:22:16 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90ED1@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R92LwGXCMHD7ASm6QmOzF6UyG7QAN883g From: "Paul Leach" To: "Magnus Nystrom" Cc: , X-OriginalArrivalTime: 09 Jun 2000 16:29:20.0300 (UTC) FILETIME=[DD0436C0:01BFD22F] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 2:50 AM > To: Paul Leach > Cc: ietf-sasl@imc.org; robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 >=20 > Dear Paul, >=20 > No, I am not mis-speaking. There are in fact architectures like this. >=20 > -- Magnus >=20 Well, then they are deliberately allowing untrusted parties, _including malicious ones, against whom the proposal offers no protection_, to access their communications. They don't need authentication at all, in which case. Paul ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 2:50 AM
> To: Paul Leach
> Cc: ietf-sasl@imc.org; = robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>
> Dear Paul,
>
> No, I am not mis-speaking. There are in fact = architectures like this.
>
> -- Magnus
>

Well, then they are deliberately allowing untrusted = parties, _including malicious ones, against whom the proposal offers no = protection_, to access their communications. They don't need = authentication at all, in which case.

Paul

------_=_NextPart_001_01BFD22E.E0481654-- From owner-ietf-sasl Fri Jun 9 14:36:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07932 for ietf-sasl-bks; Fri, 9 Jun 2000 14:36:24 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07928 for ; Fri, 9 Jun 2000 14:36:23 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 13:13:41 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 13:21:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD24F.602B0186" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 13:14:54 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R+YJYd8yoMufhR/CtpyI5/ApCngAVi8OA From: "Paul Leach" To: "Magnus Nystrom" , "John Myers" Cc: "Robert Zuccherato" , X-OriginalArrivalTime: 09 Jun 2000 20:21:58.0987 (UTC) FILETIME=[5D0AD1B0:01BFD250] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 3:04 AM > To: John Myers > Cc: Robert Zuccherato; ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should=20 > be made more > explicit in the draft. Why not? What stops any app that would use the proposed new authentication protocol from making the two end points the same and using TLS instead? In fact, nothing does. Paul ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 3:04 AM
> To: John Myers
> Cc: Robert Zuccherato; ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>

> The TLS endpoint isn't always the same as the = application endpoint and
> that is the very reason for this proposal. Maybe = this should
> be made more
> explicit in the draft.

Why not? What stops any app that would use the = proposed new authentication protocol from making the two end points the = same and using TLS instead?

In fact, nothing does.

Paul

------_=_NextPart_001_01BFD24F.602B0186-- From owner-ietf-sasl Sat Jun 10 01:42:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18413 for ietf-sasl-bks; Sat, 10 Jun 2000 01:42:26 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA18409 for ; Sat, 10 Jun 2000 01:42:23 -0700 (PDT) Received: (qmail 62027 invoked from network); 10 Jun 2000 08:50:52 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 10 Jun 2000 08:50:52 -0000 Received: (qmail 17246 invoked by uid 1183); 10 Jun 2000 08:51:09 -0000 Date: Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: Paul Leach cc: John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, On Fri, 9 Jun 2000, Paul Leach wrote: > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Friday, June 09, 2000 3:04 AM > > > > The TLS endpoint isn't always the same as the application endpoint and > > that is the very reason for this proposal. Maybe this should > > be made more explicit in the draft. > > Why not? What stops any app that would use the proposed new > authentication protocol from making the two end points the same and > using TLS instead? > > In fact, nothing does. How about: A client uncapable of verifying certificates? A situation where unilateral authentication is enough? A client uncapable of performing a full TLS handshake? BR, -- Magnus From owner-ietf-sasl Sat Jun 10 04:01:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA28330 for ietf-sasl-bks; Sat, 10 Jun 2000 04:01:48 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28326 for ; Sat, 10 Jun 2000 04:01:46 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id HAA05096; Sat, 10 Jun 2000 07:10:15 -0400 (EDT) Date: Sat, 10 Jun 2000 7:10:14 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Paul, > > On Fri, 9 Jun 2000, Paul Leach wrote: > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > > > > > The TLS endpoint isn't always the same as the application endpoint and > > > that is the very reason for this proposal. Maybe this should > > > be made more explicit in the draft. > > > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > > > > In fact, nothing does. > > How about: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? > > BR, > -- Magnus > Use a TLS cipher suite that does not use X.509 certificates for authentication. At the moment there is only Kerberos 5 defined as an RFC but there is nothing to stop someone from defining a cipher suite that uses something else. Or you can use TLS in an anonymous mode if you have another authentication mechanism that can prove shared knowledge of unverified data. If so, you take the TLS client finished message and the server finished message and you verify them as part of the authentication method. That will ensure there is no MITM. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org From owner-ietf-sasl Sat Jun 10 13:34:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14759 for ietf-sasl-bks; Sat, 10 Jun 2000 13:34:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14755 for ; Sat, 10 Jun 2000 13:34:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKYrO15561 for ; Sat, 10 Jun 2000 13:34:53 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYHIG00.QJ0 for ; Sat, 10 Jun 2000 13:42:16 -0700 Message-ID: <3942A746.85B7CE7D@netscape.com> Date: Sat, 10 Jun 2000 13:38:41 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF60FEB9B648E5FBF63A83891" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msF60FEB9B648E5FBF63A83891 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should be made more > explicit in the draft. What is HostA authenticating to, HostB or HostC? Whenever I address one case, you counter with an argument about the other. If the TLS endpoint isn't the same as the application endpoint, you have the TLS endpoint authenticate to the application endpoint using its own credentials, passing the original client's identity in the authorization ID. This results in much better security, as only middlemen the application endpoint is configured to trust are permitted to eavesdrop or modify the the connection. > > I'm sorry, I don't see the argument behind these assertions. What > > difference between TLS and SASL makes TLS a "link" protocol as opposed > > to an "application" protocol? > > IMHO, since it is possible to "insert" SASL in many higher-level protocols > it is a useful mechanism when, for one reason or another, lower level > protocols (I include TLS here) terminates at a gateway or similar, or the > application using the SASL-enabled protocol is unable to run TLS for one > reason or another, but is still capable of doing public-key operations. One can also "insert" TLS in higher-level protocols. See RFC's 2817, 2595, and 2487. TLS is no different than SASL in this regard. How does the theoretical existence of applications which support SASL and public-key operations make TLS a "link" protocol but not an "application" protocol? There do exist applications which support TLS and public-key operations, but are unable to run SASL for one reason or another. > > In your HostA, HostB, HostC situation, how would you handle a SASL > > negotiation using a mechanism that provides perfect forward secrecy of > > the identity being authenticated? > > Just so we are talking about the same thing here: Perfect forward secrecy > = Disclosing one key/authentication does not give an attacker the > possibility to reuse that information in subsequent exchanges. Exactly. Consider a SASL mechanism where the client and server first perform a Diffie-Hellman key exchange. The client then sends the server his cert encrypted with the Diffie-Hellman key and an authenticator formed by signing the Diffie-Hellman key with his private key. Or just explain how in your HostA, HostB, HostC situation you would handle a Kerberos authentication which negotiates a privacy security layer. I brought up the issue of perfect forward secrecy of the identity being authenticated to prevent the answer where HostB and HostC both have access to the server key. > The proposed protocol is vulnerable to session hi-jacking, this fact is > also mentioned in the draft, and true also for other SASL mechanisms not > inserting a security layer. Most of the other SASL mechanisms which don't have a security layer don't have it because they are incapable of negotiating a session key. The thing I don't like about this particular proposal are the implications that this lack of security layer somehow improves security or makes it significantly easier to implement than TLS. --------------msF60FEB9B648E5FBF63A83891 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxMzg0MVowIwYJKoZIhvcNAQkEMRYEFFb3JfB2R2u0 AP/6ISFCFoEKfLK+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2suDY3iZTSFCMbAmEaZeODqt/9EnCh8gz3yX6eod11a5YJGkeCmqgo89hEJuUNz 6GhdfIqznFlJdtiqjOStrHREBUk9l0hs2U/voQ1vQ4Yz46PZ6FKLZl5RtX75W0ilfTzmmOai 122j/Q/8Qh2vYXcdPHYwSl9lbm3NPzCsBy8= --------------msF60FEB9B648E5FBF63A83891-- From owner-ietf-sasl Sat Jun 10 13:49:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14924 for ietf-sasl-bks; Sat, 10 Jun 2000 13:49:28 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14920 for ; Sat, 10 Jun 2000 13:49:27 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKrUw02756 for ; Sat, 10 Jun 2000 13:53:30 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYI7X00.NPF for ; Sat, 10 Jun 2000 13:57:33 -0700 Message-ID: <3942AAE3.A6CCFDE3@netscape.com> Date: Sat, 10 Jun 2000 13:54:03 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C4BBC890518868687607636" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms2C4BBC890518868687607636 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client can perform a TLS handshake and ignore the cert sent by the server. Like the proposed mechanism, such a client would be subject to active attacks. Unlike your proposed mechanism, such a client would be protected from passive eavesdropping and would interoperate with the installed base. Our implmentation of STARTTLS in outgoing SMTP relay uses this mode. Subsequent releases will allow the site to configure which domains require protection against active attack in outgoing SMTP relay. > A client uncapable of performing a full TLS handshake? Why would a client capable of managing a client cert and signing authentication requests be uncapable of performing a full TLS handshake? --------------ms2C4BBC890518868687607636 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxNTQwNFowIwYJKoZIhvcNAQkEMRYEFCmRIks4K5gC q7S8+7tCnZFb2+kHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyEN0w6ycEoCO9PIzqIkpDpmcSi4pJMuWLomOXByPWzv19uBpusZAkJBMnZEldqOi 2/ZrkV35CUIBTKL+pgwib+VfpGC4N3rNpBF6Zkxdd+jLeipNRONetOAnupcUhNxi31XYlNUO Z5u86pF8sL+pH265y4+HmqHrkFwYgp+8R/E= --------------ms2C4BBC890518868687607636-- From owner-ietf-sasl Sat Jun 10 15:33:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15922 for ietf-sasl-bks; Sat, 10 Jun 2000 15:33:04 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA15918 for ; Sat, 10 Jun 2000 15:33:03 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 10 Jun 2000 15:33:12 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Sat, 10 Jun 2000 15:41:40 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD32B.AA1D8DC2" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Sat, 10 Jun 2000 15:31:48 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EE6@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/SuCbt3pclRNO/Qg6DtDKrh0V11QAc/wOg From: "Paul Leach" To: "Magnus Nystrom" Cc: "John Myers" , "Robert Zuccherato" , X-OriginalArrivalTime: 10 Jun 2000 22:41:40.0712 (UTC) FILETIME=[0B5A4E80:01BFD32D] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Saturday, June 10, 2000 1:51 AM > To: Paul Leach > Cc: John Myers; Robert Zuccherato; ietf-sasl@imc.org > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Paul, >=20 > On Fri, 9 Jun 2000, Paul Leach wrote: > >=20 > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > >=20 > > > The TLS endpoint isn't always the same as the application=20 > endpoint and > > > that is the very reason for this proposal. Maybe this should=20 > > > be made more explicit in the draft. > >=20 > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > >=20 > > In fact, nothing does. >=20 > How about: > A client uncapable of verifying certificates? A situation=20 > where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? If your complaint is that TLS doesn't readily admit to reducing the level of security, I would argue that TLS is easy enough to implement in it entirety that that is an irrelevane argument, and that _less_ security isn't what the world needs right now. Besides, as John pointed out, it is possible to handle those cases. And, given the existence of open source TLS implementations, why would anyone bother to implement a totally new package that has less security? Paul ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Saturday, June 10, 2000 1:51 AM
> To: Paul Leach
> Cc: John Myers; Robert Zuccherato; = ietf-sasl@imc.org
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Paul,
>
> On Fri, 9 Jun 2000, Paul Leach wrote:
> >
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> > > Sent: Friday, June 09, 2000 3:04 = AM
> > >
> > > The TLS endpoint isn't always the same = as the application
> endpoint and
> > > that is the very reason for this = proposal. Maybe this should
> > > be made more explicit in the = draft.
> >
> > Why not? What stops any app that would use = the proposed new
> > authentication protocol from making the two = end points the same and
> > using TLS instead?
> >
> > In fact, nothing does.
>
> How about:
> A client uncapable of verifying certificates? A = situation
> where unilateral
> authentication is enough?  A client = uncapable of performing a full TLS
> handshake?

If your complaint is that TLS doesn't readily admit to = reducing the level of security, I would argue that TLS is easy enough to = implement in it entirety that that is an irrelevane argument, and that = _less_ security isn't what the world needs right now.

Besides, as John pointed out, it is possible to handle = those cases. And, given the existence of open source TLS = implementations, why would anyone bother to implement a totally new = package that has less security?

Paul

------_=_NextPart_001_01BFD32B.AA1D8DC2-- From owner-ietf-sasl Sun Jun 11 13:02:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA19334 for ietf-sasl-bks; Sun, 11 Jun 2000 13:02:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19330 for ; Sun, 11 Jun 2000 13:02:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5BK6Iw13792 for ; Sun, 11 Jun 2000 13:06:18 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW0AP900.VMG; Sun, 11 Jun 2000 13:10:21 -0700 Message-ID: <3943F14C.DD447F74@netscape.com> Date: Sun, 11 Jun 2000 13:06:39 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> <393FF694.4EEB1D21@amazon.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms21CF901E3143C20952D5E60F" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms21CF901E3143C20952D5E60F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Margrave wrote: > As long as major applications, like say LDAP or IMAP for example, are in love > with SASL [...] don't you think it's worthwhile to at least > go to the effort to add a modicum of real security to it? I mean, the only > SASL mech worth a darn security-wise at the moment is GSS-API. Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security. One cannot simply "add security" by throwing in cryptographic protocols wherever they are convenient. One has to form a threat model, devise security policies to address the modeled threats, and evaluate an implementation of those policies as a whole against said threats. To claim that SPNEGO adds "a modicum of real security" to SASL, one must show how the combination implements security policies to thwart which classes of threats. > I struggled > with this for a while, then realized that if both sides really want a secure > connection, then can simply decide they're only going to support one > SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few > extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, > everybody wins. If both sides are configured to only support GSS KRB5, then what threat does the addition of SPNEGO protect against? > So I would think that an SPNEGO SASL mech would be a good thing, because > well-designed implementations of application protocols could be configured to > only support one SASL mech (SPNEGO), so that we get real negotiation of a > security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around > it. Please address how a client supporting only Kerberos V5 underneath SPNEGO underneath SASL would interoperate with a server supporting only Kerberos V5 underneath SASL. --------------ms21CF901E3143C20952D5E60F 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMTIxMDYzOVowIwYJKoZIhvcNAQkEMRYEFECGK2rIFaYz gUHEOxvvx5s335cgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2Hn9VULwy420FZcuKsI6apbxImmNNecnjWzQ0stEBlWp0u6xfEv9PrpBOGz1S/1 aCfp1UkE+VRJf+AuX+p/oE0m2mUwn1e0TopGpW1cBOAQ6f6bGapmY1Hnt1B4eEcIpY6KHiN6 lbb3mtpU1qEC301cAKrznisXJrRWAPLi478= --------------ms21CF901E3143C20952D5E60F-- From owner-ietf-sasl Sun Jun 11 21:08:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA18555 for ietf-sasl-bks; Sun, 11 Jun 2000 21:08:39 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18551 for ; Sun, 11 Jun 2000 21:08:37 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5C47hh14236; Mon, 12 Jun 2000 00:07:43 -0400 (EDT) Message-Id: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Sun, 11 Jun 2000 13:06:39 PDT." <3943F14C.DD447F74@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> So I would think that an SPNEGO SASL mech would be a good thing, because >> well-designed implementations of application protocols could be configured to >> only support one SASL mech (SPNEGO), so that we get real negotiation of a >> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around >> it. > >Please address how a client supporting only Kerberos V5 underneath >SPNEGO underneath SASL would interoperate with a server supporting only >Kerberos V5 underneath SASL. You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. I am still undecided on this issue; maybe it is right to not recommend the use of SPNEGO with SASL, but I don't think this is a valid reason. --Ken From owner-ietf-sasl Mon Jun 12 10:23:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11719 for ietf-sasl-bks; Mon, 12 Jun 2000 10:23:47 -0700 (PDT) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11715 for ; Mon, 12 Jun 2000 10:23:46 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id NAA23410; Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Message-Id: <200006121723.NAA23410@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Cc: Ken Hornstein In-reply-to: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Subject: Re: SASL GSSAPI draft References: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein [...] You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition to SPNEGO, no additional security is obtained via SPNEGO (the active attacks that SPNEGO prevents are just circumvented by removing SPNEGO from the capabilities line). Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be used without advertising/allowing Krb5 without SPNEGO---which leads to the interoperability problems. Larry From owner-ietf-sasl Mon Jun 12 14:37:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA16450 for ietf-sasl-bks; Mon, 12 Jun 2000 14:37:56 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16446 for ; Mon, 12 Jun 2000 14:37:54 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5CLbHh21208; Mon, 12 Jun 2000 17:37:17 -0400 (EDT) Message-Id: <200006122137.e5CLbHh21208@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Mon, 12 Jun 2000 13:23:04 EDT." <200006121723.NAA23410@smtp3.andrew.cmu.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 17:37:16 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. I don't think this is a legitimate reason for > recommending against the use of SPNEGO. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition >to SPNEGO, no additional security is obtained via SPNEGO (the active >attacks that SPNEGO prevents are just circumvented by removing SPNEGO >from the capabilities line). That's true, with the current draft. But if GSSAPI simply means, "any GSSAPI mechanism", then there's no reason a non-SPNEGO client can't interoperate with a SPNEGO-aware server, without any loss of security that I can tell (since there wouldn't be any negotiation in the non-SPNEGO case). I was under the impression that "the interoperability problem" was given as a reason not to use SPNEGO; that's the only reason why I'm saying I don't think it's a valid reason. --Ken From owner-ietf-sasl Tue Jun 13 06:59:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19645 for ietf-sasl-bks; Tue, 13 Jun 2000 06:59:49 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19639 for ; Tue, 13 Jun 2000 06:59:47 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Jun 2000 13:54:30 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA10808; Tue, 13 Jun 2000 09:58:58 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 09:59:13 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: RE: SASL GSSAPI draft Date: Tue, 13 Jun 2000 09:59:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Properly, I think, the interoperability concern applies to the case where GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at the SASL level. If GSS mechanisms are exposed for negotiation at both the SPNEGO and SASL levels, this would provide the broadest degree of interoperability, supporting even those clients whose policies reject negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as a protected means to select among the available GSS mechanisms. If it's plausible for a client to have such a policy, even though it's interacting with a server which may also have clients having other policies, interoperability would be best served by allowing negotiation at both levels. One argument against SPNEGO under SASL (additionally to SASL-level exposure of the same GSS mechanism set) is that it adds complexity which would be superfluous in some situations; the (apparently modest) incremental complexity might be justified by the fact that it enables a protected negotiation which would be usefully and additionally secure in other situations. Generally, wrt SPNEGO support under SASL, we've seen arguments for both positions. Rather than the present SHOULD NOT (albeit with listed exception), would this be a good candidate for compromise on a MAY? --jl > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, June 12, 2000 5:37 PM > To: ietf-sasl@imc.org; ietf-cat-wg@lists.Stanford.EDU > Subject: Re: SASL GSSAPI draft > > > > You keep bringing up these mythical "only Kerberos V5 underneath > > SPNEGO" implementations. Even if you're doing SPNEGO, you still > > have to parse V5 GSSAPI tokens; I can't really imagine a reason > > why you would not be able to handle a V5 GSSAPI token exchange > > without SPNEGO. I don't think this is a legitimate reason for > > recommending against the use of SPNEGO. > > > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). > > I was under the impression that "the interoperability > problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. > > --Ken > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > From owner-ietf-sasl Wed Jun 14 23:38:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00690 for ietf-sasl-bks; Wed, 14 Jun 2000 23:38:04 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00684 for ; Wed, 14 Jun 2000 23:38:03 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5F6TY805835 for ; Wed, 14 Jun 2000 23:29:34 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW6NPU00.R18; Wed, 14 Jun 2000 23:37:06 -0700 Message-ID: <3948788D.62BADB48@netscape.com> Date: Wed, 14 Jun 2000 23:32:46 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms49DFB204291C59317B913E32" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms49DFB204291C59317B913E32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > As I read RFC 2478, > you always deal with the OID of the underlying mechanism, so I > don't think it's possible to support, for example, Kerberos "under" > SPNEGO without just supporting Kerberos If a server supports Kerberos underneath SPNEGO but rejects Kerberos GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is that server violating? --------------ms49DFB204291C59317B913E32 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNTA3MzI0NlowIwYJKoZIhvcNAQkEMRYEFAvLy+AgVmIp rC5DizLuBZHcLTotMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyFvbeL5fVgm+qdg3i5XFVNXelmM+GcE4+tO/RlxeE8wHXAy5Co1IT0BDmNEUvVHw jsxPy2CxPdTqU8hHXANxRX8w3qOSyogqn7aqhg+Dc2c2MjvERdx2WjOiQUaXvZYk6m2TV0M9 GWfuFZc3s7kTNRSvQn0UjswPyzQBbeNDU8k= --------------ms49DFB204291C59317B913E32-- From owner-ietf-sasl Fri Jun 16 14:59:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA24881 for ietf-sasl-bks; Fri, 16 Jun 2000 14:59:19 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24877 for ; Fri, 16 Jun 2000 14:59:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GLowW06866 for ; Fri, 16 Jun 2000 14:50:58 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9P1M00.RW5; Fri, 16 Jun 2000 14:58:34 -0700 Message-ID: <394AA301.D623264@netscape.com> Date: Fri, 16 Jun 2000 14:58:25 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: <3943F14C.DD447F74@netscape.com> <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEB93552D1CF51C9180CCE623" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msEB93552D1CF51C9180CCE623 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My apologies, I accidentally left the ietf-cat-wg list off the recipient list when I first sent this message: Ken Hornstein wrote: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Reportedly, the Microsoft Windows 2000 SSPI implementation only advertises the availability of the SPNEGO GSSAPI mechanism. A straightforward implementation of SASL on Windows 2000 would be unlikely to advertise or recognize GSSAPI SASL mechanisms other than the "GSS-SPNEGO" mechanism that was registered by Microsoft. > Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. Consider a SPNEGO client and a non-SPNEGO server. The server will be unable to parse the SPNEGO GSSAPI token that the client sends. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a client which supports more than one GSSAPI mechanism doesn't know which one to send to the server. If a client supports both Kerberos V5 and SPKM-1 and sees the server advertising "GSSAPI", which one should it send? Surely you don't intend for an IMAP client to take two round trips per GSSAPI mechanism in order to find out the server only supports the last mechanism the client tried? What do you mean there wouldn't be any negotiation in the non-SPNEGO case? There's always negotiation in SASL. A man in the middle can always make it look like either side doesn't support SPNEGO, so my "no additional security is obtained" statement still applies. > I was under the impression that "the interoperability problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. I'm sorry, I don't understand. What is the reason you're saying you don't think "the interoperability problem" is a valid reason? --------------msEB93552D1CF51C9180CCE623 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIxNTgyNlowIwYJKoZIhvcNAQkEMRYEFE+a6Q9ihQxB O+F6UJ8jdTqtj3TYMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAIxxg/ZeWaKZYQCD0GKZyUc3uTPdNH6m7OhkNn5roN4jY JUDRk6hjKptpJ0ANGk0H9Cb3uFif4QuVpPkH3SHF6mBOD36cY5BOXJrDE8DKXsQ5LTZrzPCP 1oszNNwWebfrhyIIERM2pIOgCEGZ+blhs2WIh4WKm4ZqLWGSsQLgbss= --------------msEB93552D1CF51C9180CCE623-- From owner-ietf-sasl Fri Jun 16 16:35:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA25849 for ietf-sasl-bks; Fri, 16 Jun 2000 16:35:34 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25845 for ; Fri, 16 Jun 2000 16:35:33 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GNRDW18851 for ; Fri, 16 Jun 2000 16:27:13 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9TI100.4BV; Fri, 16 Jun 2000 16:34:49 -0700 Message-ID: <394AB984.B4A401B@netscape.com> Date: Fri, 16 Jun 2000 16:34:28 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD28D6A4382055AF44DF9B865" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msD28D6A4382055AF44DF9B865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > Properly, I think, the interoperability concern applies to the case where > GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at > the SASL level. Agreed. There is also a problem case where the policy prefers a non-GSSAPI mechanism over a particular GSSAPI mechanism. One possible reasonable policy would be to first prefer Kerberos, then DIGEST-MD5, then GSS-API-Easy. If a server only supports DIGEST-MD5 and GSS-API-Easy, a client might through SPNEGO inadvertently use GSS-API-Easy instead of DIGEST-MD5. > If GSS mechanisms are exposed for negotiation at both the > SPNEGO and SASL levels, this would provide the broadest degree of > interoperability, supporting even those clients whose policies reject > negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as > a protected means to select among the available GSS mechanisms. One issue is whether or not it is a reasonable policy for the server to only accept certain weaker GSS mechanisms when their use has been negotiated through SPNEGO. If it is a reasonable policy, then the draft's current MUST wording about advertising the strongest GSS mechanism at the SASL layer is sufficient. If it is not a reasonable policy, then the requirement needs to be strengthened to say that all of the GSS mechanisms supported inside SPNEGO MUST also be advertised at the SASL layer. For SPNEGO to be useful, a client must not only have the policies you state, but must additionally support and have access to credentials for at least two GSS mechanisms. Steve Hole, who has implemented both Kerberos and SPKM, reports that in his experience any given client or server only has access to infrastructure for one GSS mechanism. I won't claim that it will never happen, but the set of policies and circumstances for which SPNEGO under SASL is necessary is rarely practical. > One argument against SPNEGO under SASL (additionally to SASL-level > exposure of the same GSS mechanism set) is that it adds complexity which > would be superfluous in some situations; the (apparently modest) incremental > complexity might be justified by the fact that it enables a protected > negotiation which would be usefully and additionally secure in other > situations. The incremental complexity of implementing SPNEGO is not necessarily modest. The SASL implementation I am currently working on and the CMU Cyrus SASL library both allow for SASL mechanism plug-ins. It would be relatively straightforward to create a SASL mechanism plug-in implementing Kerberos--that plug-in could then be loaded into any product implemented using the library. To support Kerberos underneath SPNEGO, either the SASL library would have to implement both GSSAPI and SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then have Kerberos plug-in to the GSSAPI plug-in. > Generally, wrt SPNEGO support under SASL, we've seen arguments for both > positions. Rather than the present SHOULD NOT (albeit with listed > exception), would this be a good candidate for compromise on a MAY? I am extremely worried about offering two different ways to do the same thing. When a protocol offers multiple ways to do something, it is not uncommon for an implementation to only test one of them. Even if only one way is a MUST IMPLEMENT, that is not necessarily the way that gets tested. If an implementation botches the MUST way and gains wide deployment due to some some other way working, the protocol effectively ends up with two or more MUST IMPLEMENTS. (This is a form of the "be liberal considered harmful" argument.) This is why I wrote this as a SHOULD NOT requirement with a listed exception. I am trying to get implementors to think about their customer's security requirements and only take on the complexity and risk of noninteroperation if the security policy and set of circumstances require. If we change the SHOULD NOT to a MAY, how else can we minimize the risk of clients and servers which only work with SPNEGO due to implementation laziness or error? --------------msD28D6A4382055AF44DF9B865 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIzMzQyOVowIwYJKoZIhvcNAQkEMRYEFGT8cS+9ZRsH E3rBzsldG2a09U6MMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGASRm4goDBlEYABRIS4f3sZ2hpDJdORlMR1vrOihSpMggv 3v3c/uCy7SneSyFdyeo2WdfI7ToT1pwt6xqQSfXehTK0EHeB1AXbd+puIfhMHsnNQ/gwfqkW SBeIiFmRjNSAgOxJRSGN+khFanFdjOnTfZBo3gMZPJXVtuN+LsEBDRk= --------------msD28D6A4382055AF44DF9B865-- From owner-ietf-sasl Fri Jun 16 20:15:06 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA28686 for ietf-sasl-bks; Fri, 16 Jun 2000 20:15:06 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28682 for ; Fri, 16 Jun 2000 20:15:04 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5H3Ec801945; Fri, 16 Jun 2000 23:14:39 -0400 (EDT) Message-Id: <200006170314.e5H3Ec801945@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Fri, 16 Jun 2000 14:58:25 PDT." <394AA301.D623264@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 16 Jun 2000 23:14:38 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> You keep bringing up these mythical "only Kerberos V5 underneath >> SPNEGO" implementations. > >Reportedly, the Microsoft Windows 2000 SSPI implementation only >advertises the availability of the SPNEGO GSSAPI mechanism. A >straightforward implementation of SASL on Windows 2000 would be unlikely >to advertise or recognize GSSAPI SASL mechanisms other than the >"GSS-SPNEGO" mechanism that was registered by Microsoft. Hm, back up here. Are we talking about advertisement at the SASL or GSSAPI level? I think I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI. I will say that when I telnetted to the SMTP server on a coworkers Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI", and I didn't see GSS-SPNEGO anywhere. Maybe that will change in the future. Everything I have seen from Microsoft has led me to believe that this server would accept a valid Kerberos 5 GSSAPI token (but I haven't actually tested it yet), _and_ it would accept a SPNEGO token. I actually thought that this interoperability has been tested by Microsoft, but I'd appreciate a correction. >> Even if you're doing SPNEGO, you still >> have to parse V5 GSSAPI tokens; I can't really imagine a reason >> why you would not be able to handle a V5 GSSAPI token exchange >> without SPNEGO. > >Consider a SPNEGO client and a non-SPNEGO server. The server will be >unable to parse the SPNEGO GSSAPI token that the client sends. I agree, this is a problem; I don't think I ever disagreed with that. >> That's true, with the current draft. But if GSSAPI simply means, "any >> GSSAPI mechanism", then there's no reason a non-SPNEGO client can't >> interoperate with a SPNEGO-aware server, without any loss of security >> that I can tell (since there wouldn't be any negotiation in the >> non-SPNEGO case). > >If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a >client which supports more than one GSSAPI mechanism doesn't know which >one to send to the server. No disagreement here. But ... it was my thinking that if you supported more than one mechanism, you'd really have to do SPNEGO (or your proposed draft). >What do you mean there wouldn't be any negotiation in the non-SPNEGO >case? There's always negotiation in SASL. A man in the middle can >always make it look like either side doesn't support SPNEGO, so my "no >additional security is obtained" statement still applies. My apologies; I should have been clearer. I meant, "there wouldn't be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5 only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism). But you're right; you still don't gain any security, because you can then simply remove GSSAPI from the supported mechanism line. My apologies. >> I was under the impression that "the interoperability problem" was given >> as a reason not to use SPNEGO; that's the only reason why I'm saying >> I don't think it's a valid reason. > >I'm sorry, I don't understand. What is the reason you're saying you >don't think "the interoperability problem" is a valid reason? It's been said a number of times that Kerberos 5-only GSSAPI implementations won't interoperate with GSSAPI implementations that support Kerberos 5 only under SPNEGO, and this is one of the reasons a seperate GSS-SPNEGO SASL mechanism is needed. It is my belief that there are no GSSAPI implementations that support SPNEGO which do not support GSS Kerberos 5, and furthermore there is no reason why you would ever _create_ such a GSSAPI implementation (number one: you'd lose interoperability with Kerberos 5 GSSAPI implementations on non-SASL protocols such as FTP). So I don't think that any such interoperability problem exists. (from another note) >If a server supports Kerberos underneath SPNEGO but rejects Kerberos >GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is >that server violating? None, as far as I can tell (that exists outside of the SPNEGO spec, as far as I can tell). But is there a reason why you would do such a thing? Please understand that I'm not raising an objection to your draft; I'm just trying to understand the reasoning better. --Ken From owner-ietf-sasl Tue Jun 6 08:50:05 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05976 for ietf-sasl-bks; Tue, 6 Jun 2000 08:50:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05972 for ; Tue, 6 Jun 2000 08:50:04 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13425 for ; Tue, 6 Jun 2000 08:58:18 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22630 for ; Tue, 6 Jun 2000 08:58:11 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27374 for ; Tue, 6 Jun 2000 08:56:32 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO37C@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Date: Tue, 06 Jun 2000 08:54:58 -0700 From: Chris Newman Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt To: Magnus Nystrom , ietf-sasl@imc.org Message-id: <1367452.3169270498@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom wrote: > FYI. Comments and feedback is welcome and solicited. I skimmed the document. I'm sorry I don't have time to chase down all the X.509/FIPS references necessary to grok the spec. (1) It seems to have far too many things marked "OPTIONAL". This makes the protocol more complex than necessary. Preferably the only OPTIONAL items should be the differences between one-way and mutual auth. RandomC certainly has no business being optional. (2) I don't understand the value of this if the client cert is optional. Doesn't that mean the server has to store the certs for every possible client in order to guarantee interoperability? Or am I missing something? (3) I presume this factors in the DNS name of the server which the client intends to communicate with -- usually the only information the client has about the server. Where can I read the rules for how that is used? Is that put in the EntityB field? Is the case where multiple physical servers answer for the same domain name considered? Is it possible for each physical server to have a different private key in that case? (4) I don't see a clear statement of how to determine the authorization identity (user to log in as, which may be different from the user whose private key is used). If this is buried somewhere in X.509 specs, please draw attention to it in the spec. (5) The reference to RFC 1738 should be updated to RFC 2396. (6) Is there a fast re-authentication option, or should TLS be used when that's needed? Note that many POP clients make a connection every 5 minutes to check mail, and some IMAP clients make a new connection every time a new folder is opened so a fast re-authentication protocol could be important for scalability. (7) Is there an open-source implementation of RFC 2459? If not, this seems much more complex than TLS where I can just grab OpenSSL and let it do all the work. (8) The IETF has a policy (the "Munich Mandate") which prohibits making patented algorithms mandatory to implement when there's and unpatented equivalent. I consider the recommendation to implement the RSA algorithm inappropriate given that policy. Since this is a set of mechanisms rather than a protocol, the recommendation is not necessary for interoperability so you could simply remove it. Alternatively you could change it to recommend DSA, or wait until after September 20th for standardization. - Chris From owner-ietf-sasl Tue Jun 6 08:49:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05944 for ietf-sasl-bks; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05940 for ; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13253 for ; Tue, 6 Jun 2000 08:58:01 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28012 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27362 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO279@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 21:51:30 -0700 From: Chris Newman Subject: RE: SASL GSSAPI draft In-reply-to: To: "Linn, John" , "'Ken Hornstein'" , jgmyers@netscape.com Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Message-id: <850698.3169230690@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" wrote: > It's certainly true that an SPNEGO token won't be usefully processable by > a target which doesn't support SPNEGO. If, however, a GSS implementation > can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that > GSS implementation is being used with SASL, it may not be too much > incremental effort to make GSS_MECH_A and GSS_MECH_B also available for > negotiation at the SASL level. There's a security vs. interoperability > tradeoff, since the SPNEGO negotiation is protected but the SASL > negotiation isn't. I'd suggest recommending, not discouraging, support > for SPNEGO for use where available and appropriate, but also recommending > configurable support to allow negotiation of individual GSS mechanisms at > the SASL level. Some problems with recommending SPNEGO in SASL: There are standards-compliant email servers deployed which only support Kerberos 5 (GSSAPI SASL) and don't support SPNEGO. Any email server which only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards track) for Kerberos 5 support is hostile both to the installed base of standards-compliant servers and to the deployment of Kerberos 5. If admins encounter an interop problem when trying to upgrade security, the first thing they usually do is back out the security upgrade. We don't want that to happen. I suspect the protection provided by SPNEGO will be irrelevant to most SASL-based protocols in practice because they'll get integrity protection from either TLS or IPsec prior to the SASL negotiation if they want it at all. So it just doesn't seem to be worth the extra round trip(s), IMHO. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if > none of the GSS mechanisms are available. If (1), the client is most > easily served by performing the negotiation (and exposing the individual > GSS mechanisms) at the SASL level. Given the prospect of (2), however, > it'd be good to be able to negotiate among the available GSS mechanisms > in an SPNEGO-protected manner. I'm very uncomfortable with options in security protocols. Every option can double the complexity of a security analysis of the software. I suspect that any benefit gained by making SPNEGO an option will be outweighed by the cost of a security analysis of both codepaths and the interaction between various security polices and SPNEGO/SASL mechanism lists. - Chris From owner-ietf-sasl Tue Jun 6 15:49:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15161 for ietf-sasl-bks; Tue, 6 Jun 2000 15:49:30 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15157 for ; Tue, 6 Jun 2000 15:49:29 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56MnuO13661 for ; Tue, 6 Jun 2000 15:49:56 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVR93C00.HR0; Tue, 6 Jun 2000 15:57:12 -0700 Message-ID: <393D812E.8D123B88@netscape.com> Date: Tue, 06 Jun 2000 15:54:38 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7A4108F79C32C4FD17956951" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7A4108F79C32C4FD17956951 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > Okay, I saw only a message from Bill Ricker asking about SPNEGO, > posting by you, and Paul Leach's reply. I recall some other exchange when I first published a draft, but haven't located it. It doesn't much matter, we're having a good discussion about this now. > Having said that .... I > think that a client that sent a SPNEGO token to a SPNEGO-unaware > server would fail. I have been thinking for a while on how to > migrate to clients & servers supporting SPNEGO, and I haven't come > up with any good ideas yet (if I'm missing something obvious, then > please let me know). I don't think you can make this work and maintain SPNEGO's security requirement to protect the negotiation of mechanism. A man in the middle could make it appear to each side that the other does not support SPNEGO, thus forcing a downgrade to the weakest mechanism. If you are willing to take this risk, forgoing this property of SPNEGO, then the propsal to negoitate the mechanism directly through SASL instead of through SPNEGO is simpler. > This presumes that the app will have to have special-case code to > determine which mechanisms exist and to apply policy information > to the mechanism list; I'm not sure how you'll do that without > giving the app knowledge of each mechanism, which would kinda defeat > part of the purpose of GSSAPI. I have a hard time imaging this done > in practice (it seems that you can give SPNEGO some policy constraints, > but it doesn't give you the ability to do the ordering you want). Typically, a SASL library has both policy constrants and a mechanism preference ordering. Usually the preferences are ordered from strongest mechanism to weakest, but sometimes the cost of obtaining a credential affects this. For example, if the SASL library has a Kerberos credential available, it may want to use Kerberos over any mechanism that will need to prompt the user. --------------ms7A4108F79C32C4FD17956951 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIyNTQzOVowIwYJKoZIhvcNAQkEMRYEFJFTsgpttt09 IoHjQ4t45VWOxQMlMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAYrx0vJLB5W0xTTs+3FYOyFqRMCSV8E/yQ15mr+XPU6XL F5ykhvMhCH2fIlKoSFrkdLzFCUKSg1hB/Ll26ZA/+ufPiViWbWE5CVDcm0K80vitFaB87wkN fhnUFr7ooXmIS2H8H7GpIMe4hhQlzWTyBigKVJ5BgSYAPDUoCJVgi6w= --------------ms7A4108F79C32C4FD17956951-- From owner-ietf-sasl Tue Jun 6 16:13:40 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA15383 for ietf-sasl-bks; Tue, 6 Jun 2000 16:13:40 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15378 for ; Tue, 6 Jun 2000 16:13:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NHPw08710 for ; Tue, 6 Jun 2000 16:17:25 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRA7O00.CTM; Tue, 6 Jun 2000 16:21:24 -0700 Message-ID: <393D876B.5DC135F2@netscape.com> Date: Tue, 06 Jun 2000 16:21:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn John" CC: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44C1D113AC5AE39E0F921503" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms44C1D113AC5AE39E0F921503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > There's a security vs. interoperability tradeoff, since the > SPNEGO negotiation is protected but the SASL negotiation isn't. The design criterion I've used in preparing the draft is that one should not trade away interoperability unless there exists a requirement in a site's security policy which is incompatible with that interoperability. > I'd suggest > recommending, not discouraging, support for SPNEGO for use where available > and appropriate, but also recommending configurable support to allow > negotiation of individual GSS mechanisms at the SASL level. The applicable requirement in the current draft is: In any case, there is no down-negotiation security consideration with using the strongest mechanism and set of options the implementation supports, so for interoperability that mechanism and set of options MUST be negotiable without using the "GSS-SPNEGO" mechanism. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if none > of the GSS mechanisms are available. If (1), the client is most easily > served by performing the negotiation (and exposing the individual GSS > mechanisms) at the SASL level. Given the prospect of (2), however, it'd be > good to be able to negotiate among the available GSS mechanisms in an > SPNEGO-protected manner. If your security policy allows the negotiation of a weak mechanism outside of SPNEGO, then what benefit are you gaining from SPNEGO? An active attacker can make it appear that SPNEGO is not suppported by the other side, removing all benefit of SPNEGO over SASL mechainsm negotiation. This is why I discourage rather than encourage SPNEGO underneath SASL. Unless you have a security policy of allowing certain mechanisms only when their negotiation has been protected, the SPNEGO negotiation protection doesn't buy you anything. This particular security policy is explicitly mentioned in the draft as a reason to violate the SHOULD NOT directive against SPNEGO under SASL. --------------ms44C1D113AC5AE39E0F921503 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIzMjExNlowIwYJKoZIhvcNAQkEMRYEFNVm9y3JzG4m ZTtkVAIIRPY2eYc6MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAmk9WHFo4eyYhkQ4ETuGpyANwwAcjbnn052pPoH0Ou4zD 4hFNvNZN9BSIjHnMMeMW4ZpkCeJQEAP9GFMpS3rIzZeoQXjQtRDUlOYvQbecH7rg9mDTybY+ q/3ASKEJM6yvcdChQQYg+Y29iCV2/J/r9pMhtdd4yTiLAHeQf+ITPwU= --------------ms44C1D113AC5AE39E0F921503-- From owner-ietf-sasl Tue Jun 6 16:55:47 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18711 for ietf-sasl-bks; Tue, 6 Jun 2000 16:55:47 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18704 for ; Tue, 6 Jun 2000 16:55:45 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NuFO22674 for ; Tue, 6 Jun 2000 16:56:15 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRC5W00.JX4 for ; Tue, 6 Jun 2000 17:03:32 -0700 Message-ID: <393D914B.3FEBD002@netscape.com> Date: Tue, 06 Jun 2000 17:03:23 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5EBBBA0BCDF14825170DA5B8" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms5EBBBA0BCDF14825170DA5B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I second Chris Newman's comments, though I think that if this is intended for standardization then waiting for September 20 is better than switching to DSA. I'd appreciate it if you could expand on why you want to do this as a SASL mechanism instead of using a combination of TLS and the EXTERNAL SASL mechanism. My experience with implementing this stuff is that the key and certificate management aspects are far harder to implement than the protocol aspects. Each of the important protocols has an extension to start a TLS negotiation on a previously unprotected connection. At the latest MailConnect, there were quite a few implementations of these STARTTLS extensions. Only three of these companies supported client certs, this was up from one company the previous year. A product implementing only this draft will not interoperate with a product implementing only the combination of TLS and EXTERNAL. TLS does appear to have won the X.509 space and is gaining implementation momentum. I think this draft is approaching the wrong problem. --------------ms5EBBBA0BCDF14825170DA5B8 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNzAwMDMyNFowIwYJKoZIhvcNAQkEMRYEFOQ2w36fvM1N 2obU4EoevVUWtmq2MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGALFHw1flmrJp1XESJfKEAZEDOmtGVf+9ws0puzDd2klV6 8Zy3+QCN4qBnhZfn8Mm7GkGEeLD6oWbbu4lGWncNSWciZgOcTxVtEoufQcCDCMiB66Qh3NiS TCEu/BtFN1kHJAkxRAZg0o4omsIi23hN1K+nEE3U70HOhaz+PEFXy/0= --------------ms5EBBBA0BCDF14825170DA5B8-- From owner-ietf-sasl Tue Jun 6 19:01:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA04731 for ietf-sasl-bks; Tue, 6 Jun 2000 19:01:38 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA04721 for ; Tue, 6 Jun 2000 19:01:36 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 18:45:50 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 18:45:53 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD021.244B91F6" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Tue, 6 Jun 2000 18:38:55 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EB8@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QE4de/K5YKnZcShqLBlUQP9UeSAACYjog From: "Paul Leach" To: "John Myers" , X-OriginalArrivalTime: 07 Jun 2000 01:45:53.0859 (UTC) FILETIME=[1DE3B130:01BFD022] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: John Myers [mailto:jgmyers@netscape.com] > Sent: Tuesday, June 06, 2000 5:03 PM > To: ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > TLS does > appear to have won the X.509 space and is gaining implementation > momentum. I think this draft is approaching the wrong problem. I concur completely. Paul ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: John Myers [mailto:jgmyers@netscape.com]
> Sent: Tuesday, June 06, 2000 5:03 PM
> To: ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>  TLS does
> appear to have won the X.509 space and is = gaining implementation
> momentum.  I think this draft is = approaching the wrong problem.

I concur completely.

Paul

------_=_NextPart_001_01BFD021.244B91F6-- From owner-ietf-sasl Wed Jun 7 10:17:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11530 for ietf-sasl-bks; Wed, 7 Jun 2000 10:17:24 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11524 for ; Wed, 7 Jun 2000 10:17:21 -0700 (PDT) Received: (qmail 22791 invoked from network); 7 Jun 2000 17:25:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:25:40 -0000 Received: (qmail 19734 invoked by uid 1183); 7 Jun 2000 17:25:57 -0000 Date: Wed, 7 Jun 2000 19:25:57 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul and John, Thanks for your views. However, IMHO, TLS is not always suitable, for several reasons. Among them are: -(partially quoting from a posting by P. Fahn, Certicom, sent to another list:) Many network architectures today have "untrusted" middlemen (gateways, proxies, translators, formatters, and it is not unlikely that architectures like this will increase in numbers. The end users and content providers and application developers should be able to put in security on top of all the middlemen, at the application layer. And middlemen want the same thing to avoid the liability that comes with seeing all the plaintext. Since one will not always have simple two-party network topologies, simple transport-layer channel security will not always be enough. -As mentioned in the draft, TLS is more complex and does not carry the concept of separate authentication and authorization identities. Regards, -- Magnus On Tue, 6 Jun 2000, Paul Leach wrote: > > -----Original Message----- > > From: John Myers [mailto:jgmyers@netscape.com] > > Sent: Tuesday, June 06, 2000 5:03 PM > > To: ietf-sasl@imc.org > > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > TLS does appear to have won the X.509 space and is gaining > > implementation momentum. I think this draft is approaching the > > wrong problem. > > I concur completely. > > Paul From owner-ietf-sasl Wed Jun 7 10:21:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11657 for ietf-sasl-bks; Wed, 7 Jun 2000 10:21:13 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11653 for ; Wed, 7 Jun 2000 10:21:11 -0700 (PDT) Received: (qmail 22849 invoked from network); 7 Jun 2000 17:29:31 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:29:31 -0000 Received: (qmail 19949 invoked by uid 1183); 7 Jun 2000 17:29:48 -0000 Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, Many thanks for your comments and suggestions for improvements. My response below. On Tue, 6 Jun 2000, Chris Newman wrote: > --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom > wrote: > > FYI. Comments and feedback is welcome and solicited. > > I skimmed the document. I'm sorry I don't have time to chase down all the > X.509/FIPS references necessary to grok the spec. > > (1) It seems to have far too many things marked "OPTIONAL". This makes the > protocol more complex than necessary. Preferably the only OPTIONAL items > should be the differences between one-way and mutual auth. RandomC > certainly has no business being optional. Right, we will change this in the next draft. > (2) I don't understand the value of this if the client cert is optional. > Doesn't that mean the server has to store the certs for every possible > client in order to guarantee interoperability? Or am I missing something? Yes, client CertData should probably be mandatory. > (3) I presume this factors in the DNS name of the server which the client > intends to communicate with -- usually the only information the client has > about the server. Where can I read the rules for how that is used? Is > that put in the EntityB field? Is the case where multiple physical servers > answer for the same domain name considered? Is it possible for each > physical server to have a different private key in that case? Yes it is. Only requirement is that the server is able to see that the client intended to communicate with it - if, e.g., there is a round-robin DNS, then for all intent and purposes involved servers are the same (from the client's perspective). It could be that the DNS name is a SHOULD (or even a MUST?). > (4) I don't see a clear statement of how to determine the authorization > identity (user to log in as, which may be different from the user whose > private key is used). If this is buried somewhere in X.509 specs, please > draw attention to it in the spec. Correct, thanks for the observation. There should be an explicit, but optional, authorization id included. If not included, the server will have to use the authenticated id. > (5) The reference to RFC 1738 should be updated to RFC 2396. Right. > (6) Is there a fast re-authentication option, or should TLS be used when > that's needed? Note that many POP clients make a connection every 5 > minutes to check mail, and some IMAP clients make a new connection every > time a new folder is opened so a fast re-authentication protocol could be > important for scalability. No, there is no fast re-authentication option. One could add one (for example by letting the entities negotiate a session secret) but it is our feeling that this would complicate the mechanism unnecessarily. > (7) Is there an open-source implementation of RFC 2459? If not, this seems > much more complex than TLS where I can just grab OpenSSL and let it do all > the work. Certificate-handling open-source is certainly available,e.g. as part of OpenSSL, and ssleay, but the Jonah PKIX freeware library is another alternative, I guess. > (8) The IETF has a policy (the "Munich Mandate") which prohibits making > patented algorithms mandatory to implement when there's and unpatented > equivalent. I consider the recommendation to implement the RSA algorithm > inappropriate given that policy. Since this is a set of mechanisms rather > than a protocol, the recommendation is not necessary for interoperability > so you could simply remove it. Alternatively you could change it to > recommend DSA, or wait until after September 20th for standardization. Right, the latter was (and is) our intent. Thanks, -- Magnus From owner-ietf-sasl Wed Jun 7 18:18:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28339 for ietf-sasl-bks; Wed, 7 Jun 2000 18:18:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28327 for ; Wed, 7 Jun 2000 18:18:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e581MAw02792 for ; Wed, 7 Jun 2000 18:22:10 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTANN00.SZ5 for ; Wed, 7 Jun 2000 18:26:11 -0700 Message-ID: <393EF62D.90D04494@netscape.com> Date: Wed, 07 Jun 2000 18:26:05 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDBB2633BB5C5E1273A580AC7" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msDBB2633BB5C5E1273A580AC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. --------------msDBB2633BB5C5E1273A580AC7 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAxMjYwNlowIwYJKoZIhvcNAQkEMRYEFNLKjvs652s1 3hpbQ538rPu1D4gFMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAvfFI/2UTzJneXp+zjtV7J/OaBzCnOpXj4nnMVel1FKtp PMVFH+xY7+uOSpMd+//MIz52ZxEDjTRnPydmdzbIuyPp/cqvMEWfMSXcY9ew20iU2+Alhvfn dkxVFQVhHyHZQaD5PEzR2utRl1yZ+I2N1oAlgljteehtHUn68LxnuhU= --------------msDBB2633BB5C5E1273A580AC7-- From owner-ietf-sasl Wed Jun 7 18:42:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03460 for ietf-sasl-bks; Wed, 7 Jun 2000 18:42:39 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03456 for ; Wed, 7 Jun 2000 18:42:37 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 11:53:37 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 11:54:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I must have blinked. I thought the statement at issue was that TLS is a good poit-to-point solution but that it can't be used where middle-men are involved (DMZs, for example). In particular, SASL/EXTERNAL cannot be used. I don't believe TLS is a session layer protocol, either. Its purpose and implementation are as a network layer look-alike. Wherever TCP is found, TLS may be shimmed in. So, it provides neither transport nor session services. I also can't understand references to SASL services and then proposing to use TLS without client certificates. Even if SASL/EXTERNAL could be used, it would be useless without client certificates. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 11:26 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. From owner-ietf-sasl Wed Jun 7 19:15:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA07811 for ietf-sasl-bks; Wed, 7 Jun 2000 19:15:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07806 for ; Wed, 7 Jun 2000 19:15:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e582FqO27378 for ; Wed, 7 Jun 2000 19:15:52 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTDAO00.43B for ; Wed, 7 Jun 2000 19:23:12 -0700 Message-ID: <393F0386.999E2B34@netscape.com> Date: Wed, 07 Jun 2000 19:23:02 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B5289C8F322EAB542625529" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4B5289C8F322EAB542625529 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. --------------ms4B5289C8F322EAB542625529 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAyMjMwM1owIwYJKoZIhvcNAQkEMRYEFMiF+TX6lseM ob/o6bout1yKNb3jMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAV73BHMxgBYKU97UJf3JKIsXOTz6EuGEqSii/u38gpKSB 2K+qNF6dfOR+0BYAZHkmapbGZ4ounLf26zJzP+SVeopndZmC1B7RvBD24o2/Y4DAp7aL7GAx UEvbxMHs9b1Bduw8mBGFMXxLW1o5ulzQRtgir+ADM5YaQk6Gepcqj48= --------------ms4B5289C8F322EAB542625529-- From owner-ietf-sasl Wed Jun 7 19:43:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12202 for ietf-sasl-bks; Wed, 7 Jun 2000 19:43:59 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12197 for ; Wed, 7 Jun 2000 19:43:55 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 12:54:56 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 12:56:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An example. We are going to attempt an authenticated logon through a DMZ. Therefore, we have my host, HostA, the DMZ host, HostB, and the destination host, HostC. I connect to HostB (thinking that it is HostC, if I understand how a DMZ works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, so I send my client certificate. The connection is established. I logon, specifying SASL/EXTERNAL. HostB receives the logon and passes it to HostC. HostC does not have my client certificate and rejects the logon. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 12:23 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. From owner-ietf-sasl Wed Jun 7 19:56:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13917 for ietf-sasl-bks; Wed, 7 Jun 2000 19:56:14 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13906 for ; Wed, 7 Jun 2000 19:56:13 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA19901; Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Message-Id: <200006080304.XAA19901@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org Cc: John Gardiner Myers In-reply-to: <393EF62D.90D04494@netscape.com> Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: <393EF62D.90D04494@netscape.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry From owner-ietf-sasl Wed Jun 7 20:16:08 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA16280 for ietf-sasl-bks; Wed, 7 Jun 2000 20:16:08 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16276 for ; Wed, 7 Jun 2000 20:16:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e583Jxw13107 for ; Wed, 7 Jun 2000 20:19:59 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTG3Z00.RX6 for ; Wed, 7 Jun 2000 20:23:59 -0700 Message-ID: <393F1110.3519635F@netscape.com> Date: Wed, 07 Jun 2000 20:20:50 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms950CC6E5C461642C245C16E9" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms950CC6E5C461642C245C16E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. --------------ms950CC6E5C461642C245C16E9 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA0MjA1MFowIwYJKoZIhvcNAQkEMRYEFFrxOtQjML9w BiJMIEgrxTXT4NdeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAShVpt1Osg2dAgbR7knhyk1wcSCDNoMDdAy/23Z9UcRpyYrnb/m1HjikgfNFH671P lwbkbwCEu8+tD7UUR8C1IT9OXHXq+3617HL2TUin1biSUvq5g1CYQNAuiaN2nVQQmaBSpuaP 0VsOQPNScZ2GfBAa3vFuDpo/BS9qLGrLD7A= --------------ms950CC6E5C461642C245C16E9-- From owner-ietf-sasl Wed Jun 7 21:07:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20750 for ietf-sasl-bks; Wed, 7 Jun 2000 21:07:05 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20746 for ; Wed, 7 Jun 2000 21:07:02 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:18:03 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:19:15 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But then you are NOT using SASL/EXTERNAL because HostC is simply validating HostB and not HostA! For example, if we were using X.509 authentication, the certification path and token would actually travel end-to-end and HostC would indeed receive credentials from HostA. This really IS an application protocol. What you are talking about is a link protocol. Your remarks about TLS being a session or application protocol are simply wrong. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 13:21 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. From owner-ietf-sasl Wed Jun 7 21:23:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA21074 for ietf-sasl-bks; Wed, 7 Jun 2000 21:23:53 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21065 for ; Wed, 7 Jun 2000 21:23:50 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:34:51 +1000 Message-ID: From: "Ramsay, Ron" To: Lawrence Greenfield , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:36:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry, I'm fascinated by [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" Can I substitute: S: "Authentication failed. Try PLAIN"? Ron. -----Original Message----- From: Lawrence Greenfield [mailto:leg+@andrew.cmu.edu] Sent: Thursday, 8 June 2000 13:05 To: ietf-sasl@imc.org Cc: John Gardiner Myers Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry From owner-ietf-sasl Wed Jun 7 21:50:32 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA25424 for ietf-sasl-bks; Wed, 7 Jun 2000 21:50:32 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25417 for ; Wed, 7 Jun 2000 21:50:31 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e584sOw19763 for ; Wed, 7 Jun 2000 21:54:24 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTKHB00.00E for ; Wed, 7 Jun 2000 21:58:23 -0700 Message-ID: <393F2732.ADB491F3@netscape.com> Date: Wed, 07 Jun 2000 21:55:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms878058F0A2C4ADC712311B67" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms878058F0A2C4ADC712311B67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > HostB and not HostA! In the example I provided in my last message, I am using EXTERNAL between HostA and HostB. Any SASL mechanism, including EXTERNAL, that supports an authorization id field can be used between HostB and HostC. This is analogous to the example you provided, since that example showed a TLS security association being established between HostA and HostB. > For example, if we were using X.509 authentication, the certification path > and token would actually travel end-to-end and HostC would indeed receive > credentials from HostA. If you instead want to establish a security association between HostA and HostC, then HostB should forward the TLS records through between HostA and HostC. > This really IS an application protocol. What you are talking about is a link > protocol. Your remarks about TLS being a session or application protocol are > simply wrong. I'm sorry, I don't see the argument behind these assertions. What difference between TLS and SASL makes TLS a "link" protocol as opposed to an "application" protocol? In your HostA, HostB, HostC situation, how would you handle a SASL negotiation using a mechanism that provides perfect forward secrecy of the identity being authenticated? --------------ms878058F0A2C4ADC712311B67 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA1NTUxNVowIwYJKoZIhvcNAQkEMRYEFGsWQc0PMKXP NDc6eeuaFQLO1pJaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAKVyPxEv0/RGmrO71WAzwBy4i3rUetOPVSjXBvsHmAdb2mbQeM+xryFua7XDnHUh0 mEimCMfSzqGC5g1CxbjfOK3cXnDvokvP/T18gj7KpGOQ4xK24yNnkVrKr9s2IqSlX6L3VrFD vMCwB5EcVfs2NwhK2nlKjltHHTn+5yJoG3A= --------------ms878058F0A2C4ADC712311B67-- From owner-ietf-sasl Wed Jun 7 22:46:35 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29884 for ietf-sasl-bks; Wed, 7 Jun 2000 22:46:35 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29880 for ; Wed, 7 Jun 2000 22:46:34 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e585l8O11218 for ; Wed, 7 Jun 2000 22:47:08 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTN2Q00.9YN for ; Wed, 7 Jun 2000 22:54:26 -0700 Message-ID: <393F3454.564F543D@netscape.com> Date: Wed, 07 Jun 2000 22:51:18 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms81E3B4AA457C0A57A98237DE" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms81E3B4AA457C0A57A98237DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > Can I substitute: > > S: "Authentication failed. Try PLAIN"? Sure. You can even do this as soon as the client sends: C: a AUTHENTICATE "TLS" or even replace all the SASL mechanisms in the banner with just PLAIN. Or you can replace legitimate TLS records with TLS fatal alerts. Protocol spoofers can do all sorts of interesting things if the endpoints have a sufficiently lax security policy. Which brings up an interesting point about the draft. There's no point having the mechanism support mutual authentication because the mechanism doesn't support any security layers. It's useless for the server to prove its identity to the client since the moment the SASL negotiation is over either side could be talking to anybody. --------------ms81E3B4AA457C0A57A98237DE 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA2NTExOFowIwYJKoZIhvcNAQkEMRYEFEmf6VjK05/s TrX6SJpjrIiSHdHHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAAQLP/ptLQO7JQ25oHE/YHur79/vuU+yuONglhRK/8ZM75cEEi0IF6sIOP/VlUs8Z YeWEMbt2/PNzKG+8v8znJIIECNWLSkCDdmU5FdiRgB2a4qiJiy74QYksm8yGrKjtnTErf9ey rtRaDJ5yc6/P7SqLilaVNuwPJ+e66tJEdGU= --------------ms81E3B4AA457C0A57A98237DE-- From owner-ietf-sasl Thu Jun 8 10:27:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03210 for ietf-sasl-bks; Thu, 8 Jun 2000 10:27:19 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03205 for ; Thu, 8 Jun 2000 10:27:16 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 10:19:13 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 8 Jun 2000 10:25:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD16C.7CC39E72" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Thu, 8 Jun 2000 10:10:46 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QpOmxZOqfIAyMRzCjRDN/0Aj3YQAyCxTA From: "Paul Leach" To: "Magnus Nystrom" , Cc: X-OriginalArrivalTime: 08 Jun 2000 17:25:08.0436 (UTC) FILETIME=[7E3F7940:01BFD16E] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Wednesday, June 07, 2000 10:26 AM > To: ietf-sasl@imc.org > Cc: robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Dear Paul and John, >=20 > Thanks for your views. However, IMHO, TLS is not always suitable, for > several reasons. Among them are: >=20 > -(partially quoting from a posting by P. Fahn, Certicom, sent to > another list:) Many network architectures today have > "untrusted" middlemen (gateways, proxies, translators,=20 > formatters, Allowing an "untrusted" middleman to translate or re-format information flowing through it smacks of a recipe for disaster. Surely you mis-speak. Paul ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Wednesday, June 07, 2000 10:26 AM
> To: ietf-sasl@imc.org
> Cc: robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Dear Paul and John,
>
> Thanks for your views. However, IMHO, TLS is not = always suitable, for
> several reasons. Among them are:
>
> -(partially quoting from a posting by P. Fahn, = Certicom, sent to
>  another list:) Many network architectures = today have
>  "untrusted" middlemen (gateways, = proxies, translators,
> formatters,

Allowing an "untrusted" middleman to = translate or re-format information flowing through it smacks of a recipe = for disaster. Surely you mis-speak.

Paul

------_=_NextPart_001_01BFD16C.7CC39E72-- From owner-ietf-sasl Thu Jun 8 12:34:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05481 for ietf-sasl-bks; Thu, 8 Jun 2000 12:34:59 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05476 for ; Thu, 8 Jun 2000 12:34:57 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 456E465F; Thu, 8 Jun 2000 12:43:24 -0700 (PDT) Received: by mail-proxy-2.amazon.com id MAA09585; Thu, 8 Jun 2000 12:43:23 -0700 (PDT) Message-ID: <393FF694.4EEB1D21@amazon.com> Date: Thu, 08 Jun 2000 12:40:04 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Myers Cc: Linn John , "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Myers wrote: > > This is why I discourage rather than encourage SPNEGO underneath SASL. > Unless you have a security policy of allowing certain mechanisms only > when their negotiation has been protected, the SPNEGO negotiation > protection doesn't buy you anything. This particular security policy is > explicitly mentioned in the draft as a reason to violate the SHOULD NOT > directive against SPNEGO under SASL. As long as major applications, like say LDAP or IMAP for example, are in love with SASL (Honestly, do you blame them? Good grief, look at the prototype for gss_init_sec_context() some time!), don't you think it's worthwhile to at least go to the effort to add a modicum of real security to it? I mean, the only SASL mech worth a darn security-wise at the moment is GSS-API. I struggled with this for a while, then realized that if both sides really want a secure connection, then can simply decide they're only going to support one SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, everybody wins. So I would think that an SPNEGO SASL mech would be a good thing, because well-designed implementations of application protocols could be configured to only support one SASL mech (SPNEGO), so that we get real negotiation of a security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around it. Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords" that you would want to avoid by policy configuration. I believe that the best we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so that SASL (which isn't going away) will support SPNEGO as an available option in the vast majority of implementations. Dave From owner-ietf-sasl Fri Jun 9 02:42:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00469 for ietf-sasl-bks; Fri, 9 Jun 2000 02:42:30 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA00465 for ; Fri, 9 Jun 2000 02:42:27 -0700 (PDT) Received: (qmail 46938 invoked from network); 9 Jun 2000 09:50:54 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 09:50:54 -0000 Received: (qmail 2908 invoked from network); 9 Jun 2000 09:51:11 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 09:51:11 -0000 Date: Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: Paul Leach cc: ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security From owner-ietf-sasl Fri Jun 9 02:56:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01404 for ietf-sasl-bks; Fri, 9 Jun 2000 02:56:42 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01400 for ; Fri, 9 Jun 2000 02:56:40 -0700 (PDT) Received: (qmail 47102 invoked from network); 9 Jun 2000 10:05:09 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 10:05:09 -0000 Received: (qmail 3519 invoked from network); 9 Jun 2000 10:05:26 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 10:05:26 -0000 Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: John Myers cc: Robert Zuccherato , ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <393F2732.ADB491F3@netscape.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear John, On Wed, 7 Jun 2000, John Myers wrote: > "Ramsay, Ron" wrote: > > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > > HostB and not HostA! > > In the example I provided in my last message, I am using EXTERNAL > between HostA and HostB. Any SASL mechanism, including EXTERNAL, that > supports an authorization id field can be used between HostB and HostC. > > This is analogous to the example you provided, since that example showed > a TLS security association being established between HostA and HostB. > > > For example, if we were using X.509 authentication, the certification path > > and token would actually travel end-to-end and HostC would indeed receive > > credentials from HostA. > > If you instead want to establish a security association between HostA > and HostC, then HostB should forward the TLS records through between > HostA and HostC. The TLS endpoint isn't always the same as the application endpoint and that is the very reason for this proposal. Maybe this should be made more explicit in the draft. > > This really IS an application protocol. What you are talking about is a link > > protocol. Your remarks about TLS being a session or application protocol are > > simply wrong. > > I'm sorry, I don't see the argument behind these assertions. What > difference between TLS and SASL makes TLS a "link" protocol as opposed > to an "application" protocol? IMHO, since it is possible to "insert" SASL in many higher-level protocols it is a useful mechanism when, for one reason or another, lower level protocols (I include TLS here) terminates at a gateway or similar, or the application using the SASL-enabled protocol is unable to run TLS for one reason or another, but is still capable of doing public-key operations. > In your HostA, HostB, HostC situation, how would you handle a SASL > negotiation using a mechanism that provides perfect forward secrecy of > the identity being authenticated? Just so we are talking about the same thing here: Perfect forward secrecy = Disclosing one key/authentication does not give an attacker the possibility to reuse that information in subsequent exchanges. The proposed protocol is vulnerable to session hi-jacking, this fact is also mentioned in the draft, and true also for other SASL mechanisms not inserting a security layer. -- Magnus From owner-ietf-sasl Fri Jun 9 03:07:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02566 for ietf-sasl-bks; Fri, 9 Jun 2000 03:07:53 -0700 (PDT) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02558 for ; Fri, 9 Jun 2000 03:07:51 -0700 (PDT) Received: from 209-6-126-154.c4-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([209.6.126.154] helo=PIXIE) by smtp03.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 130Lps-0004aD-00; Fri, 9 Jun 2000 06:16:20 -0400 Message-ID: <01ca01bfd1fb$07f9c870$9a7e06d1@aa.net> From: "Scott Guthery" To: "Magnus Nystrom" , "Paul Leach" Cc: , References: Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Fri, 9 Jun 2000 06:11:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: WAP, for example. Cheers, Scott ----- Original Message ----- From: Magnus Nystrom To: Paul Leach Cc: ; Sent: Friday, June 09, 2000 5:50 AM Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security From owner-ietf-sasl Fri Jun 9 05:05:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10792 for ietf-sasl-bks; Fri, 9 Jun 2000 05:05:49 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10787 for ; Fri, 9 Jun 2000 05:05:47 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA16307; Fri, 9 Jun 2000 08:14:05 -0400 (EDT) Date: Fri, 9 Jun 2000 8:14:05 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems to me that the fact that you have untrusted middlemen is even more reason why you would use TLS. You do not trust them, therefore you must protect your data end to end. You allow the middlemen to proxy, translate, ... the connection and then you perform an end to end authentication and encryption. > > Dear Paul, > > No, I am not mis-speaking. There are in fact architectures like this. > > -- Magnus > > On Thu, 8 Jun 2000, Paul Leach wrote: > > > > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Wednesday, June 07, 2000 10:26 AM > > > To: ietf-sasl@imc.org > > > Cc: robert.zuccherato@entrust.com > > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > > > > Dear Paul and John, > > > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > > several reasons. Among them are: > > > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > > another list:) Many network architectures today have > > > "untrusted" middlemen (gateways, proxies, translators, > > > formatters, > > > > Allowing an "untrusted" middleman to translate or re-format information > > flowing through it smacks of a recipe for disaster. Surely you > > mis-speak. > > > > Paul > > > > -- Magnus > Magnus Nystrom Email: magnus@rsasecurity.com > RSA Security > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org From owner-ietf-sasl Fri Jun 9 08:11:45 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA22310 for ietf-sasl-bks; Fri, 9 Jun 2000 08:11:45 -0700 (PDT) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22300 for ; Fri, 9 Jun 2000 08:11:42 -0700 (PDT) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA12479; Fri, 9 Jun 2000 08:20:12 -0700 (PDT) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA06713 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by networking.Stanford.EDU (8.8.6/8.8.5) with ESMTP id MAA11365 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA24850 for rfc-dist-outgoing; Thu, 8 Jun 2000 11:06:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24843 for ; Thu, 8 Jun 2000 11:06:56 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA18853; Thu, 8 Jun 2000 11:07:36 -0700 (PDT) Message-Id: <200006081807.LAA18853@boreas.isi.edu> To: rfc-dist@isi.edu Subject: RFC 2831 on Digest SASL Mechanism Cc: rfc-ed@isi.edu Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:07:36 -0700 From: RFC Editor Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2831 Title: Using Digest Authentication as a SASL Mechanism Author(s): P. Leach, C. Newman Status: Standards Track Date: May 2000 Mailbox: paulle@microsoft.com, chris.newman@innosoft.com Pages: 27 Characters: 58124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-leach-digest-sasl-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2831.txt This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2831 --OtherAccess Content-Type: Message/External-body; name="rfc2831.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-sasl Fri Jun 9 09:33:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01240 for ietf-sasl-bks; Fri, 9 Jun 2000 09:33:21 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01236 for ; Fri, 9 Jun 2000 09:33:20 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 09:20:58 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 09:29:20 -0700 content-class: urn:content-classes:message Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD22E.E0481654" X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 09:22:16 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90ED1@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R92LwGXCMHD7ASm6QmOzF6UyG7QAN883g From: "Paul Leach" To: "Magnus Nystrom" Cc: , X-OriginalArrivalTime: 09 Jun 2000 16:29:20.0300 (UTC) FILETIME=[DD0436C0:01BFD22F] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 2:50 AM > To: Paul Leach > Cc: ietf-sasl@imc.org; robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 >=20 > Dear Paul, >=20 > No, I am not mis-speaking. There are in fact architectures like this. >=20 > -- Magnus >=20 Well, then they are deliberately allowing untrusted parties, _including malicious ones, against whom the proposal offers no protection_, to access their communications. They don't need authentication at all, in which case. Paul ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 2:50 AM
> To: Paul Leach
> Cc: ietf-sasl@imc.org; = robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>
> Dear Paul,
>
> No, I am not mis-speaking. There are in fact = architectures like this.
>
> -- Magnus
>

Well, then they are deliberately allowing untrusted = parties, _including malicious ones, against whom the proposal offers no = protection_, to access their communications. They don't need = authentication at all, in which case.

Paul

------_=_NextPart_001_01BFD22E.E0481654-- From owner-ietf-sasl Fri Jun 9 14:36:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07932 for ietf-sasl-bks; Fri, 9 Jun 2000 14:36:24 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07928 for ; Fri, 9 Jun 2000 14:36:23 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 13:13:41 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 13:21:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD24F.602B0186" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 13:14:54 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R+YJYd8yoMufhR/CtpyI5/ApCngAVi8OA From: "Paul Leach" To: "Magnus Nystrom" , "John Myers" Cc: "Robert Zuccherato" , X-OriginalArrivalTime: 09 Jun 2000 20:21:58.0987 (UTC) FILETIME=[5D0AD1B0:01BFD250] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 3:04 AM > To: John Myers > Cc: Robert Zuccherato; ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should=20 > be made more > explicit in the draft. Why not? What stops any app that would use the proposed new authentication protocol from making the two end points the same and using TLS instead? In fact, nothing does. Paul ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 3:04 AM
> To: John Myers
> Cc: Robert Zuccherato; ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>

> The TLS endpoint isn't always the same as the = application endpoint and
> that is the very reason for this proposal. Maybe = this should
> be made more
> explicit in the draft.

Why not? What stops any app that would use the = proposed new authentication protocol from making the two end points the = same and using TLS instead?

In fact, nothing does.

Paul

------_=_NextPart_001_01BFD24F.602B0186-- From owner-ietf-sasl Sat Jun 10 01:42:26 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18413 for ietf-sasl-bks; Sat, 10 Jun 2000 01:42:26 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA18409 for ; Sat, 10 Jun 2000 01:42:23 -0700 (PDT) Received: (qmail 62027 invoked from network); 10 Jun 2000 08:50:52 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 10 Jun 2000 08:50:52 -0000 Received: (qmail 17246 invoked by uid 1183); 10 Jun 2000 08:51:09 -0000 Date: Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: Paul Leach cc: John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, On Fri, 9 Jun 2000, Paul Leach wrote: > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Friday, June 09, 2000 3:04 AM > > > > The TLS endpoint isn't always the same as the application endpoint and > > that is the very reason for this proposal. Maybe this should > > be made more explicit in the draft. > > Why not? What stops any app that would use the proposed new > authentication protocol from making the two end points the same and > using TLS instead? > > In fact, nothing does. How about: A client uncapable of verifying certificates? A situation where unilateral authentication is enough? A client uncapable of performing a full TLS handshake? BR, -- Magnus From owner-ietf-sasl Sat Jun 10 04:01:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA28330 for ietf-sasl-bks; Sat, 10 Jun 2000 04:01:48 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28326 for ; Sat, 10 Jun 2000 04:01:46 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id HAA05096; Sat, 10 Jun 2000 07:10:15 -0400 (EDT) Date: Sat, 10 Jun 2000 7:10:14 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Paul, > > On Fri, 9 Jun 2000, Paul Leach wrote: > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > > > > > The TLS endpoint isn't always the same as the application endpoint and > > > that is the very reason for this proposal. Maybe this should > > > be made more explicit in the draft. > > > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > > > > In fact, nothing does. > > How about: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? > > BR, > -- Magnus > Use a TLS cipher suite that does not use X.509 certificates for authentication. At the moment there is only Kerberos 5 defined as an RFC but there is nothing to stop someone from defining a cipher suite that uses something else. Or you can use TLS in an anonymous mode if you have another authentication mechanism that can prove shared knowledge of unverified data. If so, you take the TLS client finished message and the server finished message and you verify them as part of the authentication method. That will ensure there is no MITM. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org From owner-ietf-sasl Sat Jun 10 13:34:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14759 for ietf-sasl-bks; Sat, 10 Jun 2000 13:34:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14755 for ; Sat, 10 Jun 2000 13:34:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKYrO15561 for ; Sat, 10 Jun 2000 13:34:53 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYHIG00.QJ0 for ; Sat, 10 Jun 2000 13:42:16 -0700 Message-ID: <3942A746.85B7CE7D@netscape.com> Date: Sat, 10 Jun 2000 13:38:41 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF60FEB9B648E5FBF63A83891" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msF60FEB9B648E5FBF63A83891 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should be made more > explicit in the draft. What is HostA authenticating to, HostB or HostC? Whenever I address one case, you counter with an argument about the other. If the TLS endpoint isn't the same as the application endpoint, you have the TLS endpoint authenticate to the application endpoint using its own credentials, passing the original client's identity in the authorization ID. This results in much better security, as only middlemen the application endpoint is configured to trust are permitted to eavesdrop or modify the the connection. > > I'm sorry, I don't see the argument behind these assertions. What > > difference between TLS and SASL makes TLS a "link" protocol as opposed > > to an "application" protocol? > > IMHO, since it is possible to "insert" SASL in many higher-level protocols > it is a useful mechanism when, for one reason or another, lower level > protocols (I include TLS here) terminates at a gateway or similar, or the > application using the SASL-enabled protocol is unable to run TLS for one > reason or another, but is still capable of doing public-key operations. One can also "insert" TLS in higher-level protocols. See RFC's 2817, 2595, and 2487. TLS is no different than SASL in this regard. How does the theoretical existence of applications which support SASL and public-key operations make TLS a "link" protocol but not an "application" protocol? There do exist applications which support TLS and public-key operations, but are unable to run SASL for one reason or another. > > In your HostA, HostB, HostC situation, how would you handle a SASL > > negotiation using a mechanism that provides perfect forward secrecy of > > the identity being authenticated? > > Just so we are talking about the same thing here: Perfect forward secrecy > = Disclosing one key/authentication does not give an attacker the > possibility to reuse that information in subsequent exchanges. Exactly. Consider a SASL mechanism where the client and server first perform a Diffie-Hellman key exchange. The client then sends the server his cert encrypted with the Diffie-Hellman key and an authenticator formed by signing the Diffie-Hellman key with his private key. Or just explain how in your HostA, HostB, HostC situation you would handle a Kerberos authentication which negotiates a privacy security layer. I brought up the issue of perfect forward secrecy of the identity being authenticated to prevent the answer where HostB and HostC both have access to the server key. > The proposed protocol is vulnerable to session hi-jacking, this fact is > also mentioned in the draft, and true also for other SASL mechanisms not > inserting a security layer. Most of the other SASL mechanisms which don't have a security layer don't have it because they are incapable of negotiating a session key. The thing I don't like about this particular proposal are the implications that this lack of security layer somehow improves security or makes it significantly easier to implement than TLS. --------------msF60FEB9B648E5FBF63A83891 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxMzg0MVowIwYJKoZIhvcNAQkEMRYEFFb3JfB2R2u0 AP/6ISFCFoEKfLK+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2suDY3iZTSFCMbAmEaZeODqt/9EnCh8gz3yX6eod11a5YJGkeCmqgo89hEJuUNz 6GhdfIqznFlJdtiqjOStrHREBUk9l0hs2U/voQ1vQ4Yz46PZ6FKLZl5RtX75W0ilfTzmmOai 122j/Q/8Qh2vYXcdPHYwSl9lbm3NPzCsBy8= --------------msF60FEB9B648E5FBF63A83891-- From owner-ietf-sasl Sat Jun 10 13:49:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14924 for ietf-sasl-bks; Sat, 10 Jun 2000 13:49:28 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14920 for ; Sat, 10 Jun 2000 13:49:27 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKrUw02756 for ; Sat, 10 Jun 2000 13:53:30 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYI7X00.NPF for ; Sat, 10 Jun 2000 13:57:33 -0700 Message-ID: <3942AAE3.A6CCFDE3@netscape.com> Date: Sat, 10 Jun 2000 13:54:03 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C4BBC890518868687607636" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms2C4BBC890518868687607636 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client can perform a TLS handshake and ignore the cert sent by the server. Like the proposed mechanism, such a client would be subject to active attacks. Unlike your proposed mechanism, such a client would be protected from passive eavesdropping and would interoperate with the installed base. Our implmentation of STARTTLS in outgoing SMTP relay uses this mode. Subsequent releases will allow the site to configure which domains require protection against active attack in outgoing SMTP relay. > A client uncapable of performing a full TLS handshake? Why would a client capable of managing a client cert and signing authentication requests be uncapable of performing a full TLS handshake? --------------ms2C4BBC890518868687607636 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxNTQwNFowIwYJKoZIhvcNAQkEMRYEFCmRIks4K5gC q7S8+7tCnZFb2+kHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyEN0w6ycEoCO9PIzqIkpDpmcSi4pJMuWLomOXByPWzv19uBpusZAkJBMnZEldqOi 2/ZrkV35CUIBTKL+pgwib+VfpGC4N3rNpBF6Zkxdd+jLeipNRONetOAnupcUhNxi31XYlNUO Z5u86pF8sL+pH265y4+HmqHrkFwYgp+8R/E= --------------ms2C4BBC890518868687607636-- From owner-ietf-sasl Sat Jun 10 15:33:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15922 for ietf-sasl-bks; Sat, 10 Jun 2000 15:33:04 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA15918 for ; Sat, 10 Jun 2000 15:33:03 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 10 Jun 2000 15:33:12 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Sat, 10 Jun 2000 15:41:40 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD32B.AA1D8DC2" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Sat, 10 Jun 2000 15:31:48 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EE6@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/SuCbt3pclRNO/Qg6DtDKrh0V11QAc/wOg From: "Paul Leach" To: "Magnus Nystrom" Cc: "John Myers" , "Robert Zuccherato" , X-OriginalArrivalTime: 10 Jun 2000 22:41:40.0712 (UTC) FILETIME=[0B5A4E80:01BFD32D] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Saturday, June 10, 2000 1:51 AM > To: Paul Leach > Cc: John Myers; Robert Zuccherato; ietf-sasl@imc.org > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Paul, >=20 > On Fri, 9 Jun 2000, Paul Leach wrote: > >=20 > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > >=20 > > > The TLS endpoint isn't always the same as the application=20 > endpoint and > > > that is the very reason for this proposal. Maybe this should=20 > > > be made more explicit in the draft. > >=20 > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > >=20 > > In fact, nothing does. >=20 > How about: > A client uncapable of verifying certificates? A situation=20 > where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? If your complaint is that TLS doesn't readily admit to reducing the level of security, I would argue that TLS is easy enough to implement in it entirety that that is an irrelevane argument, and that _less_ security isn't what the world needs right now. Besides, as John pointed out, it is possible to handle those cases. And, given the existence of open source TLS implementations, why would anyone bother to implement a totally new package that has less security? Paul ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Saturday, June 10, 2000 1:51 AM
> To: Paul Leach
> Cc: John Myers; Robert Zuccherato; = ietf-sasl@imc.org
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Paul,
>
> On Fri, 9 Jun 2000, Paul Leach wrote:
> >
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> > > Sent: Friday, June 09, 2000 3:04 = AM
> > >
> > > The TLS endpoint isn't always the same = as the application
> endpoint and
> > > that is the very reason for this = proposal. Maybe this should
> > > be made more explicit in the = draft.
> >
> > Why not? What stops any app that would use = the proposed new
> > authentication protocol from making the two = end points the same and
> > using TLS instead?
> >
> > In fact, nothing does.
>
> How about:
> A client uncapable of verifying certificates? A = situation
> where unilateral
> authentication is enough?  A client = uncapable of performing a full TLS
> handshake?

If your complaint is that TLS doesn't readily admit to = reducing the level of security, I would argue that TLS is easy enough to = implement in it entirety that that is an irrelevane argument, and that = _less_ security isn't what the world needs right now.

Besides, as John pointed out, it is possible to handle = those cases. And, given the existence of open source TLS = implementations, why would anyone bother to implement a totally new = package that has less security?

Paul

------_=_NextPart_001_01BFD32B.AA1D8DC2-- From owner-ietf-sasl Sun Jun 11 13:02:12 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA19334 for ietf-sasl-bks; Sun, 11 Jun 2000 13:02:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19330 for ; Sun, 11 Jun 2000 13:02:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5BK6Iw13792 for ; Sun, 11 Jun 2000 13:06:18 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW0AP900.VMG; Sun, 11 Jun 2000 13:10:21 -0700 Message-ID: <3943F14C.DD447F74@netscape.com> Date: Sun, 11 Jun 2000 13:06:39 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> <393FF694.4EEB1D21@amazon.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms21CF901E3143C20952D5E60F" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms21CF901E3143C20952D5E60F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Margrave wrote: > As long as major applications, like say LDAP or IMAP for example, are in love > with SASL [...] don't you think it's worthwhile to at least > go to the effort to add a modicum of real security to it? I mean, the only > SASL mech worth a darn security-wise at the moment is GSS-API. Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security. One cannot simply "add security" by throwing in cryptographic protocols wherever they are convenient. One has to form a threat model, devise security policies to address the modeled threats, and evaluate an implementation of those policies as a whole against said threats. To claim that SPNEGO adds "a modicum of real security" to SASL, one must show how the combination implements security policies to thwart which classes of threats. > I struggled > with this for a while, then realized that if both sides really want a secure > connection, then can simply decide they're only going to support one > SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few > extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, > everybody wins. If both sides are configured to only support GSS KRB5, then what threat does the addition of SPNEGO protect against? > So I would think that an SPNEGO SASL mech would be a good thing, because > well-designed implementations of application protocols could be configured to > only support one SASL mech (SPNEGO), so that we get real negotiation of a > security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around > it. Please address how a client supporting only Kerberos V5 underneath SPNEGO underneath SASL would interoperate with a server supporting only Kerberos V5 underneath SASL. --------------ms21CF901E3143C20952D5E60F 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMTIxMDYzOVowIwYJKoZIhvcNAQkEMRYEFECGK2rIFaYz gUHEOxvvx5s335cgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2Hn9VULwy420FZcuKsI6apbxImmNNecnjWzQ0stEBlWp0u6xfEv9PrpBOGz1S/1 aCfp1UkE+VRJf+AuX+p/oE0m2mUwn1e0TopGpW1cBOAQ6f6bGapmY1Hnt1B4eEcIpY6KHiN6 lbb3mtpU1qEC301cAKrznisXJrRWAPLi478= --------------ms21CF901E3143C20952D5E60F-- From owner-ietf-sasl Sun Jun 11 21:08:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA18555 for ietf-sasl-bks; Sun, 11 Jun 2000 21:08:39 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18551 for ; Sun, 11 Jun 2000 21:08:37 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5C47hh14236; Mon, 12 Jun 2000 00:07:43 -0400 (EDT) Message-Id: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Sun, 11 Jun 2000 13:06:39 PDT." <3943F14C.DD447F74@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> So I would think that an SPNEGO SASL mech would be a good thing, because >> well-designed implementations of application protocols could be configured to >> only support one SASL mech (SPNEGO), so that we get real negotiation of a >> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around >> it. > >Please address how a client supporting only Kerberos V5 underneath >SPNEGO underneath SASL would interoperate with a server supporting only >Kerberos V5 underneath SASL. You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. I am still undecided on this issue; maybe it is right to not recommend the use of SPNEGO with SASL, but I don't think this is a valid reason. --Ken From owner-ietf-sasl Mon Jun 12 10:23:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11719 for ietf-sasl-bks; Mon, 12 Jun 2000 10:23:47 -0700 (PDT) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11715 for ; Mon, 12 Jun 2000 10:23:46 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id NAA23410; Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Message-Id: <200006121723.NAA23410@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Cc: Ken Hornstein In-reply-to: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Subject: Re: SASL GSSAPI draft References: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein [...] You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition to SPNEGO, no additional security is obtained via SPNEGO (the active attacks that SPNEGO prevents are just circumvented by removing SPNEGO from the capabilities line). Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be used without advertising/allowing Krb5 without SPNEGO---which leads to the interoperability problems. Larry From owner-ietf-sasl Mon Jun 12 14:37:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA16450 for ietf-sasl-bks; Mon, 12 Jun 2000 14:37:56 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16446 for ; Mon, 12 Jun 2000 14:37:54 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5CLbHh21208; Mon, 12 Jun 2000 17:37:17 -0400 (EDT) Message-Id: <200006122137.e5CLbHh21208@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Mon, 12 Jun 2000 13:23:04 EDT." <200006121723.NAA23410@smtp3.andrew.cmu.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 17:37:16 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. I don't think this is a legitimate reason for > recommending against the use of SPNEGO. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition >to SPNEGO, no additional security is obtained via SPNEGO (the active >attacks that SPNEGO prevents are just circumvented by removing SPNEGO >from the capabilities line). That's true, with the current draft. But if GSSAPI simply means, "any GSSAPI mechanism", then there's no reason a non-SPNEGO client can't interoperate with a SPNEGO-aware server, without any loss of security that I can tell (since there wouldn't be any negotiation in the non-SPNEGO case). I was under the impression that "the interoperability problem" was given as a reason not to use SPNEGO; that's the only reason why I'm saying I don't think it's a valid reason. --Ken From owner-ietf-sasl Tue Jun 13 06:59:49 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19645 for ietf-sasl-bks; Tue, 13 Jun 2000 06:59:49 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19639 for ; Tue, 13 Jun 2000 06:59:47 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Jun 2000 13:54:30 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA10808; Tue, 13 Jun 2000 09:58:58 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 09:59:13 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: RE: SASL GSSAPI draft Date: Tue, 13 Jun 2000 09:59:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Properly, I think, the interoperability concern applies to the case where GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at the SASL level. If GSS mechanisms are exposed for negotiation at both the SPNEGO and SASL levels, this would provide the broadest degree of interoperability, supporting even those clients whose policies reject negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as a protected means to select among the available GSS mechanisms. If it's plausible for a client to have such a policy, even though it's interacting with a server which may also have clients having other policies, interoperability would be best served by allowing negotiation at both levels. One argument against SPNEGO under SASL (additionally to SASL-level exposure of the same GSS mechanism set) is that it adds complexity which would be superfluous in some situations; the (apparently modest) incremental complexity might be justified by the fact that it enables a protected negotiation which would be usefully and additionally secure in other situations. Generally, wrt SPNEGO support under SASL, we've seen arguments for both positions. Rather than the present SHOULD NOT (albeit with listed exception), would this be a good candidate for compromise on a MAY? --jl > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, June 12, 2000 5:37 PM > To: ietf-sasl@imc.org; ietf-cat-wg@lists.Stanford.EDU > Subject: Re: SASL GSSAPI draft > > > > You keep bringing up these mythical "only Kerberos V5 underneath > > SPNEGO" implementations. Even if you're doing SPNEGO, you still > > have to parse V5 GSSAPI tokens; I can't really imagine a reason > > why you would not be able to handle a V5 GSSAPI token exchange > > without SPNEGO. I don't think this is a legitimate reason for > > recommending against the use of SPNEGO. > > > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). > > I was under the impression that "the interoperability > problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. > > --Ken > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > From owner-ietf-sasl Wed Jun 14 23:38:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00690 for ietf-sasl-bks; Wed, 14 Jun 2000 23:38:04 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00684 for ; Wed, 14 Jun 2000 23:38:03 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5F6TY805835 for ; Wed, 14 Jun 2000 23:29:34 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW6NPU00.R18; Wed, 14 Jun 2000 23:37:06 -0700 Message-ID: <3948788D.62BADB48@netscape.com> Date: Wed, 14 Jun 2000 23:32:46 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms49DFB204291C59317B913E32" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms49DFB204291C59317B913E32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > As I read RFC 2478, > you always deal with the OID of the underlying mechanism, so I > don't think it's possible to support, for example, Kerberos "under" > SPNEGO without just supporting Kerberos If a server supports Kerberos underneath SPNEGO but rejects Kerberos GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is that server violating? --------------ms49DFB204291C59317B913E32 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNTA3MzI0NlowIwYJKoZIhvcNAQkEMRYEFAvLy+AgVmIp rC5DizLuBZHcLTotMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyFvbeL5fVgm+qdg3i5XFVNXelmM+GcE4+tO/RlxeE8wHXAy5Co1IT0BDmNEUvVHw jsxPy2CxPdTqU8hHXANxRX8w3qOSyogqn7aqhg+Dc2c2MjvERdx2WjOiQUaXvZYk6m2TV0M9 GWfuFZc3s7kTNRSvQn0UjswPyzQBbeNDU8k= --------------ms49DFB204291C59317B913E32-- From owner-ietf-sasl Fri Jun 16 14:59:19 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA24881 for ietf-sasl-bks; Fri, 16 Jun 2000 14:59:19 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24877 for ; Fri, 16 Jun 2000 14:59:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GLowW06866 for ; Fri, 16 Jun 2000 14:50:58 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9P1M00.RW5; Fri, 16 Jun 2000 14:58:34 -0700 Message-ID: <394AA301.D623264@netscape.com> Date: Fri, 16 Jun 2000 14:58:25 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: <3943F14C.DD447F74@netscape.com> <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEB93552D1CF51C9180CCE623" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msEB93552D1CF51C9180CCE623 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My apologies, I accidentally left the ietf-cat-wg list off the recipient list when I first sent this message: Ken Hornstein wrote: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Reportedly, the Microsoft Windows 2000 SSPI implementation only advertises the availability of the SPNEGO GSSAPI mechanism. A straightforward implementation of SASL on Windows 2000 would be unlikely to advertise or recognize GSSAPI SASL mechanisms other than the "GSS-SPNEGO" mechanism that was registered by Microsoft. > Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. Consider a SPNEGO client and a non-SPNEGO server. The server will be unable to parse the SPNEGO GSSAPI token that the client sends. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a client which supports more than one GSSAPI mechanism doesn't know which one to send to the server. If a client supports both Kerberos V5 and SPKM-1 and sees the server advertising "GSSAPI", which one should it send? Surely you don't intend for an IMAP client to take two round trips per GSSAPI mechanism in order to find out the server only supports the last mechanism the client tried? What do you mean there wouldn't be any negotiation in the non-SPNEGO case? There's always negotiation in SASL. A man in the middle can always make it look like either side doesn't support SPNEGO, so my "no additional security is obtained" statement still applies. > I was under the impression that "the interoperability problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. I'm sorry, I don't understand. What is the reason you're saying you don't think "the interoperability problem" is a valid reason? --------------msEB93552D1CF51C9180CCE623 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIxNTgyNlowIwYJKoZIhvcNAQkEMRYEFE+a6Q9ihQxB O+F6UJ8jdTqtj3TYMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAIxxg/ZeWaKZYQCD0GKZyUc3uTPdNH6m7OhkNn5roN4jY JUDRk6hjKptpJ0ANGk0H9Cb3uFif4QuVpPkH3SHF6mBOD36cY5BOXJrDE8DKXsQ5LTZrzPCP 1oszNNwWebfrhyIIERM2pIOgCEGZ+blhs2WIh4WKm4ZqLWGSsQLgbss= --------------msEB93552D1CF51C9180CCE623-- From owner-ietf-sasl Fri Jun 16 16:35:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA25849 for ietf-sasl-bks; Fri, 16 Jun 2000 16:35:34 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25845 for ; Fri, 16 Jun 2000 16:35:33 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GNRDW18851 for ; Fri, 16 Jun 2000 16:27:13 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9TI100.4BV; Fri, 16 Jun 2000 16:34:49 -0700 Message-ID: <394AB984.B4A401B@netscape.com> Date: Fri, 16 Jun 2000 16:34:28 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD28D6A4382055AF44DF9B865" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msD28D6A4382055AF44DF9B865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > Properly, I think, the interoperability concern applies to the case where > GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at > the SASL level. Agreed. There is also a problem case where the policy prefers a non-GSSAPI mechanism over a particular GSSAPI mechanism. One possible reasonable policy would be to first prefer Kerberos, then DIGEST-MD5, then GSS-API-Easy. If a server only supports DIGEST-MD5 and GSS-API-Easy, a client might through SPNEGO inadvertently use GSS-API-Easy instead of DIGEST-MD5. > If GSS mechanisms are exposed for negotiation at both the > SPNEGO and SASL levels, this would provide the broadest degree of > interoperability, supporting even those clients whose policies reject > negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as > a protected means to select among the available GSS mechanisms. One issue is whether or not it is a reasonable policy for the server to only accept certain weaker GSS mechanisms when their use has been negotiated through SPNEGO. If it is a reasonable policy, then the draft's current MUST wording about advertising the strongest GSS mechanism at the SASL layer is sufficient. If it is not a reasonable policy, then the requirement needs to be strengthened to say that all of the GSS mechanisms supported inside SPNEGO MUST also be advertised at the SASL layer. For SPNEGO to be useful, a client must not only have the policies you state, but must additionally support and have access to credentials for at least two GSS mechanisms. Steve Hole, who has implemented both Kerberos and SPKM, reports that in his experience any given client or server only has access to infrastructure for one GSS mechanism. I won't claim that it will never happen, but the set of policies and circumstances for which SPNEGO under SASL is necessary is rarely practical. > One argument against SPNEGO under SASL (additionally to SASL-level > exposure of the same GSS mechanism set) is that it adds complexity which > would be superfluous in some situations; the (apparently modest) incremental > complexity might be justified by the fact that it enables a protected > negotiation which would be usefully and additionally secure in other > situations. The incremental complexity of implementing SPNEGO is not necessarily modest. The SASL implementation I am currently working on and the CMU Cyrus SASL library both allow for SASL mechanism plug-ins. It would be relatively straightforward to create a SASL mechanism plug-in implementing Kerberos--that plug-in could then be loaded into any product implemented using the library. To support Kerberos underneath SPNEGO, either the SASL library would have to implement both GSSAPI and SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then have Kerberos plug-in to the GSSAPI plug-in. > Generally, wrt SPNEGO support under SASL, we've seen arguments for both > positions. Rather than the present SHOULD NOT (albeit with listed > exception), would this be a good candidate for compromise on a MAY? I am extremely worried about offering two different ways to do the same thing. When a protocol offers multiple ways to do something, it is not uncommon for an implementation to only test one of them. Even if only one way is a MUST IMPLEMENT, that is not necessarily the way that gets tested. If an implementation botches the MUST way and gains wide deployment due to some some other way working, the protocol effectively ends up with two or more MUST IMPLEMENTS. (This is a form of the "be liberal considered harmful" argument.) This is why I wrote this as a SHOULD NOT requirement with a listed exception. I am trying to get implementors to think about their customer's security requirements and only take on the complexity and risk of noninteroperation if the security policy and set of circumstances require. If we change the SHOULD NOT to a MAY, how else can we minimize the risk of clients and servers which only work with SPNEGO due to implementation laziness or error? --------------msD28D6A4382055AF44DF9B865 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIzMzQyOVowIwYJKoZIhvcNAQkEMRYEFGT8cS+9ZRsH E3rBzsldG2a09U6MMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGASRm4goDBlEYABRIS4f3sZ2hpDJdORlMR1vrOihSpMggv 3v3c/uCy7SneSyFdyeo2WdfI7ToT1pwt6xqQSfXehTK0EHeB1AXbd+puIfhMHsnNQ/gwfqkW SBeIiFmRjNSAgOxJRSGN+khFanFdjOnTfZBo3gMZPJXVtuN+LsEBDRk= --------------msD28D6A4382055AF44DF9B865-- From owner-ietf-sasl Fri Jun 16 20:15:06 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA28686 for ietf-sasl-bks; Fri, 16 Jun 2000 20:15:06 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28682 for ; Fri, 16 Jun 2000 20:15:04 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5H3Ec801945; Fri, 16 Jun 2000 23:14:39 -0400 (EDT) Message-Id: <200006170314.e5H3Ec801945@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Fri, 16 Jun 2000 14:58:25 PDT." <394AA301.D623264@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 16 Jun 2000 23:14:38 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> You keep bringing up these mythical "only Kerberos V5 underneath >> SPNEGO" implementations. > >Reportedly, the Microsoft Windows 2000 SSPI implementation only >advertises the availability of the SPNEGO GSSAPI mechanism. A >straightforward implementation of SASL on Windows 2000 would be unlikely >to advertise or recognize GSSAPI SASL mechanisms other than the >"GSS-SPNEGO" mechanism that was registered by Microsoft. Hm, back up here. Are we talking about advertisement at the SASL or GSSAPI level? I think I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI. I will say that when I telnetted to the SMTP server on a coworkers Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI", and I didn't see GSS-SPNEGO anywhere. Maybe that will change in the future. Everything I have seen from Microsoft has led me to believe that this server would accept a valid Kerberos 5 GSSAPI token (but I haven't actually tested it yet), _and_ it would accept a SPNEGO token. I actually thought that this interoperability has been tested by Microsoft, but I'd appreciate a correction. >> Even if you're doing SPNEGO, you still >> have to parse V5 GSSAPI tokens; I can't really imagine a reason >> why you would not be able to handle a V5 GSSAPI token exchange >> without SPNEGO. > >Consider a SPNEGO client and a non-SPNEGO server. The server will be >unable to parse the SPNEGO GSSAPI token that the client sends. I agree, this is a problem; I don't think I ever disagreed with that. >> That's true, with the current draft. But if GSSAPI simply means, "any >> GSSAPI mechanism", then there's no reason a non-SPNEGO client can't >> interoperate with a SPNEGO-aware server, without any loss of security >> that I can tell (since there wouldn't be any negotiation in the >> non-SPNEGO case). > >If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a >client which supports more than one GSSAPI mechanism doesn't know which >one to send to the server. No disagreement here. But ... it was my thinking that if you supported more than one mechanism, you'd really have to do SPNEGO (or your proposed draft). >What do you mean there wouldn't be any negotiation in the non-SPNEGO >case? There's always negotiation in SASL. A man in the middle can >always make it look like either side doesn't support SPNEGO, so my "no >additional security is obtained" statement still applies. My apologies; I should have been clearer. I meant, "there wouldn't be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5 only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism). But you're right; you still don't gain any security, because you can then simply remove GSSAPI from the supported mechanism line. My apologies. >> I was under the impression that "the interoperability problem" was given >> as a reason not to use SPNEGO; that's the only reason why I'm saying >> I don't think it's a valid reason. > >I'm sorry, I don't understand. What is the reason you're saying you >don't think "the interoperability problem" is a valid reason? It's been said a number of times that Kerberos 5-only GSSAPI implementations won't interoperate with GSSAPI implementations that support Kerberos 5 only under SPNEGO, and this is one of the reasons a seperate GSS-SPNEGO SASL mechanism is needed. It is my belief that there are no GSSAPI implementations that support SPNEGO which do not support GSS Kerberos 5, and furthermore there is no reason why you would ever _create_ such a GSSAPI implementation (number one: you'd lose interoperability with Kerberos 5 GSSAPI implementations on non-SASL protocols such as FTP). So I don't think that any such interoperability problem exists. (from another note) >If a server supports Kerberos underneath SPNEGO but rejects Kerberos >GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is >that server violating? None, as far as I can tell (that exists outside of the SPNEGO spec, as far as I can tell). But is there a reason why you would do such a thing? Please understand that I'm not raising an objection to your draft; I'm just trying to understand the reasoning better. --Ken Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA28686 for ietf-sasl-bks; Fri, 16 Jun 2000 20:15:06 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28682 for ; Fri, 16 Jun 2000 20:15:04 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5H3Ec801945; Fri, 16 Jun 2000 23:14:39 -0400 (EDT) Message-Id: <200006170314.e5H3Ec801945@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Fri, 16 Jun 2000 14:58:25 PDT." <394AA301.D623264@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 16 Jun 2000 23:14:38 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> You keep bringing up these mythical "only Kerberos V5 underneath >> SPNEGO" implementations. > >Reportedly, the Microsoft Windows 2000 SSPI implementation only >advertises the availability of the SPNEGO GSSAPI mechanism. A >straightforward implementation of SASL on Windows 2000 would be unlikely >to advertise or recognize GSSAPI SASL mechanisms other than the >"GSS-SPNEGO" mechanism that was registered by Microsoft. Hm, back up here. Are we talking about advertisement at the SASL or GSSAPI level? I think I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI. I will say that when I telnetted to the SMTP server on a coworkers Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI", and I didn't see GSS-SPNEGO anywhere. Maybe that will change in the future. Everything I have seen from Microsoft has led me to believe that this server would accept a valid Kerberos 5 GSSAPI token (but I haven't actually tested it yet), _and_ it would accept a SPNEGO token. I actually thought that this interoperability has been tested by Microsoft, but I'd appreciate a correction. >> Even if you're doing SPNEGO, you still >> have to parse V5 GSSAPI tokens; I can't really imagine a reason >> why you would not be able to handle a V5 GSSAPI token exchange >> without SPNEGO. > >Consider a SPNEGO client and a non-SPNEGO server. The server will be >unable to parse the SPNEGO GSSAPI token that the client sends. I agree, this is a problem; I don't think I ever disagreed with that. >> That's true, with the current draft. But if GSSAPI simply means, "any >> GSSAPI mechanism", then there's no reason a non-SPNEGO client can't >> interoperate with a SPNEGO-aware server, without any loss of security >> that I can tell (since there wouldn't be any negotiation in the >> non-SPNEGO case). > >If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a >client which supports more than one GSSAPI mechanism doesn't know which >one to send to the server. No disagreement here. But ... it was my thinking that if you supported more than one mechanism, you'd really have to do SPNEGO (or your proposed draft). >What do you mean there wouldn't be any negotiation in the non-SPNEGO >case? There's always negotiation in SASL. A man in the middle can >always make it look like either side doesn't support SPNEGO, so my "no >additional security is obtained" statement still applies. My apologies; I should have been clearer. I meant, "there wouldn't be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5 only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism). But you're right; you still don't gain any security, because you can then simply remove GSSAPI from the supported mechanism line. My apologies. >> I was under the impression that "the interoperability problem" was given >> as a reason not to use SPNEGO; that's the only reason why I'm saying >> I don't think it's a valid reason. > >I'm sorry, I don't understand. What is the reason you're saying you >don't think "the interoperability problem" is a valid reason? It's been said a number of times that Kerberos 5-only GSSAPI implementations won't interoperate with GSSAPI implementations that support Kerberos 5 only under SPNEGO, and this is one of the reasons a seperate GSS-SPNEGO SASL mechanism is needed. It is my belief that there are no GSSAPI implementations that support SPNEGO which do not support GSS Kerberos 5, and furthermore there is no reason why you would ever _create_ such a GSSAPI implementation (number one: you'd lose interoperability with Kerberos 5 GSSAPI implementations on non-SASL protocols such as FTP). So I don't think that any such interoperability problem exists. (from another note) >If a server supports Kerberos underneath SPNEGO but rejects Kerberos >GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is >that server violating? None, as far as I can tell (that exists outside of the SPNEGO spec, as far as I can tell). But is there a reason why you would do such a thing? Please understand that I'm not raising an objection to your draft; I'm just trying to understand the reasoning better. --Ken Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA25849 for ietf-sasl-bks; Fri, 16 Jun 2000 16:35:34 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25845 for ; Fri, 16 Jun 2000 16:35:33 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GNRDW18851 for ; Fri, 16 Jun 2000 16:27:13 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9TI100.4BV; Fri, 16 Jun 2000 16:34:49 -0700 Message-ID: <394AB984.B4A401B@netscape.com> Date: Fri, 16 Jun 2000 16:34:28 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD28D6A4382055AF44DF9B865" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msD28D6A4382055AF44DF9B865 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > Properly, I think, the interoperability concern applies to the case where > GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at > the SASL level. Agreed. There is also a problem case where the policy prefers a non-GSSAPI mechanism over a particular GSSAPI mechanism. One possible reasonable policy would be to first prefer Kerberos, then DIGEST-MD5, then GSS-API-Easy. If a server only supports DIGEST-MD5 and GSS-API-Easy, a client might through SPNEGO inadvertently use GSS-API-Easy instead of DIGEST-MD5. > If GSS mechanisms are exposed for negotiation at both the > SPNEGO and SASL levels, this would provide the broadest degree of > interoperability, supporting even those clients whose policies reject > negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as > a protected means to select among the available GSS mechanisms. One issue is whether or not it is a reasonable policy for the server to only accept certain weaker GSS mechanisms when their use has been negotiated through SPNEGO. If it is a reasonable policy, then the draft's current MUST wording about advertising the strongest GSS mechanism at the SASL layer is sufficient. If it is not a reasonable policy, then the requirement needs to be strengthened to say that all of the GSS mechanisms supported inside SPNEGO MUST also be advertised at the SASL layer. For SPNEGO to be useful, a client must not only have the policies you state, but must additionally support and have access to credentials for at least two GSS mechanisms. Steve Hole, who has implemented both Kerberos and SPKM, reports that in his experience any given client or server only has access to infrastructure for one GSS mechanism. I won't claim that it will never happen, but the set of policies and circumstances for which SPNEGO under SASL is necessary is rarely practical. > One argument against SPNEGO under SASL (additionally to SASL-level > exposure of the same GSS mechanism set) is that it adds complexity which > would be superfluous in some situations; the (apparently modest) incremental > complexity might be justified by the fact that it enables a protected > negotiation which would be usefully and additionally secure in other > situations. The incremental complexity of implementing SPNEGO is not necessarily modest. The SASL implementation I am currently working on and the CMU Cyrus SASL library both allow for SASL mechanism plug-ins. It would be relatively straightforward to create a SASL mechanism plug-in implementing Kerberos--that plug-in could then be loaded into any product implemented using the library. To support Kerberos underneath SPNEGO, either the SASL library would have to implement both GSSAPI and SPNEGO or one would have to create a GSSAPI/SPNEGO SASL plug-in and then have Kerberos plug-in to the GSSAPI plug-in. > Generally, wrt SPNEGO support under SASL, we've seen arguments for both > positions. Rather than the present SHOULD NOT (albeit with listed > exception), would this be a good candidate for compromise on a MAY? I am extremely worried about offering two different ways to do the same thing. When a protocol offers multiple ways to do something, it is not uncommon for an implementation to only test one of them. Even if only one way is a MUST IMPLEMENT, that is not necessarily the way that gets tested. If an implementation botches the MUST way and gains wide deployment due to some some other way working, the protocol effectively ends up with two or more MUST IMPLEMENTS. (This is a form of the "be liberal considered harmful" argument.) This is why I wrote this as a SHOULD NOT requirement with a listed exception. I am trying to get implementors to think about their customer's security requirements and only take on the complexity and risk of noninteroperation if the security policy and set of circumstances require. If we change the SHOULD NOT to a MAY, how else can we minimize the risk of clients and servers which only work with SPNEGO due to implementation laziness or error? --------------msD28D6A4382055AF44DF9B865 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIzMzQyOVowIwYJKoZIhvcNAQkEMRYEFGT8cS+9ZRsH E3rBzsldG2a09U6MMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGASRm4goDBlEYABRIS4f3sZ2hpDJdORlMR1vrOihSpMggv 3v3c/uCy7SneSyFdyeo2WdfI7ToT1pwt6xqQSfXehTK0EHeB1AXbd+puIfhMHsnNQ/gwfqkW SBeIiFmRjNSAgOxJRSGN+khFanFdjOnTfZBo3gMZPJXVtuN+LsEBDRk= --------------msD28D6A4382055AF44DF9B865-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA24881 for ietf-sasl-bks; Fri, 16 Jun 2000 14:59:19 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24877 for ; Fri, 16 Jun 2000 14:59:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5GLowW06866 for ; Fri, 16 Jun 2000 14:50:58 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW9P1M00.RW5; Fri, 16 Jun 2000 14:58:34 -0700 Message-ID: <394AA301.D623264@netscape.com> Date: Fri, 16 Jun 2000 14:58:25 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org, ietf-cat-wg@lists.stanford.edu Subject: Re: SASL GSSAPI draft References: <3943F14C.DD447F74@netscape.com> <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msEB93552D1CF51C9180CCE623" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msEB93552D1CF51C9180CCE623 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My apologies, I accidentally left the ietf-cat-wg list off the recipient list when I first sent this message: Ken Hornstein wrote: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Reportedly, the Microsoft Windows 2000 SSPI implementation only advertises the availability of the SPNEGO GSSAPI mechanism. A straightforward implementation of SASL on Windows 2000 would be unlikely to advertise or recognize GSSAPI SASL mechanisms other than the "GSS-SPNEGO" mechanism that was registered by Microsoft. > Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. Consider a SPNEGO client and a non-SPNEGO server. The server will be unable to parse the SPNEGO GSSAPI token that the client sends. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a client which supports more than one GSSAPI mechanism doesn't know which one to send to the server. If a client supports both Kerberos V5 and SPKM-1 and sees the server advertising "GSSAPI", which one should it send? Surely you don't intend for an IMAP client to take two round trips per GSSAPI mechanism in order to find out the server only supports the last mechanism the client tried? What do you mean there wouldn't be any negotiation in the non-SPNEGO case? There's always negotiation in SASL. A man in the middle can always make it look like either side doesn't support SPNEGO, so my "no additional security is obtained" statement still applies. > I was under the impression that "the interoperability problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. I'm sorry, I don't understand. What is the reason you're saying you don't think "the interoperability problem" is a valid reason? --------------msEB93552D1CF51C9180CCE623 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNjIxNTgyNlowIwYJKoZIhvcNAQkEMRYEFE+a6Q9ihQxB O+F6UJ8jdTqtj3TYMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAIxxg/ZeWaKZYQCD0GKZyUc3uTPdNH6m7OhkNn5roN4jY JUDRk6hjKptpJ0ANGk0H9Cb3uFif4QuVpPkH3SHF6mBOD36cY5BOXJrDE8DKXsQ5LTZrzPCP 1oszNNwWebfrhyIIERM2pIOgCEGZ+blhs2WIh4WKm4ZqLWGSsQLgbss= --------------msEB93552D1CF51C9180CCE623-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA00690 for ietf-sasl-bks; Wed, 14 Jun 2000 23:38:04 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00684 for ; Wed, 14 Jun 2000 23:38:03 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5F6TY805835 for ; Wed, 14 Jun 2000 23:29:34 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW6NPU00.R18; Wed, 14 Jun 2000 23:37:06 -0700 Message-ID: <3948788D.62BADB48@netscape.com> Date: Wed, 14 Jun 2000 23:32:46 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms49DFB204291C59317B913E32" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms49DFB204291C59317B913E32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > As I read RFC 2478, > you always deal with the OID of the underlying mechanism, so I > don't think it's possible to support, for example, Kerberos "under" > SPNEGO without just supporting Kerberos If a server supports Kerberos underneath SPNEGO but rejects Kerberos GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is that server violating? --------------ms49DFB204291C59317B913E32 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxNTA3MzI0NlowIwYJKoZIhvcNAQkEMRYEFAvLy+AgVmIp rC5DizLuBZHcLTotMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyFvbeL5fVgm+qdg3i5XFVNXelmM+GcE4+tO/RlxeE8wHXAy5Co1IT0BDmNEUvVHw jsxPy2CxPdTqU8hHXANxRX8w3qOSyogqn7aqhg+Dc2c2MjvERdx2WjOiQUaXvZYk6m2TV0M9 GWfuFZc3s7kTNRSvQn0UjswPyzQBbeNDU8k= --------------ms49DFB204291C59317B913E32-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA19645 for ietf-sasl-bks; Tue, 13 Jun 2000 06:59:49 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA19639 for ; Tue, 13 Jun 2000 06:59:47 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 Jun 2000 13:54:30 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA10808; Tue, 13 Jun 2000 09:58:58 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 09:59:13 -0400 Message-ID: From: "Linn, John" To: "'Ken Hornstein'" , ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: RE: SASL GSSAPI draft Date: Tue, 13 Jun 2000 09:59:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Properly, I think, the interoperability concern applies to the case where GSS mechanisms are exposed for negotiation only via SPNEGO, and not also at the SASL level. If GSS mechanisms are exposed for negotiation at both the SPNEGO and SASL levels, this would provide the broadest degree of interoperability, supporting even those clients whose policies reject negotiation of any non-GSS SASL mechanisms and which demand to use SPNEGO as a protected means to select among the available GSS mechanisms. If it's plausible for a client to have such a policy, even though it's interacting with a server which may also have clients having other policies, interoperability would be best served by allowing negotiation at both levels. One argument against SPNEGO under SASL (additionally to SASL-level exposure of the same GSS mechanism set) is that it adds complexity which would be superfluous in some situations; the (apparently modest) incremental complexity might be justified by the fact that it enables a protected negotiation which would be usefully and additionally secure in other situations. Generally, wrt SPNEGO support under SASL, we've seen arguments for both positions. Rather than the present SHOULD NOT (albeit with listed exception), would this be a good candidate for compromise on a MAY? --jl > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > Sent: Monday, June 12, 2000 5:37 PM > To: ietf-sasl@imc.org; ietf-cat-wg@lists.Stanford.EDU > Subject: Re: SASL GSSAPI draft > > > > You keep bringing up these mythical "only Kerberos V5 underneath > > SPNEGO" implementations. Even if you're doing SPNEGO, you still > > have to parse V5 GSSAPI tokens; I can't really imagine a reason > > why you would not be able to handle a V5 GSSAPI token exchange > > without SPNEGO. I don't think this is a legitimate reason for > > recommending against the use of SPNEGO. > > > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition > >to SPNEGO, no additional security is obtained via SPNEGO (the active > >attacks that SPNEGO prevents are just circumvented by removing SPNEGO > >from the capabilities line). > > That's true, with the current draft. But if GSSAPI simply means, "any > GSSAPI mechanism", then there's no reason a non-SPNEGO client can't > interoperate with a SPNEGO-aware server, without any loss of security > that I can tell (since there wouldn't be any negotiation in the > non-SPNEGO case). > > I was under the impression that "the interoperability > problem" was given > as a reason not to use SPNEGO; that's the only reason why I'm saying > I don't think it's a valid reason. > > --Ken > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to > majordomo@lists.stanford.edu > Received: by ns.secondary.com (8.9.3/8.9.3) id OAA16450 for ietf-sasl-bks; Mon, 12 Jun 2000 14:37:56 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16446 for ; Mon, 12 Jun 2000 14:37:54 -0700 (PDT) Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5CLbHh21208; Mon, 12 Jun 2000 17:37:17 -0400 (EDT) Message-Id: <200006122137.e5CLbHh21208@ginger.cmf.nrl.navy.mil> To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Mon, 12 Jun 2000 13:23:04 EDT." <200006121723.NAA23410@smtp3.andrew.cmu.edu> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 17:37:16 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > You keep bringing up these mythical "only Kerberos V5 underneath > SPNEGO" implementations. Even if you're doing SPNEGO, you still > have to parse V5 GSSAPI tokens; I can't really imagine a reason > why you would not be able to handle a V5 GSSAPI token exchange > without SPNEGO. I don't think this is a legitimate reason for > recommending against the use of SPNEGO. > >If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition >to SPNEGO, no additional security is obtained via SPNEGO (the active >attacks that SPNEGO prevents are just circumvented by removing SPNEGO >from the capabilities line). That's true, with the current draft. But if GSSAPI simply means, "any GSSAPI mechanism", then there's no reason a non-SPNEGO client can't interoperate with a SPNEGO-aware server, without any loss of security that I can tell (since there wouldn't be any negotiation in the non-SPNEGO case). I was under the impression that "the interoperability problem" was given as a reason not to use SPNEGO; that's the only reason why I'm saying I don't think it's a valid reason. --Ken Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11719 for ietf-sasl-bks; Mon, 12 Jun 2000 10:23:47 -0700 (PDT) Received: from smtp3.andrew.cmu.edu (SMTP3.ANDREW.CMU.EDU [128.2.10.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11715 for ; Mon, 12 Jun 2000 10:23:46 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp3.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id NAA23410; Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT) Message-Id: <200006121723.NAA23410@smtp3.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org, ietf-cat-wg@lists.Stanford.EDU Cc: Ken Hornstein In-reply-to: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Subject: Re: SASL GSSAPI draft References: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein [...] You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition to SPNEGO, no additional security is obtained via SPNEGO (the active attacks that SPNEGO prevents are just circumvented by removing SPNEGO from the capabilities line). Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be used without advertising/allowing Krb5 without SPNEGO---which leads to the interoperability problems. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id VAA18555 for ietf-sasl-bks; Sun, 11 Jun 2000 21:08:39 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18551 for ; Sun, 11 Jun 2000 21:08:37 -0700 (PDT) Received: from cmf.nrl.navy.mil (pendragon.cmf.nrl.navy.mil [134.207.5.3]) (authenticated) by ginger.cmf.nrl.navy.mil (8.10.1/8.10.1) with ESMTP id e5C47hh14236; Mon, 12 Jun 2000 00:07:43 -0400 (EDT) Message-Id: <200006120407.e5C47hh14236@ginger.cmf.nrl.navy.mil> To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft In-reply-to: Your message of "Sun, 11 Jun 2000 13:06:39 PDT." <3943F14C.DD447F74@netscape.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 12 Jun 2000 00:07:42 -0400 From: Ken Hornstein Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> So I would think that an SPNEGO SASL mech would be a good thing, because >> well-designed implementations of application protocols could be configured to >> only support one SASL mech (SPNEGO), so that we get real negotiation of a >> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around >> it. > >Please address how a client supporting only Kerberos V5 underneath >SPNEGO underneath SASL would interoperate with a server supporting only >Kerberos V5 underneath SASL. You keep bringing up these mythical "only Kerberos V5 underneath SPNEGO" implementations. Even if you're doing SPNEGO, you still have to parse V5 GSSAPI tokens; I can't really imagine a reason why you would not be able to handle a V5 GSSAPI token exchange without SPNEGO. I don't think this is a legitimate reason for recommending against the use of SPNEGO. I am still undecided on this issue; maybe it is right to not recommend the use of SPNEGO with SASL, but I don't think this is a valid reason. --Ken Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA19334 for ietf-sasl-bks; Sun, 11 Jun 2000 13:02:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19330 for ; Sun, 11 Jun 2000 13:02:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5BK6Iw13792 for ; Sun, 11 Jun 2000 13:06:18 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FW0AP900.VMG; Sun, 11 Jun 2000 13:10:21 -0700 Message-ID: <3943F14C.DD447F74@netscape.com> Date: Sun, 11 Jun 2000 13:06:39 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU CC: ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> <393FF694.4EEB1D21@amazon.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms21CF901E3143C20952D5E60F" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms21CF901E3143C20952D5E60F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Margrave wrote: > As long as major applications, like say LDAP or IMAP for example, are in love > with SASL [...] don't you think it's worthwhile to at least > go to the effort to add a modicum of real security to it? I mean, the only > SASL mech worth a darn security-wise at the moment is GSS-API. Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security. One cannot simply "add security" by throwing in cryptographic protocols wherever they are convenient. One has to form a threat model, devise security policies to address the modeled threats, and evaluate an implementation of those policies as a whole against said threats. To claim that SPNEGO adds "a modicum of real security" to SASL, one must show how the combination implements security policies to thwart which classes of threats. > I struggled > with this for a while, then realized that if both sides really want a secure > connection, then can simply decide they're only going to support one > SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few > extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, > everybody wins. If both sides are configured to only support GSS KRB5, then what threat does the addition of SPNEGO protect against? > So I would think that an SPNEGO SASL mech would be a good thing, because > well-designed implementations of application protocols could be configured to > only support one SASL mech (SPNEGO), so that we get real negotiation of a > security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around > it. Please address how a client supporting only Kerberos V5 underneath SPNEGO underneath SASL would interoperate with a server supporting only Kerberos V5 underneath SASL. --------------ms21CF901E3143C20952D5E60F 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMTIxMDYzOVowIwYJKoZIhvcNAQkEMRYEFECGK2rIFaYz gUHEOxvvx5s335cgMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2Hn9VULwy420FZcuKsI6apbxImmNNecnjWzQ0stEBlWp0u6xfEv9PrpBOGz1S/1 aCfp1UkE+VRJf+AuX+p/oE0m2mUwn1e0TopGpW1cBOAQ6f6bGapmY1Hnt1B4eEcIpY6KHiN6 lbb3mtpU1qEC301cAKrznisXJrRWAPLi478= --------------ms21CF901E3143C20952D5E60F-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15922 for ietf-sasl-bks; Sat, 10 Jun 2000 15:33:04 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA15918 for ; Sat, 10 Jun 2000 15:33:03 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 10 Jun 2000 15:33:12 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Sat, 10 Jun 2000 15:41:40 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD32B.AA1D8DC2" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Sat, 10 Jun 2000 15:31:48 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EE6@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/SuCbt3pclRNO/Qg6DtDKrh0V11QAc/wOg From: "Paul Leach" To: "Magnus Nystrom" Cc: "John Myers" , "Robert Zuccherato" , X-OriginalArrivalTime: 10 Jun 2000 22:41:40.0712 (UTC) FILETIME=[0B5A4E80:01BFD32D] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Saturday, June 10, 2000 1:51 AM > To: Paul Leach > Cc: John Myers; Robert Zuccherato; ietf-sasl@imc.org > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Paul, >=20 > On Fri, 9 Jun 2000, Paul Leach wrote: > >=20 > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > >=20 > > > The TLS endpoint isn't always the same as the application=20 > endpoint and > > > that is the very reason for this proposal. Maybe this should=20 > > > be made more explicit in the draft. > >=20 > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > >=20 > > In fact, nothing does. >=20 > How about: > A client uncapable of verifying certificates? A situation=20 > where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? If your complaint is that TLS doesn't readily admit to reducing the level of security, I would argue that TLS is easy enough to implement in it entirety that that is an irrelevane argument, and that _less_ security isn't what the world needs right now. Besides, as John pointed out, it is possible to handle those cases. And, given the existence of open source TLS implementations, why would anyone bother to implement a totally new package that has less security? Paul ------_=_NextPart_001_01BFD32B.AA1D8DC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Saturday, June 10, 2000 1:51 AM
> To: Paul Leach
> Cc: John Myers; Robert Zuccherato; = ietf-sasl@imc.org
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Paul,
>
> On Fri, 9 Jun 2000, Paul Leach wrote:
> >
> > > -----Original Message-----
> > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> > > Sent: Friday, June 09, 2000 3:04 = AM
> > >
> > > The TLS endpoint isn't always the same = as the application
> endpoint and
> > > that is the very reason for this = proposal. Maybe this should
> > > be made more explicit in the = draft.
> >
> > Why not? What stops any app that would use = the proposed new
> > authentication protocol from making the two = end points the same and
> > using TLS instead?
> >
> > In fact, nothing does.
>
> How about:
> A client uncapable of verifying certificates? A = situation
> where unilateral
> authentication is enough?  A client = uncapable of performing a full TLS
> handshake?

If your complaint is that TLS doesn't readily admit to = reducing the level of security, I would argue that TLS is easy enough to = implement in it entirety that that is an irrelevane argument, and that = _less_ security isn't what the world needs right now.

Besides, as John pointed out, it is possible to handle = those cases. And, given the existence of open source TLS = implementations, why would anyone bother to implement a totally new = package that has less security?

Paul

------_=_NextPart_001_01BFD32B.AA1D8DC2-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14924 for ietf-sasl-bks; Sat, 10 Jun 2000 13:49:28 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14920 for ; Sat, 10 Jun 2000 13:49:27 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKrUw02756 for ; Sat, 10 Jun 2000 13:53:30 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYI7X00.NPF for ; Sat, 10 Jun 2000 13:57:33 -0700 Message-ID: <3942AAE3.A6CCFDE3@netscape.com> Date: Sat, 10 Jun 2000 13:54:03 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C4BBC890518868687607636" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms2C4BBC890518868687607636 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client can perform a TLS handshake and ignore the cert sent by the server. Like the proposed mechanism, such a client would be subject to active attacks. Unlike your proposed mechanism, such a client would be protected from passive eavesdropping and would interoperate with the installed base. Our implmentation of STARTTLS in outgoing SMTP relay uses this mode. Subsequent releases will allow the site to configure which domains require protection against active attack in outgoing SMTP relay. > A client uncapable of performing a full TLS handshake? Why would a client capable of managing a client cert and signing authentication requests be uncapable of performing a full TLS handshake? --------------ms2C4BBC890518868687607636 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxNTQwNFowIwYJKoZIhvcNAQkEMRYEFCmRIks4K5gC q7S8+7tCnZFb2+kHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAyEN0w6ycEoCO9PIzqIkpDpmcSi4pJMuWLomOXByPWzv19uBpusZAkJBMnZEldqOi 2/ZrkV35CUIBTKL+pgwib+VfpGC4N3rNpBF6Zkxdd+jLeipNRONetOAnupcUhNxi31XYlNUO Z5u86pF8sL+pH265y4+HmqHrkFwYgp+8R/E= --------------ms2C4BBC890518868687607636-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14759 for ietf-sasl-bks; Sat, 10 Jun 2000 13:34:12 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14755 for ; Sat, 10 Jun 2000 13:34:11 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5AKYrO15561 for ; Sat, 10 Jun 2000 13:34:53 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVYHIG00.QJ0 for ; Sat, 10 Jun 2000 13:42:16 -0700 Message-ID: <3942A746.85B7CE7D@netscape.com> Date: Sat, 10 Jun 2000 13:38:41 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF60FEB9B648E5FBF63A83891" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msF60FEB9B648E5FBF63A83891 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should be made more > explicit in the draft. What is HostA authenticating to, HostB or HostC? Whenever I address one case, you counter with an argument about the other. If the TLS endpoint isn't the same as the application endpoint, you have the TLS endpoint authenticate to the application endpoint using its own credentials, passing the original client's identity in the authorization ID. This results in much better security, as only middlemen the application endpoint is configured to trust are permitted to eavesdrop or modify the the connection. > > I'm sorry, I don't see the argument behind these assertions. What > > difference between TLS and SASL makes TLS a "link" protocol as opposed > > to an "application" protocol? > > IMHO, since it is possible to "insert" SASL in many higher-level protocols > it is a useful mechanism when, for one reason or another, lower level > protocols (I include TLS here) terminates at a gateway or similar, or the > application using the SASL-enabled protocol is unable to run TLS for one > reason or another, but is still capable of doing public-key operations. One can also "insert" TLS in higher-level protocols. See RFC's 2817, 2595, and 2487. TLS is no different than SASL in this regard. How does the theoretical existence of applications which support SASL and public-key operations make TLS a "link" protocol but not an "application" protocol? There do exist applications which support TLS and public-key operations, but are unable to run SASL for one reason or another. > > In your HostA, HostB, HostC situation, how would you handle a SASL > > negotiation using a mechanism that provides perfect forward secrecy of > > the identity being authenticated? > > Just so we are talking about the same thing here: Perfect forward secrecy > = Disclosing one key/authentication does not give an attacker the > possibility to reuse that information in subsequent exchanges. Exactly. Consider a SASL mechanism where the client and server first perform a Diffie-Hellman key exchange. The client then sends the server his cert encrypted with the Diffie-Hellman key and an authenticator formed by signing the Diffie-Hellman key with his private key. Or just explain how in your HostA, HostB, HostC situation you would handle a Kerberos authentication which negotiates a privacy security layer. I brought up the issue of perfect forward secrecy of the identity being authenticated to prevent the answer where HostB and HostC both have access to the server key. > The proposed protocol is vulnerable to session hi-jacking, this fact is > also mentioned in the draft, and true also for other SASL mechanisms not > inserting a security layer. Most of the other SASL mechanisms which don't have a security layer don't have it because they are incapable of negotiating a session key. The thing I don't like about this particular proposal are the implications that this lack of security layer somehow improves security or makes it significantly easier to implement than TLS. --------------msF60FEB9B648E5FBF63A83891 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYxMDIxMzg0MVowIwYJKoZIhvcNAQkEMRYEFFb3JfB2R2u0 AP/6ISFCFoEKfLK+MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAu2suDY3iZTSFCMbAmEaZeODqt/9EnCh8gz3yX6eod11a5YJGkeCmqgo89hEJuUNz 6GhdfIqznFlJdtiqjOStrHREBUk9l0hs2U/voQ1vQ4Yz46PZ6FKLZl5RtX75W0ilfTzmmOai 122j/Q/8Qh2vYXcdPHYwSl9lbm3NPzCsBy8= --------------msF60FEB9B648E5FBF63A83891-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA28330 for ietf-sasl-bks; Sat, 10 Jun 2000 04:01:48 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28326 for ; Sat, 10 Jun 2000 04:01:46 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id HAA05096; Sat, 10 Jun 2000 07:10:15 -0400 (EDT) Date: Sat, 10 Jun 2000 7:10:14 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Paul, > > On Fri, 9 Jun 2000, Paul Leach wrote: > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Friday, June 09, 2000 3:04 AM > > > > > > The TLS endpoint isn't always the same as the application endpoint and > > > that is the very reason for this proposal. Maybe this should > > > be made more explicit in the draft. > > > > Why not? What stops any app that would use the proposed new > > authentication protocol from making the two end points the same and > > using TLS instead? > > > > In fact, nothing does. > > How about: > A client uncapable of verifying certificates? A situation where unilateral > authentication is enough? A client uncapable of performing a full TLS > handshake? > > BR, > -- Magnus > Use a TLS cipher suite that does not use X.509 certificates for authentication. At the moment there is only Kerberos 5 defined as an RFC but there is nothing to stop someone from defining a cipher suite that uses something else. Or you can use TLS in an anonymous mode if you have another authentication mechanism that can prove shared knowledge of unverified data. If so, you take the TLS client finished message and the server finished message and you verify them as part of the authentication method. That will ensure there is no MITM. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18413 for ietf-sasl-bks; Sat, 10 Jun 2000 01:42:26 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA18409 for ; Sat, 10 Jun 2000 01:42:23 -0700 (PDT) Received: (qmail 62027 invoked from network); 10 Jun 2000 08:50:52 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 10 Jun 2000 08:50:52 -0000 Received: (qmail 17246 invoked by uid 1183); 10 Jun 2000 08:51:09 -0000 Date: Sat, 10 Jun 2000 10:51:09 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: Paul Leach cc: John Myers , Robert Zuccherato , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, On Fri, 9 Jun 2000, Paul Leach wrote: > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Friday, June 09, 2000 3:04 AM > > > > The TLS endpoint isn't always the same as the application endpoint and > > that is the very reason for this proposal. Maybe this should > > be made more explicit in the draft. > > Why not? What stops any app that would use the proposed new > authentication protocol from making the two end points the same and > using TLS instead? > > In fact, nothing does. How about: A client uncapable of verifying certificates? A situation where unilateral authentication is enough? A client uncapable of performing a full TLS handshake? BR, -- Magnus Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07932 for ietf-sasl-bks; Fri, 9 Jun 2000 14:36:24 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07928 for ; Fri, 9 Jun 2000 14:36:23 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 13:13:41 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 13:21:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD24F.602B0186" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 13:14:54 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EDA@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R+YJYd8yoMufhR/CtpyI5/ApCngAVi8OA From: "Paul Leach" To: "Magnus Nystrom" , "John Myers" Cc: "Robert Zuccherato" , X-OriginalArrivalTime: 09 Jun 2000 20:21:58.0987 (UTC) FILETIME=[5D0AD1B0:01BFD250] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 3:04 AM > To: John Myers > Cc: Robert Zuccherato; ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > The TLS endpoint isn't always the same as the application endpoint and > that is the very reason for this proposal. Maybe this should=20 > be made more > explicit in the draft. Why not? What stops any app that would use the proposed new authentication protocol from making the two end points the same and using TLS instead? In fact, nothing does. Paul ------_=_NextPart_001_01BFD24F.602B0186 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 3:04 AM
> To: John Myers
> Cc: Robert Zuccherato; ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>

> The TLS endpoint isn't always the same as the = application endpoint and
> that is the very reason for this proposal. Maybe = this should
> be made more
> explicit in the draft.

Why not? What stops any app that would use the = proposed new authentication protocol from making the two end points the = same and using TLS instead?

In fact, nothing does.

Paul

------_=_NextPart_001_01BFD24F.602B0186-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01240 for ietf-sasl-bks; Fri, 9 Jun 2000 09:33:21 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01236 for ; Fri, 9 Jun 2000 09:33:20 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 09:20:58 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 09:29:20 -0700 content-class: urn:content-classes:message Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD22E.E0481654" X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Fri, 9 Jun 2000 09:22:16 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90ED1@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/R92LwGXCMHD7ASm6QmOzF6UyG7QAN883g From: "Paul Leach" To: "Magnus Nystrom" Cc: , X-OriginalArrivalTime: 09 Jun 2000 16:29:20.0300 (UTC) FILETIME=[DD0436C0:01BFD22F] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Friday, June 09, 2000 2:50 AM > To: Paul Leach > Cc: ietf-sasl@imc.org; robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 >=20 > Dear Paul, >=20 > No, I am not mis-speaking. There are in fact architectures like this. >=20 > -- Magnus >=20 Well, then they are deliberately allowing untrusted parties, _including malicious ones, against whom the proposal offers no protection_, to access their communications. They don't need authentication at all, in which case. Paul ------_=_NextPart_001_01BFD22E.E0481654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Friday, June 09, 2000 2:50 AM
> To: Paul Leach
> Cc: ietf-sasl@imc.org; = robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>
> Dear Paul,
>
> No, I am not mis-speaking. There are in fact = architectures like this.
>
> -- Magnus
>

Well, then they are deliberately allowing untrusted = parties, _including malicious ones, against whom the proposal offers no = protection_, to access their communications. They don't need = authentication at all, in which case.

Paul

------_=_NextPart_001_01BFD22E.E0481654-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA22310 for ietf-sasl-bks; Fri, 9 Jun 2000 08:11:45 -0700 (PDT) Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22300 for ; Fri, 9 Jun 2000 08:11:42 -0700 (PDT) Received: from localhost (hodges@localhost) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id IAA12479; Fri, 9 Jun 2000 08:20:12 -0700 (PDT) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id MAA06713 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by networking.Stanford.EDU (8.8.6/8.8.5) with ESMTP id MAA11365 for ; Thu, 8 Jun 2000 12:37:17 -0700 (PDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id LAA24850 for rfc-dist-outgoing; Thu, 8 Jun 2000 11:06:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id LAA24843 for ; Thu, 8 Jun 2000 11:06:56 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA18853; Thu, 8 Jun 2000 11:07:36 -0700 (PDT) Message-Id: <200006081807.LAA18853@boreas.isi.edu> To: rfc-dist@isi.edu Subject: RFC 2831 on Digest SASL Mechanism Cc: rfc-ed@isi.edu Mime-Version: 1.0 Date: Thu, 08 Jun 2000 11:07:36 -0700 From: RFC Editor Content-Type: Multipart/Mixed; Boundary=NextPart Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2831 Title: Using Digest Authentication as a SASL Mechanism Author(s): P. Leach, C. Newman Status: Standards Track Date: May 2000 Mailbox: paulle@microsoft.com, chris.newman@innosoft.com Pages: 27 Characters: 58124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-leach-digest-sasl-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2831.txt This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. This document is a product of the LDAP Extension Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2831 --OtherAccess Content-Type: Message/External-body; name="rfc2831.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000608110522.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10792 for ietf-sasl-bks; Fri, 9 Jun 2000 05:05:49 -0700 (PDT) Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10787 for ; Fri, 9 Jun 2000 05:05:47 -0700 (PDT) Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id IAA16307; Fri, 9 Jun 2000 08:14:05 -0400 (EDT) Date: Fri, 9 Jun 2000 8:14:05 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Magnus Nystrom Cc: Paul Leach , ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: Your message of Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) Message-ID: Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems to me that the fact that you have untrusted middlemen is even more reason why you would use TLS. You do not trust them, therefore you must protect your data end to end. You allow the middlemen to proxy, translate, ... the connection and then you perform an end to end authentication and encryption. > > Dear Paul, > > No, I am not mis-speaking. There are in fact architectures like this. > > -- Magnus > > On Thu, 8 Jun 2000, Paul Leach wrote: > > > > > > > > -----Original Message----- > > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > > Sent: Wednesday, June 07, 2000 10:26 AM > > > To: ietf-sasl@imc.org > > > Cc: robert.zuccherato@entrust.com > > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > > > > Dear Paul and John, > > > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > > several reasons. Among them are: > > > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > > another list:) Many network architectures today have > > > "untrusted" middlemen (gateways, proxies, translators, > > > formatters, > > > > Allowing an "untrusted" middleman to translate or re-format information > > flowing through it smacks of a recipe for disaster. Surely you > > mis-speak. > > > > Paul > > > > -- Magnus > Magnus Nystrom Email: magnus@rsasecurity.com > RSA Security > > > Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org Received: by ns.secondary.com (8.9.3/8.9.3) id DAA02566 for ietf-sasl-bks; Fri, 9 Jun 2000 03:07:53 -0700 (PDT) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02558 for ; Fri, 9 Jun 2000 03:07:51 -0700 (PDT) Received: from 209-6-126-154.c4-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com ([209.6.126.154] helo=PIXIE) by smtp03.mrf.mail.rcn.net with smtp (Exim 2.12 #3) id 130Lps-0004aD-00; Fri, 9 Jun 2000 06:16:20 -0400 Message-ID: <01ca01bfd1fb$07f9c870$9a7e06d1@aa.net> From: "Scott Guthery" To: "Magnus Nystrom" , "Paul Leach" Cc: , References: Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Fri, 9 Jun 2000 06:11:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: WAP, for example. Cheers, Scott ----- Original Message ----- From: Magnus Nystrom To: Paul Leach Cc: ; Sent: Friday, June 09, 2000 5:50 AM Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01404 for ietf-sasl-bks; Fri, 9 Jun 2000 02:56:42 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01400 for ; Fri, 9 Jun 2000 02:56:40 -0700 (PDT) Received: (qmail 47102 invoked from network); 9 Jun 2000 10:05:09 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 10:05:09 -0000 Received: (qmail 3519 invoked from network); 9 Jun 2000 10:05:26 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 10:05:26 -0000 Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: John Myers cc: Robert Zuccherato , ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <393F2732.ADB491F3@netscape.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear John, On Wed, 7 Jun 2000, John Myers wrote: > "Ramsay, Ron" wrote: > > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > > HostB and not HostA! > > In the example I provided in my last message, I am using EXTERNAL > between HostA and HostB. Any SASL mechanism, including EXTERNAL, that > supports an authorization id field can be used between HostB and HostC. > > This is analogous to the example you provided, since that example showed > a TLS security association being established between HostA and HostB. > > > For example, if we were using X.509 authentication, the certification path > > and token would actually travel end-to-end and HostC would indeed receive > > credentials from HostA. > > If you instead want to establish a security association between HostA > and HostC, then HostB should forward the TLS records through between > HostA and HostC. The TLS endpoint isn't always the same as the application endpoint and that is the very reason for this proposal. Maybe this should be made more explicit in the draft. > > This really IS an application protocol. What you are talking about is a link > > protocol. Your remarks about TLS being a session or application protocol are > > simply wrong. > > I'm sorry, I don't see the argument behind these assertions. What > difference between TLS and SASL makes TLS a "link" protocol as opposed > to an "application" protocol? IMHO, since it is possible to "insert" SASL in many higher-level protocols it is a useful mechanism when, for one reason or another, lower level protocols (I include TLS here) terminates at a gateway or similar, or the application using the SASL-enabled protocol is unable to run TLS for one reason or another, but is still capable of doing public-key operations. > In your HostA, HostB, HostC situation, how would you handle a SASL > negotiation using a mechanism that provides perfect forward secrecy of > the identity being authenticated? Just so we are talking about the same thing here: Perfect forward secrecy = Disclosing one key/authentication does not give an attacker the possibility to reuse that information in subsequent exchanges. The proposed protocol is vulnerable to session hi-jacking, this fact is also mentioned in the draft, and true also for other SASL mechanisms not inserting a security layer. -- Magnus Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00469 for ietf-sasl-bks; Fri, 9 Jun 2000 02:42:30 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA00465 for ; Fri, 9 Jun 2000 02:42:27 -0700 (PDT) Received: (qmail 46938 invoked from network); 9 Jun 2000 09:50:54 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 9 Jun 2000 09:50:54 -0000 Received: (qmail 2908 invoked from network); 9 Jun 2000 09:51:11 -0000 Received: from mnystrom-lap.n.dynas.se (10.129.13.102) by spirit.dynas.se with SMTP; 9 Jun 2000 09:51:11 -0000 Date: Fri, 9 Jun 2000 11:50:06 +0200 (W. Europe Daylight Time) From: Magnus Nystrom To: Paul Leach cc: ietf-sasl@imc.org, robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt In-Reply-To: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> Message-ID: X-X-Sender: magnus@[172.16.1.10] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul, No, I am not mis-speaking. There are in fact architectures like this. -- Magnus On Thu, 8 Jun 2000, Paul Leach wrote: > > > > -----Original Message----- > > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > > Sent: Wednesday, June 07, 2000 10:26 AM > > To: ietf-sasl@imc.org > > Cc: robert.zuccherato@entrust.com > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > > > Dear Paul and John, > > > > Thanks for your views. However, IMHO, TLS is not always suitable, for > > several reasons. Among them are: > > > > -(partially quoting from a posting by P. Fahn, Certicom, sent to > > another list:) Many network architectures today have > > "untrusted" middlemen (gateways, proxies, translators, > > formatters, > > Allowing an "untrusted" middleman to translate or re-format information > flowing through it smacks of a recipe for disaster. Surely you > mis-speak. > > Paul > -- Magnus Magnus Nystrom Email: magnus@rsasecurity.com RSA Security Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05481 for ietf-sasl-bks; Thu, 8 Jun 2000 12:34:59 -0700 (PDT) Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05476 for ; Thu, 8 Jun 2000 12:34:57 -0700 (PDT) Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202]) by smtp-outgoing.amazon.com (Postfix) with ESMTP id 456E465F; Thu, 8 Jun 2000 12:43:24 -0700 (PDT) Received: by mail-proxy-2.amazon.com id MAA09585; Thu, 8 Jun 2000 12:43:23 -0700 (PDT) Message-ID: <393FF694.4EEB1D21@amazon.com> Date: Thu, 08 Jun 2000 12:40:04 -0700 From: David Margrave Organization: Amazon.com, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Myers Cc: Linn John , "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <393D876B.5DC135F2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Myers wrote: > > This is why I discourage rather than encourage SPNEGO underneath SASL. > Unless you have a security policy of allowing certain mechanisms only > when their negotiation has been protected, the SPNEGO negotiation > protection doesn't buy you anything. This particular security policy is > explicitly mentioned in the draft as a reason to violate the SHOULD NOT > directive against SPNEGO under SASL. As long as major applications, like say LDAP or IMAP for example, are in love with SASL (Honestly, do you blame them? Good grief, look at the prototype for gss_init_sec_context() some time!), don't you think it's worthwhile to at least go to the effort to add a modicum of real security to it? I mean, the only SASL mech worth a darn security-wise at the moment is GSS-API. I struggled with this for a while, then realized that if both sides really want a secure connection, then can simply decide they're only going to support one SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few extra bytes of cruft (SASL) in front of the GSS token. Everybody is happy, everybody wins. So I would think that an SPNEGO SASL mech would be a good thing, because well-designed implementations of application protocols could be configured to only support one SASL mech (SPNEGO), so that we get real negotiation of a security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around it. Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords" that you would want to avoid by policy configuration. I believe that the best we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so that SASL (which isn't going away) will support SPNEGO as an available option in the vast majority of implementations. Dave Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03210 for ietf-sasl-bks; Thu, 8 Jun 2000 10:27:19 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03205 for ; Thu, 8 Jun 2000 10:27:16 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 10:19:13 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 8 Jun 2000 10:25:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD16C.7CC39E72" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Thu, 8 Jun 2000 10:10:46 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EC0@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QpOmxZOqfIAyMRzCjRDN/0Aj3YQAyCxTA From: "Paul Leach" To: "Magnus Nystrom" , Cc: X-OriginalArrivalTime: 08 Jun 2000 17:25:08.0436 (UTC) FILETIME=[7E3F7940:01BFD16E] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Nystrom [mailto:magnus@rsasecurity.com] > Sent: Wednesday, June 07, 2000 10:26 AM > To: ietf-sasl@imc.org > Cc: robert.zuccherato@entrust.com > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > Dear Paul and John, >=20 > Thanks for your views. However, IMHO, TLS is not always suitable, for > several reasons. Among them are: >=20 > -(partially quoting from a posting by P. Fahn, Certicom, sent to > another list:) Many network architectures today have > "untrusted" middlemen (gateways, proxies, translators,=20 > formatters, Allowing an "untrusted" middleman to translate or re-format information flowing through it smacks of a recipe for disaster. Surely you mis-speak. Paul ------_=_NextPart_001_01BFD16C.7CC39E72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@rsasecurity.com]=
> Sent: Wednesday, June 07, 2000 10:26 AM
> To: ietf-sasl@imc.org
> Cc: robert.zuccherato@entrust.com
> Subject: RE: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
> Dear Paul and John,
>
> Thanks for your views. However, IMHO, TLS is not = always suitable, for
> several reasons. Among them are:
>
> -(partially quoting from a posting by P. Fahn, = Certicom, sent to
>  another list:) Many network architectures = today have
>  "untrusted" middlemen (gateways, = proxies, translators,
> formatters,

Allowing an "untrusted" middleman to = translate or re-format information flowing through it smacks of a recipe = for disaster. Surely you mis-speak.

Paul

------_=_NextPart_001_01BFD16C.7CC39E72-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA29884 for ietf-sasl-bks; Wed, 7 Jun 2000 22:46:35 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29880 for ; Wed, 7 Jun 2000 22:46:34 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e585l8O11218 for ; Wed, 7 Jun 2000 22:47:08 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTN2Q00.9YN for ; Wed, 7 Jun 2000 22:54:26 -0700 Message-ID: <393F3454.564F543D@netscape.com> Date: Wed, 07 Jun 2000 22:51:18 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms81E3B4AA457C0A57A98237DE" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms81E3B4AA457C0A57A98237DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > Can I substitute: > > S: "Authentication failed. Try PLAIN"? Sure. You can even do this as soon as the client sends: C: a AUTHENTICATE "TLS" or even replace all the SASL mechanisms in the banner with just PLAIN. Or you can replace legitimate TLS records with TLS fatal alerts. Protocol spoofers can do all sorts of interesting things if the endpoints have a sufficiently lax security policy. Which brings up an interesting point about the draft. There's no point having the mechanism support mutual authentication because the mechanism doesn't support any security layers. It's useless for the server to prove its identity to the client since the moment the SASL negotiation is over either side could be talking to anybody. --------------ms81E3B4AA457C0A57A98237DE 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA2NTExOFowIwYJKoZIhvcNAQkEMRYEFEmf6VjK05/s TrX6SJpjrIiSHdHHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAAQLP/ptLQO7JQ25oHE/YHur79/vuU+yuONglhRK/8ZM75cEEi0IF6sIOP/VlUs8Z YeWEMbt2/PNzKG+8v8znJIIECNWLSkCDdmU5FdiRgB2a4qiJiy74QYksm8yGrKjtnTErf9ey rtRaDJ5yc6/P7SqLilaVNuwPJ+e66tJEdGU= --------------ms81E3B4AA457C0A57A98237DE-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA25424 for ietf-sasl-bks; Wed, 7 Jun 2000 21:50:32 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25417 for ; Wed, 7 Jun 2000 21:50:31 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e584sOw19763 for ; Wed, 7 Jun 2000 21:54:24 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTKHB00.00E for ; Wed, 7 Jun 2000 21:58:23 -0700 Message-ID: <393F2732.ADB491F3@netscape.com> Date: Wed, 07 Jun 2000 21:55:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms878058F0A2C4ADC712311B67" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms878058F0A2C4ADC712311B67 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > But then you are NOT using SASL/EXTERNAL because HostC is simply validating > HostB and not HostA! In the example I provided in my last message, I am using EXTERNAL between HostA and HostB. Any SASL mechanism, including EXTERNAL, that supports an authorization id field can be used between HostB and HostC. This is analogous to the example you provided, since that example showed a TLS security association being established between HostA and HostB. > For example, if we were using X.509 authentication, the certification path > and token would actually travel end-to-end and HostC would indeed receive > credentials from HostA. If you instead want to establish a security association between HostA and HostC, then HostB should forward the TLS records through between HostA and HostC. > This really IS an application protocol. What you are talking about is a link > protocol. Your remarks about TLS being a session or application protocol are > simply wrong. I'm sorry, I don't see the argument behind these assertions. What difference between TLS and SASL makes TLS a "link" protocol as opposed to an "application" protocol? In your HostA, HostB, HostC situation, how would you handle a SASL negotiation using a mechanism that provides perfect forward secrecy of the identity being authenticated? --------------ms878058F0A2C4ADC712311B67 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA1NTUxNVowIwYJKoZIhvcNAQkEMRYEFGsWQc0PMKXP NDc6eeuaFQLO1pJaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAKVyPxEv0/RGmrO71WAzwBy4i3rUetOPVSjXBvsHmAdb2mbQeM+xryFua7XDnHUh0 mEimCMfSzqGC5g1CxbjfOK3cXnDvokvP/T18gj7KpGOQ4xK24yNnkVrKr9s2IqSlX6L3VrFD vMCwB5EcVfs2NwhK2nlKjltHHTn+5yJoG3A= --------------ms878058F0A2C4ADC712311B67-- Received: by ns.secondary.com (8.9.3/8.9.3) id VAA21074 for ietf-sasl-bks; Wed, 7 Jun 2000 21:23:53 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21065 for ; Wed, 7 Jun 2000 21:23:50 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:34:51 +1000 Message-ID: From: "Ramsay, Ron" To: Lawrence Greenfield , ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:36:03 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry, I'm fascinated by [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" Can I substitute: S: "Authentication failed. Try PLAIN"? Ron. -----Original Message----- From: Lawrence Greenfield [mailto:leg+@andrew.cmu.edu] Sent: Thursday, 8 June 2000 13:05 To: ietf-sasl@imc.org Cc: John Gardiner Myers Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20750 for ietf-sasl-bks; Wed, 7 Jun 2000 21:07:05 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20746 for ; Wed, 7 Jun 2000 21:07:02 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 14:18:03 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 14:19:15 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But then you are NOT using SASL/EXTERNAL because HostC is simply validating HostB and not HostA! For example, if we were using X.509 authentication, the certification path and token would actually travel end-to-end and HostC would indeed receive credentials from HostA. This really IS an application protocol. What you are talking about is a link protocol. Your remarks about TLS being a session or application protocol are simply wrong. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 13:21 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA16280 for ietf-sasl-bks; Wed, 7 Jun 2000 20:16:08 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16276 for ; Wed, 7 Jun 2000 20:16:07 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e583Jxw13107 for ; Wed, 7 Jun 2000 20:19:59 -0700 (PDT) Received: from netscape.com ([198.93.95.203]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTG3Z00.RX6 for ; Wed, 7 Jun 2000 20:23:59 -0700 Message-ID: <393F1110.3519635F@netscape.com> Date: Wed, 07 Jun 2000 20:20:50 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms950CC6E5C461642C245C16E9" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms950CC6E5C461642C245C16E9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I connect to HostB (thinking that it is HostC, if I understand how a DMZ > works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, > so I send my client certificate. The connection is established. Ah, it's as I thought. Mr. Nystrom's statement: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. is entirely false. The middlemen want to eavesdrop on and spoof the plaintext, so you're trying to negotiate a level of security that is lower than TLS permits. What we do in this situation is instead of having HostB forward the EXTERNAL authentication to HostC, we have HostB perform its own SASL negotiation with HostC, using whatever SASL mechanism it wants, providing its own credentials, and passing HostA's user's identity in the authorization id field. TLS can be used between HostB and HostC or not, depending on the site's security requirements. --------------ms950CC6E5C461642C245C16E9 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 MIIIhgYJKoZIhvcNAQcCoIIIdzCCCHMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAfUwggHxAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODA0MjA1MFowIwYJKoZIhvcNAQkEMRYEFFrxOtQjML9w BiJMIEgrxTXT4NdeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAShVpt1Osg2dAgbR7knhyk1wcSCDNoMDdAy/23Z9UcRpyYrnb/m1HjikgfNFH671P lwbkbwCEu8+tD7UUR8C1IT9OXHXq+3617HL2TUin1biSUvq5g1CYQNAuiaN2nVQQmaBSpuaP 0VsOQPNScZ2GfBAa3vFuDpo/BS9qLGrLD7A= --------------ms950CC6E5C461642C245C16E9-- Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13917 for ietf-sasl-bks; Wed, 7 Jun 2000 19:56:14 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13906 for ; Wed, 7 Jun 2000 19:56:13 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id XAA19901; Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT) Message-Id: <200006080304.XAA19901@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: ietf-sasl@imc.org Cc: John Gardiner Myers In-reply-to: <393EF62D.90D04494@netscape.com> Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: <393EF62D.90D04494@netscape.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [...] Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. To be silly, why not do just this? A "TLS" SASL mechanism could easily be made. For example (using ACAP as the protocol to avoid base64 encoding): C: a AUTHENTICATE "TLS" S: "ok, start TLS negotiation" C: {xxx+} C: tls negotiation S: + {xxx} S: more tls negotiation C: {xxx+} C: tls negotiation ... S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5" [ tls security layer takes effect here ] C: "CRAM-MD5" S: + "" C: "response" [ this next response would have to be done in plaintext] S: a OK "Authentication succeeded using TLS/CRAM-MD5" [ tls security layer resumed ] This seems more useful than this proposed mechanism. It allows TLS to be negotiated in any protocol that has a SASL profile. I shudder to add a third option to existing protocols (IMAP, POP) by suggesting this (and I think that sinks this idea) but hey. It does mean that existing protocols need not define a STARTTLS command. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12202 for ietf-sasl-bks; Wed, 7 Jun 2000 19:43:59 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12197 for ; Wed, 7 Jun 2000 19:43:55 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 12:54:56 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 12:56:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An example. We are going to attempt an authenticated logon through a DMZ. Therefore, we have my host, HostA, the DMZ host, HostB, and the destination host, HostC. I connect to HostB (thinking that it is HostC, if I understand how a DMZ works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL, so I send my client certificate. The connection is established. I logon, specifying SASL/EXTERNAL. HostB receives the logon and passes it to HostC. HostC does not have my client certificate and rejects the logon. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 12:23 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA07811 for ietf-sasl-bks; Wed, 7 Jun 2000 19:15:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07806 for ; Wed, 7 Jun 2000 19:15:19 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e582FqO27378 for ; Wed, 7 Jun 2000 19:15:52 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTDAO00.43B for ; Wed, 7 Jun 2000 19:23:12 -0700 Message-ID: <393F0386.999E2B34@netscape.com> Date: Wed, 07 Jun 2000 19:23:02 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B5289C8F322EAB542625529" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4B5289C8F322EAB542625529 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > I thought the statement at issue was that TLS is a good poit-to-point > solution but that it can't be used where middle-men are involved (DMZs, for > example). I am indeed taking issue with this statement. Anywhere you have a SASL protocol definition conforming to RFC 2222 section 4, I can construct an extension to do a TLS negotiation. > In particular, SASL/EXTERNAL cannot be used. I disagree. Please provide a concrete example of where this breaks. > I don't believe TLS is a session layer protocol, either. Its purpose and > implementation are as a network layer look-alike. Wherever TCP is found, TLS > may be shimmed in. TLS can also be shimmed in other places. > I also can't understand references to SASL services and then proposing to > use TLS without client certificates. I am not proposing to use TLS without client certificates, I am using the number of extant TLS implementations without client certificates to support the arugument that client certificate management is significantly harder to implement than TLS. --------------ms4B5289C8F322EAB542625529 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAyMjMwM1owIwYJKoZIhvcNAQkEMRYEFMiF+TX6lseM ob/o6bout1yKNb3jMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAV73BHMxgBYKU97UJf3JKIsXOTz6EuGEqSii/u38gpKSB 2K+qNF6dfOR+0BYAZHkmapbGZ4ounLf26zJzP+SVeopndZmC1B7RvBD24o2/Y4DAp7aL7GAx UEvbxMHs9b1Bduw8mBGFMXxLW1o5ulzQRtgir+ADM5YaQk6Gepcqj48= --------------ms4B5289C8F322EAB542625529-- Received: by ns.secondary.com (8.9.3/8.9.3) id SAA03460 for ietf-sasl-bks; Wed, 7 Jun 2000 18:42:39 -0700 (PDT) Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03456 for ; Wed, 7 Jun 2000 18:42:37 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Jun 2000 11:53:37 +1000 Message-ID: From: "Ramsay, Ron" To: jgmyers@netscape.com, ietf-sasl@imc.org Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Date: Thu, 8 Jun 2000 11:54:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I must have blinked. I thought the statement at issue was that TLS is a good poit-to-point solution but that it can't be used where middle-men are involved (DMZs, for example). In particular, SASL/EXTERNAL cannot be used. I don't believe TLS is a session layer protocol, either. Its purpose and implementation are as a network layer look-alike. Wherever TCP is found, TLS may be shimmed in. So, it provides neither transport nor session services. I also can't understand references to SASL services and then proposing to use TLS without client certificates. Even if SASL/EXTERNAL could be used, it would be useless without client certificates. Ron. -----Original Message----- From: jgmyers@netscape.com [mailto:jgmyers@netscape.com] Sent: Thursday, 8 June 2000 11:26 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA28339 for ietf-sasl-bks; Wed, 7 Jun 2000 18:18:20 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA28327 for ; Wed, 7 Jun 2000 18:18:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e581MAw02792 for ; Wed, 7 Jun 2000 18:22:10 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVTANN00.SZ5 for ; Wed, 7 Jun 2000 18:26:11 -0700 Message-ID: <393EF62D.90D04494@netscape.com> Date: Wed, 07 Jun 2000 18:26:05 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDBB2633BB5C5E1273A580AC7" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------msDBB2633BB5C5E1273A580AC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > The end users and content providers and application developers > should be able to put in security on top of all the middlemen, at > the application layer. TLS and SASL are both session layer protocols. The name "Transport Layer Security" is a misnomer, TLS is not part of TCP, it is a layer above TCP. Anywhere you can add a command to a protocol to do a SASL negotiation you can also add a command to do a TLS negotiation. > And middlemen want the same thing to avoid the > liability that comes with seeing all the plaintext. Since proposed SASL mechanism doesn't support any security layers, when it is used the middlemen will always see the plaintext. > -As mentioned in the draft, TLS is more complex and does not carry the > concept of separate authentication and authorization identities. The concept of separate authentication and authorization identities is handled through the use of the EXTERNAL SASL mechanism once the TLS negotiation is complete. As I have mentioned before, TLS complexity is small compared to the complexity of key and certificate management, as evidenced by the number of applications implementing TLS but not implementing client certs. --------------msDBB2633BB5C5E1273A580AC7 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwODAxMjYwNlowIwYJKoZIhvcNAQkEMRYEFNLKjvs652s1 3hpbQ538rPu1D4gFMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAvfFI/2UTzJneXp+zjtV7J/OaBzCnOpXj4nnMVel1FKtp PMVFH+xY7+uOSpMd+//MIz52ZxEDjTRnPydmdzbIuyPp/cqvMEWfMSXcY9ew20iU2+Alhvfn dkxVFQVhHyHZQaD5PEzR2utRl1yZ+I2N1oAlgljteehtHUn68LxnuhU= --------------msDBB2633BB5C5E1273A580AC7-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA11657 for ietf-sasl-bks; Wed, 7 Jun 2000 10:21:13 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11653 for ; Wed, 7 Jun 2000 10:21:11 -0700 (PDT) Received: (qmail 22849 invoked from network); 7 Jun 2000 17:29:31 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:29:31 -0000 Received: (qmail 19949 invoked by uid 1183); 7 Jun 2000 17:29:48 -0000 Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, Many thanks for your comments and suggestions for improvements. My response below. On Tue, 6 Jun 2000, Chris Newman wrote: > --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom > wrote: > > FYI. Comments and feedback is welcome and solicited. > > I skimmed the document. I'm sorry I don't have time to chase down all the > X.509/FIPS references necessary to grok the spec. > > (1) It seems to have far too many things marked "OPTIONAL". This makes the > protocol more complex than necessary. Preferably the only OPTIONAL items > should be the differences between one-way and mutual auth. RandomC > certainly has no business being optional. Right, we will change this in the next draft. > (2) I don't understand the value of this if the client cert is optional. > Doesn't that mean the server has to store the certs for every possible > client in order to guarantee interoperability? Or am I missing something? Yes, client CertData should probably be mandatory. > (3) I presume this factors in the DNS name of the server which the client > intends to communicate with -- usually the only information the client has > about the server. Where can I read the rules for how that is used? Is > that put in the EntityB field? Is the case where multiple physical servers > answer for the same domain name considered? Is it possible for each > physical server to have a different private key in that case? Yes it is. Only requirement is that the server is able to see that the client intended to communicate with it - if, e.g., there is a round-robin DNS, then for all intent and purposes involved servers are the same (from the client's perspective). It could be that the DNS name is a SHOULD (or even a MUST?). > (4) I don't see a clear statement of how to determine the authorization > identity (user to log in as, which may be different from the user whose > private key is used). If this is buried somewhere in X.509 specs, please > draw attention to it in the spec. Correct, thanks for the observation. There should be an explicit, but optional, authorization id included. If not included, the server will have to use the authenticated id. > (5) The reference to RFC 1738 should be updated to RFC 2396. Right. > (6) Is there a fast re-authentication option, or should TLS be used when > that's needed? Note that many POP clients make a connection every 5 > minutes to check mail, and some IMAP clients make a new connection every > time a new folder is opened so a fast re-authentication protocol could be > important for scalability. No, there is no fast re-authentication option. One could add one (for example by letting the entities negotiate a session secret) but it is our feeling that this would complicate the mechanism unnecessarily. > (7) Is there an open-source implementation of RFC 2459? If not, this seems > much more complex than TLS where I can just grab OpenSSL and let it do all > the work. Certificate-handling open-source is certainly available,e.g. as part of OpenSSL, and ssleay, but the Jonah PKIX freeware library is another alternative, I guess. > (8) The IETF has a policy (the "Munich Mandate") which prohibits making > patented algorithms mandatory to implement when there's and unpatented > equivalent. I consider the recommendation to implement the RSA algorithm > inappropriate given that policy. Since this is a set of mechanisms rather > than a protocol, the recommendation is not necessary for interoperability > so you could simply remove it. Alternatively you could change it to > recommend DSA, or wait until after September 20th for standardization. Right, the latter was (and is) our intent. Thanks, -- Magnus Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11530 for ietf-sasl-bks; Wed, 7 Jun 2000 10:17:24 -0700 (PDT) Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA11524 for ; Wed, 7 Jun 2000 10:17:21 -0700 (PDT) Received: (qmail 22791 invoked from network); 7 Jun 2000 17:25:40 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 7 Jun 2000 17:25:40 -0000 Received: (qmail 19734 invoked by uid 1183); 7 Jun 2000 17:25:57 -0000 Date: Wed, 7 Jun 2000 19:25:57 +0200 (MET DST) From: Magnus Nystrom X-Sender: magnus@spirit.dynas.se Reply-To: Magnus Nystrom To: ietf-sasl@imc.org cc: robert.zuccherato@entrust.com Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Paul and John, Thanks for your views. However, IMHO, TLS is not always suitable, for several reasons. Among them are: -(partially quoting from a posting by P. Fahn, Certicom, sent to another list:) Many network architectures today have "untrusted" middlemen (gateways, proxies, translators, formatters, and it is not unlikely that architectures like this will increase in numbers. The end users and content providers and application developers should be able to put in security on top of all the middlemen, at the application layer. And middlemen want the same thing to avoid the liability that comes with seeing all the plaintext. Since one will not always have simple two-party network topologies, simple transport-layer channel security will not always be enough. -As mentioned in the draft, TLS is more complex and does not carry the concept of separate authentication and authorization identities. Regards, -- Magnus On Tue, 6 Jun 2000, Paul Leach wrote: > > -----Original Message----- > > From: John Myers [mailto:jgmyers@netscape.com] > > Sent: Tuesday, June 06, 2000 5:03 PM > > To: ietf-sasl@imc.org > > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt > > > > TLS does appear to have won the X.509 space and is gaining > > implementation momentum. I think this draft is approaching the > > wrong problem. > > I concur completely. > > Paul Received: by ns.secondary.com (8.9.3/8.9.3) id TAA04731 for ietf-sasl-bks; Tue, 6 Jun 2000 19:01:38 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA04721 for ; Tue, 6 Jun 2000 19:01:36 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 18:45:50 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 18:45:53 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD021.244B91F6" Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Tue, 6 Jun 2000 18:38:55 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690BC90EB8@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-zuccherato-9798-3-sasl-00.txt Thread-Index: Ab/QE4de/K5YKnZcShqLBlUQP9UeSAACYjog From: "Paul Leach" To: "John Myers" , X-OriginalArrivalTime: 07 Jun 2000 01:45:53.0859 (UTC) FILETIME=[1DE3B130:01BFD022] Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: John Myers [mailto:jgmyers@netscape.com] > Sent: Tuesday, June 06, 2000 5:03 PM > To: ietf-sasl@imc.org > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt >=20 >=20 > TLS does > appear to have won the X.509 space and is gaining implementation > momentum. I think this draft is approaching the wrong problem. I concur completely. Paul ------_=_NextPart_001_01BFD021.244B91F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

> -----Original Message-----
> From: John Myers [mailto:jgmyers@netscape.com]
> Sent: Tuesday, June 06, 2000 5:03 PM
> To: ietf-sasl@imc.org
> Subject: Re: I-D Action: = draft-zuccherato-9798-3-sasl-00.txt
>
>
>  TLS does
> appear to have won the X.509 space and is = gaining implementation
> momentum.  I think this draft is = approaching the wrong problem.

I concur completely.

Paul

------_=_NextPart_001_01BFD021.244B91F6-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA18711 for ietf-sasl-bks; Tue, 6 Jun 2000 16:55:47 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18704 for ; Tue, 6 Jun 2000 16:55:45 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NuFO22674 for ; Tue, 6 Jun 2000 16:56:15 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRC5W00.JX4 for ; Tue, 6 Jun 2000 17:03:32 -0700 Message-ID: <393D914B.3FEBD002@netscape.com> Date: Tue, 06 Jun 2000 17:03:23 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-sasl@imc.org Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5EBBBA0BCDF14825170DA5B8" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms5EBBBA0BCDF14825170DA5B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I second Chris Newman's comments, though I think that if this is intended for standardization then waiting for September 20 is better than switching to DSA. I'd appreciate it if you could expand on why you want to do this as a SASL mechanism instead of using a combination of TLS and the EXTERNAL SASL mechanism. My experience with implementing this stuff is that the key and certificate management aspects are far harder to implement than the protocol aspects. Each of the important protocols has an extension to start a TLS negotiation on a previously unprotected connection. At the latest MailConnect, there were quite a few implementations of these STARTTLS extensions. Only three of these companies supported client certs, this was up from one company the previous year. A product implementing only this draft will not interoperate with a product implementing only the combination of TLS and EXTERNAL. TLS does appear to have won the X.509 space and is gaining implementation momentum. I think this draft is approaching the wrong problem. --------------ms5EBBBA0BCDF14825170DA5B8 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNzAwMDMyNFowIwYJKoZIhvcNAQkEMRYEFOQ2w36fvM1N 2obU4EoevVUWtmq2MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGALFHw1flmrJp1XESJfKEAZEDOmtGVf+9ws0puzDd2klV6 8Zy3+QCN4qBnhZfn8Mm7GkGEeLD6oWbbu4lGWncNSWciZgOcTxVtEoufQcCDCMiB66Qh3NiS TCEu/BtFN1kHJAkxRAZg0o4omsIi23hN1K+nEE3U70HOhaz+PEFXy/0= --------------ms5EBBBA0BCDF14825170DA5B8-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA15383 for ietf-sasl-bks; Tue, 6 Jun 2000 16:13:40 -0700 (PDT) Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15378 for ; Tue, 6 Jun 2000 16:13:39 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56NHPw08710 for ; Tue, 6 Jun 2000 16:17:25 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVRA7O00.CTM; Tue, 6 Jun 2000 16:21:24 -0700 Message-ID: <393D876B.5DC135F2@netscape.com> Date: Tue, 06 Jun 2000 16:21:15 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Linn John" CC: "'Ken Hornstein'" , ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms44C1D113AC5AE39E0F921503" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms44C1D113AC5AE39E0F921503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Linn, John" wrote: > There's a security vs. interoperability tradeoff, since the > SPNEGO negotiation is protected but the SASL negotiation isn't. The design criterion I've used in preparing the draft is that one should not trade away interoperability unless there exists a requirement in a site's security policy which is incompatible with that interoperability. > I'd suggest > recommending, not discouraging, support for SPNEGO for use where available > and appropriate, but also recommending configurable support to allow > negotiation of individual GSS mechanisms at the SASL level. The applicable requirement in the current draft is: In any case, there is no down-negotiation security consideration with using the strongest mechanism and set of options the implementation supports, so for interoperability that mechanism and set of options MUST be negotiable without using the "GSS-SPNEGO" mechanism. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if none > of the GSS mechanisms are available. If (1), the client is most easily > served by performing the negotiation (and exposing the individual GSS > mechanisms) at the SASL level. Given the prospect of (2), however, it'd be > good to be able to negotiate among the available GSS mechanisms in an > SPNEGO-protected manner. If your security policy allows the negotiation of a weak mechanism outside of SPNEGO, then what benefit are you gaining from SPNEGO? An active attacker can make it appear that SPNEGO is not suppported by the other side, removing all benefit of SPNEGO over SASL mechainsm negotiation. This is why I discourage rather than encourage SPNEGO underneath SASL. Unless you have a security policy of allowing certain mechanisms only when their negotiation has been protected, the SPNEGO negotiation protection doesn't buy you anything. This particular security policy is explicitly mentioned in the draft as a reason to violate the SHOULD NOT directive against SPNEGO under SASL. --------------ms44C1D113AC5AE39E0F921503 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIzMjExNlowIwYJKoZIhvcNAQkEMRYEFNVm9y3JzG4m ZTtkVAIIRPY2eYc6MCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAmk9WHFo4eyYhkQ4ETuGpyANwwAcjbnn052pPoH0Ou4zD 4hFNvNZN9BSIjHnMMeMW4ZpkCeJQEAP9GFMpS3rIzZeoQXjQtRDUlOYvQbecH7rg9mDTybY+ q/3ASKEJM6yvcdChQQYg+Y29iCV2/J/r9pMhtdd4yTiLAHeQf+ITPwU= --------------ms44C1D113AC5AE39E0F921503-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA15161 for ietf-sasl-bks; Tue, 6 Jun 2000 15:49:30 -0700 (PDT) Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15157 for ; Tue, 6 Jun 2000 15:49:29 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id e56MnuO13661 for ; Tue, 6 Jun 2000 15:49:56 -0700 (PDT) Received: from netscape.com ([192.18.126.70]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FVR93C00.HR0; Tue, 6 Jun 2000 15:57:12 -0700 Message-ID: <393D812E.8D123B88@netscape.com> Date: Tue, 06 Jun 2000 15:54:38 -0700 From: jgmyers@netscape.com (John Myers) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Subject: Re: SASL GSSAPI draft References: <200005300336.e4U3aDt00689@ginger.cmf.nrl.navy.mil> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7A4108F79C32C4FD17956951" Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7A4108F79C32C4FD17956951 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ken Hornstein wrote: > Okay, I saw only a message from Bill Ricker asking about SPNEGO, > posting by you, and Paul Leach's reply. I recall some other exchange when I first published a draft, but haven't located it. It doesn't much matter, we're having a good discussion about this now. > Having said that .... I > think that a client that sent a SPNEGO token to a SPNEGO-unaware > server would fail. I have been thinking for a while on how to > migrate to clients & servers supporting SPNEGO, and I haven't come > up with any good ideas yet (if I'm missing something obvious, then > please let me know). I don't think you can make this work and maintain SPNEGO's security requirement to protect the negotiation of mechanism. A man in the middle could make it appear to each side that the other does not support SPNEGO, thus forcing a downgrade to the weakest mechanism. If you are willing to take this risk, forgoing this property of SPNEGO, then the propsal to negoitate the mechanism directly through SASL instead of through SPNEGO is simpler. > This presumes that the app will have to have special-case code to > determine which mechanisms exist and to apply policy information > to the mechanism list; I'm not sure how you'll do that without > giving the app knowledge of each mechanism, which would kinda defeat > part of the purpose of GSSAPI. I have a hard time imaging this done > in practice (it seems that you can give SPNEGO some policy constraints, > but it doesn't give you the ability to do the ordering you want). Typically, a SASL library has both policy constrants and a mechanism preference ordering. Usually the preferences are ordered from strongest mechanism to weakest, but sometimes the cost of obtaining a credential affects this. For example, if the SASL library has a Kerberos credential available, it may want to use Kerberos over any mechanism that will need to prompt the user. --------------ms7A4108F79C32C4FD17956951 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 MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIeFDANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA2MDIxNzE1MjlaFw0wMDExMjkxNzE1Mjla MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 0+WYWlf3g+u6vFEBJwo+4Cxz0PM5GUuqOHGVkjPFTeGjR05BUJADWm8mZDoAhUuIVuTvixCx AB0f5JzDWmIIWbB0ea92RwOHdibSS3bT0BTwKNTgt+PQAH3ZdH+IjmGAZI6/J+5Ob3m43ZZl o/3lfGEd4O7gAJY62Sy76MgO1O0CAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAGPAOC3FZineuE0PLv+pKc52i5uz+lpHzvssmUrr5FNSSD3M+DBow7Sd3YW+ vyPVAxH+MZ5RtE+If/aDDYQhgpCtbujQb5wPVRS5ZCmKpAC0eOnP12jcUDLr1tfhyBIlIvJQ 6xGKj7ckSK6G7lNxuQ8a12v/v2yEEk2uADg51oY7MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIeFDAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDYwNjIyNTQzOVowIwYJKoZIhvcNAQkEMRYEFJFTsgpttt09 IoHjQ4t45VWOxQMlMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAYrx0vJLB5W0xTTs+3FYOyFqRMCSV8E/yQ15mr+XPU6XL F5ykhvMhCH2fIlKoSFrkdLzFCUKSg1hB/Ll26ZA/+ufPiViWbWE5CVDcm0K80vitFaB87wkN fhnUFr7ooXmIS2H8H7GpIMe4hhQlzWTyBigKVJ5BgSYAPDUoCJVgi6w= --------------ms7A4108F79C32C4FD17956951-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05976 for ietf-sasl-bks; Tue, 6 Jun 2000 08:50:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05972 for ; Tue, 6 Jun 2000 08:50:04 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13425 for ; Tue, 6 Jun 2000 08:58:18 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22630 for ; Tue, 6 Jun 2000 08:58:11 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27374 for ; Tue, 6 Jun 2000 08:56:32 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO37C@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Date: Tue, 06 Jun 2000 08:54:58 -0700 From: Chris Newman Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt To: Magnus Nystrom , ietf-sasl@imc.org Message-id: <1367452.3169270498@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom wrote: > FYI. Comments and feedback is welcome and solicited. I skimmed the document. I'm sorry I don't have time to chase down all the X.509/FIPS references necessary to grok the spec. (1) It seems to have far too many things marked "OPTIONAL". This makes the protocol more complex than necessary. Preferably the only OPTIONAL items should be the differences between one-way and mutual auth. RandomC certainly has no business being optional. (2) I don't understand the value of this if the client cert is optional. Doesn't that mean the server has to store the certs for every possible client in order to guarantee interoperability? Or am I missing something? (3) I presume this factors in the DNS name of the server which the client intends to communicate with -- usually the only information the client has about the server. Where can I read the rules for how that is used? Is that put in the EntityB field? Is the case where multiple physical servers answer for the same domain name considered? Is it possible for each physical server to have a different private key in that case? (4) I don't see a clear statement of how to determine the authorization identity (user to log in as, which may be different from the user whose private key is used). If this is buried somewhere in X.509 specs, please draw attention to it in the spec. (5) The reference to RFC 1738 should be updated to RFC 2396. (6) Is there a fast re-authentication option, or should TLS be used when that's needed? Note that many POP clients make a connection every 5 minutes to check mail, and some IMAP clients make a new connection every time a new folder is opened so a fast re-authentication protocol could be important for scalability. (7) Is there an open-source implementation of RFC 2459? If not, this seems much more complex than TLS where I can just grab OpenSSL and let it do all the work. (8) The IETF has a policy (the "Munich Mandate") which prohibits making patented algorithms mandatory to implement when there's and unpatented equivalent. I consider the recommendation to implement the RSA algorithm inappropriate given that policy. Since this is a set of mechanisms rather than a protocol, the recommendation is not necessary for interoperability so you could simply remove it. Alternatively you could change it to recommend DSA, or wait until after September 20th for standardization. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05944 for ietf-sasl-bks; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05940 for ; Tue, 6 Jun 2000 08:49:47 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13253 for ; Tue, 6 Jun 2000 08:58:01 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28012 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27362 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO279@elvira.west.sun.com> for ietf-sasl@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 21:51:30 -0700 From: Chris Newman Subject: RE: SASL GSSAPI draft In-reply-to: To: "Linn, John" , "'Ken Hornstein'" , jgmyers@netscape.com Cc: ietf-cat-wg@lists.Stanford.EDU, ietf-sasl@imc.org Message-id: <850698.3169230690@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-sasl@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" wrote: > It's certainly true that an SPNEGO token won't be usefully processable by > a target which doesn't support SPNEGO. If, however, a GSS implementation > can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that > GSS implementation is being used with SASL, it may not be too much > incremental effort to make GSS_MECH_A and GSS_MECH_B also available for > negotiation at the SASL level. There's a security vs. interoperability > tradeoff, since the SPNEGO negotiation is protected but the SASL > negotiation isn't. I'd suggest recommending, not discouraging, support > for SPNEGO for use where available and appropriate, but also recommending > configurable support to allow negotiation of individual GSS mechanisms at > the SASL level. Some problems with recommending SPNEGO in SASL: There are standards-compliant email servers deployed which only support Kerberos 5 (GSSAPI SASL) and don't support SPNEGO. Any email server which only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards track) for Kerberos 5 support is hostile both to the installed base of standards-compliant servers and to the deployment of Kerberos 5. If admins encounter an interop problem when trying to upgrade security, the first thing they usually do is back out the security upgrade. We don't want that to happen. I suspect the protection provided by SPNEGO will be irrelevant to most SASL-based protocols in practice because they'll get integrity protection from either TLS or IPsec prior to the SASL negotiation if they want it at all. So it just doesn't seem to be worth the extra round trip(s), IMHO. > If an application client (and its associated SASL and/or SPNEGO client) > supports policy-driven mechanism negotiation, the preferred set might (1) > span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms > only, with non-GSS SASL mechanisms to be invoked only as a fallback if > none of the GSS mechanisms are available. If (1), the client is most > easily served by performing the negotiation (and exposing the individual > GSS mechanisms) at the SASL level. Given the prospect of (2), however, > it'd be good to be able to negotiate among the available GSS mechanisms > in an SPNEGO-protected manner. I'm very uncomfortable with options in security protocols. Every option can double the complexity of a security analysis of the software. I suspect that any benefit gained by making SPNEGO an option will be outweighed by the cost of a security analysis of both codepaths and the interaction between various security polices and SPNEGO/SASL mechanism lists. - Chris